Registros de OpenTelemetry: Guía completa

Imagínate esto: tu entorno de producción se comporta de forma errática, con solicitudes que se interrumpen y mensajes de error por todas partes. Con una solución de registro tradicional, identificar la causa raíz -especialmente en aplicaciones distribuidas- suele requerir un proceso largo y laborioso. El registro de OpenTelemetry aborda este problema facilitando y acelerando la solución de problemas y la depuración.

Obtén todos tus registros de sistemas distribuidos en un solo lugar.

Empezar gratis

Sigue leyendo para entender qué es el registro de OpenTelemetry, cómo recopilar registros de OpenTelemetry y cómo aprovechar el middleware para afrontar los retos de la gestión de registros en sistemas distribuidos.

¿Qué es OpenTelemetry?

OpenTelemetry es un marco de observabilidad de código abierto e independiente del proveedor que proporciona un enfoque estándar y unificado para capturar datos de telemetría en aplicaciones modernas. Ofrece un conjunto de API, bibliotecas de instrumentación, SDK e integraciones para recopilar datos de telemetría, incluidas métricas, trazas y registros.

OpenTelemetry está construido y diseñado en torno a tres componentes básicos: instrumentación, recogida y exportación. El componente de instrumentación te permite añadir código a tu aplicación para la recogida de telemetría.

Una vez instrumentada tu aplicación, el Colector de telemetría OpenTelemetry recoge telemetría de varias fuentes de tu pila en tiempo de ejecución y la procesa para su posterior análisis. A continuación, OpenTelemetry exporta la telemetría recopilada a varios backends, como plataformas de observabilidad, sistemas de registro y herramientas de supervisión.

¿Qué son los registros de OpenTelemetry?

Los registros de OpenTelemetry son registros de texto con fecha y hora de eventos y actividades con metadatos. Cualquier dato -como eventos o intervalos- que no forme parte de una traza distribuida o de una métrica en OpenTelemetry es un tipo de registro o está adjunto a él.

Los registros proporcionan información detallada sobre el estado de la aplicación, incluidos errores, advertencias y otros eventos importantes. Facilitan la depuración y te permiten tomar decisiones informadas para mejorar la aplicación. Con OpenTelemetry, puedes integrar sistemas de alerta que te avisen cuando se detecten patrones de registro específicos preconfigurados o desencadenantes de palabras clave.

Los registros de OpenTelemetry se recopilan utilizando un enfoque diferente en comparación con las métricas y las trazas. Para las métricas y las trazas, OpenTelemetry proporciona una nueva API y su implementación en varios lenguajes.

Pero los registros tienen una rica historia de recopilación y uso; los lenguajes de programación más populares han incorporado tradicionalmente capacidades o bibliotecas de registro en su marco de trabajo. Como tal, OpenTelemetry es compatible con las bibliotecas de registro existentes, al tiempo que mejora sus capacidades y abstrae sus retos de integrabilidad.

En esencia, con la “Logs Bridge API” de OpenTelemetry, puedes recopilar datos de registro incorporando las bibliotecas de registro existentes -independientemente del lenguaje de programación utilizado- a tu pila.

Además, OpenTelemetry conecta los registros con trazas y métricas para proporcionar una telemetría más rica que facilite la resolución de problemas. También captura eventos span que proporcionan contexto para que puedas interpretar fácilmente los registros. Comparemos brevemente los registros y los intervalos de OpenTelemetry.

Recopila y controla tus registros en un solo lugar – Middleware.

Empezar gratis

Registros vs. Eventos Span

Los logs son registros de eventos críticos, errores y advertencias, y del momento en que se producen dentro de una app. Proporcionan registros exhaustivos del comportamiento de una app durante su ejecución y facilitan la supervisión en tiempo real.

Los eventos Span, por otra parte, capturan el contexto de las operaciones dentro de una app, incluyendo el tiempo y las relaciones causales entre los distintos componentes. OpenTelemetry correlaciona los registros con otros datos de observabilidad mediante el tiempo de ejecución, el contexto de ejecución y el contexto de recursos.

Los Span IDs, cuando se incluyen en los LogRecords, proporcionan los recursos para correlacionar los logs con las trazas que corresponden al mismo contexto de ejecución.

Un intervalo suele incluir metadatos, una hora de inicio, una hora de fin y un conjunto de eventos de registro asociados a ese intervalo. Esto hace que los tramos sean muy valiosos para correlacionar registros de eventos individuales de varios servicios en sistemas distribuidos.

¿Por qué es importante la correlación de datos?

La correlación de datos es importante por varias razones, entre ellas las siguientes.

Análisis sencillo de la causa raíz

Correlacionar registros, métricas y trazas permite un análisis eficaz de la causa raíz. Aparte de la causa raíz, los datos correlacionados también facilitan la identificación y comprensión de la secuencia de acontecimientos que conducen a un incidente, y señalan con precisión los componentes o servicios exactos que contribuyen al problema. Esto facilita una reparación eficaz del problema y reduce las posibilidades de que vuelva a producirse.

Optimización del rendimiento

Analizando métricas correlacionadas, registros y trazas, puedes identificar cuellos de botella, ineficiencias o procesos que consumen muchos recursos. Esta información te permite tomar decisiones basadas en datos para optimizar el rendimiento de las aplicaciones, ajustar las configuraciones y asignar los recursos de forma más eficaz.

Visión holística

Al combinar datos de distintas fuentes, como aplicaciones, hosts (por ejemplo, máquinas virtuales y contenedores) y componentes de host, la correlación te permite comprender las interdependencias entre varios componentes, servicios e infraestructura.

También obtendrás información sobre el flujo de solicitudes de extremo a extremo, comprenderás los impactos en todo el sistema durante los incidentes y visualizarás las relaciones entre las métricas y los registros de varios componentes.

Modelo de datos de registros de OpenTelemetry

Se trata del modelo y las convenciones semánticas que permiten representar los registros de diversas fuentes, como archivos de registro de aplicaciones, eventos generados por máquinas, registros del sistema, etc.

El modelo de datos de registros de OpenTelemetry pretende alcanzar los siguientes objetivos:

• Unificar la situación de los registros: qué es un registro de registro, qué datos debe registrar, transferir, almacenar e interpretar un sistema de registro.

• Para mapear fácilmente los formatos de registro heredados a este modelo de datos.

• Permitir una fácil traducción de formatos de datos heterogéneos hacia y desde este modelo de datos.

• Garantizar que los formatos de registro convertidos a y desde este modelo de datos tengan significado semántico.

• Permitir una representación eficaz del modelo de datos en implementaciones concretas que requieran almacenamiento o transmisión de datos.

• Para representar 3 tipos principales de registros: aplicaciones de origen, formatos del sistema (por ejemplo, Syslog) y aplicaciones de terceros (por ejemplo, archivo de registro de Apache).

Tipos de registros recogidos por OTel

Veamos brevemente los 3 tipos de registros y eventos que el Modelo de Datos de Registros de OpenTelemetry pretende representar.

• Formatos del Sistema: Son registros generados por el SO. Generalmente tienes un control limitado sobre su formato, a menos que los genere una aplicación que pueda modificarlos.
• Registros de aplicaciones de terceros: Son registros generados por aplicaciones de terceros. Es posible que puedas personalizar su formato, pero normalmente tienes un control limitado sobre ellos.
• Registros de aplicaciones de origen: Son registros generados por tu aplicación. Tienes más control sobre cómo se generan y qué información se incluye. También puedes modificar el código fuente de la aplicación para hacer cambios.

Registros

Un registro de logs proporciona detalles de un evento de la app y contiene dos tipos de campos, que incluyen descripciones del carácter de los logs. Los campos se comentan a continuación.

Campos de nivel superior con nombre

Son campos de tipo y significado específicos. Incluyen campos obligatorios o que aparecen regularmente tanto en los formatos de registro heredados como en los futuros (por ejemplo, Timestamps y TraceIds, respectivamente). La semántica de los campos de nivel superior debe ser idéntica en todos los formatos de registro y eventos conocidos. También debe ser fácil e inequívocamente convertible al modelo de datos de registros de OpenTelemetry.

Campos de recursos y atributos

También llamados pares clave-valor arbitrarios, estos campos se almacenan como “mapa” y ofrecen flexibilidad para la representación del registro. Te permiten definir campos y valores personalizados en los mensajes de registro utilizando convenciones semánticas estandarizadas o arbitrarias. Capturan información específica de las necesidades de la aplicación, como ID de usuario, ID de solicitud y códigos de error.

Los campos se describen en la tabla siguiente.

Estos campos suelen representarse en un registro de log típico, como se ejemplifica a continuación.

Registro de OpenTelemetry: Un ejemplo

Este es el aspecto que podría tener un registro de Log de OTel, siguiendo el modelo de datos de logs y en formato JSON.

 "Timestamp" : "1634630600000",
  "ObservedTimestamp" : "1634630601000",
  "TraceId" : "xyz7890",
  "SpanId" : "ijkl4321",
  "SeverityText" : "INFO",
  "SeverityNumber" : "6",
  "Body" : "A successful request has been processed.",
  "Resource" : {
    "service.name" : "web-backend",
    "host.name" : "web-server-2"
  },
  "InstrumentationScope": {
    "Name" : "JavaLogger",
    "Version": "1.0.0"
  },
  "Attributes" : {
    "http.method": "POST",
    "http.status_code": "200"
  }

Entonces, ¿cómo recogemos estos datos?

Métodos de recogida de datos de registro

Tanto si estás instrumentando un sistema, una aplicación propia o una aplicación de terceros, OpenTelemetry ofrece dos enfoques para la recopilación de datos. Los discutiremos a continuación.

A través de archivo o Stdout Logs

Se trata de un método en el que los registros se escriben en un medio intermedio (por ejemplo, un archivo o stdout). Una ventaja importante de este método es que minimiza la necesidad de cambios en la forma en que se producen los registros y dónde los escribe la aplicación.

El enfoque requiere la capacidad de leer registros de archivos y manejarlos correctamente, incluso cuando se utiliza la rotación de registros. El enfoque también puede requerir opcionalmente la capacidad de analizar los registros y convertirlos en formatos más estructurados utilizando varios tipos de analizadores sintácticos.

Para ello, OpenTelemetry recomienda utilizar el Recopilador o (si éste no puede) otros agentes de recopilación de registros (por ejemplo, FluentBit). Los analizadores pueden configurarse para manejar formatos de registro personalizados o comunes, como CSV, Formato de Registro Común, LTSV, formato de Par Clave/Valor y JSON.

Un inconveniente importante de utilizar el medio intermediario es que requiere la lectura y el análisis de archivos, lo que puede resultar difícil, llevar mucho tiempo y ser poco fiable si el formato de salida está mal definido.

Directo al Recaudador

Este enfoque implica modificar la aplicación para que genere registros a través de un protocolo de red, como OTLP. Esto se puede conseguir cómodamente proporcionando complementos o extensiones para las bibliotecas de registro más utilizadas. Los complementos envían los registros a través del protocolo de red seleccionado. Esto requiere que hagas cambios localizados mínimos en el código de tu aplicación, normalmente centrados en actualizar el objetivo de registro.

Una vez recopilados los registros, el Recopilador los enriquece con contexto de recursos, de forma similar a como se hace con las aplicaciones de terceros. Este enriquecimiento garantiza que los registros tengan información de correlación completa en todas las dimensiones del contexto.

Las ventajas de este enfoque son que reduce las complejidades asociadas a la emisión de registros de archivos (como el análisis sintáctico, la cola y la rotación), emite registros en un formato estructurado y permite que los registros se envíen directamente al backend de registro sin un agente de recogida de registros.

Sin embargo, este enfoque no está exento de desventajas. Elimina de la ecuación los archivos de registro locales, lo que simplifica la lectura de registros locales. También añade un reto de compatibilidad; el backend de registro debe ser capaz de recibir registros de OTLP o de cualquier otro protocolo de red compatible con OpenTelemetry.

Para facilitar los enfoques comentados anteriormente, OpenTelemetry ofrece una Bridge API y un SDK. Estas herramientas pueden utilizarse junto con las bibliotecas de registro existentes para incluir automáticamente el contexto de rastreo en los registros emitidos y simplificar el proceso de envío de registros a través de OTLP. Los anexores de registros utilizan la API para puentear los registros de las bibliotecas existentes con el modelo de datos de OpenTelemetry, y el SDK garantiza el procesamiento y la exportación adecuados de los registros.

La imagen de arriba muestra cómo funcionan los dos enfoques en los registros de aplicaciones heredadas de origen, los registros de aplicaciones de terceros y los registros del sistema. El diagrama siguiente muestra cómo una nueva aplicación de origen utiliza la API de OpenTelemetry, el SDK y las bibliotecas de registros existentes.

Los registros se dirigen a OpenTelemetry Collector a través de OTLP. Al parecer, los registros del Colector de Telemetría Abierto siguen el Modelo de Datos de Registros OTel, lo que facilita el proceso.

Una vez explicada la arquitectura del Modelo de Datos de OpenTelemetry, consideremos por qué y cómo OpenTelemetry mejora las soluciones de registro existentes.

Limitaciones de las soluciones de registro existentes

Las soluciones de registro existentes han facilitado la supervisión y la resolución de problemas de las aplicaciones heredadas. Sin embargo, las siguientes limitaciones las hacen inadecuadas para las aplicaciones modernas.

Volumen de telemetría

Algunas soluciones de registro tienen dificultades para gestionar el gran volumen de registros que generan las aplicaciones modernas. A menudo se ven desbordadas, lo que provoca problemas de rendimiento y retrasos en el procesamiento de los registros, que pueden obstaculizar el proceso de observabilidad.

Integración

Las soluciones de registro heredadas carecen de las integraciones adecuadas o requieren configuraciones adicionales para funcionar sin problemas con los sistemas modernos. Encontrar eventos o patrones de registro específicos e implementar consultas complejas, filtrado y correlación de registros puede ser un reto en las soluciones de registro tradicionales. A menudo, requiere herramientas adicionales (que pueden ser difíciles de integrar) o esfuerzo manual.

Almacenamiento de datos

Estas soluciones de registro tienen limitaciones en cuanto a la cantidad de datos que pueden almacenar o los periodos de retención que pueden admitir. Esto a menudo provoca la pérdida de datos de registro históricos, lo que dificulta el análisis de los eventos de la aplicación o las tendencias de comportamiento a lo largo del tiempo.

Normalización

Los marcos, bibliotecas y aplicaciones de registro pueden utilizar diversos formatos de registro que pueden resultar problemáticos para los equipos de DevOps que tratan de procesar los registros de varios microservicios.

Del mismo modo, la falta de normalización significa que los formatos de registro emitidos por una solución heredada pueden no ser compatibles con una solución de observabilidad preferida. A menudo, tendrías que hacer un esfuerzo adicional para transformar y normalizar tus registros antes de analizarlos.

OpenTelemetry ayuda a superar estas limitaciones con su Modelo de Datos de Registros y su soporte de backend agnóstico de proveedor. De este modo, OpenTelemetry gestiona y facilita la recopilación, normalización y correlación de registros, mientras que el backend que elijas garantiza que puedas interpretar tus registros.

Es importante elegir tu solución de registro en función de su escalabilidad, capacidad de almacenamiento, compatibilidad con formatos de registro, funciones de búsqueda y análisis, capacidad de supervisión en tiempo real e integración con otros sistemas de supervisión.

La buena noticia es que nuestro marco de observabilidad, Middleware, las ofrece al tiempo que aborda las limitaciones de las soluciones de registro heredadas. La plataforma funciona a la perfección con OpenTelemetry y sus modelos de datos telemétricos, y tiene una serie de características que la diferencian de otras soluciones de registro.

• El middleware combina y correlaciona métricas, registros y trazas en una plataforma unificada para el análisis de la causa raíz y la visibilidad de principio a fin del estado de tus aplicaciones.

• Está construido sobre una infraestructura escalable que puede manejar grandes tasas de ingestión de datos y procesar registros en tiempo real.

• Ofrece potentes funciones de procesamiento de registros, que te permiten realizar análisis avanzados, filtrado y consultas de búsqueda en tus datos de registro.

• El middleware te permite configurar alertas inteligentes, en las que defines umbrales, patrones o condiciones específicas para activar alertas cuando se produzcan determinados eventos de registro. Esto garantiza una notificación proactiva, reduce la fatiga de las alertas y facilita la rápida solución de los problemas.

Middleware: Una plataforma de observabilidad de pila completa basada en telemetría abierta

Middleware es una plataforma integral de observabilidad construida para analizar la telemetría recogida de OTel. Proporciona pantallas de monitorización de registros para una visibilidad de extremo a extremo de tus aplicaciones.

• Para empezar con Middleware, crea una cuenta.
• Una vez que hayas iniciado sesión, aparecerá el panel de control de la Observabilidad Unificada del Middleware. El panel proporciona una visión general de alto nivel de la salud, el rendimiento y las métricas clave de tu sistema.

• La pantalla siguiente muestra los numerosos marcos con los que Middleware se integra perfectamente, incluido OpenTelemetry. Los iconos OTel de la pantalla son para métricas y registros.

• Middleware ofrece una sección dedicada a la supervisión de registros -el icono de la parte izquierda de la pantalla- que te permite ver y analizar tus datos de registro de forma centralizada e intuitiva.

• Cuando hagas clic en el icono de los registros, tendrás la siguiente pantalla.

Dentro de esta sección, encontrarás las opciones de filtro de registro, que te permiten filtrar los mensajes de registro en función de criterios específicos como la marca de tiempo, el nivel de registro, palabras clave o atributos personalizados. En la parte superior izquierda están los niveles de registro. Al marcar la casilla de cada “nivel”, Middleware mostrará los mensajes del nivel seleccionado.

• Puedes analizar más a fondo tus registros haciendo clic en mensajes individuales. Cuando hagas clic en el primer mensaje de registro, verás la siguiente pantalla.

En esta pantalla, verás el registro de log con los campos obligatorios y sus valores, que incluyen cuerpo, marca de tiempo y gravedad, entre otros.

• Encima de los campos, cuando hagas clic en “Registros de origen”, encontrarás un análisis más refinado con marcas de tiempo detalladas de los eventos. Esta sección te permite centrarte en flujos de registro, fuentes o atributos específicos, lo que te permite comprender contextos de registro concretos y solucionar problemas con eficacia.

• Por último, en la pantalla de inicio, cuando navegues a “ver panel” y luego a “panel unificado”, encontrarás tus registros, métricas y trazas correlacionados en una sola página. Esta página unificada también te permite visualizar patrones de registro, tendencias y anomalías mediante tablas y gráficos interactivos.

Además, la plataforma te permite configurar alertas inteligentes basadas en registros, que se envían a través de varios canales, como Slack o Microsoft Teams, para notificarte cuando se producen eventos de registro específicos. Puedes configurar reglas de alerta basadas en patrones de mensajes de registro, niveles de registro o atributos específicos.

Aprovechando el conjunto de potentes funcionalidades de visualización y análisis de registros de Middlewarepara tus aplicaciones instrumentadas con OpenTelemetry, puedes identificar y resolver problemas de forma proactiva, lo que se traduce en una mejor calidad del software y experiencia del usuario.

PREGUNTAS FRECUENTES

Los registros pueden recopilarse mediante Registros de Archivo o Registros Stdout, enviados directamente al Recopilador, dependiendo de los requisitos de tu aplicación y de tus preferencias. Ambas opciones tienen sus pros y sus contras.

Mientras que los registros capturan eventos y mensajes discretos, los eventos capturan el contexto de las operaciones, incluyendo el tiempo y las relaciones causales entre los distintos componentes de una aplicación.

Telemetría es un término más amplio que engloba registros, métricas y trazas, mientras que los registros se refieren específicamente a mensajes o eventos capturados que representan el estado y la ejecución de una aplicación.