SNMP Sensors & OID Catalog: Every Metric You Can Monitor

By the SNMP Monitoring team · Reviewed July 2026

This is the reference wing of the site. If the /monitoring/ pages answer "how do I watch X," these pages answer the narrower, more urgent question you actually type at 2 a.m.: "what's the OID for X?" No workflow, no alerting philosophy — just the object, the MIB it lives in, the type it returns, and a walk you can paste. Every sensor page here has a how-to twin over in monitoring, and links straight to it, so you can grab the OID and then go read how to alert on it sanely.

Parent: home. The one page most people bookmark is the master list: all SNMP OIDs.

How SNMP sensors are organised

SNMP doesn't have "sensors" as a first-class concept — it has objects, grouped into MIBs. A sensor page here is really a curated slice of one or more MIBs. The organising rule is simple:

• Standard MIBs cover the portable stuff — CPU, memory, disk, interfaces, generic physical sensors. Same OIDs across vendors.
• Enterprise MIBs (under 1.3.6.1.4.1) cover the vendor-specific stuff — a Cisco CPU object, an APC probe, a MegaRAID array state.

So finding a sensor is a two-step habit: reach for the standard MIB first, and only drop into a vendor's enterprise tree when the standard one doesn't carry what you need. The pages below are grouped that way.

Sensor categories

The catalog splits into four families. Each links to its detail page (OIDs + walk) and, from there, its how-to twin:

• System — CPU, memory & swap, disk, uptime, processes, SSH sessions, system load. Mostly HOST-RESOURCES and UCD.
• Network — interfaces (traffic, errors, status, speed) and TCP/UDP/IP. The IF-MIB and the protocol MIBs.
• Physical / hardware — temperature, fan speed, power (voltage/current/watts), humidity & airflow, optical dBm. Mostly ENTITY-SENSOR plus vendor trees.
• Device — UPS, PDU, printer, RAID, and the escape hatch, custom OID. Dedicated device MIBs.

If you're not sure which page you want, start at the master table and filter from there.

The full OID catalog

The single biggest page in this cluster is the consolidated table — every sensor, its MIB, its base OID, its unit, and a link to the detail page — at the complete SNMP OID catalog. That's the copy-paste hub: find your metric, grab the OID, test it, move on. Bookmark it; it's the one page here you'll open again and again.

Reading any OID

Every page here shows the specific walk, but the pattern is always the same two tools:

snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.1.3.0
snmpwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.25.2.3.1

snmpget fetches one scalar object (note the trailing .0); snmpwalk traverses a whole table or subtree. The habit that finds any object:

1. Identify the family and its base MIB from the table below.
2. snmpwalk the base OID to see what the device actually exposes.
3. Resolve the numeric OIDs to names with a MIB browser.
4. snmpget the exact instance once you know its index.

Use get when you know the instance, walk when you're discovering. See snmpwalk and MIB browser. <RO_string> is a placeholder; never paste a live community into notes or scripts.

Standard vs enterprise OIDs

The split above is the single most useful thing to internalise. Everything under 1.3.6.1.2.1 (the mib-2 arc) is standardised — an interface counter is the same object on a Cisco switch, a Linux server and a MikroTik router. Everything under 1.3.6.1.4.1 (the enterprises arc) is a vendor's private space, where they publish whatever the standard MIBs don't cover. When a metric isn't in a standard MIB — RAID health, a labelled CPU-temperature sensor, a specific PDU outlet — it's almost certainly in an enterprise MIB. More on that boundary: enterprise OIDs.

From OID to monitoring

A reference page gives you the object; it doesn't tell you how to alert on it without paging yourself into the ground. That's what the how-to twins are for. Grab hrProcessorLoad here, then read monitor CPU via SNMP for averaging and thresholds. Grab the interface counters, then read network monitoring for the rate math. Reference and how-to are deliberately two pages so each does one job well — see the whole monitoring hub for the procedural side.

Why keep them separate at all? Because the two answer different searches and serve different moments. When you're building a template or filling an allowlist, you want the bare object — OID, type, index — and nothing between you and the copy button. When you're designing an alert that won't wake the team over a backup-window spike, you want judgement: what threshold, over how many samples, paired with which other signal. Cramming both into one page makes each worse — the reference gets buried under prose, and the how-to gets interrupted by OID tables. So a sensor page here stays terse and factual, and its twin over in monitoring carries the opinions. Follow the link in whichever direction your task needs; every page points to its counterpart.

Frequently asked questions

What can SNMP monitor?

Almost any numeric or state value a device exposes: CPU, memory, disk, network interfaces, temperature, fans, voltage, power, UPS battery, printer toner, RAID health, and more. Standard metrics live in standard MIBs under 1.3.6.1.2.1; vendor-specific ones live in enterprise MIBs under 1.3.6.1.4.1. If a device publishes it as an object, you can poll it.

Where do I find an SNMP OID?

Start with the complete OID catalog here, which maps common metrics to their OIDs. For anything not listed, walk the relevant MIB on the device with snmpwalk and resolve names with a MIB browser, or consult the vendor's MIB file for enterprise objects.

What MIB has which sensor?

System metrics are in HOST-RESOURCES-MIB (1.3.6.1.2.1.25); interfaces in the IF-MIB (1.3.6.1.2.1.2 and .31); generic physical sensors in ENTITY-SENSOR-MIB (1.3.6.1.2.1.99); UPS in UPS-MIB (1.3.6.1.2.1.33); printers in Printer-MIB (1.3.6.1.2.1.43). Vendor extras sit under 1.3.6.1.4.1.

What's the difference between standard and vendor OIDs?

Standard OIDs under 1.3.6.1.2.1 are defined by public MIBs and behave the same across vendors. Vendor (enterprise) OIDs under 1.3.6.1.4.1 are a manufacturer's private space for objects the standards don't cover — you need that vendor's MIB to interpret them.

Key takeaways

• This is the reference cluster — "what's the OID," not "how do I alert" (that's monitoring).
• SNMP exposes objects in MIBs; standard metrics under 1.3.6.1.2.1, vendor ones under 1.3.6.1.4.1.
• Four families: system, network, physical, device — each page has OIDs, a walk, and a how-to twin.
• The bookmark page is the complete OID catalog.
• Read with snmpget (one object) and snmpwalk (a subtree); resolve names via a MIB browser.