Without monitoring, you find out about problems when someone complains: the website has been down for hours, the server disk has been full for days, the certificate expired this morning. With well-designed monitoring you learn about them first, often before users even notice. You do not need expensive tools: you need to know what to measure and how to turn measurements into useful alerts.
Three kinds of information
| Type | Question it answers | Example |
|---|---|---|
| Availability checks | Is the service responding? | The site returns 200 within 2 seconds |
| Metrics | How is it doing over time? | CPU usage, disk space, traffic on the WAN port |
| Logs | What exactly happened? | Application errors, failed logins |
The three complement each other: a check tells you something is wrong, metrics show the trend that led to the problem, logs explain why.
Availability checks
These are the starting point and can be run at several levels:
- ping (ICMP): the device is on and reachable on the network;
- TCP port: the service accepts connections, for example on port 443 or 25;
- HTTP: the site responds with the expected code and, better still, the page contains a specific piece of text, so you can tell a real page from an error page returned with status 200;
- DNS: the domain resolves to the correct address;
- TLS certificate: more than a set number of days remain before expiry.
Run at least some checks from outside your network. A monitor running on the same server it is supposed to watch goes silent exactly when that server goes down, and one inside the network will not notice if the Internet line has dropped.
The metrics that matter
For a server:
- free disk space, the most banal and most frequent cause of outages;
- memory and CPU usage, paying attention to sustained values, not momentary spikes;
- drive health (SMART attributes) and RAID status;
- application response times.
For the network:
- traffic and errors on router and switch interfaces;
- latency and packet loss towards a few reference points, such as the provider's gateway and a couple of external services;
- the number of devices connected to access points.
Many network devices expose this information via SNMP, a standard management protocol. Use version 3, which provides authentication and encryption, and restrict access to the monitoring machine alone.
Tools
There are solutions for every scale:
- external uptime services, many with a free tier, to check sites and ports from multiple locations;
- lightweight self-hosted tools such as Uptime Kuma, handy for a home network or small office;
- full platforms such as Zabbix, or the Prometheus and Grafana combination, to collect metrics from many systems and build dashboards and alert rules;
- centralised log collection, starting with a simple syslog server, so you do not have to log into every device hunting for the relevant lines.
Useful alerts, not noise
The most common problem is not having too few alerts but too many. After a few days of pointless notifications people stop reading them, and the important one gets lost. Some rules:
- Alert only on what requires action. A one-minute CPU spike is not a problem; a disk at 90% growing 2% a day is.
- Use thresholds with duration. "Site unreachable for three consecutive checks" rather than "one failed check".
- Distinguish severity. A service that is down deserves an immediate phone notification; a certificate expiring in thirty days only needs an email.
- Group dependencies. If the router goes down, you do not need twenty alerts for the twenty services behind it.
- Send alerts through an independent channel. If email is hosted on the server that has stopped, the email alert will never arrive.
Look back too
Keep metric history for a few months. It lets you see trends, such as growth in used space, plan an expansion in time and, after an incident, reconstruct what changed and when. Logs should also be retained for a defined period and protected from tampering: they are often the only source for understanding where a problem came from.
In short
- Combine availability checks, metrics and logs: they answer different questions.
- Run checks from outside the network too, and monitor certificate expiry dates.
- Disk space is the most banal and most neglected metric.
- Configure alerts with thresholds, durations and severity levels, delivered on an independent channel.
- Keep history to spot trends and reconstruct incidents.
