A utilization graph shows the uplink at 95% at 10:12. It does not say who caused it, whether the traffic was legitimate, or what broke. For that you need logs (what happened) and flows (who talked to whom).
Syslog: severity and structure
| Severity | Meaning | Typical use |
|---|---|---|
| 0 | Emergency | Device unusable |
| 1 | Alert | Immediate action |
| 2 | Critical | Severe |
| 3 | Error | Something failed |
| 4 | Warning | Attention, not failure |
| 5 | Notice | Normal but significant |
| 6 | Informational | Routine |
| 7 | Debug | Development only |
Most networks log at 5–6 and drown. A workable policy: send 0–4 everywhere, 5 for auth and config changes, and never 7 outside a lab.
Structured logs — key=value pairs or JSON — are worth the effort because they can be searched. A line
like user=concken src=10.40.60.84 action=login result=fail is a query; a sentence is a reading
exercise.
Logs without time are anecdotes
If a device's clock is wrong, its logs cannot be correlated with anything. Every device that logs should sync to the same time source, and the collector should reject or flag timestamps that jump backwards.
Flow data: who talked to whom
Flow protocols summarize connections rather than capturing packets:
| Protocol | Notes |
|---|---|
| NetFlow v5 | Fixed format, IPv4 only, legacy |
| NetFlow v9 | Template-based, IPv6 capable |
| IPFIX | Standardized NetFlow v9 |
| sFlow | Packet sampling, works on switches without full flow tables |
A flow record usually contains: source and destination address, ports, protocol, byte and packet counts, start and end time, input/output interface, and sometimes the next hop.
That is enough to answer:
- Which host is consuming the uplink?
- Which destinations are popular at 10:00?
- Is traffic to a country or ASN that should not appear?
- Did the backup run over the WAN instead of the LAN?
It is not enough to answer "what was in the packet." For that, capture.
Sampling, and honesty about it
High-end routers cannot export a record for every packet. Sampling at 1:1000 is normal, and it is fine for top-talker analysis — the heavy hitters remain heavy. It is not fine for accounting or for finding a single small flow.
If your flow data is sampled, say so in the dashboard. A "total bytes" number derived from 1:1000 sampling is an estimate with a wide error bar.
Storage, roughly
| Data | Volume at 3,000 devices | Keep |
|---|---|---|
| Syslog at 5 | 1–5 GB/day | 90 days |
| Flows, 5-minute aggregation | 2–10 GB/day | 30 days |
| Full packet capture | terabytes | hours, if ever |
The last row is why full capture is a troubleshooting tool, not a monitoring strategy.
Worked example: the 10:12 spike
- Metric: uplink at 95% for 14 minutes.
- Flow: top talker is
10.40.12.88sending 4.2 GB to an external address on 443. - Log: the device's MDM log shows a policy push at 10:11.
- Capture (30 seconds): confirms a bulk upload, not a compromise.
Four data sources, four minutes, and a conclusion you can defend. With only the metric, the answer would have been "the network was busy."
What breaks in production
- Everything at debug level, so the collector stores noise and the disk fills.
- No time sync, so correlation fails exactly when you need it.
- Flows without interfaces, so you cannot tell which building generated the traffic.
- Sampling presented as exact, producing wrong capacity decisions.
- Logs kept for a week, which is shorter than the time it takes a problem to be noticed.
Checklist
- Severity policy is explicit and enforced at the device.
- All logging devices sync to a common time source.
- Flow export includes interfaces and is aggregated to a useful interval.
- Sampling rates are documented on the dashboards that use them.
- Retention matches the detection time of your slowest-moving problem.
- Logs are structured enough to search by user, source, and action.
Next
Three data types, one more distinction to make: metrics, logs, and traces as design choices. Continue with Metrics, Logs, Traces.