Logs | OpenTelemetry

The content of this page may be outdated and some links may be invalid. A newer version of this page exists in English.More information ...To see the changes to the English page since this page was last updated: visit GitHub compare 7c0e4db0..c16116598 and search for content/en/docs/concepts/signals/logs.md.
To see the changes to the English page since this page was last updated: visit GitHub compare 7c0e4db0..c16116598 and search for content/en/docs/concepts/signals/logs.md.
Un log es un registro de texto con marca de tiempo, ya sea estructurado (recomendado) o no estructurado, con metadatos opcionales. De todas las señales de telemetría, los logs son la señal de telemetría con más historia. La mayoría de los lenguajes de programación tienen capacidades de logging integradas o librerías de logging muy conocidas y ampliamente usadas.
OpenTelemetry no define una API o SDK a medida para crear logs. En cambio, los logs de OpenTelemetry son los logs existentes que ya tienes de un framework de logging o un componente de infraestructura. Los SDKs y la auto-instrumentación de OpenTelemetry utilizan varios componentes para correlacionar automáticamente los logs con las trazas.
El soporte de OpenTelemetry para los logs está diseñado para ser totalmente compatible con lo que ya tienes, proporcionando capacidades para envolver esos logs con contexto adicional y un kit de herramientas común para parsear y manipular logs en un formato común para muchas fuentes diferentes.
El OpenTelemetry Collector proporciona varias herramientas para trabajar con logs:
El primer paso en la adopción de OpenTelemetry a menudo implica desplegar un collector como un agente de logging de propósito general.
En las aplicaciones, los logs de OpenTelemetry se crean con cualquier librería de logging o con las capacidades de logging integradas. Cuando añades auto-instrumentación o activas un SDK, OpenTelemetry correlacionará automáticamente tus logs existentes con cualquier traza y span activo, envolviendo el cuerpo del log con sus IDs. En otras palabras, OpenTelemetry correlaciona automáticamente tus logs y trazas.
Los logs son una señal estable en la especificación de OpenTelemetry. Para las implementaciones específicas de la API de Logs y el SDK de cada lenguaje, el estado es el siguiente:
OpenTelemetry no distingue técnicamente entre logs estructurados y no estructurados. Puedes usar cualquier log que ya tengas con OpenTelemetry. Sin embargo, ¡no todos los formatos de log son igualmente útiles! Los logs estructurados, en particular, son recomendados para la observabilidad en producción porque son fáciles de parsear y analizar a escala. La siguiente sección explica las diferencias entre logs estructurados, no estructurados y semiestructurados.
Un log estructurado es un log cuyo formato de texto sigue un formato consistente y que las máquinas puedan leer. Para las aplicaciones, uno de los formatos más comunes es JSON:
y para los componentes de infraestructura, el Common Log Format (CLF) se usa habitualmente:
También es habitual que se mezclen diferentes formatos de logs estructurados. Por ejemplo, un log en Extended Log Format (ELF) puede mezclar JSON con un log en formato CLF con datos separados por espacios en blanco.
Para aprovechar al máximo este log, parsea tanto las partes de JSON como las relacionadas con ELF en un formato compartido para facilitar el análisis en un backend de observabilidad. El filelogreceiver en el OpenTelemetry Collector contiene formas estandarizadas de parsear logs como este.
Los logs estructurados son la forma preferida de usar logs. Dado que los logs estructurados se emiten en un formato consistente, son fáciles de parsear, lo que los hace más sencillos de preprocesar en un colector de OpenTelemetry, de correlacionar con otros datos y, en última instancia, de analizar en un backend de observabilidad.
Los logs no estructurados son logs que no siguen una estructura consistente. Pueden ser más legibles por humanos y se usan a menudo en el desarrollo. Sin embargo, no es preferible usar logs no estructurados para propósitos de observabilidad en producción, ya que son mucho más difíciles de parsear y analizar a escala.
Ejemplos de logs no estructurados:
Es factible almacenar y analizar logs no estructurados en producción, aunque es posible que necesites hacer un trabajo sustancial para parsearlos o preprocesarlos de otra forma para que sean interpretables por máquina. Por ejemplo, los tres logs anteriores requerirán una expresión regular para parsear sus marcas de tiempo y parsers personalizados para extraer de forma consistente los cuerpos del mensaje de log. Esto será típicamente necesario para que un backend de logging sepa cómo ordenar y organizar los logs por su marca de tiempo. Aunque es posible parsear logs no estructurados para fines de análisis, hacerlo puede suponer más trabajo que cambiar al logging estructurado, por ejemplo, a través de un framework de logging estándar en tus aplicaciones.
Un log semiestructurado es un log que utiliza algunos patrones propios y consistentes para distinguir datos de modo que sean interpretable por máquina, pero puede que no use el mismo formato y delimitadores entre los datos de diferentes sistemas.
Ejemplo de un log semiestructurado:
Aunque son interpretables por máquina, los logs semiestructurados pueden requerir parsers diferentes para permitir el análisis a escala.
Las siguientes listas de conceptos y componentes son la clave para el soporte de logging en OpenTelemetry.
Como desarrollador de aplicaciones, la Logs Bridge API no debe ser llamada directamente por ti, ya que se proporciona para que los autores de librerías de logging construyan log appenders / bridges. En su lugar, simplemente usas tu librería de logging preferida y la configuras para usar un log appender (o log bridge) que sea capaz de emitir logs en un LogRecordExporterde OpenTelemetry.
Los SDKs de lenguaje de OpenTelemetry ofrecen esta funcionalidad.
Es parte de la Logs Bridge API y sol