Cómo definir un buen sistema de monitorización y observabilidad
¿Monitorización?, ¿observabilidad?, ¿metrics?, ¿logging?, ¿tracing?... ¡pero qué locura es esta!. Lo que antiguamente conocíamos como el noble arte de "saber qué está pasando", se está convirtiendo en toda una suerte de tecnologías, estándares y conceptos que hacen muy difícil saber si mi sistema de monitorización y observabilidad es lo suficientemente fiable y robusto o no. Y es que, no nos engañemos, en los tiempos que corren hay aplicaciones y soluciones de software cuya arquitectura es mucho más sencilla que la de los propios sistemas que las monitorizan.
Hace 15 años todo era mucho más sencillo. Con saber si mi aplicación estaba dando servicio o se había caído era suficiente, y en este ámbito Nagios era el rey y campaba a sus anchas. No es que no quisiéramos saber más que eso, es que las infraestructuras que soportaban nuestras aplicaciones era más caras y, por tanto, más reducidas, así que se aprovechaba cada recurso al límite para que el servicio que ofrecían nuestras aplicaciones fuera el mejor posible. Si había algún problema, se encendía momentaneamente algún sistema de APM, se encontraba dónde estaba el cuello de botella o cuál era el caballo más lento, se arreglaba, y se apagaba de nuevo el sistema de APM, porque además de consumir muchos recursos añadía latencia a las respuesta de las aplcaciones.
Claro, hoy en día todo esto ha cambiado, la infraestructura ya no es tan escasa ni tan cara. Además, el rendimiento de todo tipo de agentes, colectores y demás herramientas encargadas de recoger datos ha mejorado mucho, con lo que la latencia ya no es tan problemática (en algunos casos sí, pero esto daría para otro artículo).
Por tanto, las reglas de juego han cambiado, y, en estas circustancias, queremos saber más. No queremos saber sólo un poco. No. Queremos saberlo todo. Y ahí es donde vienen las dudas que comentaba al principio de este artículo: ¿monitorizo y observo bien?, ¿me estoy perdiendo algún detalle?, ¿cuál es la mejor solución?
Voy a tratar de simplificar la respuesta: ¿sabes lo que está pasando en tu aplicación?. Si la respuesta es sí, yo diría que lo estás haciendo bien. Si tienes dudas o tienes que preguntar a más de media docena de personas para poder responder, es posible que haya margen de mejora.
Vaya por delante que yo soy un enamorado de la monitorización, observabilidad, apm y cualquier otro nombre que queramos darle. Y cuanto más sepamos, mejor.
No voy a caer en la tentación de decir eso de que el saber no ocupa lugar, porque sí que ocupa, y mucho. Concretamente, teras y teras en algún CPD tuyo o de otro que almacene tu saber. Y es que, desde mi punto de vista, justo aquí está la clave de todo este asunto. En los últimos años he trabajado ayudando a construir este tipo de soluciones, y, en muchas ocasiones, nos centramos más en conseguir todo tipo de información que en saber si toda esta información que estoy almacenando sirve para algo.
Y es que, igual de malo es no tener la información y necesitarla, que tenerla almacenada y que no me sirva para nada. Porque no se trata únicamente de capturar cuanta más información mejor, se trata de capturarla de manera que sea fácil de consumir y que, además, pueda dar respuesta a mis necesidades. Cuando queremos aprovechar los datos que almacenamos, la calidad de esos datos es primordial, porque si tengo un dato que no entiendo o no tengo manera de contextualizar, probablemente, no lo consumiré y acabará siendo basura en forma de ceros y unos en mi CPD o en el de cualquier otro. Nunca me cansaré de repetir que la calidad del dato marca la diferencia en este tipo de soluciones y en cualquier proyecto relacionado con la gestión de datos.
Por otro lado, nuestras aplicaciones son cada vez más complejas y la irrupción de los microservicios y las arquitecturas orientas a eventos han hecho que una petición de lo más inocente que hago desde el sofá de mi casa para conocer el estado de mi cuenta bancaria, sea resuelta por 14 servicios diferentes en múltiples localizaciones. Tener constancia de por dónde ha pasado esa petición, dónde ha tenido más o menos latencia, el estado de la infraesrtuctura en ese momento o los logs que se han generado se ha convertido en todo un arte. Ya no es suficiente con mirar un determinado servidor y un fichero de log, sino que aquí entra en juego la trazabilidad distribuida, necesito conocer qué ha pasado con esa petición, identificarla en cada uno de los servicios, seguirle el rastro en cada microservicio y, a poder ser, correlar todo esto con el estado de cada uno de los servidores y los logs que se han ido escribiendo. Casi nada.
No voy a pararme a describir qué son métricas, qué es tracing o qué es logging. No porque quiera haceros un feo, sino porque ya está definido en múltiples sitios en la red y, una vez que ya hemos acordado que el saber sí que ocupa lugar, no vale la pena repetirlo. Además, aunque parezca que todos estos conceptos se puedan diferenciar de una manera sencilla, a poco que empecemos a tirar del hilo veremos que los conceptos se mezclan y están mucho más entrelazados de lo que parece, así que, ¿para qué meterme en este jaleo? Lo cierto es que prefiero, por un lado, indicar qué es lo que yo esperaría de una buena plataforma de observabilidad y, de paso, sacar mi bola de cristal para tratar de predecir el futuro (cosa que no tendrá mucho mérito, porque es un futuro cercano y previsible).
¿Qué me gustaría encontrar en mi solución de observabilidad?
La respuesta para mi es muy sencilla: que me ponga las cosas fáciles. No me tachéis de vago, por favor. Tengo muchas aficiones, muchas más de las que me permite mi escaso tiempo libre y, una de ellas, es montar puzzles. Pero me gustaría que montar puzzles siguiera siendo algo para mi tiempo libre. Sin embargo, en muchas ocasiones nos encontramos con logs, trazas y métricas que no están relacionadas de ninguna manera, como mucho a través de un timestamp que de poco sirve cuando hablamos de miles de eventos por segundo. En estos casos, tratar de entender qué ha pasado y porqué, se convierte en una tarea similar a la de montar un puzzle de 10.000 piezas.
Hoy en día, hay muchos actores en este juego, y los más veteranos tienen ganado mucho terreno en algún aspecto de la monitorización. Por ejemplo, Prometheus es el rival a batir en cuanto a métricas, Elastic es referencia en cuanto a ingesta y procesamiento de logs, Dynatrace juega un papel muy importante en APM (aunque este pastel está muy repartido también con Cisco AppDynamics, New Relic, etc.).
No obstante, todas por separado no consiguen el fin deseado: "poner las cosas fáciles". Y todos los fabricantes son muy conscientes de ello, porque la mejor manera de poner las cosas fáciles es, como comentábamos antes, relacionar todos los datos y ofrecer los resultados en contexto. Está muy bien tener métricas, trazas y logs con la mejor herramienta para cada cosa, pero mejor está tenerlo todo junto para que, a partir del análisis del funcionamiento de una aplicación, pueda llegar a ver también los logs generados y el estado de la infraestructura en ese momento porque, todo ese contexto, es el que realmente me va a ayudar a saber qué está pasando.
Y como comentaba hace escasos momentos, los distintos fabricantes lo saben. Lo mejor no es tener una solución muy buena en una parte, sino tener una solución buena para todo. Y así están evolucionando todos los productos: Dynatrace ya permite capturar métricas y logs, aunque su punto fuerte sea la parte de APM. Elastic, no sólo nos sirve para ingestar logs, sino que también se está posicionando fuertemente en la captura de métricas, APM y SIEM. Lo mismo con New Relic o Data Dog. La tendencia actual parece clara. Quien tenga todos los datos podrá facilitar la vida a los usuarios y ofrecer información de mayor calidad.
Podemos constatar esta tendencia incluso en quien trata de convertirse en un estandar en todo lo relacionado con la observabilidad: Open Telemetry. Sus especificaciones incluyen tracing, metrics y logging y, aunque gran parte de esto está todavía en desarrollo, su colector estará listo para capturar todo este tipo de datos y servirlos a quien sepa tratarlos, relacionarlos y, en resumen, aprovecharlos.
Así que, en cuanto a ¿qué me gustaría encontrar en mi solución de observabilidad? yo lo tengo claro. Que haga el trabajo por mi y que me ofrezca todos los datos para poner en contexto lo que pasa con mi aplicación en un momento dado sin tener que ir a buscar esta información fuera.
¿Cuál es la solución ideal?
Pues justamente, la solución ideal es la que haga el trabajo por mi. Y esto pasa porque la solución no sólo sea capaz de ingestar los datos, sino también de analizarlos e interpretarlos. Y aquí, quien juega un papel muy importante, es el tan desgastado Machine Learning.
¿Por qué considero que esto es importante? Porque, en la mayoría de las ocasiones, lo que me interesa saber con un sistema de observabilidad no es cómo está mi aplicación en un momento dado, sino saber cuándo se está comportando de una manera inesperada o, mejor aún, anticiparme a un posible problema antes de que ocurra. Todos somos conscientes de que el alarmado es un pilar fundamental de la observabilidad. Pero un alarmado en base a valores prefijados no siempre será del todo fiable, y esta fiablidad es de gran importancia, especialmente cuando estamos pensando en levantar a alguien de la cama a las 3 de la mañana por un falso positivo.
Tener una alarma que me avise cuando la CPU está a mas del 80% durante 5 minutos es un buen punto de partida, pero quizás ese pico de CPU al 80% no es algo preocupante el día 1 de cada mes en la aplicación que gestiona las nóminas de la compañía, con todos los trabajadores consultándola a primera hora de la mañana. Sin embargo, un consumo de CPU del 60% durante 10 minutos en esa misma aplicación un domingo cualquiera a las 2 de la madrugada sí es un problema o la antesala de un problema que deba ser revisado. Sin embargo, un alarmado tradicional saltará el día 1 del mes y no lo hará ese domingo cualquiera.
De ahí la importancia de conocer bien nuestras aplicaciones y saber qué es un comportamiento esperado y qué no a la hora de establecer un buen alarmado. Porque en la mayoría de las ocasiones lo que tiene que hacer que nos preocupemos no es que nuestra aplicación alcance unos determinados valores, sino el saber que se está produciendo una anomalía. Y esa anomalía puede tener múltiples representaciones: demasiadas peticiones, demasiado pocas, carga inesperada para un determinado día, etc. Definir todo esto manualmente es un locura, pero si la herramienta de observabilidad dispone de mecanismos que detecten anomalías por nosotros, hemos ganado mucho. Y, si el alarmado está basado en esas anomalías en lugar de en valores fijos para cualquier momento dado, tendremos una solución mucho más completa.
Y, nuevamente, los fabricantes de las diferentes soluciones no son ajenas a esto y, quien más quien menos, ya se ha movido en este aspecto o está planeando hacerlo. Elastic ya ofrece su módulo de Machine Learning que permite, no sólo la detección de anomalías, sino también predecir valores futuros a partir de sus forecast. Dynatrace también ofrece a Davis su motor de inteligencia artificial. Y es que, aunque el Machine Learning está cada vez más presente en todo tipo de casos de uso, en temas de observabilidad todavía tiene mucho que ofrecer.
Conclusión
No le des más vueltas, si sabes lo que está pasando, estás haciendo las cosas bien. El resto, ya se verá.