SIU-Toba / framework

Framework para desarrollo rápido de aplicaciones web
http://toba.siu.edu.ar
21 stars 24 forks source link

Generación innecesaria de archivos de logs para WS #30

Closed sergiovier closed 6 years ago

sergiovier commented 6 years ago

En toba, el logger para los servicios rest parece estar configurado de forma incorrecta. Con sistemas medianamente intensivos en el acceso a sus api rest, tenemos cientos de archivos de logs que nos quedan en i__<instancia>/p__<aplicacion>/logs/web_services/.

Tal parece que el inconveniente puede venir por acá, por cada ID de solicitud se está generando un archivo.

/cc @enfoqueNativo @andres-blanco

enfoqueNativo commented 6 years ago

No esta configurado de manera incorrecta, es una decision de diseño a causa del requerimiento. Para WS (soap, rest) se pidio poder loguear un pedido incompleto (para obtener algo de informacion ante un fatal) y tener la posibilidad de efectuar un checkpoint por codigo para forzar el logueo en varios momentos.

Eso hizo que se deban separar los logs en distintos archivos, ya que es imposible loguear de manera continua como si sucede con los proyectos, donde se espera a la finalizacion del pedido de pagina. Quizas se podria evitar el id de solicitud, pero eso implicaria que quedarian logueados en un mismo archivo llamadas a distintos WS con distintos checkpoints, lo que guardaria pedidos mezclados entre si.

Otra opción seria que salga desactivado por defecto y se active de manera explicita ante un acontecimiento, se dejo asi para mantener homogeneidad con el log del proyecto.

sergiovier commented 6 years ago

La opción de desactivarlo por defecto me parece válida. Se está generando mucho output de manera estándar.

Por otro lado, como ves que se tome el camino de mandar todo a un mismo logger (archivo) y formatear la entrada cosa de que contenga el ID de la solicitud? No será fácil de leer para el que mira a mano un log, pero también hoy por hoy los que juegan en serio o tengan un volumen indecente tendrán algo que les permita sistematizarlo.

enfoqueNativo commented 6 years ago

La opción de desactivarlo por defecto me parece válida. Se está generando mucho output de manera estándar.

Es verdad, lo pongo como desactivado para la próxima versión.

Por otro lado, como ves que se tome el camino de mandar todo a un mismo logger (archivo) y formatear la entrada cosa de que contenga el ID de la solicitud? No será fácil de leer para el que mira a mano un log, pero también hoy por hoy los que juegan en serio o tengan un volumen indecente tendrán algo que les permita sistematizarlo.

Para mandarlo todo a un solo lugar, habría que cambiar el mecanismo de log directamente, onda usar Monolog en todo (incluso Toba). Como esta hoy, tenerlo todo en un mismo archivo te genera pedidos de pagina cortados (cuando cicla), complicando aun mas el debug. Por otro lado, hay que cambiar la manera en la que trabaja ya que al guardar parcialmente hay que trackear que se guardo y que no, es posible.. pero quizas requiera algo mas integral.

hslavich commented 6 years ago

El logger hace un chmod que en directorios con mucha cantidad de logs (+100k) genera tiempos de respuestas muy altos haciendo la api practicamente inaccesible.

https://github.com/SIU-Toba/framework/blob/41255e63c1c9b460cdabcd03b71681eacb0cb207/php/nucleo/lib/toba_logger_ws.php#L115

enfoqueNativo commented 6 years ago

El logger hace un chmod que en directorios con mucha cantidad de logs (+100k) genera tiempos de respuestas muy altos haciendo la api practicamente inaccesible.

framework/php/nucleo/lib/toba_logger_ws.php

Line 115 in 41255e6

      @toba_manejador_archivos::chmod_recursivo($path, $permisos);

Si, por eso se cambia la forma de loguear, se va por un esquema de unico archivo por defecto y posibilidad de explicitar la separación: framework/php/nucleo/lib/toba_logger_ws.php