What a network monitoring system should do
Feature lists on project pages tend to look alike: SNMP, graphs, alerts, maps, "extensible". They tell you what exists, not whether it works the way your network needs. This page is a checklist from the other side, written for the people who will live with the system: what a network monitoring system (NMS) has to do, grouped the way you would test it during a trial. Use it to compare candidates from the downloads directory, or to audit the system you already run.
How to read the columns
Must have means a candidate without it is out, however nice the rest looks. Nice to have breaks ties between two systems that both pass. Skip unless marks features that sound impressive but add cost, complexity or upgrade pain, and only pay off in particular situations.
| Area | Must have | Nice to have | Skip unless |
|---|---|---|---|
| System | Runs on an OS you can patch; documented backup and restore; handles your poll load with headroom | Distribution packages or containers; a standby central server | A clustered database: you poll tens of thousands of devices |
| Collection | SNMP v2c and v3, 64-bit counters, ICMP, TCP and HTTP checks, traps, syslog | Flow data (NetFlow, sFlow, IPFIX), agents, HTTP and JSON APIs | Full packet capture inside the NMS: you have nowhere else to keep it |
| Web interface | Event console, status overview, interface graphs with any time range, HTTPS | Nested maps, a wall-display mode | Animated or 3D maps |
| Alerting | Delays, dependencies, escalation, maintenance windows, email and webhooks | On-call schedules, chat and SMS integration | A built-in phone dialer: your paging service already does that |
| Access control | Roles, per-group scopes, read-only views, an audit log | Directory login or single sign-on, multi-factor login | Per-metric permissions |
| Discovery | Subnet scans, interface discovery, templates chosen by device type | Neighbor discovery over LLDP or CDP, scheduled rediscovery | Fully automatic adds with no review step |
| Reporting | Availability per host, interface and service, excluding maintenance; CSV export | Scheduled per-customer reports, 95th percentile | A full business-intelligence layer |
| Integrations | An API for hosts and events; ticket and chat webhooks | Config backup, IPAM or inventory sync, Grafana as a front end | Custom plugins only you would maintain |
The sections below explain what each row means in practice and what to try during a trial.
System
Start with the boring questions, because they decide what the next five years look like. What does it run on, and can you patch that OS on your normal schedule? Which database does it use, and where does it keep time series: RRD files, a time-series database or plain SQL tables? The storage choice decides how much history you can keep and how fast a year-long graph draws.
Ask about scale in polls per second, not in hosts. Three hundred devices with 30 monitored items each, polled every 60 seconds, is 9,000 values a minute, or 150 a second. Ask how the system behaves when a poll cycle overruns, and whether you can see it happening (the polling guide explains poll duration against interval).
Extensibility matters more than the list of built-in checks. If you can add a check by writing a script that prints a value or exits with the common 0, 1, 2, 3 codes for OK, warning, critical and unknown, no built-in list is ever really short.
Collection
SNMP is still the backbone for network gear, so the basics have to be solid: v2c and v3 (with authentication and privacy), bulk requests, and 64-bit counters such as ifHCInOctets. A 32-bit octet counter wraps in about 34 seconds at 1 Gb/s and in under 4 seconds at 10 Gb/s, so a system that reads only the old counters will draw nonsense for fast links.
Beyond SNMP, look for ICMP with loss and latency (not just up or down), TCP connect and HTTP checks with response time and certificate expiry, a trap receiver, and a syslog receiver that can turn lines into proper events (see turning syslog lines into events). Flow data, agents for servers, and polling of HTTP and JSON APIs are nice to have, and they become musts if you run many Linux hosts or cloud services.
Web interface
The event console is where operators live, so it carries the most weight in a trial. Look for one time-ordered stream that mixes poll results, traps and syslog, with filters you can save, and acknowledgement with a comment. Then check the status overview: can someone new to the team tell in ten seconds whether anything is wrong? Graphs need a free choice of time range, zoom, and side-by-side comparison of two periods. Maps and submaps are useful for sites and buildings, as long as somebody keeps them current. The whole interface must work over HTTPS and stay readable on a phone at 3 a.m.
Alerting
Alert features are where systems differ most and where a weak design costs the most sleep. The must-haves are a delay before firing (alert after three failed polls, not one), dependencies so a dead router does not page you for everything behind it, escalation when nobody acknowledges, maintenance windows, and at least email and webhooks as outputs. Test whether you can trigger a rule safely without paging the whole team. The triggers and actions guide goes through a full rule set for a small network.
Access control
Even a small team ends up with people who should see less than everything: a department head, a client of a managed service provider, the NOC wall display. Look for roles, permissions scoped by host group, read-only views and an audit log of who changed what. Directory login and multi-factor authentication are the next step up. The guide to users, customers and access control covers the design.
Auto-discovery
Discovery saves days on a new install and causes trouble when nobody watches it. A good implementation scans a subnet, identifies each device by its SNMP sysObjectID, picks a matching template, and discovers interfaces with filters so loopbacks and unused VLAN interfaces are not added by the hundred. Neighbor discovery over LLDP or CDP is a bonus. Insist on a review step, or at least a separate landing group, before discovered devices start sending alerts.
Reporting and SLAs
Availability reports should come from state history rather than from ping samples, should exclude maintenance windows you declared, and should work per host, per interface and per service. If you bill or report bandwidth, 95th percentile reporting saves a spreadsheet each month. CSV export is the minimum, because someone will always want the numbers in a different shape.
Integrations
An API for adding hosts and reading events turns the NMS from an island into part of your tooling: the inventory system can feed it, the ticketing system can open tickets from alarms, and a config backup job can run on the same host list. Grafana as an alternate front end is common and useful. Custom plugins are fine when a community maintains them, and a burden when the only maintainer is you.
Questions to ask during a trial
- Add ten real devices with SNMPv3. How long did it take, and did anything need a workaround?
- Unplug a test switch port. How long until the event appears, and does it clear by itself when the port returns?
- Take down a test router with hosts behind it. How many alerts arrive?
- Draw a 30-day traffic graph for a 10 Gb/s uplink. Does it look sane?
- Create a read-only user for one host group and log in as them. What can they see?
- Restore the configuration from backup onto a fresh machine. Does it come back complete?
- Read the upgrade notes for the last two major versions. Would you have survived them?
A system that passes those seven tests will cover most of what a small or medium network needs, whatever its feature page says.