Introduction to Network Monitoring: Know Before the Phone Rings

The backup internet link had been down for two weeks. Nobody knew, because the primary was still working. On the day the primary failed, everything went down at once, and IT found out from the general manager's phone call.

That's what happens without monitoring: IT learns about problems after the users do. Monitoring reverses the order. It tells you the backup link has died, the NVR disk is nearly full, the rack is getting hotter or the UPS is running on battery, before any of it becomes everyone's problem. And it keeps history, so you can plan when you'll need more bandwidth or more disk.

What to watch

The last row is the one people forget. An expired firewall subscription can quietly stop IPS and web-filter updates without anyone noticing.

What each tool is for

ICMP (ping) answers one question: is the device still there? It's the simplest check and a good place to start.

SNMP reads values from switches, firewalls, UPSs and printers: bandwidth, CPU, battery status. Use SNMPv3 with authentication and encryption. SNMP v1/v2c with the "public" community string is like leaving the door open for anyone to read your configuration.

Syslog has devices send their event logs to a central server. When something happens, you have a history to investigate, even after the device has rebooted and lost its local logs.

NetFlow / sFlow / IPFIX answers "who's eating the bandwidth?" When the internet is slow every afternoon, it tells you whether it's Windows Update, a cloud backup or someone streaming the football.

API / cloud dashboards. Cloud-managed equipment usually has built-in monitoring that works out of the box.

Choosing a tool

What we usually see work is a combination: the vendor dashboard for Wi-Fi detail, and Zabbix or something similar for everything else, including UPSs and temperature sensors.

Worked example: what monitoring 60 devices takes

A head office with two branches: two firewalls, 14 switches, 30 access points, 3 UPS units, 2 NVRs, 4 servers, 3 internet links and 2 temperature sensors, about 60 devices.

• Polling. Each device has perhaps 20–60 values worth collecting (ports, CPU, temperature, battery). At one poll per minute that's roughly 3,000 values a minute, or 50 a second. A small virtual machine with 2–4 vCPUs and 8 GB of RAM handles that comfortably.
• History. Keep detailed data for about 90 days and hourly trends for one to two years. That fits in well under 100 GB of disk at this size.
• Bandwidth. SNMP polling of 60 devices uses a few tens of kbps. Even across a branch VPN, it won't be noticed.
• Wi-Fi. Read the 30 APs from the vendor's controller or cloud dashboard rather than polling each one, and send only the important events into the central tool.

The hard part isn't the server. It's an afternoon of tidying device names, enabling SNMPv3 and deciding who gets which alert.

Alerting: fewer, but right

A system that sends 200 messages a day will be muted within a week. That's alert fatigue, and it's the number one reason monitoring projects fail.

• Alert only on things someone has to act on
• Use levels: warning (e.g. disk 80%) and critical (disk 95%, uplink down)
• Deliver alerts where the team actually looks: email, LINE, WhatsApp, Telegram
• Use dependencies: if a branch firewall is down, don't alert on the 40 devices behind it
• Decide who owns each alert and how many minutes they have to respond

Starting thresholds that work

Use these as a first draft and adjust after a month of real data:

Note the time windows. Alerting on a single bad sample is what creates noise; a condition that lasts five or fifteen minutes is usually real.

Getting started in six steps

1. Build an inventory of every device with IP and location
2. Enable SNMPv3 and syslog on devices, accessible only from the monitoring server
3. Deploy the monitoring server (a VM or small appliance) in the management VLAN
4. Add critical devices first: firewall, core switch, WAN links, UPS, NVR
5. Configure alerts and test that they actually arrive
6. Review trend reports every month

Step 4 matters. Don't try to add everything on day one. Five devices monitored well are worth more than 200 nobody looks at.

What makes monitoring fail

A tool nobody watches is the most common. Next is a monitoring server with no UPS: when the power goes, it dies with everything else and can't alert at exactly the moment you need it. And not monitoring UPSs and temperature, which in our experience are the leading causes of equipment failure in Laos.

Three more we find often. Checking only from inside: if the internet link dies, the monitoring server can't send its alert out, so add an outside check, a cloud ping service or a 4G modem for alerts. Alerts going to one person's phone, so nothing happens while that person is on leave. And no maintenance windows, so every planned reboot pages everyone and trains them to ignore alerts.

A dashboard for management

Executives don't need 50 graphs. These five numbers are enough:

A monthly report like this lets IT ask for budget with numbers instead of impressions. "The UPS ran on battery 23 times this month" carries far more weight than "the power here is bad".

For organizations in Laos

If you have an in-house IT team, start with Zabbix or a similar open-source tool. If the team is small or non-existent, a managed monitoring service is better value than trying to run it yourself.

Prioritize UPS, temperature and internet links. Those three are where we see the most problems in Laos. Monitor provincial branches centrally from Vientiane over VPN or SD-WAN. And write alert messages in a language the team understands at a glance, delivered through the apps they open every day.

One practical note on alert channels: LINE Notify, which many older setups used to push alerts into LINE groups, closed in 2025. If your alerts went that way, they have stopped. Move them to a LINE Messaging API bot, Telegram, WhatsApp or email, and send a test alert to confirm. Whatever tool you choose, run an LTS (long-term support) release in production rather than the short-support versions in between.

Start with five devices

Tell us which five devices would stop your business if they failed (usually the firewall, core switch, internet links, UPS and NVR or main server). We'll propose how to monitor and alert on just those five first, then build out from there.