Outil pour monitorer une IP distante et ses intermédiaires (tracert)

Outil pour monitorer une IP distante et ses intermédiaires (tracert) - Réseaux - Systèmes & Réseaux Pro

Marsh Posté le 19-09-2013 à 11:47:43    

Hello !
 
Nous utilisons pour notre site web (boutique en ligne) un flux fourni par un prestataire.
Le pool de serveurs est souvent indisponible ou en partie indispo, de quelques secondes à quelques minutes. Ces problèmes peuvent planter notre site.
 
Comme souvent, le prestataire nous renvoie la balle, ou nous dit ne pas avoir de prb, que c'est sûrement entre nous, et eux...
 
Nous pingons donc en continue, suivons les serveurs via Cacti pour générer des courbes, mais... ce n'est pas assez.
Nous devons savoir si c'est chez eux, à l'extrémité, ou un intermédiaire.
 
Nous devons donc tracer les adresses.
 
Connaissez-vous un outil qui permette de monitorer plusieurs adresses de cette façon et de biper/flasher quand ça déconne ? (et de nous montrer rapidement où ça foire)
 
:jap:


---------------
www.aurora-maniacs.com - Tout sur les aurores boréales : prévisions aurores, explications, infos pour organiser un voyage en Laponie, photos..
Reply

Marsh Posté le 19-09-2013 à 11:47:43   

Reply

Marsh Posté le 19-09-2013 à 12:19:12    

Nagios entre le serveur hébergé chez eux et chez vous ? [:spamatounet]  
http://www.it-sudparis.eu/s2ia/user/procacci/Doc/nagios/nagios001.png
Avec un mail envoyé s'il y a un problème de ping ou de service arrêté... mais ça ne dira pas si cela vient d'un intermédiaire sauf à pinger aussi cet intermédiaire. Idem si "chez eux" si c'est un switch qui déconne, là seul un outil comme MRTG ou NFsen pourra faire remonter ce problème, chose que vous ne pouvez installer car il faut avoir accès à certaines données (transmises par SNMP)
 
Un test avec iperf peut aussi être judicieux pour savoir si au niveau débit il n'y a pas de problème, notamment s'il est fait mention d'un débit minimal garanti dans les contrats.


---------------
Grippe ? Coronavirus ? Portez votre masque correctement ! :D
Reply

Marsh Posté le 19-09-2013 à 12:30:55    

Salut,
 
pingplotter fait ca pas mal à priori : http://www.pingplotter.com .
 
Sinon le plus simple est sans doute de réaliser le tracert à chaque fois que vous observez l'incident, mais ca pense que tu le savais déjà !
 
Au pire, noter les adresses remontées par le tracert et les monitorer toutes par ping, mais attention les routes peuvent changer et donc les adresses à monitorer.
 
Bon courage


---------------
Mon blog sur le métier de DSI : http://www.dsiblog.fr
Reply

Marsh Posté le 19-09-2013 à 12:45:29    

alex th a écrit :

Au pire, noter les adresses remontées par le tracert et les monitorer toutes par ping, mais attention les routes peuvent changer et donc les adresses à monitorer.


Je me permets de rajouter que les routeurs des opérateurs :
 - ne répondent pas forcément au ping venant d'autres sources que leur noc
 - peuvent avoir un rate-limit qui engendrerait des faux positif
 - les routes issues d'un traceroute indiquent le chemin uniquement dans un seul sens
 - ces routes peuvent changer (pb réseau, ecmp, etc...)
 - les routeurs opérateurs peuvent être pollé ponctuellement pour des problèmes de troubleshooting mais pas continuellement


---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 19-09-2013 à 13:04:34    

Le plus simple ne serait-il pas de checker l'accès aux serveurs du presta depuis un autre site (avec un autre opérateur) ?

Reply

Marsh Posté le 19-09-2013 à 14:33:42    

ShonGail a écrit :

Le plus simple ne serait-il pas de checker l'accès aux serveurs du presta depuis un autre site (avec un autre opérateur) ?

 

j'aurais dit ça aussi. Le boulot du presta c'est de garantir l'accès au site depuis l'extérieur, donc c'est ça qu'il faut mesurer.
Si possible depuis plusieurs opérateurs différents (enfin si c'est un site public destiné à être accédé par n'importe qui).

 

Après les métriques à prendre en compte sont multiples, temps de réponse IP (smokeping peut te faire ça assez simplement), temps d'ouverture d'une session TCP sur le port 80, temps complet de chargement de la page d'accueil, etc.
Faire un traceroute régulier peut aussi te permettre de voir si le chemin change parfois et si ça se corrèle avec les moments où ça marche moins bien.

 

Mais comme dit o'gure les intermédiaires tu ne peux pas vraiment les monitorer, et te fier au résultat de ping des routeurs que tu traverses c'est hasardeux.

Message cité 1 fois
Message édité par Misssardonik le 19-09-2013 à 14:36:49

---------------
Que va-t-il se passer cette gelgamar ? vous le découvrirez janamont à 20h
Reply

Marsh Posté le 19-09-2013 à 16:02:05    

Merci les gars.
 
 

alex th a écrit :

Salut,
 
pingplotter fait ca pas mal à priori : http://www.pingplotter.com .
 
Sinon le plus simple est sans doute de réaliser le tracert à chaque fois que vous observez l'incident, mais ca pense que tu le savais déjà !
 
Au pire, noter les adresses remontées par le tracert et les monitorer toutes par ping, mais attention les routes peuvent changer et donc les adresses à monitorer.
 
Bon courage


J'utilise déjà fping, qui a chaque test ping un DNS Google comme référence + les 6 IP, + BIP en cas d'erreur. Dès que ça bip plusieurs fois de suite, on regarde, et on sait très rapidement que ça va couper.
 
On peut bien sûr faire un tracert à la main quand ça foire, mais le temps de réaction pour tester les 6 IP manuellement...  
Avec un outil qui automatique et qui indique visuellement qu'elle étape de al route coupe serait particulièrement rapide. Posé sur un écran dédié, on serait assez réactif.
 
Par manque de ressource humaine/temps, nous ne pourrons pas nous le développer en interne.


---------------
www.aurora-maniacs.com - Tout sur les aurores boréales : prévisions aurores, explications, infos pour organiser un voyage en Laponie, photos..
Reply

Marsh Posté le 19-09-2013 à 16:04:18    

ShonGail a écrit :

Le plus simple ne serait-il pas de checker l'accès aux serveurs du presta depuis un autre site (avec un autre opérateur) ?


Tu ne peux pas être sûr que les routes seront complètement différentes, même en changeant d'opérateur. On partie sera peut-être commune.


---------------
www.aurora-maniacs.com - Tout sur les aurores boréales : prévisions aurores, explications, infos pour organiser un voyage en Laponie, photos..
Reply

Marsh Posté le 19-09-2013 à 16:07:19    

Misssardonik a écrit :

temps de réponse IP (smokeping peut te faire ça assez simplement),


 
Pour Cacti, j'utilise Advanced Ping dans Cacti, "mieux" que Smokeping. Je teste le port TCP 80.
En + de ça, on a FPING qui tourne toutes les 2s avec un timeout de 5s.
 
 
On doit savoir si ça foire chez eux (on en est sûr) ou sur la route, pour leur prouver que ça vient d'eux. Pour l'instant, ils nous disent que tout es ok chez eux, que ça doit venir entre nos serveurs et eux. Facile de se décharger quand on sait qu'internet est un réseau "non sûr".
 
 
 
 


---------------
www.aurora-maniacs.com - Tout sur les aurores boréales : prévisions aurores, explications, infos pour organiser un voyage en Laponie, photos..
Reply

Marsh Posté le 19-09-2013 à 16:49:34    

Jey-b a écrit :


Tu ne peux pas être sûr que les routes seront complètement différentes, même en changeant d'opérateur. On partie sera peut-être commune.


 
Oui enfin si leur service est inaccessible de ta part et depuis un serveur en datacenter par exemple, cela devient plus leur problème que le tien.

Reply

Marsh Posté le 19-09-2013 à 16:49:34   

Reply

Marsh Posté le 19-09-2013 à 17:22:02    

Reply

Marsh Posté le 19-09-2013 à 17:38:44    

Jey-b a écrit :

J'utilise déjà fping, qui a chaque test ping un DNS Google comme référence + les 6 IP, + BIP en cas d'erreur. Dès que ça bip plusieurs fois de suite, on regarde, et on sait très rapidement que ça va couper.
<...>
Par manque de ressource humaine/temps, nous ne pourrons pas nous le développer en interne.


et tu peux ne pas juste rajouter les commandes traceroutes en //  + redirection dans un fichier/mail à ton script de tests/bip  ? Ce n'est pas bien lourd à développer vu que tu as déjà l'infra en place.
 
 
 

Jey-b a écrit :

En + de ça, on a FPING qui tourne toutes les 2s avec un timeout de 5s.


Article intéressant, pour info
http://www.bortzmeyer.org/que-pinguer.html


---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 20-09-2013 à 12:10:33    


Ne monitore qu'une IP, ne gère pas les alertes.
 
pingplotter peut correspondre, je l'ai installé et ai commencé à le configurer (les 6 serveurs du pool), et reprendrai dès que j'aurai le temps.
 
 
Merci pour votre aide et vos idées.


---------------
www.aurora-maniacs.com - Tout sur les aurores boréales : prévisions aurores, explications, infos pour organiser un voyage en Laponie, photos..
Reply

Marsh Posté le 20-09-2013 à 14:17:52    

J'ai l'impression d'être invisible [:transparency]  
Pour la route, en affichant le débit ou le ping vers les 6 adresses AP avec weathermap ça pourrait aussi le faire [:spamatounet]


---------------
Grippe ? Coronavirus ? Portez votre masque correctement ! :D
Reply

Marsh Posté le 23-09-2013 à 08:25:41    

Nous avons eu un pb similaire et pour s'assurer que le pb ne venait pas de chez nous, nous avons pris un VPS chez un hébergeur (Gand ou OVH, par ex) et installer SmokePing (ou tout autre outil de monitoring type Nagios ou Icinga, plus lourds que Smokeping pour le résultat recherché).
 
Sur ce dernier, nous monitorons les ips à surveiller (la tienne + celle de ton fournisseur) + des sites indépendants (www.google.fr, par ex) ce qui permet d'être sûr que ce n'est pas éventuellement le serveur VPS qui pose problème.  
 
En gros, si Google répond, mais pas l'ip mesurée, c'est qu'il y a bien un pb sur l'ip.
 
@+
 
Fred


---------------
http://leblogdundsi.lesprost.fr/
Reply

Marsh Posté le 23-09-2013 à 17:02:42    

La commande mtr dans un screen sous linux.


Message édité par roondar le 23-09-2013 à 17:04:17
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed