--- type: Topic Hub title: "What Can SNMP Monitor — Sensor & OID Catalog" description: "What can SNMP monitor? CPU, memory, disks, network throughput, processes, uptime and more — a sensor catalog mapping each metric to its exact OID." resource: "https://snmp-monitoring.com/sensors/" tags: [sensors, snmp] timestamp: 2026-07-13T00:00:00Z --- # What Can SNMP Monitor — Sensor & OID Catalog Ask "what can SNMP monitor" and the honest answer is: far more than most people expect, and all of it through one small, boring protocol your servers probably already speak. CPU, memory, swap, disks, network throughput, running processes, uptime, logged-in users — every one of those is just a numbered address away. This page is the map. It's the sensor and OID catalog that routes you to each metric, shows the exact object identifier behind it, and tells you which of them an external checker like ostr.io pulls out of the box. Think of it as the index; the individual pages hold the detail. ## Overview SNMP works because every measurable thing on a device lives at an OID — an object identifier, a dotted-number path into a giant tree defined by MIB files. An agent on the host publishes those values; a manager polls them. That's the whole dance. What makes SNMP so useful for infrastructure monitoring is that the important server metrics sit in a handful of well-known, standardized MIBs, so the same OID means the same thing on almost any Linux box, switch, or appliance. This catalog groups the common sensors, names each OID, and links out to a dedicated page for every metric where you'll find query commands, thresholds, and the gotchas. Below, the master table is the centerpiece — an SNMP OID catalog you can scan in one pass. Whether you're building an SNMP sensors list for a new fleet or just chasing one value, start here. A quick word on the pieces before the table. A MIB is a document — a schema — that names objects and pins them to OIDs. The device doesn't ship the MIB; it ships the *values*, and you use the MIB locally to translate a raw number like `1.3.6.1.2.1.25.1.1.0` into a readable name like `hrSystemUptime`. That's why two people can poll the same server and one sees friendly names while the other sees bare digits — they just have different MIBs installed. The numbers are identical either way, which is exactly why this catalog lists the numeric OIDs: they're the part that never changes. ## The reference table Here's the core of the SNMP OID catalog — the metrics people actually poll, the exact OID for each, the MIB and standard it belongs to, and whether ostr.io's external monitoring collects it as part of its default health check. Every OID below is real and traceable to its RFC or vendor MIB; none are invented. | Sensor / metric | OID | MIB / standard | ostr.io collects? | |---|---|---|---| | Host uptime | `1.3.6.1.2.1.25.1.1.0` | Host Resources MIB (RFC 2790) | Yes | | Logged-in users / SSH logins | `1.3.6.1.2.1.25.1.5.0` | Host Resources MIB (RFC 2790) | Yes | | Running processes (status) | `1.3.6.1.2.1.25.4.2.1.7` | Host Resources MIB (RFC 2790) | Yes | | System load average | `1.3.6.1.4.1.2021.10.1.3` | UCD-SNMP-MIB (vendor, enterprise 2021) | Yes | | CPU utilization (per core) | `1.3.6.1.2.1.25.3.3.1.2` | Host Resources MIB (RFC 2790) | Yes | | Storage names (disk/RAM/swap) | `1.3.6.1.2.1.25.2.3.1.3` | Host Resources MIB (RFC 2790) | Yes | | Storage capacity | `1.3.6.1.2.1.25.2.3.1.5` | Host Resources MIB (RFC 2790) | Yes | | Storage used | `1.3.6.1.2.1.25.2.3.1.6` | Host Resources MIB (RFC 2790) | Yes | | Network interface counters (64-bit) | `1.3.6.1.2.1.31.1.1.1` | IF-MIB (RFC 2863) | Yes | | Network interface table (32-bit) | `1.3.6.1.2.1.2.2.1` | IF-MIB (RFC 2863) | Yes | | Environmental sensors (temp, fan, voltage) | `1.3.6.1.2.1.99.1.1.1.4` | Entity Sensor MIB (RFC 3433) / vendor | Vendor-specific | A few things to read out of that grid. Notice how tightly the server metrics cluster under `1.3.6.1.2.1.25` — that's the Host Resources MIB, and it's the workhorse for host-level monitoring. Storage is especially neat: one table, `hrStorage`, exposes physical RAM, swap, and every mounted filesystem as rows, so RAM and swap are literally storage entries rather than special cases. Load average is the odd one out — it lives under `1.3.6.1.4.1.2021`, the Net-SNMP vendor branch, not a standards-track RFC. And the network side lives in the IF-MIB, where 64-bit counters (`ifXTable`) matter on any interface fast enough to wrap the old 32-bit ones. Each row is a link into the site. Server resources break down into [CPU utilization](/sensors/server-resources/cpu-utilization.md), [RAM / memory](/sensors/server-resources/ram-memory.md), [swap](/sensors/server-resources/swap.md), [system load](/sensors/server-resources/system-load.md), [uptime & reboot detection](/sensors/server-resources/uptime-reboot.md), and [running processes](/sensors/server-resources/processes.md). Storage gets its own pages for [disk space usage](/sensors/storage/disk-space-usage.md), [storage capacity](/sensors/storage/storage-capacity.md), [storage inventory & names](/sensors/storage/storage-inventory-names.md), and [HDD / SSD](/sensors/storage/hdd-ssd.md). The full machine-readable master list lives at [the complete SNMP OID catalog](/sensors/all.md). ![Diagram of the SNMP OID tree branching into Host Resources MIB, IF-MIB and UCD-SNMP-MIB sensor groups](https://snmp-monitoring.com/img/sensors/snmp-oid-catalog-tree.webp) ## How to read and use it Working out what SNMP can monitor on a specific device follows the same rhythm every time. 1. **Pick the metric** you care about and grab its OID from the table above. If it's under `1.3.6.1.2.1`, it's standards-track and portable; under `1.3.6.1.4.1`, it's vendor-private. 2. **Confirm the agent publishes it.** A value only exists if the SNMP daemon exposes it. Walk the subtree; an empty result usually means the OID isn't in the agent's view. 3. **Query it** with a Net-SNMP client — `snmpwalk` for a whole table, `snmpget` for a single leaf. Every sensor page shows the exact command and sample output. 4. **Allowlist only what you need** in [snmpd.conf](/setup/snmpd-conf.md) and lock it down with an [OID allowlist](/setup/oid-allowlist.md), so you expose the reading without opening the whole tree. 5. **Set a threshold and poll on a schedule**, ideally from a machine that isn't the one being watched. That last point is the one that separates a dashboard from real protection, and it's why the external angle runs through every page here. Two practical notes save a lot of head-scratching. First, tables versus scalars: an OID ending in `.0` is a single scalar value (uptime, process count), while most others are table columns that return one row per CPU, disk, or interface — you walk those, you don't just get them. Second, version choice: SNMPv2c is fine for read-only polling on a trusted network and is what most of these examples use, but reach for SNMPv3 when you need authentication and encryption on the wire. The OIDs are identical across versions; only the transport security changes. ## Custom & advanced sensors The table covers the metrics almost everyone wants, but SNMP reaches much further once you leave the standard host MIBs behind. This is where the SNMP sensors list stops being universal and starts being device-specific: - **Environmental readings** — temperature, fan speed, voltage, humidity — typically come through the Entity Sensor MIB (RFC 3433) at `entPhySensorValue`, or through a vendor's own MIB. Exact OIDs vary by hardware; consult the device MIB rather than guessing. - **Hardware health** — RAID array state, power supply status, UPS battery charge, PDU outlets — almost always lives in vendor-private branches under `1.3.6.1.4.1.`. - **Application and custom metrics** — queue depth, cache hit rate, a business counter — can be exposed through Net-SNMP's `extend`/`pass` mechanism and read like any other OID. The [custom OID monitoring](/sensors/custom-oid.md) page covers that pattern. The rule of thumb: if a value isn't in a standard MIB, treat its OID as unknown until you've confirmed it in the vendor's documentation. Never fabricate one. ![Reference table of common SNMP sensors mapped to their OIDs and MIBs in the SNMP OID catalog](https://snmp-monitoring.com/img/sensors/snmp-sensors-list-table.webp) ## FAQ **What can SNMP monitor on a standard Linux server?** Out of the box, with the Host Resources MIB and UCD-SNMP-MIB: CPU load per core, memory and swap usage, disk space, running-process status and count, uptime, logged-in users, and per-interface network throughput. Everything in the master table above is available on a typical Net-SNMP install. **Where do I find the OID for a metric that isn't listed?** Use `snmptranslate` to map names to numbers, browse the device's MIB files, or check the vendor's documentation for enterprise OIDs under `1.3.6.1.4.1`. Don't invent an OID — if the agent doesn't publish it, no number will conjure it. **Are these OIDs the same on every device?** The standards-track ones (Host Resources MIB, IF-MIB) are consistent across compliant agents. Vendor-private OIDs under enterprise branches are specific to the manufacturer and model. **Does external monitoring cover this whole catalog?** ostr.io collects the core set marked "Yes" above — uptime, users, processes, load, CPU, storage, and network interfaces — polling them from outside your network. ## Conclusion So, what can SNMP monitor? The short version: nearly every vital sign a server or network device produces, each addressable by a real, standardized OID — and this catalog is your route to all of them. The Host Resources MIB carries CPU, memory, storage, processes, and uptime; the IF-MIB carries the network; the Net-SNMP branch fills the gaps. Pick your metric, grab its OID, publish it safely, and poll it. Then poll it from somewhere independent — [ostr.io Monitoring](https://ostr.io/service/monitoring) reads this exact set from outside your network and alerts by email and SMS, which is the whole point of [double durability](/monitoring/double-durability.md): the reading still reaches you when the server itself can't send it.