Registro de OpenTelemetry: una introducción

El registro de OTel ofrece a los equipos de TI una estructura de mapeo unificada e inequívoca para convertir datos de registro de diferentes fuentes, sistemas y formatos en un único modelo independiente del idioma, al tiempo que conserva los significados semánticos originales.

Con un modelo de datos estructurados e independiente del proveedor, las herramientas de observabilidad pueden analizar logs de forma más fácil y fiable, anexar metadatos y correlacionar logs con métricas y trazas para una visibilidad profunda y completa.

El registro de OTel permite a las empresas cambiar y mezclar backends de observabilidad sin volver a instrumentar toda la arquitectura de TI, por lo que se ha convertido en el estándar de la industria para la instrumentación en sistemas modernos nativosde la nube. Estas capacidades ayudan a los equipos de TI y a los ingenieros de confiabilidad del sitio (SRE) a evitar las brechas de observabilidad y los problemas de fragmentación de datos que ocurren cuando cada proveedor, pila y dispositivo tiene su propio esquema de registro y protocolos de transmisión.

El registro de OTel también facilita la correlación automática entre señales, lo que mejora drásticamente la depuración y reduce la observabilidad del proveedor de bloqueo.

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 (API) independientes del proveedor y otras herramientas para la 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 de funcionalidad dificultaba (y, a menudo, imposibilitaba) que los equipos recopilaran datos de diferentes lenguajes de programación, formatos y entornos de tiempo de ejecución.

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

Si, por ejemplo, un equipo de desarrollo quisiera cambiar las herramientas de backend, tendría que reinstrumentar 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 generaron silos de datos y confusión, lo que dificultó 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. Proporcionaba 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 el monitoreo 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 canalización de observabilidad unificada. Por ejemplo:

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 los campos y la semántica, de modo que los backends puedan interpretar de manera coherente los registros procedentes de diferentes lenguajes y sistemas.

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

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 observada (cuándo ocurrió el evento y cuándo se vio)

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

• El cuerpo (el mensaje de registro principal, a menudo una cadena corta u objeto JSON)

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

• Información de recursos que identifica el servicio emisor y el entorno de despliegue

• 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 estructurales que imponen convierten los logs de diferentes servicios y tecnologías en entidades de telemetría ricas y consultables que se ven y se comportan igual cuando entran en la cadena de observabilidad. Los modelos de datos de registro permiten a los equipos de TI correlacionar logs con trazas, agruparlos por servicio o usuario y ejecutar los mismos tipos de consultas en todo el entorno de TI, en lugar de tratar con un arreglo de discos de formatos de registro incompatibles.

Y debido a que el modelo de registro es abierto e impulsado por la comunidad, la instrumentación y los pipelines de registro de OTel son portátiles (no están vinculados a un solo producto de software como servicio (SaaS) o agente propietario). Funcionan en todos los marcos y plataformas, lo que es particularmente valioso en entornos de microservicios políglotas.

Un Logger es el objeto que escribe registros de log, similar a las instancias de logger en otros frameworks de logging (como Java y Python). 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.

Diferentes partes de una aplicación o sistema pueden requerir sus propios registradores (por ejemplo, uno para “pago” y otro para “pagos”), pero todos siguen las mismas reglas para generar registros.

Los registradores se obtienen de un proveedor de madera, que es responsable de crear los registradores y configurarlos con la pipeline, atributos y exportadores correctos.​ Cuando el código de software solicita un Registrador, el Proveedor proporciona uno que ya está configurado adecuadamente.

Este diseño permite que las distintas partes de un sistema utilicen diferentes registradores que, no obstante, comparten una configuración común y son gestionados de forma centralizada por el proveedor de registradores. También facilita que los equipos de TI intercambien implementaciones y ajusten el comportamiento de registro globalmente sin modificar cada sitio de llamada.

OTel Collector 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 Ingesta registros de varias entradas, como transmisiones 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 (agregando metadatos de pod de Kubernetes, por ejemplo), el filtrado y el muestreo en registros. Luego, los exportadores dentro del recopilador reenviarán los logs procesados a uno o más destinos.

Los exportadores de registros se encuentran dentro de un OTel Collector o un SDK de aplicación y definen dónde y cómo se entregan los datos de telemetría a los sistemas de 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" descendente. Los consumidores pueden incluir OTel Collectors, soluciones de observabilidad o tiendas de código abierto, por ejemplo.

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

La API de Logs y el SDK de Logs 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 transporta la electricidad.

Las API de OpenTelemetry comprenden un conjunto de funciones a las que recurren las bibliotecas de código y registro para crear entradas de registro uniformes. Esencialmente, la API de registros determina la "forma" que debe tomar un registro para "conectarse" a OTel. La API de Logs ayuda a garantizar que las mismas llamadas a la API funcionen sin importar qué backend de observabilidad o proveedor 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 o cómo se envían. Ahí es donde el SDK de OpenTelemetry, o SDK de registros, entra en escena.

El SDK de Logs toma los logs del endpoint de la API y realiza el trabajo real con ellos. Recibe registros de log, los enriquece (añadiendo, por ejemplo, el nombre del servicio o el entorno), los agrupa por lotes y los prepara para su envío. A continuación, utiliza Exporters para enviar los registros procesados a un Collector o a una plataforma de registros.

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

En lugar de que los desarrolladores de software llamen directamente a la API de registros, pueden configurar su marco de registro existente para usar un appender que transforma cada evento de registro tradicional en un registro de 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 seguimiento está activo, un puente de registro o SDK puede adjuntar automáticamente el ID de seguimiento actual y el ID de tramo a cada registro emitido.

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

Otel habla de “tipos” de log de diferentes maneras: por estructura, por fuente y por codificación o protocolo de transmisión.

Los logs estructurados tienen un esquema consistente, los mismos campos, con nombres y tipos de datos estables, por lo que las herramientas de observabilidad pueden analizar y consultarlos de manera confiable. 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 análisis y normalización adicionales antes de que los equipos puedan analizarlos de manera efectiva.

Los registros no estructurados son mensajes de texto de formato libre sin un esquema estable (como declaraciones de impresión 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 de la infraestructura son generados por los sistemas operativos, los dispositivos de red, los servicios de infraestructura en la nube y otros componentes de la plataforma, y no por el código de las aplicaciones. Capturan eventos, como errores del sistema operativo, problemas de red y estado de la infraestructura, para ayudar a los equipos a comprender el estado y el rendimiento del entorno subyacente.

Los registros de aplicaciones de origen provienen de servicios y aplicaciones internos, generalmente a través de un SDK de OTel, una biblioteca de registros, un sidecar (un segundo contenedor de aplicaciones que se ejecuta junto con el contenedor principal y utiliza los mismos recursos) o un agente. Describen eventos comerciales, manejo de solicitudes, acciones del usuario y 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 son generados por los servicios externos, los componentes gestionados y los productos SaaS de los que dependen muchos entornos de TI empresariales (por ejemplo, API y bases de datos externas). OTel puede ingerir estos registros junto con los registros internos para que los equipos de TI puedan ver cómo las dependencias externas afectan el ecosistema.

Los registros de 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 la neutralidad del proveedor y la correlación rápida con rastreos y 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 rastrean archivos o escuchan mensajes de syslog y luego 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 admite CSV, formato de registro común (CLF), LTSV y pares clave-valor. El recopilador analiza estos formatos en el modelo de datos de registro OTel común, por lo que se pueden consultar y correlacionar de la misma manera que los registros OTLP nativos.

Imagine que los SRE ven un aumento en los errores de "fallo de pago" en los paneles de observabilidad para 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 (incluidos el monto del pedido, el recuento de artículos y el ID de seguimiento) para cada registro de 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 específico o una región concreta, con solo consultar 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 enrutados a un proveedor de pago específico. Siguen un seguimiento de todos los registros que comparten ese atributo de proveedor, donde encuentran tiempos de inactividad repetidos. Con esa evidencia, el equipo de TI puede dirigir rápidamente el incidente al propietario correcto e implementar una estrategia de mitigación (por ejemplo, pasar a otro proveedor).

El registro de OTel difiere significativamente del 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 la generación de alertas basadas en patrones de registros. Son herramientas poderosas para la búsqueda de texto y el análisis histórico, pero generalmente examinan los registros de forma aislada de otros datos de telemetría.

Los métodos tradicionales de registro se centran principalmente en el almacenamiento local de mensajes de texto, de modo que los desarrolladores puedan depurar problemas en una sola aplicación o host. Se da por sentado que los usuarios leerán los archivos, los filtrarán y tal vez los envíen a un agregador de registros más adelante. Además, suelen utilizar formatos ad hoc, como líneas de texto sin formato, JSON con una estructura poco definida o patrones específicos de cada marco de trabajo, sin que exista un estándar común para todos los servicios.

Y dado que cada equipo de desarrollo puede elegir sus propios campos y nomenclatura, el análisis entre sistemas resulta un proceso engorroso.

Las herramientas de registro tradicionales no suelen incluir características integradas de correlación o migración, 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 de observabilidad unificado que trata los registros, las métricas y los rastreos como señales interoperables de primera clase gobernadas por convenciones semánticas compartidas. Desde el principio, diseña registros para que puedan correlacionarse y analizarse en sistemas distribuidos, ya que el objetivo es comprender el comportamiento del sistema de principio a fin.

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 alcance y enfoque unificados permiten a los equipos de TI crear flujos de trabajo holísticos de resolución de problemas, donde pueden mover perfectamente entre paneles y tipos de datos para entender fallos complejos y distribuidos.

El registro OTel proporciona registros estandarizados y ricos en contexto que se integran estrechamente con trazas y métricas, haciendo que la resolución de problemas y el análisis sean mucho más efectivos que los enfoques tradicionales. Los beneficios incluyen: