Prometheus + Grafana Monitoring
Server monitoring with Prometheus and Grafana
The purpose of monitoring is simple: to hear about a problem before your customers do. The difference between "the site was down for an hour overnight" and "it was down until morning, when somebody wrote in" comes down to exactly this.
What I set up
- Site availability from outside: it responds, returns the expected status code, the certificate has not expired.
- Resources: CPU, memory, disk space, network.
- Application metrics: response time, 5xx errors, PHP worker queue, database health.
- Dashboards for your stack — so that during an incident you open one page instead of hunting through logs.
- Alerts to the channel you actually watch: email, messenger.
The main rule about alerts
Alerts people stop reacting to are worse than no alerts. If the system sends a dozen emails a day, within a week they get filtered into a folder. So I configure the minimum: alarms only for things that need action right now, with separate channels for "important" and "critical".
The single most useful metric
From experience: disk space. The most frequent cause of sudden failures is neither an attack nor load, but simply running out of space — the database stops writing and the site starts returning errors. An alert at 80% capacity closes that risk entirely.
Where to start on a limited budget
Not with deploying a full stack. A simple external availability check plus downtime alerts covers the biggest risk and is quick to configure. Full metric collection makes sense once there is something to analyse — several servers, or recurring load problems.
Tags: prometheus, grafana, monitoring, alerting, devops