In most organisations without monitoring, the way a network incident is detected is a user’s phone call. By then the problem already has an impact, there’s no data on what happened before and diagnosis starts from scratch. A monitored network changes the order of events: degradation is caught before it becomes an outage, the cause is located with data and, often, it’s fixed before anyone notices.
This guide shows what monitoring adds through typical scenarios that recur in business networks, what to monitor at a minimum, and the difference between having a monitoring tool and having a NOC that acts on what the tool detects.
Contents
- Six common scenarios, with and without monitoring.
- What to monitor at a minimum.
- Designing useful alerts.
- From tool to NOC.
1. Six common scenarios
The following scenarios are typical situations we often find in office networks. They don’t describe a specific client, but any IT manager will recognise one of them.
The backup link that didn’t work
The office has a main fibre line and a 4G or 5G backup set to kick in automatically. For months nobody checks it. The day the fibre goes down, the backup doesn’t come up: the SIM has expired, the data plan has run out or the backup router lost its configuration after a power cut. The office loses service exactly when it was counting on not doing so.
With monitoring: the backup link is watched continuously even when it isn’t in use, with periodic checks of its availability and latency. Any fault raises an alert the moment it happens, not the day the backup is needed.
The micro-outages nobody could prove
Users complain about brief drops on video calls and the VPN disconnects several times a day. The carrier checks the line and says it’s working fine. Without data, the conversation goes nowhere and the incident drags on for weeks.
With monitoring: latency and packet loss are measured continuously towards the carrier’s gateway and external destinations. The graphs show the exact time, the duration and on which segment the loss happens. With that evidence, the ticket with the carrier is opened with hard data and followed through to resolution.
The uplink that degraded little by little
A link between a floor switch and the core starts piling up interface errors because of a damaged patch cord or a failing transceiver. For weeks it only shows up as occasional slowness that’s hard to pin down. One day the link goes down and the whole floor is cut off.
With monitoring: the error counters (CRC, discards) on each interface are collected over SNMP and their growth raises an alert. The part is replaced in a planned intervention, before it fails.
The comms room at the weekend
The comms room air conditioning breaks down on a Friday afternoon. The temperature climbs all weekend; equipment starts restarting or shuts down on thermal protection. On Monday the office doesn’t start up and some equipment won’t turn back on.
With monitoring: the temperature reported by switches, firewall and servers is watched with warning thresholds. The alert arrives as soon as the temperature starts climbing, with time to act before there’s any damage.
The access point that kept restarting
In one part of the office the Wi-Fi drops for a few minutes now and then. After several complaints the access point is checked and seems fine. The real cause is that the switch is at the limit of its PoE budget and, when other devices draw more power, the access point runs short and restarts.
With monitoring: PoE draw against the switch’s budget and each access point’s uptime are logged. The restarts line up with the power peaks and the cause is found without having to reproduce the problem.
The line that had “run out of capacity”
The general feeling is that the internet is slow and the proposal is to buy more bandwidth. Nobody really knows how much the line is used or when.
With monitoring: the traffic history shows whether the line saturates and when. Often the saturation lines up with backups or syncs scheduled during working hours, and it’s fixed by rescheduling them or applying QoS. When more capacity really is needed, the history lets you size it with data.
2. What to monitor at a minimum
- Availability of network devices, firewall, access points, servers and sites.
- WAN links, main and backup, and VPN tunnels to sites and cloud: status, latency and packet loss.
- Traffic per interface, with history to see trends.
- Interface status, negotiated speed and error counters.
- CPU, memory and temperature of the equipment.
- PoE draw against each switch’s budget.
- Logs from devices centralised over syslog, with time synced via NTP.
- Where relevant, servers, storage and backups: a backup that fails silently is one of the most common risks.
Data is collected over SNMP, ICMP, syslog and each platform’s APIs, depending on what each vendor supports. A platform such as LibreNMS brings devices from different vendors into a single console, with history and alerts.
3. Designing useful alerts
Badly configured monitoring raises so many alerts that they end up ignored. That’s alert fatigue, and it cancels out the tool’s value. Alerts must be designed for the specific network:
- Thresholds tuned to each device’s and link’s normal behaviour, not generic values.
- Dependencies: if a site’s link goes down, one alert for the link instead of one for every device at that site.
- Persistence: alert when a condition lasts for a while, not on every one-off spike.
- Maintenance windows so planned changes don’t trigger false alarms.
- Severity and recipient: every alert should state its severity and reach someone who can act.
4. From tool to NOC
A monitoring tool detects; it doesn’t fix. If alerts land in the inbox of someone with other responsibilities, who’s on holiday or who doesn’t know the network well, early detection is lost. That’s the difference between having monitoring and having a NOC (Network Operations Center): a technical team that receives the alerts, analyses them and acts on the infrastructure.
A NOC handles an incident in a defined sequence:
- Detection, automatically by the platform.
- Analysis: the affected element is identified and the impact assessed.
- Diagnosis using the history and the logs from the time.
- Action remotely on the infrastructure or, if needed, a site visit by an engineer who already knows the network.
- Follow-up with the carrier, vendor or third-party supplier when the fix depends on them.
- Verification and closure, with the incident documented.
Applied to the scenarios above, the difference is tangible: the failed backup is fixed before it’s needed, the NOC opens and follows the carrier ticket with the graphs, the patch cord is replaced in a planned visit and Saturday’s temperature alert is handled by someone who knows what to do. The NOC also builds up knowledge of the network: every incident improves the documentation and the alert configuration.
Monitoring is measuring; operating is acting
The value of monitoring isn’t in the dashboard, but in what happens when an alert fires. Without an engineer responsible for acting, the best tool only documents precisely how the outage happened.
When specialist help is needed
From our own NOC we monitor our clients’ networks on LibreNMS: devices, WAN links, VPN tunnels, Wi-Fi and, if asked, servers, storage and backup. We configure alerts for each network, act remotely and follow up with carriers and vendors until it’s resolved. We explain it in our monitoring and NOC service.
If your network depends on a single link or on equipment without redundancy, monitoring is also the starting point for improving the network architecture. And for an overall view of your infrastructure, you can use our network self-assessment.