Información de registro de OpenTelemetry: una introducción

La información de registro OTel ofrece a los equipos de TI una estructura de mapeo unificada y sin ambigüedades para convertir los datos de registro de diferentes fuentes, sistemas y formatos en un modelo único y neutro desde el punto de vista lingüístico, preservando al mismo tiempo los significados semánticos originales.

Gracias a un modelo de datos estructurado e independiente del proveedor, las herramientas de observabilidad pueden analizar los registros de forma más sencilla y fiable, asociarles metadatos y correlacionarlos con métricas y trazas, lo que permite obtener una visibilidad profunda y de extremo a extremo.

El registro de OTel permite a las empresas cambiar y combinar diferentes backends de observabilidad sin necesidad de volver a instrumentar toda la arquitectura de TI, por lo que se ha convertido en el estándar del sector para la instrumentación de los sistemas modernos nativos de la nube. Estas capacidades ayudan a los equipos de TI y a los ingenieros de fiabilidad de sistemas (SRE) a evitar las lagunas en la observabilidad y los problemas de fragmentación de datos que se producen cuando cada proveedor, pila tecnológica y dispositivo tienen su propio esquema de registro y sus propios protocolos de transmisión.

El registro de OTel facilita la correlación automática entre señales, lo que mejora considerablemente la depuración y reduce el vendor lock-in en materia de observabilidad.

Los registros de OpenTelemetry son un componente vital de OpenTelemetry. OpenTelemetry es un marco de observabilidad de código abierto que incluye una colección de kits de desarrollo de software (SDK), interfaces de programación de aplicaciones (APIs) independientes del proveedor y otras herramientas para instrumentación de aplicaciones, sistemas y dispositivos.

El código de instrumentación solía variar mucho, y ningún proveedor comercial ofrecía una herramienta capaz de recopilar datos de todas las aplicaciones y servicios de una red. Esta brecha funcional dificultaba (y a menudo, imposibilitaba) que los equipos recopilaran datos de diferentes lenguajes de programación, formatos y tiempo de ejecución.

Los enfoques tradicionales de observabilidad también hicieron que cambiar la infraestructura y los componentes del backend fuera un proceso que consumiera mucho tiempo y trabajo.

Si, por ejemplo, un equipo de desarrollo quisiera cambiar las herramientas de backend, tendría que volver a instrumentar completamente su código y configurar nuevos agentes (componentes de software que ejecutan tareas automatizadas de compilación y lanzamiento) para enviar datos de telemetría a los nuevos servidores. Los enfoques fragmentados creaban silos de datos y confusión, lo que dificultaba la resolución eficaz de los problemas de rendimiento.

OpenTelemetry representó un avance significativo en las herramientas de observabilidad porque estandarizó la forma en que se recopilan, analizan y transmiten los datos de telemetría a las plataformas de backend. Proporcionó una solución de código abierto (basada en estándares impulsados por la comunidad) para recopilar datos sobre el comportamiento y la seguridad del sistema, ayudando a los equipos a optimizar la monitorización y la observabilidad en ecosistemas distribuidos.

El registro de OpenTelemetry se basa en varios componentes cooperantes que crean, estructuran, transportan y entregan registros de registro como parte de una cadena unificada de observabilidad. Entre ellos se incluyen:

Un registro es una estructura de datos central que representa un único evento de registro en OpenTelemetry. Sigue un modelo de datos estándar que define campos y semántica, por lo que los backends pueden interpretar de forma coherente los registros de diferentes lenguajes y sistemas.

Los registros aparecen como filas estructuradas en una hoja de cálculo que describen un evento y responden a preguntas básicas, como "qué sucedió", "cuándo sucedió esto", "cómo de importante es" y "por qué pasó".

El modelo de datos de registro es la plantilla común que sigue cada registro, en todos los idiomas y sistemas. Define qué campos de nivel superior existen y qué significa cada uno de ellos.

Un modelo típico de datos de registro requiere que los registros incluyan:

• Una marca de tiempo y una marca de tiempo de observación (cuándo ocurrió el evento y cuándo se observó)

• Números y texto de gravedad (también denominados "nivel de registro"), que describen el nivel de gravedad de un evento

• El cuerpo (el mensaje principal del registro, que suele ser una cadena corta o un objeto JSON)

• Atributos, que añaden detalles más detallados sobre cada evento (como detalles de usuario o HTTP)

• Información sobre los recursos que identifica el servicio emisor y el entorno de implementación

• Identificadores de rastreo e identificadores de tramo que vinculan el evento a una solicitud específica (simplifica la correlación de datos)

Los modelos de datos de estructura transforman los registros de diferentes servicios y tecnologías en entidades de telemetría completas y consultables, con el mismo aspecto y comportamiento cuando entran en el canal de observabilidad. Los modelos de datos de registro permiten a los equipos de TI correlacionar registros con trazas, agruparlos por servicio o usuario, y ejecutar los mismos tipos de consultas en todo el entorno de TI, en lugar de lidiar con una serie de formatos de registro incompatibles.

Y dado que el modelo de registros es abierto y está impulsado por la comunidad, la instrumentación y los pipelines de registros de OTel son portátiles (no están ligadas a un único producto de software como servicio (SaaS) ni a un agente propietario). Funcionan en todos los marcos y plataformas, lo que es especialmente valioso en entornos de microservicio políglotas.

Un Logger o registrador es el objeto que escribe registros de información de registro, similar a las instancias de registrador en otros marcos de información de registro (como Python y Java). Cuando una plataforma de observabilidad envía un comando "registrar este error" o "registrar este mensaje de información", está enviando el mensaje a un registrador.

Las distintas partes de una aplicación o un sistema pueden necesitar sus propios registradores de registros (por ejemplo, uno para el "proceso de pago" y otro para los "pagos"), pero todos ellos siguen las mismas reglas a la hora de generarlos.

Los registradores se obtienen de un proveedor de madera, que es responsable de crear los registradores y configurarlos con el pipeline y los atributos y exportadores correctos.​ Cuando el código del software pide un registrador, el proveedor proporciona uno que ya está correctamente configurado.

Este diseño permite que distintas partes de un sistema utilicen diferentes registradores que, aun así, comparten una configuración común y son gestionados de forma centralizada por el proveedor de registradores. También facilita a los equipos de TI el intercambio de implementaciones y el ajuste global del comportamiento de registro sin modificar cada sitio de llamada.

El OTeI Collector o recopilador de OTeI es un servicio independiente que recibe, procesa y exporta datos de telemetría, incluidos registros, de muchas fuentes. Las aplicaciones envían sus registros (y rastreos y métricas) al recopilador, que puede recibir datos en diferentes formatos, estandarizarlos y luego enviarlos a uno o más backends.

Los recopiladores admiten pipelines de registro dedicados construidos en torno a tres subcomponentes principales: receptores, procesadores y exportadores.

Los receptores consumen registros de varias entradas, como flujos de OpenTelemtetry Protocol (OTLP) y archivos de registro de receptores de seguimiento de archivos. Los procesadores realizan operaciones como el procesamiento por lotes, la modificación de atributos, el enriquecimiento de contexto (añadiendo metadatos de pod de Kubernetes, por ejemplo), el filtrado y el muestreo en registros. A continuación, los exportadores del recopilador envían los registros procesados a uno o varios destinos.

Los exportadores de registros se sitúan dentro de un recopilador de OTel o de un SDK de aplicación y definen dónde y cómo se entregan los datos de telemetría a los sistemas backend.

Después de que el SDK de registros crea y procesa un registro, el exportador codifica el modelo de datos de registro en un protocolo o formato específico y envía el registro a un "consumidor" posterior. Los consumidores pueden incluir, por ejemplo, recopiladores de OTeI, soluciones de observabilidad o almacenes de código abierto.

Los exportadores pueden funcionar según los modelos push o pull, y pueden intercambiarse y combinarse para transmitir simultáneamente los mismos registros de registro a diferentes backends sin necesidad de modificar el código de la aplicación. La flexibilidad que ofrecen los exportadores facilita a las empresas la evolución de su arquitectura de observabilidad a medida que cambian los requisitos.

La API de registros y el SDK de registros funcionan como una toma de corriente en una regleta: la API es el tipo de toma de corriente, y el SDK es la regleta que conduce la electricidad.

Las API de OpenTelemetry comprenden un conjunto de funciones a las que llaman las bibliotecas de código y registro para crear entradas de registro uniformes. Básicamente, la API de registros determina la "forma" que debe adoptar un registro para "conectarse" a OTel. La API de registros ayuda a garantizar que las mismas llamadas a la API funcionen sin importar el backend o el proveedor de observabilidad que elija el equipo de TI más adelante.

Sin embargo, la API es solo una interfaz. No puede decidir a dónde van los registros ni cómo se envían. Ahí es donde entra el SDK de OpenTelemetry (o SDK de registros).

El SDK de registros toma los registros del endpoint de la API y realiza el trabajo real con ellos. Recibe registros, los enriquece (añadiendo el nombre del servicio o el entorno, por ejemplo), los agrupa y los prepara para su envío. Luego, utiliza exportadores o Exporters para enviar los registros procesados a un recopilador o a una plataforma de registros.

Los anexores de log, también llamados log bridges, conectan las bibliotecas de registros existentes (como Log4j, SLF4J o marcos similares) al modelo de datos de log OpenTelemetry.

En lugar de que los desarrolladores de software llamen directamente a la API de registros, pueden configurar su marco de registro actual para que utilice un "appender" que transforme cada evento de registro tradicional en un registro OTel.

Los puentes de log también pueden inyectar span y trace context en los registros de log, permitiendo correlación entre logs y traces incluso cuando el propio código de la aplicación no tiene conocimiento de los detalles de trazado.

La propagación del contexto y los mecanismos de correlación son componentes esenciales del registro de OpenTelemetry. Cuando un tramo de rastreo está activo, un puente de registro o SDK puede adjuntar automáticamente el ID de rastreo actual y el ID de tramo a cada registro emitido.

La correlación ayuda a los backends de observabilidad a conectar registros con rastreos distribuidos que representan la misma solicitud o flujo de trabajo. Estas conexiones permiten a los equipos navegar desde una entrada de registro problemática directamente a una traza que muestra la ruta completa de la solicitud. También facilita el análisis de señales cruzadas para métricas, rastros y registros que comparten campos comunes de recursos y contextos.

OTel habla de los "tipos" de registros de varias maneras diferentes: por estructura, por origen y por codificación o protocolo de transmisión.

Los registros estructurados tienen un esquema coherente (los mismos campos, con nombres y tipos de datos estables), por lo que las herramientas de observabilidad pueden analizarlos y consultarlos de forma fiable. Los registros pueden estar codificados con JSON u otro formato, pero lo que los hace estructurados es el conjunto predecible de campos de datos.

Los registros semiestructurados contienen alguna estructura reconocible (pares clave-valor o blobs similares a JSON, por ejemplo), pero el esquema no es coherente a lo largo del tiempo. Son más legibles por máquina que el texto de formato libre, pero requieren un análisis y una normalización adicionales antes de que los equipos puedan analizarlos de forma eficaz.

Los registros no estructurados son mensajes de texto de formato libre sin un esquema estable (como declaraciones impresas ad hoc o registros de servidor de texto sin formato). Son fáciles de escribir y leer para los humanos, pero más difíciles de buscar, correlacionar y agregar para los sistemas automatizados sin un análisis adicional considerable. 

Los registros del sistema y la infraestructura los producen los sistemas operativos, los dispositivos de red, los servicios de infraestructura en la nube y otros componentes de la plataforma, en lugar de mediante el código de la aplicación. Capturan eventos (como errores del sistema operativo, problemas de red y estado de la infraestructura) para ayudar a los equipos a comprender la salud y el rendimiento del entorno subyacente.

Los registros de aplicaciones de origen provienen de servicios y aplicaciones internos, normalmente a través de un SDK de OTel, una biblioteca de información de registro, un sidecar (un segundo contenedor que se ejecuta junto con el contenedor principal y utiliza los mismos recursos) o un agente. Describen los eventos empresariales, la gestión de las solicitudes, las acciones de los usuarios y los errores internos. Se pueden enriquecer con atributos de recursos y alcance de instrumentación (que describe el origen del registro dentro de la entidad que lo generó) para proporcionar una imagen más completa del comportamiento de la aplicación.

Los registros de terceros los emiten los servicios externos, los componentes gestionados y los productos de SaaS de los que dependen muchos entornos de TI empresariales (API y bases de datos externas, por ejemplo). OTel puede consumir estos registros junto con los registros internos para que los equipos de TI puedan ver cómo las dependencias externas afectan al ecosistema.

Los registros OTLP se representan en el modelo de datos OTLP nativo y se envían a través de OTLP gRPC o HTTP. Cada registro está estandarizado para garantizar la neutralidad del proveedor y una correlación rápida con los rastreos y las métricas.

Los registros basados en archivos se escriben en archivos (archivos de registro de aplicaciones o registros de acceso al servidor web), y los registros de estilo syslog son mensajes emitidos mediante el protocolo syslog. OTel suele recopilar estos registros mediante receptores que siguen los archivos o escuchan los mensajes de syslog y, a continuación, los convierte en registros de OTel para un procesamiento unificado.

Los registros HTTP y JSON se entregan a través de HTTP en JSON. OpenTelemetry también es compatible con CSV, Common Log Format (CLF), LTSV y pares clave-valor. El recopilador analiza estos formatos en el modelo de datos de registro OTel común, por lo que pueden consultarse y correlacionarse de la misma manera que los registros OTLP nativos.

Imagine que los SRE ven un aumento de los errores de "fallo de pago" en los paneles de control de observabilidad de un microservicio de pago. Podrían comenzar el proceso de resolución de problemas examinando los registros de OTel, que ya están estandarizados e incluyen atributos estructurados (como el importe del pedido, la cantidad de artículos y el ID de seguimiento) para cada registro de "pedido realizado".

Los ingenieros pueden comprobar rápidamente si los fallos están relacionados con un volumen elevado de pedidos, un método de envío concreto o una región específica consultando los atributos del registro. También pueden alinear la ventana de tiempo entre registros, rastreos y métricas, porque OTel utiliza marcas de tiempo y metadatos de recursos coherentes en todas las señales de telemetría.

Los ingenieros confirman que solo fallan los pedidos dirigidos a un proveedor de pagos específico. Siguen un rastreo hasta todos los registros que comparten ese atributo de proveedor, donde encuentran tiempos de espera de la sesión repetidos. Con esas pruebas, el equipo de TI puede dirigir rápidamente el incidente al propietario adecuado y aplicar una estrategia de mitigación (pasar a otro proveedor, por ejemplo).

La información de registro OTel difiere significativamente de la información de registro tradicional en sus procedimientos de recopilación, estandarización, correlación y transmisión de registros.  

Los sistemas de registro tradicionales se centran en la agregación, la indexación, la búsqueda y las alertas de registros en función de los patrones de registro. Son herramientas potentes para la búsqueda de texto y el análisis histórico, pero suelen examinar los registros de forma aislada de otros datos de telemetría.

Los enfoques tradicionales de registro consisten principalmente en registrar mensajes de texto localmente, para que los desarrolladores puedan depurar problemas en una sola aplicación o host. Suponen que los usuarios leerán los archivos, los filtrarán y quizá los envíen a un agregador de registros en un momento posterior. También suelen utilizar formatos ad hoc, como líneas de texto sin formato, JSON poco estructurados o patrones específicos del marco sin ningún estándar multiservicio.

Y como cada equipo de desarrollo puede elegir sus propios campos y nombres, el análisis entre sistemas es un proceso engorroso.

Las herramientas de registro tradicionales no suelen incluir características de correlación o migración integradas, por lo que la correlación de datos y la Integración con backends de observabilidad requieren procesos manuales y pasos adicionales. Los equipos de TI deben crear convenciones y reglas de análisis personalizadas para unir eventos entre servicios, y la integración de datos de registro en la pila de observabilidad generalmente requiere remitentes personalizados o adaptadores de formato.

El registro de OpenTelemetry forma parte de un marco unificado de observabilidad que trata los registros, métricas y trazas como señales de primera clase e interoperables, gobernadas por convenciones semánticas compartidas. Desde el principio, diseña registros para correlacionarlos y analizarlos en sistemas distribuidos, porque el objetivo es comprender el comportamiento del sistema de extremo a extremo.

Mientras que el registro tradicional depende de la pila y del backend, el registro de OTel es deliberadamente independiente de ellos. Proporciona puentes y anexores para que los marcos de registro existentes puedan emitir datos en formato OTel sin tener que reescribir cada llamada de registro.

Este enfoque y alcance unificados permiten a los equipos de TI crear flujos de trabajo integrales para la resolución de problemas, en los que pueden pasar de un panel a otro y de un tipo de datos a otro de manera fluida para comprender fallos complejos y distribuidos.

El registro de OTel proporciona registros estandarizados y ricos en contexto que se integran a la perfección con las huellas y las métricas, lo que hace que la resolución de problemas y el análisis sean mucho más eficaces que con los enfoques tradicionales. Los beneficios incluyen: