El 21 de mayo de 2026, en la Observability Summit de Minneapolis, la Cloud Native Computing Foundation anunció que OpenTelemetry se convertía en su segundo proyecto graduado con mayor velocidad de crecimiento de toda la fundación, solo por detrás de Kubernetes: más de 12.000 colaboradores, más de 2.800 empresas participando, y unas cifras de descarga de sus librerías —1.360 millones para la de JavaScript, más de 1.300 millones para la de Python, solo en abril de ese año— que ya no dejan sitio a la duda de si el estándar ha calado. Michele Mancioppi, arquitecto jefe de Dash0, lo resumió con una frase que merece quedarse grabada: la graduación de OpenTelemetry ha traído un cambio sísmico porque, en vez de competir sobre quién tiene la mejor telemetría, los proveedores ahora compiten sobre quién hace mejor uso de la telemetría que todos ya tienen igual.
Y sin embargo, menos de tres meses después, un estudio de Middleware con 407 profesionales de DevOps, SRE y arquitectura cloud de más de veinte sectores —recogido en el blog de la propia CNCF bajo un titular que no se anda con rodeos, «las herramientas están listas, entonces ¿por qué la mayoría de equipos cloud native siguen operando tres stacks de observabilidad a la vez?»— encontraba que solo un 7,4% de las organizaciones había logrado una experiencia de observabilidad realmente unificada. Un 46,7% seguía operando entre dos y tres herramientas en paralelo. Y un dato que resume bien la tensión de fondo: el 81% se declaraba satisfecho con su configuración actual, pero el 63% seguía abierto a cambiarla. Ni el estándar es el problema, ni la gente está descontenta con lo que tiene, y aun así casi nadie ha resuelto de verdad el problema de fondo.
Esa contradicción —un ecosistema técnicamente maduro que sigue generando confusión operativa— es exactamente lo que hace que monitorizar aplicaciones en Kubernetes siga siendo, en 2026, un tema donde cuesta encontrar una respuesta simple.
El estándar ya no es el cuello de botella
Vale la pena separar dos preguntas que se mezclan constantemente en cualquier conversación sobre observabilidad en Kubernetes: ¿existen ya herramientas maduras para capturar métricas, logs y trazas de un clúster? y ¿sabe la mayoría de equipos cómo ensamblarlas en algo coherente? La respuesta a la primera es, hoy, un sí razonablemente sólido. Prometheus lleva años siendo el estándar de facto para métricas en el mundo cloud native, Grafana domina la visualización, y OpenTelemetry —tras su graduación— se ha consolidado como el protocolo común para instrumentar aplicaciones y transportar sus datos sin atarse a un backend concreto. La propia encuesta de Middleware lo confirma indirectamente: cuando pregunta por los mayores obstáculos, no aparece «faltan funcionalidades» entre las respuestas principales. Aparecen la configuración de dashboards y alertas (54%), la complejidad de integración entre piezas (46,4%) y la dificultad de configurar pipelines de datos correctamente (33,2%).
Es una distinción incómoda pero importante: no es un problema de herramientas, es un problema de fontanería. Conectar un exporter de Prometheus con el scraping correcto, decidir qué processor de OpenTelemetry Collector aplica antes de exportar, encajar la cardinalidad de las métricas con lo que el backend puede digerir sin disparar el coste… nada de esto es exótico ni requiere un componente que no exista todavía, pero requiere un conocimiento operativo que no viene incluido de fábrica en ningún Helm chart. La CNCF, en su encuesta anual de 2025, llega a una conclusión que va en la misma dirección desde otro ángulo: los retos culturales de adopción (el 47% menciona el cambio cultural en equipos de desarrollo como principal obstáculo) han superado ya a la complejidad puramente técnica.
La arquitectura sigue siendo el problema real
Para quien todavía no ha tenido que instrumentar un clúster de Kubernetes con decenas de microservicios, vale la pena explicar por qué esto es estructuralmente distinto a monitorizar una aplicación monolítica de toda la vida. Con un monolito, un log de errores y una métrica de latencia por endpoint suelen bastar para saber qué está pasando: hay un único proceso, un único punto donde mirar. Con microservicios desplegados en pods que aparecen y desaparecen constantemente, una petición de usuario puede atravesar quince servicios distintos antes de completarse, y el fallo puede estar en cualquiera de ellos —o en la red que los conecta, que en Kubernetes es una capa de complejidad en sí misma—.
MONOLITO MICROSERVICIOS EN KUBERNETES
═════════ ═════════════════════════════
[ Petición ] [ Petición ]
│ │
▼ ▼
[ Aplicación ] → log + métrica [ Gateway ] → [ Servicio A ] → [ Servicio B ]
│ │ │ │
▼ trace trace trace
[ Base de datos ] │ │ │
└──────► [ Servicio C ] ◄───────┘
│
[ Base de datos ]
Una sola señal suele bastar. Sin trazabilidad distribuida (tracing),
reconstruir el camino de un fallo es
casi imposible.
Esto es lo que ha empujado a que el tracing distribuido —seguir el rastro completo de una petición a través de todos los servicios que toca, con un identificador común— pasara de ser una curiosidad académica a una pieza obligatoria del stack. Pero el tracing por sí solo tampoco resuelve todo: correlacionarlo con métricas de infraestructura del pod (¿el servicio B estaba lento porque tenía un bug, o porque el nodo donde corría estaba con el CPU al límite?) y con los logs de aplicación sigue siendo, en la práctica, el punto donde más equipos se atascan —y exactamente el punto que la encuesta de Middleware señala como el obstáculo principal.
eBPF: la vía que promete observabilidad sin tocar el código
Una de las tendencias más interesantes de los últimos dos años para intentar resolver esto por otro camino es el uso de eBPF (extended Berkeley Packet Filter), una tecnología del kernel de Linux que permite ejecutar programas de forma segura dentro del propio kernel sin modificarlo ni recompilarlo. Aplicado a observabilidad, esto significa poder capturar tráfico de red, llamadas a sistema y comportamiento de procesos directamente desde el kernel, sin necesidad de instrumentar cada aplicación con una librería o inyectar un sidecar en cada pod. Proyectos como Cilium, con su componente de visibilidad Hubble, o el ya adquirido Pixie, lo aprovechan para dar visibilidad de red y de servicio «gratis», sin que el equipo de desarrollo tenga que tocar una línea de código.
La promesa es atractiva porque ataca directamente uno de los costes ocultos de las mallas de servicio (service mesh) tradicionales basadas en sidecars: cada pod necesita un proxy adicional corriendo a su lado, lo que añade consumo de CPU y memoria y una capa más que mantener y actualizar. eBPF, al operar a nivel de kernel, evita ese sobrecoste de sidecar y reduce la fricción de instrumentación de la que hablaba el apartado anterior.
SERVICE MESH CON SIDECAR OBSERVABILIDAD CON eBPF
═════════════════════════ ════════════════════════
[ Pod ] [ Pod ]
├─ [ App ] └─ [ App ]
└─ [ Sidecar ]──► métricas/trazas ▲
(proxy, CPU extra por pod) │ (sin tocar el pod)
[ eBPF en el kernel del nodo ]
│
▼
métricas/trazas de red y syscalls
Pero conviene no venderlo como la solución definitiva. eBPF da una visibilidad excelente de red, latencia entre servicios y syscalls, pero no sustituye el tracing a nivel de aplicación cuando el fallo está en la lógica de negocio interna de un servicio, no en cómo se comunica con los demás. Requiere kernels relativamente recientes y ciertos permisos a nivel de nodo que no todos los entornos gestionados permiten sin fricción, y su curva de aprendizaje operativo —depurar un programa eBPF que no se comporta como se espera— no es precisamente suave. Es una pieza más del rompecabezas, no un sustituto de todas las demás.
Cómo lo están afrontando los equipos que sí avanzan
Ni la encuesta de Middleware ni la de la propia CNCF sugieren que exista un atajo mágico, pero sí dejan un patrón reconocible en los equipos que consiguen salir del bucle de «tres stacks a la vez»: tienden a tratar OpenTelemetry no como una herramienta más que se añade al final, sino como la capa de instrumentación desde el primer día, de forma que métricas, logs y trazas nazcan correlacionados por diseño en vez de intentar coserlos después con reglas ad-hoc. Eso no elimina la necesidad de elegir un backend (Prometheus más Grafana, un proveedor comercial, o una combinación de ambos según el caso de uso), pero sí evita el escenario más habitual de tool sprawl: el de acumular una herramienta distinta cada vez que aparece un problema nuevo, sin que ninguna hable el mismo idioma que las demás.
La demanda de detección de anomalías asistida por IA que recoge la propia encuesta de Middleware —un 59,5% la quiere integrada, aunque un 48,3% insiste en mantener supervisión humana antes de que actúe de forma autónoma— apunta en la misma dirección que el artículo anterior de este blog sobre los retos del SRE: la ambición de automatizar la correlación de señales va por delante de la confianza real en dejarla actuar sola. Tiene sentido: antes de fiarte de que un sistema automático te diga por qué falló una petición que atravesó quince servicios, conviene tener la certeza de que esos quince servicios están, de entrada, emitiendo señales que se pueden correlacionar entre sí.
Los límites que conviene no perder de vista
Ni OpenTelemetry, ni eBPF, ni ninguna combinación de ambos resuelve el problema de la cardinalidad: cuantas más etiquetas (labels) añadas a una métrica para poder filtrarla con precisión —por pod, por versión de despliegue, por región—, más caro se vuelve almacenarla y consultarla, y es fácil disparar el coste de un backend de métricas sin darse cuenta hasta que llega la factura. Tampoco resuelve el reto cultural que la propia CNCF señala como el principal en 2025: la mejor arquitectura de observabilidad no sirve de mucho si los equipos de desarrollo no adoptan el hábito de instrumentar su código correctamente desde que lo escriben, en vez de dejarlo para cuando algo ya se ha roto en producción. Y para clústeres pequeños o equipos sin una persona dedicada a observabilidad, montar una pila completa de OpenTelemetry Collector, Prometheus, un backend de trazas y Grafana puede ser, sencillamente, más complejidad operativa de la que el tamaño del proyecto justifica —a veces la respuesta correcta sigue siendo una solución gestionada más sencilla, aunque menos «de moda».
Fuentes:
- CNCF — Cloud Native Computing Foundation Announces OpenTelemetry’s Graduation
- CNCF — The tools are ready. So why are most cloud native teams still running three observability stacks?
- CNCF — Kubernetes Established as the De Facto ‘Operating System’ for AI (2025 CNCF Annual Cloud Native Survey)
- Cilium — Hubble: Network, Service & Security Observability for Kubernetes
