Skip to main content
RunBook Academy

CephLXXVIII · Monitoring the Monitoring PathMonitoring the Monitoring Path

Every part of the telemetry path can fail silently

Advanced⏱ ~17 minprometheuscephcurl

What you'll learn

  • Enumerate the failure points in the telemetry path
  • Explain why each fails silently
  • Detect each from outside the pipeline
  • Design for detectability

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Not yet marked complete on this device.

Why this matters in production

A broken monitoring pipeline produces silence, and silence is indistinguishable from health. Every other failure announces itself; this one does not.

The path and its failure points

flowchart LR
  A[Ceph daemons] --> B[Active MGR]
  B --> C[/metrics endpoint/]
  C --> D[Prometheus scrape]
  D --> E[TSDB storage]
  E --> F[Rule evaluation]
  F --> G[Alertmanager]
  G --> H[Notification channel]
  H --> I[On-call engineer]
FailureSymptomDetectable by
Manager downno metricsup == 0
Module disabledconnection refusedup == 0
Endpoint returns emptymetrics absent, up == 1absent()
Scrape times outgaps in dataup == 0, scrape duration
TSDB out of diskwrites failPrometheus self-metrics
Rule evaluation failingalerts never fireprometheus_rule_evaluation_failures_total
Alertmanager downalerts fire, nobody notifiedAlertmanager self-metrics, dead man
Notification channel brokenalerts fire, nobody notifiedend-to-end test only
On-call rotation emptynotification sent nowhereprocess, not monitoring

The bottom three are the dangerous ones: everything upstream works, alerts evaluate correctly, and nothing reaches a human.

Why each fails silently

An alert that cannot evaluate does not fire.
An alert that fires and is not delivered produces no signal.
Absence of alerts is the normal state.

There is no mechanism inside the pipeline that distinguishes “nothing is wrong” from “the pipeline is broken”, because both produce the same output: nothing.

Detecting from outside

# a dead man's switch — an alert that always fires
- alert: DeadMansSwitch
  expr: vector(1)
  labels: { severity: deadman }
  annotations:
    summary: "This alert always fires. Its absence means the pipeline is broken."
route:
  routes:
    - matchers: [ severity="deadman" ]
      receiver: deadman-webhook
      group_wait: 0s
      group_interval: 1m
      repeat_interval: 1m

An external service receives this every minute and alerts by a different path if it stops arriving. That external check is the only thing that detects a fully broken pipeline.

Designing for detectability

PracticeDetects
Dead man’s switch to an external servicetotal pipeline failure
up and absent() alertsscrape-level failures
Prometheus self-monitoringrule and storage failures
Alertmanager self-monitoringnotification path failures
Periodic end-to-end testdelivery to the actual channel
Independent second path for critical alertssingle-path failure
# an end-to-end test: trigger a benign condition and confirm delivery
ceph osd set noscrub          # raises OSDMAP_FLAGS
# confirm the alert arrives at the real channel
ceph osd unset noscrub

Quiz

Knowledge check · 4 questions

  1. Q1. Why must a dead man's switch be received by a service outside the monitoring pipeline?

  2. Q2. A working Prometheus and healthy scrape targets confirm that alerts will reach the on-call engineer.

  3. Q3. Verify a monitoring pipeline end to end.

    A team wants confidence their Ceph alerts would actually reach someone. Prometheus targets are healthy and the alert rules are in place.

  4. Q4. Which three failure points leave everything upstream working while nothing reaches a human?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Add a dead man’s switch routed to an external heartbeat service in a different failure domain — it is the only construct that distinguishes a healthy cluster from a broken pipeline. Trigger a benign real condition periodically to verify delivery reaches the actual on-call channel.

Cross-course references

  • Kubernetes: the Watchdog alert in kube-prometheus serves exactly this purpose
  • Linux: a heartbeat is what distinguishes a quiet system from a dead one