vmarsy

Ah thanks for finding the name, I tried to describe it in an older comment [1], on the same topic of Framework laptop expansions.

Agree with you, I hope such a version exists one day!

Specifically, how to make the sum of all monitored "pillars" more useful than each of them individually.

3 major pillars being:

- Metrics (whether application or higher-level of the stack, like OS)

- Logs (whether structured or unstructured)

- Traces

Observability is these major pillars and how to easily "jump" from one to another to very quickly identify the root cause of an issue. I.e. go Metrics <-> Logs, Logs <-> Traces, or Metrics <-> Traces,

For instance, with good Metrics, one can easily figure out & get alerts when there is a large spike of 500 errors. But when Metrics & Logs can work together, one can easily see the exception from stack trace that are emitted with those 500 errors.

Similarly, with good Metrics, one can easily figure out that the frontend service latency p90 has increased by 5x. But with Metrics & Traces working together(for instance via Exemplar[1]), one can look at a bunch of the traces that have a very high latency, and identify the upstream service responsible for this increase.

With Monitoring only, you could get a nice Metrics solution in place, with fancy alerting rules, but all it was good at is informing you "Something bad is currently happening". With a good "Observability" setup, you should also be able to change it to "Something bad is currently happening and the root cause is right here."

That's funny I remember laptops from the 2000s with those swappable cards with different ports.

One I distinctly remember because it was clever way to keep the card ~3mm thin were the Ethernet cards, where the Ethernet port was hidden inside and you'd press it to make it pop, similar to handleless kitchen cabinets.