OpenTelemetry Ha Ganado las Guerras de Observabilidad. Ahora Viene la Parte Difícil.
El Problema del Que Nadie Habla lo Suficiente
Estás ejecutando un sistema distribuido en producción. Algo está mal — la latencia se disparó, las tasas de error aumentaron, un usuario está abriendo un ticket de soporte. Tu primer instinto es mirar los logs. ¿Pero qué servicio? Tienes doce. Los logs están ahí, en algún lugar, dispersos en tres pilas de herramientas diferentes dejadas por ingenieros que ya se han ido. Buscas. Cambias. Veinte minutos después encuentras la causa raíz: una consulta a la base de datos que empezó a agotar el tiempo de espera porque una migración de esquema se ejecutó en el host equivocado.
Este es el problema de observabilidad. No las alertas. No los paneles. El problema fundamental: entender qué está sucediendo realmente dentro de tus sistemas cuando las cosas van mal — y cada vez más, antes de que vayan mal. Las tres señales canónicas son logs (eventos discretos), métricas (mediciones numéricas a lo largo del tiempo) y traces (el viaje de una solicitud a través de un sistema distribuido). Antes de OpenTelemetry, recolectar las tres de manera coherente y portátil era genuinamente doloroso.
La Era del Lock-In
Cada proveedor de observabilidad — Datadog, New Relic, Dynatrace, Honeycomb, Jaeger — enviaba su propio SDK. Su propio agente. Su propio protocolo de cable. Si instrumentabas tu servicio Python con el trazador de Datadog y luego decidías evaluar Honeycomb, te enfrentabas a reescribir tu capa de instrumentación. No porque los proveedores fueran maliciosos, sino porque no había un estándar. La capa de recolección de telemetría era el foso.
Esto no era una molestia menor. Significaba que los equipos tomaban decisiones de proveedores temprano, antes de tener suficientes datos de producción para saber lo que realmente necesitaban. Significaba que los equipos de plataforma gastaban ciclos de ingeniería manteniendo múltiples pipelines de telemetría. Significaba que los costos de cambio eran lo suficientemente altos como para que la mayoría de los equipos simplemente no cambiaran — incluso cuando aparecía una mejor herramienta.
De Dónde Vino OpenTelemetry
En 2019, dos proyectos de observabilidad de código abierto competidores — OpenCensus (respaldado por Google) y OpenTracing (un proyecto de CNCF) — se fusionaron en OpenTelemetry. La fusión evitó lo que habría sido una fragmentación dañina del ecosistema. OpenTelemetry se convirtió en un proyecto de CNCF y creció rápido. Por número de contribuyentes, es ahora el segundo proyecto de CNCF más activo después de Kubernetes.
La propuesta de valor era simple: instrumenta una vez, exporta a cualquier lugar. Un SDK por lenguaje. Un protocolo de cable — OTLP (Protocolo OpenTelemetry). Un recolector — otel-collector — para recibir, procesar y exportar telemetría a cualquier backend. Los proveedores compiten en análisis y visualización, no en lock-in de instrumentación.
El Estado de OTel en 2026
La apuesta valió la pena. OpenTelemetry está desplegado en producción en Google, Microsoft, Shopify, Uber y miles de otras organizaciones. Cada backend importante de observabilidad — Datadog, Grafana, Elastic, Honeycomb, Dynatrace, New Relic, Splunk — acepta OTLP de forma nativa. CNCF reporta que OpenTelemetry está en uso en el 83% de las empresas Fortune 500 en alguna capacidad. Eso ya no es un proyecto de nicho. Es infraestructura.
Los SDKs de Go, Java, Python y JavaScript son estables y están bien mantenidos. La auto-instrumentación para frameworks populares — Django, Express, Spring Boot, Rails — funciona de manera confiable. Puedes agregar una sola dependencia, establecer algunas variables de entorno y tener traces fluyendo a tu backend sin tocar el código de la aplicación. Para proyectos nuevos, este es el punto de partida obvio.
Lo Que Realmente Funciona
Los traces son la parte más fuerte de la historia de OTel. La especificación de tracing es madura. Los SDKs son estables. La auto-instrumentación para HTTP, llamadas a bases de datos y sistemas de mensajería cubre las necesidades de instrumentación más comunes. Si estás empezando con OTel hoy, empieza aquí.
El otel-collector es potente y probado en producción. Puede recibir telemetría de docenas de fuentes, aplicar transformaciones, filtrar ruido y distribuir a múltiples backends simultáneamente. Los equipos que ejecutan entornos multi-nube complejos usan el recolector como una capa de enrutamiento de telemetría — exporta todo al recolector, deja que el recolector maneje el enrutamiento del backend.
El ecosistema también ha madurado alrededor del recolector. Los receivers y exporters contrib cubren la mayoría de las fuentes de datos empresariales. El operador para Kubernetes es sólido. Las distribuciones del recolector de los proveedores (como AWS Distro for OpenTelemetry o Grafana Agent) proporcionan builds probados y compatibles con exporters específicos del proveedor preconfigurados.
Lo Que Sigue Siendo Difícil
Los logs solo son estables recientemente en la especificación de OTel. La señal de logging se quedó atrás de los traces y las métricas significativamente, y aunque ahora es estable, el ecosistema no se ha puesto al día por completo. Correlacionar logs con traces usando TraceId y SpanId — que es el objetivo — todavía requiere cableado deliberado en la mayoría de los frameworks. Funciona, pero aún no es de esfuerzo cero.
Las convenciones semánticas de métricas son inconsistentes entre lenguajes. Una métrica nombrada de una manera en el SDK de Java se nombra ligeramente diferente en el SDK de Python. Esto se está abordando, pero lentamente. Los equipos que construyen paneles multi-lenguaje encuentran esta fricción.
La configuración del recolector es compleja. La configuración YAML del otel-collector — receivers, processors, exporters, pipelines — es flexible pero verbosa. A medida que las topologías crecen, terminas con archivos YAML que son genuinamente difíciles de razonar. Aún no hay una gran solución aquí. Algunos equipos usan jsonnet o cue para generar configuraciones del recolector. Otros escriben herramientas de gestión de configuración. Es un problema solucionable, pero es trabajo operativo real.
El muestreo basado en cola (tail-based sampling) es potente pero operativamente pesado. El muestreo basado en cabeza (head-based sampling) (tomar la decisión de muestreo al inicio de un trace) es simple y sin estado. El muestreo basado en cola (tomar la decisión de muestreo después de haber visto el trace completo) te permite mantener el 100% de los traces de error y los traces lentos mientras descartas los rutinarios — pero requiere infraestructura con estado. El procesador tailsampling en el OTel Collector funciona, pero requiere una arquitectura de despliegue cuidadosa para asegurar que todos los spans de un trace dado lleguen a la misma instancia del recolector.
El Problema de Cardinalidad Que OTel No Resolvió
OpenTelemetry facilita agregar atributos a tu telemetría. Eso es una característica. También es un arma de doble filo. Agregar atributos de alta cardinalidad — IDs de usuario, IDs de solicitud, tokens de sesión — a las métricas es un error clásico que causa explosiones de costos en backends que cobran por serie métrica (que son la mayoría).
OTel no te protege de esto. Reenvía fielmente cualquier atributo que adjuntes. La explosión de cardinalidad es un problema del backend, pero OTel es el mecanismo mediante el cual lo creas. Los equipos que adoptan OTel necesitan entender esto temprano: la gobernanza de cardinalidad de métricas no es opcional, es higiene operativa. Usa atributos de alta cardinalidad en spans y logs, donde pertenecen. Mantén las dimensiones de métricas bajas y deliberadamente acotadas.
La Cuarta Señal: Perfilado
OpenTelemetry está trabajando en una cuarta señal de observabilidad: el perfilado continuo. Los datos de perfilado — gráficos de llama de CPU, traces de asignación de memoria — han vivido históricamente en herramientas separadas (pprof, async-profiler, py-spy) sin un formato estándar ni correlación con las otras tres señales.
La señal de perfilado de OTel sigue siendo experimental, pero Grafana, Elastic y varios otros proveedores ya están apostando por ella. El objetivo es el mismo que para las otras señales: un formato estándar, un protocolo de cable estándar, correlación con traces. Cuando se estabilice, cerrará la última gran brecha en la historia de observabilidad de OTel.
Consejos Prácticos para Equipos que Adoptan OTel Hoy
- Empieza con traces. La señal de tracing es la más madura. Usa auto-instrumentación primero — no instrumentes manualmente antes de haber visto lo que te da la auto-instrumentación.
- Elige tu backend antes de configurar el recolector. La configuración del pipeline del recolector depende de a dónde estás exportando. No construyas una topología compleja del recolector antes de conocer tu backend. Un solo exporter está bien para empezar.
- No implementes una topología personalizada del recolector prematuramente. Los endpoints OTLP gestionados de la mayoría de los proveedores son suficientemente buenos para la mayoría de los equipos. El recolector añade sobrecarga operativa. Agrégalo cuando necesites distribución, filtrado o enriquecimiento — no antes.
- Entiende la cardinalidad antes de agregar atributos de métricas. Ten una conversación con quien sea dueño de la factura de observabilidad antes de enviar tu primera métrica personalizada. Define tu conjunto de etiquetas permitidas explícitamente.
- Usa los SDKs, no la API directamente. La API de OTel es el contrato estable; el SDK es la implementación. En el código de la aplicación, depende del SDK. Solo depende directamente de la API si estás escribiendo una biblioteca que no debe forzar una elección de SDK a los consumidores.
La Guerra Está Ganada. El Trabajo No Está Terminado.
OpenTelemetry ha logrado algo genuinamente raro en software de infraestructura: mató el problema del lock-in de instrumentación. Los proveedores compiten en la calidad de su análisis, sus lenguajes de consulta, sus alertas, su UX — no en atraparte en su SDK. Ese es un mundo mejor.
Pero "el estándar ganó" es el comienzo de la historia, no el final. La parte difícil — convenciones consistentes entre lenguajes, configuración accesible del recolector, logs estables, gobernanza de cardinalidad, perfilado — todavía se está resolviendo. Los equipos que adoptan OTel hoy lo hacen en un ecosistema maduro pero aún en evolución. Eso está bien. La base es sólida. Construye sobre ella deliberadamente.