Te va a interesar!

6/recent/ticker-posts

Observabilidad: Qué es esta hechicería?


Quizás todavía no hayan escuchado o leído este término. O quizás si... lo cierto es que viene muy en boca de todos en el ámbito del desarrollo de software y está, como no, relacionado de alguna manera con DevOps. Pero... qué es exactamente la Observabilidad y por qué están todos tan emocionados con esto? Es otro término de moda que va a irse como vino? En esta nota, vamos a hablar de todas esas cosas.

Ni un programa, ni una metodología...

La observabilidad muchas veces se confunde con el monitoreo de un sistema, lo cual es incorrecto, aunque anda cerca de qué es realmente...

El monitoreo, ya semánticamente lo vemos, es una acción. La acción de monitorear es la que se confunde a menudo con la observabilidad.

La observabilidad no es, ni más ni menos, que una propiedad de un sistema. Así es! Se terminó el misterio! Es la propiedad mediante la cual puede ser más fácil o más difícil inferir el estado del sistema en función de su output.

Ufff...me quedó medio complicada la frase. Déjenme refactorear lo que puse:

La observabilidad es qué tan fácil o difícil es entender el estado del sistema con solo mirar sus reportes.

Pero pará! Mencioné reportes! Qué? No era que no eran reportes? Bueno, no... pero sí es cierto que los reportes son los que van a darnos el output que va o no a servirnos para darnos un panorama claro del sistema. Y qué tan útiles sean esos reportes va a estar ligado a la observabilidad del sistema.

Si yo tengo una serie de servicios escondidos atrás de mil proxies y a los cuales cada vez que pasa algo hay que meterse por SSH a debuggear logs como loco para ver qué está pasando, la observabilidad de ese sistema no va a ser buena.

https://images.unsplash.com/photo-1434626881859-194d67b2b86f?ixlib=rb-1.2.1&q=85&fm=jpg&crop=entropy&cs=srgb

La Tri-fuerza de la observabilidad.

Perdón por el referención a La Leyenda de Zelda, pero no pude evitarlo. Veníamos hablando de logs, no? Bueno, da la casualidad que son uno de los 3 pilares de la observabilidad actual. Junto a las métricas y los traces.

Explicado a nivel muy general, los logs son los que nos informan eventos en un sistema, las métricas son las que nos miden y devuelven una representación numérica en función de intervalos de tiempo dados y, los traces, son los que nos dan la representación de eventos causalmente relacionados entre ellos en un sistema. El caminito de logs relacionados digamos.

Esas tres cosas por separado: Logs, métricas y traces , van a representar solamente la capacidad de un desarrollador o tester de debuggear un sistema y ver qué está pasando.

Pero cuando las juntás y armás una automatización proactiva en lugar de reactiva, que vigile el sistema y nos avise en caso que alguno de los parámetros definidos llegue a su límite... ahí es donde entra el potencial de la observabilidad.

Esto es parte de la cultura DevOps y una pieza fundamental de la automatización de la entrega de software.

Nos permite tener, sobre todo en ambientes de Producción, visibilidad de qué está pasando y ver las cosas antes de que sea demasiado tarde.

Como Ingenieros de Prueba, la Observabilidad va a jugar un papel muy importante tanto en tener un CV atractivo como en sumar un valor enorme desde nuestro rol.

Mi experiencia con la Observabilidad.

Ya he hablado sobre esto un poco en el blog, pero mi herramienta principal en este caso es Grafana.

Grafana es una herramienta que nos permite configurar data sources, las cuales pueden ser bases de datos u otros artefactos donde guardemos logs, métricas, etc. En mi caso, el setup completo requirió de Openshift para crear la instancia de Grafana, Jenkins para ejecutar los jobs que ejecutaban los scripts de JMeter y listo.

La configuración de Grafana en si es donde la magia ocurre. Acá vamos a poder configurar alertas, mostrar distintos segmentos de métricas y realizar modelos y muchísimo más.

Esto permitía que un simple script de performance, por ejemplo, estuviese corriendo con una frecuencia alta y siendo monitoreado activamente en pantallas en todos los pisos del cliente. Los problemas se podían ver enseguida gracias a la configuración de alertas que enviaban emails cuando el tiempo de respuesta no era el esperado en un rango de tiempo y permitía atender los problemas antes que nadie más.

La observabilidad de este sistema estaba dada por qué tan sencillo hizo todo esto posible. No es Grafana ni JMeter lo que hace a la observabilidad, son solo piezas en el esquema de esta propiedad.

Los invito, a ustedes, a proponer hacer algo similar en sus trabajos como Ingenieros de Testing. Monitorear los sistemas de forma activa con Grafana y JMeter. Pueden usar una base de datos como influx dB y configurarla muy sencillamente como data source en Grafana y en JMeter mediante un listener que ya nos da la herramienta.

Ahora si, me retiro dejando estas ideas revoloteando por sus cabecitas! Nos vemos en el canal, los cursos o twitter!

Nunca dejen de aprender...

Publicar un comentario

0 Comentarios