OpenTelemetry es el resultado de una fusión entre dos proyectos anteriores, OpenTracing y OpenCensus. Ambos proyectos se crearon para resolver el mismo problema: la falta de un estándar sobre cómo instrumentar el código y enviar datos de telemetría a un backend de observabilidad. Sin embargo, ninguno de los dos proyectos fue capaz de resolver el problema por sí solo, por lo que los dos proyectos se fusionaron para formar OpenTelemetry para que pudieran combinar sus fortalezas y ofrecer realmente un solo estándar.

Fundamentalmente, OpenTelemetry es independiente de los proveedores y las herramientas, lo que significa que se puede usar con una amplia variedad de backends de observabilidad, incluidas las herramientas de código abierto como Jaeger y Prometheus, así como ofertas comerciales. Otel es un proyecto de Cloud Native Computing Foundation (CNCF), desarrollado para funcionar como una solución robusta, portátil y fácil de instrumentar en muchos idiomas. Proporciona un conjunto único de API, bibliotecas, agentes y servicios de recopilador para capturar trazabilidad y métricas distribuidas de tu aplicación. OpenTelemetry hace posible la verdadera observabilidad.

“Observabilidad” es un término que ha ganado mucha atención en el mundo de la ingeniería de software y la administración de sistemas, casi hasta el punto de perder parte de su significado. Hoy en día, incluso muchos de los que trabajan en TI usan el término de forma general para indicar cualquier tipo de visibilidad del sistema. Pero ¿qué es exactamente la observabilidad y en qué se diferencia de la supervisión tradicional?

La observabilidad no es lo mismo que la supervisión.

La supervisión es el proceso de observar y comprobar activamente el estado del sistema, normalmente mediante umbrales y alertas predefinidos. Si bien este enfoque puede llamar tu atención sobre los sistemas afectados cuando algo sale mal, la supervisión a menudo no te proporciona información sobre por qué se produce el problema o cuál es la mejor manera de resolverlo.

La observabilidad, por otro lado, es un enfoque más integral. Se refiere a la capacidad de comprender lo que sucede dentro de un sistema mediante el análisis de sus salidas externas. La observabilidad te permite hacer cualquier pregunta sobre lo que ocurrió en cualquier momento, sin tener predefinido lo que querías saber de antemano. Esencialmente, la supervisión puede indicarte si hay un problema, pero la observabilidad te ayuda a comprender por qué ocurrió dicho problema.

Trazabilidad, métricas y registros

Hay tres pilares principales que son esenciales para la observabilidad:

• Trazabilidad
  Una trazabilidad representa el recorrido de una solicitud a través de un sistema y puede proporcionar una imagen detallada de las interacciones de servicio. La trazabilidad de OpenTelemetry se organiza en intervalos que contienen atributos y eventos, y describen y contextualizan el trabajo que se realiza en varios procesos y servicios.
• Métricas
  Las métricas son representaciones numéricas de datos medidos a lo largo de intervalos de tiempo. Permiten la supervisión continua del rendimiento y el comportamiento del sistema. En OpenTelemetry, la API de métricas se puede usar para registrar, establecer y agregar métricas del sistema, ofreciendo herramientas para filtrar y agregar análisis más adelante.
• Registros
  Son registros basados en texto generados por sistemas y aplicaciones. Proporcionan un relato cronológico de los eventos y pueden ser vitales para depurar y comprender el comportamiento del sistema.

Si bien estos tres elementos se han considerado durante mucho tiempo los factores más esenciales en la observabilidad, la creciente escala y complejidad de los sistemas distribuidos modernos ha obligado a este modelo tradicional a evolucionar. Los profesionales han comenzado a reconocer que los tres pilares no están aislados, sino fundamentalmente interconectados y deben utilizarse en coordinación entre sí.

OpenTelemetry desempeña un rol crucial para permitir la observabilidad en sistemas distribuidos basados en microservicios. Su énfasis en la portabilidad, la disponibilidad de implementaciones y kits de desarrollo de software (SDK) en la mayoría de los idiomas, y especialmente sus modelos de exportador y recopilador, lo convierten en una herramienta clave para recopilar y distribuir datos adecuados para el sistema.

Con OpenTelemetry, los equipos pueden recopilar de manera eficiente los datos de trazabilidad y métricas clave necesarios para analizar el comportamiento del sistema. Esta alineación con las prácticas de observabilidad permite una comprensión más profunda del rendimiento del sistema, lo que mejora la capacidad de diagnosticar y resolver problemas.

¿Qué es el rastreo en OpenTelemetry?

Al igual que la trazabilidad es uno de los tres pilares de la observabilidad, el rastreo es una práctica crucial dentro del desarrollo de software, que se utiliza normalmente para perfilar y analizar el código de la aplicación a través de herramientas de depuración especializadas. En el contexto de OpenTelemetry, el rastreo adquiere un significado más matizado, refiriéndose más a menudo al rastreo distribuido, un concepto esencial en las arquitecturas complejas de hoy.

Rastreo distribuido

El rastreo distribuido representa la aplicación de técnicas de rastreo tradicionales a aplicaciones modernas impulsadas por microservicios. A diferencia de las aplicaciones monolíticas en las que el diagnóstico de un fallo puede implicar seguir un solo rastreo de pila, los sistemas distribuidos son simplemente demasiado complejos para este enfoque. Cuando una aplicación consta de miles de servicios que se ejecutan en varios hosts, la trazabilidad individual se vuelve insuficiente. El rastreo distribuido resuelve este problema mediante el perfilado de las solicitudes a medida que atraviesan diferentes límites del servicio, y genera datos de alta calidad para su análisis. Este método proporciona competencias tales como:

• Detección de anomalías 
• Modelado de cantidad de trabajo 
• Diagnóstico de problemas en estado estable

Trazabilidad e intervalos

En OpenTelemetry, una trazabilidad es una colección de intervalos vinculados, que son operaciones con nombre y cronometradas que representan una unidad de trabajo en una solicitud. Un intervalo puede tener un intervalo principal, o puede ser un intervalo raíz, que describe la latencia de un extremo a otro de toda la trazabilidad. Los intervalos secundarios representan suboperaciones dentro de la trazabilidad.

• Intervalo raíz
  El punto principal o inicial de la trazabilidad, que representa la latencia de toda la solicitud. 
• Intervalo secundario
  Suboperaciones específicas dentro de la trazabilidad.

Los intervalos encapsulan información esencial, incluido el nombre de la operación, las marcas de tiempo de inicio y finalización, los eventos y los atributos que se produjeron durante el intervalo. También contienen enlaces a otros intervalos y al estado de la operación.

Atributos y eventos

Dada la complejidad de los datos de trazabilidad del sistema distribuido, tener acceso al contexto y otros detalles relevantes puede marcar una gran diferencia positiva en el análisis de datos. En OpenTelemetry, estas etiquetas se conocen como atributos y eventos:

• Atributos
  Pares de clave/valor (conocidos en OpenTracing como “etiquetas”) que se pueden agregar a un intervalo para ayudar a analizar los datos de trazabilidad.
• Eventos
  Cadenas con marca de tiempo con un conjunto opcional de atributos que proporcionan una descripción adicional, lo que permite un análisis más detallado.

Rastreadores y propagadores

Los intervalos en OpenTelemetry son generados por el Rastreador, un objeto que rastrea el intervalo activo actualmente y permite la creación de nuevos intervalos. Los objetos propagadores admiten la transferencia del contexto a través de los límites del proceso, un aspecto vital del rastreo en sistemas distribuidos. El Rastreador envía los intervalos completados al exportador del SDK de Otel, responsable de enviar los intervalos a un sistema backend para su posterior análisis.

Si bien el rastreo proporciona información detallada sobre las solicitudes y operaciones individuales, también se relaciona con el contexto más amplio de observabilidad dentro de OpenTelemetry, incluidas las métricas. Cuando se conectan los datos de trazabilidad con métricas relevantes, las organizaciones pueden obtener una comprensión integral del comportamiento y el rendimiento de su sistema.

En el contexto de OpenTelemetry, la API de métricas está diseñada para procesar y resumir continuamente las mediciones sin procesar. Esto proporciona a las organizaciones una mayor visibilidad de las métricas operacionales vitales, incluida la utilización de la memoria de procesos, las tasas de error y más. Las métricas se pueden enviar a varios instrumentos para su agregación y registro. La API de métricas de OpenTelemetry clasifica los instrumentos de métrica según su significado semántico en lugar del tipo final de valor que exportan.

Instrumentos de métricas en OpenTelemetry

La API de métricas proporciona seis instrumentos de métricas distintos, cada uno de los cuales cumple una función específica. Estos instrumentos se crean y definen mediante llamadas a una API Meter, el punto de entrada del usuario al SDK. Los instrumentos de métrica son síncronos o asíncronos.

Instrumentos síncronos

Los instrumentos síncronos se invocan dentro de una solicitud y poseen un contexto distribuido asociado. Los instrumentos síncronos incluyen los siguientes:

• Counter
  El instrumento Counter acepta valores positivos con la función Add() (Agregar). Esto es ideal para contar datos como bytes recibidos y solicitudes completadas, y para medir la incidencia de errores, y es particularmente adecuado para las mediciones de volumen.
• UpDownCounter
  Una extensión de la funcionalidad de contador, UpDownCounter procesa incrementos positivos y negativos a través de la función Add() (Agregar). Esto es útil para supervisar cantidades como solicitudes activas, memoria en uso y tamaño de la cola.
• ValueRecorder
  El instrumento ValueRecorder captura valores para eventos discretos usando la función Record() (Registrar). Esto se utiliza para capturar la latencia, el tamaño de la solicitud y la longitud de la cola, haciendo énfasis en una distribución de valores

Instrumentos asíncronos

A diferencia de los instrumentos síncronos, los instrumentos asíncronos carecen de un contexto asociado. Estos instrumentos se informan mediante callback y se llaman solo una vez por intervalo de recopilación. Los instrumentos síncronos incluyen los siguientes:

• SumObserver
  El instrumento SumObserver utiliza la función Observe() (Observar) para sumas monótonas asíncronas, y es más adecuado para datos como errores de caché y CPU del sistema. 
• UpDownSumObserver
  UpDownSumObserver es un contador asíncrono y no monótono que acepta sumas positivas y negativas con la función Observe() (Observar). Este instrumento se utiliza para las mediciones que capturan el aumento y la caída de las sumas, como el tamaño de pila del proceso.
• ValueObserver
  Finalmente, ValueObserver empodera a las organizaciones con un control detallado sobre las mediciones no aditivas mediante la función Observe() (Observar). Esto es ideal cuando el foco de las mediciones es una distribución.

La composición de los eventos de métrica

Los eventos de métrica capturados por cualquier instrumento consisten en una marca de tiempo, una definición del instrumento (nombre, tipo, descripción, unidad de medida), un conjunto de etiquetas (claves y valores), un valor (número entero o de coma flotante), recursos asociados con el SDK y contexto distribuido (solo para eventos síncronos). La variedad de instrumentos de métrica disponibles ofrece flexibilidad para capturar diferentes tipos de datos, lo que ayuda en el análisis y la supervisión de diversos atributos del sistema.

Ya sea que supervise las tasas de error, la latencia o la utilización de recursos, los instrumentos de métrica de OpenTelemetry ofrecen diversas opciones para que los desarrolladores obtengan información crítica sobre sus aplicaciones.

El exportador es responsable de procesar por lotes y transportar los datos de telemetría a un sistema backend para su análisis y alerta. El modelo exportador de OpenTelemetry admite la integración de la instrumentación en tres niveles diferentes:

• Integración de nivel de servicio
  Esto implica declarar una dependencia del paquete de OpenTelemetry relevante dentro de tu código y desplegarlo en consecuencia.
• Dependencias de biblioteca
  Similar a la integración de nivel de servicio, pero específica de las bibliotecas, que normalmente solo declaran una dependencia de la API de OpenTelemetry.
• Dependencias de la plataforma
  Estos son componentes de software independientes que respaldan tu servicio, como Envoy e Istio. Despliegan su copia de OpenTelemetry y emiten un contexto de trazabilidad útil para tu servicio.

La interfaz del exportador, implementada por los SDK de OpenTelemetry, utiliza un modelo de complemento que traduce los datos de telemetría al formato requerido para un sistema backend en particular antes de transmitir los datos. Este modelo también admite la composición y el encadenamiento de exportadores, lo que facilita la funcionalidad compartida en diferentes protocolos.

Una ventaja significativa del enfoque de OpenTelemetry es la facilidad de cambiar o agregar componentes de exportación. Esto lo diferencia de OpenTracing, donde cambiar el sistema requiere reemplazar todo el componente de rastreo.

Si bien el modelo de exportador ofrece una gran comodidad, ciertas restricciones organizativas o técnicas pueden impedir la fácil reimplementación de un servicio para agregar un nuevo exportador. El recopilador de OpenTelemetry está diseñado para actuar como un “enlace” para los datos de telemetría de varios procesos, exportándolos a varios sistemas backend como Observabilidad de la nube de ServiceNow, Jaeger o Prometheus. El recopilador se puede implementar como un agente junto con un servicio o como una aplicación remota:

• Agente
  Se despliega con tu servicio y se ejecuta como un proceso independiente o sidecar. 
• Recopilador remoto
  Se implementa por separado en un contenedor o máquina virtual, recibiendo datos de telemetría de cada agente y exportándolos a sistemas backend.

OpenTelemetry consta de los siguientes componentes principales:

• Una especificación para todos los componentes
• Un protocolo estándar que define la forma de los datos de telemetría
• Convenciones semánticas que definen un esquema de nomenclatura estándar para tipos de datos de telemetría comunes
• API que definen cómo generar datos de telemetría
• Un ecosistema de biblioteca que implementa la instrumentación para bibliotecas y marcos de trabajo comunes
• Componentes de instrumentación automática que generan datos de telemetría sin necesidad de cambios de código.
• SDK de idiomas que implementan la especificación, las API y la exportación de datos de telemetría
• El recopilador de OpenTelemetry, un proxy que recibe, procesa y exporta datos de telemetría.
• Otras herramientas, como Operador de OpenTelemetry para Kubernetes

Compatibilidad

Compatible con una amplia variedad de integraciones de ecosistemas de código abierto, OpenTelemetry también cuenta con el respaldo de un gran número de proveedores, muchos de los cuales proporcionan soporte comercial para OpenTelemetry y contribuyen directamente al proyecto.

Extensibilidad

OpenTelemetry está diseñado para ser extensible. Algunos ejemplos de cómo se puede ampliar incluyen los siguientes:

• Agregar un receptor al Recopilador de OpenTelemetry para admitir datos de telemetría de una fuente personalizada.
• Cargar instrumentación personalizada en un SDK
• Crear una distribución de un SDK o el recopilador adaptada a un caso de uso específico
• Crear un nuevo exportador para un backend personalizado que aún no admite el protocolo OpenTelemetry (OTLP)
• Crear un propagador personalizado para un formato de propagación de contexto no estándar

Aunque la mayoría de los usuarios no necesitará ampliar OpenTelemetry, el proyecto está diseñado para hacerlo posible en casi todos los niveles.

¿Por qué OpenTelemetry es importante?

Con el aumento de la computación en la nube, las arquitecturas de microservicios y los requisitos empresariales cada vez más complejos, la necesidad de observabilidad nunca había sido mayor.

Para que un sistema sea observable, debe estar instrumentado. Es decir, el código debe emitir trazabilidad, métricas y registros. Los datos instrumentados deben enviarse a un backend de Observabilidad.

OpenTelemetry hace dos cosas importantes:

• Te permite ser propietario de los datos que generas en lugar de quedarte atascado con un formato de datos o una herramienta patentada.
• Te permite aprender un único conjunto de API y convenciones

Estas dos cosas combinadas otorgan a los equipos y a las organizaciones la flexibilidad que necesitan en el mundo de la informática moderna de hoy.

OpenTelemetry no es un back end de Observabilidad como Jaeger, Prometheus o proveedores comerciales. OpenTelemetry se centra en la generación, la recopilación, la gestión y la exportación de datos de telemetría. El almacenamiento y la visualización de esos datos se dejan intencionalmente a otras herramientas.

La necesidad de visibilidad de un extremo a otro es más crucial que nunca. OpenTelemetry ofrece un enfoque estandarizado para la recopilación de datos de telemetría en diversas aplicaciones y lenguajes de programación. Al ofrecer conocimientos completos sobre el comportamiento del sistema, Otel permite a las organizaciones optimizar el rendimiento, solucionar problemas y ofrecer una experiencia de usuario perfecta. Pero cuando se trata de observabilidad, siempre hay margen de mejora.

Observabilidad de la nube de ServiceNow, anteriormente conocido como Lightstep, admite OpenTelemetry como la forma de obtener datos de telemetría (trazabilidad, registros y métricas) a medida que las solicitudes viajan a través de servicios y otras infraestructuras. Observabilidad en la nube incorpora datos de OpenTelemetry a través del protocolo nativo OpenTelemetry Protocol (OTLP). Los datos de OTLP se pueden exportar a Observabilidad en la nube a través de HTTP o gRPC.

Para mejorar aún más la observabilidad y la gobernanza en entornos nativos de la nube, ServiceNow también lanzó el Conector de Service Graph para OpenTelemetry (SGC). Aprovechando los datos de OpenTelemetry y el backend de Observabilidad de la nube de ServiceNow, esta solución revoluciona la forma en que las empresas obtienen visibilidad y conocimientos sobre sus aplicaciones nativas de la nube y la infraestructura de Kubernetes. SGC detecta y mapea automáticamente las dependencias del servicio, creando una topología de servicio precisa y actualizada. Al permitir a las organizaciones evaluar el impacto de los cambios, optimizar la gestión de incidentes y fomentar la colaboración multifuncional, esta solución mejora la eficiencia, reduce el riesgo y ayuda a garantizar la mejor observabilidad posible en entornos de TI complejos.

Experimenta las competencias transformadoras del Conector de Service Graph para OpenTelemetry; ¡comunícate con ServiceNow hoy mismo!