Nota publicada originalmente por el CTO de #54cuatro en Linkedin.

La #observabilidad es una característica dentro de un sistema de control que permite dar con una solución prediseñada a un problema que surja. Dentro del mundo TI, la observabilidad de un sistema permite evaluar resultados para llegar a conclusiones sobre los estados de un recurso.

Si bien han surgido distintos puntos de vista sobre la definición, a partir de la masificación de #DevOps (y #SRE), el crecimiento de las instalaciones #Cloud, el uso intensivo que hacen las plataformas de #bigdata y la adopción de #Contenedores, la observabilidad se volvió una palabra en constante crecimiento.

A diferencia de las actividades de monitoreo tradicionales, donde el objetivo es “observar” el estado, la salud y #performance de #Redes, #Servidores, #Servicios, #Redes, Aplicaciones, etc para luego tomar acciones, la observabilidad podriamos definirla como un componente mas del diseño de una aplicación que permite tener en cuenta todos los elementos de la misma para saber como monitorearlas y operarlas.

Al igual que el análisis de la seguridad en nuevos desarrollos (#DevSecOps), es de esperar que también se realicen los diseños de monitoreo de los componentes en etapas tempranas de la construcción del software y no al momento de la implementación.

Sin ir a mas, en el sitio de SRE de Google, indican que la operación exitosa de un servicio implica una amplia gama de actividades: desarrollar sistemas de monitoreo, capacidad de planificación, responder a incidentes, asegurar que se aborden las causas fundamentales de las interrupciones, y ponen esta pirámide que permite ver los elementos que intervienen para hacer que un servicio sea confiable, desde el más básico hasta el más avanzado.

Diseñar y desarrollar aplicaciones “observables” permite ser proactivo y prever los posibles puntos de fallas, con el objetivo de lograr rápidas recuperaciones ante fallos y administrar de forma eficiente el capacity planning y junto a ello la performance.

Podemos pensar un sistema observable a partir del control de todas las partes, conociendo como se desarrolló, como estará montado y como se comportará, podremos definir el monitoreo horizontal (servidores, redes, transacciones, logs) y el monitoreo vertical (experiencia de usuario, tracing, debug) mas acorde. El Monitoreo y la Observabilidad son cosas diferentes y también complementarios.

De hecho, el concepto de observabilidad no tiene que estar ligado al incidente. Una aplicación observable puede reportar datos que permitan mejorar la arquitectura, la performance, el escalamiento automático sin la necesidad que haya un perjuicio o incidencia dentro de la plataforma.

Para ir finalizando, podemos decir que debemos de adoptar una estrategia que consista en diseñar aplicaciones observables desde su nacimiento, diseñando de que manera vamos a controlar y monitorear la nueva aplicación, entendiendo que componentes vamos a usar y cuales son las mejores métodos y/o herramientas para respaldas la salud de esas aplicaciones; de allí el nacimiento de grandes conjuntos de tools que funcionan muy bien juntas. Se me vienen a la cabeza soluciones basadas en #ELK, en #Influx o la dupla #Prometheus y #Grafana, básicamente Prometheus recopila datos y métricas de diferentes servicios y los almacena de acuerdo con un identificador único, el nombre de la métrica, y una marca de tiempo (en una base time series) y Grafana se encarga de realizar hermosos dashboards donde mirar dicha información. Toda esta informacion puede ser “cruzada” con aquellos datos adicionales que tengamos configurada en nueva navaja suiza del monitoreo como las experiencias de los usuarios y con toda la correlación de los eventos determinar que todos los servicios de monitoreo estén vivos y saludables.

Video de Monitoreo de Infra

Video de Monitoreo #Netflow

Como siempre… Gracias por leerme! Hasta la próxima!

[popup_anything id=”2076″]