Closed sergiovier closed 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.
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.
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.
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.
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
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