Ping est-il un moyen fiable de vérifier si un serveur est disponible?
Dans mon application, j'effectue un ping sur un serveur et j'attends une réponse. J'utilise ceci pour déterminer si le serveur est disponible et réactif ou non.
Est-ce un moyen fiable de déterminer la disponibilité? Je suppose qu'un pare-feu pourrait filtrer le trafic ICMP ... Y a-t-il d'autres inconvénients? Existe-t-il une méthode plus fiable?
La meilleure façon de savoir si un service distant donné est en vie est de lui demander de répondre à une demande de la manière dont il est censé - en fait, c'est la seule façon de vraiment savoir que quelque chose fonctionne correctement.
Par exemple, je reçois toujours mes équilibreurs de charge pour obtenir une réponse réelle de la tête de nos serveurs Web, vous pouvez faire la même chose pour une petite sélection sur une boîte de base de données si vous le souhaitez, ou tout ce que votre serveur réel sert. Comme conseil, vous pouvez créer un 'online.txt' (ou le nom que vous voulez lui donner) sur vos serveurs Web, faire essayer à vos LB d'obtenir ce fichier et s'il échoue, il supprime le serveur du VIP, c'est une belle façon de retirer manuellement des serveurs individuels de vos VIP simplement en renommant un seul fichier.
Ping teste uniquement la capacité de répondre aux pings, c'est donc le système d'exploitation de base, des parties de la pile IP et les liens physiques - mais c'est tout, tout le reste pourrait être en panne et vous ne le sauriez pas.
Je sais que cela est mentionné ci-dessous, mais cela mérite d'être répété encore et encore.
Les requêtes d'écho ICMP (aka "Pings") (aka ICMP Type 8) sont construites sur la spécification de pile IP, oui, mais ne doivent pas être implémentées ou utilisées. En fait, il existe un grand nombre de fournisseurs Internet qui refusent de les transmettre et abandonnent silencieusement ces demandes, car il s'agit d'une forme d'attaque réseau (appelée pingflood).
Comme mentionné ci-dessus, cela est géré par le système d'exploitation (en particulier au niveau de la pile réseau) et il appartient donc à la configuration du système d'exploitation de répondre à ceux-ci ou non. Si cette option est désactivée (par mesure de sécurité?), Vous ne pouvez rien faire pour recevoir des réponses ping de l'autre côté. C'est pourquoi ce n'est pas fiable.
Mais la plupart du temps, oui:
certains serveurs bloquent les requêtes ping
juste parce que le serveur répond ne signifie pas automatiquement le site Web (ou le service que vous prévoyez d'utiliser) fonctionne, vous devez également vérifier si la réponse correspond au contenu attendu .
Il est vrai qu'à plusieurs reprises, le trafic ICMP est filtré, ce qui peut ne pas être fiable ...
Un meilleur moyen pourrait être de connecter telnet le serveur au port de service qui vous intéresse.
c'est-à-dire telnet 127.0.0.1 8080
Si le serveur est uniquement requis pour répondre aux pings, c'est une bonne méthode pour déterminer sa disponibilité. S'il est nécessaire de fournir par exemple un service Web, vous devez effectuer une sorte de test pour voir si cela fonctionne de la même manière pour les services de fichiers, etc.
Il existe des outils spéciaux pour tester et surveiller comme Nagios / Icinga .
Avec ces outils, vous pouvez (bien sûr) effectuer des vérifications avec divers tests ping, mais également des vérifications sur vos services.
Tous les contrôles peuvent utiliser la valeur renvoyée pour classer le résultat comme "bon", "avertissement" et "critique" et peuvent être écrits dans presque tous les langages de programmation.
Bien sûr, pas facile à configurer (comme pointer et cliquer), mais personnalisable, fiable et extensible. Fonctionne bien sur diverses distributions Linux et Unix.
ping a 2 inconvénients:
- ping envoie icmp, qui peut être filtré par le pare-feu
- le port tcp ou udp utilisé par votre application peut être occupé ou non ouvert - le ping ne vérifie pas que
ne meilleure solution est de vérifier directement votre port udp/tcp, pour voir si le service est toujours disponible ...: -)
Testez les services que vous recherchez, un simple ping sur un serveur ne signifie pas que les services fonctionnent.
Par exemple:
Imaginez un serveur Web avec une douzaine de sites Web, alors j'ai besoin de savoir si les sites Web sont UP, je me suis fait un petit script en php et je l'exécute toutes les 10 minutes.
Le script fait le suivi ->
<?php
$website1 = "http://www.mywebsite.com/";
$myWebsite = file_get_contents($website1);
$message = 'My website' . $website1 . ' is DOWN at the moment.';
if (empty($myWebsite)) mail('[email protected]', 'Website is DOWN', $message);
?>
L'utilisation de ping pour déterminer si un serveur est disponible est comme un médecin urgentiste qui vérifie si un patient respire. Oui, c'est un bon point de départ, mais il peut y avoir d'autres problèmes.
Nous utilisons ping pour faire un pré-contrôle, que l'hôte est sous tension et accessible, avant de lancer notre service systemd qui tente une connexion ssh avec lui. Cela fait gagner du temps au débogage, car la commande systemctl start Échouera immédiatement, au lieu d'échouer en silence et de se perdre dans la jungle journalctl.
Notez que ping n'est pas "fiable" au même sens que TCP. Si vous avez une mauvaise connexion (ou une pile réseau merdique, merci Intel mpss) et que les paquets sont supprimés, un ping de paquet unique peut échouer. D'un autre côté, une connexion TCP est fiable contre les paquets perdus. Donc, ironiquement, une connexion ssh pourrait fonctionner immédiatement après un seul ping échec . Donc, si vous utilisez ping pour faire un contrôle de cohérence, assurez-vous d'autoriser un échec.
Juste mes deux cents: nous avons une application héritée qui utilise cette méthode, et nous avons dû la réparer car le ping était pas suffisant pour déterminer la disponibilité du service.
Ping montre simplement que le serveur est capable d'écouter, mais dans notre cas, le service n'a pas pu démarrer sans intervention humaine.
En conséquence, les unités, qui supposaient naïvement que le serveur était disponible, tentaient de se connecter et de temporiser. Au lieu d'afficher notre message "Le serveur n'est pas disponible".
-
Notre application actuelle, qui communique via XMLHTTPRequests à un serveur Web, envoie un message formé auquel le serveur répondra avec un code d'état. Le code d'état est calculé par le serveur en effectuant un certain nombre de vérifications pour s'assurer que les différents sous-systèmes sont en ligne (DB, les répertoires nécessaires sont accessibles en écriture, etc.)
Ping (Packet Internet Groper) vous indique si votre système communique avec le système avec lequel vous souhaitez établir la connexion sur le réseau. Il fait même un ping, ne signifie pas que le service par exemple le service RemoteRegistry est en cours d'exécution.
Cependant, pour résoudre tout problème, un ping est nécessaire. Vous pouvez résoudre à distance n'importe quel problème. Par conséquent, le ping a sa propre importance.
Si, dans des circonstances normales, votre serveur répond au ping, il est utile de le ping à des intervalles d'une minute pour vérifier s'il répond. Bien sûr, cela vous indique uniquement qu'il existe un serveur à cette adresse IP et qu'il existe un chemin d'accès réseau de la source du ping à la destination. La définition d'un seuil pour le temps de réponse peut également vous permettre de surveiller l'état du réseau. Si vous envoyez une requête ping à un serveur sur Internet, vous ne pouvez pas faire grand-chose pour réparer le réseau, mais si un client appelle pour se plaindre, vous serez déjà conscient du problème. Pinging google.com en plus est également utile. Si vous et google êtes tous les deux en panne, quelque chose se passe.
Comme d'autres l'ont mentionné, il est important de vérifier que le service que vous fournissez répond et que ses performances sont correctes. C'est à dire. vous voudrez peut-être vérifier pourquoi un âge Web qui répond généralement en une seconde répond maintenant, je suis 10 secondes.
Donc, savoir qu'un service ne répond pas et qu'il échoue ping vous donne beaucoup plus d'informations qu'une seule approche. De plus, si vous surveillez également les processus, sachant que le ping répond, le service ne répond pas et le serveur Web n'a pas le bon nombre de processus vous indique où chercher en premier.
Vous pouvez devenir fou avec la surveillance, alors surveillez juste assez pour vous dire quand quelque chose de mauvais s'est produit ou devient dangereux. C'est à dire. trop de swaps,> 90% d'utilisation du disque, io disque élevé, 100% de CPU pour des périodes prolongées et rappelez-vous que la surveillance est juste une attaque par déni de service effectuée très lentement.