All you need is Wide Events, not "Metrics, Logs and Traces"
Advocates of “wide events” — richly structured, high-cardinality event records — argue they can unify logs, metrics, and traces into a single, more flexible observability model. Commenters broadly agree the approach resembles structured logging plus powerful querying, but emphasize that storing and indexing such detailed data at scale is expensive, forcing trade-offs around sampling, schema design, and storage backends like Kafka, Elasticsearch, ClickHouse, or specialized time-series databases. Many conclude that wide events are highly valuable for debugging and exploratory analysis, yet are best combined with traditional, cheaper metrics and careful controls on data volume, privacy, and team practices.
What “wide events” are relative to logs, traces, and metrics
- Many commenters equate “wide events” with structured logs: key–value records (often JSON) that can represent metrics, spans, and traces.
- Traces can be reconstructed from event logs with trace/span IDs; a metric can be seen as an event “measurement.”
- Some argue the term “wide events” mainly emphasizes: include lots of contextual fields and use storage optimized for many columns.
Perceived benefits of wide events
- Unify logs, traces, and metrics into one conceptual model and backend.
- Great for “unknown unknowns”: fast ad‑hoc exploration, correlation across dimensions, and debugging complex incidents.
- If instrumented well, logs alone can yield metrics and traces and support powerful forensic debugging.
Cost, scale, and cardinality concerns
- Strong skepticism about cost: storing raw, high‑cardinality events at scale (especially with vendors) is described as “really expensive” and sometimes overkill for smaller orgs.
- Some report success with wide‑event systems at non‑giant scale using Kafka + Elasticsearch, ELK, ClickHouse, or in‑house tools, but acknowledge hardware and ops costs.
- Several note that columnar storage and time‑series databases can mitigate cost but don’t remove trade‑offs around indexing and cardinality.
Sampling: necessity and controversy
- Wide‑event advocates lean heavily on sampling (often dynamic / per‑trace) to keep costs manageable while retaining rich context.
- Others call telemetry sampling “a tragedy” or “nonsense,” arguing you should never need to sample or that sampling noise and bias harm accuracy.
- Middle view: sample heavily for successful, uniform traffic; keep everything for errors/slow paths.
Metrics vs wide events
- Metrics are praised for being extremely cheap, long‑retention, and accurate for counts and SLIs, especially at high throughput.
- Many argue wide events do not replace metrics; they are complementary. Metrics are better for alerting and long‑term trends; events/logs for deep dives.
- Some note exemplars and span‑metrics as hybrids: metrics enriched with links to specific wide events/traces.
Implementation patterns and tools
- Suggested stacks: Kafka + ES, ClickHouse‑based systems, Loki‑like log architectures, TSDBs (Prometheus, VictoriaMetrics, QuestDB), OpenTelemetry + Tempo/Loki/Prometheus, PostgreSQL JSONB for small setups.
- Several highlight differences between inverted‑index systems (Elasticsearch, Splunk) and append‑only/columnar approaches for petabyte‑scale telemetry.
Organizational, UX, and data‑quality issues
- Tool usability and simple UIs for exploratory querying are seen as crucial; raw query languages are powerful but a barrier for many users.
- Over‑sharing event streams as “APIs” can create brittle downstream dependencies and schema‑change pain.
- Vendor incentives and marketing claims around “logs are trash” or “stop sampling” are viewed skeptically.
- Concerns raised about accidentally logging PII into broad observability stores and the need for guardrails.