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.

The reference table

Below is the master SNMP OID reference. The final column marks the nine standard metric groups that ostr.io 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.

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:

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 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 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.<vendor>). 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 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 <host> .1.3.6.1 and read what comes back. The agent can only report what it's been built and configured to expose.