Building a Multi-Channel Network Monitoring Chatbot with Nagios, Viber & SMS
Building a Multi-Channel Network Monitoring Chatbot with Nagios, Viber & SMS
In modern ISP operations, the speed at which network incidents are detected and communicated directly impacts service reliability. Traditional monitoring dashboards require engineers to be constantly watching screens — an approach that doesn't scale. During my tenure as a Supervisor at Dish Media Network, I designed and implemented a multi-channel alert integration that bridged Nagios Core monitoring with instant messaging platforms including Viber, SMS, and Telegram.
The Problem: Alert Fatigue and Delayed Response
Before the integration, our incident workflow looked like this:
1. Nagios detects a threshold breach (link down, high CPU, packet loss)
2. An email notification is sent to the NOC team
3. Engineers manually check email, assess severity, and begin troubleshooting
This pipeline had critical bottlenecks:
- Email latency: Notifications were often buried under other messages, with average response times exceeding 15 minutes.
- No mobile-first alerting: Field technicians didn't have access to dashboards while on-site.
- No severity-based routing: Critical and warning alerts were treated identically.
Architecture Overview
The solution involved three key layers:
1. Nagios Event Handler
Nagios was configured with custom event handlers that trigger Python scripts upon state changes. Each event handler captures the host/service name, current state, output text, and timestamp.
2. Python Middleware API
A lightweight Flask-based API receives the Nagios event payload and performs:
- Severity classification: Maps Nagios states (CRITICAL, WARNING, UNKNOWN, OK) to priority tiers.
- Channel routing: CRITICAL alerts go to Viber group + SMS to on-call engineer. WARNING alerts go to Viber only. OK (recovery) alerts go to Viber as resolution confirmations.
- Rate limiting: Prevents notification flooding during cascading failures by implementing a cooldown window per host.
3. Multi-Channel Dispatch
- Viber Bot: Using the Viber REST API, messages are formatted with rich cards showing severity colour coding, affected device, and a direct link to the Nagios status page.
- SMS Gateway: Integration with a local telecom SMS API for critical-only alerts when internet connectivity to Viber may itself be impacted.
- Telegram Bot: Secondary channel for the engineering team's Telegram group, using Markdown-formatted messages.
Results and Impact
After deploying the integration across our monitoring infrastructure:
- Incident response time decreased by 30% — from an average of 15 minutes to under 10 minutes for critical alerts.
- Field technicians received real-time alerts on their mobile devices without needing VPN access to internal dashboards.
- Alert fatigue was reduced through intelligent severity routing — engineers only received SMS for truly critical events.
- Recovery notifications provided automatic closure confirmation, reducing manual status update overhead.
Lessons Learned
- Always implement rate limiting: During a fibre cut affecting multiple nodes, the system initially generated hundreds of alerts per minute. The cooldown mechanism was essential.
- Test failover scenarios: If the Viber API is unreachable (the network itself is down), the SMS fallback becomes the primary channel — this path must be tested regularly.
- Keep messages actionable: Each alert includes the device name, location, and a suggested first-response action rather than just raw Nagios output.
Conclusion
Integrating network monitoring with multi-channel messaging transforms reactive NOC operations into a proactive, mobile-first incident response workflow. The combination of severity-based routing and channel fallback ensures that the right engineer gets the right information at the right time.