Cambiar de herramienta de observabilidad en producción duele. Lo sabe cualquiera que haya pasado por ello. OpenTelemetry llegó con la promesa de unificar la recolección de métricas, trazas y registros bajo un estándar abierto, sin atarte a un proveedor concreto. Sobre el papel, suena ideal. En la práctica, adoptarlo implica decisiones que no siempre son evidentes y compensaciones que conviene conocer antes de comprometerse.
Este artículo recorre el estado actual de OpenTelemetry, dónde demuestra su valor en entornos reales, dónde sigue presentando aristas y cómo tomar decisiones informadas según el contexto de cada infraestructura. No es un tutorial de instalación: es una guía para decidir si merece la pena y cómo evitar los errores habituales.
Estado del proyecto en 2026
OpenTelemetry nació en 2019 de la fusión entre OpenTracing y OpenCensus, dos proyectos que intentaban resolver el mismo problema desde ángulos distintos. La consolidación bajo la Cloud Native Computing Foundation (CNCF) fue clave para que la industria convergiera en un único estándar.
A día de hoy, el proyecto ha madurado significativamente respecto a lo que era hace dos años. La especificación 1.0 alcanzó estabilidad completa para las tres señales principales — trazas, métricas y logs — en todos los SDKs principales a mediados de 2025. Esto significa que las APIs no van a romper entre versiones menores, lo que da confianza para invertir en instrumentación sin miedo a rehacer el trabajo cada seis meses.
El proyecto es el segundo más activo de toda la CNCF, solo por detrás de Kubernetes. Cuenta con más de 28.000 contribuidores y el respaldo de empresas como Google, Microsoft, Datadog, Splunk y Elastic. La solicitud de graduación a nivel Graduated se presentó en mayo de 2025 y varias publicaciones oficiales de la CNCF ya lo mencionan con ese estatus.
Más allá de las tres señales clásicas, en marzo de 2026 se anunció que la señal de Profiles (perfilado continuo) alcanzó Alpha público. El profiler eBPF donado por Elastic funciona ya como receiver del Collector, permitiendo capturar perfiles de CPU a nivel de sistema sin modificar el código de las aplicaciones. No es estable todavía, pero marca la dirección: OpenTelemetry aspira a cubrir las cuatro patas de la observabilidad (trazas, métricas, logs y perfiles) bajo un único marco.
También existe la certificación OTCA (OpenTelemetry Certified Associate) de la CNCF, lo que refuerza que el ecosistema ha alcanzado la masa crítica necesaria para ser considerado una competencia profesional verificable.
Por qué OpenTelemetry ganó tracción
El argumento principal es la portabilidad. Instrumentar aplicaciones con OpenTelemetry permite cambiar de backend de monitorización sin reescribir el código de telemetría. En entornos donde la estrategia de observabilidad evoluciona o donde se trabaja con múltiples proveedores, esta flexibilidad tiene valor real. También facilita la migración gradual: es posible enviar datos a varios destinos simultáneamente mientras se valida el nuevo sistema.
Otro punto fuerte es la capacidad de correlacionar señales. OpenTelemetry está diseñado para relacionar métricas, trazas y registros mediante identificadores comunes (trace ID, span ID). Esto reduce el tiempo de diagnóstico cuando un problema afecta a varios componentes distribuidos. En sistemas complejos, poder seguir una petición desde el balanceador hasta la base de datos sin cambiar de herramienta marca la diferencia.
Según datos de una encuesta de Honeycomb en 2025, los equipos que usan instrumentación estandarizada con OTel resuelven incidentes un 28% más rápido que los que dependen de agentes propietarios. La diferencia no está en la herramienta en sí, sino en la consistencia semántica: cuando cada traza lleva el mismo significado en todos los servicios, se dedica menos tiempo a traducir y más a resolver.
Dónde funciona bien en producción
Instrumentación automática: dos enfoques
Existen actualmente dos vías para instrumentar aplicaciones sin modificar (o apenas modificar) el código fuente:
La instrumentación basada en SDK/agentes es la más madura. Para lenguajes con buen soporte — Java, Python, .NET, Go, Node.js —, un agente intercepta las llamadas a bibliotecas conocidas (frameworks HTTP, clientes de base de datos, colas de mensajes) y genera trazas automáticamente. Es especialmente útil en aplicaciones heredadas donde tocar el código fuente es arriesgado o costoso.
La instrumentación basada en eBPF (OBI — OpenTelemetry eBPF Instrumentation) es más reciente y opera a un nivel completamente distinto: se engancha al kernel de Linux para capturar peticiones HTTP, gRPC, consultas SQL y resoluciones DNS sin tocar el proceso ni su código. Es agnóstico de lenguaje porque trabaja a nivel de syscalls y paquetes de red. Grafana donó el proyecto Beyla como base, y en 2026 el SIG de eBPF Instrumentation tiene como objetivo alcanzar una versión 1.0 estable. OBI no reemplaza a los SDKs — captura métricas RED (rate, errors, duration) y trazas básicas, pero no puede añadir atributos de negocio personalizados. El enfoque ideal es combinar ambos: OBI para visibilidad instantánea sin esfuerzo, y SDKs para la instrumentación detallada donde aporte valor.
El Collector como pieza central
El OpenTelemetry Collector es el componente que actúa como punto intermedio entre las aplicaciones y los backends de observabilidad. Su pipeline se compone de tres bloques:
- Receivers: reciben datos en múltiples formatos (OTLP, Prometheus, Zipkin, Jaeger, syslog, entre otros).
- Processors: transforman, filtran, enriquecen o muestrean los datos antes de enviarlos. Aquí es donde se añaden atributos de Kubernetes, se eliminan trazas de health checks o se aplica muestreo por cola (tail sampling).
- Exporters: envían los datos procesados a uno o varios backends simultáneamente.
El Collector se despliega habitualmente de dos formas:
Como agent (un Collector por nodo, tipo DaemonSet en Kubernetes o servicio systemd en máquinas físicas): recoge telemetría local y la envía a un destino central. Tiene la ventaja de añadir metadatos del host automáticamente.
Como gateway (un Collector centralizado que recibe telemetría de múltiples fuentes): permite aplicar procesamiento centralizado, muestreo global y enrutamiento a múltiples backends. En infraestructuras grandes, es habitual combinar ambos: agents en cada nodo que envían al gateway central.
Un detalle práctico que conviene conocer: en nodos con menos de 4 GB de RAM, el Collector puede entrar en OOM durante el shutdown graceful. El memory_limiter processor ayuda, pero necesita margen para funcionar correctamente. Si despliegas en nodos pequeños, ten esto en cuenta.
Más allá de Kubernetes
OpenTelemetry se integra naturalmente con Kubernetes, ofreciendo métricas de contenedores, nodos y servicios. Pero no es exclusivo de entornos cloud native. En servidores Linux clásicos con systemd, el Collector se despliega como un servicio más:
[Unit]
Description=OpenTelemetry Collector
After=network-online.target
[Service]
ExecStart=/usr/local/bin/otelcol --config=/etc/otelcol/config.yaml
Restart=always
User=otelcol
Group=otelcol
MemoryMax=512M
[Install]
WantedBy=multi-user.targetEsto es relevante para quienes administramos infraestructura mixta: no hace falta contenedorizarlo todo para beneficiarse de OpenTelemetry.
Donde aparecen las dificultades
Curva de aprendizaje
OpenTelemetry introduce conceptos propios — spans, contextos, propagadores, samplers, semantic conventions — que requieren tiempo para asimilar. Quien viene de sistemas tradicionales de métricas (Prometheus, Nagios, Zabbix) o de registros centralizados (ELK) necesita un cambio de modelo mental hacia la telemetría distribuida. La documentación oficial ha mejorado mucho, pero sigue siendo densa y orientada a casos de uso específicos. Es habitual que los equipos necesiten experimentar antes de configurar todo correctamente.
Consumo de recursos
Generar trazas detalladas en aplicaciones de alto tráfico implica volúmenes considerables de datos. Una aplicación que atiende miles de peticiones por segundo puede generar millones de spans diarios si no se aplica muestreo. Configurar el muestreo adecuadamente requiere entender los patrones de tráfico y ajustar las tasas según el contexto:
- Muestreo por cabecera (head sampling): se decide al inicio de la traza si se registra o no. Sencillo de implementar pero incapaz de capturar selectivamente errores o latencias altas que aparecen al final.
- Muestreo por cola (tail sampling): se decide al final de la traza, cuando se conoce el resultado. Más inteligente pero requiere que el Collector almacene temporalmente todas las trazas en memoria, lo que complica el despliegue.
Un muestreo demasiado agresivo pierde información valiosa; uno demasiado laxo satura el almacenamiento y encarece la infraestructura. La recomendación es definir desde el primer día qué trazas se conservan siempre (errores, latencias anómalas) y aplicar muestreo probabilístico al resto.
Madurez desigual según el lenguaje
A fecha de 2026, el panorama ha mejorado mucho respecto a 2023-2024. Trazas están estables en todos los lenguajes principales, métricas en la mayoría, y logs progresan hacia estabilidad general. Java, Go, Python, .NET y JavaScript cuentan con implementaciones maduras. Sin embargo, lenguajes menos comunes o frameworks nicho pueden tener soporte incompleto o experimental. Antes de comprometerse, conviene verificar la matriz de cumplimiento de la especificación (specification compliance matrix) en el repositorio de OTel para las tecnologías concretas que se usan en producción.
Propagación de contexto
Para que las trazas distribuidas funcionen, cada servicio debe propagar el contexto a las llamadas salientes mediante las cabeceras W3C Trace Context. Si un servicio intermedio — por ejemplo, un proxy escrito en PHP o un componente legacy que no soporta la propagación — no pasa estas cabeceras, la traza se rompe ahí. En lugar de ver una traza completa desde el frontend hasta la base de datos, se ven dos fragmentos inconexos sin relación aparente. Esto es especialmente frecuente en arquitecturas heterogéneas donde conviven múltiples lenguajes, frameworks o componentes de terceros.
Integración con herramientas existentes
Si la infraestructura ya usa herramientas consolidadas (Prometheus para métricas, ELK para logs, un APM comercial para trazas), añadir OpenTelemetry puede generar redundancia. Mantener dos sistemas en paralelo durante la migración consume recursos y complica el diagnóstico cuando algo falla. La transición requiere planificación: definir qué señales se migran primero, cuánto tiempo coexisten ambos sistemas y cuándo se retira el anterior.
OpenTelemetry frente a agentes propietarios
Es inevitable comparar OTel con los agentes de los principales proveedores: Dynatrace OneAgent, Datadog Agent, New Relic Agent, Elastic APM. No se trata de que uno sea «mejor» que otro — resuelven problemas distintos con filosofías distintas.
Los agentes propietarios suelen ofrecer una experiencia más integrada: descubrimiento automático de servicios, correlación nativa con el backend del proveedor, dashboards preconstruidos y detección de anomalías con IA. A cambio, te atan a ese proveedor: migrar implica reinstrumentar.
OpenTelemetry ofrece independencia a costa de más trabajo de configuración y mantenimiento. No incluye backend, dashboards ni detección de anomalías: solo recolección y transporte de datos. Hace falta elegir y mantener las herramientas de almacenamiento y visualización (Prometheus + Grafana, Jaeger, Tempo, Loki, o un SaaS compatible).
Un dato relevante: según los resultados del tercer trimestre de 2025 de Datadog, más del 35% de sus nuevos clientes empresariales ingestaban telemetría a través de OpenTelemetry Collectors en lugar de agentes propietarios. Su CTO lo describió como «impulso irreversible del ecosistema». Cuando el proveedor que más se beneficia de los agentes cerrados reconoce esto, la tendencia es clara.
Muchas organizaciones optan por un enfoque híbrido: instrumentar con SDKs de OpenTelemetry para generar los datos, pero enviarlos tanto a un backend de código abierto (para métricas y trazas básicas) como a un APM comercial (para análisis avanzado). El Collector facilita esta arquitectura gracias a sus múltiples exporters.
Lecciones prácticas: qué hacer y qué evitar
No intentes instrumentar todo de golpe. OpenTelemetry ofrece muchas capacidades, pero empezar por trazas distribuidas en toda la infraestructura sin experiencia previa suele acabar mal. Empieza con un servicio no crítico, aprende cómo funciona el sistema y extiende gradualmente. La observabilidad incremental reduce riesgos.
No asumas que OpenTelemetry resuelve la observabilidad por sí solo. Es un marco de recolección y transporte, no un backend de análisis. Hace falta una herramienta que almacene, indexe y visualice. Subestimar el esfuerzo de configurar y mantener esos backends — especialmente si optas por soluciones autoalojadas como el stack LGTM (Loki, Grafana, Tempo, Mimir) — es un error frecuente.
Define la estrategia de muestreo desde el día uno. El muestreo adaptativo, que ajusta las tasas según la carga o el tipo de petición, ayuda a equilibrar coste y visibilidad. También es importante definir qué trazas se conservan siempre: errores, latencias por encima de un umbral y peticiones a endpoints críticos.
Cuida la propagación de contexto. Antes de desplegar trazas distribuidas, verifica que todos los servicios en la cadena propagan las cabeceras W3C Trace Context. Un solo componente que no lo haga rompe la visibilidad. Documenta los puntos donde la propagación se interrumpe y prioriza su resolución.
Monitoriza tu propia infraestructura de telemetría. El Collector, los exporters y los backends deben monitorizarse igual que cualquier otro componente crítico. Un sistema de observabilidad que falla silenciosamente es peor que no tenerlo. El Collector expone métricas propias en formato Prometheus que conviene vigilar: colas internas, tasas de descarte y uso de memoria.
Documenta las decisiones de configuración. OpenTelemetry ofrece muchas opciones, y recordar por qué se eligió un processor concreto o una tasa de muestreo específica evita rehacer el trabajo cuando alguien nuevo se incorpora al equipo.
Cuándo merece la pena y cuándo no
OpenTelemetry aporta valor real en estos escenarios:
- Infraestructuras complejas con múltiples servicios distribuidos donde el diagnóstico requiere seguir peticiones a través de varios componentes.
- Organizaciones que buscan independencia de proveedores o que trabajan con múltiples backends de observabilidad simultáneamente.
- Equipos que están migrando de herramientas legacy y quieren una transición gradual sin lock-in.
- Entornos multi-cloud o híbridos donde la consistencia de la instrumentación entre plataformas es crítica.
En cambio, probablemente no compense si:
- La aplicación es monolítica o la infraestructura es pequeña y las herramientas actuales funcionan bien.
- El equipo no tiene experiencia con telemetría distribuida y no hay problemas evidentes de observabilidad. Mejor resolver primero el problema que justifique la inversión.
- Los recursos humanos ya están saturados. El Collector es un componente más que monitorizar, actualizar y escalar. Añadir complejidad puede empeorar la situación.
En estos casos, la recomendación es posponer la adopción y reevaluar cuando el contexto lo justifique. OpenTelemetry no se va a ningún sitio: su estabilidad y masa crítica garantizan que seguirá ahí cuando lo necesites.
Para saber más
Documentación oficial de OpenTelemetry — Cubre especificaciones, guías de instrumentación y ejemplos prácticos para distintos lenguajes. El mejor punto de entrada para empezar.
Documentación del Collector — Configuración detallada con ejemplos de pipelines, processors y exporters.
«Learning OpenTelemetry» de Ted Young y Austin Parker (O’Reilly, 2024) — El libro más actualizado sobre OpenTelemetry, centrado en implementación práctica. Recomendado como primera lectura.
«Observability Engineering» de Charity Majors, Liz Fong-Jones y George Miranda (O’Reilly) — Aborda la observabilidad desde una perspectiva de ingeniería, con énfasis en sistemas modernos. No es específico de OTel pero da el marco conceptual necesario.
Caso práctico CNCF: migración multi-cloud con OTel — Un caso real documentado de unificación de observabilidad en entorno multi-cloud con OpenTelemetry.
Recap de KubeCon Europe 2026 — Estado del arte del proyecto tras la última KubeCon: Collector v1, Profiles Alpha, OBI, y roadmap hacia la graduación.
Repositorio del Collector — Código fuente, ejemplos de configuración y extensiones disponibles.
Especificación y estado de madurez — Tabla actualizada con el estado de cada señal por lenguaje. Consulta obligatoria antes de adoptar OTel para un stack concreto.