love this piece. the hardest problem in distributed systems is often isolating which component is at fault. medium.com/observability/…
interesting to see how easy it is to explain to engineers how honeycomb works and why we chose the tradeoffs we did (sampling not aggregation, arbitrarily wide events to pack loads of context, no indexing etc) when they come from a frame of traces instead of metrics.
software engineers are already beginning to rapidly adjust to a world where metrics are useless and logs are a dusty annoyance for backwards-compatibility.
you don't actually need metrics or logs. all you need are events and traces (&& a trace is just a type of event).
you don't actually need metrics or logs. all you need are events and traces (&& a trace is just a type of event).
you can always derive metrics from events, and aggregate them later.
you can never work your way back to a fully context-rich event given only metrics, or time series aggregates. they are useless, futile for understanding how software and systems work.
you can never work your way back to a fully context-rich event given only metrics, or time series aggregates. they are useless, futile for understanding how software and systems work.
and logs? logs are technical debt made manifest. they are historically a mess of unstructured strings written out to disk. they have only enough context to hint at problems, no structure to perform operations or calculations on. and flushing to disk is a loaded gun in hand.
fuck logs. fuck metrics.
my life got easy when i stopped peering at dashboards and trying to correlate timestamps between systems or remember which weird string i was supposed to be grepping on.
all you need is events and aggregated tracing. 🎵
my life got easy when i stopped peering at dashboards and trying to correlate timestamps between systems or remember which weird string i was supposed to be grepping on.
all you need is events and aggregated tracing. 🎵
