Network Monitoring is the systematic process of continuously observing a computer network's components (routers, switches, firewalls, servers) to evaluate their health, performance, and availability. When a component fails or degrades, the monitoring system immediately alerts administrators, allowing them to resolve the issue—ideally before users even notice.
At an enterprise scale, you cannot wait for the CEO's phone call to know the internet is down. You need proactive fault detection and trend analysis.
Monitoring vs Logging vs Observability
While often used interchangeably, these represent different layers of maturity:
- Logging (Syslog): Recording discrete events that happened in the past ("User logged in").
- Monitoring (SNMP): Tracking predefined metrics against static thresholds ("CPU is at 99%").
- Observability: A modern concept where systems export highly detailed telemetry, allowing engineers to ask arbitrary questions to debug complex, unknown failures without relying on pre-configured dashboards.
Key Monitoring Areas and Methods
| Category | What is Monitored | Typical Method |
|---|---|---|
| Availability | Is the device physically turned on and reachable? | ICMP (Ping) |
| Interfaces | Port up/down status, bandwidth utilization, errors, discards. | SNMP Polling |
| Device Health | CPU, Memory, Temperature, Uptime, Power supply status. | SNMP Polling / API |
| Traffic Flow | Who is talking to whom, and consuming the most bandwidth. | NetFlow / IPFIX |
| Network Services | Is DNS resolving? Is the VPN tunnel up? Is the website responding with HTTP 200? | Active Service Checks |
Understanding Thresholds and Baselines
A common mistake for junior engineers is assuming static, arbitrary thresholds (e.g., "Alert me if bandwidth hits 80%"). Thresholds depend entirely on business requirements, link capacity, and historical traffic patterns.
- Baseline: What does "normal" look like? If a backup server runs every night at 2 AM and consumes 95% of a gigabit link, that is normal. Alerting on it would be useless noise.
- Warning vs Critical: A Warning threshold (e.g., 75% disk space) might generate an email ticket for next-day review. A Critical threshold (e.g., 95% disk space) might trigger a pager to wake an engineer up at 3 AM.
- Duration: A CPU hitting 100% for 5 seconds is normal operation. A CPU hitting 100% for 15 straight minutes is a fault. Alerts should require a duration condition to prevent "Flapping" (alerts turning on and off constantly).
A Practical Troubleshooting Workflow
How does monitoring integrate into daily operations? Consider this workflow for an office's WAN connection:
- Detection: The monitoring server detects the WAN router failing 3 consecutive ICMP pings. It triggers a Critical Alert.
- Verification: An engineer receives the alert. They check the dashboard and confirm the interface status is DOWN.
- Investigation: They review Syslog and see a message indicating the physical fiber link dropped. They run a Troubleshooting Workflow to verify if the backup VPN has successfully failed over.
- Escalation: They contact the ISP, providing exact timestamps and logs from the monitoring platform as evidence of the outage.
Alert Design Best Practices
Poorly designed monitoring leads directly to Alert Fatigue—a dangerous scenario where engineers receive so many useless alerts that they begin ignoring them, eventually missing a critical failure.
- Actionable Alerts: If an alert triggers, there must be a clear action an engineer can take to fix it. If the alert is "informational," it belongs in a dashboard, not an email.
- Dependency Awareness: If a core switch goes down, the 50 servers plugged into it will also become unreachable. A smart monitoring system suppresses the 50 server alerts and only sends one alert for the core switch.
- Maintenance Windows: Always pause alerting before performing scheduled reboots or upgrades to avoid waking up the on-call team unnecessarily.