There's a difference between observing systems and observing applications. Observability 2.0 describes application observability, observing request/response flows and using wide logs/spans/traces to capture data. Metrics and TSDBs still very much have a place for observing systems over time. Something like CPU usage should be a metric; trying to publish CPU usage as a structured log is usually unnecessary, complicated and expensive. Now, you could enrich your Observability 2.0 spans with the current CPU usage in order to analyse the data and, say, look at request duration vs CPU usage to understand the correlation, but that's still for application observability. You still need a separate CPU usage metric for the system, to be able to observe the system and analyse what's happening outside of the request/response flow.
![Chris Langan - The Interview THEY Didn't Want You To See - CTMU [Full Version; Timestamps]](/img/1.gif)
Brilliant and insightful convo!
Love Charity so much
I didn't get it, so CPU usage should be published as a structured log instead of metric?
There's a difference between observing systems and observing applications. Observability 2.0 describes application observability, observing request/response flows and using wide logs/spans/traces to capture data. Metrics and TSDBs still very much have a place for observing systems over time. Something like CPU usage should be a metric; trying to publish CPU usage as a structured log is usually unnecessary, complicated and expensive.
Now, you could enrich your Observability 2.0 spans with the current CPU usage in order to analyse the data and, say, look at request duration vs CPU usage to understand the correlation, but that's still for application observability. You still need a separate CPU usage metric for the system, to be able to observe the system and analyse what's happening outside of the request/response flow.
@CelestialKeystone thanks for the detailed explanation, I get it now
Corey I just realized you look awfully a lot like Tucker Carlson! 😄