SNMP Exporter

Last reviewed Sep 13, 2026 · 835 words

Nine out of ten SNMP Exporter problems are the same problem: the snmp.yml you are running does not contain the OIDs for the device in front of you. The exporter itself is a stateless Go binary that idles at around 20 MB and never needs restarting; all the difficulty lives in generating that config file from your hardware's MIBs, and once you have done it correctly for one device you can do it for any device in 15 minutes. This guide spends most of its words there, because the Prometheus side is 12 lines of scrape config.

How it fits: one exporter, many targets

Unlike node_exporter, which runs on the machine it measures, SNMP Exporter runs once and walks any number of devices on request. Prometheus asks the exporter for /snmp?target=10.0.0.1&module=if_mib&auth=public_v2, the exporter performs the SNMP walk against that target, and returns the result as Prometheus metrics. Default port 9116. One container monitors your whole switch closet, and adding a device is adding a target, not installing anything on it.

Prometheus needs the classic relabel dance to make this work:

scrape_configs:
  - job_name: snmp
    static_configs:
      - targets: ['10.0.0.1', '10.0.0.2']
    metrics_path: /snmp
    params:
      module: [if_mib]
      auth: [public_v2]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: snmp-exporter:9116

Copy that, change the targets and the exporter address, and the stock if_mib module gives you interface counters, errors, speeds and operational status for any device that speaks standard SNMP, which is every managed switch made this century.

The shipped snmp.yml is a starting point, not a product

The release tarball and Docker image include a generated snmp.yml with a handful of modules: if_mib, plus vendor ones for common gear such as Cisco, Ubiquiti, APC-style UPSes, printers and Synology. If your device is covered, you are done. If it is not, or you want vendor-specific metrics like PoE power per port, fan speeds or temperature, you need the generator.

The generator is a separate binary in the same repository. You give it a generator.yml naming the modules you want and the OIDs or MIB objects to walk, plus a directory of MIB files, and it writes snmp.yml with every OID resolved, every index and label handled, and every enum mapped:

auths:
  public_v2:
    community: public
    version: 2
modules:
  my_switch:
    walk:
      - ifTable
      - ifXTable
      - 1.3.6.1.4.1.9.9.13.1.3   # ciscoEnvMonTemperatureStatusTable
    lookups:
      - source_indexes: [ifIndex]
        lookup: ifName

Then MIBDIRS=./mibs ./generator generate and restart the exporter with the output. The auths and modules split is the current config format; older tutorials that put the community string inside each module describe a layout the exporter no longer accepts, and that is the single most common reason a copied config fails to load.

Where the MIB fetching goes wrong

The generator needs the vendor MIBs and everything they import, and vendors are inconsistent about publishing them. The repository's Makefile fetches a curated set covering the common cases. For anything else you will be downloading a zip from a support portal, discovering it depends on three other MIBs, and hunting those down. snmptranslate -Tp from net-snmp is the tool for checking that a MIB tree resolves before feeding it to the generator. Plan for an hour per new vendor the first time, and keep the MIB directory in Git next to your generator.yml so the next person does not repeat it.

SNMPv3 with authentication and privacy is fully supported in the auths block, and you should use it on anything reachable from a network you do not fully control; v2c community strings travel in plaintext.

What it is not

It is not a network monitoring system. There is no discovery, no topology, no per-device dashboards, no alerting; you bring those. Grafana has community dashboards for if_mib that get you traffic graphs per interface in minutes, and Alertmanager handles the "port 24 has been down for 5 minutes" rules. If you want the whole thing in one install with auto-discovery and a device inventory, LibreNMS is the mature choice and the safer pick for anyone who does not already run Prometheus. The exporter is for people who have committed to Prometheus and want their network gear to be ordinary time series alongside everything else in the monitoring category.

What I'd do

Run the exporter as a container beside Prometheus, start with the stock snmp.yml and if_mib to prove the pipeline, then build a generator.yml per vendor and commit it with the MIBs. Use SNMPv3 everywhere it is offered. Scrape every 60 seconds; switches do not change faster and some older gear takes 10 seconds to answer a full walk. And if you have no Prometheus yet and just want to see your switches, install LibreNMS instead and come back to this when your metrics already live in Prometheus.