Free through lesson 3

Monitoring & Observability for Beginners

From telling symptoms apart from causes to structured logs, Prometheus metrics, Grafana dashboards, Alertmanager notifications, OpenTelemetry distributed tracing, and SLOs with error budgets. Over 30 lessons, you'll get to the point where you notice problems in your own service before your users do. You'll actually run Prometheus, Grafana, Alertmanager, and OpenTelemetry on your own machine, and every output shown here was really measured.

Start from lesson 1 Unlock every course

Curriculum

The 30 lessons are split into 6 chapters. We recommend going in order from chapter 1, but feel free to jump to whatever interests you. Note: commands can't run in the browser, so try them on your own machine with Prometheus, Grafana, and OpenTelemetry installed. The sample app runs on the Python standard library alone. Domains and host names have been replaced with example values (such as shop.example.com).

Chapter 1 — What Do You Want to Know About? (lessons 1–4)

Before monitoring is about tools, it's about what you want to know. You'll separate symptoms from causes, pick the four signals worth measuring, and decide up front when it's worth waking someone up.

Monitoring vs. Observability

Monitoring watches questions you decided on; observability lets you ask new ones later. How logs, metrics, and traces split the work, plus the tools for this course.

Free

Separating Symptoms from Causes

Users see symptoms; you fix causes. Build a table that maps each symptom to where to look, so you know which signal to check first.

Free

The Four Golden Signals

Latency, traffic, errors, saturation. Decide on these four and you won't wonder what to measure. How to measure each, and why to use quantiles instead of averages.

Free

Avoiding Alert Fatigue

An alert nobody acts on is worse than none. When to wake someone, why for checks duration, how to set thresholds, and what to do with alerts that never fire.

Chapter 2 — Logs (lessons 5–11)

First, you'll make your logs searchable after the fact. You'll structure them, settle on levels, strip out personal data, and get to the point where you can follow a single request with a trace_id.

Structured Logs: Output You Can Search Later

You can't search print statements and plain-text logs. Swap the logging Formatter to output JSON and make your logs machine-readable.

Designing Log Levels

How to choose between DEBUG, INFO, WARNING, and ERROR, using the rule that ERROR is for people to look at. Plus the default level in production and temporarily raising it.

Keeping Personal Data Out of Logs

Logs get copied and stick around for a long time. Scrub emails, card numbers, and tokens before they're written. How to mask them, and how to avoid passing them in at all.

Collecting and Storing Logs

Have the app just write to standard output and leave collection to something else. Measuring rotation by size and deletion by age, and estimating retention.

Searching Logs

Narrow down 3,000 lines with grep and jq. Count, filter by condition, read a single request. Because the logs are structured, each takes one line.

Tying Together a Single Request

One request turns into several log lines. Put a shared trace_id on every line to bundle lines scattered over time into one story.

Spotting Problems from Logs

Don't read logs; turn them into numbers. Counting error rates, sampling down noisy logs, and putting a brake on costs before they blow up.

Chapter 3 — Metrics (lessons 12–18)

Keeping numbers as time series reveals trends and anomalies. You'll write your own /metrics, have Prometheus come and collect it, and use PromQL to get latency and error rates.

The Four Metric Types

Counter, gauge, histogram, summary. Choose by whether it only goes up, goes up and down, or needs a distribution. Pick the wrong type and your graphs lie.

Writing /metrics Yourself

The Prometheus exposition format is just text. Write a /metrics endpoint that lists numbers with HELP and TYPE, using only the standard library.

Running Prometheus and Scraping

All it takes is listing targets in prometheus.yml. See for real how labels get attached, what target health looks like, and what up shows when a target goes down.

PromQL Basics

Instant vectors and range vectors, rate and sum by, and division for error rates. Learn by running queries locally with promtool query instant.

Histograms and Quantiles

histogram_quantile computes p95 from cumulative buckets. Why your choice of buckets sets the accuracy, and using it alongside average latency.

Label Design and Cardinality

Add one label and your time series multiply. Run a bad example that includes user_id and watch how fast it explodes.

Recording Rules and Meta-Metrics

Precompute heavy expressions and give them names. How to write recording rules, and the scrape health checks Prometheus reports about itself.

Chapter 4 — Visualization and Alerts (lessons 19–23)

You'll turn numbers into something people can look at, and when nobody is looking, call them with a notification. You'll build Grafana dashboards and set up Alertmanager receivers, grouping, and silences.

Running Grafana and Connecting a Data Source

Start Grafana and register Prometheus as a data source through the API. Configuring without clicking around means you can rebuild your environment.

Building Dashboards

Turn the four golden signals from lesson 3 into four panels. Dashboards are JSON, so you can create them through the API and keep them in your repository.

Writing Alert Rules

expr, for, and labels. You can unit test your rules with promtool test rules. Watch an alert actually move from pending to firing.

Receivers and Routing

Put Alertmanager in between to group, route, and deduplicate notifications. Write your own webhook receiver and look at the JSON that actually arrives.

Escalation and Silences

Use severity to choose where alerts go and how urgently. Silences during deploys, repeat_interval when things stay broken, and why notifications should link a runbook.

Chapter 5 — Distributed Tracing (lessons 24–27)

You'll see where a single request spent how many milliseconds. You'll emit spans with OpenTelemetry, connect them across services, and learn to name the slow path.

Distributed Tracing and OpenTelemetry

The signal that shows the breakdown of a single request. Run the OpenTelemetry SDK with the console exporter and emit your first span.

The Structure of a Span

Attributes, events, and status. Mark the section that failed and record exceptions as events. Plus a trick for reading the output on one line.

Connecting Across Services

Pass the trace_id along with the traceparent header. Put the trace_id in your logs too, tying metrics, traces, and logs together with one thread.

Finding the Slow Path

You can't record everything. How to choose sampling, and how to tell sequential from parallel. Use a trace to name the one place to fix.

Chapter 6 — Keeping It Going (lessons 28–30)

Monitoring isn't done once it's built. You'll use SLOs and error budgets to decide between "fix things or ship features," and keep it all running with on-call and postmortems.

SLIs, SLOs, and Error Budgets

Decide in numbers what percentage of uptime is good enough. The error budget is the time you're allowed to be down, and it tells you whether to fix or ship.

On-Call and Incident Response Patterns

Make sure whoever gets woken up knows what to do. Writing runbooks, keeping notes during an incident, and auditing alerts, so people can keep it running.

Postmortems and Wrap-Up

Postmortems so the same incident never happens twice. Rebuild all 30 lessons into one flow: notice, narrow down, read.

Once you've finished all 30 lessons, move on to GitHub Actions Fundamentals Course, which automates everything from push to deploy, or Terraform Fundamentals Course, which sets up the servers themselves as code. If you're still unsure about the basics of deploying, go back to Intro to Shipping and Running a Service. A membership unlocks every course.