Historia, Conceptos & Mejores Prácticas para aprovisionar Observabilidad como Código

Autores:

Oscar Mendez & Yury Niño

Introducción

El término observabilidad suele asociarse en sistemas de software con el monitoreo o la supervisión de operaciones, y aunque esa definición es aceptable, conviene aclarar que observar sistemas tiene una fundamentación matemática y humana.

La relación matemática tiene su origen en la definición de Rudolf E. Kálmán en 1960 [1], quien usó el término para medir el grado de conocimiento sobre el estado de un sistema a partir de sus salidas.

La asociación con factores humanos fue establecida por Charity Majors, George Miranda y Liz Fong-Jones en el libro Observability Engineering [2], al afirmar que la observabilidad está relacionada con las personas que interactúan y comprenden los sistemas y no con tipos de datos, entradas o ecuaciones matemáticas.

Aceptar cualquiera de las definiciones, ubica al observador en un contexto en el que los principios y prácticas promovidos por Site Reliability Engineering o Ingeniería de Confiabilidad en Sitio [3][4] son de alto valor; ejemplos particulares de estas prácticas son la eliminación del trabajo repetitivo, el monitoreo de sistemas distribuidos, la automatización de procesos y una práctica que ha venido ganando importancia: la Observabilidad como Código [OaC].

Este artículo se enfoca en este último concepto, y para ello ofrece un guía con recomendaciones y buenas prácticas para automatizar la implementación de observabilidad a través de código. En las siguientes secciones se proveen definiciones clave en [OaC], una descripción del concepto en ambientes nativos a nube, un módulo en Terraform y una guía con recomendaciones para su implementación .

Definiciones Clave

En esta sección se presentan definiciones clave que fundamentan la disciplina de [OaC] y sobre las que conviene tener claridad antes de escribir código fuente.

Métrica: aunque el concepto tiene diferentes definiciones ajustadas al contexto en el que se use, el significado suele ser el mismo. En términos generales, es una medida que representa una variable y que caracteriza el estado de un sistema. En matemáticas, una métrica se define como una función que mide la distancia entre dos puntos en un espacio. En ingeniería, las métricas son usadas como indicadores cuantitativos del desempeño de un componente o recurso de un sistema y en Ingeniería de Software son medidas que describen las propiedades de un componente de software o hardware.

Observabilidad: es la capacidad de descubrir datos y generar información usando las señales de un sistema bajo observación. La observabilidad permite a los usuarios comprender el estado de un sistema y tomar decisiones a partir de sus salidas [10]. Esto ayuda en el entendimiento de arquitecturas, la identificación de latencias y el mejoramiento del desempeño. De acuerdo con [11] observabilidad no se limita al entendimiento de un problema, sino a la solución de tres preguntas: por qué está ocurriendo, cómo puede solucionarse y cómo puede evitarse.

Monitoreo: es una de las prácticas asociadas a [OaC] que busca entender el estado de un sistema a partir del seguimiento a eventos y métricas. Las métricas son luego usadas en la configuración de alertas sobre anomalías, errores, problemas y tiempos de inactividad. El monitoreo ha sido usado de manera errónea como un sinónimo de observabilidad por lo que en el libro Site Reliability Engineering [3] se explica en función de cuatro métricas: latencia, tráfico, errores y saturación. Estas métricas se conocen en la literaturacomo “Las 4 Métricas de Oro”. A continuación se extiende la definición de cada métrica.

Tráfico: esta métrica representa la demanda ejercida sobre un sistema. Algunos ejemplos incluyen el número de peticiones por segundo, la tasa de entrada y salida de red, el número de transacciones por segundo y el número de sesiones concurrentes.

Saturación: esta métrica representa la cantidad de recursos que consume un servicio en el sistema. Algunos ejemplos incluyen: la utilización de CPU, el consumo de memoria, el uso de disco o caché y el número de usuarios conectados.

Latencia: esta métrica está asociada al tiempo que tarda un sistema en responder a una solicitud. Algunos ejemplos incluyen: el tiempo de carga de la página, la duración de una consulta, la duración de una transacción y el tiempo de procesamiento de un conjunto de datos.

Errores: esta métrica describe la tasa de peticiones que fallan en un sistema. Los valores pueden ser explícitos como los códigos de error HTTP o derivados implícitamente del comportamiento de una aplicación en la que la respuesta es correcta pero su contenido no es consistente. Algunos ejemplos incluyen el número de solicitudes fallidas, el número de excepciones, el número de códigos de error HTTP y el número de conexiones perdidas.

Monitoreo de caja negra: permite revisar cómo se ve el sistema desde el exterior, lo que significa sondear el servicio de la misma manera que lo haría un usuario final. En Google Cloud Monitoring, este tipo de monitoreo se proporciona con verificaciones de tiempo de actividad, que validan si el servicio está activo o inactivo. Los métodos clásicos para llegar a ellos son la URL, la dirección IP o el nombre DNS.

Monitoreo de caja blanca: este tipo de monitoreo permite inspeccionar el interior del servicio. Aunque requiere instrumentación del servicio, se puede lograr mediante la inclusión de bibliotecas de programación o la escritura de datos de series de tiempo personalizados utilizando el API de Cloud Monitoring.

Monitoreo de caja gris: este tipo de monitoreo recopila información sobre el estado del entorno en el que se ejecutan los servicios. Incluye cosas como el uso de CPU de las instancias de VM subyacentes o métricas relacionadas con el almacenamiento y el uso de la red. Aunque la instrumentación no es requerida, los agentes deben estar instalados en las instancias subyacentes.

Telemetría: se refiere a la recopilación, almacenamiento y análisis remoto de las entradas y salidas de un sistema con el fin de centralizar en un única fuente de datos los datos asociados a Observabilidad. La telemetría hace uso de logs, métricas y trazas para facilitar la Observabilidad de un sistema. A continuación se extiende la definición de dos de estos conceptos que se conocen como los “pilares de la observabilidad”.

Logs: son registros en texto de los eventos o cambios en el comportamiento de un sistema. Estos registros suelen incluir una marca del tiempo en el que ocurrió el evento y una descripción útil que ofrece contexto. Los registros de log suelen estar disponibles en formato no estructurado, lo que representa un desafío para la consultas enriquecida desde herramientas de agregación.

Trazas: se usan para representar el recorrido de inicio a fin de una petición a través de un sistema distribuido. La representación muestra todas las operaciones realizadas sobre la petición mediante la correlación de logs y la agregación de datos. El tracing es de valor, durante la optimización y auditoría de sistemas, ya que permite la identificación de cuellos de botella y la identificación de oportunidades de mejora.

Observabilidad como Código

La expresión Observabilidad como Código [OaC], el tema central de este artículo, se hizo popular en el 2018 cuando apareció en la categoría “técnicas” en el nivel “en pruebas” publicada por Thoughtworks en el mismo año [5]. En la publicación se aclaran varios conceptos y se promueve la automatización en la configuración de tableros de monitoreo, la minimización de tareas repetitivas y la implementación de pipelines que faciliten la aplicación continua de pruebas y el ajuste en los umbrales para la generación de alertas. Para alcanzar un ecosistema de observabilidad basado en código, los autores recomiendan la combinación de dos técnicas: configuración como código [CaC] e infraestructura como código [IaC]. En la práctica esto se traduce en la elección de tecnologías que soporten la configuración a través del versionamiento controlado del código y la ejecución de comandos vía pipelines.

La publicación de Thoughtworks sobre [OaC] inició un campo de estudio que hoy en día forma parte de algo más general, el desarrollo impulsado por observabilidad [ODD], una expresión que refiere todas las actividades necesarias para alcanzar verdadera observabilidad y que básicamente incluye tecnologías, soluciones, diseños, instrumentación y visualización de logs, métricas y trazas, entre las que se encuentran la latencia, los errores, la saturación y el tráfico.

Observabilidad como Código en Terraform

Aunque el proveedor de Google Cloud para Terraform ofrece recursos que facilitan la implementación de [OaC], estas implementaciones están limitadas a los servicios de monitoreo. La integración con los demás servicios, incluidos en las soluciones de los proveedores de nube, no se encuentran de forma explícita en módulos que permitan el aprovisionamiento de tableros para Google Compute Engine, Google Kubernetes Engine o Google Cloud SQL usando [OaC]. Esto, más que imponer una limitación, representa una oportunidad para el diseño de módulos, la implementación de abstracciones y la generación de patrones que le permitan a los equipos de desarrollo contar con arquitecturas basadas en los tres principios de observabilidad y las cuatro métricas de doradas descritas en la sección anterior.

Sumado a estos desafíos, es común que muchas organizaciones contraten herramientas de monitoreo y telemetría como NewRelic [6], Datadog [7], Honeycomb [8] o Dynatrace [9] porque encuentran valor en las funcionalidades que ofrecen y que en la mayoría de los casos no están presentes en los servicios de los proveedores de nube. Esto representa un desafío para los equipos de tecnología, en términos de diseño, implementación y mantenimiento de arquitecturas limpias centradas en monitoreo y observabilidad y lo que en consecuencia puede convertirse en una limitación para la implementación de [OaC]. Las razones incluyen las curvas de aprendizaje asociadas a cada herramienta, el dominio de diferentes providers en Terraform y el seguimiento a fallas entre las implementaciones.

Esta sección presenta una primera aproximación para resolver el primero de los dos desafíos: la generación de [OaC] sobre los servicios de Google Cloud. Para ello, en en el siguiente módulo de Terraform se clasifican las métricas disponibles para Google Kubernetes Engine, en términos de las cuatro métricas doradas y se detalla la implementación de los módulos para disponer tableros de monitoreo que permitan su visualización.

El repositorio se puede consultar aquí.

Mejores Prácticas en OaC

Aunque la práctica de [OaC] es relativamente nueva en el mercado, ya se tienen historias de éxito y fracaso sobre su implementación. Las lecciones aprendidas se presentan en esta seccción como mejores prácticas y recomendaciones.

Elija la Arquitectura de Observabilidad apropiada

Aunque en la literatura hay documentación sobre diferentes estrategias para construir arquitecturas de observabilidad, Google Cloud publicó un diagrama de flujo que permite tomar una decisión con una descripción de las formas más comunes de organizar los recursos, sus ventajas y desventajas.

Considere los Permisos para Monitorear

Haga un buen uso de tres roles de IAM relacionados con el monitoreo y priorice el uso del menor privilegio posible.

• Visor de monitoreo: brinda al usuario acceso de solo lectura a la consola y las API de Cloud Monitoring.
• Editor de supervisión: otorga al usuario acceso de lectura y escritura a la consola y las API de Cloud Monitoring, incluida la escritura de datos de supervisión en un espacio de trabajo.
• Administrador de supervisión: otorga al usuario acceso total a la supervisión en la nube.

Optimice los Costos de Monitoreo

Considere una estrategia FinOps y siga las recomendaciones documentadas aquí. Por ejemplo, de acuerdo con un estudio el uso de las métricas disponibles en el catálogo suelen ser hasta 80% menos costosas que escribir métricas personalizadas desde Google Kubernetes Engine. En la misma referencia hay una guía extensa para optimizar los costos, usando pipelines de métricas de carga de trabajo.

Utilice las Visualizaciones Apropiadas

Considere los siguientes elementos en el aprovisionamiento de los tableros con [OaC]:

• ¿La visualización de los datos se requiere en tiempo real o histórico?
• ¿Se requiere el uso de métricas comparativas?
• ¿Cuántas fuentes de datos alimentan el dashboard requerido?

Revise documentación sobre la mejor estrategia para representar series de tiempo, histogramas o gráficos de comportamiento.

Referencias

[1] Rudolf E. Kálmán. Topics in Mathematical System Theory. 1960.

[2] Charity Majors, Liz Fong-Jones, George Miranda. Observability Engineering. 2022.

[3] Betsy Beyer, Chris Jones, Niall Richard Murphy, Jennifer Petoff. Site Reliability Engineering . 2016.

[4] Betsy Beyer, Niall Murphy, David Rensin, Kent Kawahara and Stephen Thorne. The Site Reliability Workbook . 2018.

[5] https://www.thoughtworks.com/radar/techniques/observability-as-code

[6] https://newrelic.com/

[7] https://www.datadoghq.com/

[8] https://www.honeycomb.io/

[9] https://www.dynatrace.com/

[10] https://www.hashicorp.com/resources/observability-as-code-with-terraform

[11] https://registry.terraform.io/providers/hashicorp/google/latest/docs

[12] https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/monitoring_dashboard

[13] https://opentelemetry.io/docs/instrumentation/java/automatic/

[14] https://github.com/terraform-google-modules/terraform-google-cloud-operations

[15] https://github.com/terraform-google-modules/terraform-google-slo

[16] https://github.com/terraform-google-modules/terraform-google-log-export

[17] https://cloud.google.com/architecture/managing-monitoring-dashboards-automatically-using-the-api