Vous perdez trop de temps à résoudre les problèmes ?
Dans notre étude « State of the Network 2008 », 75 pour cent des professionnels de réseau ont cité que « identifier la source de problème » était leur souci primaire de résolution de problèmes réseau. La plupart des répondants passe au moins 25 jours par an à déterminer les causes de leurs problèmes. En plus de la résolution, l'étude a aussi jeté un coup d’œil sur le 10 GbE, VoIP, et les tendances de MPLS.

Voir l'étude (PDF) (en Anglais)

     
   
  Allez jusqu’au détail avec « L’Analyse Applicative »
Selon l’étude globale récente de Network Instruments, trois quarts de directeurs de réseau deviennent embourbés afin d’indiquer exactement les causes des problèmes et les problèmes de performance d'application. Il manque souvent aux entreprises la visibilité nécessaire pour identifier la source d'un problème réseau.


L’Analyse Applicative d’Observer diffère de la concurrence dans sa capacité à donner les détails sur les erreurs et la performance. Cette information est souvent la clef afin de pouvoir résoudre les problèmes que d’autres solutions loupent.

L'Analyse Applicative d’Observer est un outil puissant pour rapidement identifier ou éliminer les causes d'application comme source de problème. Elle montre les détails tels que le nombre d'erreurs, le type de transaction, et les transactions échouées pour les applications les plus couramment utilisées comme : SQL, Oracle, VoIP, HTTP, POP3, Citrix, MS Exchange, Telnet, SNMP, FTP, DNS, et MS Networking (SMB).

D'autres outils d'analyse peuvent offrir un reporting limité de temps de réponse, mais la plupart échoue dans la présentation des informations détaillées sur les performances d’application ou les codes d’erreurs.

L'exemple suivant montre comment l'Analyse Applicative détaillée d’Observer permet à des administrateurs réseau d'isoler exactement les problèmes d'exécution qu’ils ne peuvent pas voir avec d'autres outils d'analyse :

Un utilisateur s'est plaint que l'accès à la base de données du service comptabilité était lent. Le problème a-t-il été provoqué par des erreurs de réseau, de serveur ou d'application ? D'autres outils d'analyse ont prouvé que les temps de réponse d'application semblaient normaux.

En utilisant l'Analyse Applicative d’Observer, le responsable réseau a pu forer dans la performance du serveur de SQL pour une vue détaillée. Bien que l'exécution d'application ait semblé normale, les codes d'erreur ont indiqué que pour chaque demande le serveur publiait des messages d’erreurs « Serveur non disponible ».

Le responsable a vérifié la console de gestion de base de données, a déterminé que la base de données était corrompue et l'a reconstituée, ce qui a résolu le problème.

Observer fournit l'analyse détaillée et spécifique à l'application qui est critique pour indiquer exactement la cause d'erreur. Sans l’analyse précise, le responsable réseau aurait passé des heures essayant de localiser le problème réseau.

 

     
   
  Forer dans les erreurs d'Analyse Applicative
Les rapports d'erreurs de l'analyse d'application à niveau élevé facilitent l’exploration des détails d’erreurs et permettent de forer dans les paquets. Pour faire ainsi, suivez les étapes ci-dessous :

 

  1. Dans l’écran « Decode & Analysis » d’Observer, cliquez sur « Applications Statistics », ce qui représente les statistiques de l’appareil spécifique dans la capture.

  2. Repérez l'erreur d'application. Dans l'exemple, l'erreur de serveur interne est sélectionnée. Cliquer-droite sur l'erreur et choisissez « Show Error Detail ». Ceci produit l'écran d'erreur, qui énumère les erreurs avec la demande correspondante, les paquets et les temps de réponse.



  3. Pour regarder le paquet d'erreur spécifique dans le décodage, sélectionnez l'erreur et puis « Go to Response Packet » ou « Go to Request Packet ». Selon le protocole, ceci vous donnera la vue détaillée au niveau de la trame sur l'erreur.



 

     
 
mai 2008 


La réponse du mois dernier
La segmentation de Data Stream se produit dans la couche de transport du modèle OSI. Félicitations au gagnant du mois dernier, Marque Bibbs d’Atlanta, Georgia.

La question du mois : A quelle couche OSI le Frame Relay est-il lié ?

Soumettez votre réponse pour peut être gagner un magnifique polo Network Instruments®.

Quel est l'état de votre réseau?
Lisez sur les tendances en MPLS, VoIP, et 10 GbE. (en Anglais)

NIU à Paris
11-13 juin

Hôpital Expo
Paris
27-30 mai