Database monitoring and observability
You collect connection, query, lock, replication and disk metrics into dashboards, write meaningful alert rules and trace a problem from metrics down to logs.
Level 301 · 15 lessons · 12 practice labs
Lessons
What to measure
- Key signals for databases
- The USE and RED methods
- Operating system metrics: CPU, memory and disk I/O
- Engine metrics: cache hits, connections and locks
- Short task: map a server’s metrics
Collecting and showing
- Metric exporters
- Prometheus queries
- Designing meaningful dashboards
- Collecting slow query and error logs
- Short task: one dashboard for two engines
Alerting and diagnosis
- Alert rules and thresholds
- Avoiding alert fatigue
- Capacity trends and forecasting
- From metrics to root cause
- Capstone: catch a quietly slowing database early
Practice labs
- Find a resource bottleneck with USE: On a slowing database server, gather utilisation, saturation and errors for CPU, memory and disk.
- Translate engine metrics into plain terms: Read cache hit, connection count and lock wait metrics and write a health summary of the server.
- Match metrics across two engines: Pair metrics that mean the same thing in MySQL and PostgreSQL and build a shared signal list.
- Read an exporter's metrics: Find the connection and query count metrics in a ready exporter's /metrics output.
- Compute queries per second with PromQL: Write queries that compute queries per second from a counter with rate() and the 95th percentile latency.
- Add a missing metric with your own exporter: Write a small exporter that reads the app-specific pending order count from the database and publishes it.
- Cut the noise from a dashboard: Reduce a forty-chart dashboard to the six most important signals and note why.
- Centralise the slow query log: Collect two servers' slow query logs in one place and find the query shape that is slow most often.
- Design one dashboard for two engines: Build one dashboard that shows PostgreSQL and Redis side by side with variables to pick the server.
- Alert before the disk fills: Write and test a rule that alerts when the disk will fill within four hours at the current rate.
- Quiet noisy alerts: Fix thresholds, durations and grouping for alerts that fire dozens of times a night.
- Catch a quietly slowing database early: Show latency creeping up over weeks with trend analysis and trace the root cause from metrics down to logs.
About this course
You collect connection, query, lock, replication and disk metrics into dashboards, write meaningful alert rules and trace a problem from metrics down to logs.
What you will learn
- What to measure
- Collecting and showing
- Alerting and diagnosis
Prerequisites
You should be comfortable with the level 101 and 201 topics of the same path.
Lab environment
Lessons run in your own Kali Linux terminal in the browser, connected to a private lab network. Nothing to install.
Frequently asked questions
- Is this course right for my level?
- The course is at level 301; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.