alt Hacker NewsWhat the author is saying in practice is: it's nice to have Meta level funding for effectively infinite distributed storage and compute. In other areas of the industry where you want to stay profitable, metrics stay metrics, because you're submitting 2 integers for an aggregate, rather than tens of megabytes of JSON logs per minute. Then you want to retrieve this in seconds on demand... so that's either preprocessing (ongoing compute) or some serious parallel IO.
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.
All true and fair. But I do like having the instrumentation API in your code speak wide events. Then have your telemetry config decide what you want to transmit as a verbatim big event, what you want to sample/transmit as a metric, or a trace (or whether you, at the moment of transmission, need to go grab a few things out of the local tracing context stack and use them for preprocessing), and so on.
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.