Monitors
/monitors. Needs module.monitors.
Uptime-style monitoring of the internal services you care about: the intranet, the print server, the Wi-Fi controller, the library system.
Monitor kinds
Section titled “Monitor kinds”| Kind | Checks |
|---|---|
| HTTP | A GET or HEAD against a URL, optionally asserting a status code or a keyword in the body |
| TCP | Opens a socket to a host and port |
| TLS | Completes a handshake and checks certificate expiry |
| PING | Best-effort reachability |
| AGENT | Heartbeat freshness of a connector agent |
The agent kind is inverted from the others. Nothing can reach an agent inside a customer network, so the check is “did it report recently” rather than an outbound probe.
Creating one
Section titled “Creating one”Give it a name, a kind, a target, an interval and a timeout.
Names matter more than you would think. Intranet is better than
http://10.0.4.19:8080, because the name is what appears in an alert at 7am and
on the public status page.
The keyword assertion
Section titled “The keyword assertion”The most useful option on an HTTP monitor. A web server returning 200 with an error page is a service that is down and a check that passes.
Assert on a keyword that appears only when the service works: a student’s name on a dashboard, or a term that renders after a successful database query.
Alerts
Section titled “Alerts”Monitors raise severity-based alerts when something goes down or degrades, and
send the monitor.down email to staff who can
view monitors.
Send alerts to a monitored mailbox rather than a personal one, so somebody reads them while the owner is on leave.
History
Section titled “History”Each monitor keeps its check history, so you can answer “how long has this been flapping” rather than guessing.
A service that fails one check in twenty is a different problem from one that has been down since Tuesday, and the history is what tells them apart.
Publishing
Section titled “Publishing”Mark a monitor public and it appears on the public status
page at /status, which needs module.statusPage.
Publish the things your community asks about: the Wi-Fi, the intranet, the printing. Do not publish internal infrastructure whose name would mean nothing to a student and everything to somebody scanning your network.
Do not monitor Plugboard with Plugboard
Section titled “Do not monitor Plugboard with Plugboard”A monitor that lives inside the thing it is watching cannot tell you the thing is down.
Point an external uptime check at /api/health/ready. See keeping an eye on
it.
Private addresses
Section titled “Private addresses”Plugboard blocks outbound requests to private, loopback and link-local addresses by default, so a monitor target cannot be used to reach internal hosts or a cloud metadata service.
A self-hosted install that legitimately monitors LAN addresses needs:
ALLOW_PRIVATE_EGRESS=1A managed deployment needs a connector agent instead, or a target reachable from the internet.
Permissions
Section titled “Permissions”| Permission | Allows |
|---|---|
monitor.view |
See monitors and their history |
monitor.manage |
Create and configure them |