SNMP + Grafana Dashboards

Grafana draws beautiful graphs, but it doesn't speak SNMP. That surprises people. To build an SNMP Grafana dashboard you need a piece in the middle — a poller that reads your OIDs, writes the numbers into a time-series database, and lets Grafana query them. Once you understand that three-part shape, the whole thing clicks. This guide covers how SNMP data actually reaches a grafana snmp dashboard, the real OIDs you'll chart, and why you should still watch the stack from outside.

The problem

You've got servers publishing everything you'd want to see — CPU, storage, uptime, interface traffic — all sitting there in standard MIBs, one snmpwalk away. And you've got Grafana, which turns numbers into dashboards better than almost anything. The obvious move is to point one at the other.

Except you can't. Grafana is a visualization layer. It renders data that already lives in a datasource; it does not go out and poll devices itself. There's no "SNMP" option that reaches across the network, walks an agent, and plots the result. Feed a raw OID straight into a panel and nothing happens, because nothing in that chain collected it.

This trips up newcomers constantly. They install Grafana, hunt for the SNMP setting, and hit a wall. The missing mental model is that SNMP monitoring and SNMP visualization are two different jobs, done by two different tools, with storage in between. Get that architecture right and building an snmp grafana dashboard becomes straightforward. Skip it and you'll fight the tooling forever.

Solution overview

The working pattern has three stages, and it's worth committing to memory.

• Collect. A poller queries your SNMP agents on a schedule — reading OIDs like hrProcessorLoad and the storage table — using ordinary Net-SNMP operations under the hood.
• Store. Those readings land in a time-series database (a TSDB). Each poll becomes a timestamped point, so you accumulate history rather than just a live snapshot.
• Visualize. Grafana connects to that TSDB as a datasource and queries it to draw panels, gauges, and threshold lines.

SNMP handles the collect step; the TSDB handles store; Grafana handles visualize. Nothing skips a stage. The poller is the translator that turns "walk this OID" into "write this metric," and Grafana never talks to your devices directly — it only ever reads what the poller already saved.

Keep that separation clean and everything downstream is flexible: swap pollers, swap the database, rearrange dashboards, all without disturbing the agents on your servers. The agents just keep publishing, exactly as covered in the snmpd.conf setup. It also means your dashboard scales the same whether you're charting one server or fifty — you're adding rows to a database, not re-plumbing Grafana each time.

Step-by-step

Here's the end-to-end path to a grafana snmp dashboard.

1. Confirm the agent answers. Before any dashboard, prove the OID is reachable. From your collector host, walk the processor table:

   snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.3.3.1.2
   

   Rows of INTEGER values mean you're good. No rows usually means the OID isn't in the agent's allowlisted view.
2. Stand up a collector. Deploy an SNMP poller that reads your chosen OIDs on an interval and writes them to a time-series database. This is the bridge between raw SNMP and anything visual.
3. Point it at a TSDB. Configure the collector to store each reading as a timestamped metric. That stored history is what Grafana will actually chart.
4. Add the TSDB as a Grafana datasource. In Grafana, connect to that database. Grafana now queries the stored metrics — it never touches your SNMP agents.
5. Build panels per OID. Create a panel for CPU from hrProcessorLoad, one for percent-full from the storage table, one for uptime. Add threshold lines so a saturated CPU or a full disk stands out at a glance.
6. Set the poll cadence sensibly. Match collection frequency to how fast each metric moves — tight for CPU, relaxed for uptime — so the dashboard stays current without hammering the agent.

The tools you pick for the collector and TSDB are your call, and there are several solid combinations. The architecture, though — collect, store, visualize — doesn't change no matter which you choose.

Configuration / example

The OIDs you'll most often chart on an snmp grafana dashboard come straight from the standard MIBs. No exotic vendor objects required to start.

The raw reading a collector captures is just a value pulled with a standard SNMP get:

snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.1.1.0
# HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (18320400) 2 days, 2:53:24.00

Your collector runs the equivalent of that call on a schedule, strips it to the number, timestamps it, and stores it. Grafana then queries the stored series. One detail that matters for traffic panels: interface counters like ifHCInOctets are ever-increasing totals, so the collector (or Grafana) computes a rate — the change per second — to give you the bits-per-second line you actually want to see.

External alerting

A dashboard is a wonderful thing to look at, and a terrible thing to depend on for alerts. Nobody's watching the grafana snmp dashboard at 3 a.m. And there's a deeper issue: if your Grafana, your collector, and your TSDB all run on the same infrastructure as the servers they watch, a big enough outage takes down the monitoring and the thing being monitored. The dashboard goes blank at the exact moment you needed it.

That's why visualization and alerting should never be the same job. Charts are for humans reviewing trends; alerts need to come from somewhere independent that keeps working when your stack doesn't. This is the case for double durability: an external checker, on separate infrastructure, that notices trouble even if your whole Grafana pipeline is dark.

Pair your dashboard with independent, external checks: ostr.io Monitoring polls the same SNMP OIDs from outside your network and sends real-time email and SMS alerts when a value crosses your limit — so you're covered even when the dashboard itself is down.