Un serveur qui tombe la nuit et personne pour le savoir avant le lendemain matin. La supervision sert à inverser ça : c’est la machine qui prévient, pas le client.
Ce qui est surveillé
- Disponibilité des services : web, messagerie, bases de données, DNS.
- Espace disque, charge, mémoire, processus.
- Certificats TLS et expiration des noms de domaine.
- État des sauvegardes — voir Sauvegardes.
- Réplication de bases de données, et décrochage de réplication.
- File d’attente et réputation de la messagerie.
Avec quoi
- Zabbix — supervision et alertes, avec découverte automatique des éléments à suivre.
- AWStats — fréquentation.
- Mailgraph et Bindgraph — courbes de la messagerie et du DNS.
- ZaZabbixSupervision et alertes : disponibilité, disque, certificats, réplication.
- AWAWStatsAnalyse des journaux du serveur — il voit les 404, les robots et les téléchargements, que la mesure par script ignore.
- MaMailgraphCourbes du trafic de messagerie.
- BiBindgraphCourbes des requêtes DNS.
- CrCrowdSecDétection et blocage des tentatives d'intrusion, à partir des journaux.
L’alerte qui prouve qu’elle fonctionne
Une alerte qui ne se déclenche qu’en cas de problème ne dit rien quand tout va bien : le silence du système en panne ressemble exactement au silence du système en bonne santé. C’est le raisonnement que j’applique aux sauvegardes, et il vaut pour le reste — j’y reviens dans Gestion des sauvegardes.
Un parc à surveiller, ou une supervision en place dont plus personne ne lit les alertes ? Écrivez-moi.