El concepto de Observability y la evolución de sus herramientas

• Concepto de Observability:

  • Una medida de qué tan bien se puede inferir el estado interno de un sistema a partir de los resultados (conocimiento) de sus salidas externas
  • Un sistema dinámico diseñado para estimar el estado del sistema a partir de la medición de sus salidas
  • La necesidad de Observability surgió con la popularización de los entornos cloud y la adopción generalizada de apps en contenedores Docker y arquitecturas de microservicios

• Diferencia entre Observability y monitoreo:

  • Monitoreo: algo que hace el usuario. Muestra qué está mal
  • Observability: un concepto más amplio que incluye al monitoreo. Proporciona abundante contexto sobre el funcionamiento interno y ayuda a resolver problemas profundos del sistema. Muestra incluso por qué está mal algo

• Situaciones en las que una organización necesita Observability:

  • Cuando, al surgir un incidente en producción, aparece la duda: “¿Qué datos permiten identificar la causa del problema, dónde están y cómo deben revisarse?”
  • Cuando un servicio que estaba funcionando bien hasta hace un minuto presenta un problema y surge la pregunta: “¿Dónde debo buscar la causa raíz?”
  • Cuando en la organización se plantean: “¿Cómo podemos hacer para que el equipo de desarrollo detecte los síntomas anómalos del servicio antes que el cliente o los equipos de soporte/operación?”
  • Cuando se quiere saber si existe una forma efectiva de rastrear errores de servicio o de rendimiento en microservicios, o si esto puede verificarse mediante logs o monitoreo de rendimiento de aplicaciones (APM)

• Evolución de las herramientas de Observability:

  • Desde la década de 2010, han aparecido diversas herramientas de Observability en la industria de TI
  • En 2010, Google presentó “Dapper”, una infraestructura de trazado para sistemas distribuidos a gran escala
  • Después, Uber y Twitter crearon respectivamente los sistemas de trazado distribuido “Jaeger” (Uber) y “Zipkin” (Twitter)
  • Surgió “Open Tracing”, un conjunto de API estándar para seguir modelando y describiendo el funcionamiento de sistemas distribuidos
  • Se publicó “Open Census”: un conjunto de librerías para varios lenguajes que recopilan métricas de aplicaciones y trazado distribuido, y luego envían los datos al backend en tiempo real
  • Luego apareció “Prometheus”
  • En 2019 se publicó “Open Telemetry (OTel)”, una colección de herramientas, API y SDK que integra Open Tracing y Open Census

• Open Telemetry:

  • Un framework de Observability open source y neutral respecto al proveedor
  • Existen datos de telemetría como logs, métricas y trazas que ayudan a analizar el rendimiento y el comportamiento del software; Open Telemetry se usa para instrumentarlos, generarlos, recopilarlos y exportarlos
    • Logs: metadatos con marca de tiempo. Se usan para determinar la causa raíz de un incidente
    • Métricas: datos estadísticos o agregados con etiquetas key/value medidos en un servicio. Son mediciones del servicio capturadas en tiempo de ejecución
    • Trazas: registros de eventos ocurridos a usuarios y aplicaciones. Registran la ruta de propagación de cada request individual
  • Forma de uso: la herramienta de Observability envía una alerta -> se revisa el contenido de la alerta y se va al dashboard para identificar el punto del problema -> se consulta en detalle una parte específica de ese punto -> se buscan y revisan los logs -> se encuentran y se estructuran en patrones los datos de trazas relacionados con esos logs -> ahí se identifica el problema, se corrige y se implementa Observability
  • La mayoría de las herramientas de Observability creadas recientemente ya ofrecen soporte nativo para Open Telemetry

• Razones de la aparición de Open Telemetry:

  • Antes, cada backend de Observability tenía sus propias librerías de instrumentación y agentes para enviar datos desde las herramientas, y existían varias formas de instrumentar el código
  • No existía un formato de datos estandarizado para enviar información a los backends de Observability
  • Después, Open Tracing y Open Census se integraron para crear un estándar único, dando origen a Open Telemetry

• SigNoz: herramienta APM open source

  • Ayuda a monitorear aplicaciones y resolver problemas
  • Usa tecnología de trazado distribuido para entender el stack de software del usuario
    • Monitorea métricas de aplicaciones como latency, requests per second y error rates
    • También observa métricas de infraestructura como uso de CPU y consumo de memoria
    • Rastrea requests de usuario a través de todos los servicios
    • Permite configurar alertas sobre métricas
    • Se puede ir a la traza exacta que causa el problema para encontrar la causa raíz
    • También permite ver gráficos de flama detallados del rastreo de requests individuales

[ninebow]

¡Gracias por el buen artículo!

[ironlung]

¡Gracias por tu comentario! :)

[kaistj]

Muchas gracias por el buen artículo~

[ironlung]

¡Gracias por tu comentario! :)

[jujumilk3]

¿Cómo se monitorea que el monitoreo esté funcionando bien?

Había pensado en algo parecido a la preocupación que sale en el cómic Watchmen, pero resulta que existía la palabra observability; gracias.

[ironlung]

¡Gracias! Últimamente también he notado que están surgiendo herramientas que buscan simplificar la observabilidad con IA. ¡Es un campo sobre el que me gustaría aprender más! :)

[inthelife]

Gracias por el buen artículo :)

[ironlung]

¡Gracias! :D