Superviser pour détecter les pannes, c'est bien. Superviser pour prévenir les pannes, c'est mieux !

En effet, la supervision se limite trop souvent aux quelques métriques fournies par défaut par les systèmes type Nagios. Mais au delà des métriques habituelles (Pings, taux d'utilisation du disque et de la RAM, charge CPU, etc.), il y a des sondes qui sont très rarement utilisées et qui peuvent pourtant se révéler cruciales pour être anticiper les pannes et ne pas simplement se retrouver devant le fait accompli : « Ça ne marche plus ! ». Voici quelques sondes que nous utilisons.

On distingue globalement deux types de sondes :

  • celles qui avertissent que quelque chose ne fonctionne plus. Il y en a une par protocole réseau : check_ping, check_tcp, check_http, check_smtp, etc.
  • celles qui avertissent que quelque chose est entrain de mal tourner. Elles contrôlent les métriques principales du système, taux d'utilisation des disques, de la RAM et de la SWAP, charge CPU, utilisation du réseau, etc.

Les premières sont indispensables si vous voulez éviter l'appel d'un client qui aura remarqué que son service est tombé pendant que vous faisiez la sieste. Il en faut précisément une par service. Il n'y a généralement aucune configuration, c'est très binaire, « ça marche » ou « ça ne marche pas ». Une fois qu'elles sont en place, on peut s'intéresser au second type de sonde.

Celles-ci sont beaucoup plus intéressantes. Déjà parce que ce sont elles qui vont éviter au service de tomber en panne, mais aussi parce qu'elle vous aiderons à diagnostiquer immédiatement la source des pannes. En fait, ce sont ces sondes qui représentent tout le travail des administrateurs systèmes en matière de supervision. Il faut savoir les sélectionner pour surveiller un maximum de métriques, et configurer leurs seuils pour être alerté lorsque quelque chose commence à mal tourner. Tout le défit consiste alors à limiter les faux positifs tout en restant sûr d'être alerté en cas de problème.

Sur ces sondes, il y a aussi des « best seller » : check_mem, check_swap, check_load, etc. Passé ces sondes systématiquement livrées avec l'outil de monitoring, voici quelques autres sondes que nous utilisons et vous recommandons.

Taux de forks

En usage normal voire intensif, vous ne devriez avoir qu'entre 1 et 10 forks par secondes. Que se passe-t-il si vous montez à 100/s ? Pas grand chose à moins que ce soit régulier. Que se passe-t-il si vous montez à 1000/s ? Là, il y a probablement quelque chose entrain de faire une fork bomb latente, et à court ou moyen terme ça risque de planter complètement votre serveur. Pour réagir à temps et éviter des ralentissements, il est impératif de superviser ce taux de fork.

N'hésitez pas à élever le seuil sur certains serveurs. Le serveur de supervision, par exemple, passe son temps à exécuter des scripts shell, c'est à dire faire des forks par paquets de 50. Vous aurez forcément une moyenne bien supérieure à l'habitude, mais c'est normal. Le principal, c'est d'être alerté quand un serveur sort des clous.

Taux d'entrées/sorties de la Swap

Il est d'usage de vérifier si l'usage de la Swap ne dépasse pas des seuils donnés, typiquement 50 et 80%. Mais vous avez déjà essayé d'intervenir sur un serveur après avoir reçu une alerte critique sur la consommation de Swap et de RAM ? Indice : si la RAM et la Swap sont pleines, le serveur va terriblement ramer, et vous aurez beaucoup de mal à intervenir. Solution : redémarrer le serveur comme une brute, parce que vous ne pouvez pas faire attendre les utilisateurs. Conséquence : vous perdez toute chance de comprendre ce qu'il s'est passé, et ça se reproduira forcément.

Par ailleurs, ça n'est pas la quantité d'utilisation de la Swap qui impactera vos performances, mais plutôt le taux d'entrées/sorties entre la RAM et la Swap.

Seulement 1 page par seconde, ça devrait déjà lever une alerte. Ça n'a l'air de rien, mais avec un check toutes les 5 minutes, si la sonde retourne une moyenne de 1 i/o par seconde, c'est que votre serveur utilise vraiment trop la Swap et que ça a probablement des conséquence sur un service.

Statistiques des disques

Au même titre que le taux d'I/O en Swap, il est nécessaire de superviser le taux d'entrées sorties sur vos disques. C'est capital sur les serveurs de bases de données mais aussi sur les serveurs web où c'est souvent LA plus grosse source de ralentissement, bien avant le CPU et la RAM. Vous ne me croyez pas ? Essayez d'héberger quelques Prestashop qui subissent une charge moyenne sur le même serveur et sans optimiser quoique ce soit, vous verrez.

De manière générale, c'est le genre de problème dont on peut passer des heures à trouver la source si on a pas tout de suite les bonnes données sous les yeux.

S.M.A.R.T.

Au niveau matériel, vous n'êtes pas sans savoir que les disques durs tombent en panne, et que ça peut causer des dégâts. Même si vous avez des sauvegardes, vous allez devoir faire intervenir un technicien pour changer le disque, souvent machine éteinte, et donc couper le serveur et le service dans l'urgence. Pourtant, les pannes de disque peuvent être détectées bien à l'avance à l'aide de smartmontools. Ça peut permettre de diagnostiquer des ralentissement, mais aussi et surtout de programmer le remplacement en toute sérénité.

Décalage de l'horloge NTP

Avec le temps, l'horloge d'un ordinateur dérive. Ceci peut avoir de nombreuses conséquences sur un serveur, car de nombreux services et systèmes ont besoin que l'heure soit synchronisée au sein de l'infrastructure. Sur un répertoire partagé entre plusieurs machines, par exemple, les dates de création et modification ne devront pas se retrouver dans le futur chez certains serveurs alors qu'elles sont bien dans le passé pour d'autres. Les systèmes de cache ou encore de certificats se basent eux aussi sur les dates.

Pour s'assurer que l'horloge reste précise, vous utilisez probablement le protocole NTP implémenté par divers clients (ntp, ntpdate, openntpd, etc.). Mais le décalage entre l'heure de votre serveur et l'heure atomique est-il surveillé ? Si ça n'est pas le cas, il y a fort à parier que l'un de vos serveurs n'est pas correctement synchronisé, que ce soit parce que le daemon ntpd n'est pas installé ou parce qu'il n'est pas exécuté.

Il est donc indispensable de superviser le décalage entre l'heure de vos serveurs et l'heure d'un serveur NTP.

Connexion IPv6 & IPv4

check_ping c'est super, mais si votre serveur a une IPv4 et une IPv6, vous vérifiez quoi en fait ? La connexion IPv4 ou IPv6 ? Ne cherchez pas, vous supervisez l'IPv4, il faut passer une option à la commande pour superviser l'IPv6. Conséquence, votre serveur a peut être une connexion IPv6 complètement foirée, vous ne vous en rendrez pas compte, et un jour vous vous arracherez les cheveux à comprendre pourquoi certains utilisateurs attendent leurs pages web pendant plus de 30 secondes.

Si vos serveurs utilisent les deux version d'IP, pensez toujours à configurer deux sondes check_ping pour superviser l'IPv4 et l'IPv6.

Vers l'extérieur ?

Par ailleurs, on a vite fait de décider de configurer sa supervision pour faire passer ses sondes par un VPN. Mais, si on supervise que le serveur est bien accessible via le VPN, sommes-nous toujours sûr qu'il a bien accès à internet ?

Chez Sysnove, nous utilisons donc 4 sondes :

  • 2 pour vérifier que le serveur de supervision arriver bien à joindre le serveur supervisé, en IPv4 et en IPv6,
  • 2 pour vérifier que le serveur supervisé arrive bien à joindre internet (check_ping google.fr exécuté par NRPE ou SSH), en IPv4 et en IPv6.

Redémarrage de serveur

Les redémarrages inattendus, ça arrive, surtout lorsque vous administrez des dizaines ou des centaines de serveurs virtualisés. Mais savez-vous quand ça vous arrive ?

Pour être averti en cas de redémarrage, nous utilisons un simple script init qui nous envoie un mail au démarrage du serveur. Ce script, comme toute notre configuration, est déployé par Ansible.

Autres

N'hésitez pas aussi à superviser la date d'expiration des certificats SSL et de vos noms de domaine. Perdre un nom de domaine, c'est le genre de bétise qui peut coûter très cher, qui arrive plus souvent qu'on ne le pense, et même (surtout) à de grands groupes, alors que c'est vraiment le quelque chose qui peut être supervisé très simplement.

Tout ces scripts, et d'autres, peuvent être trouvés sur notre dépôt git.

À propos de l'auteur



Guillaume est l'un des deux fondateurs et cogérants de Sysnove. Développeur Python et administrateur système passionné de logiciel libre et des technologies liées à Internet, il participe à divers projets, notamment le fournisseur d'accès Internet Aquilenet ainsi que la Fédération FDN.

Chez Sysnove, son rôle consiste à mettre en place et administrer les infrastructures nécessaires à l'hébergement des services fournis aux clients. En tant que directeur général, il gère aussi les aspects administratifs de l'entreprise.