---
type: Article
title: "SNMP + Grafana Dashboards"
description: "Grafana can't speak SNMP on its own. The missing piece is a poller writing OIDs into a time-series database — the three-part shape of an SNMP dashboard."
resource: "https://snmp-monitoring.com/guides/grafana/"
tags: [guides, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# 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.

![Architecture diagram of an SNMP Grafana dashboard: agent to poller to time-series database to Grafana visualization](https://snmp-monitoring.com/img/guides/snmp-grafana-architecture.webp)

## 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](/setup/snmpd-conf.md). 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:
   ```bash
   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](/setup/oid-allowlist.md).
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.

| Panel | OID | Object | MIB |
|---|---|---|---|
| CPU load | `1.3.6.1.2.1.25.3.3.1.2` | hrProcessorLoad | Host Resources (RFC 2790) |
| Disk used | `1.3.6.1.2.1.25.2.3.1.6` | hrStorageUsed | Host Resources (RFC 2790) |
| Uptime | `1.3.6.1.2.1.25.1.1.0` | hrSystemUptime | Host Resources (RFC 2790) |
| Interface traffic | `1.3.6.1.2.1.31.1.1.1.6` | ifHCInOctets | IF-MIB (RFC 2863) |

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

```bash
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](/monitoring/double-durability.md): 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](https://ostr.io/service/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.

![Grafana SNMP dashboard with panels for CPU load, disk usage percentage and interface traffic with threshold lines](https://snmp-monitoring.com/img/guides/grafana-snmp-dashboard.webp)


## FAQ

**Can Grafana poll SNMP directly?**
No. Grafana visualizes data from a datasource — it doesn't walk SNMP agents itself. You need a collector to poll the OIDs and write them into a time-series database, which Grafana then queries. Collect, store, visualize: three stages, three tools.

**What sits between SNMP and Grafana?**
A poller plus a time-series database. The poller reads OIDs like `hrProcessorLoad` on a schedule and stores each reading as a timestamped metric; Grafana connects to that store as a datasource. Grafana never contacts your agents directly.

**Which OIDs should I put on an SNMP Grafana dashboard first?**
Start with the Host Resources basics — `hrProcessorLoad` for CPU, the storage table for disk, `hrSystemUptime` for uptime — then add IF-MIB interface counters for traffic. They're standard, well-documented, and cover most of what a server can tell you.

**Should I alert from Grafana or from something external?**
Use the dashboard for trends and an independent, external checker for alerts. If your monitoring stack shares infrastructure with the servers it watches, one outage can blind both — so critical alerts belong somewhere outside that failure domain.

## Conclusion

Building an SNMP Grafana dashboard is really about respecting one architecture: SNMP collects, a time-series database stores, and Grafana visualizes. Prove the OID answers with `snmpwalk`, stand up a collector that writes to a TSDB, add it as a datasource, and chart `hrProcessorLoad`, the storage table, and uptime with threshold lines. Then keep alerting separate and external — because a grafana snmp dashboard is for the humans watching trends, and an independent checker is what catches the outage when nobody's looking. For related use-cases, browse the full [SNMP monitoring guides](/guides/index.md) or return to the [knowledge base home](/index.md).