What a network monitoring system does, and the words it uses

A network monitoring system, usually shortened to NMS, is software that keeps asking your equipment how it is doing, listens when the equipment volunteers bad news, writes all of it down, and tells a person when something needs attention. That is the whole job. Everything else in this manual (pollers, traps, templates, triggers, availability reports) is detail about how one part of that job gets done.

This chapter sets out the vocabulary. Monitoring tools disagree about names: one product's "item" is another's "service check", "metric", "sensor" or "interface". The ideas underneath are the same everywhere, and once you can map a tool's words onto them, you can read any NMS documentation without getting lost.

Three questions every monitor answers

A useful NMS answers three questions, roughly in order of urgency.

1. Is it up? A router, a switch port, a web service, a UPS: is it reachable and doing its job right now?
2. Is it healthy? Up is not the same as fine. A link can be up and dropping 2 percent of its frames. A server can answer ping while its log disk sits at 98 percent.
3. What changed, and when? When someone says "the network was slow on Tuesday afternoon", stored history is the only thing that can settle it.

The first question is about state. The second and third are about values over time. That split runs through every chapter that follows, so it is worth holding on to.

The vocabulary in one table

Three of these cause most of the confusion for newcomers: what counts as an object, the difference between polling and pushed messages, and the difference between an event and an alarm. Each gets a section below.

Objects, or why "interface" means more than a port

Early SNMP tools called every monitored thing an "interface", because the first things anyone watched were router and switch ports. The word stretched to cover processes, TCP ports, fans, BGP sessions and TLS certificates. Newer tools mostly say "item", "service" or "check", but the model has not changed. A host is a container. The objects are what you actually monitor.

Every object has a type, and the type decides four things: how instances are found (discovery), what is collected, what is stored, and which graphs make sense. Anything with a state, one or more values, or both, can be an object. A switch port has both: up or down, plus traffic, error and discard counters. A certificate has one value (days until it expires) that a threshold turns into a state. A ping target has a state (answers or not) and two values (round-trip time and loss).

When you plan a monitor, count objects rather than hosts. A single 48-port access switch is one host and easily 60 objects once you add its uplinks, CPU, memory, fans and power supplies.

Pulled and pushed

Information reaches the monitor in two ways.

Polling is the monitor taking the initiative. On a schedule it sends an SNMP request, a ping, a TCP connection attempt or an HTTP request, or runs a script, and records what comes back. Polling is predictable: you know when the next sample is due, and silence is itself information. If a device stops answering, that is a fact you can raise an alarm on.

Pushed messages leave the device at the moment something happens. SNMP traps (UDP port 162) and syslog (UDP port 514 in its classic form) are the long-standing standards; webhooks and streaming telemetry are newer ones. Pushed messages are fast, often seconds ahead of the next poll, and they carry detail a poll never sees, such as which user saved a configuration. They are also unreliable in a particular way. Most travel over UDP, so a dropped packet is simply gone, and a device that has lost power sends nothing at all.

Good setups use both. The trap or log line brings the news early; the next poll confirms it and catches anything the push missed. A ping on its own answers only the first of the three questions; the article ping is not monitoring makes that case in detail. The polling chapter covers the pull side in depth.

Events are not alarms

An event is a fact with a timestamp: this happened, at this time, to this object. Events pile up quickly. A modest network produces thousands a day: logins, configuration saves, links bouncing, thresholds crossed. They are the raw record. You keep them for a set period and then purge them.

An alarm is a condition: this object is in a bad state, it has been since 10:42, and it is still open. One event opens an alarm (link down) and another closes it (link up). In between, ten more "link down" events for the same port should not open ten more alarms. They belong to the one already open. That bookkeeping (matching events to objects, folding duplicates together, opening and closing alarms) is usually called consolidation, and it has its own chapter on how monitoring data flows.

The distinction matters because people should be paged for alarms, not events. A console that lists every event is a log viewer. A console that lists open alarms is a to-do list.

One check, from poll to page

Here is one check followed from start to finish. The object is port Gi1/0/48 on an access switch called sw-b2-acc1 at 10.20.4.11. The port is the uplink to the building's distribution switch, and the monitor polls interface status every 60 seconds.

1. 14:03:00. The scheduler hands the host to a poller, which sends an SNMP GET for ifOperStatus on that port (OID 1.3.6.1.2.1.2.2.1.8 plus the port's index) and gets back up(1). Nothing has changed, so the result goes into history and the poller moves on.
2. 14:03:31. Someone unplugs the fiber in the wiring closet. The switch sends a linkDown trap to UDP 162 on the monitor and a syslog line to UDP 514. Both arrive within a second.
3. 14:03:32. The trap receiver and the syslog receiver each turn their message into a normalized event: host sw-b2-acc1, object Gi1/0/48, type link, state down. The monitor recognizes that both describe the same fact and keeps a single alarm, with the trap and the log line attached as evidence.
4. 14:03:32. The alarm opens. The port turns red on the status map, and so does the switch, because a host shows the worst state of its objects.
5. 14:04:00. The next poll returns down(2) and confirms the news. Had the trap been lost on the way, this poll is what would have opened the alarm, 28 seconds later.
6. 14:05:32. A trigger rule says that uplink ports down for 2 minutes page the on-call engineer. The 2-minute delay is there so a port that bounces and recovers does not wake anyone. The alarm is still open, so the page goes out.
7. 14:11:10. The engineer acknowledges the alarm with a note: "B2 closet, on my way". The acknowledgement stops repeat pages and tells the rest of the team that someone owns the problem.
8. 14:26:45. The fiber is back in. A linkUp trap, a log line and the next poll close the alarm. Its start and end times (23 minutes 13 seconds apart) feed the month's availability report for that port.

Every NMS, from a hobby setup on a single-board computer to a carrier's monitoring cluster, runs some version of those eight steps. Products differ in how you configure each step, not in whether the steps exist.

Who needs one

A small office has 10 to 50 devices: a firewall, a couple of switches, a few Wi-Fi access points, a NAS and the printer everyone blames. The payoff is knowing about a problem before the staff do, plus traffic graphs that settle the "is the internet slow again" argument with evidence. A small virtual machine or a mini PC is plenty.

A school or school district runs hundreds of access points and switches across several buildings with a small IT team, and load arrives in predictable bursts: testing days, the first period of the morning. Monitoring earns its keep there through per-building maps and views, and through availability reports that support budget requests.

An ISP or hosting provider has thousands of interfaces, customer-facing service levels and contracts tied to traffic figures. Polling at scale, 64-bit counters, distributed pollers and careful de-duplication of alarms stop being optional.

A home lab has a router, a managed switch, a hypervisor and a Raspberry Pi or two. Nobody strictly needs a monitor at home, which is exactly why it is a good place to learn one. Everything in this manual can be practiced on a home network first, where a misconfigured trigger pages nobody but you.

A reading order through the manual

The chapters are written to stand alone, but if you are starting from nothing, this order works well.

1. This introduction, for the vocabulary.
2. Installing a monitoring server: sizing, the software stack, and the first hour after install.
3. How monitoring data flows: raw input, events, consolidation, alarms and actions.
4. Polling: the kinds of poller, intervals, timeouts and keeping up.
5. SNMP traps, then turning syslog lines into events, for the pushed side.
6. Events, filters and triggers, in that order, to turn data into alerts that people read.
7. Organizing hosts and the catalogue of object types, to decide what you watch.
8. Common errors, day-to-day administration and working the operator console, for running the system.
9. Writing your own checks, external programs and distributed polling, once the basics hold up.

Every chapter is listed on the manual index. If you take one idea from this page, take the split between events and alarms: collect as many events as you like, but only ever ask a person to act on an alarm.