OpenTelemetry (OTel) es un marco de trabajo de observabilidad y un conjunto de herramientas que consiste en un lenguaje compartido, un modelo de datos y una unificación de los comportamientos de propagación subyacentes. OTel también se ha diseñado para gestionar datos de telemetría, como trazas, métricas y logs, y es de código abierto, lo que permite una mayor flexibilidad.
OpenTelemetry es el resultado de una fusión entre dos proyectos previos, OpenTracing y OpenCensus. Ambos proyectos se crearon para resolver el mismo problema: la falta de un estándar sobre cómo instrumentar código y enviar datos de telemetría a un backend de observabilidad. Sin embargo, ninguno de los dos proyectos era capaz de resolver el problema por sí solo, por lo que se fusionaron para formar OpenTelemetry con el fin de combinar sus puntos fuertes y ofrecer un solo estándar.
Fundamentalmente, OpenTelemetry es independiente de proveedores y 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), diseñado para funcionar como una solución robusta, portátil y fácil de instrumentar en muchos lenguajes. Proporciona un conjunto único de API, bibliotecas, agentes y servicios de recopilador para capturar métricas y trazas distribuidas de tu aplicación. OpenTelemetry hace posible la auténtica observabilidad.
La “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 a la ligera 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 supervisión es el proceso de observar y comprobar activamente el estado del sistema, normalmente mediante alertas y umbrales predefinidos. Aunque este enfoque puede dirigir la atención hacia los sistemas afectados cuando algo sale mal, la supervisión no suele proporcionar conocimientos sobre por qué se produce el problema o cómo resolverlo mejor.
Por otro lado, la observabilidad es un enfoque más integral. Consiste en la capacidad de comprender lo que sucede dentro de un sistema mediante el análisis de sus resultados externos. La observabilidad te permite indagar sobre lo que ocurrió en cualquier momento, sin tener predefinido lo que querías saber de antemano. Básicamente, la supervisión puede indicarte cuándo existe un problema, pero la observabilidad te ayuda a comprender por qué ocurrió ese problema.
Hay tres pilares principales que son esenciales para la observabilidad:
- Trazas
Una traza representa el recorrido de una solicitud a través de un sistema y puede proporcionar una imagen detallada de las interacciones del servicio. Las trazas de OpenTelemetry se organizan en “spans” 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, y ofrece herramientas para filtrar y agregar análisis posteriormente. - Logs
Los logs son registros basados en texto que generan los sistemas y las aplicaciones. Proporcionan un relato cronológico de los eventos y pueden ser esenciales para depurar y comprender el comportamiento del sistema.
Aunque estos tres elementos se han considerado durante mucho tiempo como 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 que están interconectados y deben utilizarse coordinados entre sí.
OpenTelemetry desempeña un papel fundamental para permitir la observabilidad en sistemas distribuidos basados en microservicios. Su hincapié en la portabilidad, la disponibilidad de implementaciones y kits de desarrollo de software (SDK) en la mayoría de los lenguajes, y en especial 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 clave de trazas y métricas 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.
Al igual que las trazas son 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 aplicaciones a través de herramientas de depuración especializadas. En el contexto de OpenTelemetry, el rastreo adquiere un significado más matizado, ya que se suele referir al rastreo distribuido, un concepto esencial en las arquitecturas complejas de hoy en día.
El rastreo distribuido representa la aplicación de técnicas de rastreo tradicionales en aplicaciones modernas basadas en microservicios. A diferencia de las aplicaciones monolíticas, en las que diagnosticar un fallo puede implicar el seguimiento de una traza de una sola pila, los sistemas distribuidos son demasiado complejos para este enfoque. Cuando una aplicación consta de miles de servicios que se ejecutan en varios hosts, las trazas individuales son insuficientes. El rastreo distribuido resuelve este problema mediante la elaboración de perfiles de las solicitudes a medida que atraviesan diferentes límites del servicio, lo que genera datos de alta calidad para su análisis. Este método proporciona competencias como las siguientes:
- Detección de anomalías
- Modelado de cargas de trabajo
- Diagnóstico de problemas en estado estacionario
En OpenTelemetry, una traza es una colección de spans vinculados, que son operaciones con nombre y fecha que representan una unidad de trabajo en una solicitud. Un span puede tener un “parent”, o puede ser un root span, que describe la latencia de un extremo a otro de toda la traza. Los “child” spans representan suboperaciones dentro de la traza.
- Root Span
El punto inicial de la traza, que representa la latencia de toda la solicitud. - Child Span
Una suboperación específica dentro de la traza.
Los spans 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 span. También contienen enlaces a otros spans y al estado de la operación.
Dada la complejidad de los datos de trazas 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 valores clave (conocidos en OpenTracing como "etiquetas") que se pueden agregar a un span para ayudar a analizar los datos de trazas. - 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.
En OpenTelemetry, los spans los genera un rastreador, un objeto que rastrea el span activo y permite la creación de nuevos spans. Los objetos propagadores respaldan la transferencia del contexto por los límites del proceso, un aspecto esencial del rastreo en sistemas distribuidos. El rastreador envía los spans completados al exportador del SDK de OTel, responsable de enviar los spans a un sistema backend para un análisis más detallado.
Aunque el rastreo proporciona conocimientos detallados sobre las solicitudes y operaciones individuales, también se relaciona con el contexto más amplio de la observabilidad dentro de OpenTelemetry, incluidas las métricas. Al conectar los datos de trazas 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 mediciones sin procesar. Esto proporciona a las organizaciones una mayor visibilidad de las métricas operacionales esenciales, incluido el uso de la memoria de procesos, las tasas de error, etc. Las métricas se pueden enviar a varios instrumentos para que las agreguen y las registren. La API de métricas de OpenTelemetry clasifica los instrumentos métricos según su significado semántico en lugar del tipo final de valor que exportan.
La API de métricas proporciona seis instrumentos métricos 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 métricos son síncronos o asíncronos.
Los instrumentos síncronos se invocan dentro de una solicitud y poseen un contexto distribuido asociado. Los instrumentos síncronos incluyen:
- Counter
El instrumento Counter acepta valores positivos con la función Add(). Es ideal para contar datos como bytes recibidos y solicitudes completadas, así como para medir la incidencia de errores, y es especialmente adecuado para medir volúmenes. - UpDownCounter
Extensión de la funcionalidad Counter que procesa incrementos positivos y negativos a través de la función Add(). 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 con la función Record(). Se utiliza para capturar la latencia, el tamaño de la solicitud y la longitud de la cola, haciendo hincapié en una distribución de valores.
A diferencia de los instrumentos síncronos, los instrumentos asíncronos carecen de un contexto asociado. Estos instrumentos se informan mediante un “callback” y se llaman solo una vez por intervalo de recopilación. Los instrumentos asíncronos incluyen:
- SumObserver
El instrumento SumObserver utiliza la función Observe() para sumas monotónicas 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 monotónico que acepta sumas positivas y negativas con la función Observe(). Este instrumento se utiliza para las mediciones que capturan el aumento y la caída de las sumas, como el tamaño de la pila del proceso. - ValueObserver
Por último, ValueObserver proporciona a las organizaciones un control detallado sobre las mediciones no aditivas mediante la función Observe(). Es ideal cuando el foco de las mediciones es una distribución.
Los eventos métricos capturados por cualquier instrumento consisten en una marca de tiempo, una definición del instrumento (nombre, tipo, descripción, unidad de medida), conjunto de etiquetas (claves y valores), 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 métricos 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 se supervisen las tasas de error, la latencia o el uso de recursos, los instrumentos métricos de OpenTelemetry ofrecen diversas opciones para que los desarrolladores obtengan conocimientos esenciales 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 la generación de alertas. 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 como corresponda. - Dependencias de biblioteca
Similar a la integración de nivel de servicio, pero específico de las bibliotecas, que normalmente solo declaran una dependencia de la API de OpenTelemetry. - Dependencias de 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 traza útil para tu servicio.
La interfaz del exportador, implementada por los SDK de OpenTelemetry, utiliza un modelo basado en plug-ins 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 entre diferentes protocolos.
Una gran ventaja del enfoque de OpenTelemetry es la facilidad de cambiar o agregar componentes de exportación. Esto lo distingue de OpenTracing, donde cambiar el sistema requiere reemplazar todo el componente del rastreador.
Aunque el modelo de exportador ofrece una gran comodidad, determinadas restricciones organizativas o técnicas pueden impedir la reimplementación sencilla de un servicio para agregar un nuevo exportador. El recopilador de OpenTelemetry está diseñado para actuar como “sumidero” para los datos de telemetría de diversos procesos, exportándolos a varios sistemas backend como Observabilidad de ServiceNow en la nube, Jaeger o Prometheus. El recopilador se puede desplegar 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 despliega por separado en un contenedor o máquina virtual, recibe datos de telemetría de cada agente y los exporta 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 bibliotecas que implementa instrumentación para marcos de trabajo y bibliotecas comunes.
- Componentes de instrumentación automática que generan datos de telemetría sin necesidad de cambios de código.
- SDK de lenguajes 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 OpenTelemetry Operator for Kubernetes.
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.
OpenTelemetry se ha diseñado para que se pueda ampliar. Algunos ejemplos de cómo se puede ampliar incluyen:
- 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 del 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án ampliar OpenTelemetry, el proyecto está diseñado para que se pueda hacer en casi todos los niveles.
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 tan grande.
Para que un sistema sea observable, debe estar instrumentado. Es decir, el código debe emitir trazas, métricas y logs. Los datos instrumentados deben enviarse a un backend de observabilidad.
OpenTelemetry hace dos cosas importantes:
- Te permite poseer los datos que generas en lugar de dejarte con una herramienta o un formato de datos patentados.
- Te permite aprender un único conjunto de API y convenciones.
Estas dos cosas combinadas ofrecen a los equipos y a las organizaciones la flexibilidad que necesitan en el mundo de la computación moderna de hoy en día.
OpenTelemetry no es un back end de observabilidad como Jaeger, Prometheus o proveedores comerciales. OpenTelemetry se centra en la generación, recopilación, gestión y exportación de datos de telemetría. El almacenamiento y la visualización de esos datos se dejan intencionadamente a otras herramientas.
La necesidad de visibilidad de un extremo a otro es más importante 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 exhaustivos sobre el comportamiento del sistema, OTel permite a las organizaciones optimizar el rendimiento, solucionar problemas y ofrecer una experiencia de usuario fluida. Pero en lo que respecta a la observabilidad, siempre hay margen de mejora.
Observabilidad de ServiceNow en la nube, cuya denominación anterior era Lightstep, admite OpenTelemetry como método para obtener datos de telemetría (trazas, logs y métricas) a medida que las solicitudes fluyen por los servicios y otras infraestructuras. Observabilidad en la nube asimila datos de OpenTelemetry a través del protocolo de OpenTelemetry (OTLP) nativo. 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ó Conector de gráfico de servicios para OpenTelemetry (SGC). Al aprovechar los datos de OpenTelemetry y el backend de Observabilidad de ServiceNow en la nube, 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 asigna automáticamente las dependencias del servicio, y crea 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.
Disfruta de las competencias transformadoras de Conector de gráfico de servicios para OpenTelemetry; ponte en contacto con ServiceNow hoy mismo.