OpenTelemetry funcionó, pero ¿por qué es tan complicado?

• OpenTelemetry (OTel) es un framework y conjunto de herramientas de observabilidad
• Las herramientas existentes incluyen Prometheus (métricas), Logstash (logs) y OpenTracing (trazado distribuido)
• OTel estandariza tres señales: métricas, logs y trazas, y ofrece OpenTelemetry Protocol (OTLP), OpenTelemetry Collector y SDK para varios lenguajes
  • Cumple con todas las palabras de moda: open source, independiente del proveedor, independiente del lenguaje, distribuido, zero code, etc.

Problemas de OTel

• Los logs y las métricas son similares a las herramientas existentes, por lo que se pueden integrar fácilmente. Incluso es posible migrar a OTel solo agregando configuración
• La dificultad de implementar el trazado
  • Context Propagation: es necesario para transmitir información de las solicitudes entre sistemas distribuidos
    • La unidad de una solicitud se divide en Trace y Span
    • Ejemplo: clic en el botón "Comprar" → Frontend → Backend → la relación entre los servicios de Payment/Shipping se expresa como Span
  • Cómo lo soporta OTel:
    • Proporciona varios estándares de Context Propagation (por ejemplo, b3, W3C Trace Context)
  • OTel debe soportar múltiples estándares
    • Al migrar de OpenTracing existente a OTel, se producen conflictos inesperados
    • Lightbend Telemetry soporta logs y métricas de OpenTelemetry, pero no soporta trazado.

Problemas de conflicto entre APIs

Problema de integración entre Spring y Akka

• Spring: se usa para el arranque de aplicaciones y la gestión de configuración
• Akka: se usa para event sourcing, scheduling, clustering y más
• Problema:
  • Al usar OTel, las APIs de trazado de Spring y Akka no interactúan entre sí
  • No pueden compartir el mismo Trace ID → resultados de trazado incorrectos

Solución: OpenTracing Shim

• Herramienta para convertir un OTel Tracer en un OpenTracing Tracer
• Problema:
  • Lightbend Telemetry de Akka no logra ajustarse a la implementación de OpenTracing
  • Jaeger y OTel requieren distintos SpanContext, lo que provoca conflictos

Proceso de resolución

Integración manual de OTel y OpenTracing

• Convertir manualmente OTel Context a Jaeger SpanContext:
  • Insertar el contexto de OTel en un Java Map
  • Extraer ese map en Jaeger SpanContext y configurarlo manualmente
• Ejemplo de código:

  var otelContext = new HashMap<>();  
  GlobalOpenTelemetry.get().getPropagators().getTextMapPropagator()  
      .inject(Context.current(), otelContext, (carrier, key, value) -> carrier.put(key, value));  
  var openTracingContext = new TextMapCodec(false).extract(new TextMapAdapter(otelContext));  
  GlobalExtendedTracer.get().local().activateContext(openTracingContext);  
  

• Resultado:
  • Se logró integrar los datos de trazado entre Spring y Akka
  • Las trazas se conectaron correctamente a través de los límites HTTP

Conclusión

Causa de la complejidad

• Intento de integrar dos librerías de trazado diferentes
• Los estándares que ofrece OpenTelemetry son útiles, pero existe la posibilidad de conflictos con herramientas existentes

El valor de OpenTelemetry

• OpenTelemetry cumple un papel importante en la estandarización de la observabilidad
• Es un proyecto open source complejo pero potente

Tareas futuras

• Es necesario verificar si el Trace Context de Akka se transmite correctamente entre hilos
• Se requieren pruebas adicionales y feedback para mejorar el proyecto

[GN⁺]

Opiniones de Hacker News

• Mientras aprendía y portaba Otel, sentí que había vuelto al mundo de Java. Al explorar el código, se sentía como EnterpriseFizzBuzz y no tenía nada de descubrible. En NodeJS usaba cerca de 4 veces más CPU que StatsD, y redujimos eso con agregación propia. OTEL es hostil para los lenguajes que usan un proceso por núcleo. Es mejor usar Prometheus.

• Otel puede sentirse complejo por los SDK, agentes y API que ofrecen varios proveedores de observabilidad. Terminamos usando OpenTelemetry como estándar, y aplaudo que Grafana haya adoptado OpenTelemetry. El precio de Datadog se volvió incontrolable entre empresas medianas y grandes. La documentación podría ser mejor, y los documentos de onboarding difieren según el lenguaje de programación. Hice un paquete y una pila de ejemplo de Grafana para arrancar rápido con OpenTelemetry en un stack de NodeJS/Typescript.

• Quería soporte para logs, trazas y métricas en desarrollo local, pero no quería ejecutar varias imágenes de Docker. El equipo de .NET lanzó .NET Aspire, y permite visualizar todo fácilmente en el stack de desarrollo local. Al desplegar en k8s, si conectas el endpoint de OTEL al agente de DataDog, todo funciona. Evitamos las bibliotecas de trazado y los SDK personalizados de DataDog y usamos OTEL.

• OpenTelemetry puede ser complejo según lo que necesites. Nuestro equipo lo usa de forma simple, con instrumentación manual para elegir cuidadosamente qué observar. Usamos dos backends: uno es un servicio de terceros barato y el otro es una instalación de Jaeger para desarrollo local.

• Al usar Otel en Python, conviene usar el cliente de Logfire. El cliente hecho por el equipo de Pydantic es mucho mejor y más simple que la biblioteca oficial de Otel.

• Muchos frameworks web manejan automáticamente la mayor parte de la instrumentación. Si usas opentelemetry-js y hospedas tú mismo algo como Signoz, puedes obtener muchos datos en menos de una hora.

• Para facilitar la adopción de OpenTelemetry, inicié un proyecto open source que se puede ejecutar con un solo comando.

• En Python, si usas el stack estándar, puedes rastrear todo automáticamente con solo unas cuantas importaciones. Otel es complejo porque fue diseñado para empresas que venden software compatible con Otel.

• OpenTelemetry empezó con trazas, pero es mejor dejar las métricas y los logs a soluciones especializadas. El intento de poner todo bajo un mismo paraguas se siente como un problema de "abstracción con fugas". Las bases de datos SQL también pueden hacerlo todo al mismo tiempo, pero eso no significa que deban hacerlo.