I'm glad the author likes wide events for everything. I do too. But once you try to justify the cost, you understand why it's metrics, logs and (often sampled) traces.
I'm glad the author likes wide events for everything. I do too. But once you try to justify the cost, you understand why it's metrics, logs and (often sampled) traces.
If you do all that on the client side (not in a sidecar, ideally: actually in your client code when deciding what to transmit) you have a fairly nice way to temporarily turn on e.g. rich trace recording to hunt a bug, or start spraying event bodies to a local file when debugging a troublesome service instance, and so on. The rest of the time, things can transmit a few big payloads and a lot of small metrics, and things stay cheap.
In other words, it's easy to go from "recorder.record_rich_typed_event(...)" to capturing any or all of events, traces, metrics, or logs. It's not easy to go from e.g. "metrics.record_integer_metric("somemetric", 15)" to recording a richer, more complex event in a pinch.