Il s'agit d'un article de blog invité de Shawn Parrish de NodePing, l'un de nos partenaires de surveillance, sur la façon d'éviter certains des points d'achoppement les plus courants en matière de surveillance. NodePing fournit des services de surveillance de serveur externe simples et abordables. Pour en savoir plus sur NodePing, visitez leur site Web ( https://nodeping.com )

Je suis responsable des serveurs et de la surveillance des services depuis des années et j'ai probablement commis presque toutes les erreurs. Alors écoutez les histoires de guerre d'un gars avec des cicatrices et apprenez de mes erreurs. Voici 10 ponts bas sur lesquels je me suis cogné la tête. La plupart d'entre eux relèvent du bon sens. Faites attention à l'écart.

Voici 10 erreurs courantes que j’ai commises en matière de surveillance de serveur.

1. Je ne vérifie pas tous mes serveurs

Oui, cela semble évident, mais quand j'ai tant de fers au feu, il est difficile de se rappeler de configurer la surveillance du serveur pour chacun d'eux. Certains serveurs plus fréquemment oubliés sont :

• Serveurs DNS et MX secondaires. Cette équipe « B » de serveurs intervient généralement lorsque les serveurs principaux sont hors ligne pour maintenance ou sont en panne. Si je ne les surveille pas également, ils risquent de ne pas fonctionner au moment où j'en ai le plus besoin. Assurez-vous de garder un œil sur vos boîtiers de secours.

• Nouveaux serveurs. Ah, l'odeur des boîtes à pizza fraîches de Dell ! Après toutes les tâches amusantes (installation du système d'exploitation, configuration, rodage, renforcement, tests, etc.), les deux « incontournables » les plus oubliés sur un nouveau serveur sont l'étiquette d'inventaire de l'entreprise (est-ce que quelqu'un les utilise encore ?) et la configuration de la surveillance du serveur. Ajoutez-les à votre liste de contrôle.

• Serveurs cloud. Ces instances VPS et AWS rapides sont faciles à configurer et faciles à oublier de surveiller.

• Serveurs temporaires/permanents. Vous savez de quoi je parle. Le boîtier de développement « preuve de concept » qui a été assemblé à partir de matériel hors d'usage et qui a soudainement été surnommé « production ». Il a également besoin d'être surveillé.

2. Ne pas vérifier tous les services sur un hôte

Nous savons que la plupart des pannes font tomber toute la machine, mais si je ne surveille pas chaque service sur un hôte, je pourrais avoir un site Web en cours d'exécution alors que le FTP est à plat. Le plus courant que j'oublie est de vérifier à la fois HTTP et HTTPS. Bien sûr, c'est le même « service », mais la configuration Apache est distincte, les règles du pare-feu sont probablement distinctes. N'oubliez pas non plus les vérifications SSL, distinctes des vérifications HTTPS, pour vous assurer que vous disposez de certificats SSL valides. J'ai reçu des appels embarrassants concernant le site « en panne » pour découvrir que le certificat avait expiré. Oh, oui… J'étais censé le renouveler, n'est-ce pas ?

3. Ne pas vérifier assez souvent

Les utilisateurs et les patrons ont une tolérance très faible aux temps d'arrêt. J'ai appris une leçon en essayant d'utiliser un service de surveillance bon marché qui ne fournissait que des intervalles de vérification de 10 minutes. Cela représente jusqu'à 9,96 minutes de risque (un calcul assez précis, non ?) que mon serveur soit en panne avant que je sois alerté. Configurez des intervalles de vérification d'une minute sur tous les services. Même si je n'ai pas besoin d'y répondre immédiatement (une machine de développement qui tombe en panne au milieu de la nuit), je saurai « quand » il est tombé en panne dans les 60 secondes, ce qui pourrait être une information utile lorsque je fouillerai dans les journaux pour une analyse ultérieure des causes profondes.

4. Ne pas vérifier le contenu HTTP

La vérification HTTP standard est efficace, mais la page du serveur Apache « par défaut » et « en construction » m'a renvoyé ce joyeux code de réponse 200 et un « PASS » vert dans mon service de surveillance, tout comme mon vrai site. Choisissez quelque chose dans le pied de page de la page qui ne change pas et effectuez une vérification de correspondance du contenu HTTP sur celui-ci. N'utilisez cependant pas le nom de domaine, car il pourrait également apparaître dans la page « par défaut » et rendre cette vérification moins utile.

Il est également important de s'assurer que certains contenus n'apparaissent PAS sur une page. Nous avons tous visité un site CMS qui affichait cette belle erreur « Impossible de se connecter à la base de données ». Vous voulez savoir si cela se produit.

5. Ne pas définir le délai d'expiration correct

Les délais d'expiration d'un service sont très subjectifs et doivent être configurables sur votre service de surveillance. Les spécialistes du Web me disent que notre site Web public doit se charger en moins de 2 secondes, sinon nos visiteurs iront ailleurs. Si ma vérification du service HTTP prend 3,5 secondes, cela doit être considéré comme un résultat d'ÉCHEC et quelqu'un doit être averti. De même, si j'avais un délai « helo » de 4 secondes configuré dans mon sendmail, je souhaiterais déplacer ce délai d'expiration de plus de 5 secondes. Les délais d'expiration définis sur une valeur élevée laissent passer mes problèmes de performances inaperçus ; les délais d'expiration définis sur une valeur trop basse augmentent simplement le bruit de mes notifications. Il faut du temps pour les modifier au niveau de chaque service.

6. Oublier le DNS est réciproque

Bien sûr, j'ai des contrôles DNS pour m'assurer que mes noms d'hôtes correspondent à mes adresses IP, mais j'oublie trop souvent de vérifier également les entrées DNS inversées (rDNS). Il est particulièrement important pour les services SMTP d'avoir des enregistrements PTR correctement résolus, sinon mon courrier électronique sera dirigé vers le bac à spam. Je surveille toujours les enregistrements SPF et DKIM pendant que j'y suis. Votre service de surveillance peut le faire, n'est-ce pas ?

Même lorsque j'utilise un service DNS externe réputé, je configure des contrôles DNS pour surveiller chacun des enregistrements NS de mes domaines. Une mauvaise configuration de ma part ou de la leur provoquera toutes sortes de ravages.

7. Sensibilité trop faible/élevée

Certains serveurs ou services semblent plus susceptibles d'avoir de petits problèmes qui ne font pas tomber le serveur, mais qui peuvent par intermittence provoquer l'échec des vérifications en raison du trafic ou du routage ou peut-être de la phase de la lune. Rien n'est plus ennuyeux qu'un SMS « down » à 3 heures du matin pour un hôte qui n'est pas vraiment en panne. Certains appellent cela un faux positif ou un battement d'ailes - moi, je l'appelle une nuisance. Bien sûr, je ne devrais pas sursauter à chaque fois qu'un seul ping perd son chemin sur Internet et que chaque « helo » SMTP reste sans réponse, puis la réalité s'installe et une situation plus dangereuse peut se produire. Je peux être tenté de commencer à ignorer les notifications à cause de tout le bruit des alertes dont je ne me soucie pas vraiment.

Un bon service de surveillance gère bien cela en me permettant d'ajuster la sensibilité de chaque contrôle. Si vous définissez ce paramètre trop bas, mes notifications pour les événements de panne légitimes mettent trop de temps à m'atteindre, mais si vous le définissez trop haut, je suis submergé de notifications de faux positifs inutiles. Encore une fois, il s'agit d'un élément qui doit être configuré par service et qui prendra du temps à peaufiner.

8. Informer la mauvaise personne

Rien ne gâche des vacances comme une notification « hôte indisponible ». Bien sûr, j'ai des administrateurs système de secours qui devraient me remplacer, mais j'oublie de modifier les horaires de PagerDuty afin que les notifications leur soient envoyées et non à moi.

9. Ne pas choisir le bon type de notification

Le point n°8 est de savoir quel type de notification envoyer. Oui, j'ai fait l'erreur de le configurer pour envoyer des alertes par e-mail lorsque le serveur de messagerie est en panne. Les notifications critiques du serveur doivent presque toujours être envoyées par SMS, par la voix ou par push mobile persistant.

10. Ne pas ajouter l'adresse e-mail du système de notification à la liste blanche

Juste après le point n° 9 (nous avons beaucoup de talons par ici), je reconnais que si je ne mets pas sur liste blanche l'adresse e-mail du service de surveillance, elle risque de se retrouver dans le panier de spam.

Prime!

11. Payer trop cher

J'ai déjà payé des centaines de dollars par mois pour un service de surveillance médiocre pour quelques dizaines de serveurs. C'est tout simplement stupide. NodePing coûte 15 $ par mois pour 200 serveurs/services à des intervalles d'une minute et ce n'est pas le seul service de surveillance rentable du marché. Assurez-vous de faire le tour des différents services pour en trouver un qui réponde bien à vos besoins. Associez-le aux capacités d'astreinte/transfert de PagerDuty et vous êtes sur la bonne voie pour éviter les cicatrices que j'ai sans perdre votre chemise.

C'est tout ce qu'il faut dire, vrai croyant.