Ahora no monitoreamos: observamos
La forma en que se construye software ha cambiado radicalmente en los últimos 5 años. Es muy clara la evolución de ciertas prácticas, a la par que se complementan unas con otras. Los equipos de desarrollo se volvieron multidisciplinarios para abordar una solución de punta a punta. Los sistemas se empezaron a distribuir más, rompiendo con las clásicas arquitecturas monolíticas y virando hacia arquitecturas de microservicios o serverless. La infraestructura dejó de ser on-premise para ir a servicios Cloud, con aprovisionamiento bajo demanda de manera automática. Apareció la cultura DevOps y una manera diferentes de encarar los desafíos al llevar una aplicación a producción.
Toda esta nueva complejidad también trajo consigo cambios en cómo controlamos la salud de nuestros sistemas. No es lo mismo entender qué pasa con una sola gran aplicación, que con una aplicación que consta de 30 microservicios en donde cada uno puede escalar de manera independiente. Esto requiere trabajar en diferentes aspectos para controlar desde distintas aristas. Ya no monitoreamos más: ahora observamos. Apareció el concepto de Observabilidad.
Pero, ¿qué es la Observabilidad?
Podemos definirla como la forma de medir qué tan bueno es el estado de un sistema a partir de sus salidas externas. Un sistema es observable si el estado actual puede ser determinado en un período de tiempo finito sólo a través de sus salidas.
La infraestructura de IT consta de componentes de hardware y software que generan automáticamente registros de cada actividad en el sistema, y que incluyen las actividades de las aplicaciones, de las bases de datos, de los controles de seguridad, entre otros. La idea es utilizarlos y procesarlos para conocer el estado del sistema.
El concepto de observabilidad se puede dividir en tres grandes temas: event logs, metrics y traces. Cada uno apunta a una necesidad diferente.
Elementos a observar
Un event log es un registro de un evento que sucedió en un sistema. Los registros de eventos suelen estar “timestampeados” y contienen un mensaje que refiere a lo ocurrido con un grado de severidad. Usualmente estos se almacenan en archivos, o directamente se entregan a través de la salida por defecto de los procesos. En conjunto, proporcionan un registro completo y preciso de eventos discretos, incluidos metadatos adicionales sobre el estado del sistema cuando ocurrió el evento. Estos solían escribirse en texto sin formato, pero ahora se tiende a ir por logs estructurados para tener la capacidad de procesarlos posteriormente con facilidad.
Por otro lado, una metric es una representación numérica de datos que se midió durante un período de tiempo. A diferencia de un event log, que registra un evento específico, una métrica es un valor medido que se deriva del rendimiento del sistema. Las métricas con frecuencia contienen información sobre indicadores como cantidad de request, memoria libre, disponibilidad de los servicios, etc. Además, nos permiten definir gráficos, umbrales, y generar alertas cuando una situación se vuelve anómala.
Un trace es el registro documentado de una serie de eventos causalmente relacionados que suceden en una red. Los eventos no tienen que tener lugar dentro de una sola aplicación, pero sí deben ser parte del mismo flujo de solicitud. Una traza puede formatearse o presentarse como una lista de registros de eventos tomados de diferentes sistemas que participaron en el cumplimiento de la solicitud. En el mundo de los microservicios, se vuelve primordial entender cómo es el flujo de llamadas entre ellos ante el request que realizó el cliente.
¿Por qué usar observabilidad?
Porque necesitamos:
- Detectar y resolver problemas de manera temprana y proactiva para evitar riesgos a nivel de producción.
- Implementar cambios de forma segura a medida que se supervisa todo el entorno.
- Proveer información para realizar ajustes a las aplicaciones y así ofrecer un rendimiento y una experiencia de usuario mejorados.
- Proveer información para optimizar la asignación de recursos
¿Cómo se relacionan métricas, logs y trazabilidad?
Cada pilar tiene un objetivo preciso y funciona como un complemento para entender qué está pasando con nuestro sistema.
Las métricas nos dan un “pantallazo” sobre el estado general del sistema. Es lo primero que hay que ver: suelen organizarse en forma de dashboard y nos permiten ver rápidamente las variables más importantes, como disponibilidad de los servicios, carga de los servidores, cantidad de usuarios activos, etc.
Pero estas mismas métricas pueden presentar comportamientos anómalos, y es acá donde entran los otros dos pilares: la trazabilidad y los logs. Son el “doble click” que hacemos para entender el problema de fondo. Los logs nos dan el detalle fino de un sistema y las métricas nos permiten detectar problemas en el flujo de llamadas de un request específico.
En este contexto, es fundamental que existan atributos que nos permitan vincular los tres elementos: ir fácilmente de una métrica a los logs correspondientes y al request trazado. Estos atributos tienen que ser nombrados de la misma forma para poder realizar esta tarea.
¿Por dónde empezamos?
Elegir un stack
Es importante entender cómo es nuestra infraestructura para elegir la herramienta correcta. A fin de cuentas, la mayoría de las veces es una cuestión de costos.
Prometheus, Grafana: Es “el” stack de la comunidad Open Source y Kubernetes. Es extremadamente sólido y ágil para el tratamiento de métricas, y es el producto más utilizado para dicho fin.
ELK o EFK: es el más versátil al momento de integrar los logs y explotarlos. Más allá de la versión gratis, el verdadero potencial se obtiene usando las versiones pagas.
Datadog: es un SaaS que resuelve, en una sola herramienta, los tres pilares de la observabilidad. Es muy fácil de integrar y evoluciona muy rápidamente en su funcionalidad. A veces no encontramos el potencial que tenemos en Grafana o en Kibana.
Jaeger o Zipkin: son herramientas enfocadas en la trazabilidad. Las dos son open source, gratis y muy utilizadas en contextos de microservicios.
Homogeneizar los logs
No tiene sentido hacer todo el esfuerzo de instalar alguna herramienta de manejo de logs, recolectarlos y agruparlos para luego darnos cuenta de que los logs que estamos generando no nos aportan valor. Escribir logs de calidad es crucial para poder entender luego qué está pasando con la aplicación. Dado que estos logs se van a indexar, es importante enviar mucha información de contexto en los mismos, más allá de la información principal que estamos enviando: fecha, hora, información sobre el request, sobre el usuario, sobre el servidor que está ejecutando la operación, etc.
Además, para simplificar el procesamiento, es conveniente generar logs de manera estructurada; por ejemplo, usando el formato Json. Esto acelera el parseo y la indexación.
Definir alguna métrica de disponibilidad
Si queremos entender rápidamente cuando nuestro sistema entra en una situación no deseada, sugiero definir métricas que nos hablen sobre la disponibilidad de nuestra aplicación. Y acá entra en juego lo funcional, a veces con contabilizar la cantidad de request entrantes es una métrica que alcanza. Pero lo ideal sería individualizar la disponibilidad de cada uno de los servicios que brindamos y compararlos con valores históricos.
Generar alertas
Obviamente, no podemos estar todo el día mirando un dashboard para saber si andan mal o bien las cosas. Por eso definimos alertas sobre los valores anómalos de una métrica durante un periodo de tiempo. Es muy común, actualmente, enviar estas notificaciones por un medio como Slack, y que todo el equipo esté mirando este tipo de cosas; por supuesto, en pos de la cultura DevOps.
Creo que es importante destacar el cambio cultural en cuanto a la manera en que se desarrolla software. El desarrollador debe ser consciente del ciclo de vida de lo que produce de punta a punta, y eso también incluye entender y saber cómo está corriendo su software.
Algunos dicen que dejamos de hablar de “monitorear” porque era una tarea de Ops totalmente aburrida; y que le pusieron el nombre de “Observabilidad” porque suena más “geek”.
Más allá de la humorada, yo creo que la observabilidad o el monitoreo (como lo quieran llamar) y su relación con el desarrollador es vital. Genera un flujo sobre qué cosas de las que hace funcionan bien y cuáles no (que se retroalimenta), de manera que el dev es el primero que puede dar cuenta sobre qué es lo que está pasando ante un problema. Lo empodera y lo hace participe todo el tiempo de lo que produce.
Las herramientas han evolucionado de tal manera que permiten a cada actor tener un desglose de la porción de software que le pertenece, así como la descentralización de la observabilidad para poder analizar al mismo tiempo diferentes aspectos. A fin de cuentas, tener un buen esquema de observabilidad y reaccionar lo antes posible ante situaciones no deseadas apunta directamente a la calidad de servicio que damos.
