Server Monitoring Checklist
Setting up monitoring is one of those jobs that's easy to do halfway and hard to do right. You enable the daemon, you glance at a graph, you move on — and six weeks later a disk fills up and nobody gets paged. This server monitoring checklist walks the whole path in order, from turning on the SNMP agent to alerting from outside the box, with the real OIDs and commands at each step. Work through it top to bottom and you'll have a monitoring setup checklist you can actually trust, not a dashboard that looks busy while missing the one thing that matters.
Why a checklist beats "I'll set it up later"
Ad-hoc monitoring fails in a predictable way. Someone installs snmpd on a Friday, confirms one OID responds, and calls it done. Nobody wrote down which metrics are covered, nobody set a threshold, and the community string is still public on the default port. It works right up until it doesn't, and then you're reconstructing the whole thing under pressure while the site is down.
A checklist fixes the two things that actually go wrong: gaps and drift. Gaps are the metrics you forgot to watch — usually disk, until it's full. Drift is the config that was fine at setup and quietly rotted, like an agent still listening wide-open on UDP 161. Going through a written sequence forces every server to clear the same bar. It also makes the setup reviewable: a teammate can read the list and see, at a glance, what's covered and what's missing. That's the whole point of a monitoring setup checklist — turning "I think it's fine" into "here's exactly what we watch, and here's the proof it responds."
What a complete monitoring setup covers
Before the steps, know the shape of the finished thing. A solid setup has four parts, and skipping any one leaves a hole.
- A secured agent — snmpd running with read-only SNMPv2c, a random community string, an OID allowlist, and a non-default port.
- The right metrics — CPU, memory, disk, uptime, and network, drawn from the standard Host Resources MIB (RFC 2790) and IF-MIB (RFC 2863).
- Sane thresholds — duration-based limits that alert on sustained problems, not momentary spikes.
- An external checker — an independent watcher off the host, so a crashed server still raises the alarm.
Miss the first and you've opened an attack surface. Miss the second and you're blind to the failure that eventually bites. Miss the third and you drown in false pages until you mute everything. Miss the fourth and your monitoring dies exactly when the server does. The rest of this page is those four parts, expanded into concrete steps you can tick off.
The step-by-step server monitoring checklist
Follow these in order — each step assumes the one before it worked.
- Install the SNMP agent. On Debian or Ubuntu, install snmpd and confirm the service is enabled. The install snmpd guide has the packages and the daemon toggle in
/etc/default/snmpd. - Write a locked-down snmpd.conf. Configure read-only SNMPv2c — a
com2sec/group/view/accesschain that grants read only. The snmpd.conf reference has the full template. - Replace the community string. Never ship
public. Use a long random string; on v2c it's sent in clear text, so treat it like a password. See securing the community string. - Allowlist your OIDs. Add one
view ... includedline per OID you intend to poll, so the agent exposes those and nothing else. The OID allowlist guide shows the exact syntax. - Move off the default port. Change the agent from UDP 161 to a random high port to cut down on drive-by scans. Walk through it in changing the SNMP port.
- Choose the metrics. Decide what you're watching before you wire up alerts. At minimum: CPU, memory, disk, uptime, and interface traffic — the sensor & OID catalog and network sensors list the OIDs.
- Verify every OID responds. Walk each one with
snmpwalkand confirm real values come back. An empty walk here means the OID isn't in your allowlist — fix it now, not during an incident. - Set duration-based thresholds. Define warning and critical levels, and require each to hold for a few minutes before it fires. This one rule kills most false alarms.
- Add an external check. Point an off-host monitor at the same endpoint, so the server's own failure can't silence its alerts.
- Test it end to end. Deliberately trip a threshold and confirm the alert actually lands. Untested alerting is just decoration.
If a walk misbehaves along the way, the troubleshooting guide covers the usual suspects — wrong port, wrong community, firewall, or a missing view line.
The config and the OIDs to verify
Here's the verification pass in one place — the commands from step 7, against the metrics that matter. Run each and confirm you get numbers, not silence.
# CPU load per core (percent):
snmpwalk -v2c -c <community> <host>:<port> 1.3.6.1.2.1.25.3.3.1.2
# Storage: name, size, used (root filesystem is the one to watch):
snmpwalk -v2c -c <community> <host>:<port> 1.3.6.1.2.1.25.2.3.1.3
snmpwalk -v2c -c <community> <host>:<port> 1.3.6.1.2.1.25.2.3.1.5
snmpwalk -v2c -c <community> <host>:<port> 1.3.6.1.2.1.25.2.3.1.6
# System uptime (a reset means a reboot):
snmpget -v2c -c <community> <host>:<port> 1.3.6.1.2.1.25.1.1.0
# Interface traffic counters:
snmpwalk -v2c -c <community> <host>:<port> 1.3.6.1.2.1.2.2.1
Keep this table as your coverage record — tick each row once its walk returns clean:
| Check | OID | MIB / standard | Alert when |
|---|---|---|---|
| CPU load | 1.3.6.1.2.1.25.3.3.1.2 | Host Resources (RFC 2790) | Sustained high |
| Storage used | 1.3.6.1.2.1.25.2.3.1.6 | Host Resources (RFC 2790) | Over ~85% full |
| Uptime | 1.3.6.1.2.1.25.1.1.0 | Host Resources (RFC 2790) | Unexpected reset |
| Interface traffic | 1.3.6.1.2.1.2.2.1 | IF-MIB (RFC 2863) | Abnormal throughput |
Closing the loop: monitor it from outside
Nine of those ten steps run on the server. That's the flaw hiding in almost every server monitoring checklist — if the agent, the thresholds, and the alert sender all live on the same box, then the box's own failure takes them all out together. A crashed host doesn't email you to say it crashed. A CPU pinned to 100% may never schedule the notifier. The single moment you most need the page is the moment the local stack can't send it.
Step 9 exists to break that dependency. This is double durability: an independent observer, off the host and outside your network, keeps polling and alerting even when the server has gone dark. ostr.io Monitoring is the zero-setup way to add it — it polls your SNMP health metrics externally and fires real-time email and SMS alerts on downtime, resource spikes, and even SSH logins, so your checklist ends with a safety net the server can't switch off. Pair it with on-host tooling and you've got alerts from two directions instead of one.
