Skip to content
Log in Sign up My account

Network Monitoring Stacks

This article compares the monitoring platforms a network engineer is likely to meet or build: LibreNMS, Zabbix, Prometheus with the SNMP exporter and Grafana, Telegraf with InfluxDB for streaming telemetry, PRTG and SolarWinds. You will get what each does well, where it hurts, how the data flows, and a working starting point for the Prometheus route.

Try NetManager

NetManager is a monitoring and management app for multi-vendor networks (Aruba CX, Cisco IOS XE, Palo Alto, Aruba Central, UniFi), from the same author as this site. The live demo runs it against a simulated company network. A free cisconets.com account includes 7 days of read-only demo access.

Polling, traps, logs and streaming

Monitoring tools mix four data sources. Know which one a tool is built around.

Source How it works Typical transport
SNMP polling Collector asks devices for counters and state at an interval UDP 161
SNMP traps and informs Device pushes an event UDP 162
Syslog Device pushes log lines UDP 514, or TCP/TLS
Streaming telemetry Device pushes structured data on a subscription (gNMI or Cisco model-driven telemetry) gRPC
Flow export Device exports flow records (NetFlow, IPFIX) UDP, port set by collector

SNMP is still the lowest common denominator. Use SNMPv3 with authentication and encryption where the platform allows it. On IOS XE:

snmp-server view MONVIEW iso included
snmp-server group MONGRP v3 priv read MONVIEW
snmp-server user monuser MONGRP v3 auth sha AuthPass123 priv aes 128 PrivPass123

Test from the collector before configuring any tool:

snmpwalk -v3 -l authPriv -u monuser -a SHA -A AuthPass123 -x AES -X PrivPass123 192.0.2.1 sysDescr

If this fails, the monitoring tool will fail too, and the tool's own error messages are usually worse.

Warning

The passwords above are placeholders. Use unique credentials per environment and keep them in a secrets store, not in config files in Git.

LibreNMS

What it is. An open source (GPLv3) network monitoring system written in PHP, a descendant of the Observium codebase. It is built around SNMP auto-discovery.

Strengths.

  • Fast to a useful result: add a device, and it discovers interfaces, sensors, routing neighbours and graphs them without hand-built templates.
  • Broad device support through community-contributed OS definitions.
  • Built-in alert rules, syslog and trap reception, an API, and plugins.
  • Free, with a very active community.

Weaknesses.

  • Mostly SNMP and syslog; streaming telemetry is not its focus.
  • RRD-based graphing by default, with optional time-series integrations. Long retention at high resolution needs thought.
  • Customization beyond the supplied checks means working with its code and plugins.

Fits. Small and mid-sized teams that want a network-focused monitor with minimal setup.

Zabbix

What it is. An open source enterprise monitoring platform for servers, applications and network devices, with commercial support sold by the vendor. It uses a relational database (PostgreSQL or MySQL variants) and a web UI.

Strengths.

  • A flexible model: templates, low-level discovery, triggers with expressions, proxies for remote sites, and agents for hosts, alongside SNMP.
  • One system for server and network monitoring, which helps teams that own both.
  • Strong alert logic, maintenance windows and dependency handling, plus a large template library.
  • No feature-gated commercial edition; you pay for support and services.

Weaknesses.

  • A steeper learning curve than LibreNMS. Templates and discovery rules take time to tune.
  • Large installations need database tuning and housekeeping.
  • Network-specific views are less polished than in tools built only for networks.

Fits. Teams that want one monitoring platform for infrastructure, with real alerting logic and proxies for distributed sites.

Prometheus, SNMP exporter and Grafana

What it is. A composable stack. Prometheus (Apache 2.0) scrapes metrics over HTTP and stores them in a time-series database. The SNMP exporter translates SNMP into a Prometheus scrape target. Grafana (open source edition under AGPLv3) draws dashboards. Alertmanager handles notifications.

graph LR
    D["Network devices"] -- "SNMP UDP 161" --> E["snmp_exporter :9116"]
    E -- "HTTP scrape" --> P["Prometheus :9090"]
    P --> G["Grafana :3000"]
    P --> A["Alertmanager :9093"]
    A --> N["Email / chat / pager"]

Strengths.

  • A powerful query language (PromQL), efficient storage and a clean alerting model.
  • Fits environments that already use Prometheus for servers and Kubernetes; network metrics join the same dashboards and alerts.
  • Everything is configuration as code, which suits Git workflows.

Weaknesses.

  • You assemble it. There is no auto-discovery of interfaces or a device inventory out of the box; you generate the SNMP module from MIBs, and you maintain target lists (for example from NetBox via service discovery).
  • Pull-based and dashboard-first, so it has no built-in syslog or trap handling.
  • Long-term storage needs a remote-write backend or an additional component.

Fits. Teams with a platform or SRE mindset who want network metrics next to everything else.

A minimal Prometheus scrape job for the SNMP exporter, using the stock if_mib module (the exporter ships with a default snmp.yml; build your own with the generator for vendor MIBs):

scrape_configs:
  - job_name: snmp_switches
    metrics_path: /snmp
    params:
      module: [if_mib]
      auth: [public_v2]
    static_configs:
      - targets:
          - 192.0.2.1
          - 192.0.2.2
    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

The relabeling is the part that confuses people. Prometheus is told to scrape the exporter, and the device address is passed to it as the target query parameter. Define the auth entry (SNMPv3 credentials) in the exporter's configuration, not in the Prometheus file. Auth and module configuration changed format across exporter releases, so follow the README of the version you install.

A useful starting alert, with an interface-down rule:

groups:
  - name: network
    rules:
      - alert: InterfaceDown
        expr: ifOperStatus{ifAdminStatus="1"} != 1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }} {{ $labels.ifDescr }} is down"

Check that the label names match your generated metrics; they depend on the generator configuration.

Telegraf and InfluxDB for streaming telemetry

What it is. Telegraf (MIT) is an agent with many input and output plugins. InfluxDB is a time-series database. Together with Grafana they form a common path for model-driven telemetry.

Strengths.

  • Telegraf has inputs for SNMP, syslog, gNMI and Cisco model-driven telemetry (cisco_telemetry_mdt), so one collector handles several sources.
  • Streaming gives fine-grained data and sub-minute resolution without polling load, which suits interface counters, optics and BGP state.
  • Many output choices, so you can switch the database later.

Weaknesses.

  • Telemetry requires device support, subscription configuration per platform and YANG path knowledge.
  • Several tools from the same family change between major versions. Check which InfluxDB major version and query language you are deploying, and read its current documentation.
  • No built-in inventory or alert logic comparable to Zabbix; alerting is done in InfluxDB tasks or Grafana.

A skeleton Telegraf input for gNMI looks like this. Field names follow the plugin documentation; confirm them for your version:

[[inputs.gnmi]]
  addresses = ["192.0.2.1:9339"]
  username = "telemetry"
  password = "changeme"

  [[inputs.gnmi.subscription]]
    name = "interface_counters"
    origin = "openconfig-interfaces"
    path = "/interfaces/interface/state/counters"
    subscription_mode = "sample"
    sample_interval = "10s"

Port 9339 is the IANA-assigned gNMI port, but the port a given platform listens on depends on its configuration.

Fits. Teams adopting model-driven telemetry who want high-resolution data and are comfortable with YANG and gRPC.

PRTG

What it is. A commercial, Windows-based monitoring product from Paessler, licensed by the number of sensors. A sensor is one measured item, such as an interface's traffic or a ping check.

Strengths.

  • Quick to deploy, with auto-discovery, a clear web UI and many built-in sensor types for SNMP, flows, WMI and more.
  • Approachable for generalist IT teams and small networks.
  • Good reporting and mobile apps.

Weaknesses.

  • Sensor-based licensing means counts grow quickly if you monitor every interface. Check the current licensing, including any free tier.
  • Windows only for the core server, and less open for custom automation than the open source tools.
  • A single core server design limits some scaling patterns.

Fits. Small and mid-sized organizations with Windows skills who want a supported, quick-to-start product.

SolarWinds

What it is. A commercial suite on the Orion platform. Network Performance Monitor covers SNMP and topology, with modules such as NetFlow Traffic Analyzer for flows and Network Configuration Manager for config backup and change management.

Strengths.

  • A wide, integrated feature set: monitoring, flow analysis, config management, IP address management and more, all in one console.
  • Rich maps, dashboards and reporting.
  • A large installed base and a lot of operational experience in the market.

Weaknesses.

  • Commercial licensing that grows with modules and elements; get a current quote.
  • A heavy platform with Windows servers and SQL Server dependencies.
  • Security of the monitoring platform itself is a serious subject: any tool holding credentials for every device is a high-value target. Past supply-chain incidents in the industry are a reminder to patch it and isolate it.

Fits. Larger enterprises that want one vendor-supported suite and have budget and staff to run it.

Comparison table

Tool Licence Discovery Data sources Alerting Effort to run Best fit
LibreNMS Open source (GPLv3) Strong, automatic SNMP, syslog, traps Built in Low Network-only teams, quick start
Zabbix Open source, paid support Templates and LLD SNMP, agents, traps, scripts Very flexible Medium Mixed server and network monitoring
Prometheus + SNMP exporter + Grafana Open source Manual or via service discovery SNMP, many exporters Alertmanager Medium to high SRE-style, metrics-first
Telegraf + InfluxDB + Grafana Open source cores Manual gNMI, MDT, SNMP, syslog Tasks or Grafana Medium to high Streaming telemetry
PRTG Commercial, per sensor Good SNMP, flows, WMI Built in Low SMB and generalist teams
SolarWinds Commercial, modular Good SNMP, flows, config Built in Medium to high Large enterprise suite

Choosing and avoiding common traps

  • Start with questions, not tools. Which failures must you detect within a minute? Which trends do you need for a year? Who gets paged?
  • Do not alert on everything. Alert on interface errors over a threshold, BGP or OSPF neighbours leaving, high CPU sustained over minutes, power supply and fan failures, and optical power out of range. Graph the rest.
  • Standardize SNMP naming. Consistent ifAlias descriptions on uplinks turn raw data into something you can read.
  • Mix sources deliberately. SNMP for broad coverage, syslog for events, flows for who-talks-to-whom, and streaming telemetry where you need resolution.
  • Feed monitoring from your source of truth. See IPAM and Source-of-Truth Tools so devices are added and removed automatically.
  • Monitor the monitor. An alert system that is down looks like a quiet network.

References