Status: Delivered
Network Supervision
Discover network devices, monitor them continuously and turn every failure into a tracked incident with measured response times.
- 7processing stages
- 3escalation levels
- 1 minmonitoring cycle
- 4scheduled jobs
Context
Final-year internship at Moov Africa. A network team needs to know at all times which devices respond, which are degrading, and who must act.
Problem
Without a central tool, failures are found late, incident follow-up is scattered and resolution times cannot be measured.
Objective
A web application that discovers devices, monitors them continuously, turns anomalies into traceable incidents and measures service quality (SLA, MTTR).
Architecture
A Flask application split into routes, services and models. A scheduler runs monitoring, SLA checks, backups and data retention in the background.
- DiscoveryNmap finds live hosts, a parallel ICMP ping (50 threads) confirms them, SNMP identifies the device type.
- ValidationA discovered device waits for human validation before being monitored.
- MonitoringEvery minute, in parallel: availability, latency, packet loss, CPU and RAM over SNMP.
- AlertsThresholds and consecutive failures raise an alert with a severity level.
- Incidents & ticketsEach ticket gets an SLA deadline based on the incident priority.
- EscalationSLA breached: automatic escalation up to level 3 and email notification.
- ReportsSLA and MTTR indicators, CSV and PDF exports.
Technologies
- Python
- Flask
- SQLAlchemy
- Flask-Login
- Flask-WTF
- python-nmap
- pysnmp
- icmplib
- MySQL
- APScheduler
- ReportLab
- Flask-Mail
Features
- Automatic discovery of the devices on a subnet
- Continuous monitoring: availability, latency, CPU, RAM, interfaces
- CPU/RAM history and per-device SNMP community
- Full incident lifecycle: alert, incident, ticket, resolution
- Per-priority SLA and automatic three-level escalation
- Scheduled maintenance that silences alerts
- SLA/MTTR reports exported to CSV and PDF
- User and role management
- Daily database backup and 30-day metrics retention
Screenshots
Internal internship interface: screenshots not published.
Technical decisions
Two-phase discovery
Nmap quickly finds live hosts. A parallel ping confirms each one and measures latency, then SNMP refines the device type, with a fallback rule when SNMP does not answer.
One SLA per priority
A critical incident does not share the deadline of a minor one. Each ticket gets its own due time, and escalation follows it instead of a fixed threshold.
Consecutive failures before alerting
Counting consecutive availability, CPU and RAM failures avoids opening an incident on a single lost packet.
Secure by default
The app refuses to start without a secret key outside debug mode. CSRF protection, HttpOnly session cookies and secrets in environment variables.
Challenges
A scheduler started twice
In debug mode, the Werkzeug reloader spawns two processes. The scheduler now starts only in the server process.
Duplicate logs
Logging centralised on the root logger, with file rotation (5 × 5 MB).
Metrics volume
Automatic purge after 30 days, indexes on filtered columns, daily backup.
Result
Working application, validated in a lab (mock-up) environment as part of the internship.
Possible evolution
- Real-time dashboard (WebSocket)
- SMS or WhatsApp alerts for on-call staff
- Anomaly detection on CPU/RAM history
- Containerised deployment
Code and demo
Private repository — internship project