Skip to main content

📊 Free observability course: see what is happening in production

Welcome to the most educational observability discovery course. In 7 short lessons, you will understand why you cannot operate a system you do not measure, and how the world's most reliable teams know a problem exists before their users report it.

What this course aims for: to answer once and for all the questions "monitoring or observability?", "what are the three pillars?", "what is an SLO for?", "why does my team ignore alerts?", "Prometheus or Datadog?" — with concrete examples and no jargon.

What this course does not do: teach you how to write a PromQL query or configure a Grafana dashboard. That hands-on mastery is the subject of the Premium Monitoring and Logs course.


What you are going to discover


Course contents

#LessonMain objectiveDuration
1The problem observability solvesUnderstand the real cost of flying blind6 min
2Monitoring or observability?Rigorously distinguish the two notions6 min
3The three pillarsMetrics, logs, traces: when to use which8 min
4What exactly should you measure?The four golden signals, the USE and RED methods7 min
5SLI, SLO and error budgetThe heart of the SRE approach, explained simply7 min
6The tools and the art of alertingPrometheus, Grafana, OpenTelemetry + useful alerts7 min
7Real-world use cases + FAQGoogle, famous incidents + 14 frequent questions5 min
8Quiz and attestationValidate what you learned in 5 corrected questions3 min

Is this course for you?

  • You are a developer and you learn about production problems from user messages.
  • You are a system administrator or SRE and you want to structure your approach beyond CPU load graphs.
  • You are on call and you get woken up by alerts that, half of the time, correspond to nothing.
  • You are transitioning into DevOps and observability comes up in every interview.
  • You are a project manager or CTO and you want to understand what "our service is 99.9% available" really means.

No heavy prerequisites. Reading Docker Discovery and Kubernetes Discovery beforehand helps grasp the examples, without being essential.


The course plan at a glance


What you will know by the end

No queries to memorize. By the end of the course, you will be able to:

  • Explain the difference between monitoring and observability without hesitation.
  • Choose between metrics, logs and traces depending on the question at hand.
  • Apply the four golden signals to any service.
  • Define a relevant SLO and compute the corresponding error budget.
  • Understand why your team suffers from alert fatigue, and how to fix it.
  • Compare Prometheus, Grafana, Datadog and OpenTelemetry with real arguments.
  • Approach the Premium Monitoring and Logs course with confidence.

⏱️ Estimated duration

About 45 minutes of reading in total. Each lesson is self-contained — you can read one per day, or go through everything in one evening.


Useful prerequisites:

Natural follow-up after this course:


Frequent questions in one answer

Monitoring or observability — what is the difference?

Monitoring: watching indicators you chose in advance. It answers the questions you knew you had to ask.

Observability: the ability to understand the internal state of the system from what it emits, including for questions you never anticipated.

A useful formula: monitoring covers known problems, observability lets you investigate novel ones. Lesson 2 goes deeper.

What are the three pillars?
  • Metrics — numbers aggregated over time. Cheap. They answer "is there a problem?"
  • Logs — timestamped textual events. Voluminous. They answer "what exactly happened?"
  • Traces — the journey of a request across all services. They answer "where in the chain is the slowness?"

Lesson 3 details each one, with the costs and the pitfalls.

What should you monitor first?

The four golden signals defined by Google:

  1. Latency — the response time.
  2. Traffic — the volume of demand.
  3. Errors — the failure rate.
  4. Saturation — how full your critical resources are.

If you can only monitor four things, these are the ones. Not CPU load — this is explained in lesson 4.

What is an SLO and an error budget?

An SLO is an internal numeric target, for example "99.9% of requests served in under 300 ms over 30 days".

The error budget is its complement: with 99.9%, you are entitled to 0.1% of failures, roughly 43 minutes per month.

This budget becomes a decision-making tool: if it is exhausted, new features are frozen so the team can focus on reliability. Lesson 5 explains everything.

Prometheus or Datadog?

Prometheus + Grafana — free, open source, the de facto standard on Kubernetes. But you operate it yourself.

Datadog (or New Relic, Dynatrace, Grafana Cloud) — immediately operational, very complete, but the cost grows quickly with the number of machines.

A simple rule: small team without operations skills → commercial offering. Team already comfortable with Kubernetes → Prometheus. Lesson 6 compares in detail.

Why does my team ignore alerts?

That is alert fatigue, and it is a design problem, not a discipline problem. It comes from three causes:

  • Alerts that require no action ("CPU load at 80%" — so what?).
  • Too many alerts, most of which are false positives.
  • Alerts that do not say what to do.

Golden rule: an alert that wakes someone up must require immediate human action. Otherwise, it is not an alert, it is a dashboard. See lesson 6.


Want to move on to practice?

This discovery course explains what to measure and why, without any configuration. To install Prometheus, write PromQL queries, build Grafana dashboards, centralize logs with Loki and trace with Jaeger, move on to the Premium Monitoring and Logs course — included in all our paid plans.


Other discovery courses not to miss


Ready? Start with lesson 1 →