SNMP + Grafana: How to Visualize SNMP Metrics

By the SNMP Monitoring team · Reviewed July 2026

Here's the misconception that trips up almost everyone who wants SNMP graphs: Grafana does not poll SNMP. Grafana is a visualisation layer — it draws whatever a data source hands it — and it has no native SNMP data source that goes out and queries your agents. So you can't just point Grafana at a switch and get interface graphs. What you do instead is put a collector in the middle: something that actually polls the OIDs, stores the results as time series, and presents them to Grafana as a data source. There are two standard ways to do that, and this guide walks both. Get the pipeline right and you'll have live SNMP dashboards; skip the collector and you'll spend an evening hunting for a data source that doesn't exist.

Parent: guides. Related: SNMP vs Prometheus, interface sensor, all sensors.

The two standard paths

Both routes end at Grafana; they differ in what does the polling and storing:

Neither is "better" in the abstract — pick the one that fits what you already run. If your shop is Prometheus-based, Path A slots in naturally. If you'd rather have a straightforward poller writing to a purpose-built time-series database, Path B is cleaner. Both are mature, well-documented, and widely used for exactly this. The deeper contrast between SNMP's pull model and Prometheus's is on SNMP vs Prometheus.

Path A: Prometheus + snmp_exporter

Prometheus can't speak SNMP either — that's what the snmp_exporter is for. It sits between Prometheus and your devices, translating a scrape into SNMP polls using a config that maps OIDs to metrics. The flow:

1. Generate the config. snmp_exporter uses a generated snmp.yml (produced by its generator from your MIBs) that maps the OIDs you care about — interfaces, CPU, storage — to named metrics. Start from the shipped example and add your modules.
2. Run the exporter pointed at that config; it listens on its own HTTP port.
3. Scrape it from Prometheus. Add a job that targets the exporter, passing the device address as a parameter so one exporter can poll many devices:

scrape_configs:
  - job_name: snmp
    static_configs:
      - targets: ["10.0.0.20"]
    metrics_path: /snmp
    params:
      module: [if_mib]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 127.0.0.1:9116

4. Query in Grafana with PromQL. Add Prometheus as a data source and build panels against metrics like ifHCInOctets. Prometheus scrapes the exporter, the exporter polls the device, Grafana queries Prometheus — three hops, each doing one job.

The generator step is the part people miss: the exporter only exposes what its config maps, so if a metric isn't in snmp.yml, it won't appear. Add the module, regenerate, reload.

Path B: InfluxDB + Telegraf

The InfluxDB route uses Telegraf, which does poll SNMP directly through its snmp input plugin — no separate exporter needed. The flow:

1. Configure the Telegraf snmp input with your device address, credentials, and the OIDs or tables to poll (interfaces, CPU, storage), plus an outputs.influxdb (or v2) block pointing at your InfluxDB.
2. Telegraf polls on its interval and writes the readings as time series into InfluxDB — it handles the SNMP conversation itself.
3. Add InfluxDB as a Grafana data source and build panels with InfluxQL or Flux, depending on your InfluxDB version.

A minimal Telegraf snippet:

[[inputs.snmp]]
  agents = ["udp://10.0.0.20:161"]
  version = 2
  community = "S3cr3tR0str1ng"
  [[inputs.snmp.field]]
    name = "uptime"
    oid = "1.3.6.1.2.1.1.3.0"
  [[inputs.snmp.table]]
    oid = "1.3.6.1.2.1.31.1.1"
    name = "interfaces"

This path has one fewer moving part than Path A — Telegraf is both the poller and the shipper — which some teams find simpler to reason about. The trade-off is that you're running the InfluxDB/Telegraf stack rather than the Prometheus one.

Building panels

Once a data source is wired up, the panels are the same regardless of path — you're just querying stored time series. The metrics people build first:

• Interface bandwidth — rate of ifHCInOctets/ifHCOutOctets converted to bits per second; the single most-requested SNMP graph. See interface sensor for the underlying counters.
• Disk usage % — computed from the HOST-RESOURCES storage table (used ÷ size × 100) per volume.
• CPU load — per-processor or aggregate, depending on the device.
• Uptime / availability — sysUpTime, useful for spotting reboots.

For counters like octets and errors, remember to graph the rate (a rate() in PromQL, a derivative in InfluxDB), never the raw ever-climbing total — the raw counter is meaningless as a line. Gauges like temperature or disk percent you plot directly.

Importing community dashboards

Grafana's dashboard library has ready-made SNMP dashboards, and they're a fine head start — but import them with care. A community dashboard was built against someone else's devices and their exact metric names and OIDs. If your snmp_exporter config or Telegraf setup names things differently, or your devices expose different tables, panels will show "No data" until you reconcile them. So treat an imported dashboard as a template: check that the queries reference metrics your pipeline actually produces, and adjust the OIDs and labels to match your devices. Verifying that the dashboard's OIDs match what your hardware exposes — using all sensors as a reference — saves a lot of "why is this panel empty" confusion.

Frequently asked questions

Can Grafana poll SNMP directly?

No. Grafana is a visualisation tool with no native SNMP data source — it can't go out and query your agents. You need a collector in between: either Prometheus with snmp_exporter, or InfluxDB with Telegraf's SNMP input. The collector polls the OIDs and stores the data as time series, and Grafana queries that store. Any tutorial claiming a direct Grafana-to-SNMP connection is mistaken.

How do I show SNMP metrics in Grafana?

Route SNMP through a collector. In the Prometheus path, snmp_exporter translates scrapes into SNMP polls and Prometheus stores the results, which Grafana queries with PromQL. In the InfluxDB path, Telegraf's snmp input polls the devices directly and writes to InfluxDB, which Grafana queries with InfluxQL or Flux. Then build panels against the stored metrics like interface bandwidth or disk usage.

Should I use Prometheus or InfluxDB for SNMP with Grafana?

Pick the one that fits your existing stack. If you already run Prometheus or want its ecosystem, use snmp_exporter and PromQL. If you'd rather have a direct poller writing to a time-series database, use Telegraf and InfluxDB — it has one fewer moving part since Telegraf both polls and stores. Both are mature and widely used; there's no wrong choice, only the one that matches what you run.

Are community SNMP dashboards safe to import?

They're safe to import but rarely work unchanged. A community dashboard was built against different devices with specific metric names and OIDs, so panels will read "No data" if your pipeline names things differently or your hardware exposes different tables. Use it as a starting template: verify each panel's queries reference metrics your collector actually produces, and adjust OIDs and labels to match your own devices.

Key takeaways

• Grafana doesn't poll SNMP — there's no native SNMP data source; you need a collector in between.
• Path A: snmp_exporter → Prometheus (PromQL), driven by a generated snmp.yml mapping OIDs to metrics.
• Path B: Telegraf's snmp input → InfluxDB — one fewer moving part, since Telegraf polls and stores.
• Panels are the same either way; graph the rate of counters (octets/errors), plot gauges directly.
• Imported dashboards need their OIDs/metric names reconciled to your devices, or panels show "No data".
• For an independent off-box path alongside your dashboards, see external monitoring with ostr.io.