Dans mon application, je fais 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 ... Existe-t-il d'autres inconvénients? Existe-t-il une méthode plus fiable?
Réponses:
La meilleure façon de savoir si un service distant donné est actif est de lui demander de répondre à la demande de la manière dont il est censé le faire. En fait, c'est le seul moyen de vraiment savoir que quelque chose fonctionne correctement.
Par exemple, je demande toujours à mes équilibreurs de charge de recevoir une réponse directe de nos serveurs Web. Vous pouvez faire de même pour un petit choix sur une boîte de base de données si vous le souhaitez, ou quel que soit le type de serveur utilisé. Comme astuce, vous pouvez créer un 'online.txt' (ou le nom que vous voulez lui donner) sur vos serveurs Web, demandez à vos LB d'essayer d'obtenir ce fichier et s'il échoue, il supprime le serveur du VIP, c'est-à-dire un moyen agréable de supprimer manuellement des serveurs individuels de vos VIP simplement en renommant un seul fichier.
Ping teste uniquement la capacité à répondre aux pings. Il s’agit donc du système d’exploitation de base, d’une partie de la pile IP et des 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 il convient de le répéter encore et encore.
Les demandes d'écho ICMP (ou "Pings") (ou ICMP Type 8) sont construites sur la spécification de pile IP, mais elles ne doivent pas nécessairement être implémentées ou utilisées. En fait, un grand nombre de fournisseurs d’Internet refusent de les transmettre et abandonnent ces demandes en silence, 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 de réseau) et il appartient donc à la configuration du système d'exploitation de répondre à ces questions ou non. Si cette option est désactivée (une mesure de sécurité?), Vous ne pouvez rien faire pour recevoir des réponses au ping de l'autre bout. C'est pourquoi ce n'est pas fiable.
La plupart du temps, oui, cependant:
certains serveurs bloquent les requêtes ping
le fait que le serveur réponde ne signifie pas automatiquement que le site Web (ou le service que vous comptez utiliser) fonctionne , vous devez également vérifier si la réponse correspond au contenu attendu.
Il est vrai que le trafic ICMP est filtré à de nombreuses reprises, de sorte qu'il pourrait ne pas être fiable ...
Une meilleure solution consisterait peut-être à établir une connexion telnet avec le serveur sur le port de service qui vous intéresse.
Telnet 127.0.0.1 8080
Si le serveur doit uniquement répondre aux pings, il s'agit d'une méthode efficace pour déterminer sa disponibilité. S'il est nécessaire de fournir, par exemple, un service Web, vous devez effectuer un test pour voir s'il fonctionne de manière similaire pour les services de fichiers, etc.
ping a 2 inconvénients:
une meilleure solution consiste à vérifier directement votre port udp / tcp pour voir si le service est toujours disponible ... :-)
Il existe des outils spéciaux pour tester et surveiller, tels que Nagios / Icinga .
Avec ces outils, vous pouvez (bien sûr) effectuer des contrôles avec divers tests de ping mais également des contrôles de vos services.
Toutes les vérifications 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 à installer (comme pointer et cliquer), mais personnalisable, fiable et extensible. Fonctionne bien sur diverses distributions Linux et Unix.
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 je dois savoir si les sites Web sont UP, je me suis fait un petit script en php et je l'ai lancé toutes les 10 minutes.
Le script fait ce qui suit ->
<?php
$website1 = "http://www.mywebsite.com/";
$myWebsite = file_get_contents($website1);
$message = 'My website' . $website1 . ' is DOWN at the moment.';
if (empty($myWebsite)) mail('mail@server.com', 'Website is DOWN', $message);
?>
Nous avons l' pinghabitude de faire une vérification préalable, que l'hôte est allumé et accessible, avant de lancer notre service systemd qui tente une connexion ssh avec celui-ci. Cela économise du temps pour le débogage, car la systemctl startcommande échouera immédiatement, au lieu d’échouer en silence et de se perdre dans la jungle journalctl.
Notez que le ping n'est pas "fiable" dans le même sens que TCP. Si vous avez une mauvaise connexion (ou une pile réseau décevante , merci Intel mpss ) et que des paquets sont abandonnés, un seul ping de paquet peut échouer. D'autre part, une connexion TCP est fiable contre les paquets perdus. Donc, paradoxalement, une connexion SSH peut fonctionner immédiatement après une ping défaillance unique . Donc, si vous utilisez ping pour effectuer un contrôle de sécurité, assurez-vous de permettre certains échecs.
Rien que mes deux cents: nous avons une application héritée qui utilise cette méthode et que nous avons dû entretenir, car le ping n’était pas suffisant pour déterminer la disponibilité du service.
Ping indique 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 d’expirer. Au lieu d’afficher notre message "Le serveur est indisponible".
-
Notre application actuelle, qui communique via XMLHTTPRequests vers un serveur Web, envoie un message formé auquel le serveur répond avec un code d'état. Le code d'état est calculé par le serveur qui effectue un certain nombre de vérifications pour s'assurer que différents sous-systèmes sont en ligne (la base de données, les répertoires nécessaires sont en écriture, etc.).
Si, dans des circonstances normales, votre serveur répond à une requête ping, il est utile de lui envoyer une requête ping toutes les minutes pour vérifier s'il répond. Bien entendu, cela vous indique uniquement qu’il existe un serveur à cette adresse IP et qu’il existe un chemin 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 pourrez peut-être rien faire pour réparer le réseau, mais si un client appelle pour se plaindre, vous serez déjà au courant du problème. En plus, cinglez google.com est également utile. Si vous et Google êtes tous les deux en panne, il se passe quelque chose.
Comme d'autres l'ont mentionné, il est important de contrôler que le service que vous fournissez répond et que ses performances sont correctes. C'est-à-dire que vous voudrez peut-être vérifier pourquoi une ère web qui répond habituellement en une seconde répond maintenant que je suis 10 secondes.
Ainsi, le fait de savoir qu'un service ne répond pas et que le ping échoue vous donne beaucoup plus d'informations qu'une seule approche. De même, si vous surveillez également les processus, sachant que ping répond, le service ne répond pas et le serveur Web ne dispose pas du nombre correct de processus. Il vous indique où chercher en premier.
Vous pouvez devenir fou avec la surveillance, alors surveillez-la suffisamment pour vous avertir lorsque quelque chose de grave s'est passé ou devient dangereux. C'est-à-dire que vous permutez trop, que vous utilisez plus de 90% du disque, que votre disque dur est élevé, que votre processeur est à 100% pendant de longues périodes et que vous vous souvenez bien que la surveillance n'est qu'une attaque par déni de service très lente.
Ping (Packet Internet Groper) vous permet de savoir si votre système communique avec le système avec lequel vous souhaitez établir une connexion sur le réseau. Même les pings, 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 n'importe quel problème à distance. Par conséquent, le ping a sa propre importance.
La meilleure façon d’utiliser mes scripts est
#rsh servername.com "date"
Mon Sep 19 04:42:20 PDT 2011
à la place de rsh, des alternatives telles que remsh peuvent être utilisées. Cela garantit que votre système distant est complètement démarré et que vous pouvez exécuter des commandes dessus. Un ping simple n’est pas suffisant car au démarrage, lorsque les services réseau sont démarrés, le système commence à répondre au ping.
rsh? Vraiment? Pourquoi ne pas utiliser à la sshplace?
rshPar contre ssh, comment être capable de s’exécuter date(en supposant que vous le soyez au départ) dit si un serveur Web, un serveur SMTP, un serveur DNS, un serveur de base de données local ou quoi que ce soit ne fonctionne pas et ne peut pas répondre aux demandes? Mieux vaut demander le service spécifique dont vous voulez vérifier la disponibilité (ce peut être un shell distant, mais ce n’est pas nécessairement le cas).
Lorsque je redémarre un serveur Windows, j'ouvre une fenêtre d'invite de commande et saisis
ping <box> -t
Tout d'abord, cela suggérera qu'il est disponible - c'est la boîte qui tombe en panne. Ensuite, vous aurez beaucoup de "demande de temps mort". Lorsque vous commencez à obtenir des réponses, la boîte est ouverte.