Skip to content
MZPanel MZPanel
Monitoring Real metric charts, threshold alert rules, a live snapshot and a log tail for a server.
CtrlK

Monitoring

The Monitoring section of a server (/servers/:id/monitoring) is the box’s observability surface: historical CPU / RAM / disk / network charts, a live snapshot, the top processes, threshold-based alert rules, and a live Logs tail — all from real agent data. It’s available on all plans. Two tabs live here: Metrics (the default) and Logs.

Create an alert rule, step by step

Section titled “Create an alert rule, step by step”
  1. Scroll to Alert rules and click New rule to open the rule drawer.
  2. Give it a Title (e.g. “CPU above 90%”).
  3. Pick the Metric — CPU %, RAM %, Disk %, Swap %, Load (1m), Network KB/s, or a container-health metric (unhealthy / stopped containers).
  4. Set the Operator (>, <, ==) and a Threshold.
  5. Set the Duration — how long the condition must hold before it fires (e.g. 5m; immediate fires on the first breach). This is the anti-flap window.
  6. Choose a Severity (warning or critical) and tick the Channels to notify. Channels come from your account-wide Chat & Alerts connections.
  7. Leave Active on and Create rule. The rule persists on the control plane and the alert worker starts evaluating it against every heartbeat.

What else you can do

Section titled “What else you can do”
  • Read the charts — four cards (CPU, RAM, Disk, Network rx/tx) plot real history bucketed from agent heartbeats. Hover for a crosshair chip naming the exact time and value; a gap reads “no data” rather than a carried value.
  • Change the time range — the 1h / 6h / 24h / 7d / 30d segmented control re-buckets the history. Longer ranges fill in as history accumulates.
  • Go Live — the Live toggle flips the shared poll cadence to ~3s (vs ~15s) so the headline numbers update in near real time. It drives the right-sidebar gauges in lock-step, so the two can never disagree.
  • Live snapshot — uptime, 1-minute load, memory, swap, process count, top CPU process, kernel and hostname from the current mz metrics reading.
  • Top processes — the live “what’s eating the box” table; toggle By CPU / By RAM to find a runaway process.
  • Manage rules — pause/resume, edit, or delete any rule; a firing rule shows a pulsing Firing pill.
  • Channels — the connected notification destinations are listed with a Send test; add or edit them in Chat & Alerts (one place, reused by rules here and by Uptime).
  • Logs tab — a live-feeling tail of the box’s system and service logs (nginx access/error, php-fpm, mariadb, syslog, auth). Pick a source and Refresh to re-run the tail.

How it works

Section titled “How it works”

Monitoring stitches together three real data paths:

  • Charts read GET /v1/servers/:id/metrics/history?range=…. The agent appends one metric sample per heartbeat into the server_metrics table; the API buckets and averages that series per range (CPU, RAM, disk, swap, load, net rx/tx). This works even while the box is briefly offline, since it reads stored history.
  • Live snapshot, headline numbers and top processes come from the metrics.get job — the agent runs mz metrics --json natively. The same snapshot feeds the right-sidebar gauges and the Servers list cards, so every surface shows one number.
  • Alert rules are persisted per-server on the control plane. A server-side alert worker loads active rules each tick, reads each server’s latest heartbeat metrics, evaluates the threshold against the duration window, and — on transition to firing — delivers to the rule’s channels over real HTTPS (webhook / Slack / Telegram). Email delivery needs SMTP configured on the control plane. Container-health metrics are computed from the agent-pushed Docker inventory cache, not the heartbeat.
  • Logs dispatch a logs.tail job — the agent runs mz logs <target> --json and returns a one-shot snapshot of that log file.

CLI & automation

Section titled “CLI & automation”

The metric and log reads are plain box-level mz commands — the same engine the dashboard drives. SSH in and run them, or let an on-box AI (ClaudeCode) read them the same way:

Terminal window
mz metrics --json                     # the live snapshot (CPU, RAM, load, top procs)
mz logs sources --json                # which log targets the box exposes
mz logs nginx-error --lines 200 --json
mz logs syslog --lines 200 --json

Alert rules are managed on the control plane (dashboard or the API), not through mz. See The mz CLI and the command catalog.

Gotchas & troubleshooting

Section titled “Gotchas & troubleshooting”
  • History accumulates from when monitoring began. The charts render only the samples already stored, so a fresh server shows “Collecting metric history…” and the longer ranges (7d / 30d) fill in over time — they are not back-filled.
  • A rule only fires while the box is heartbeating. The alert worker evaluates the last heartbeat metrics; if the agent is fully offline there are no new samples to breach a threshold. Use Uptime monitoring for “is the box/site reachable at all” — it probes from the outside and is the right tool for hard-down detection.
  • Email channels can be saved but inert. Webhook / Slack / Telegram deliver with no extra infrastructure; email is only sent if the control plane has SMTP configured, otherwise the channel is skipped with a logged warning.
  • Offline shows a Preview banner with example data. When the agent is offline the section still renders (with a “Preview” banner and last-known/example values) so the layout is reviewable, and the Logs tab falls back to synthetic sample lines. Live reads, the snapshot, and log tails resume when mzagent reconnects.
  • ?tab=logs deep-links the Logs tab. The old /servers/:id/logs route now redirects here, so bookmarks keep working.
Section titled “Related”