Comment faire le meilleur usage d’un sniffeur réseau

De plus en plus d’administrateurs réseau s’orientent vers les solutions NPM/APM, alors qu’ils disposent déjà de sniffeurs réseau et d’analyseurs de paquets, et qu’ils sont parfaitement compétents lorsqu’il s’agit d’analyser les paquets réseau dans le détail.  Et ce quelque soit le décodeur de protocoles : opensource ou sous licence commerciale, et quelque soit l’éditeur (ex., Wireshark, Savvius, Clearsight, Network Observer, ….).

Pour quelles raisons font-ils cela ? Quelles sont les difficultés auxquelles ils sont confrontés ? Comment les dépasser ?

Quelles sont les limites de leurs sniffeurs pour résoudre les problèmes de performance?

La lecture du témoignage de la Préfecture de Police de Paris, au sujet de son utilisation de SkyLIGHT PVX, vous éclairera sur la nature des limites rencontrées dans l’utilisation des décodeurs de paquets tels que Wireshark ou Clearsight. Voici le contexte :

• ils exploitent une infrastructure de 30.000 utilisateurs répartis sur 300 sites.
• les utilisateurs remontent périodiquement des problèmes de lenteurs applicatives

Jusqu’en 2011, leurs administrateurs réseau se sont appuyés sur les décodeurs de protocole pour faire du troubleshooting (résolution d’incidents), notamment sur les produits Wireshark et Clearsight. Ils se déplaçaient sur site avec ces outils logiciels et tentaient de capturer un échantillon de trafic qui corresponde à une dégradation de performance. Il ne réussissaient que rarement à diagnostiquer quoi que ce soit.

Qu’est ce qui rend si difficile la résolution d’incidents de performance à l’aide d’un sniffeur

• La performance ressentie par l’utilisateur est une notion subjective : en conséquence, si votre sniffeur ne vous donne pas un jeu complet d’indicateurs de performance, vous aurez beaucoup de mal à déterminer quand les utilisateurs atteignent un niveau de performance satisfaisant.
• Les remontées des utilisateurs ne permettent pas de connaître le moment précis et le périmètre d’une dégradation. Les administrateurs réseau ne collectent pas des plaintes suffisamment précises pour déterminer quels sont les clients impactés, à quel moment, pour quelle transaction et vers quel serveur.
• Les sniffeurs sont inutiles à moins que que vous puissiez leur soumettre très précisément ce que vous cherchez. A défaut, vous vous trouvez devant une masse trop importante de données pour exploiter la capacité d’un sniffeur à vous fournir une analyse détaillée.
• Les dégradations de performance sont souvent intermittentes… si vous n’avez pas sauvegardé le trafic concerné, vous pouvez seulement espérer que vous serez en mesure de capturer la prochaine dégradation de même nature. Mais en réalité, ce dont vous avez besoin, c’est d’un historique de la performance de votre réseau et de vos applications.

Une solution APM/NPM peut vous apporter ce que le décodeur de protocoles ne vous fournira jamais :

• une vue historique de la performance qui permette de comprendre quand ou alors où il y a eu une dégradation (et quel est le niveau « normal » du comportement de votre application).
• le passage rapide d’une vue graphique de l’évolution des temps de réponses à des conversations spécifiques de façon à ce que vous puissiez limiter votre analyse en détail aux seules conversations (et le cas échéant aux seules transactions) qui correspondent à la dégradation.

Une fois équipé d’un NPM/APM, vous pourrez également faire un usage plus adapté de votre décodeur de paquets.

C’est précisément ce que nous avons réussi en intégrant SkyLIGHT PVX avec la solution Omnipeek de Wildpacket.