--- type: Article title: "Complete SNMP Sensor & OID Reference Table" description: "A working SNMP OID reference: each server metric paired with the exact object identifier, the MIB that defines it, and whether an external check pulls it." resource: "https://snmp-monitoring.com/sensors/all/" tags: [sensors, snmp] timestamp: 2026-07-13T00:00:00Z --- # Complete SNMP Sensor & OID Reference Table If you have ever stared at a wall of dotted numbers wondering which one actually returns CPU load, this page is for you. It is a working SNMP OID list — a single reference that pairs each server metric with the exact object identifier that reports it, the MIB that defines it, and whether an external checker like ostr.io pulls it by default. No fluff, no invented numbers. Everything below is drawn from published standards, and every OID resolves to a real object you can query today with a stock Net-SNMP client. ## Overview A monitoring system is only as good as the addresses it reads from. In SNMP, those addresses are object identifiers, and a complete SNMP sensor list is really just a curated map of which OID answers which question. This catalog is that map. Think of it as the index at the front of a reference manual: the individual sensor pages go deep on one metric each, while this page shows you the whole terrain at a glance so you can decide what's worth polling before you touch a config file. The scope here is deliberately narrow and honest. We cover the standard, cross-vendor OIDs that any Linux or Unix server exposes through its SNMP daemon — processor load, memory, storage, uptime, sessions, processes, and network interfaces — plus a note on where vendor and environmental sensors live. What you won't find is a guessed OID. When a value depends on a specific device's MIB, this catalog says so rather than fabricating a number that would send you chasing ghosts. ![Diagram of the SNMP OID tree branching from 1.3.6.1 into the Host Resources MIB, IF-MIB and vendor enterprise arcs with example sensor OIDs](https://snmp-monitoring.com/img/sensors/oid-tree-map.webp) ## The reference table Below is the master SNMP OID reference. The final column marks the nine standard metric groups that [ostr.io Monitoring](https://ostr.io/service/monitoring) collects out of the box via SNMPv2c — the vitals that matter for keeping a server healthy. A dash means the metric is real and useful, but it lives in a vendor or environmental MIB that varies by hardware, so it isn't part of the default health poll. | Metric | OID | MIB / Standard | ostr.io collects | |---|---|---|---| | Host uptime | `1.3.6.1.2.1.25.1.1.0` | Host Resources MIB (RFC 2790) | ✓ | | SSH logins (system users) | `1.3.6.1.2.1.25.1.5.0` | Host Resources MIB (RFC 2790) | ✓ | | Running processes (status) | `1.3.6.1.2.1.25.4.2.1.7` | Host Resources MIB (RFC 2790) | ✓ | | System load average | `1.3.6.1.4.1.2021.10.1.3` | UCD-SNMP-MIB (Net-SNMP, enterprise 2021) | ✓ | | CPU utilization (per core) | `1.3.6.1.2.1.25.3.3.1.2` | Host Resources MIB (RFC 2790) | ✓ | | HDD/SSD/RAM/Swap names | `1.3.6.1.2.1.25.2.3.1.3` | Host Resources MIB (RFC 2790) | ✓ | | HDD/SSD/RAM/Swap capacity | `1.3.6.1.2.1.25.2.3.1.5` | Host Resources MIB (RFC 2790) | ✓ | | HDD/SSD/RAM/Swap usage | `1.3.6.1.2.1.25.2.3.1.6` | Host Resources MIB (RFC 2790) | ✓ | | Network interfaces (32-bit) | `1.3.6.1.2.1.2.2.1` | IF-MIB `ifTable` (RFC 2863) | ✓ | | Network interfaces (64-bit) | `1.3.6.1.2.1.31.1.1.1` | IF-MIB `ifXTable` (RFC 2863) | ✓ | | Temperature / fan / voltage | `1.3.6.1.2.1.99.1.1.1.4` (`entPhySensorValue`) | Entity Sensor MIB (RFC 3433) | — | | UPS / PDU / RAID / optical | vendor-specific — consult the device MIB | Vendor enterprise MIB | — | A few of these deserve a second look. The `1.3.6.1.2.1.25.*` block is the Host Resources MIB, and it does the heavy lifting: uptime, CPU, storage, and process data all branch off it. Notice that storage isn't split into disk versus RAM — the `hrStorage` table treats physical disks, RAM, and swap as rows in one table, distinguished by their `hrStorageDescr` name at `.3`. Multiply `hrStorageUsed` by the allocation-unit size (`1.3.6.1.2.1.25.2.3.1.4`) to get real bytes. System load is the odd one out: it comes from the UCD-SNMP-MIB under enterprise arc 2021, which is a Net-SNMP vendor extension, not an IETF RFC. And network throughput has two homes — the classic 32-bit `ifTable` and the 64-bit `ifXTable` that keeps high-speed links from wrapping their counters. ## How to read and use it An OID is a hierarchy read left to right, each dot a step deeper down the tree. Here's how to go from a row in that table to a value on your screen. 1. **Decode the prefix.** `1.3.6.1.2.1` is the standard `mib-2` branch; `1.3.6.1.4.1` is the enterprise branch where vendors register their own arcs (2021 is Net-SNMP's). If an OID starts with `.4.1`, expect it to be vendor-defined. 2. **Spot scalar vs. table.** An OID ending in `.0`, like uptime's `1.3.6.1.2.1.25.1.1.0`, is a single scalar value. One without a trailing `.0`, like the CPU column, is a *table* — the agent returns one indexed row per CPU, disk, or interface. 3. **Walk a table, get a scalar.** Use `snmpwalk` to enumerate every row of a table and `snmpget` for a known scalar or a specific row you can already address. 4. **Resolve names when you can.** With the MIB files installed, `snmptranslate` turns `1.3.6.1.2.1.25.3.3.1.2` into `hrProcessorLoad` and back. Add `-On` to force numeric output when the MIB isn't present. A quick, real example against an agent at `10.0.0.5` with a read-only community: ```bash snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.3.3.1.2 # per-core CPU load snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.1.1.0 # host uptime ``` Start narrow. Pick the three or four metrics that actually predict trouble on your box — usually CPU, memory, disk, and uptime — publish just those in your agent's view, and expand later. A tight [OID allowlist](/setup/oid-allowlist.md) is easier to reason about and smaller to attack. ## Custom & advanced sensors The table's standard rows cover the software side of a server well. Hardware and environmental telemetry is where things fragment. Temperature probes, fan tachometers, PSU voltage, UPS battery state, PDU outlet draw, RAID controller health, and optical transceiver levels are all real, monitorable signals — but the industry never fully standardized where they live, so the exact OID depends on your hardware. - **Environmental sensors** — Many enterprise devices expose these through the Entity Sensor MIB (RFC 3433), where `entPhySensorValue` at `1.3.6.1.2.1.99.1.1.1.4` returns a reading whose type and scale are described by sibling objects. See [environmental sensors](/sensors/index.md) for the details. - **Vendor extensions** — Storage arrays, switches, and UPS units usually publish the richest data under their own enterprise arc (`1.3.6.1.4.1.`). Load the vendor's MIB file, then browse it; don't guess the numbers. - **Application metrics** — Anything SNMP doesn't model natively — queue depth, cache hit ratio, a business counter — can be surfaced through a custom OID you define yourself. The [custom OID guide](/sensors/custom-oid.md) shows how to wire one up with a Net-SNMP `extend` or `pass` directive. When you're unsure whether a value even exists on your device, walk the whole tree once with `snmpwalk -v2c -c public .1.3.6.1` and read what comes back. The agent can only report what it's been built and configured to expose. ![Complete SNMP sensor list table showing metric, OID, MIB and whether external monitoring collects each value](https://snmp-monitoring.com/img/sensors/snmp-oid-reference-table.webp) ## FAQ **What is an SNMP OID, exactly?** An OID (object identifier) is a globally unique, dotted-number address for one manageable piece of data — like `1.3.6.1.2.1.25.1.1.0` for host uptime. Each number is a node in a tree standardized by IETF and vendor registrations, so the same OID means the same thing on every conformant agent. **Are these OIDs the same on every server?** The standard ones are. Anything under `1.3.6.1.2.1` (Host Resources, IF-MIB) behaves identically across conformant Linux, BSD, and Unix agents. The UCD-SNMP load OID assumes Net-SNMP. Vendor OIDs under `1.3.6.1.4.1` differ by device, which is exactly why this catalog flags them rather than pinning a number. **Why does ostr.io collect only some of these?** The nine marked rows are the cross-vendor health vitals — CPU, memory, storage, load, uptime, sessions, processes, and network — that apply to essentially any server. Environmental and vendor OIDs are hardware-specific, so they're left to per-device configuration instead of a default poll. **How do I find an OID that isn't listed here?** Walk the device with `snmpwalk`, or load and browse its MIB with `snmptranslate`. If the value is application-specific, define your own via the [custom OID](/sensors/custom-oid.md) page. ## Conclusion A good SNMP OID reference saves you from the two classic traps: polling numbers that don't mean what you think, and inventing ones that don't exist. This catalog keeps you honest on both counts — standard OIDs mapped to their MIBs, vendor territory clearly marked, and the nine health vitals that a default poll should cover. Use it as your jumping-off point, drill into the individual [sensor pages](/sensors/index.md) for depth, and remember that reading these values from *outside* the box — the [double durability](/monitoring/double-durability.md) idea — is what turns a table of numbers into an early-warning system. Back to the [SNMP Monitoring home](/index.md) when you need the bigger picture.