Monitor Any Custom OID
If a value lives somewhere in a device's MIB tree, you can watch it — that's the whole promise of the SNMP custom OID. The named sensors in the catalog cover CPU, memory, disk, interfaces, and the usual suspects, but SNMP was never limited to a fixed menu. Every object has an OID, and once you know the OID you can poll it. This page is the how-to: how to discover any OID, how to allow it through the agent with a single view line, how to poll it, and how to keep watching it from outside your network so the reading survives the very failure it's meant to catch.
Overview
SNMP is a tree. Every measurable thing — a temperature probe, a queue depth, a per-outlet amp draw, a battery's runtime — sits at a numeric address like 1.3.6.1.2.1.25.1.1.0, and the protocol's job is to hand you the value at that address on request. Nothing about it restricts you to popular metrics. If your hardware or software exposes a number through an SNMP agent, that number has an OID, and any OID is pollable.
That's what makes a custom SNMP sensor so powerful. Whether it's a standard object from the Host Resources MIB or a deep branch of a vendor's proprietary tree, the mechanics are identical: find the OID, make sure the agent is allowed to serve it, and read it on a schedule. This page walks through exactly that, so you can monitor any OID — including the advanced environmental sensors that don't ship as named catalog entries — with confidence and without guessing.
One idea underpins everything below, and it's worth stating plainly. The named sensors are just OIDs that happen to be common enough to earn their own page. There's nothing special about them at the protocol level. A custom OID follows the identical path — the only difference is that you're the one who located it and decided it was worth watching. Learn the loop once and the entire MIB tree opens up to you.
The reference table
The heart of custom-OID monitoring is the agent's view — the allowlist that decides which OIDs the daemon will actually hand out. On a hardened snmpd.conf you don't expose the whole tree; you name each OID you want readable. Adding a new metric means adding one line. This is the allow/deny mechanism, and it's worth understanding field by field.
Here's the anatomy of the two directives that matter, using the reference snmpd.conf layout:
| Directive | Example | What each field does |
|---|---|---|
view (allow) | view ReadData included .1.3.6.1.2.1.25.1.1.0 | view = keyword · ReadData = view name · included = allow this subtree · the OID = what to expose |
view (deny) | view ReadData excluded .1.3.6.1.2.1.25.1.5.0 | Same fields, but excluded blocks that subtree even if a parent is included |
access (bind) | access ReadGroup "" any noauth exact ReadData none none | Ties the group to the ReadData view for read access — write and notify stay none |
The rule is simple: included opens an OID (or a whole subtree, if you name a parent), excluded closes one back off. To add a brand-new custom OID, you append one more view ReadData included <your.oid> line and restart the daemon. To keep something private, excluded wins over a broader included. The full walkthrough of this file lives in the snmpd.conf reference, and the dedicated OID allowlist guide drills into the view line specifically.
A quick discovery cheat sheet for finding the OID you want to add:
| Task | Command |
|---|---|
| Walk a subtree to see what's there | snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.25 |
| Force raw numeric OIDs (no MIB names) | snmpwalk -v2c -c public -On 10.0.0.5 1.3.6.1.2.1.25 |
| Resolve a name to its numeric OID | snmptranslate -On HOST-RESOURCES-MIB::hrSystemUptime.0 |
| Resolve a numeric OID back to a name | snmptranslate 1.3.6.1.2.1.25.1.1.0 |
How to read / use it
Putting a new custom OID under watch is a short, repeatable loop. Follow it for any metric on any device:
- Discover the OID. Walk the relevant subtree with
snmpwalk, or if you already have a MIB, resolve the object name to its number withsnmptranslate. Confirm the value is the one you actually want by checking it changes as expected. - Note the exact address. Use the fully numeric OID (the
-Onflag prints it) so the agent and your poller agree without relying on MIB files being installed everywhere. - Allow it in the view. Add a
view ReadData included <your.oid>line tosnmpd.conf, keeping the daemon read-only and allowlisted rather than wide open. - Restart and verify. Run
service snmpd restart, thensnmpgetthe new OID from a client to confirm the agent now serves it. An empty or "no such object" reply means it's still outside the view. - Poll on a cadence. Read the OID on whatever interval fits the metric — frequently for volatile values, sparingly for slow ones — and store the history so you can chart trends and set thresholds.
That's the entire lifecycle. Discover, allow, verify, poll. The only part that changes between a CPU reading and an obscure vendor counter is the OID itself.
A couple of habits save real time here. Always keep the numeric OID alongside the human-readable name in your notes, because the pretty name only resolves when the matching MIB file is installed, and it usually isn't on the machine doing the polling. And when a walk returns a table rather than a single scalar — many custom metrics are indexed, one row per outlet, port, or disk — pin down which index maps to the thing you care about before you set a threshold, since indices can shift when hardware is added or a device reboots. Getting that mapping right once is the difference between an alert that means something and one that quietly watches the wrong row.
Custom & advanced sensors
This method is exactly how the advanced environmental sensors get monitored — the ones that aren't in the standard host-resources tree and need a vendor or entity OID. Each has its own page with the discovery specifics, but they all come home to the workflow above:
- PDU power — per-outlet current and load in amps, read from a managed PDU's vendor MIB.
- UPS battery — battery status and runtime from the UPS-MIB (RFC 1628) and vendor extensions.
- Optical dBm — transceiver Tx/Rx power via the ENTITY-SENSOR-MIB
entPhySensorValue(1.3.6.1.2.1.99.1.1.1.4, RFC 3433). - RAID health — controller and disk status from a vendor RAID MIB or a script-backed custom OID.
- Anything else — application counters, queue depths, sensor probes; if it has an OID, this page's loop applies.
For the complete inventory of named metrics and whether they're collected out of the box, see the full sensor list. When something isn't there, you're not stuck — you're back here, adding it as a custom OID.
The last piece is where you poll from. Reading a custom OID from a box on the same network tells you the value right now, but it shares that box's fate: if the site or the server goes down, so does the monitor. Polling from outside removes that dependency — the double durability principle, where an independent external checker keeps reading your OIDs even when your infrastructure is in trouble. It's better to get an alert from two places than from none.
