Statut : Livré
Network Supervision
Découvrir les équipements réseau, les surveiller en continu et transformer chaque panne en incident suivi, avec des délais mesurés.
- 7étapes de traitement
- 3niveaux d’escalade
- 1 mincycle de supervision
- 4tâches planifiées
Contexte
Stage de fin de Licence chez Moov Africa. Une équipe réseau doit savoir en permanence quels équipements répondent, lesquels se dégradent, et qui doit intervenir.
Problème
Sans outil centralisé, une panne est découverte tard, le suivi des incidents est dispersé et les délais de résolution ne peuvent pas être mesurés.
Objectif
Une application web qui découvre les équipements, les surveille en continu, transforme les anomalies en incidents traçables et mesure la qualité de service (SLA, MTTR).
Architecture
Une application Flask organisée en routes, services et modèles. Un planificateur exécute la supervision, le contrôle des SLA, la sauvegarde et la purge en arrière-plan.
- DécouverteNmap repère les hôtes actifs, un ping ICMP parallèle (50 threads) les confirme, SNMP identifie le type d’équipement.
- ValidationUn équipement découvert attend une validation humaine avant d’être surveillé.
- SupervisionChaque minute, en parallèle : disponibilité, latence, perte de paquets, CPU et RAM via SNMP.
- AlertesSeuils et échecs consécutifs produisent une alerte avec un niveau de sévérité.
- Incidents & ticketsChaque ticket reçoit une échéance SLA selon la priorité de l’incident.
- EscaladeSLA dépassé : escalade automatique jusqu’au niveau 3 et notification par e-mail.
- RapportsIndicateurs SLA et MTTR, exports CSV et PDF.
Technologies
- Python
- Flask
- SQLAlchemy
- Flask-Login
- Flask-WTF
- python-nmap
- pysnmp
- icmplib
- MySQL
- APScheduler
- ReportLab
- Flask-Mail
Fonctionnalités
- Découverte automatique des équipements d’un sous-réseau
- Supervision continue : disponibilité, latence, CPU, RAM, interfaces
- Historique CPU/RAM et communauté SNMP propre à chaque équipement
- Cycle d’incident complet : alerte, incident, ticket, résolution
- SLA par priorité et escalade automatique sur trois niveaux
- Maintenances planifiées qui suspendent les alertes
- Rapports SLA/MTTR exportables en CSV et PDF
- Gestion des utilisateurs et des rôles
- Sauvegarde quotidienne de la base et purge des métriques à 30 jours
Captures
Interface interne au stage : captures non publiées.
Décisions techniques
Une découverte en deux phases
Nmap repère vite les hôtes actifs. Le ping parallèle confirme chacun et mesure sa latence, puis SNMP précise le type d’équipement, avec une règle de repli quand SNMP ne répond pas.
Un SLA par priorité
Un incident critique n’a pas le même délai qu’un incident mineur. Chaque ticket reçoit son échéance, et l’escalade suit ces délais plutôt qu’un seuil fixe.
Des échecs consécutifs avant l’alerte
Compter les échecs successifs de disponibilité, de CPU et de RAM évite d’ouvrir un incident sur une perte de paquet isolée.
Sécurisé par défaut
L’application refuse de démarrer sans clé secrète hors mode debug. Protection CSRF, cookies de session HttpOnly et secrets en variables d’environnement.
Difficultés
Un planificateur lancé deux fois
En mode debug, le rechargeur de Werkzeug crée deux processus. Le planificateur ne démarre désormais que dans le processus serveur.
Des journaux en double
Journalisation centralisée sur le logger racine, avec rotation des fichiers (5 × 5 Mo).
Le volume des métriques
Purge automatique au-delà de 30 jours, index ajoutés sur les colonnes filtrées, sauvegarde quotidienne.
Résultat
Application fonctionnelle, validée en environnement de laboratoire (maquette) dans le cadre du stage.
Évolution possible
- Tableau de bord en temps réel (WebSocket)
- Alertes SMS ou WhatsApp pour les astreintes
- Détection d’anomalies sur l’historique CPU/RAM
- Déploiement conteneurisé
Code et démo
Dépôt privé — projet de stage