OpenTelemetry en 2023

• OpenTelemetry, que nació en 2019 de la fusión de OpenTracing y OpenCensus, en solo 4 años se consolidó como un estándar de observabilidad que abarca trazas, métricas y logs
• Su estructura central se divide en especificación e implementaciones, y ofrece tanto los criterios de compatibilidad entre vendors como las herramientas reales de instrumentación y recolección
• La especificación de OTEL estabilizó tracing en 2020, métricas en 2021 y logs en 2023, con lo que todas las señales están ahora en estado stable, aunque el soporte de logs todavía varía según el SDK
• OTLP y Collector son la base para enviar y procesar datos de observabilidad en un formato común, y agentes de vendors como Grafana y Datadog también lo implementan
• OTEL amplía su alcance con Collector, Semantic Conventions, OpAMP, OTTL e incluso Demo, y sigue expandiéndose como la base común de la observabilidad neutral frente a vendors

---

La posición actual de OpenTelemetry

• OpenTelemetry, o OTEL, comenzó en 2019 con la unión de OpenTracing y OpenCensus
• Al principio era un proyecto centrado en tracing, pero después de la fusión su alcance se amplió a toda la observabilidad
• Su objetivo es ayudar a las organizaciones a ofrecer telemetría de alta calidad, universal y portable
• Tras 4 años, OTEL ya cuenta con las siguientes bases
  • estándares estables para métricas, logs y trazas
  • un Collector capaz de recibir, procesar y exportar telemetría en cualquier entorno
  • SDKs que permiten instrumentar código en los principales lenguajes
  • estándares adicionales relacionados con Semantic Conventions y la gestión de agentes
• Actualmente, OTEL es el proyecto más activo de la CNCF después de Kubernetes, con contribuidores repartidos entre los principales vendors de observabilidad y un protocolo ya adoptado casi de forma universal entre los proveedores de observabilidad

La estructura de OTEL: especificación e implementaciones

• OTEL se compone principalmente de especificación (specification) e implementaciones (implementation)
• La especificación define cómo capturar, recolectar, procesar y exportar telemetría
  • Es, en la práctica, un estándar común que los vendors deben seguir para ser compatibles con OTEL
• Las implementaciones son las librerías cliente y herramientas que manejan los datos de telemetría
  • Es la parte con la que el usuario final interactúa directamente al instrumentar su código
• La estabilidad del proyecto normalmente se indica por señal
  • En OTEL, una señal se refiere a tipos de datos de telemetría como métricas, logs y trazas
• Los principales subproyectos son los siguientes
  • OpenTelemetry Specification
  • OpenTelemetry SDKs
  • OpenTelemetry Protocol
  • OpenTelemetry Collector
  • Open Agent Management Protocol
  • OpenTelemetry Semantic Conventions

OpenTelemetry Specification 1.24.0

• OpenTelemetry Specification es la base de OTEL y proporciona la API, el SDK y el modelo de datos sobre los que se construyen los demás estándares de OTEL
• La estabilización avanzó por señal
  • septiembre de 2020: tracing stable
  • noviembre de 2021: métricas stable
  • abril de 2023: logs stable
• Actualmente, la especificación de OTEL está en estado stable para todas las señales
• Como la señal de logs recién se estabilizó en 2023, muchos SDKs de OTEL todavía no la soportan

OpenTelemetry SDK y auto instrumentación

• El OTEL SDK ofrece instrumentación del lado cliente basada en la especificación de OTEL
• Cada SDK por lenguaje tiene un nivel de madurez distinto según la señal: métricas, logs o trazas
• Algunos SDKs admiten auto instrumentación (auto instrumentation) dependiendo del lenguaje de programación
  • La auto instrumentación consiste en que el SDK inserta automáticamente señales en el código de la aplicación, sobre todo trazas, reduciendo así la carga de la instrumentación manual
• En lenguajes compilados como go y rust, la auto instrumentación no funciona
• Aun así, fuera del SDK se puede obtener inyección automática de trazas usando herramientas basadas en eBPF o service mesh

OTLP 1.0 y el estándar de transporte de datos

• OTLP es un protocolo wire común para transportar datos de observabilidad
• Hay dos métodos oficiales de transporte
  • HTTP y Protocol Buffers
  • gRPC
• Esta especificación se considera stable y puede implementarse en cualquier servicio que reciba, procese y exporte datos de OTEL
• OTLP es implementado por OpenTelemetry Collector, y también por agentes de vendors de observabilidad como Grafana y Datadog

OpenTelemetry Collector 0.83.0

• OTEL Collector es un agente neutral frente a vendors para recolectar, transformar y enviar datos de observabilidad
• Collector está compuesto por los siguientes componentes
  • receivers: reciben datos desde múltiples fuentes mediante push/pull
  • processors: transforman, filtran, enriquecen y derivan los datos en tránsito
  • exporters: envían los datos a destinos downstream
  • connectors: actúan tanto como receiver como exporter y enlazan varios pipelines
  • pipelines: cadenas compuestas por receiver, cero o más processor y exporter
  • extensions: proporcionan funciones ajenas al procesamiento de telemetría, como basic auth o health check
• En conjunto, estos componentes funcionan como un pipeline de observabilidad que permite recolectar telemetría desde cualquier fuente, procesarla en tránsito y enviarla al destino deseado
• Collector se divide en dos proyectos
  • otel-collector: incluye solo los componentes centrales de Collector y contiene principalmente la lógica directamente relacionada con el procesamiento de datos OTLP
  • otel-collector-contrib: es un paquete de integraciones que incluye exporters y receivers para la mayoría de los proveedores de observabilidad
• Al momento de escribir esto, otel-collector-contrib incluye 91 receivers, 48 exporters y 24 processors
• Se recomienda que los usuarios finales usen OpenTelemetry Collector Builder para crear una build personalizada de otel-collector-contrib con solo los componentes necesarios
• Vendors como AWS y Splunk también ofrecen sus propias distribuciones de OTEL

OpAMP y la gestión remota de agentes

• OpAMP es un protocolo de red para la gestión remota de agentes
• Es un estándar relativamente nuevo, añadido a OTEL en 2022, que ofrece una forma neutral frente a vendors de controlar un conjunto de agentes
• Lo que se administra puede ser una instancia de otel-collector o un agente propietario de algún vendor que implemente OpAMP
• Con OpAMP se pueden habilitar las siguientes funciones
  • despliegue dinámico de configuración
  • actualización de agentes
  • gestión de credenciales
• Actualmente, la implementación en Go de la especificación OpAMP está en desarrollo

Semantic Conventions y proyectos adicionales

• OTEL Semantic Conventions define un conjunto común de atributos usados en los datos de observabilidad
• Su alcance incluye recursos cloud, bases de datos, excepciones y sistemas
• Semantic Conventions es usado por los SDKs de OTEL, y en los SDKs con soporte de auto instrumentación se aplica automáticamente
• Una semántica común permite correlacionar señales distintas entre sí
• También existen otros componentes importantes dentro de OTEL
  • OpenTelemetry Transformation Language (OTTL): un lenguaje común de transformación para telemetría, diseñado e implementado en otel-collector-contrib con foco en rendimiento y flexibilidad
  • OTEL Demo: un sitio de compras basado en microservicios que muestra las capacidades de OTEL y de la mayoría de sus SDKs por lenguaje

4 años de cambios

• OTEL nació de la fusión de especificaciones de tracing que competían entre sí y evolucionó hasta convertirse en un estándar de la industria para observabilidad
• Los últimos 4 años fueron el período en el que se construyó una base común entre vendors y herramientas

[GN⁺]

Opiniones en Hacker News

• OpenTelemetry tiene dos problemas

  1. Su identidad no está clara. No queda claro si es un estándar semántico, un protocolo, una fachada, una biblioteca, ni qué capa de abstracción ofrece; la respuesta se acerca a “todo lo anterior”
  2. Del lado de OpenTelemetry parece que no hubiera nadie que realmente haya instrumentado bibliotecas. Tampoco hay recomendaciones sobre cómo debería usar un instrumentador métricas, trazas y logs, si debería usar las tres cosas o solo una. Lo pregunté hace 2 años, pero no recibí respuesta: https://github.com/open-telemetry/opentelemetry-specificatio...
  • Estoy de acuerdo. Es como darte el fregadero y una casa pegada a él todo junto, así que la documentación termina siendo escasa y confusa
    De forma similar, quería implementar un heartbeat sencillo para entender el uso en una app de escritorio, pero, considerando el nombre del proyecto, sorprendentemente era casi imposible. Hubo poca respuesta a las preguntas, así que abandoné por completo el plan de usar OpenTelemetry: https://github.com/open-telemetry/community/discussions/1598, https://github.com/open-telemetry/semantic-conventions/issue...
  • Estoy de acuerdo. Algunas de las cosas que recomienda OpenTelemetry no son posibles con el SDK real
    Por ejemplo, no se pueden definir buckets cerca del lugar donde se define un histograma. Hay que pasar a algún lugar como un exporter global una lista de “overrides” que mapean nombres de histogramas a buckets. Si hay una biblioteca que emite métricas, se vuelve muy desordenado: https://github.com/open-telemetry/opentelemetry-go/issues/38...
  • Son buenas preguntas, pero no las veo muy importantes. Estas preguntas son difíciles de responder con claridad en el área de la observabilidad, ya sea con OpenTelemetry o con otro sistema propietario
    Incluso al mirar los sitios web de las principales empresas de observabilidad, los textos sobre instrumentación personalizada ocupan unas 4 páginas y solo cubren cosas muy básicas. OTel no está particularmente atrasado; la respuesta suele ser, en general, “depende”. Con más experiencia, estas partes que confunden a los principiantes también se pueden ir resolviendo
  • Lo único necesario era mantener 3 archivos de esquema JSON
  • La tercera pregunta es si tiene extensibilidad

• Me gusta mucho OpenTelemetry y quiero rastrear casi todos los spans. Si hubiera usado algún vendor, habría quebrado por los costos
  Con instrumentación automática de Java incorporé OpenTelemetry casi sin esfuerzo, y lo envío a ClickHouse autohospedado, donde almaceno más de 700 millones de spans al día en una EC2 de 100 dólares: https://clickhouse.com/blog/how-we-used-clickhouse-to-store-...

  • En un proyecto personal pequeño estoy enviando trazas/logs/métricas a ClickHouse mediante SigNoz. Son alrededor de 400 mil a 800 mil spans al día (https://i.imgur.com/s0J6Mzo.png), y en una sola t4g.small la CPU normalmente está en 11% y las IOPS en 4%
    Con una retención de 1 mes de trazas, signoz_index_v2 tiene 26.9 millones de filas y 17.06 GiB, trace_log tiene 123 millones de filas y 2.64 GiB, y samples_v2 tiene 949 millones de filas y 345 MiB, así que la compresión es buena. Si hubiera usado una máquina ClickHouse con las especificaciones recomendadas, habría reducido el tiempo de tuning, pero aun así funciona bien
    La desventaja es que las IOPS del disco sc1 pequeño rondan 4, por lo que ClickHouse tarda unos 5 minutos en iniciar, y aunque la UI de SigNoz tiene funciones suficientes, es difícil esperar el nivel de pulido de Datadog
  • Conviene tener una tasa de muestreo, pero asegurarse de enviar todos los errores
    En un trabajo anterior solo recolectábamos el 5% de las trazas que no eran errores
  • Siendo realistas, la mayoría no quiere operar su propio almacenamiento ClickHouse, y no todos los ingenieros manejan SQL con tanta eficiencia como el código. Aun así, es una configuración bastante genial
  • También es genial que el esfuerzo de configuración haya sido bajo. Es la combinación de instrumentación automática de Java + exporter de ClickHouse + plugin ClickHouse de Grafana

• OpenTelemetry me decepcionó bastante. En mi experiencia, es un amasijo confuso y sobrediseñado, y la experiencia de uso básica es muy hostil para el usuario.
  Se promociona a sí mismo como un formato universal de tracing/métricas/logs y como un conjunto de librerías plug-and-play con adaptadores para todo lo necesario, pero en la práctica se parece más a un conjunto de librerías a medio hacer, con muchas filtraciones de la implementación interna, adaptadores de mala calidad y no tantas funcionalidades.

  • Estoy de acuerdo. Cada vez que uso el SDK siento que tengo que pensar de una forma ortogonal al sentido común. Nada funciona como uno esperaría, todo tiene tres capas de abstracción innecesarias y hay que entrar por la puerta trasera.
    Muchas funciones vienen con pistas del tipo cuándo, dónde, cuánto, en qué fase de la luna, cuando Júpiter sea visible en el cielo y con qué longitud de string funcionan.
    Aun así, si se ignoran las APIs del SDK con abstracciones que se filtran y las funcionalidades implementadas a medias, cumple en cierta medida la promesa de intercambiabilidad. Antes de OTel todo era un stack propietario, pero ahora puedes esperar conectar otro backend de logging a un SDK estándar y que, en general, funcione. Es peor que un stack verticalmente integrado, pero desde el punto de vista de arquitectura es una victoria parcial, porque permite competencia y evolución por partes sin tener que rehacer todo el stack de observabilidad.
  • Pasé por el mismo dolor, pero las alternativas que dicen ser mejores porque tienen una especificación OpenAPI tampoco son muy distintas cuando las pruebas: https://github.com/openzipkin/zipkin-api-example
    El ejemplo solo muestra cómo parsear con herramientas de swagger la especificación OpenAPI (https://github.com/openzipkin/zipkin-api/blob/master/zipkin2...), generar automáticamente código pegamento en Go y luego llamar a una función autogenerada para registrar traces.
    No había documentación ni otros ejemplos en absoluto, así que terminé preguntándome si alguien usaba realmente este enfoque, y al final usé directamente la API del servicio (https://zipkin.io/zipkin-api/#/) mediante llamadas REST. OTel es doloroso, pero las alternativas no son mejores. Dado que medir SLO y SLI se está volviendo cada vez más importante, ojalá esta área reciba más atención.
  • Entonces me da curiosidad si puedes recomendar una alternativa o si simplemente soportas OTel.
  • Estaría bueno escuchar experiencias concretas y propuestas de mejora.

• Las librerías oficiales de OTel todavía no funcionan bien en el frontend web. Por ejemplo, en el estado predeterminado no hay forma de vincular errores con sourcemaps.
  El colector para navegadores web que publicó el proyecto OTel usa Zone.js para interceptar como contexto casi todo en el navegador. Si has usado Angular moderno, sabrás que Zone.js a veces puede ser bastante doloroso y, al tocar globales, generar comportamientos difíciles de predecir.
  Tampoco conozco un estándar de OTel para cosas como session replay. Muchas plataformas de telemetría, como Sentry, Rollbar y DataDog, lo soportan. A los equipos de backend parece gustarles bastante, y me agrada la característica de los spans de cruzar límites, que permite seguir todo el sistema con una etiqueta única. Dicho eso, los payloads generados a veces son muy verbosos, y algunas plataformas de logging son más compactas. En la práctica no lo he sentido como un gran problema.

  • En un entorno con Promise nativas y async/await, parece que actualmente no hay forma de implementar bien algo como Zone.js.
    También probé instrumentación manual, pero era propensa a errores y verbosa. El navegador realmente necesita algo como https://nodejs.org/api/async_context.html#class-asynclocalst....
  • En la mayoría de las plataformas, Otel se sintió más como un punto de partida para construir una buena librería de instrumentación.
    En nuestro paquete, sobre la implementación del SDK de navegador de Otel/Splunk agregamos session replay, mejor seguimiento de excepciones, etc. Lamentablemente, estas cosas están lejos de venir incluidas por defecto. Aun así, creo que poder vincular sesiones de frontend con traces/logs de backend cambió mucho la experiencia de desarrollo: https://www.hyperdx.io/blog/browser-based-distributed-tracin...
  • También vale la pena ver esta documentación de Otel: https://opentelemetry.io/docs/instrumentation/js/getting-sta...
    No resuelve el problema por completo, pero sirve como punto de partida.
  • Real User Monitoring, la instrumentación frontend de DataDog, tampoco se ve especialmente pulida. Tiene la delicadeza de manipular bloques Duplo.
    Me pregunto si alguien ha empezado siquiera un poco con tracing frontend.
  • Me pregunto si has visto Grafana Faro. Se puede hacer que envíe a Grafana Agent, y Grafana Agent es open source y puede almacenar traces en otro lugar.

• A algunos colegas y a mí se nos ocurrió una idea algo descabellada: que ya no necesitamos logs. En vez de mensajes de log, basta con adjuntar eventos de span: https://opentelemetry.io/docs/instrumentation/ruby/manual/#a...
  Luego solo dejaríamos en el log el título del span y el enlace al span correspondiente en Jaeger. Solo lo probé en un proyecto personal, pero me pareció bastante bien; eso sí, ojalá la UI de Jaeger diera mejor soporte a este tipo de uso.
  De hecho, esos colegas dieron una charla sobre este tema. Si estás cerca de Hannover, Alemania, busca “Nie wieder Log-Files!” en https://javaforumnord.de/2023/programm/

  • Dependiendo de qué tan greenfield sea el proyecto, quizá ni siquiera necesites eventos de span, salvo en casos donde solo necesitas el timestamp de una operación concreta y no su duración.
    Usar spans para todas las operaciones significativas se parece a usar logs estructurados más potentes. Es difícil en muchos sistemas que tienen que arrastrar logs existentes, pero si es suficientemente greenfield, lo recomiendo.
  • Yo también pensé en este enfoque, pero me gusta que con herramientas simples se pueda tener una idea general de qué está pasando.
    Para usar trazas, muchas cosas tienen que funcionar correctamente. O quizá todavía me falta experiencia y por eso las herramientas me dan miedo.
  • Esa era la idea del proyecto Veneur de Stripe. Trataba spans, logs y métricas con el mismo formato, y hacía rollup de la cardinalidad “automáticamente” según fuera necesario.
    Cuando vi una charla hace algunos años me pareció genial, pero pensé que sería muy difícil convencer a desarrolladores que no fueran SRE: https://github.com/stripe/veneur
  • Ni siquiera hace falta enviar las trazas a ningún lado. Puedes conservarlas dentro del proceso y construir una API sobre esos datos de trazas en memoria.
  • Estamos hablando de lo mismo en la empresa. Tiene bastante sentido, y creo que incluso podríamos eliminar casi por completo los logs.

• OpenTelemetry es un proyecto impulsado por marketing; parece diseñado de forma ingenua e ineficiente por comité, con el objetivo principal de permitir que los CTO de Fortune X00 marquen una casilla en sus documentos de roadmap estratégico.
  No es algo que deba usar alguien que tenga opción.

  • Los demás comentarios de este hilo son en general favorables o muy positivos; me gustaría escuchar con más detalle qué es lo que concretamente no te gusta.
  • Como fundador de highlight.io, desde el punto de vista del consumidor he visto mucho valor en OTEL. Lo usamos para ampliar el soporte de lenguajes para varios clientes, y la comunidad fue muy receptiva.
    Aquí hay un ejemplo de un cambio que subimos: https://github.com/open-telemetry/opentelemetry-js/pull/4049
    Me gustaría que compartieras por qué crees que nadie debería usarlo.
  • No creo que esa evaluación sea correcta. Más bien me parece algo como: “el software open source emite métricas de Prometheus y trazas de Jaeger, pero nosotros queremos vender un producto propietario que sea una alternativa, y no queremos enviar parches a todos los proyectos”.
    Datadog de hecho puso a mucha gente a gran escala a agregar soporte para Datadog en proyectos OSS. Meterse en codebases desconocidas es una habilidad poderosa, así que incluso pudo haber sido bastante bueno al inicio de una carrera.
    OTel hace que los proyectos open source usen una capa de abstracción, de modo que los usuarios puedan comprar en vez de autohospedar. No me encanta, pero si se trata de un servicio operado por gente fuera de la empresa, ahora consideraría OTel. Porque así no bloqueamos a un usuario que quiera usar Datadog.
    Cuando usé OTel muy al inicio, la API de Go era muy ineficiente y me decepcionó. Para incrementar un contador necesitaba context.Context, y la abstracción también tenía fugas, por ejemplo no había forma de configurar los buckets de histogramas al exportar a Prometheus. Supongo que ahora ya lo habrán corregido.
  • Es demasiado duro. Creo que el modelo de datos es un avance en la dirección correcta.
    El procesador también es bastante capaz, y el conjunto contrib de receivers y exporters en general está bien. No digo que sea la mejor solución, y depende de cada caso de uso, pero una crítica tan fuerte no me parece justificada. Como referencia, formo parte del equipo de mantenimiento de fluent-bit.
  • Es excelente poder hacer que los servicios hablen OTLP y simplificar la configuración de las aplicaciones para que envíen los datos al colector de OTEL.
    Desde el punto de vista de operaciones, sea cual sea la observabilidad que los desarrolladores agreguen al código, se puede imponer el filtrado de forma centralizada, y las aplicaciones solo necesitan un punto de entrada central con el que comunicarse.
    Como todo emite OTLP, si quieres cambiar a un backend nuevo solo cambias un archivo YAML, sin tener que reescribir la aplicación para dar soporte a un nuevo backend de logging. Antes que volver a la vieja forma de usar librerías de logging específicas de cada vendor, con sus defectos y todo, seguiría usando OTEL 10 de cada 10 veces.

• Odio muchísimo el popup de suscripción de este blog. No hay botón x, así que no queda nada claro que se pueda cerrar sin entregar el correo.
  Debajo del botón de suscripción hay un “continue reading” muy poco intuitivo; no pensé que eso fuera a funcionar, y hacer clic afuera tampoco lo cerraba. Estas cosas deberían mejorar.
  Sobre OpenTelemetry, desde hace tiempo quería probar si ofrece todas las funciones que necesitamos al enviar datos a Datadog. Pero si además de las funciones básicas todavía necesito el agente de Datadog, entonces es una cosa más que administrar y enseñar, y eso me hace dudar.
  Me interesa saber si alguien realmente lo conectó con Datadog. El objetivo no es necesariamente quedar atado a Datadog, pero ahora muchas de nuestras alertas y logs están ahí, así que si primero cambiamos a OpenTelemetry, en teoría más adelante podríamos migrar a otra cosa.

  • Ese popup es una función de medium.com. Coincido en que es muy molesto.
  • Personalmente, la encuesta me pareció peor. Me pidió mi opinión, hice clic en una opción y me recompensó con una ventana de creación de cuenta a pantalla completa.
    Presioné atrás y terminé de vuelta en HN.

• Me pregunto si todavía existe un frontend que no se coma de forma importante los ingresos en términos de costos de personal, infraestructura y licencias.
  Con más de 2,000 solicitudes por segundo, incluso mantener solo los logs es caro.

  • Si aún no lo están haciendo, recomiendo el muestreo de trazas. Datadog APM no me impresionó porque no tiene una configuración barata.
    Nosotros operamos nuestro propio stack de Jaeger con un muestreo de 0.1%, y comparado con Datadog APM el costo es prácticamente despreciable.
    Para métricas y logs, el muestreo no es tan útil, así que no hay una buena respuesta. Si el margen bruto de Datadog es del 80%, como mucho el 20% de lo que pagas son costos de infraestructura; y si el costo de mano de obra es menor que ese 80%, puedes ahorrar mucho operando tú mismo un stack open source. Incluso usando Datadog, tenemos un proyecto cada 3 meses para reducir el uso, así que de todos modos hay que estarlo cuidando constantemente.
  • La respuesta es el muestreo. Basta con muestrear solo el 1% de las solicitudes exitosas y recolectar todos los errores.
    El costo también es un problema, pero puede sorprenderte lo pesada que resulta la observabilidad para el servicio. Usa bastante CPU.
  • Hay que definir qué significa “de forma importante”. En una empresa anterior, ruteábamos las trazas a Cassandra, las almacenábamos en un dominio de AWS Elasticsearch y las visualizábamos con Jaeger.
    También escribí algunas consultas de Elasticsearch para crear reportes básicos que encontraran consultas lentas. Si sigues los tutoriales de OTEL/Jaeger, es una configuración bastante estándar.
    Las trazas eran del orden de cientos por segundo y las recolectábamos todas, sin downsampling. El periodo de retención se podía configurar en 7 días y, cuando me fui, casi no había optimización real. Creo que el costo mensual era de decenas a cientos de dólares.
    Puedes definir el comportamiento del sampler de tracing con variables de entorno configurables en el contenedor. Consulta OTEL_TRACES_SAMPLER en la documentación: https://opentelemetry.io/docs/specs/otel/configuration/sdk-e...
  • La mayoría de los proveedores de observabilidad ya soportan OTEL. El proyecto OSS en el que participo también soporta la recolección con OTEL: https://github.com/grafana/tempo/
  • No sé por qué le están dando downvotes. Nosotros tenemos el mismo dolor, solo que a una escala de 500,000 solicitudes por segundo.
    Actualmente usamos Datadog, pero todos sabemos que es demasiado caro.

• La mayor parte de este hilo trata sobre enviar métricas/logs con OpenTelemetry a trabajos de collectors autohospedados.
  Usar una biblioteca estándar soportada por varias herramientas de collector, como ClickHouse, ya es útil por sí mismo, pero otro beneficio es que la especificación permite propagar trace IDs a través de los límites del sistema.
  Si tanto tú como tus dependencias implementan la especificación de OpenTelemetry, puedes obtener spans que muestran con detalle qué ocurrió durante el recorrido. Por ejemplo, puedes saber si la carga lenta de una página se debió a que la base de datos tuvo que cargar páginas desde disco, o si un span del plano de metadatos de un servicio cloud fue la causa de una latencia alta.

• Estoy muy satisfecho con el avance de OpenTelemetry. Cuando impulsé su adopción hace unos años, los desarrolladores dudaban porque era nuevo y nunca lo habían escuchado; pero cuando lo volví a revisar hace un año, OpenTelemetry estaba por todas partes en nuestros sistemas y el proveedor de logs/tracing que usábamos también estaba migrando hacia eso.