Comment surveiller la disponibilité des serveurs : contrôles, outils et alertes

Pour surveiller la disponibilité d'un serveur, lancez des contrôles automatisés depuis l'extérieur du serveur (ping, port TCP ou requêtes HTTP depuis plusieurs emplacements), collectez les signaux de santé du serveur lui-même avec un agent, et ne déclenchez une alerte que lorsque plusieurs emplacements échouent à la suite. Enregistrez ensuite chaque interruption pour pouvoir calculer chaque mois la disponibilité par rapport à votre SLA.

Points clés

• Les contrôles synthétiques externes répondent à « les utilisateurs peuvent-ils y accéder ? » ; les agents internes répondent à « pourquoi est-ce en panne ? ». Il faut les deux.
• Contrôlez depuis au moins trois emplacements et alertez sur des échecs consécutifs pour éviter les fausses alertes dues à un seul chemin réseau défaillant. Microsoft recommande au moins cinq emplacements de test pour les tests de disponibilité Azure.
• Testez ce qu'utilisent les utilisateurs : une requête HTTPS qui vérifie le code d'état et le contenu de la page vaut mieux qu'un ping.
• Une disponibilité de 99,9 % autorise encore environ 43,8 minutes d'indisponibilité par mois. Sachez ce que votre objectif autorise avant de fixer les seuils d'alerte.
• Excluez systématiquement les fenêtres de maintenance convenues, et rendez compte de la disponibilité à partir des mêmes données chaque mois.

Qu'est-ce que la supervision de la disponibilité des serveurs ?

La supervision de la disponibilité des serveurs consiste à vérifier en continu qu'un serveur et les services qu'il héberge sont accessibles et répondent correctement. Elle produit deux choses : des alertes quand un élément tombe en panne, et un historique que vous pouvez convertir en pourcentage de disponibilité.

Le temps de fonctionnement (uptime) et la disponibilité sont liés mais pas identiques. Un serveur peut être allumé (uptime élevé) alors que son service web renvoie des erreurs (disponibilité faible). Pour la plupart des entreprises, le chiffre qui compte est la disponibilité du service, telle que la perçoivent les utilisateurs.

Combien d'indisponibilité chaque objectif de disponibilité autorise-t-il ?

La disponibilité est égale à (temps total − indisponibilité) ÷ temps total. Le tableau convertit les objectifs courants en indisponibilité autorisée, sur la base d'un mois moyen de 730 heures.

Un objectif exigeant change la façon de superviser. À 99,99 %, un intervalle de contrôle de cinq minutes ne peut même pas détecter tous les manquements ; il faut donc des contrôles toutes les minutes ou plus rapides et une réponse d'astreinte mesurée en minutes. Le chapitre du livre SRE de Google sur l'acceptation du risque explique pourquoi chaque « neuf » supplémentaire coûte plus cher et pourquoi l'objectif doit suivre le besoin métier.

Quels contrôles lancer ?

Contrôles externes (synthétiques)

• Ping ICMP : montre que l'hôte répond sur le réseau. Peu coûteux, mais de nombreux pare-feu le bloquent, et un hôte peut répondre au ping alors que ses applications sont en panne.
• Contrôles de port TCP : confirment qu'un service est à l'écoute, par exemple 443 pour HTTPS, 3389 pour RDP ou 5432 pour PostgreSQL.
• Contrôles HTTP(S) : appellent une URL et vérifient le code d'état, le temps de réponse et un élément de contenu attendu. Utilisez un point de terminaison de santé dédié qui teste aussi la connexion à la base de données.
• Contrôles de certificat TLS : préviennent avant l'expiration d'un certificat. Un certificat expiré est une panne pour les utilisateurs même si le serveur est sain.
• Contrôles DNS : confirment que le nom se résout vers la bonne adresse.

Signaux internes (par agent)

• Heartbeat : l'agent envoie un signal chaque minute ; l'absence de heartbeat signifie que l'hôte ou l'agent est en panne.
• Compteur d'uptime système : révèle les redémarrages non planifiés. Sous Linux, utilisez uptime ou last reboot ; sous Windows, l'ID d'événement 6008 du journal Système enregistre un arrêt inattendu.
• Métriques de ressources : CPU, mémoire, espace disque et latence disque. Les disques pleins et l'épuisement de la mémoire sont des causes fréquentes de « en ligne mais ne fonctionne pas ».
• État des services et des processus : le serveur web, la base de données ou la tâche planifiée sont-ils en cours d'exécution ?

Pour les hôtes Windows, notre guide sur la supervision des performances de Windows Server énumère les compteurs à collecter.

Quels outils peuvent superviser la disponibilité des serveurs ?

Le choix compte moins que la mise en place. Un outil auto-hébergé doit lui aussi être supervisé : si votre seul serveur de supervision se trouve dans la même baie que les serveurs qu'il surveille, une coupure de courant met les deux hors service. Exécutez au moins un contrôle externe depuis un autre réseau ou un service cloud.

Comment configurer des alertes de disponibilité sans fausses alertes

1. Utilisez plusieurs emplacements. Microsoft recommande au moins cinq emplacements de test pour les tests de disponibilité Azure et un seuil d'alerte égal au nombre d'emplacements moins deux, par exemple trois échecs sur cinq.
2. Exigez des échecs consécutifs. L'option de nouvelle tentative d'Azure ne signale un échec qu'après l'échec de trois tentatives successives ; Microsoft indique qu'environ 80 % des échecs disparaissent à la nouvelle tentative.
3. Définissez la gravité selon l'impact. Un portail client en production alerte l'ingénieur d'astreinte ; un serveur de test envoie un ticket.
4. Acheminez les alertes vers les personnes capables d'agir, avec une escalade si personne n'accuse réception dans un délai défini.
5. Mettez en sourdine la maintenance planifiée dans l'outil de supervision plutôt que d'ignorer les alertes par habitude.
6. Alertez aussi au rétablissement, pour que l'équipe sache quand l'incident est terminé.

Les recommandations SRE de Google sur la supervision des systèmes distribués ajoutent une règle utile : chaque page d'alerte doit être urgente, exploitable et nécessiter un humain. Tout le reste relève d'un ticket ou d'un tableau de bord.

Comment rendre compte de la disponibilité par rapport à un SLA

• Définissez ce qui compte comme une panne, par exemple « le point de terminaison de santé échoue depuis trois emplacements sur cinq pendant deux contrôles consécutifs ».
• Convenez des fenêtres de maintenance exclues et enregistrez-les dans l'outil.
• Calculez la disponibilité mensuelle à partir des résultats des contrôles, pas de mémoire ni de notes de tickets.
• Tenez un journal des interruptions avec début, fin, cause et correction. Les tendances, comme des pannes après chaque nuit de correctifs, montrent où investir.
• Comparez votre chiffre à l'engagement de votre fournisseur cloud. Par exemple, le SLA Amazon Compute s'engage sur 99,99 % de disponibilité mensuelle pour EC2 déployé sur plusieurs zones de disponibilité d'une région, mais seulement 99,5 % pour une seule instance EC2. La disponibilité de votre application ne peut jamais dépasser celle de sa dépendance la plus faible.

La supervision vous informe des pannes ; la redondance les évite. Exécutez les charges critiques sur plus d'un serveur ou d'une zone de disponibilité derrière un répartiteur de charge, pour qu'une défaillance isolée ne mette pas le service hors service. WorkBuster, une plateforme SaaS de recrutement, fonctionne sur EC2 derrière un Application Load Balancer avec MySQL RDS multi-AZ, un groupe de mise à l'échelle automatique et des tableaux de bord et alarmes CloudWatch ; l'étude de cas WorkBuster présente l'ensemble de l'architecture.

Comment Opsio vous aide

Opsio assure une supervision et une réponse aux incidents 24h/24 et 7j/7 pour les serveurs et les charges de travail cloud sur AWS, Azure et Google Cloud. Nous mettons en place les contrôles, l'acheminement des alertes et les rapports mensuels de disponibilité, et nos ingénieurs traitent les alertes. Voir nos pages supervision et support cloud, supervision d'infrastructure à distance et observabilité avec Prometheus et Grafana.

Questions fréquentes

Comment savoir depuis combien de temps un serveur fonctionne ?

Sous Linux, exécutez uptime ou last reboot. Sous Windows, ouvrez l'onglet Performance du Gestionnaire des tâches, exécutez systeminfo et lisez « Heure de démarrage du système », ou consultez le journal d'événements Système. Ces éléments indiquent le temps écoulé depuis le dernier démarrage, pas si les services étaient disponibles.

À quelle fréquence lancer les contrôles de disponibilité ?

Toutes les une à cinq minutes pour la plupart des services de production. Adaptez l'intervalle à votre objectif : à 99,99 %, vous n'avez qu'environ 4,4 minutes d'indisponibilité par mois, et un intervalle de cinq minutes est trop lent pour la mesurer.

Le ping suffit-il pour superviser la disponibilité d'un serveur ?

Non. Le ping prouve seulement que la pile réseau répond. Ajoutez un contrôle TCP ou HTTPS sur le service dont dépendent les utilisateurs, idéalement avec une vérification de contenu, ainsi que des contrôles par agent sur le serveur lui-même.

Quel pourcentage de disponibilité est satisfaisant pour un serveur ?

Pour les applications métier, 99,9 % est un objectif courant ; les services destinés aux clients visent souvent 99,95 % ou plus. Les objectifs plus élevés exigent de la redondance : AWS, par exemple, ne s'engage que sur 99,5 % pour une seule instance EC2 mais sur 99,99 % pour EC2 réparti sur plusieurs zones de disponibilité.

Peut-on superviser la disponibilité gratuitement ?

Oui. Des outils open source comme Prometheus avec blackbox_exporter, Zabbix ou Nagios n'ont aucun coût de licence, même si vous payez l'hébergement et le temps de maintenance. Les contrôles natifs des fournisseurs cloud sont peu coûteux pour un petit nombre de points de terminaison.

À lire aussi

• Qu'est-ce que la supervision cloud ?
• Qu'est-ce que la supervision en temps réel des serveurs et des applications ?
• Comment surveiller les performances de Windows Server ? Outils et métriques