The Pain of Silent “Black Box” Network Devices
Have you ever been in a situation where your boss is standing behind you asking, “Why is the network slow?” while you’re frantically SSHing into every Cisco Catalyst switch to type show interface status? When your system grows to about 20-30 devices, this manual management becomes a real burden.
For Linux or Windows servers, we have Node Exporter. But network appliances run closed operating systems. You can’t install any agents on them. Without monitoring bandwidth or port errors (input/output errors), you’ll always be reactive when network congestion occurs.
Why Can’t Prometheus “Talk” Directly to Switches?
Prometheus operates on a pull mechanism. It requires targets to provide an HTTP endpoint with data in a simple text format. Conversely, network devices, old and new, primarily use SNMP (Simple Network Management Protocol).
This protocol uses a highly complex OID (Object Identifier) tree structure and runs over UDP. The two simply don’t speak the same language. To solve this, we need a “translator” in the middle. That’s the role of the SNMP Exporter.
Evaluating Common Monitoring Solutions
Here are a few options network administrators often consider:
- Zabbix: The “king” of SNMP. However, if your team is already using Prometheus for all servers, setting up Zabbix will cause data fragmentation and increase operational overhead.
- Writing Python Scripts: Manually running
snmpwalkand pushing data to Pushgateway. This is quick at first but becomes a maintenance nightmare as the number of devices grows. - SNMP Exporter: The standard solution from the Prometheus ecosystem. It’s lightweight, efficient, and integrates seamlessly with Grafana.
A Practical Workflow for Deploying Prometheus SNMP Exporter
I prefer SNMP Exporter for its ability to centralize all metrics. Here are the steps I’ve applied for enterprise systems with over 50 Core and Access switches.
1. Enable SNMP on Network Devices
You need to configure the device to accept SNMP queries. For example, on a Cisco switch, execute the following commands:
# Enter configuration mode
conf t
# Create Community String (acts as a password for reading data)
snmp-server community MySecretPassword RO
# Restrict access to the monitoring server IP only (e.g., 192.168.1.50)
access-list 10 permit 192.168.1.50
snmp-server community MySecretPassword RO 10
Note: Prioritize SNMP v2c or v3. Avoid v1 as it is very slow and doesn’t support 64-bit counters for high-speed ports above 1Gbps.
2. Run SNMP Exporter with Docker
Docker is the fastest way to deploy without worrying about dependencies. Create a docker-compose.yml file as follows:
version: '3'
services:
snmp-exporter:
image: prom/snmp-exporter
container_name: snmp-exporter
restart: always
ports:
- "9116:9116"
volumes:
- ./snmp.yml:/etc/snmp_exporter/snmp.yml
3. Configure the snmp.yml File
The snmp.yml file contains thousands of lines of OID definitions, so you can’t write it by hand. Typically, we use the Config Generator to create this file from vendor MIB files.
To get started quickly, download the sample file supporting Cisco, HP, and APC from the official GitHub. A lesson I learned: always ask the vendor for MIB files when purchasing new equipment to make future monitoring easier.
4. Define Devices in Prometheus
Open the prometheus.yml file and add a new job. SNMP Exporter acts as a proxy. Prometheus sends a request to the Exporter, which then queries the network device.
scrape_configs:
- job_name: 'snmp_network_devices'
static_configs:
- targets:
- 192.168.1.1 # Core Switch IP
- 192.168.1.2 # Edge Router IP
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: 192.168.1.50:9116 # IP of the machine running SNMP Exporter
5. Visualize Data on Grafana
Don’t settle for raw text in Prometheus. Go to Grafana, select “Import Dashboard,” and enter ID 11169. This is a highly professional template for SNMP.
All metrics will appear clearly: In/Out bandwidth per port, Up/Down status, and especially the Error rate. If you see the Error rate spiking on a specific port, there’s a high chance that the network cable is physically faulty.
Pro-Tips to Avoid Headaches
After several real-world deployments, here is some advice:
- Scrape Interval: Don’t set it too low (like 1s or 5s). Switch CPUs are usually quite weak. Intense SNMP queries can cause the device to hang or spike CPU to 100%. A 30s-60s interval is most reasonable.
- Leverage Descriptions: Give descriptive names to switch ports (e.g.,
Description: Uplink_To_Server_DB). SNMP Exporter will pick up these names, making your charts much easier to understand. - Smart Alerting: Only set alerts for critical Uplink ports. If every user port triggers a “Down” alert, your phone will explode with notifications.
Since implementing this system, I no longer have to guess when the network is slow. A quick glance at the dashboard tells me exactly where the problem lies. Good luck with your deployment and mastering your network infrastructure!

