Metrics & alerts

How samples are collected

Provisore samples every server over SSH every five minutes, with no setup. For finer data, install the on-server collector under Monitoring in the server's Settings. It sends a sample roughly every 30 seconds.

• The collector is a systemd timer with its own credential. Installing it again replaces the credential, and the old one stops working at once.
• Removing it revokes the credential, and the server goes back to SSH sampling on the next cycle. Collection never stops.
• The collector reads as not installed, awaiting first sample, reporting, or silent. A collector that was reporting and has stopped reads as silent, not healthy.

What is collected

• CPU load, normalised per core so that 1.0 means fully busy, plus the 5- and 15-minute averages.
• Memory and swap used against total.
• Disk and inode usage on the root filesystem.
• Whether nginx, php-fpm, postgresql, mysql, redis, and memcached were running when the sample was taken.
• Pending operating-system updates, how many are security updates, and whether the server is waiting on a reboot. These are read once a day, from the same apt-check that writes the login banner, so the numbers match what you see over SSH. Check now on the server's Overview reads them straight away.

A server that patches itself always has updates waiting, so the counts alone raise nothing. Two things are flagged, because neither resolves on its own. One is a required reboot. The other is security updates that unattended-upgrades skipped and left behind, usually because the update would prompt about a configuration file you edited, and an unattended run never answers.

Anything beyond CPU, memory, and disk can be missing, for example on a server without the tool that reports it. The chart shows that as no data, not as zero.

The charts on a server's Overview cover the last hour, 6 hours, 24 hours, or 7 days. Samples are kept for 24 hours on Solo, 7 days on Pro, and 7 days on Scale. The last six hours stay at full resolution, and anything older is averaged into five-minute buckets.

Alert rules

Rules are set per server, under Alerts in the server's Settings. Adding or editing a rule needs the Pro plan or above. There are two kinds:

• Threshold. A metric (cpu, memory, disk, swap, inodes, load5, load15) above or below a value. Usage metrics are percentages up to 100. The load metrics go up to 1000, so you can alert at 200% of the server's cores.
• Service down. One of the monitored services is not running.

Both take a duration, and the condition must hold that long before the rule fires, so a single spike does not trigger it. When a rule fires, your notification channels receive alert.triggered, then alert.resolved when the condition clears.

Name       Disk above 85%
Metric     disk above 85%
Sustained  15 minutes

Name       Memory above 90%
Metric     memory above 90%
Sustained  15 minutes

Provisore adds these rules when a server goes active. They wait that long because a deploy fills memory and disk while it builds. Edit or delete them like any other rule. A deleted default does not come back.

A sample that does not include a rule's metric counts as no data, which can neither trigger the rule nor clear it. Editing a rule's condition resets its current state.