Every monitoring system answers a question. Most answer "is the device responding to ping," which is almost never the question anyone has at 07:55.
The useful question is "can a student load the assignment page," and the six signals below are the shortest path to it.
Six signals
| Signal | Question it answers | How to get it |
|---|---|---|
| Availability | Can a client complete a transaction? | Synthetic check, not ping |
| Latency | How long does it take? | RTT, DNS time, TLS time, TTFB |
| Loss | Are packets arriving? | Interface counters, retransmits |
| Utilization | How full is the path? | 95th percentile, not average |
| Errors | Is the path degrading? | CRC, discards, resets |
| Capacity trend | When will this run out? | 30/90-day slope |
Ping measures whether ICMP is permitted. A switch can answer ping while its uplink is saturated, its DHCP scope is exhausted, and its clients cannot resolve a name.
User-centric beats device-centric
| Device-centric | User-centric |
|---|---|
| CPU 40% | Page loads in 1.8 s |
| Uplink 60% utilized | Video call has no gaps |
| AP online | Client associates in under 3 s |
| DHCP service running | Device gets a lease in under 1 s |
Device metrics are leading indicators and useful for diagnosis. User-centric checks are what you alert on, because they are what the ticket will say.
Baselines, and why averages lie
A school network has a shape: quiet at 06:00, a cliff at 07:45, a plateau until 15:30, then quiet. An average over 24 hours describes none of those states.
- Compare to the same hour last week, not to yesterday's average.
- Use p95 or p99, not mean, for latency and utilization.
- Record seasonality (first day of school, testing windows) so anomalies are not mistaken for faults.
Averages hide the outage
A link at 40% average utilization can be at 100% for the twenty minutes that matter. Percentiles show the minutes; averages show the month.
Resolution and retention
| Data | Resolution | Keep |
|---|---|---|
| Availability checks | 1 minute | 1 year |
| Interface counters | 1 minute | 90 days |
| Flow data | 5 minutes, sampled | 30 days |
| Logs | event | 90 days |
| Capacity trend | 1 hour | 2 years |
Higher resolution costs storage and CPU. One-minute availability with one-year retention is cheap; the same for raw flows is not.
Worked example: five checks that cover most failures
- DNS: resolve an internal name and an external name from a student VLAN every minute.
- DHCP: take a test lease on a lab VLAN every five minutes.
- Gateway: TCP connect to
10.0.0.1:443and measure the handshake time. - Internet: HTTPS GET to a known-good endpoint, measure TTFB.
- Uplink: poll interface errors and utilization on each building's uplink.
Five checks, five failure classes, and each one maps to a runbook. That is a better monitoring system than a wall of 400 device alerts.
What breaks in production
- Alerting on CPU and memory because they are easy, while the actual failure is a full DHCP scope.
- Ping as availability. Many devices rate-limit ICMP, producing false alarms and false confidence.
- Averages that smooth away the twenty minutes that mattered.
- No baseline, so every Monday looks like an anomaly and every real anomaly looks normal.
- Measuring the wrong side: the server is healthy and the path to it is not.
Checklist
- Every alert maps to a user-visible symptom.
- Availability is synthetic, not ICMP.
- Latency is p95, not mean.
- Counters are compared to the same hour last week.
- Retention is long enough for a trend and short enough to afford.
- Five checks cover DNS, DHCP, gateway, internet, and uplinks.
Next
The signals are chosen. Continue with SNMP, Still for the protocol that produces most of them.