2010-05-16 18 views
9

GoogleAppEngineLauncher puede mostrar el archivo de registro local de mi aplicación mientras se ejecuta en mi Mac durante el desarrollo. Sin embargo, no puedo cambiar el tamaño de la fuente allí, así que me gustaría usar el comando tail para ver el archivo de registro.¿Dónde guarda GoogleAppEngineLauncher los archivos de registro locales?

Es una lástima, pero no puedo encontrar los archivos de registro. No están bajo /var/log/, ~/Library/Logs o /Library/Logs. ¿Sabes dónde están?

(Tal vez no hay archivos físicos, sólo la salida estándar del entorno de desarrollo Python y por lo que el registro sólo está disponible en el lanzador de aplicaciones.)

Respuesta

8

Como supones, y puede confirmar mediante el estudio del archivo de origen /usr/local/google_appengine/google/appengine/tools/dev_appserver.py , los registros no se escriben en el disco (se usa una instancia cStringIO.StringIO para mantenerlos en la memoria, ya que el resto del código está orientado a escribirlos "en un objeto similar a un archivo").

Lo que yo recomendaría es escribir su propio guión servidor de aplicaciones, que importa dev_appserver, subclases dev_appserver.ApplicationLoggingHandler, y anula simplemente uno método:

from google.appengine.tools import dev_appserver 

class MyHandler(dev_appserver.ApplicationLoggingHandler): 

    def __init__(self, *a, **k): 
     dev_appserver.ApplicationLoggingHandler.__init__(self, *a, **k) 
     self.thefile = open('/tmp/mylog.txt', 'w') 

    def emit(self, record): 
     dev_appserver.ApplicationLoggingHandler(self, record) 
     self.thefile.write(str(record) + '\n') 
     self.thefile.flush() 

También es necesario asegurarse de esta clase se utiliza en lugar de la estándar, por ejemplo al crear una subclase en el despachador o al asegurar que usa su capacidad de inyección de dependencia. (dev_appserver_main.py le permite controlar esto mejor, creo).

Creo que este enfoque de personalización es mucho más engorroso de lo que debería (es perfectamente normal querer los registros escritos en el archivo, después de todo, ya sea para mostrarlos de manera diferente, como desee, o para procesarlos luego con algunos script auxiliar), así que también recomendaría poner una solicitud de función en el rastreador del motor de la aplicación: dev_appserver.py debería aceptar un indicador más, que, si se especifica, proporciona la ruta en la que se escribirán los registros en el disco.

Y, para ser sincero, si necesitara esta característica ahora mismo, lo haría de la manera sucia: editando ese archivo .py (y su relacionado _main.py) para agregar dicha marca y su uso. Eso debería ser una docena de líneas en total, mucho más fácil que la manera "canónica" que acabo de delinear. Por supuesto, es sucio porque cada vez que hay un nuevo SDK tendrá que volver a aplicar el parche, una y otra vez ... por lo que uno debería también proponer el parche en el rastreador de GAE, como parte de la solicitud de función sugerí, con la esperanza de que sea aceptada pronto -)

+1

Ya que esto requiere ejecutar el script de todos modos (en lugar de a través del iniciador), simplemente podría ejecutar " dev_appserver.py <...> | tee logfile " –

4

Un simple, y también sucia, solución es añadir el siguiente código en el archivo de dev_appserver.py, hacia la parte superior:

import logging 
logging.basicConfig(filename='/tmp/gae.log', filemode='a') 

Obviamente, cambie su archivo de registro a lo que desee. Esto requiere la menor cantidad de cambios, y es el más fácil de comprometer en su repositorio y diff cuando hay una nueva versión.

Actualización: Ligeramente mejor podría ser para convertirlo en una opción de línea de comandos:

def start_logging(): 
    import logging 

    logfile='' 
    for item in sys.argv[1:]: 
    if re.match('--log_file=', item): 
     logfile=item.split('=')[1] 
     # Remove this item from sys.argv 
     sys.argv.remove(item) 
     break 

    if logfile: 
    print "Please monitor the log file (with tail -f %s)" % logfile 
    logging.basicConfig(filename=logfile, filemode='a') 
0

Si lo que desea es ver los registros en tiempo de ejecución, que se imprimen en la línea de comandos junto con las llamadas HTTP.

logging.debug() y logging.error() no se imprimen, pero las llamadas hacia arriba son info.

Ver this answer para un poco más de detalle.

5

Muchas de estas respuestas están desactualizadas. :)

En el devappserver de hoy, use --logs_path=LOGS_FILE si desea iniciar sesión en un archivo (en su formato de base de datos sqlite nativo). O como se sugiere en un comentario, simplemente canalice la salida si eso es demasiado complicado.

Dado que hay una API de registro, en realidad ahora almacena las entradas de registro en un archivo en --storage_path si no se establece. Aunque he notado algunos errores. (supondré que no existen ahora, ha pasado un tiempo desde que usé esto.)

+0

Cuando hago esto, las cosas de SQLLite3 se almacenan en el archivo especificado en --logs_path (no quiero cosas de SQLLite3, no sé de qué se trata), pero los registros que quiero se escriben en el bash stdout (por lo tanto, piping como Nick Johnson sugiere que funciona para mí). Además, ¿qué es --storage_path? Además, ¿qué errores notaste? Gracias. –

+0

La tubería también funciona bien. El material sqlite3 * es * el registro de datos, aunque creo que podría haber sido texto anterior. Consulte http://stackoverflow.com/questions/24226078/how-to-decode-the-persisted-log-files-from-app-engines-python-dev-server o use una aplicación como https: // www.google.ca/search?q=sqlite%20osx - Edité mi respuesta para reflejar su comentario. ¡Gracias! :) –

+0

respuesta pensativa, gracias. Último comentario, incluso las tuberías no funcionaron, el material de registro simplemente se imprimió directamente en el shell (¿consola?). Alguna idea sobre esto? ¿Es un problema de "TTY"? Estoy usando Git Bash en Windows, el mismo problema tratando de canalizar con Windows Cmd normal. Gracias +1. –

Cuestiones relacionadas