Introducción
En mayo de 2026, OpenTelemetry alcanzó el estatus de proyecto graduado dentro de CNCF. Ese hito resolvió una discusión de años sobre qué estándar de instrumentación adopta la industria cloud native, pero no cerró el problema operativo que enfrentan los equipos de infraestructura todos los días: cómo correlacionar métricas, logs y traces en arquitecturas que ya incluyen workloads de IA, agentes autónomos y pipelines CI/CD distribuidos, sin que la factura de telemetría crezca más rápido que el tráfico de producción.
Observability Day, que se celebra el 9 de noviembre de 2026 como co-located event de KubeCon + CloudNativeCon North America en Salt Lake City, Utah, existe precisamente para que quienes construyen estos proyectos y quienes los operan en producción compartan trade-offs reales. No es una conferencia de marketing de vendors: es un espacio vendor-neutral donde los equipos de SRE, plataforma y seguridad comparan arquitecturas de instrumentación, pipelines de ingesta, almacenamiento y correlación. Para un equipo DevOps que hoy mantiene un stack con Prometheus, Fluent Bit, Jaeger y OpenTelemetry Collector, las decisiones que se discutan ese día van a impactar directamente en su roadmap de los próximos 12 a 18 meses.
Qué ocurrió
Observability Day no nació de la nada. Su antecedente directo es FluentCon, un co-located event que se realizó por primera vez en KubeCon + CloudNativeCon Europe 2022 en Valencia, España, enfocado exclusivamente en las comunidades de Fluentd y Fluent Bit. A finales de ese mismo año, el formato se expandió en KubeCon + CloudNativeCon North America bajo el nombre Open Observability Day, incorporando maintainers de Jaeger, Thanos, Prometheus y OpenTelemetry. La premisa era simple pero necesaria: cada proyecto tenía su comunidad, pero nadie tenía un foro compartido donde discutir cómo esos proyectos interactúan en un stack de producción real.
El evento de 2026 llega en un momento de transición concreta. OpenTelemetry graduado elimina la ambigüedad de «¿usamos OpenTracing o OpenTelemetry?», pero abre preguntas nuevas: cómo migrar instrumentación heredada de Jaeger SDK a OTLP sin downtime, cómo manejar la explosión de cardinalidad en métricas Prometheus cuando los workloads de IA generan miles de series temporales por pod, y dónde instrumentar con eBPF para capturar señales de red y kernel sin modificar el código de aplicación. El programa oficial cubre exactamente esos puntos: internos de proyectos, arquitecturas cross-project, ingeniería de datos para hacer la telemetría útil y asequible, instrumentación basada en eBPF, y observabilidad de agentes de IA.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para un equipo SRE que opera entre 200 y 2.000 pods en Kubernetes, el impacto práctico se traduce en tres frentes. Primero, costos: la telemetría puede representar entre el 15% y el 30% del gasto total de infraestructura en stacks con logs completos, métricas a alta resolución y traces distribuidos. Las sesiones de data engineering y telemetry cost del programa abordan directamente estrategias de sampling, cardinalidad controlada y tiering de almacenamiento (Thanos, Cortex, Perses) que reducen ese porcentaje sin perder visibilidad en incidentes críticos.
Segundo, la observabilidad de workloads de IA y agentes introduce una capa nueva que la mayoría de los equipos aún no instrumentó. Un agente autónomo que ejecuta tool calls, invoca LLMs y gestiona estado en memoria requiere correlación entre spans de inferencia, logs de context window y métricas de GPU. Los proyectos Pixie (observabilidad eBPF en Kubernetes) e Inspektor Gadget permiten capturar señales a nivel de kernel sin sidecar, lo que reduce overhead en workloads sensibles a latencia como inference serving.
Tercero, la seguridad: un pipeline de telemetría sin control de acceso adecuado expone datos de trazas que contienen PII, tokens o payloads de API. La conversación cross-project sobre data quality también toca governance y retención, un tema que equipos de seguridad y compliance no pueden delegar al equipo de plataforma.
Detalles técnicos
El ecosistema CNCF observability que se reúne en este evento incluye componentes específicos con roles bien definidos:
- Prometheus: métricas pull-based, standard de facto en Kubernetes. La discusión de 2026 se centra en manejo de cardinalidad y interoperabilidad con OTLP metrics.
- OpenTelemetry Collector: gateway de ingesta que normaliza señales de 70+ fuentes. Con la graduación de mayo 2026, la especificación OTLP es el contrato de instrumentación por defecto.
- Jaeger: trazado distribuido. La migración de Jaeger SDK nativo a OTLP/HTTP y OTLP/gRPC es un tema recurrente en sesiones de producción.
- Fluent Bit / Fluentd: agentes de logs. Fluent Bit, con su footprint de ~450 MB en producción, domina en Kubernetes; Fluentd mantiene tracción en pipelines de agregación.
- Thanos / Cortex: almacenamiento y querying a escala para métricas Prometheus, con compaction y downsampling.
- Perses: dashboarding y querying unificado que abstrae sobre Prometheus, Loki y Tempo.
- Pixie / Inspektor Gadget: instrumentación eBPF in-kernel que captura TCP, HTTP, DNS y signals de proceso sin modificar aplicaciones.
- Kepler: métricas de energía a nivel de pod y nodo, relevante para equipos con compromisos de eficiencia.
La instrumentación con eBPF merece mención específica. A diferencia de los SDKs de OpenTelemetry que requieren cambios en el código de aplicación, eBPF permite observar syscalls, eventos de red y trazas de kernel desde un DaemonSet en Kubernetes. Pixie utiliza eBPF para auto-instrumentar servicios HTTP/gRPC sin configuración manual, mientras que Inspektor Gadget (proyecto CNCF) expone gadgets de observabilidad a nivel de nodo. El vector de riesgo es bajo pero no nulo: un gadget mal configurado puede generar overhead en el path de syscall, degradando latencia en workloads sensibles.
Qué deberían hacer los administradores y equipos técnicos
Si tu equipo opera un stack de observabilidad en Kubernetes, estas acciones concretas tienen sentido antes y después del 9 de noviembre:
Antes del evento: revisá el schedule oficial y priorizá sesiones según tu gap actual. Si todavía tenés instrumentación Jaeger SDK (v1.x) sin migrar a OTLP, buscá las sesiones de internals de OpenTelemetry Collector y Jaeger. Si tu factura de Prometheus supera el presupuesto, apuntá a las sesiones de cardinalidad y downsampling en Thanos/Cortex.
Para equipos con workloads de IA: evaluá si tu OpenTelemetry Collector ya maneja el esquema semántico de GenAI spans (propuestos en las OTEPs de GenAI). Si no, tu instrumentación actual no captura tool calls, tokens de contexto ni latencia de inference. El Collector versión 0.100+ incluye la GenAI semantic conventions como experimental.
Para instrumentación eBPF: probá Inspektor Gadget en un clúster de staging antes de llevarlo a producción. Instalás con:
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/inspektor-gadget/main/pkg/gadget-collection/gadgets/trace/insight/trace-insight.yaml
Verificá que el overhead en p99 de tus servicios principales no supere 2-3 ms antes de habilitar gadgets de red en nodos de producción.
Para costos: implementá sampling de traces con OpenTelemetry Collector usando el processor tail_sampling con políticas basadas en latencia y errores, no en probabilidad uniforme. Un ejemplo de configuración:
processors:
tail_sampling:
decision_wait: 10s
policies:
– name: errors
type: status_code
status_code: { status_codes: [ERROR] }
– name: slow-traces
type: latency
latency: { threshold_ms: 1000 }
– name: baseline
type: probabilistic
probabilistic: { sampling_percentage: 5 }
Esto reduce volumen de spans a Jaeger/Tempo en un 70-90% manteniendo visibilidad en incidentes.
Post-evento: documentá las decisiones arquitectónicas que apliques y compartí la experiencia en las comunidades de los proyectos. El valor del modelo cross-project depende de que operadores reales retroalimenten a maintainers sobre cómo funcionan los proyectos integrados, no aislados.
Conclusión
Observability Day 2026 no es un evento de lanzamiento ni de hype. Es el punto donde el ecosistema CNCF observability —ya maduro en sus componentes individuales— discute cómo esos componentes funcionan juntos bajo presión real: workloads de IA, presupuestos de telemetría apretados, requisitos de compliance y la promesa (aún en construcción) de eBPF como capa de instrumentación universal. Para un equipo de plataforma que decide entre OpenTelemetry SDK nativo o auto-instrumentación eBPF, entre sampling probabilístico y tail-based, o entre Thanos y Cortex como backend de métricas, las respuestas no están en un whitepaper de vendor. Están en la conversación entre quien mantuvo el proyecto y quien lo operó a las 3 AM durante un incidente. Esa conversación ocurre el 9 de noviembre en Salt Lake City, y sus conclusiones van a filtrarse al ecosistema durante todo el ciclo siguiente.
Fuentes
- https://www.cncf.io/blog/2026/09/24/observability-day-where-the-community-comes-together-at-kubecon-cloudnativecon-north-america-2026/