Learn observability
What each signal is for, how to make them join, and how to keep the bill sane.
What does the Learn observability track cover?
This track covers what observability means beyond the three-pillars framing, which telemetry type answers which question, how to design alerting people still read, and how to control cost without discarding the signal you need.
The route, in order
A definition that does more work than "the three pillars", and a test you can run this week.
Why the distinction is more than marketing, and why you need both.
Logs, metrics and traces: what each is good at and what it costs.
The main driver of metric cost, and where high-cardinality data belongs instead.
Symptom-based alerting, correlation, ownership routing and pruning with evidence.
Pattern extraction and novelty detection at volume.
What you should be able to do afterwards
- Decide whether a piece of information belongs on a metric, a log or a trace
- Explain why cardinality drives cost and what to do about it
- Design an alert that a responder will still read at 3am
- Test whether your own system is genuinely observable
Questions about this track
No, but the concepts map onto it directly, and it is the standard worth adopting if you are instrumenting from scratch.
No. The material is about signal types, cardinality and alerting design, which apply regardless of backend.
Where to go next
Learn DevOps
Start here if DevOps is a word you use more confidently than you would like.
Learn Kubernetes
For people who have to run Kubernetes, not just deploy to it.
Learn DevSecOps
The controls that reduce the most risk, in the order worth doing them.
Learn AI and agentic DevOps
Where agents genuinely help, where they are oversold, and how to introduce them safely.
Learn cloud operations
Running infrastructure across providers without three of everything.
See it working rather than reading about it
Connect a cluster read-only during a demo call and look at the concepts in your own environment.