Set up Plesk Monitoring with Grafana graphs and email alerts

Every Plesk Obsidian server can graph its own CPU, memory, disk, and per-service resource use without a third-party agent. The Monitoring extension (formerly Advanced Monitoring) collects the metrics with collectd, renders them through the Grafana extension, and emails you when a threshold is crossed. It's free, runs locally, and takes about five minutes to set up.

This guide covers the single-server built-in mode: install, choosing which alerts matter, setting thresholds in bulk from the shell, and the three failure modes that leave you with blank graphs. If you run a fleet and want uptime checks from outside the server, read Plesk 360 centralised license and monitoring setup as well. The two approaches complement each other.

Built-in Monitoring vs 360 Monitoring

When you open Monitoring for the first time, Plesk asks you to pick a mode. Choose based on what you need to catch:

Built-in mode has one weakness: it runs on the machine it watches. If the server hangs, loses networking, or fills its disk, the alerts stop too. Use built-in Monitoring for capacity trends and service-level resource alerts. Use an external check (360 Monitoring or anything else outside the box) to find out the box is down.

Install Monitoring and Grafana

Both extensions come preinstalled on most Obsidian builds, but Grafana is no longer pulled in automatically. Since Grafana moved to the AGPLv3 license, installing Monitoring prompts you to add Grafana separately. The current Monitoring release requires Plesk 18.0.53 or later.

From the shell:

plesk bin extension --install monitoring
plesk bin extension --install grafana
plesk bin extension --list | grep -Ei 'monitoring|grafana'

Or in the panel: Extensions → Extensions Catalog, search "Monitoring", install, then accept the Grafana prompt. Open Monitoring from the left sidebar and pick Built-in Monitoring.

Confirm the collector and extension state before you go further:

plesk ext monitoring --installation --get-status
systemctl status collectd --no-pager

collectd also appears under Tools & Settings → Services Management, so you can restart it without shell access. The graphs fill in over the first 10–15 minutes. Anything older than the install time stays empty, because there's no backfill.

Read the dashboard

Metrics are split across five category tabs plus Overview. The Overview tab shows the graphs Plesk treats as critical by default. Click the star icon on any graph in another tab to pin it there, and use Rearrange to drag the layout into the order you check things.

Two defaults are worth changing on day one:

• Time range: the default is the last 24 hours. For capacity planning, switch to 7 or 30 days using the custom From/To range. Short spikes get averaged out at long ranges, so use 1 hour when you're chasing an incident.
• Auto-refresh: the default is every 2 minutes, and you can pick anything from 5 seconds to 1 hour. Leave it at 2 minutes unless you're watching a live incident. A 5-second refresh on an open browser tab adds its own load to Grafana.

The per-service graphs are the useful part. Memory and CPU are broken out by web, mail, and database process groups, so a MariaDB memory creep or a runaway PHP-FPM pool shows up as its own line instead of hiding inside the total. If the database line is the one climbing, go to MariaDB tuning for shared hosting. The my.cnf advice applies to Plesk too.

Configure email alerts

Go to Monitoring → Settings. Each resource has a toggle and a threshold, and some take both an absolute value (MB, GB) and a percentage. Three notification events are available:

• Resource usage threshold has been exceeded
• Resource usage value is back to normal
• Monitoring agent has detected an issue

Keep all three on. The "back to normal" email is what lets you close a ticket without logging in, and the agent-issue email is your only warning that collectd has stopped collecting. Alerts go to the Plesk administrator's email address, so make sure Profile → Email points to a monitored mailbox and not root@hostname.

Plesk enables a set of thresholds by default. On shared hosting nodes they tend to fire too often on memory, because the Linux page cache makes "used" memory look high. In practice, disk-space and inode alerts matter most. A full /var breaks mail, databases, and Plesk itself at the same time.

Set thresholds from the command line

Clicking through the Settings page doesn't scale beyond two servers. The plesk ext monitoring utility exposes the same thresholds, so you can script them and apply one policy across every box.

List the panel IDs and threshold targets first:

plesk ext monitoring --overview --list-panel-ids
plesk ext monitoring --overview --list-targets
plesk ext monitoring --thresholds --list -format json

Set a single threshold. This alerts when the web process group uses more than 40% of RAM:

plesk ext monitoring --thresholds --set -panel-id memory_usage__web -target sw_mem-Web:ps_rss:value -operator greater_than -type percent -value 40

To standardise a fleet, export the thresholds from one tuned server and import them everywhere else:

plesk ext monitoring --thresholds --list -format json > /root/monitoring-thresholds.json
scp /root/monitoring-thresholds.json root@node2.example.com:/root/
ssh root@node2.example.com 'plesk ext monitoring --thresholds --set-from-file -path /root/monitoring-thresholds.json'

Check the exported JSON before you import it on a server with different disks or mount points. Disk-panel targets are tied to device names, so a threshold for /dev/sda does nothing on an NVMe box. --thresholds --restore-defaults resets a server if an import goes wrong.

Fix empty graphs and metric errors

Three things cause most "No data" panels.

collectd isn't running

If every graph is flat from a particular time onwards, the collector has stopped. Older Plesk builds sometimes failed to restart it after a reboot.

systemctl enable --now collectd
journalctl -u collectd --since "1 hour ago" --no-pager | tail -20

Extension state is broken

A "Metric request error" (HTTP 500) or panels that never load usually mean the Monitoring and Grafana extension versions no longer match. This happened across the fleet when Grafana 8.0 arrived and old Monitoring builds flooded /var/log/messages with "plugin unavailable" alert errors. Update both extensions, then let the built-in repair re-provision the data source and dashboards:

plesk bin extension --upgrade monitoring
plesk bin extension --upgrade grafana
plesk ext monitoring --installation --fix

If the panel itself is misbehaving beyond Monitoring, the Plesk repair utility and the Plesk update failures guide cover the wider cleanup.

Firewall blocks the local Grafana backend

Grafana listens on localhost and Plesk proxies it through port 8443, so you don't need to open any extra ports. If you've written custom iptables rules that drop loopback traffic, though, the graphs fail silently. Check that lo is allowed in your ruleset, especially if you manage rules outside the Plesk Firewall extension.

Pair it with Watchdog for auto-restart

Monitoring alerts but never takes action. If you want Plesk to restart a crashed Apache, nginx, MariaDB, or Postfix on its own, enable the separate Watchdog extension on Linux. Watchdog brings services back up, and Monitoring tells you it happened and whether resource use was climbing beforehand. Together they cover most of what a small host needs without paying for external APM.

Next steps

• Plesk 360 setup for centralised licenses and monitoring
• Configure Plesk Fail2Ban jails
• Plesk license tiers explained. Compare editions or buy a Plesk license.