Why Muppy Monitoring¶
The problem¶
Muppy already knows the state of your infrastructure. It holds your hosts, your clusters, your databases, your certificates and your backups — and it reads them, constantly, to do its job. The failure is not that Muppy cannot see a problem. It is that nobody is told.
That is not hypothetical. On one production cluster, four TLS certificate chains were broken for four different reasons — the oldest for 258 days. The renewals had failed 6.3 million times. Every fact needed to diagnose it was already in Muppy's database. No screen showed it, and no message left the building.
Muppy Monitoring closes that specific gap: what Muppy already knows, it now says.
What this is not¶
It is not a metrics stack, and it is not trying to become one. Prometheus and Grafana are good at what they do, and Muppy will not out-do them at storing time series or drawing graphs.
The line between the two is a single question:
Can you judge it from one reading, or do you need the series?
| Goes to | |
|---|---|
| A certificate expires on 17 June 2027. A cluster answers or it does not. A backup either reached S3 or it did not. A credential is valid until Thursday. | Muppy |
| CPU has been climbing for three weeks. The p99 latency doubled since the last release. Disk will be full in nine days at this rate. | Prometheus |
A state you read once and can judge belongs where the state already lives — in Muppy. A series you must accumulate to judge belongs in a time-series database. Muppy monitoring is deliberately confined to the first column, and that confinement is what keeps it from becoming a second Grafana that nobody maintains.
What we export, and what we do not¶
We publish what we are the source of. We do not relay what someone else already publishes better.
Muppy is the source of truth for your backups, so it exports them. Muppy is not the
source of truth for a cert-manager certificate — cert-manager already exports
certmanager_certificate_expiration_timestamp_seconds, and doing it again would add a
second, staler copy of an answer that already exists. So Muppy reads it, judges it, and
alerts on it — but publishes no metric for it.
This is why Muppy monitoring adds no new moving part. There is no exporter to deploy, no scrape target to configure, no dashboard server to keep alive. The checks run inside Muppy, on the schedule Muppy already runs, and the results land on the records you already open.
Three rules it obeys¶
These are not style preferences. Each one is a failure mode that was actually met.
-
Silence by default. A screen that reports everything trains you to look at nothing. A tile that is empty is good news, and it says so in words rather than going blank — because a blank panel reads as "broken", and that is how a monitoring screen stops being trusted.
-
Absence is never
OK. "We have never checked this" and "this is healthy" are different situations, and only one of them is good news. Everywhere Muppy cannot reach a verdict, it says Unknown — never OK, and never a number. On an age scale, "nothing" reads as "brand new", which is precisely how the worst case escapes a check. -
Timestamps, never ages. Muppy stores when something happened, and computes the age at the moment you read it. A stored "expires in 12 days" is only refreshed when the record changes — so it would be accurate on the certificates that are fine, and stale on the one you needed it for.
An optional layer¶
Nothing here is required to run Muppy. The checks that ship come with a schedule and with notifications on, but neither does anything on its own.
Two conditions, and neither of them announces itself when it is missing:
- Checks and periodic collection are dispatched through the message queue. Without a running IMQ worker, nothing runs — and nothing says so.
- Notifications go out through Pushover, which needs credentials in a system parameter. Without them, findings are recorded but never leave the building. See Health Checks.
If you are relying on any of this to wake you up, verify both before you trust it. A screen that looks armed is the failure this layer exists to end.
What Muppy watches¶
Monitoring is documented where the thing being monitored is documented — you read about Kubernetes health in the Kubernetes guide, not in a separate silo. This table is the map.
| What | Where it is documented |
|---|---|
| The mechanism itself — checks, results, alerts, cadence | Health Checks |
| Kubernetes objects, cert-manager chains, cluster reachability, microk8s certificates | K8s Monitoring |
| PostgreSQL backups | Backup Monitoring |
| PostgreSQL replication | Replication Monitoring |
| PostgreSQL high availability | HA Monitoring |
| Point-in-time recovery | PITR Monitoring |
| PostgreSQL activity and locks | Activity & Locks |
| Host CPU, RAM and partitions | Host Metrics |
| Hosts nobody can reach any more | Dashboard tile — not documented yet |
| Vault credentials approaching expiry | Not documented yet — see the note below |
| DNS provider credentials approaching expiry | Visible on the DNS Domain record only — not documented yet |
Gaps are listed on purpose
The last three rows are things Muppy watches — or half-watches — with no page of their own yet. They are listed rather than omitted, for the same reason a check says Unknown rather than staying quiet: a gap you can see is worth more than a gap you cannot.
In particular, Vault credential expiry is currently unreliable: the Expired flag is
computed once and not re-evaluated as time passes, so a credential that expired long ago
can still read as valid. Do not use it as your only signal until that is fixed.