Bé Mercury, c'est un peu le principe du monitoring réseau/service :
- on installe une répondeur sur le(s) serveur(s)
- et une sonde (un ping) sur plusieurs clients, clients qui doivent se trouver sur différents réseaux (différents FAI, backbones), et journaliser (prendre note, dans un journal, un log) le résultat obtenu
Les résultats des clients "ping" est agrégé - on récupère tout et on calcule - sur un serveur indépendant, ce qui permet d'identifier clairement où se trouve le noeud du problème, aussi bien sur la qualité du lien que sur les couches transport, application, port/socket, etc. en réponse (trop compliqué à expliquer en quelques lignes)
C'est un peu long à mettre en place, il faut des volontaires, quelques uns au début, et c'est relativement efficace. A condition de savoir interpréter les chiffres.
Mettre un script de traces (logs) sur le serveur seul ne permet pas de qualifier le service, un log permet de savoir ce qui arrive sur la machine (et encore, avec souvent du garbage), mais ça ne permet pas de savoir ce qui n'arrive *pas* sur cette machine (cas de ce qui est bloqué par un routeur ou autre élément actif en amont, etc.). On peut utiliser SNMP pour controler les équipements environnants, mais c'est relativement gourmand en ressource système, pas souvent exploitable.
Désolé pour le côté technique - abscons - pour beaucoup ici. C'est de la vrai soupe technique. Ca donne mal au crâne, et ça n'arrange pas la couche d'ozone.
Le principal est de savoir que des vraies solutions de monitoring existent, que le test local ne sert à grand chose sauf à se poser des questions, ce qui est déjà pas si mal.
Et comme je le disais, il existe des solutions open-source et commerciales de monitoring qui font ça très bien.
op%C3%A9rateur.png){kind=icon}
