Todo lo que necesitas son Wide Events, no "Metrics, Logs and Traces"
Los defensores de los “wide events” —registros de eventos ricamente estructurados y de alta cardinalidad— sostienen que pueden unificar logs, métricas y traces en un único modelo de observabilidad más flexible. Los comentaristas coinciden en general en que el enfoque se parece al logging estructurado combinado con consultas potentes, pero subrayan que almacenar e indexar datos tan detallados a escala es costoso, lo que obliga a compensaciones en torno al sampling, el diseño del esquema y los backends de almacenamiento como Kafka, Elasticsearch, ClickHouse o bases de datos especializadas de series temporales. Muchos concluyen que los wide events son muy valiosos para la depuración y el análisis exploratorio, pero que funcionan mejor combinados con métricas tradicionales más baratas y con controles cuidadosos sobre el volumen de datos, la privacidad y las prácticas de los equipos.
Qué son los “wide events” en relación con logs, traces y métricas
- Muchos comentaristas equiparan los “wide events” con los logs estructurados: registros clave–valor (a menudo JSON) que pueden representar métricas, spans y traces.
- Los traces pueden reconstruirse a partir de logs de eventos con IDs de trace/span; una métrica puede verse como una “medición” de un evento.
- Algunos sostienen que el término “wide events” בעיקרamente enfatiza: incluir muchos campos contextuales y usar almacenamiento optimizado para muchas columnas.
Beneficios percibidos de los wide events
- Unifican logs, traces y métricas en un solo modelo conceptual y backend.
- Son excelentes para los “unknown unknowns”: exploración ad hoc rápida, correlación entre dimensiones y depuración de incidentes complejos.
- Si se instrumentan bien, los logs por sí solos pueden generar métricas y traces y ofrecer una depuración forense potente.
Preocupaciones de coste, escala y cardinalidad
- Hay un fuerte escepticismo sobre el coste: almacenar eventos brutos y de alta cardinalidad a escala (especialmente con proveedores) se describe como “realmente caro” y a veces excesivo para organizaciones pequeñas.
- Algunos reportan éxito con sistemas de wide events a escalas no gigantes usando Kafka + Elasticsearch, ELK, ClickHouse o herramientas internas, pero reconocen los costes de hardware y operaciones.
- Varios señalan que el almacenamiento columnar y las bases de datos de series temporales pueden mitigar el coste, pero no eliminan las compensaciones en indexación y cardinalidad.
Sampling: necesidad y controversia
- Los defensores de wide events se apoyan mucho en el sampling (a menudo dinámico / por trace) para mantener los costes manejables sin perder contexto rico.
- Otros califican el sampling de telemetría como “una tragedia” o “una tontería”, argumentando que nunca deberías necesitar muestrear o que el ruido y el sesgo del sampling perjudican la precisión.
- Una postura intermedia: muestrear intensamente el tráfico exitoso y uniforme; conservar todo para errores/rutas lentas.
Métricas vs wide events
- Las métricas son elogiadas por ser extremadamente baratas, de larga retención y precisas para conteos y SLIs, especialmente con alto throughput.
- Muchos sostienen que los wide events no sustituyen a las métricas; son complementarios. Las métricas son mejores para alertas y tendencias a largo plazo; los eventos/logs para análisis en profundidad.
- Algunos señalan los exemplars y los span-metrics como híbridos: métricas enriquecidas con enlaces a eventos wide/traces específicos.
Patrones de implementación y herramientas
- Pila sugerida: Kafka + ES, sistemas basados en ClickHouse, arquitecturas de logs tipo Loki, TSDBs (Prometheus, VictoriaMetrics, QuestDB), OpenTelemetry + Tempo/Loki/Prometheus, PostgreSQL JSONB para configuraciones pequeñas.
- Varios destacan las diferencias entre sistemas de índice invertido (Elasticsearch, Splunk) y enfoques append-only/columnar para telemetría a escala de petabytes.
Problemas organizativos, de UX y de calidad de datos
- La usabilidad de la herramienta y las UIs sencillas para consultas exploratorias se consideran cruciales; los lenguajes de consulta crudos son potentes, pero una barrera para muchos usuarios.
- Exponer en exceso los flujos de eventos como “APIs” puede crear dependencias frágiles aguas abajo y dolor por cambios de esquema.
- Se ven con escepticismo los incentivos de los proveedores y los reclamos de marketing sobre “logs are trash” o “stop sampling”.
- Se plantean preocupaciones sobre registrar accidentalmente PII en almacenes amplios de observabilidad y la necesidad de guardrails.