En 2016, instrumentar un entorno distribuido significaba elegir entre el SDK propietario de un vendor o mantener pipelines frágiles con herramientas open source mal conectadas. Diez años después, ese dilema ha desaparecido. OpenTelemetry se ha convertido en la capa de telemetría que une todo el ecosistema de observabilidad, y 2026 es el año en el que esa afirmación deja de ser una promesa y se convierte en un hecho verificable: APIs estables en los tres pilares clásicos (trazas, métricas y logs), una cuarta señal —profiling continuo— ya en alpha público, casi 28.000 contribuidores, más de 5.300 organizaciones participando en el desarrollo, y un 48,5 % de empresas usándolo en producción según las últimas encuestas del sector. Este artículo repasa qué ha cambiado realmente, qué herramientas del mercado lo están adoptando y qué debe tener en cuenta un equipo de operaciones antes de dar el salto.
Qué es OpenTelemetry y por qué importa (contexto rápido)
OpenTelemetry (OTel) es un proyecto open source alojado en la CNCF que proporciona un conjunto unificado de APIs, SDKs, el protocolo OTLP y un Collector para recopilar, procesar y exportar datos de telemetría: métricas, logs y trazas. Su objetivo es desacoplar la instrumentación del backend, de modo que instrumentes una vez y envíes los datos a cualquier plataforma compatible, sin depender de agentes o formatos propietarios.
Es el segundo proyecto más activo de la CNCF después de Kubernetes. Fue aceptado en 2019, alcanzó el nivel de incubación en 2021 y actualmente tiene abierta la solicitud formal de graduación, con el objetivo de completar la estabilización de todos sus componentes para alcanzar ese hito.
¿Qué ha cambiado en 2026 para hablar de «madurez»?
No se trata solo de versiones y etiquetas. Hay cambios concretos que marcan un antes y un después para los equipos de operaciones:
Las tres señales clásicas son estables en todos los SDKs principales
Trazas, métricas y logs han alcanzado estabilidad en los SDKs de los lenguajes más utilizados: Java, Go, Python, .NET, Node.js, C++, PHP y Ruby. Esto significa que las APIs no van a romper la compatibilidad entre versiones, algo que hasta hace poco era una preocupación legítima para quienes evaluaban OTel en entornos de producción críticos.
Profiling continuo: la cuarta señal
En marzo de 2026, el SIG de Profiling anunció la entrada en alpha público de la señal de profiling continuo. Esto convierte a OpenTelemetry en el primer estándar abierto que unifica las cuatro señales de observabilidad (trazas, métricas, logs y profiles) bajo un mismo SDK y protocolo. Históricamente, la industria carecía de un framework común para profiling en producción, a pesar de que formatos como JFR o pprof llevan décadas en uso. OTel está llenando ese hueco.
Semantic Conventions estables en bases de datos y mensajería
Las Semantic Conventions definen nombres de atributos estandarizados para que toda la telemetría «hable el mismo idioma». En 2026, las convenciones para bases de datos y sistemas de mensajería alcanzaron estabilidad. Además, se introdujo el grupo gen_ai (experimental) para cubrir la instrumentación de pipelines de IA generativa, con atributos como gen_ai.system, gen_ai.request.model o gen_ai.usage.input_tokens. Esto refleja una necesidad real: los equipos están desplegando modelos LLM en producción y necesitan observarlos con el mismo rigor que cualquier otro servicio.
Instrumentación eBPF sin código (OBI)
Uno de los avances más relevantes de 2026 es OpenTelemetry eBPF Instrumentation (OBI), el sucesor del proyecto Beyla que Grafana Labs donó a OpenTelemetry en 2025. OBI permite capturar trazas y métricas RED (Rate, Errors, Duration) directamente desde el kernel de Linux, sin modificar el código de la aplicación, sin reinicios y sin añadir dependencias.
OBI soporta HTTP/HTTPS, HTTP/2, gRPC, PostgreSQL, MySQL, MongoDB, Redis, Kafka, GraphQL, Elasticsearch y otros protocolos. En abril de 2026 se lanzó la versión v0.8.0 como beta en KubeCon EU Amsterdam, con el objetivo de alcanzar la release estable 1.0 a finales de año.
¿Por qué importa? Porque resuelve un problema real: instrumentar servicios legacy, binarios compilados de terceros o entornos políglotas donde añadir un SDK a cada servicio no es viable. OBI funciona como un DaemonSet en Kubernetes y cubre todo un nodo con una sola instancia. No reemplaza la instrumentación manual para lógica de negocio personalizada, pero proporciona visibilidad inmediata con esfuerzo cero.
OpAMP: gestión de flotas de Collectors
OpAMP (Open Agent Management Protocol) permite configurar, monitorizar y actualizar flotas de Collectors de forma remota, sin acceso SSH ni rolling restarts. Los equipos de plataforma están tratando los pipelines de telemetría como infraestructura configurable dinámicamente, no como despliegues estáticos.
Configuración declarativa
La configuración declarativa avanza hacia la estabilización, acercándose a un escenario donde los SDKs de OTel se pueden configurar con ficheros YAML simples en lugar de código. Ya hay implementaciones en diferentes estados de madurez para Java, Go, PHP, JavaScript y C++.
Quién está usando OpenTelemetry: adopción en el mercado
El dato más contundente: un 48,5 % de las organizaciones ya usan OpenTelemetry, y otro 25 % planea implementarlo. Pero más allá de las encuestas, lo relevante es cómo los grandes players del mercado lo están integrando:
Grafana Labs (stack LGTM)
Grafana Labs es probablemente el ecosistema más alineado con OTel. Grafana Tempo (trazas), Loki (logs) y Mimir (métricas) aceptan ingesta OTLP de forma nativa. Grafana donó Beyla a OpenTelemetry para formar OBI, y varios ingenieros de Grafana mantienen activamente componentes del proyecto. Grafana Fleet Management permite gestionar despliegues de Collectors a escala. El Prometheus Receiver del Collector, uno de los componentes más usados, está próximo a alcanzar estabilidad.
Datadog
Datadog ofrece soporte nativo para datos de OpenTelemetry: puedes configurar tu Collector para exportar directamente a Datadog. Sin embargo, hay un matiz importante: internamente convierte los datos a su formato propietario, y sus agentes y bibliotecas cliente siguen siendo custom. Esto significa que si instrumentas con el SDK de OTel y envías a Datadog, funciona; pero si después quieres migrar a otro backend, no tendrás que reinstrumentar la aplicación (que es precisamente la ventaja de OTel).
Dynatrace
Dynatrace integra datos de OpenTelemetry y los enriquece con su motor de IA (Davis) para proporcionar análisis automatizado. Su punto fuerte con OTel es que puede aplicar correlación causal sobre datos ingestados vía OTLP, algo que no todos los backends ofrecen. No obstante, la fortaleza principal de Dynatrace sigue siendo su agente propietario (OneAgent), por lo que OTel actúa más como una vía complementaria de ingesta que como su mecanismo principal.
New Relic
New Relic ha hecho de OpenTelemetry una parte central de su estrategia, con soporte nativo y cumplimiento completo de la especificación. No convierte los datos a formatos propietarios y permite trabajar directamente con la telemetría de OTel en su plataforma. Además, su modelo de precios basado en ingesta de datos y usuarios (con un tier gratuito generoso) facilita la adopción.
Elastic
Elastic Observability ha integrado OTel como mecanismo de ingesta, y contribuidores de Elastic participan activamente en el SIG de Profiling. La combinación de Elasticsearch como backend con datos ingestados vía OpenTelemetry es una opción cada vez más frecuente, especialmente para equipos que ya tienen inversión en el stack ELK.
Proveedores cloud
Los tres grandes proveedores cloud soportan OTel de forma directa: AWS con su distribución ADOT (AWS Distro for OpenTelemetry) integrada en ECS y EKS, Azure Monitor con su exportador OTLP en disponibilidad general, y Google Cloud con soporte de trazas OTel en el Ops Agent y en GKE Autopilot con toggle directo en la UI.
Plataformas y service meshes
Istio y Linkerd exportan telemetría nativamente vía OTLP. Red Hat OpenShift y VMware Tanzu incluyen configuraciones curadas de OpenTelemetry con políticas de seguridad predefinidas para escenarios multi-tenant. Jaeger V2 ha adoptado OpenTelemetry como su framework de telemetría base.
Nuevos players
Plataformas como SigNoz (open source, basado en ClickHouse), Dash0, Uptrace, Coralogix o Middleware han sido construidas directamente sobre OpenTelemetry, ofreciendo alternativas más económicas y con menor lock-in que las plataformas tradicionales.
El impacto real en los equipos de operaciones
Reducción de costes verificable
Los números no son teóricos: un 57 % de las organizaciones reporta reducción de costes tras adoptar OpenTelemetry, con un 46,4 % que declara más de un 20 % de ROI. El caso de STCLab es ilustrativo: migraron al stack LGTM con OpenTelemetry y lograron una reducción del 72 % en costes, pasando de un 5 % de trazas muestreadas a un 100 % de cobertura APM en todos sus entornos.
La razón de fondo es que los modelos de precios de los vendors propietarios penalizan el crecimiento (pricing por host, por métrica, por ingesta), mientras que con OTel la instrumentación es gratuita y eliges dónde enviar los datos.
Eliminación del vendor lock-in
Este es quizá el argumento más potente para un equipo de operaciones. Con OpenTelemetry, instrumentas una vez y puedes cambiar de backend sin reinstrumentar. Esto no solo da libertad para migrar, sino que mejora la posición negociadora frente a los proveedores de observabilidad.
Colaboración entre equipos
Cuando desarrolladores, SREs y equipos de plataforma comparten el mismo estándar de telemetría, los malentendidos se reducen. Las Semantic Conventions aseguran que http.request.method sea http.request.method en todos los servicios, sin variantes como method, http_method o req.verb según el equipo. Esto permite que dashboards, alertas y SLOs funcionen cross-service sin configuración ad hoc.
Cuándo tiene sentido adoptar OpenTelemetry (y cuándo no)
Tiene sentido si:
- Trabajas con arquitecturas distribuidas, microservicios o sistemas híbridos multi-cloud.
- Quieres evitar el lock-in con un proveedor específico de observabilidad.
- Necesitas correlacionar trazas, métricas y logs de forma integrada.
- Estás evaluando migrar de backend y no quieres reinstrumentar.
- Gestionas entornos políglotas donde la consistencia de telemetría es un problema.
Puede no compensar si:
- Tu infraestructura es pequeña, con pocas aplicaciones y un stack de observabilidad ya funcional que cubre tus necesidades.
- No tienes capacidad técnica interna para instrumentar, configurar Collectors y gestionar pipelines de telemetría (aunque OBI está reduciendo mucho esa barrera).
- Tu proveedor actual cubre completamente tus requisitos y el coste de migración no se justifica.
Retos que siguen abiertos
La madurez de OpenTelemetry no significa que todo esté resuelto:
- La instrumentación es el «final boss»: como comentó Ted Young (cofundador de OTel) en GrafanaCon 2026 en Barcelona, estabilizar las APIs y los SDKs era la parte «fácil». El verdadero reto es llevar las Semantic Conventions estables a todos los paquetes de instrumentación en todos los lenguajes. La superficie es enorme.
- Calidad de los datos: recopilar todo sin criterio genera ruido y satura las plataformas. Las estrategias de muestreo (head-based, tail-based, probabilístico) y el filtrado inteligente en el Collector son esenciales, no opcionales.
- Interoperabilidad con sistemas legados: aunque OTel avanza rápido, la diversidad tecnológica en las empresas es enorme. Los entornos legacy siguen requiriendo adaptadores y soluciones específicas.
- Coste y escalabilidad de los datos: la telemetría, por definición, genera grandes volúmenes de datos. Gestionar el coste de almacenamiento y procesamiento sigue siendo un desafío, independientemente de si usas OTel o no.
- Complejidad para equipos no expertos: como señalaba The New Stack, la observabilidad no debería ser accesible solo para el experto interno de cada organización. Los vendors están trabajando en mejorar la usabilidad, pero aún no se ha llegado a un punto donde un stakeholder no técnico pueda interpretar datos de telemetría de forma autónoma.
Rendimiento en producción: datos concretos
Una de las preocupaciones recurrentes al adoptar OTel es el overhead. Los benchmarks y despliegues en producción cuentan una historia consistente:
- Java SDK (auto-instrumentación): añade entre 1,2 y 2,8 ms a la latencia P99 en servicios Spring Boot típicos bajo 1.000 RPS. El overhead de CPU se mantiene por debajo del 3 %. El agente Java instrumenta automáticamente más de 120 librerías (JDBC, gRPC, Spring MVC, Kafka, etc.).
- Go SDK (instrumentación manual): aproximadamente 6-10 MB de heap adicional por instancia. El coste de creación de un span es de ~200 ns, despreciable incluso en servicios con 100.000 TPS.
- OTel Collector: una sola instancia con 1 vCPU y 512 MB de RAM maneja aproximadamente 50.000 spans/segundo con el batch processor y el exportador OTLP/gRPC. Para entornos de alta cardinalidad, el Load Balancing Exporter permite escalar horizontalmente de forma lineal.
Resumiendo
OpenTelemetry en 2026 no es un proyecto que «hay que vigilar». Es la capa de instrumentación sobre la que el mercado de observabilidad está construyendo su presente. Las APIs son estables, los grandes vendors lo soportan (con diferentes niveles de compromiso real), la instrumentación sin código vía eBPF está eliminando barreras de adopción, y la comunidad sigue creciendo a un ritmo que pocos proyectos open source pueden igualar.
Para un equipo de operaciones, la pregunta ya no es si adoptar OpenTelemetry, sino cuándo y cómo hacerlo. Y como cualquier herramienta potente, requiere conocimiento, estrategia y disciplina para sacarle el máximo partido.
Para seguir aprendiendo
- OpenTelemetry Specification — La documentación oficial que detalla el diseño, los estándares y el estado de madurez de cada componente.
- OpenTelemetry Status — Tabla actualizada con el estado de estabilidad de cada SDK, señal y componente del proyecto.
- Blog oficial de OpenTelemetry (2026) — Todas las novedades del proyecto en 2026, incluyendo OBI, profiling y la hoja de ruta de estabilización.
- OpenTelemetry and Grafana Labs: What’s new and what’s next in 2026 — Resumen de Grafana Labs sobre los hitos de OTel en 2025 y su visión para 2026.
- OpenTelemetry eBPF Instrumentation (OBI) — Documentación — Guía oficial de OBI para instrumentación sin código basada en eBPF.
- OpenTelemetry eBPF Instrumentation 2026 Goals — Hoja de ruta del SIG de eBPF Instrumentation para 2026, incluyendo el camino hacia 1.0.
- Profiles Alpha Announcement — Anuncio oficial de la entrada en alpha público de la señal de profiling continuo.
- OpenTelemetry Graduation Application (CNCF) — La solicitud formal de graduación del proyecto en la CNCF.
- Cloud Native Observability with OpenTelemetry, por Alex Boten (O’Reilly) — Guía práctica para instrumentar y operar OpenTelemetry en entornos cloud.
- Distributed Tracing in Practice, por Austin Parker, Daniel Spoonhower y otros (O’Reilly) — Profundiza en trazas distribuidas, un componente clave de OpenTelemetry.
- OpenTelemetry GitHub Repository — Para seguir la evolución del proyecto, consultar issues y contribuir.
