Wide Events: por qué OpenTelemetry confunde a los equipos

Wide Events: la idea que cuestiona los "tres pilares" de la observabilidad

La página de glosario de OpenTelemetry acumula más de 60 términos, y esa cifra explica por qué tantos equipos de ingeniería siguen sin tener claro qué es una traza, un span o un log. Para un founder técnico, esa confusión no es un problema académico: se traduce en dashboards que nadie mira, incidentes que tardan horas en resolverse y facturas de observabilidad que crecen sin control.

En un ensayo publicado en su newsletter, el ingeniero Ilya Burmistrov plantea una tesis incómoda: el modelo de "métricas, logs y trazas" que la industria aprendió de memoria no describe la verdadera potencia de la observabilidad. Su propuesta es volver a un concepto más simple y más antiguo, los Wide Events, que conoció de primera mano trabajando en Meta.

¿Qué es un Wide Event y en qué se diferencia de una métrica o un log?

Un Wide Event es, en palabras del autor, apenas una colección de campos con nombres y valores, muy parecida a un documento JSON. Si el sistema sirve anuncios, el evento natural a registrar es una impresión: identificador del anuncio, país del usuario, ubicación en la app, tipo de campaña, sistema operativo, versión de la app.

Se llaman "wide" (anchos) justamente porque la recomendación es volcar en ellos toda la información que se te ocurra. Ese exceso aparente es la clave: prepara el terreno para los unknown unknowns, esos problemas que hoy no se te ocurren y que aparecerán recién durante la investigación de un incidente.

La diferencia con el enfoque clásico es de fondo. TechTarget describe los logs, las métricas y las trazas como los "tres pilares" de la observabilidad, cada uno con una perspectiva distinta del sistema y con limitaciones propias: los logs solo registran lo que fueron configurados para registrar, las métricas no tienen granularidad suficiente para señalar qué microservicio falla, y las trazas solo cubren una fracción de las peticiones. Combinarlos da una foto más completa, pero sigue siendo una foto armada con tres piezas separadas.

El origen: cómo Scuba en Meta modeló otra forma de trabajar

Burmistrov describe Scuba, el sistema interno de observabilidad de Meta, como "el paraíso de la observabilidad". Su idea central es tan simple que no necesita glosario: se escriben Wide Events y luego se exploran.

El flujo que describe es el de una investigación real. Un gráfico de impresiones se ve raro. En lugar de buscar una métrica predefinida, el equipo empieza a "cortar y rebanar": agrupa por tipo de campaña, después por sistema operativo, después por versión del sistema. Sin conocer el sistema de antemano, el equipo aísla el problema en una combinación de tipo de campaña, versión de OS y versión de app, y sabe a qué equipo derivar la investigación.

Dos detalles técnicos sostienen ese flujo. El primero es el samplingRate: cada evento se escribe con la tasa con la que fue muestreado, y la interfaz hace el "upscaling" de forma transparente, lo que permite muestrear distinto según el tipo de evento sin distorsionar los valores reales. El segundo es que Scuba trabaja con eventos crudos y no pre-agrega nada, así que la cardinalidad deja de ser un problema: cualquier campo puede tener cualquier cantidad de valores distintos.

¿Por qué OpenTelemetry genera tanta confusión?

El autor apunta directamente a OpenTelemetry como responsable de la confusión masiva, aunque aclara que no es un mal producto. Su crítica es de presentación: desde el inicio, el proyecto separa trazas, métricas y logs como tres cosas distintas, y esa separación se convierte en el modelo mental que todos aprenden.

El argumento de fondo es que las tres categorías son, en realidad, casos particulares de un Wide Event. Las trazas y los spans son Wide Events que tienen campos SpanId, TraceId y ParentSpanId: con eso se filtran, se ordenan topológicamente y se dibuja la vista de tracing distribuido. Los logs se mapean poniendo el mensaje en un campo y agregando metadata. Las métricas se mapean emitiendo un Wide Event por intervalo con el estado del sistema, que es exactamente lo que hace Prometheus con su enfoque de scraping.

La cita que abre el ensayo es de Charity Majors, cofundadora y CTO de Honeycomb, y resume el estado del sector como una "confusión total y masiva". El dato de contexto que refuerza el diagnóstico: OpenTelemetry se graduó como proyecto de la Cloud Native Computing Foundation el 21 de mayo de 2026, tras ingresar en 2019 y pasar a incubación en 2021, según Virtualization Review. Es decir, el estándar ya es maduro y universal, y aun así su vocabulario sigue siendo el principal obstáculo de adopción.

El costo real: fragmentación y facturas que no cierran

Hay un problema económico detrás del vocabulario. Forbes señala que la fragmentación de la observabilidad no solo genera lock-in, sino costos más altos por datos duplicados y más ruido para equipos ya sobrecargados. Y advierte un riesgo concreto para quien adopta el estándar: muchos proveedores clasifican los datos de OpenTelemetry como "custom metrics" y cobran tarifas premium por ellos, de modo que un pico de volumen puede borrar el ahorro que motivó la migración.

Ese ahorro es la razón principal por la que las empresas migran. Según el informe 2025 State of Open Source Report, publicado por OpenLogic y la Open Source Initiative, casi todas las organizaciones aumentaron o mantuvieron su uso de open source, y más de la mitad citó el ahorro de costos como el motor principal. La observabilidad es una de las capas donde ese cálculo se juega todos los meses.

¿Hacia dónde va el debate?

Burmistrov no pide abandonar OpenTelemetry, sino que los proveedores tomen posición contra la confusión y ofrezcan una forma simple y natural de interactuar con el sistema. Menciona a Honeycomb y a Axiom como ejemplos que van en esa dirección.

El contexto del sector acompaña ese giro. En junio de 2026, Honeycomb publicó la segunda edición de Observability Engineering, con Charity Majors, Liz Fong-Jones, George Miranda y Austin Parker como autores. La primera edición era de 2022 y esta es casi una reescritura completa de más de 600 páginas, según el comunicado difundido por PR Newswire. El argumento central que citan: los equipos ahora despliegan más rápido gracias a la IA, pero sus ciclos de retroalimentación en producción no acompañaron ese ritmo, así que no aprenden más rápido, solo acumulan riesgo más rápido.

Qué significa esto para tu startup

Si tu equipo tiene menos de 50 personas, no puedes permitirte el lujo de un glosario de 60 términos ni de tres herramientas separadas que nadie correlaciona. Estas son dos decisiones concretas que puedes tomar esta semana.

• Instrumenta eventos anchos desde el primer día. En lugar de definir de antemano qué métrica vas a necesitar, registra el contexto completo de cada evento de negocio relevante (alta de usuario, pago, error de checkout) con todos los campos que se te ocurran. El costo de agregar un campo hoy es mínimo; el costo de no tenerlo durante un incidente es una madrugada entera.
• Evalúa el costo de OpenTelemetry antes de firmar. Pregunta explícitamente a tu proveedor si clasifica los datos de OTel como "custom metrics" y a qué tarifa. Es el punto donde el ahorro prometido del estándar abierto se puede evaporar en la factura.
• Prioriza herramientas con exploración visual sobre lenguajes de consulta propietarios. Si para investigar un incidente necesitas escribir SQL o aprender un lenguaje propio, tu equipo va a investigar menos. La capacidad de agrupar y filtrar con un clic es lo que convierte los datos en decisiones.

La lección de fondo es de estrategia, no de tooling. La observabilidad no sirve para tener más gráficos, sino para responder preguntas que no sabías que ibas a tener. Elegir un modelo de datos que soporte esa incertidumbre es más barato que comprar tres productos que la ignoran.

Fuentes

• All you need is Wide Events, not "Metrics, Logs and Traces" (fuente original)
• From Observability Chaos To Clarity: The Business Case For OpenTelemetry (Forbes)
• OpenTelemetry Pushes Deeper into Cloud Observability (Virtualization Review)
• The 3 pillars of observability: Logs, metrics and traces (TechTarget)
• Honeycomb Releases Second Edition of Bestseller Observability Engineering (PR Newswire)