
What useful monitoring screens show
Every monitoring tool draws its screens differently, but the useful ones answer the same six questions. Is anything broken right now? What just happened? How busy is this link? What is still open, and who owns it? How did we do this month? And what do we know about this one box?
The panels on this page are sample panels drawn for this page. They use made-up hosts and documentation addresses, and they are not screenshots of any product. The layout is deliberately generic, so you can carry what you learn to whatever console you sit in front of, whether you are evaluating a tool or inheriting one someone else built.
Read in order, the six screens follow an operator's shift: the overview, the stream of events, the numbers behind them, the open problems, the monthly view, and finally everything about a single device. The operator's guide turns that order into a routine for the first fifteen minutes of a shift.
The status map
- core-rtr-0110.0.0.1up
- core-sw-0110.0.0.2up
- fw-edge-01203.0.113.2up
- dist-sw-0210.0.10.2up
- branch-rtr-0310.3.0.1down
- ap-floor2-0710.0.20.57warn
- ups-mdf-0110.0.0.40up
- nas-0110.0.30.10up
- voip-gw-0110.0.40.5ack
The status map answers one question from across the room: is anything broken, and where? Sites, racks or individual hosts appear as tiles or nodes, each colored by the worst current state of the things inside it, sometimes with lines for the links between them.
Read it from the outside in. A red site tile may hold one red interface out of four hundred, so click through before you raise your voice. Green, yellow and red are the common states, but the one to learn first is "unknown" or "unreachable", often gray or purple. It means the monitor has no fresh data, which is not the same as healthy. When a WAN router dies, a well-built map shows the branch behind it as unreachable rather than forty separate red hosts, because each host has a parent it depends on.
A good map fits on one screen without scrolling, groups by site or function, makes acknowledged problems look different from new ones, and shows when it last refreshed. The common mistakes are the opposite: one giant topology drawing nobody can read, a hand-drawn map that stopped matching the network two moves ago, a printer's access port turning the whole headquarters tile red, and no refresh time, so a frozen browser tab looks like a calm night.
The event console
| Time | Host | Object | Event | Severity |
|---|---|---|---|---|
| 14:02:11 | branch-rtr-03 | Gi0/0 | Interface down | Critical |
| 14:02:09 | branch-rtr-03 | BGP 198.51.100.1 | Neighbour down | Major |
| 13:58:40 | ap-floor2-07 | radio1 | Clients over threshold | Warning |
| 13:41:05 | core-sw-01 | Te1/0/48 | Errors rising (CRC) | Minor |
| 13:12:52 | fw-edge-01 | auth | SSH login failed x5 | Warning |
| 12:30:00 | nas-01 | vol1 | Usage 81 % | Info |
The event console is the raw stream: every timestamped fact the monitor received from polls, traps and syslog, newest first. Typical columns are time, host, object, event type, severity and a short message. An event is something that happened; it is not yet a problem someone has to own.
Scan it for patterns rather than single lines. Twenty events in the same minute from different hosts usually share one cause upstream. A down and up pair repeating every few minutes on the same port is a flap, and the cable or the far-end device deserves attention more than the alerts do. A steady trickle of authentication failures from one address is worth a ticket of its own.
What good looks like: saved filters for each team, so the core network group is not reading printer toner warnings; restrained use of color, so critical still stands out; every row linked to its host and interface; and one time zone across the whole console, with the zone shown. Common mistakes include treating the console as the to-do list (that is the alarm list's job), letting debug-level messages in until the screen scrolls faster than anyone can read, and mixing local time with UTC so events from two sources appear out of order. The guide to events and severities covers how events become alarms.
The traffic graph
inbound outbound Mbit/s, 5-minute averages
The traffic graph shows how much an interface carried over time, inbound and outbound, against what it can carry. It is the screen people open when someone says "the network is slow".
Check three things before you believe it. First the units: bits per second is the norm, but some tools default to bytes, a factor of eight. Then the direction: "in" is from the device's point of view, so inbound on a switch uplink is traffic arriving at that switch, which is outbound on the router at the other end. Finally the averaging step. A five-minute average of 400 Mbit/s on a 1 Gbit/s port can hide one-minute bursts at line rate, and over a year the stored history is averaged into coarse steps that flatten peaks unless the maxima are kept as well.
A good graph scales its vertical axis to the port speed or draws a capacity line, shows both directions, and lists current, average and peak values (often the 95th percentile too). An errors and discards graph sits next to it, because a link can look half empty and still drop packets. The classic mistakes are an auto-scaled axis that makes 2 Mbit/s of background noise look like a crisis, and a sudden spike that is really a 32-bit counter wrapping or resetting at reboot. Interface counters explained shows why that happens and how 64-bit counters avoid it.
The alarm list
| Host | Alarm | Open for | State | Acknowledged |
|---|---|---|---|---|
| branch-rtr-03 | Gi0/0 down | 00:14:20 | Critical | No |
| voip-gw-01 | Trunk 2 down | 01:02:11 | Ack | Yes, carrier ticket open |
| ap-floor2-07 | Clients over 60 | 00:03:42 | Warning | No |
| core-sw-01 | CRC errors on Te1/0/48 | 00:21:08 | Minor | No |