CephLXXVIII · Monitoring the Monitoring PathMonitoring the Monitoring Path
Every part of the telemetry path can fail silently
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
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]
| Failure | Symptom | Detectable by |
|---|---|---|
| Manager down | no metrics | up == 0 |
| Module disabled | connection refused | up == 0 |
| Endpoint returns empty | metrics absent, up == 1 | absent() |
| Scrape times out | gaps in data | up == 0, scrape duration |
| TSDB out of disk | writes fail | Prometheus self-metrics |
| Rule evaluation failing | alerts never fire | prometheus_rule_evaluation_failures_total |
| Alertmanager down | alerts fire, nobody notified | Alertmanager self-metrics, dead man |
| Notification channel broken | alerts fire, nobody notified | end-to-end test only |
| On-call rotation empty | notification sent nowhere | process, 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
| Practice | Detects |
|---|---|
| Dead man’s switch to an external service | total pipeline failure |
up and absent() alerts | scrape-level failures |
| Prometheus self-monitoring | rule and storage failures |
| Alertmanager self-monitoring | notification path failures |
| Periodic end-to-end test | delivery to the actual channel |
| Independent second path for critical alerts | single-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
Q1. Why must a dead man's switch be received by a service outside the monitoring pipeline?
Q2. A working Prometheus and healthy scrape targets confirm that alerts will reach the on-call engineer.
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.
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