This article leaves me confused. The “wide event” example presented is a mishmash of all the different concerns involved with a business operation: HTTP request, SQL query, business objects, caches, …. How is this any better than collecting most of this information as separate events on a technical level (with minimal, if any, code changes: interceptors, middleware etc) and then aggregating afterwards?

From my perspective, this is just structured logging. It doesn’t cover tracing and metrics, at all.

> This process requires no code changes—metric are derived directly from the raw event data through queries, eliminating the need for pre-aggregation or prior instrumentation.

“requires no code changes”? Well certainly, because by the time you send events like that your code has already bent over backwards to enable them.

Surely I must be missing something.

Yes, this is a common confusing point between structured logging and wide event. The Wide Event 101 article I referenced has clear explanation:

> Structured logs could be wide events, but not all structured logs are wide events. A structured log with 5 fields is not a wide event. A structured log with no context is not a wide event.

And these also why it requires no code changes to extract more metrics from wide event. The context can carry enough information and you just write a new query to retrieve it. In current metrics tooling, you will make code change to define new labels or add new metrics for that.