--- type: Article title: "Server Monitoring Checklist" description: "A server monitoring checklist in order: from enabling the SNMP agent to alerting from outside the box, with the real OIDs and commands at each step." resource: "https://snmp-monitoring.com/guides/checklist/" tags: [guides, snmp] timestamp: 2026-07-13T00:00:00Z --- # 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." ![Diagram: a server monitoring checklist workflow from installing snmpd through allowlisting OIDs to adding an external checker](https://snmp-monitoring.com/img/guides/server-monitoring-checklist-flow.webp) ## 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. 1. **Install the SNMP agent.** On Debian or Ubuntu, install snmpd and confirm the service is enabled. The [install snmpd guide](/setup/install-snmpd-ubuntu-debian.md) has the packages and the daemon toggle in `/etc/default/snmpd`. 2. **Write a locked-down snmpd.conf.** Configure read-only SNMPv2c — a `com2sec`/`group`/`view`/`access` chain that grants read only. The [snmpd.conf reference](/setup/snmpd-conf.md) has the full template. 3. **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](/setup/secure-community-string.md). 4. **Allowlist your OIDs.** Add one `view ... included` line per OID you intend to poll, so the agent exposes those and nothing else. The [OID allowlist guide](/setup/oid-allowlist.md) shows the exact syntax. 5. **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](/setup/custom-port.md). 6. **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](/sensors/index.md) and [network sensors](/sensors/network/interface-traffic.md) list the OIDs. 7. **Verify every OID responds.** Walk each one with `snmpwalk` and confirm real values come back. An empty walk here means the OID isn't in your allowlist — fix it now, not during an incident. 8. **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. 9. **Add an external check.** Point an off-host monitor at the same endpoint, so the server's own failure can't silence its alerts. 10. **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](/setup/troubleshooting.md) 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. ```bash # CPU load per core (percent): snmpwalk -v2c -c : 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 : 1.3.6.1.2.1.25.2.3.1.3 snmpwalk -v2c -c : 1.3.6.1.2.1.25.2.3.1.5 snmpwalk -v2c -c : 1.3.6.1.2.1.25.2.3.1.6 # System uptime (a reset means a reboot): snmpget -v2c -c : 1.3.6.1.2.1.25.1.1.0 # Interface traffic counters: snmpwalk -v2c -c : 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](/monitoring/double-durability.md): an independent observer, off the host and outside your network, keeps polling and alerting even when the server has gone dark. [ostr.io Monitoring](https://ostr.io/service/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. ![Illustration: a monitoring setup checklist with ticked items for agent, community string, OID allowlist, thresholds, and external check](https://snmp-monitoring.com/img/guides/monitoring-setup-checklist.webp) ## FAQ **What's the minimum I should monitor on a server?** CPU, memory, disk, and uptime cover the essentials, with network interface traffic close behind. Disk is the one people forget and the one that most often causes an outage, so never leave `hrStorageUsed` off the list. Everything else is a refinement on top of those. **How often should I poll each metric?** Every one to five minutes is the common range for resource metrics — frequent enough to catch a developing problem, infrequent enough not to load the agent. A dual approach works well: poll fast for a live view and slower for long-term trend history. **Do I need SNMPv3 for this checklist to be secure?** Not necessarily. SNMPv2c with a random community string, a read-only allowlist, and a non-default port is a reasonable baseline on a trusted network. Step up to SNMPv3 when you need authentication and encryption, such as polling over the public internet. **Why is "test the alert" a separate step?** Because a threshold you've never tripped is a guess, not a guarantee. Plenty of monitoring setups look complete but silently fail to deliver — a broken mail relay, a muted channel, a typo in a contact. Deliberately triggering one alert proves the whole chain works before a real incident tests it for you. ## Conclusion A good server monitoring checklist isn't busywork — it's the difference between monitoring that holds up and monitoring that quietly has holes. Secure the agent, allowlist real OIDs like CPU at `1.3.6.1.2.1.25.3.3.1.2` and storage at `1.3.6.1.2.1.25.2.3.1.6`, verify every walk returns values, set duration-based thresholds, and test that the alert actually arrives. Then finish the monitoring setup checklist the way it has to end: with an external checker that keeps watching when the server can't watch itself. Once this is ticked off, the rest of the [SNMP guides](/guides/index.md) and the [SNMP monitoring home](/index.md) round out the picture.