Skip to content
A dark operations desk at night with out-of-focus monitors, a coffee mug and a rack behind

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

Status map · HQ and branch
  • 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
Sample panel drawn for this page: hosts on a site map, colored by the worst state of anything on them.

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

Event console · last 2 hours
TimeHostObjectEventSeverity
14:02:11branch-rtr-03Gi0/0Interface downCritical
14:02:09branch-rtr-03BGP 198.51.100.1Neighbour downMajor
13:58:40ap-floor2-07radio1Clients over thresholdWarning
13:41:05core-sw-01Te1/0/48Errors rising (CRC)Minor
13:12:52fw-edge-01authSSH login failed x5Warning
12:30:00nas-01vol1Usage 81 %Info
Sample panel drawn for this page: every event in one time-ordered list, newest first.

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

core-rtr-01 · Gi0/1 (uplink, 100 Mbit/s)
025507510000:0006:0012:0018:0023:00

inbound outbound Mbit/s, 5-minute averages

Sample panel drawn for this page: one interface, one day, inbound and outbound rates from octet counters.

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

Open alarms · 4
HostAlarmOpen forStateAcknowledged
branch-rtr-03Gi0/0 down00:14:20CriticalNo
voip-gw-01Trunk 2 down01:02:11AckYes, carrier ticket open
ap-floor2-07Clients over 6000:03:42WarningNo
core-sw-01CRC errors on Te1/0/4800:21:08MinorNo
Sample panel drawn for this page: what is still wrong right now, with who has taken it.

The alarm list is the to-do list: one row per open problem, not one per event. Each row shows the object, its state, how long it has been in that state, its severity, whether someone has acknowledged it, and often a ticket number or a short note.

Sort it by severity, then by age. Unacknowledged critical alarms belong at the top. The duration column tells you whether a problem started ten minutes ago or has been "normal red" since spring, and both deserve a decision, just different ones.

A good alarm list is short enough to read in one go. Alarms clear on their own when the condition clears, acknowledged rows carry a comment saying who is on it, and planned maintenance keeps expected outages off the list entirely. Watch for these mistakes:

The availability report

Availability · September (30 days, maintenance excluded)
HostAvailableDownOutages
core-rtr-0199.998 %0 h 01 m1
fw-edge-0199.991 %0 h 04 m2
branch-rtr-0399.712 %2 h 04 m5
voip-gw-0199.950 %0 h 21 m1
nas-01100.000 %0 h 00 m0
Sample panel drawn for this page: a month of availability per host, the numbers an SLA conversation starts from.

The availability report looks back over a period, usually a month: for each host, interface or service, the percentage of time it was up, the minutes it was down, and the number of separate incidents.

The number means little until you know how it was calculated. Is planned maintenance excluded? When the monitor itself was down, does that time count as up, down, or neither? Is "available" measured by a ping to a router, when users care about the application behind it? Keep the scale in mind too: over a 30-day month, 99.9 percent allows 43.2 minutes of downtime and 99.99 percent about 4.3 minutes. The uptime and SLA calculator does that arithmetic for any target and period.

A good report shows minutes beside every percentage, lists the incidents behind each number, states its method in a line at the top, and marks exclusions clearly. Common mistakes are averaging percentages across devices of very different importance, counting the monitor's own outages as uptime, and comparing months that used different exclusion rules.

The host detail page

Host · core-sw-01
sysName
core-sw-01
Address
10.0.0.2
Uptime
87 days 04:12
Model
48-port access switch
CPU (5 min)
7 %
Memory used
41 %
Temperature
38 °C
Ports up
44 of 52

Te1/0/1 uplinkCPUTemperature

Sample panel drawn for this page: one device on one screen, with the few graphs that explain its day.

The host detail page gathers everything about one device. At the top: its name and address, model and software version (from sysDescr), location and contact (from sysLocation and sysContact), and uptime (from sysUpTime). Below that: the interfaces and services with their states, a few key graphs such as CPU, memory and temperature, recent events, open alarms, the parent it depends on, and whether it is in maintenance.

Read it top down. A recent reboot explains a surprising number of odd graphs, so check uptime first. Then open alarms, then the recent events, then the graphs around the time the trouble started.

A good page fetches identity fields from the device instead of relying on someone to type them, keeps a notes field with who to call and where the box physically sits, links to the runbook, and offers quick tools such as ping and an SNMP get run from the monitoring server. Common mistakes: a page so long that the open alarm sits below the fold, notes nobody has updated in years, interfaces listed by index number without their descriptions, and community strings or other credentials visible to every user who can open the page.

When you next evaluate a monitoring tool, ask to see these six screens in the demo, filled with real data, and try a short test: hand the console to a colleague who has never used it and ask what is broken, since when, and who is working on it. A tool that lets them answer all three in under a minute is doing its job.