Observability: qué es y qué nos ofrece

Daniel Pous Montardit    16 agosto, 2021
Observability

Continuando la serie de posts sobre Cloud Native, y conociendo ya los cinco atributos que toda aplicación cloud debe cumplir para considerarse native, vamos a profundizar en uno de ellos: la observabilidad. En qué consiste, cómo se diferencia de la monitorización ‘clásica’ y cuáles son sus bondades, van a ser los puntos que trataremos en este post. Empezamos:

¿Qué es la observabilidad?

El término «observabilidad» proviene de la teoría de control de Rudolf Kalman y se refiere a la capacidad de inferir el estado interno de un sistema en función de sus salidas externas. Este concepto aplicado a sistemas software se refiere a la capacidad de comprender el estado interno de una aplicación en función de su telemetría. No todos los sistemas permiten o dan suficiente información para ser ‘observados’, así pues clasificaremos como observables aquellos que lo permitan. Ser observable es uno de los atributos fundamentales de los sistemas cloud-native.

La información de telemetría se puede clasificar en tres categorías principales:

  • Logs: probablemente el mecanismo más común y extendido de emitir información de lo acontecido internamente que disponen los procesos o servicios de un sistema software. Históricamente son la fuente más detallada de lo ocurrido y siguen un orden temporal. Su aportación es clave para depurar y comprender lo sucedido dentro de un sistema, aunque algunos  apuntan que podrían llegar a ser relevados por las trazas en este rol principal. Son fáciles de recolectar, pero muy voluminosos y consecuentemente caros de retener. Existen tanto logs estructurados como no  estructurados (texto libre), y entre los formatos comunes tenemos json y logfmt. También se encuentran propuestas de estandarización semántica como por ejemplo la de Open Telemetry o Elastic Common Schema.

  • Métricas: son información cuantitativa (datos numéricos) relativa a procesos o máquinas a lo largo del tiempo. Como por ejemplo podría ser el porcentaje de uso de CPU, Disco o Memoria de una máquina cada 30 segundos o el contador del número total de errores devueltos por una API, etiquetado con el HTTP-Status devuelto y el nombre del contenedor de Kubernetes, por ejemplo, que ha procesado la petición. Así pues estas series temporales pueden ser  determinadas por un conjunto de etiquetas con valores, y que además, sirven de punto de entrada de exploración de la información de telemetría. Las métricas se caracterizan por ser sencillas de recolectar,  económicas de almacenar, dimensionales para permitir un análisis rápido y una excelente manera de medir la  salud general del sistema. Más adelante en otro post veremos también que los valores de una métrica  pueden tener datos adjuntos llamados exemplars, también en forma de clave/valor, que sirven entre otras  razones para correlacionar fácilmente dicho valor con  otras fuentes de información. Por ejemplo en la anterior  métrica del contador de errores de una API un exemplar adjunto podría permitirnos saltar directamente de la métrica a las trazas de la petición que originó el error. Esto facilita enormemente la  operación del sistema.

  • Trazas: hablamos de datos detallados sobre el camino ejecutado en el interior de un sistema en respuesta a un estímulo exterior (como podría  ser una petición HTTP, un mensaje en una cola, o una ejecución programada). Este tipo de información es muy valiosa dado que nos muestra la latencia de un extremo a otro del recorrido ejecutado y para cada una de las llamadas individuales en él realizadas, aunque se trate de una  arquitectura distribuida y por lo tanto, la ejecución pueda afectar a múltiples componentes o procesos. La clave de este poder reside en la propagación del contexto entre los componentes del sistema que trabajan conjuntamente, por ejemplo, en un sistema distribuido de micro-servicios los  componentes pueden usar cabeceras HTTP para propagar la información de estado requerida y así conseguir los datos entrelazados de un  extremo al otro. En conclusión, las trazas nos permiten comprender las rutas de ejecución, encontrar cuellos de botella y optimizarlos eficientemente e identificar errores facilitando su comprensión y su solución.

Históricamente, estos tres verticales de información se han denominado los «tres pilares» de la observabilidad, y hacerlos trabajar conjuntamente es fundamental para maximizar los beneficios obtenidos. Por ejemplo, las métricas pueden ser alarmadas para notificar un mal funcionamiento, y sus exemplars asociados nos van a permitir identificar el subconjunto de trazas asociadas a la aparición del problema subyacente. Finalmente, seleccionaremos los logs relacionados con dichas trazas, accediendo así a todo el contexto disponible y necesario para identificar y corregir eficientemente la causa raíz del  problema. Una vez resuelto el incidente podemos enriquecer nuestra observabilidad mediante nuevas métricas, consolas o alarmas para anticipar de manera más proactiva problemas similares en un futuro.

¿Por qué la monitorización no es suficiente? ¿Qué nos ofrece la observabilidad?

La monitorización nos permite detectar si algo no está funcionando adecuadamente, pero no nos proporciona las razones. Además, sólo es posible monitorizar situaciones de  antemano previstas (known knowns). La observabilidad, en cambio, parte de la integración y relación de múltiples fuentes de datos de telemetría que, en conjunto, nos  ayudan a comprender mejor cómo funciona el sistema software bajo observación y no sólo  a identificar problemáticas. Sin embargo, el aspecto más crítico es lo que se hace con los datos una vez recopilados, por ejemplo, ¿por qué confiar en umbrales predefinidos cuando podemos detectar automáticamente ‘puntos de cambio’ inusuales? Este tipo de ‘inteligencia’ es lo que habilita al descubrimiento de incógnitas desconocidas (unknown unknowns). 

La elaboración de mapas de topología en tiempo real (real time topology) es otra de las capacidades que nos ofrece la observabilidad, y nos permite establecer relaciones automáticas entre toda la información de telemetría ingestada llegando mucho más allá que una simple correlación por tiempo. Un ejemplo de gran impacto de lo que pueden aportar estas topologías sería  conseguir mecanismos de resolución automática de incidentes en tiempo real sin intervención  humana.

La observabilidad nos facilita también la integración de la performance (rendimiento) como una  actividad de primer nivel en el desarrollo software, al permitirnos disponer de información de profiling (detalle paso a paso de una ejecución) de forma continua (algo que sin los  mecanismos adecuados requiere de mucho esfuerzo en sistemas distribuidos) y ofrecernos la posibilidad de detectar cuellos de botella en tiempo real, etc. Además, el mero hecho de hacernos entender a fondo que sucede dentro de un sistema a lo  largo del tiempo nos permite, tanto maximizar el beneficio de la realización de pruebas de carga (y en general de cualquier tipo de test e2e) como abrir las puertas a la puesta en práctica de técnicas de ingeniería del caos, y a su vez aunque no menos importante, reduce el tiempo medio de resolución (MTTR  – mean-time to resolution) de incidencias al reducir el tiempo de dedicación al diagnóstico permitiendo centrar el foco en la resolución del problema.

Podemos concluir que cuando un sistema abraza una solución de observabilidad madura, los beneficios para el negocio se agudizan. No únicamente  dando pie a innovar de forma más eficiente sino que la reducción de tiempos para implementación se traslada como incremento en eficiencia a los equipos generando todo ello consecuentes reducciones de costes.

Por todos estos motivos os podéis imaginar que la observabilidad tampoco es una preocupación puramente operativa, sino una responsabilidad  transversal de todo el equipo además de considerarse una práctica base dentro de las recomendaciones de la ingeniería software más actual y avanzada.

Conclusión

La clave para comprender los problemas de los sistemas distribuidos, problemas que aparecen de forma recurrente pero con variabilidad acentuada, es poder depurarlas armados con evidencias en lugar de conjeturas o hipótesis. Debemos interiorizar que los ‘errores’ forman parte de la nueva normalidad que acompaña a sistemas complejos distribuidos. El grado de observabilidad de un sistema es el grado en que se puede depurar, así mismo podemos asimilar el aporte de la observabilidad en un sistema distribuido, a lo que nos ofrece un depurador (debugger) sobre un sólo proceso en ejecución.  Finalmente, resaltar que un sistema observable permite ser optimizado, tanto a nivel técnico como a nivel de negocio, con mucha más facilidad que el resto.

Referencias
  • https://newrelic.com/resources/ebooks/what-is-observability
  • https://www.splunk.com/en_us/blog/devops/observability-it-s-not-what-you-think.html
  • https://www.alibabacloud.com/blog/a-unified-solution-for-observability—make-sls-compatible-with-opentelemetry_597157 https://containerjournal.com/kubeconcnc/the-future-of-observability/
  • https://www.infracloud.io/blogs/tracing-grafana-tempo-jaeger/
  • https://blog.paessler.com/the-future-of-monitoring-the-rise-of-observability

Deja una respuesta

Tu dirección de correo electrónico no será publicada.