Durante años, observabilidad en sistemas distribuidos significaba tres herramientas separadas: Prometheus para métricas, Jaeger/Zipkin para trazas, Elasticsearch/Loki para logs. Cada una con su agente, su protocolo, su formato. OpenTelemetry (OTel) es el proyecto de la CNCF que unifica las tres señales bajo un estándar único — y en 2023 ha alcanzado madurez suficiente para ser opción por defecto en nuevos proyectos.
El problema que resuelve
Antes de OTel, instrumentar una aplicación requería:
- Métricas: librería para Prometheus, exportar a
/metrics. - Trazas: librería para Jaeger/Zipkin, configurar sampler.
- Logs: librería con formato estructurado, enviar a stdout o backend.
Tres librerías, tres formatos, tres lógicas de configuración. Si cambiabas de backend, tocaba reinstrumentar. Si querías correlación entre trazas y logs, había que implementarlo manualmente.
OTel propone: una única librería de instrumentación, un único protocolo de transporte (OTLP), y backends intercambiables detrás.
El estado de las tres señales en 2023
Cada señal tiene madurez distinta:
- Trazas: GA desde 2021. Estable, producción-ready en todos los lenguajes principales. Integración con Jaeger, Tempo, Datadog, New Relic, Grafana Cloud — trivial.
- Métricas: GA desde 2023. Estable pero con ecosistema de backends todavía en transición. Prometheus no es nativo OTel pero tiene adaptador OTLP receiver desde 2023.
- Logs: en beta. El estándar está definido, implementaciones maduran. Para nuevos proyectos ya vale la pena; para migración de pipelines existentes, esperar 6-12 meses puede compensar.
Arquitectura típica
Un despliegue típico de OTel tiene tres capas:
- SDK instrumentando la aplicación (auto o manual según el lenguaje).
- OpenTelemetry Collector como proxy local o regional — recibe, procesa (sampling, filtrado, enriquecimiento), y exporta.
- Backends recibiendo los datos: Prometheus, Grafana, Jaeger, etc.
El Collector es el componente más subestimado. Permite cambiar backends sin tocar código de aplicación, añadir metadata, aplicar sampling dinámico, agregar métricas antes de enviarlas — todo en YAML declarativo.
Auto-instrumentación vs manual
Dos caminos, cada uno con su perfil:
- Auto-instrumentation: agentes que inyectan instrumentación sin tocar código. Para Java (con Javaagent), Python, .NET, Node.js, funcionan notablemente bien: obtienes trazas HTTP, DB, gRPC out-of-the-box.
- Manual: llamadas explícitas
tracer.start_span(...)en el código. Más trabajo pero captura semántica de negocio que el auto no puede inferir (“procesar_pago” como span).
La recomendación práctica: auto para cobertura básica + manual para spans de negocio críticos.
Integraciones con el stack existente
OTel no te obliga a abandonar lo que ya tienes. Tres integraciones frecuentes:
- Prometheus exporter: el Collector puede exponer métricas en formato Prometheus, así que Grafana sigue funcionando sin cambios.
- Jaeger backend: OTLP → Jaeger nativo. Sin migrar datos históricos, solo redirigir flujos nuevos.
- Promtail/Fluent Bit: puedes complementar logs OTel con pipelines existentes sin conflictos.
Cuándo adoptar
Recomendación por tipo de equipo:
- Greenfield: adopta OTel desde el día uno. El coste es idéntico a cualquier otra librería, y evita migraciones futuras.
- Stack maduro con Prometheus + Jaeger funcionando: migra gradualmente. Instrumenta servicios nuevos con OTel, déjalos enviar a tu backend existente vía exporters. A medio plazo, unifica.
- Sin observabilidad formal todavía: empieza por trazas OTel + Grafana Tempo. Incorpora métricas y logs cuando se estabilice.
Ver también nuestro análisis de cómo escribir alertas que no se ignoren — el diseño de alertas es independiente del SDK, pero OTel facilita tener datos consistentes para alertar.
Conclusión
OpenTelemetry ya no es el futuro de la observabilidad — es el presente. Para proyectos nuevos, es la elección por defecto. Para equipos con infraestructura establecida, la migración gradual es factible sin disrupciones. Lo que queda es decidir cuándo empezar, no si hacerlo.
Síguenos en jacar.es para más sobre observabilidad, SRE y arquitectura cloud-native.
