Nothing; what the author is calling a wide event is a structured log.
> Structured Log which is pretty much the Wide Event
The OP's point is that you can just capture anything that one might call a metric/span/trace in a structured log.
So, it's a bit more specific, in some senses: a "metric" is a structured log bearing some value. E.g.,
{
"@timestamp": "…",
"query_kind": "list_people_in_org",
"query_time_s": .051
}
Is a structured log. It's also a single datapoint along a timeseries. The metric might be something like "query time", with a dimension "query_kind".
ELK stacks let you visualize such structured logs into graphs with only moderate pain.
A "span" is a structured log with start/end timestamps.
A trace is just a tree of spans, built out of many structured logs. In a prior life, we'd have,
{
"span_id": "root_span_id/subspan_a/subsub_span_b",
…
}
You can pull out whole traces by doing a "span_id startswith 'root_span_id'" query in whatever your query language is. You can pull out sub-traces similarly. It works even across microservice boundaries, if you coordinate the span IDs appropriately.
I think where I depart from the OP: it takes too much space. The OP advocates sampling; I'd rather a specialized data structure for metrics that can store a data point efficiently. I.e., at least in sizeof(timestamp || f32) bytes, ideally better, and then I can just not worry about sampling. (In a sense; if you're watching a continuous value, you're always sampling. But for discrete events that you're recording, I can just record all the events. But I'll only get a number. Sometimes, that's okay. I feel like this is a bit spiritually different than the sampling the OP is discussing.)
> Structured Log which is pretty much the Wide Event
The OP's point is that you can just capture anything that one might call a metric/span/trace in a structured log.
So, it's a bit more specific, in some senses: a "metric" is a structured log bearing some value. E.g.,
Is a structured log. It's also a single datapoint along a timeseries. The metric might be something like "query time", with a dimension "query_kind".ELK stacks let you visualize such structured logs into graphs with only moderate pain.
A "span" is a structured log with start/end timestamps.
A trace is just a tree of spans, built out of many structured logs. In a prior life, we'd have,
You can pull out whole traces by doing a "span_id startswith 'root_span_id'" query in whatever your query language is. You can pull out sub-traces similarly. It works even across microservice boundaries, if you coordinate the span IDs appropriately.I think where I depart from the OP: it takes too much space. The OP advocates sampling; I'd rather a specialized data structure for metrics that can store a data point efficiently. I.e., at least in sizeof(timestamp || f32) bytes, ideally better, and then I can just not worry about sampling. (In a sense; if you're watching a continuous value, you're always sampling. But for discrete events that you're recording, I can just record all the events. But I'll only get a number. Sometimes, that's okay. I feel like this is a bit spiritually different than the sampling the OP is discussing.)