Manejando los logs en Finizens
Cuando llegué a Finizens, una de las cosas que más me llamaron la atención fue el funcionamiento y explotación de los logs que existía. Anteriormente ya había trabajado en otras empresas donde se realizaba una buena gestión con los logs, pero en Finizens lo tenemos configurado de forma que se ajusta y se reacciona acorde a la importancia del evento, y lo comunica a través de los canales adecuados, consiguiendo que nos enteremos por diferentes vías para que no se nos escape nada.
Los logs pueden llegar a ser muy importantes, ya que, bien montados, revelan absolutamente todo lo que puede estar pasando en la aplicación, ya sea a nivel de errores, o simplemente informativo, como por ejemplo sobre a qué rutas se está accediendo. Esta configuración nos ha permitido, en nuestro caso, mejorar el workflow, pero no solo a nosotros, los desarrolladores, sino que hemos extendido su utilidad a otros departamentos.
Por un lado hemos conseguido automatizar la creación de tareas en github desde la integración con Rollbar, que a su vez, de acuerdo a unas reglas definidas, nos envía un enlace a la tarea a un canal de Slack, por ahora trabajamos con dos: warnings o errors.
También tenemos integración directa con Slack, de forma que algunos eventos que pueden ser un aviso de un caso delicado lo mandamos al canal de warnings.
Y actualmente también utilizamos CloudWatch, para registrar ahí todos los logs que ocurren en producción.
Pero también tenemos al equipo de soporte, que está enterado automáticamente de posibles errores que podrían afectar a los clientes, por ejemplo a la hora de sincronizar las cuentas de los clientes, si hay alguno sobre el que ha surgido un contratiempo, utilizamos los logs para enviar una notificación al canal de Slack de forma inmediata, para que estén al tanto y puedan actuar en consecuencia.
Configuración
Nosotros trabajamos con Symfony 3.3, y para los logs utilizamos la librería Monolog, así que vamos a ver cómo configuramos todo para conseguir que nuestra aplicación se comporte de esta forma.
Primero vamos a ver la configuración principal de monolog, y luego veremos más en detalle cómo gestionamos las integraciones con terceras partes.
Así nos quedaría el fichero de configuración YML para los logs:
Analicemos un poco qué significa cada cosa:
- channels: Nos va a servir para categorizar los errores, definiendo un canal para el logger a la hora de inyectarlo a un servicio. Por ejemplo, pasando como argumento “@monolog.logger.dev”, le estamos indicando que utilice el canal “dev”, y solo actuarán los handlers que estén asociados a ese canal en concreto.
Este servicio “@monolog.logger.dev” no hace falta que lo declaremos, ya que MonologBundle se encarga, a través de un CompilerPass, de generarlos dinámicamente, no teniendo así que registrar uno para cada canal que añadamos. En concreto, aquí podemos ver donde se produce esa magia.
- handlers: Los handlers son los encargados de actuar ante los logs lanzados. Se podrán configurar para que solo actúen bajo determinadas reglas. Es en este apartado donde más tarde añadiremos las demás integraciones.
- main: Con el tipo fingers_crossed, lo que conseguimos es, en caso de que el action_level supere el establecido, se ejecutará el handler definido, además se pasará todo el log de la request, no solo el error, permitiendo tener un mejor contexto.
- group: Con el tipo group, simplemente definimos varios handlers que se activarán a la vez, en nuestro caso, será solo ‘file’.
Como ya hemos comentado, para conseguir esta difusión a diferentes departamentos de forma eficiente, utilizamos varios canales, así que ahora vamos a ver cómo los configuramos.
Slack
Para utilizar Slack, lo único que hay que hacer es añadir el handler en la configuración de monolog, ya que monolog por defecto nos proporciona un handler. Nos quedaría algo tal que así:
En Slack nos llegaría algo como este ejemplo:
Rollbar
Con Rollbar, la configuración es simple ya que monolog también nos brinda un handler, así que queda bastante similar a la de Slack:
Con la opción del canal [!dev], lo que hacemos es enviarlo en todos los casos excepto en el que sea dev
CloudWatch
Por último, para guardar nuestros logs en CloudWatch, la estrategia es un poco diferente, ya que monolog no nos brinda de un handler de CloudWatch por defecto, así que tendremos que crearlo por nuestra cuenta. Vamos a verlo por pasos:
- Para empezar, nosotros utilizamos este repositorio como base: https://github.com/maxbanton/cwh
Podemos utilizar composer para descargarlo en nuestros vendors.
composer require maxbanton/cwh:^1.0- Luego vamos a registrar como servicio tanto el cliente como el handler del repositorio, que usaremos en la configuración de monolog:
Y por último, lo añadiremos en la configuración de monolog, como hicimos con los anteriores.
Y listo, con estos tres ejemplos tenemos cómo configurar tres canales que pueden ser muy útiles a la hora de gestionar los logs.
Aquí hay más información sobre las configuraciones de los handlers que nos proporciona monolog.
Conclusiones:
Recomendaría a todo el mundo darle alguna vuelta de tuerca al planteamiento del manejo de logs, para maximizar el beneficio que se puede sacar de ello, no solo para los desarrolladores, sino para aumentar la comunicación automática con otros departamentos de la empresa.
Si tenéis cualquier duda o sugerencia, o simplemente queréis comentarnos cómo lo tenéis vosotros organizado, no dudéis en dejar un comentario por aquí.
Un saludo y ¡hasta la próxima!
