How to Monitor an Office Network: SNMP, Zabbix and Alerts
Advanced5 minInnovialabs editorial team
In short
Collect the health of uplinks, switches, access points, UPS, NAS and printers via SNMP into a tool such as Zabbix, and send to Telegram only alerts that require action, with delays and dependencies to cut the noise.
The short answer
A monitoring server polls your devices, stores metrics and raises an alert when something breaks or is about to. Data comes via SNMP, Zabbix turns it into graphs and triggers, and a Telegram bot delivers alerts to people who can act.
The goal is not to collect everything, but to learn about a problem before users call you.
What to monitor
| Device | Key metrics |
|---|---|
| Internet uplinks | Packet loss and latency to external hosts, interface traffic, which link is active in failover |
| Router or firewall | Availability, CPU, memory, interface errors, uptime (a sudden reset means a reboot) |
| Switches | Port status on uplinks, errors and discards, PoE power budget |
| Access points | Online status, number of clients, channel utilization if the controller exposes it |
| UPS | On battery, battery charge, remaining runtime, battery replacement flag |
| NAS and file servers | RAID status, disk health (SMART), free space, temperature |
| Printers | Toner level, paper jams, error state |
| Video recorder | Availability, disk status, whether cameras are recording |
Start with uplinks, the core switch, UPS and NAS: their failures affect everyone.
SNMP basics
- The monitoring server (manager) polls the agent on the device over UDP port 161.
- Devices can also send traps to the manager on UDP port 162 when an event occurs.
- Each value has an OID, a numeric address. OIDs are described in MIBs: standard ones such as IF-MIB for interfaces, HOST-RESOURCES-MIB, UPS-MIB and Printer-MIB, plus vendor MIBs.
- On fast interfaces use 64-bit counters (ifHCInOctets and similar): 32-bit counters wrap around too quickly.
Versions matter for security. SNMPv1/v2c use a community string sent in clear text. SNMPv3 adds authentication and encryption. Use v3 where devices support it; otherwise use a read-only community that is not public and allow SNMP only from the monitoring server's IP.
Check that a device answers before adding it to the tool:
snmpget -v2c -c your-ro-community 192.168.10.2 1.3.6.1.2.1.1.3.0
snmpwalk -v3 -l authPriv -u monitor -a SHA -A 'auth-pass' -x AES -X 'priv-pass' 192.168.10.2 1.3.6.1.2.1.1
The first returns uptime; the second walks the system group over SNMPv3.
Choosing a tool
| Tool | Good for | Consider |
|---|---|---|
| Zabbix | Full monitoring with SNMP templates, triggers, dependencies, proxies for branches | Takes time to set up and tune |
| LibreNMS | Network-focused, automatic discovery of SNMP devices | Less flexible for non-network checks |
| Prometheus + snmp_exporter + Grafana | Teams already using Prometheus | More assembly required |
| PRTG | Ready-made sensors, Windows-based | Commercial, licensed by number of sensors |
| Uptime Kuma | Simple availability checks with notifications | Mainly up/down, not deep device metrics |
For a few dozen devices Zabbix is a solid default: free, well documented, with templates for network gear, UPS and printers.
Zabbix in practice
- Install the Zabbix server with a database on a small Linux VM or in containers.
- Add hosts with an SNMP interface and link a matching template (generic SNMP device, vendor-specific, UPS, printer).
- Store community or SNMPv3 credentials in macros, not in each item.
- Let low-level discovery find interfaces and disks automatically.
- Review triggers and thresholds that came with templates.
- For a branch office, install a Zabbix proxy there so it polls locally.
Telegram alerts
- Create a bot with @BotFather and save the token securely.
- Add the bot to a group for the IT team and get the group chat ID.
- In Zabbix, enable the Telegram media type and enter the token.
- Add the chat ID as media to the users who should receive alerts.
- Create an action: send only problems of a chosen severity and higher, and include recovery messages.
A good message contains the host, the problem, the time it started and the current value.
Avoiding alert fatigue
If Telegram buzzes all day, people mute the chat and miss the real outage.
- Alert only on actionable problems. Everything else goes to dashboards.
- Use severity. High and Disaster go to Telegram; warnings go to a separate chat or a daily summary.
- Add delays. Trigger after several failed checks or on an average over a few minutes, not on a single spike.
- Use dependencies. If the core switch is down, suppress alerts for every access point behind it.
- Plan maintenance windows for planned work.
- Review monthly: tune or delete triggers that fire without consequences.
Common mistakes
- Leaving the community string as
publicwith write access. - Monitoring only from inside the office: when the internet goes down, alerts cannot leave. Add an external check or a backup channel.
- Nobody monitors the monitoring server itself.
- Forgetting the UPS until a power cut.