--- type: Article title: "Monitor Linux Servers via SNMP" description: "One lightweight daemon publishes CPU, memory, disk and uptime through the Host Resources MIB — the OIDs to poll on Linux and a working snmpd.conf." resource: "https://snmp-monitoring.com/devices/linux/" tags: [devices, snmp] timestamp: 2026-07-13T00:00:00Z --- # Monitor Linux Servers via SNMP Linux is where SNMP monitoring feels most at home. The daemon is a package install away, the Host Resources MIB exposes CPU, memory, disks, and uptime through standard OIDs, and you never have to log into the box to see how it's doing. SNMP Linux monitoring means one lightweight agent publishes the numbers and any manager on the network reads them — no scraping SSH sessions, no custom exporter to maintain. This guide covers turning the agent on, the exact OIDs worth polling on a Linux server, a working `snmpd.conf`, and why you'll want an independent checker watching from outside the machine. ## SNMP support on Linux servers Every mainstream distribution can run an SNMP agent, and nearly all of them use the same one: Net-SNMP's `snmpd`. It isn't installed by default on a clean server, but it's in every repo — `net-snmp` on RHEL-family systems, `snmpd` on Debian and Ubuntu. Once it's running, that single daemon answers every poll. The version question matters on Linux too. `snmpd` speaks SNMPv1, SNMPv2c, and SNMPv3, so you choose. For read-only polling on a management VLAN you trust, SNMPv2c is the common pick — simple, well supported, low overhead. Its weakness is that the community string crosses the wire in plain text, which is fine on an isolated segment and not fine over the open internet. When polling has to traverse something you don't control, step up to SNMPv3 and get authentication plus encryption from its User-based Security Model. A quick note on what "monitor linux server snmp" actually buys you. The agent is read-only by design when you set it up sensibly, so a compromised community string leaks metrics but can't change anything on the host. That read-only posture is the whole appeal — visibility without a foothold. Enabling it is a matter of a package, a short config file, and a service restart, which the steps below spell out. There's a second reason SNMP fits Linux so well: it barely costs anything. The daemon answers a poll and goes back to sleep — no persistent connection, no heavyweight collector process sitting on the box eating RAM. Compared with logging in over SSH to run `top` or `df` and scraping the text, a poll is structured data you can chart directly, on a cadence you control. That's why SNMP outlives fashion in server monitoring; it's cheap, standard, and it doesn't care which distro or kernel you're on. ![Diagram: an external monitor polling a Linux server's Net-SNMP agent for hrProcessorLoad and hrStorageUsed over UDP 161](https://snmp-monitoring.com/img/devices/linux-snmp-poll.webp) ## What you can monitor on Linux servers Most of what you'll want lives in the Host Resources MIB (RFC 2790), branch `1.3.6.1.2.1.25`. Interface traffic comes from IF-MIB. And Linux also ships a bonus: the Net-SNMP agent publishes UNIX load average through the UCD-SNMP-MIB, a vendor branch that isn't an RFC but is universally present on Linux. | Metric | OID | Object / MIB | |---|---|---| | CPU load (per core) | `1.3.6.1.2.1.25.3.3.1.2` | `hrProcessorLoad`, Host Resources MIB | | Storage description | `1.3.6.1.2.1.25.2.3.1.3` | `hrStorageDescr` | | Storage size | `1.3.6.1.2.1.25.2.3.1.5` | `hrStorageSize` | | Storage used | `1.3.6.1.2.1.25.2.3.1.6` | `hrStorageUsed` | | System uptime | `1.3.6.1.2.1.25.1.1.0` | `hrSystemUptime` | | Logged-in users | `1.3.6.1.2.1.25.1.5.0` | `hrSystemNumUsers` | | Load average (15-min) | `1.3.6.1.4.1.2021.10.1.3` | `laLoad`, UCD-SNMP-MIB (vendor) | | Interface traffic | `1.3.6.1.2.1.2.2.1` | `ifTable`, IF-MIB | The storage table is the one people underuse. It's a single table that covers physical disks, RAM, and swap all at once — walk `hrStorageDescr` to see the labels, then read `hrStorageSize` and `hrStorageUsed` for the same index to get capacity and consumption in allocation units. Multiply by `hrStorageAllocationUnits` (`1.3.6.1.2.1.25.2.3.1.4`) to land in bytes. Here's a subtlety worth internalizing: `hrProcessorLoad` is a per-core busy percentage, whereas `laLoad` is the classic UNIX load average — the length of the run queue. They answer different questions, so don't treat one as a stand-in for the other. `hrSystemUptime` deserves a mention of its own. It's not just trivia — a value that suddenly resets to near zero means the box rebooted, which is often the first hard evidence of a crash you didn't otherwise catch. `hrSystemNumUsers` tells you how many login sessions are active, a rough signal for unexpected SSH activity. And on a busy machine you'll want `snmpbulkwalk` rather than `snmpwalk` for the big tables — it fetches many rows per request instead of one at a time, which keeps polling the interface and storage tables snappy. Our [sensor & OID catalog](/sensors/index.md) breaks each of these readings down with its own page. ## Enabling SNMP — steps On Debian or Ubuntu, standing up read-only SNMPv2c takes about five minutes: 1. **Install the agent:** `sudo apt install snmpd snmp` — the first is the daemon, the second gives you `snmpwalk` and friends for local testing. 2. **Back up the default config:** `sudo cp /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.bak` before you touch anything. 3. **Write a minimal, allowlisted config** (below) that exposes only the OIDs you poll, under a read-only community. 4. **Enable the daemon** in `/etc/default/snmpd` with `SNMPDRUN=yes` (and leave `TRAPDRUN=no` unless you're sending traps). 5. **Restart and check:** `sudo service snmpd restart`, then `service snmpd status` to confirm it came up. 6. **Verify from your manager**, not just locally, so you also prove the firewall lets UDP 161 through. A tight `snmpd.conf` looks like this — read-only, one community, one allowlisted view: ```bash # /etc/snmp/snmpd.conf — v2c read-only, allowlisted OIDs agentAddress udp:161,udp6:[::1]:161 # change 161 to a random port for security # sec.name source community com2sec ReadUser default # group sec.model sec.name group ReadGroup v2c ReadUser # view incl/excl subtree view ReadData included .1.3.6.1.2.1.25.1.1.0 # ...one 'view ... included' line per allowed OID... # group context model level prefix read write notify access ReadGroup "" any noauth exact ReadData none none ``` Then confirm it from the monitoring host: ```bash snmpwalk -v2c -c public 10.0.0.7 1.3.6.1.2.1.25.2.3.1.3 ``` Read the result like a diagnostic: - **Storage labels come back** — the agent, the view, and the firewall are all cooperating. - **Empty response** — the OID probably isn't in your allowlisted view, or the community lacks read rights. - **Timeout** — a firewall in the path, the wrong port, or a mistyped community, not the OID itself. Our [snmpd.conf guide](/setup/snmpd-conf.md) and [OID allowlist guide](/setup/oid-allowlist.md) go deeper on hardening. ## Monitoring it externally Polling `hrProcessorLoad` or `hrStorageUsed` when you feel like it tells you the server's fine right now. It says nothing about the moment it stops being fine. And a monitoring agent that lives on the Linux box has a structural blind spot: when the machine itself falls over — kernel panic, full disk, pulled power — the local tooling dies with it and never sends the alert. An external checker doesn't share that fate. That's the [double durability](/monitoring/double-durability.md) idea: something outside the host keeps polling the same SNMP OIDs on its own schedule, from its own hardware, so a crashed or unreachable server still trips an alarm. SNMP being a pull protocol makes this effortless — the outside watcher asks, and silence is itself the signal. Pair it with your [setup](/setup/index.md) work and you've got both the on-host truth and an independent witness. Monitor snmp linux monitoring from outside your network with [ostr.io Monitoring](https://ostr.io/service/monitoring) — it polls your Linux server's SNMP metrics externally and fires real-time email and SMS alerts the instant a reading spikes or the host goes dark. ![Chart: Linux server disk usage and CPU load over a week with a warning threshold line](https://snmp-monitoring.com/img/devices/linux-storage-cpu-chart.webp) ## FAQ **Which package do I install to monitor a Linux server over SNMP?** Net-SNMP. On Debian and Ubuntu that's `snmpd` for the agent plus `snmp` for the CLI tools; on RHEL-family systems it's the `net-snmp` and `net-snmp-utils` packages. One daemon answers all polls. **How do I read disk usage over SNMP on Linux?** Walk `hrStorageDescr` at `1.3.6.1.2.1.25.2.3.1.3` to find each disk's index, then read `hrStorageSize` (`.5`) and `hrStorageUsed` (`.6`) at that index. The values are in allocation units — multiply by `hrStorageAllocationUnits` (`.4`) to convert to bytes. **Is `hrProcessorLoad` the same as Linux load average?** No. `hrProcessorLoad` (`1.3.6.1.2.1.25.3.3.1.2`) is a per-core busy percentage. Load average is the run-queue length, exposed separately as `laLoad` at `1.3.6.1.4.1.2021.10.1.3` via the UCD-SNMP-MIB. They measure different things. **Should I use SNMPv2c or SNMPv3 on Linux?** SNMPv2c is fine for read-only polling on a trusted management network and is the common default. Use SNMPv3 when polls cross an untrusted network, since it adds authentication and encryption that v2c's clear-text community string can't provide. ## Conclusion SNMP Linux monitoring comes down to one daemon and a handful of standard OIDs: `hrProcessorLoad` for CPU, the `hrStorage` table for disks, RAM, and swap, `hrSystemUptime` for reboots, and IF-MIB for interface traffic. Install Net-SNMP, write a read-only allowlisted `snmpd.conf`, restart, and verify from the manager. Then let something outside the box poll it too — because the server you most need to hear from is the one too broken to speak. Head back to the [devices pillar](/devices/index.md) or [home](/index.md) to monitor the rest of your fleet the same way.