Maximizando la “observabilidad”: El reto clave para las organizaciones.
Escrito por Richard Ortiz & Camilo Ortiz
Introducción
Como organización, nos encontramos inmersos en un continuo proceso de transformación de nuestros métodos para desarrollar soluciones. En este escenario, nos enfrentamos a un entorno tecnológico dinámico que diariamente nos presenta una avalancha de herramientas, tecnologías y frameworks para la construcción de aplicaciones.
Nuestros desafíos incluyen:
· Modernización de la infraestructura.
· Adopción de modelos de nube multinube/híbridos.
· Agilidad en los procesos de desarrollo.
· Seguridad de las aplicaciones.
Estos retos nos sitúan en un universo de aplicaciones distribuidas, donde la tarea de comprender su estado se vuelve cada vez más compleja y desafiante. Por ende, buscamos establecer un modelo de referencia que oriente la implementación de la observabilidad en la creación de nuestras soluciones.
1. ¿Qué es observabilidad?
Se define como la habilidad para comprender el estado interno de un sistema mediante la recopilación y análisis de datos, como métricas, trazas y logs. Esta práctica es fundamental para asegurar el rendimiento, la disponibilidad y la seguridad de nuestras soluciones tecnológicas. Al utilizar estos datos, podemos tomar decisiones fundamentadas que contribuyan a mejorar la confiabilidad y el funcionamiento general de nuestros sistemas. La observabilidad se ha vuelto crucial en el desarrollo y mantenimiento de los sistemas modernos, permitiendo a los equipos de ingeniería y negocio comprender y resolver problemas de manera efectiva. En este contexto, decidimos usar OpenTelemetry como base del modelo de referencia.
2. ¿Qué es Opentelemetry?
Es una iniciativa de código abierto diseñada para brindar herramientas y estándares que faciliten la instrumentación de aplicaciones, mejorando nuestra capacidad y efectividad para observar sistemas distribuidos. Este proyecto se fundamenta en un modelo integral que abarca la instrumentación, la recolección, el procesamiento y la distribución de datos de telemetría.
2.1. Proceso de instrumentación
OpenTelemetry ofrece varias opciones de instrumentación de acuerdo con las características de la aplicación que deseamos instrumentar.
· Instrumentación con SDKs (Code-based)
Ofrece bibliotecas para diversos lenguajes de programación, lo que capacita a los desarrolladores para instrumentar sus aplicaciones de forma coherente, capturando datos de telemetría tales como trazas, métricas y logs, de manera eficiente.
· Instrumentación con Agentes (Zero-code)
Incorpora las capacidades del SDK a la aplicación, mediante un agente específico para el lenguaje de programación en el que está desarrollada la aplicación.
· Instrumentación para Kubernetes (Zero-code)
Se realiza mediante la implementación de un operador de Kubernetes que posibilita la instrumentación automática de las cargas de trabajo, mediante las bibliotecas de instrumentación de OpenTelemetry.
2.2. Proceso de recolección
Aquí utilizamos una herramienta fundamental: OpenTelemetry collector. Este componente nos ofrece dos modalidades para obtener datos de telemetría: modo push y modo pull. Además, soporta una amplia variedad de formatos de datos, lo que lo convierte en una herramienta versátil y adaptable a diferentes necesidades.
· Modo Push
Nos permite declarar diferentes tipos de receptores (Receivers) que reciban los datos de telemetría desde las aplicaciones instrumentadas e incluso, desde otras herramientas como pueden ser receivers de AWS Cloudwatch, Azure Monitor, Datadog, entre otras.
· Modo Pull
Nos permite declarar diferentes tipos de receptores (Receivers) en los cuales el collector puede ir directamente hasta la herramienta y extraer los datos de telemetría recolectada en la misma.
La decisión de usar un modo u otro está condicionada por el punto de vista de integración de la herramienta desde la cual se genera la data de telemetría.
2.3. Procesamiento
El collector de OpenTelemetry tiene la capacidad de transformar los datos antes de ser enviados a los backends (almacenamiento, visualización).
El proceso de transformación de los datos permite mejorar la calidad y seguridad de los mismos; además, reduce costos asociados a la trasmisión de los datos gracias al filtrado de información.
Los procesadores (processors) disponibles admiten transformaciones en datos de métricas, trazas y logs.
2.4. Distribución (exportar)
El collector de OpenTelemetry tiene la capacidad de enviar datos a diferentes sistemas/backends y para ello, dispone de exportadores (exporters) como elemento de configuración de los diferentes destinos a los cuales podemos enviar la información.
2.5. Modelos de despliegue del collector de OpenTelemetry
En los modelos de despliegue del collector de OpenTelemetry podemos encontrar dos:
· Agente
En este modelo, las aplicaciones instrumentadas en sus diferentes formas (ver apartado 2.1 Proceso de instrumentación) pueden exportar los datos de telemetría directamente hacia las soluciones de backends definidas, lo que nos deja con un modelo de recolección distribuido, disminuyendo la flexibilidad y nos presenta grandes retos al momento de correlacionar la data.
· Gateway
Aquí las aplicaciones instrumentadas en sus diferentes formas (ver apartado 2.1 Proceso de instrumentación), envían los datos de telemetría hacia el collector donde se encuentran declarados los receptores (Receivers), procesadores (Processors) y exportadores (Exporters); estos últimos envían la data recibida y procesada hacia las soluciones de backends definidas, lo que nos ayuda a correlacionarla.
3. ¿Por qué usar OpenTelemetry?
La instrumentación de aplicaciones para la telemetría es un proceso complejo, con diferentes herramientas y formatos para cada tipo de dato. OpenTelemetry unifica este proceso al proporcionar:
· Un conjunto de API estándar: independientemente de los lenguajes de programación o frameworks que utilicemos, OpenTelemetry nos ofrece una API única para la instrumentación de métricas, trazas y logs.
· Soporte para múltiples lenguajes: nos brinda soporte para una amplia gama de lenguajes populares, como Java, Python, Go, JavaScript y Ruby, entre otros.
· Agentes de recolección: proporciona agentes que recopilan datos de telemetría de las aplicaciones y los envían a un backend de análisis.
· Integración con multiples backends: se integra con backends de observabilidad como Prometheus, Jaeger, Grafana y ELK Stack.
· Apoya la flexibilidad: puedes elegir los backends de almacenamiento/análisis que más se adapten a tus necesidades.
4. Modelo de “observabilidad”. Opentelemetry como eje central
5. Conclusiones
· Instrumentar aplicaciones que no disponen de un sdk o agente puede llegar a ser una tarea tediosa, pues requiere un mayor análisis para determinar las opciones de instrumentación y esto implica, incluso, la construcción de componentes que realicen la tarea de recolección y uso de la API de OpenTelemetry.
· Como organización, nos enfrentamos al desafío adicional de integrar una variedad de soluciones de terceros que no ofrecen soporte nativo para OpenTelemetry. Esta situación representa un gran reto en nuestro camino hacia la consecución de los niveles de observabilidad deseados.
· OpenTelemetry está siendo adoptado ampliamente por los principales proveedores de nube y fabricantes de soluciones de observabilidad, los cuales han realizado esfuerzos para proporcionar mecanismos de instrumentación para sus servicios. Un ejemplo de ello es AWS con su servicio AWS Distro for OpenTelemetry, el cual permite instrumentar servicios como ec2, ecs, eks, lambda.
· El pilar de los logs sigue siendo un reto mayor, debido a los grandes esfuerzos que representa la estandarización de la información.
