OpenTelemetry: la unificación de logs, métricas y trazas
Actualizado: 2026-05-03
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[1] (OTel) es el proyecto de la CNCF[2] que unifica las tres señales bajo un estándar único, y ha alcanzado madurez suficiente para ser la opción por defecto en proyectos nuevos.
Puntos clave
- Antes de OTel, instrumentar una aplicación requería tres librerías, tres formatos y tres lógicas de configuración; cambiar de backend implicaba reinstrumentar.
- OTel propone una única librería de instrumentación, un único protocolo de transporte (OTLP) y backends intercambiables.
- Trazas son GA desde 2021; métricas son GA desde 2023; logs están en beta pero ya valen para nuevos proyectos.
- El OpenTelemetry Collector es el componente más subestimado: permite cambiar backends sin tocar código de aplicación.
- La recomendación práctica es auto-instrumentación para cobertura básica más manual para spans de negocio críticos.
El problema que resuelve
Antes de OTel, instrumentar una aplicación requería:
- Métricas: librería cliente de 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 se cambiaba de backend, había que reinstrumentar. Si se quería 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
Cada señal tiene madurez distinta:
- Trazas: GA desde 2021. Estable y listo para producción 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.
- Logs: en beta. El estándar está definido, las implementaciones maduran. Para proyectos nuevos ya vale la pena; para migrar 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 y agregar métricas antes de enviarlas — todo en YAML declarativo.
Auto-instrumentación vs. manual
Dos caminos, cada uno con su perfil:
- Auto-instrumentación: agentes que inyectan instrumentación sin tocar código. Para Java (con Javaagent), Python, .NET y Node.js funcionan notablemente bien: se obtienen trazas HTTP, DB y 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 propio.
La recomendación práctica: auto para cobertura básica + manual para spans de negocio críticos.
Integraciones con el stack existente
OTel no obliga a abandonar lo que ya funciona. 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: se pueden complementar logs OTel con pipelines existentes sin conflictos.
Ver el stack Grafana completo en Loki, Tempo y Mimir para observabilidad abierta — OTel como SDK unificado y Grafana como capa de visualización forman una combinación natural. Para el contexto de redes donde las señales se generan, ver Cilium y Hubble y Pixie para K8s.
Cuándo adoptar
Recomendación por tipo de equipo:
- Greenfield: adopta OTel desde el día uno. El coste es idéntico al de 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 estabilicen.
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.
