Résolution des problèmes de bout en bout à l’aide des métriques et de la journalisation du stockage Azure, AzCopy et Message Analyzer

• portail Azure

Le diagnostic et la résolution des problèmes constituent une compétence clé pour la création et la prise en charge d’applications clientes avec Le Stockage Microsoft Azure. En raison de la nature distribuée d’une application Azure, le diagnostic et la résolution des erreurs et des problèmes de performances peuvent être plus complexes que dans les environnements traditionnels.

Dans ce tutoriel, nous montrons comment identifier certaines erreurs susceptibles d’affecter les performances et résoudre ces erreurs de bout en bout à l’aide d’outils fournis par Microsoft et Stockage Azure, afin d’optimiser l’application cliente.

Ce tutoriel fournit une exploration pratique d’un scénario de résolution des problèmes de bout en bout. Pour obtenir un guide conceptuel détaillé pour résoudre les problèmes liés aux applications de stockage Azure, consultez Surveiller, diagnostiquer et résoudre les problèmes liés au stockage Microsoft Azure.

Outils de résolution des problèmes liés aux applications de stockage Azure

Pour résoudre les problèmes liés aux applications clientes à l’aide du Stockage Microsoft Azure, vous pouvez utiliser une combinaison d’outils pour déterminer quand un problème s’est produit et quelle est la cause du problème. Ces outils comprennent :

• azure Storage Analytics. Azure Storage Analytics fournit des métriques et une journalisation pour stockage Azure.

  • Métriques de stockage effectue le suivi des métriques de transaction et des métriques de capacité pour votre compte de stockage. À l’aide de métriques, vous pouvez déterminer la façon dont votre application s’exécute en fonction de diverses mesures. Consultez schéma de table de métriques Storage Analytics pour plus d’informations sur les types de métriques suivies par Storage Analytics.
  • journalisation du stockage journalise chaque requête adressée aux services stockage Azure dans un journal côté serveur. Le journal suit les données détaillées pour chaque requête, notamment l’opération effectuée, l’état de l’opération et les informations sur la latence. Veuillez consulter le format de journalisation Storage Analytics pour plus d’informations sur les données de demande et de réponse écrites dans les journaux d’activité par Storage Analytics.

• Portail Azure. Vous pouvez configurer les métriques et la journalisation de votre compte de stockage dans le portail Azure . Vous pouvez également afficher des graphiques et des graphiques qui montrent comment votre application s’exécute au fil du temps et configurer des alertes pour vous avertir si votre application s’exécute différemment d’une métrique spécifiée.

  Consultez Surveiller un compte de stockage dans le portail Azure pour plus d’informations sur la configuration de la supervision dans le portail Azure.

• AzCopy. Les journaux de serveur Microsoft Azure sont stockés en tant que blobs, vous pouvez donc utiliser AzCopy pour copier les blobs de journaux dans un répertoire local pour l’analyse à l’aide de Microsoft Message Analyzer. Pour plus d’informations sur AzCopy, consultez Transférer des données avec l’utilitaire AzCopy Command-Line.

• Microsoft Message Analyzer. Message Analyzer est un outil qui consomme des fichiers journaux et affiche les données de journal dans un format visuel qui facilite le filtrage, la recherche et le groupe des données de journal dans des ensembles utiles que vous pouvez utiliser pour analyser les erreurs et les problèmes de performances. Consultez Guide d’exploitation microsoft Message Analyzer pour plus d’informations sur Message Analyzer.

À propos de l’exemple de scénario

Pour ce tutoriel, nous allons examiner un scénario dans lequel les métriques stockage Azure indiquent un taux de réussite de pourcentage faible pour une application qui appelle le stockage Azure. La métrique de taux de réussite de pourcentage faible (indiquée comme PercentSuccess dans le portail Azure et dans les tables de métriques) effectue le suivi des opérations qui réussissent, mais qui retournent un code d’état HTTP supérieur à 299. Dans les fichiers journaux de stockage côté serveur, ces opérations sont enregistrées avec un état de transaction de ClientOtherErrors. Pour plus d’informations sur la métrique de faible taux de réussite, consultez Metrics show low PercentSuccess ou les entrées du journal d'analyse indiquent des opérations avec un état de transaction de ClientOtherErrors.

Les opérations de stockage Azure peuvent retourner des codes d’état HTTP supérieurs à 299 dans le cadre de leur fonctionnalité normale. Toutefois, ces erreurs dans certains cas indiquent que vous pouvez optimiser votre application cliente pour améliorer les performances.

Dans ce scénario, nous allons considérer un taux de réussite faible pour cent comme étant inférieur à 100%. Toutefois, vous pouvez choisir un niveau de métrique différent en fonction de vos besoins. Nous vous recommandons d’établir une tolérance de référence pour vos métriques de performances clés lors du test de votre application. Par exemple, vous pouvez déterminer, en fonction des tests, que votre application doit avoir un taux de réussite cohérent de 90%, ou 85%. Si vos données de métriques indiquent que l’application dérive de ce nombre, vous pouvez examiner ce qui peut entraîner l’augmentation.

Pour notre exemple de scénario, une fois que nous avons établi que le taux de réussite en pourcentage est inférieur à 100%, nous examinerons les journaux pour identifier les erreurs qui correspondent à ces métriques et les utiliserons pour déterminer ce qui cause le taux de réussite réduit. Nous allons examiner spécifiquement les erreurs dans la plage 400. Nous allons ensuite examiner plus attentivement les erreurs 404 (introuvables).

Certaines causes d’erreurs 400

Les exemples ci-dessous illustrent un échantillonnage d’erreurs de la plage 400 pour les requêtes sur Azure Blob Storage et leurs causes possibles. L’une de ces erreurs, ainsi que les erreurs dans la plage 300 et la plage 500, peuvent contribuer à un taux de réussite faible pour cent.

Notez que les listes ci-dessous sont loin d’être complètes. Consultez Codes d’état et d’erreur sur MSDN pour plus d’informations sur les erreurs de stockage Azure générales et sur les erreurs spécifiques à chacun des services de stockage.

Exemples de code d’état 404 (introuvable)

Se produit lorsqu'une opération de lecture sur un conteneur ou un objet blob échoue parce que le conteneur ou l'objet blob est introuvable.

• Se produit si un conteneur ou un objet blob a été supprimé par un autre client avant cette demande.
• Se produit si vous utilisez un appel d’API qui crée le conteneur ou l’objet blob après avoir vérifié s’il existe. Les API CreateIfNotExists effectuent d’abord un appel HEAD pour vérifier l’existence du conteneur ou de l’objet blob ; s’il n’existe pas, une erreur 404 est retournée, puis un deuxième appel PUT est effectué pour écrire le conteneur ou l’objet blob.

Exemples de code d’état 409 (conflit)

• Se produit si vous utilisez une API Create pour créer un conteneur ou un objet blob, sans vérifier l’existence en premier, et qu’un conteneur ou un objet blob portant ce nom existe déjà.
• Se produit si un conteneur est supprimé et que vous tentez de créer un conteneur portant le même nom avant la fin de l’opération de suppression.
• Se produit si vous spécifiez un bail sur un conteneur ou un objet blob et qu’un bail est déjà en place.

Exemples de code d’état 412 (échec de la condition préalable)

• Se produit lorsque la condition spécifiée par un en-tête conditionnel n’a pas été remplie.
• Se produit lorsque l'identifiant de bail spécifié ne correspond pas à celui du conteneur ou de l'objet blob.

Générer des fichiers journaux pour l’analyse

Dans ce tutoriel, nous allons utiliser Message Analyzer pour utiliser trois types de fichiers journaux différents, bien que vous puissiez choisir d’utiliser l’un des éléments suivants :

• Le journal de serveur , qui est créé lorsque vous activez la journalisation du stockage Azure. Le journal du serveur contient des données sur chaque opération appelée sur l’un des services stockage Azure : blob, file d’attente, table et fichier. Le journal du serveur indique quelle opération a été appelée et quel code d’état a été retourné, ainsi que d’autres détails sur la demande et la réponse.
• Le journal client .NET, qui est créé lorsque vous activez la journalisation côté client à partir de votre application .NET. Le journal client inclut des informations détaillées sur la façon dont le client prépare la demande et reçoit et traite la réponse.
• Le journal de trace réseau HTTP, qui collecte des données sur les requêtes et réponses HTTP/HTTPS, notamment pour les opérations sur le stockage Azure. Dans ce tutoriel, nous allons générer la trace réseau via Message Analyzer.

Configurer la journalisation côté serveur et les métriques

Tout d’abord, nous devons configurer la journalisation et les métriques stockage Azure afin que nous disposions de données du côté du service pour analyser. Vous pouvez configurer la journalisation et les métriques de différentes manières , via le portail Azure , à l’aide de PowerShell ou par programmation. Consultez Activer les métriques et Activer la journalisation pour plus d’informations sur la configuration de la journalisation et des métriques.

Configurer la journalisation côté client .NET

Pour configurer la journalisation côté client pour une application .NET, activez les diagnostics .NET dans le fichier de configuration de l’application (web.config ou app.config). Pour plus d’informations, consultez journalisation côté client avec la bibliothèque cliente .NET Storage et journalisation côté client avec le Kit de développement logiciel (SDK) De stockage Microsoft Azure pour Java sur MSDN.

Le journal côté client inclut des informations détaillées sur la façon dont le client prépare la demande et reçoit et traite la réponse.

La bibliothèque cliente de stockage stocke les données de journal côté client à l’emplacement spécifié dans le fichier de configuration de l’application (web.config ou app.config).

Collecter une trace réseau

Vous pouvez utiliser Message Analyzer pour collecter une trace réseau HTTP/HTTPS pendant l’exécution de votre application cliente. Message Analyzer utilise Fiddler sur le serveur principal. Avant de collecter la trace réseau, nous vous recommandons de configurer Fiddler pour enregistrer le trafic HTTPS non chiffré :

1. Installez Fiddler.
2. Lancez Fiddler.
3. Sélectionnez Outils | Options Fiddler.
4. Dans la boîte de dialogue Options, vérifiez que Capture des CONNECTs HTTPS et Déchiffrer le trafic HTTPS sont sélectionnés tous les deux, comme indiqué ci-dessous.

Pour le tutoriel, collectez et enregistrez d’abord une trace réseau dans Message Analyzer, puis créez une session d’analyse pour étudier la trace et les journaux. Pour collecter une trace réseau dans Message Analyzer :

1. Dans l’analyseur de messages, sélectionnez Fichier | Trace rapide | HTTPS non chiffré.

2. Le traçage commencera immédiatement. Sélectionnez Arrêter pour arrêter la trace afin que nous puissions la configurer pour tracer le trafic de stockage uniquement.

3. Sélectionnez Modifier pour modifier la session de suivi.

4. Sélectionnez le lien Configure à droite du fournisseur Microsoft-Pef-WebProxy ETW.

5. Dans la boîte de dialogue Paramètres Avancés, cliquez sur l'onglet Fournisseur.

6. Dans le champ filtre de nom d’hôte, spécifiez vos points de terminaison de stockage, séparés par des espaces. Par exemple, vous pouvez spécifier vos points de terminaison comme suit : remplacez storagesample par le nom de votre compte de stockage :

   storagesample.blob.core.windows.net storagesample.queue.core.windows.net storagesample.table.core.windows.net

7. Quittez la boîte de dialogue, puis cliquez sur Redémarrer pour commencer à collecter la trace avec le filtre de nom d’hôte en place, afin que seul le trafic réseau stockage Azure soit inclus dans la trace.

Remarque

Une fois que vous avez terminé de collecter votre trace réseau, nous vous recommandons vivement de rétablir les paramètres que vous avez peut-être modifiés dans Fiddler pour déchiffrer le trafic HTTPS. Dans la boîte de dialogue Options Fiddler, désélectionnez les cases à cocher Capturer les connexions HTTPS et Déchiffrer le trafic HTTPS.

Pour plus d’informations, consultez Utilisation des fonctionnalités de suivi réseau sur Technet.

Passer en revue les données des métriques dans le portail Azure

Une fois que votre application est en cours d’exécution pendant une période donnée, vous pouvez passer en revue les graphiques de métriques qui apparaissent dans le portail Azure pour observer le fonctionnement de votre service.

Tout d’abord, accédez à votre compte de stockage dans le portail Azure. Par défaut, un graphique de suivi avec la mesure du pourcentage de réussite s’affiche dans le volet du compte. Si vous avez précédemment modifié le graphique pour afficher différentes métriques, ajoutez la pourcentage de réussite métrique.

Vous verrez maintenant pourcentage de réussite dans le graphique d’analyse, ainsi que les autres métriques que vous avez peut-être ajoutées. Dans le scénario que nous allons examiner en analysant les journaux avec Message Analyzer, le taux de succès est légèrement inférieur à 100%.

Pour plus d’informations sur l’ajout et la personnalisation des graphiques de métriques, consultez Personnaliser des graphiques de métriques.

Remarque

Il peut prendre un certain temps pour que vos données de métriques apparaissent dans le portail Azure une fois que vous avez activé les métriques de stockage. Cela est dû au fait que les métriques horaires de l’heure précédente ne sont pas affichées dans le portail Azure tant que l’heure actuelle n’est pas écoulée. En outre, les métriques de minute ne sont actuellement pas affichées dans le portail Azure. Ainsi, selon le moment où vous activez les métriques, il peut prendre jusqu’à deux heures pour afficher les données de métriques.

Utiliser AzCopy pour copier les journaux du serveur dans un répertoire local

Stockage Azure écrit les données du journal du serveur dans des blobs, tandis que les métriques sont écrites dans des tables. Les objets blob de journal sont disponibles dans le conteneur $logs bien connu de votre compte de stockage. Les blobs de journal sont nommés hiérarchiquement par année, mois, jour et heure, afin que vous puissiez facilement repérer la période que vous souhaitez examiner. Par exemple, dans le compte storagesample, le conteneur des blobs de journaux pour le 01/02/2015, de 8 à 9 heures, est https://storagesample.blob.core.windows.net/$logs/blob/2015/01/08/0800. Les objets blob individuels de ce conteneur sont nommés de manière séquentielle, en commençant par 000000.log.

Vous pouvez utiliser l’outil en ligne de commande AzCopy pour télécharger ces fichiers journaux situés sur le serveur vers un emplacement de votre choix sur votre ordinateur local. Par exemple, vous pouvez utiliser la commande suivante pour télécharger les fichiers journaux des opérations sur les blobs effectuées le 2 janvier 2015 dans le dossier C:\Temp\Logs\Server; remplacez <storageaccountname> par le nom de votre compte de stockage :

azcopy copy 'http://<storageaccountname>.blob.core.windows.net/$logs/blob/2015/01/02' 'C:\Temp\Logs\Server'  --recursive

AzCopy est disponible en téléchargement sur la page Téléchargements Azure. Pour plus d’informations sur l’utilisation d’AzCopy, consultez Transférer des données avec l’utilitaire AzCopy Command-Line.

Pour obtenir des informations supplémentaires sur le téléchargement des journaux côté serveur, consultez Télécharger les données de journalisation du stockage.

Utiliser Microsoft Message Analyzer pour analyser les données de journal

Microsoft Message Analyzer est un outil permettant de capturer, d’afficher et d’analyser le trafic de messagerie de protocole, les événements et d’autres messages système ou d’application dans les scénarios de dépannage et de diagnostic. Message Analyzer vous permet également de charger, d’agréger et d’analyser des données à partir des journaux et des fichiers de trace enregistrés. Pour plus d’informations sur l’analyseur de messages, consultez Guide d’exploitation microsoft Message Analyzer.

Message Analyzer inclut des ressources pour Azure Storage qui vous aident à analyser les journaux de serveur, de client et de réseau. Dans cette section, nous allons discuter de l'utilisation de ces outils pour résoudre le problème d'un faible taux de succès dans les journaux de stockage de données.

Télécharger et installer Message Analyzer et les ressources de stockage Azure

1. Téléchargez Message Analyzer.
2. Lancez l’analyseur de messages.
3. Dans le menu Outils, sélectionnez "Asset Manager". Dans la boîte de dialogue Asset Manager, sélectionnez Téléchargements, puis appliquez un filtre sur Stockage Azure. Vous verrez les ressources de stockage Azure, comme illustré dans l’image ci-dessous.
4. Cliquez sur Synchroniser tous les éléments affichés pour installer les ressources de stockage Azure. Les ressources disponibles sont les suivantes :
   • règles de couleur de stockage Azure : règles de couleur stockage Azure vous permettent de définir des filtres spéciaux qui utilisent des styles de couleur, de texte et de police pour mettre en surbrillance les messages qui contiennent des informations spécifiques dans une trace.
   • Graphiques de stockage Azure : Les graphiques de stockage Azure sont des graphiques prédéfinis qui tracent les données des journaux du serveur. Notez que pour utiliser des graphiques stockage Azure pour l’instant, vous pouvez uniquement charger le journal du serveur dans Analysis Grid.
   • analyseurs stockage Azure : les analyseurs stockage Azure analysent le client, le serveur et les journaux HTTP du stockage Azure pour les afficher dans Analysis Grid.
   • filtres stockage Azure : filtres stockage Azure sont des critères prédéfinis que vous pouvez utiliser pour interroger vos données dans Analysis Grid.
   • dispositions d’affichage pour Azure Storage : les dispositions d’affichage pour Azure Storage sont des dispositions et regroupements de colonnes prédéfinis dans la grille d’analyse.
5. Redémarrez l’analyseur de messages après avoir installé les ressources.

Remarque

Installez toutes les ressources stockage Azure indiquées à des fins de ce didacticiel.

Importer vos fichiers de journal dans Message Analyzer

Vous pouvez importer tous vos fichiers journaux enregistrés (côté serveur, côté client et réseau) dans une session unique dans Microsoft Message Analyzer pour analyse.

1. Dans le menu Fichier dans Microsoft Message Analyzer, cliquez sur Nouvelle session, puis sur Session vide. Dans la boîte de dialogue Nouvelle session, entrez un nom pour votre session d’analyse. Dans le panneau Détails de la session , cliquez sur le bouton Fichiers.
2. Pour charger les données de trace réseau générées par Message Analyzer, cliquez sur Ajouter des fichiers, accédez à l’emplacement où vous avez enregistré votre fichier .matp à partir de votre session de suivi web, sélectionnez le fichier .matp, puis cliquez sur Ouvrir.
3. Pour charger les données du journal côté serveur, cliquez sur Ajouter des fichiers, accédez à l’emplacement où vous avez téléchargé vos journaux côté serveur, sélectionnez les fichiers journaux pour l’intervalle de temps à analyser, puis cliquez sur Ouvrir. Ensuite, dans le panneau Détails de session , définissez la liste déroulante Configuration du journal texte pour chaque fichier journal côté serveur sur AzureStorageLog pour vous assurer que Microsoft Message Analyzer peut analyser correctement le fichier journal.
4. Pour charger les données du journal côté client, cliquez sur Ajouter des fichiers, accédez à l’emplacement où vous avez enregistré vos journaux côté client, sélectionnez les fichiers journaux à analyser, puis cliquez sur Ouvrir. Ensuite, dans le panneau Détails de session , définissez la liste déroulante Configuration du journal texte pour chaque fichier journal côté client sur AzureStorageClientDotNetV4 pour vous assurer que Microsoft Message Analyzer peut analyser correctement le fichier journal.
5. Cliquez sur Démarrer dans la boîte de dialogue Nouvelle session pour charger et analyser les données de journal. Les données du journal de bord s'affichent dans la grille d'analyse de Message Analyzer.

L’image ci-dessous montre un exemple de session configurée avec les fichiers journaux de suivi du serveur, du client et du réseau.

Veuillez noter que Message Analyzer charge les fichiers de journal en mémoire. Si vous disposez d’un grand ensemble de données de journal, vous souhaiterez le filtrer afin d’obtenir les meilleures performances de Message Analyzer.

Tout d’abord, déterminez le délai que vous souhaitez examiner et conservez cette période aussi petite que possible. Dans de nombreux cas, vous voudrez passer en revue une période de minutes ou d’heures au plus. Importez le plus petit ensemble de logs pouvant répondre à vos besoins.

Si vous avez toujours une grande quantité de données de journal, vous pouvez spécifier un filtre de session pour filtrer vos données de journal avant de les charger. Dans la zone Filtre de session, sélectionnez le bouton Bibliothèque pour choisir un filtre prédéfini ; par exemple, choisissez filtre de temps global I à partir des filtres stockage Azure pour filtrer sur un intervalle de temps. Vous pouvez ensuite modifier les critères de filtre pour spécifier l’horodatage de début et de fin de l’intervalle que vous souhaitez voir. Vous pouvez également filtrer sur un code d’état particulier ; Par exemple, vous pouvez choisir de charger uniquement les entrées de journal où le code d’état est 404.

Pour plus d’informations sur l’importation de données de journal dans Microsoft Message Analyzer, consultez Récupération des données de message sur TechNet.

Utiliser l’ID de demande client pour mettre en corrélation les données du fichier journal

La bibliothèque cliente stockage Azure génère automatiquement un ID de demande client unique pour chaque requête. Cette valeur est écrite dans le journal client, le journal du serveur et la trace réseau. Vous pouvez donc l’utiliser pour mettre en corrélation les données dans les trois journaux d’activité dans Message Analyzer. Consultez ID de demande client pour plus d’informations sur l’ID de demande client.

Les sections ci-dessous décrivent comment utiliser des vues de disposition préconfigurées et personnalisées pour mettre en corrélation et regrouper des données en fonction de l’ID de demande client.

Sélectionner une disposition d’affichage à afficher dans la grille d’analyse

Les ressources de stockage pour Message Analyzer incluent des dispositions de vue stockage Azure, qui sont des vues préconfigurées que vous pouvez utiliser pour afficher vos données avec des regroupements et des colonnes utiles pour différents scénarios. Vous pouvez également créer des dispositions d’affichage personnalisées et les enregistrer à des fins de réutilisation.

L’image ci-dessous montre le menu Afficher la disposition, disponible en sélectionnant Afficher la disposition dans le ruban de la barre d’outils. Les dispositions d’affichage pour le stockage Azure sont regroupées sous le nœud Stockage Azure dans le menu. Vous pouvez rechercher Azure Storage dans la zone de recherche pour filtrer les dispositions d’affichage de Stockage Azure uniquement. Vous pouvez également sélectionner l’étoile en regard d’une disposition d’affichage pour la rendre favorite et l’afficher en haut du menu.

Pour commencer, sélectionnez groupée par ClientRequestID et module. Cette présentation regroupe les données de journal des trois journaux par ID de la demande client, puis par fichier journal source (ou Module dans Message Analyzer). Avec cette vue, vous pouvez explorer un ID de demande client particulier et afficher les données des trois fichiers journaux de cet ID de demande client.

L’image ci-dessous montre cette vue de disposition appliquée aux exemples de données de journal, avec un sous-ensemble de colonnes affichées. Vous pouvez voir que pour un ID de demande client particulier, Analysis Grid affiche les données du journal client, du journal du serveur et de la trace réseau.

Remarque

Différents fichiers journaux ont des colonnes différentes. Par conséquent, lorsque les données de plusieurs fichiers journaux sont affichées dans la grille d’analyse, certaines colonnes peuvent ne contenir aucune donnée pour une ligne donnée. Par exemple, dans l’image ci-dessus, les lignes du journal du client n’affichent aucune donnée pour l'Timestamp, TimeElapsed, Sourceet colonnes destination, car ces colonnes n’existent pas dans le journal client, mais existent dans la trace réseau. De même, la colonne d'horodatage affiche les données d’horodatage à partir du journal du serveur, mais aucune donnée n’est affichée pour les colonnes de temps écoulé , de source et de destination , qui ne font pas partie du journal du serveur.

Outre l’utilisation des dispositions d’affichage de Stockage Azure, vous pouvez également définir et enregistrer vos propres dispositions d’affichage. Vous pouvez également sélectionner d’autres champs souhaités pour regrouper les données et enregistrer le regroupement dans le cadre de votre disposition personnalisée.

Appliquer des règles de couleur à la grille d’analyse

Les ressources de stockage incluent également des règles de couleur, qui offrent un moyen visuel d’identifier différents types d’erreurs dans la grille d’analyse. Les règles de couleur prédéfinies s’appliquent aux erreurs HTTP. Elles s’affichent donc uniquement pour le journal du serveur et la trace réseau.

Pour appliquer des règles de couleur, sélectionnez règles de couleur dans le ruban de la barre d’outils. Vous verrez les règles de couleur stockage Azure dans le menu. Pour le tutoriel, sélectionnez Erreurs du client (StatusCode entre 400 et 499), comme illustré dans l’image ci-dessous.

En plus d’utiliser les règles de couleur stockage Azure, vous pouvez également définir et enregistrer vos propres règles de couleur.

Regrouper et filtrer les données du journal de bord pour rechercher des erreurs dans la plage des 400

Ensuite, nous allons regrouper et filtrer les données du journal pour rechercher toutes les erreurs dans la plage 400.

1. Recherchez la colonne StatusCode dans la grille d’analyse, cliquez avec le bouton droit sur l’en-tête de colonne, puis sélectionnez groupe.

2. Ensuite, groupez par la colonne ClientRequestId. Vous verrez que les données de la grille d’analyse sont désormais organisées par code d’état et par ID de demande client.

3. Affichez la fenêtre de l'outil Filtre d'affichage si elle n'est pas déjà ouverte. Dans le ruban de la barre d’outils, sélectionnez Outil Windows, puis Afficher le filtre.

4. Pour filtrer les données du journal afin d'afficher uniquement les erreurs du type 400, ajoutez les critères de filtre suivants à la fenêtre Affichage du filtre, puis cliquez sur Appliquer:

   (AzureStorageLog.StatusCode >= 400 && AzureStorageLog.StatusCode <=499) || (HTTP.StatusCode >= 400 && HTTP.StatusCode <= 499)

L’image ci-dessous montre les résultats de ce regroupement et de ce filtre. L'extension du champ ClientRequestID sous le regroupement du code d’état 409, par exemple, montre une opération qui a entraîné ce code d’état.

Après avoir appliqué ce filtre, vous verrez que les lignes du journal client sont exclues, car le journal client n’inclut pas de colonne StatusCode. Pour commencer, nous allons passer en revue les journaux de suivi du serveur et du réseau pour localiser les erreurs 404, puis nous retournerons au journal client pour examiner les opérations du client qui les ont conduits.

Remarque

Vous pouvez filtrer sur la colonne StatusCode et toujours afficher les données des trois journaux, y compris le journal client, si vous ajoutez une expression au filtre qui inclut des entrées de journal où le code d’état est null. Pour construire cette expression de filtre, utilisez :

*StatusCode >= 400 or !*StatusCode

Ce filtre retourne toutes les lignes du journal client et uniquement les lignes du journal du serveur et du journal HTTP où le code d’état est supérieur à 400. Si vous l’appliquez à la disposition d’affichage groupée par ID de demande client et module, vous pouvez effectuer une recherche ou faire défiler les entrées de journal pour trouver celles où les trois journaux sont représentés.

Filtrer les données du journal pour rechercher les erreurs 404

Les ressources de stockage incluent des filtres prédéfinis que vous pouvez utiliser pour affiner les données de journal pour rechercher les erreurs ou les tendances que vous recherchez. Ensuite, nous allons appliquer deux filtres prédéfinis : celui qui filtre les journaux de suivi du serveur et du réseau pour les erreurs 404, et un filtre les données sur un intervalle de temps spécifié.

1. Affichez la fenêtre de l'outil Filtre d'affichage si elle n'est pas déjà ouverte. Dans le ruban de la barre d’outils, sélectionnez Outil Windows, puis Afficher le filtre.

2. Dans la fenêtre Afficher le filtre, sélectionnez bibliothèque, puis recherchez sur Azure Storage pour rechercher les filtres stockage Azure. Sélectionnez le filtre pour les messages 404 (introuvables) dans tous les journaux d’activité.

3. Affichez à nouveau le menu de la bibliothèque , puis recherchez et sélectionnez le filtre de temps global .

4. Modifiez les horodatages affichés dans le filtre dans la plage que vous souhaitez afficher. Cela permet d’affiner la plage de données à analyser.

5. Votre filtre doit ressembler à l’exemple ci-dessous. Cliquez sur Appliquer pour appliquer le filtre à la grille d’analyse.

   ((AzureStorageLog.StatusCode == 404 || HTTP.StatusCode == 404)) And (#Timestamp >= 2014-10-20T16:36:38 and #Timestamp <= 2014-10-20T16:36:39)

   

Analyser vos données de journal

Maintenant que vous avez regroupé et filtré vos données, vous pouvez examiner les détails des requêtes individuelles qui ont généré des erreurs 404. Dans la disposition actuelle de l’affichage, les données sont regroupées par ID de demande client, puis par source de journal. Étant donné que nous filtrons sur les demandes où le champ StatusCode contient 404, nous verrons uniquement les données de suivi du serveur et du réseau, et non les données de journal du client.

L’image ci-dessous montre une requête spécifique où une opération Get Blob a produit un 404, car l’objet blob n’existe pas. Notez que certaines colonnes ont été supprimées de l’affichage standard pour afficher les données pertinentes.

Ensuite, nous allons mettre en corrélation cet ID de demande client avec les données du journal client pour voir quelles actions le client a effectuées lorsque l’erreur s’est produite. Vous pouvez afficher une nouvelle vue Analysis Grid pour cette session pour afficher les données du journal client, qui s’ouvre dans un deuxième onglet :

1. Tout d’abord, copiez la valeur du champ ClientRequestId dans le presse-papiers. Pour ce faire, sélectionnez l’une ou l’autre ligne, recherchez le champ ClientRequestId, cliquez avec le bouton droit sur la valeur de données et choisissez Copier « ClientRequestId ».

2. Dans le ruban de la barre d’outils, sélectionnez Nouvelle visionneuse, puis Grille d’analyse pour ouvrir un nouvel onglet. Le nouvel onglet affiche toutes les données de vos fichiers journaux, sans regroupement, filtrage ou règles de couleur.

3. Dans le ruban de la barre d’outils, sélectionnez Afficher la disposition, puis toutes les colonnes de client .NET sous la section Stockage Azure. Cette disposition d’affichage affiche les données du journal client ainsi que les journaux de suivi du serveur et du réseau. Par défaut, il est trié sur la colonne MessageNumber.

4. Ensuite, recherchez l’ID de demande du client dans le journal du client. Dans le ruban de la barre d’outils, sélectionnez Rechercher des messages, puis spécifiez un filtre personnalisé sur l’ID de demande client dans le champ Rechercher. Utilisez cette syntaxe pour le filtre, en spécifiant votre propre ID de demande client :

   *ClientRequestId == "398bac41-7725-484b-8a69-2a9e48fc669a"

Message Analyzer localise et sélectionne la première entrée de journal où les critères de recherche correspondent à l’ID de demande client. Dans le journal du client, il existe plusieurs entrées pour chaque ID de demande client. Vous pouvez donc les regrouper sur le champ ClientRequestId pour faciliter leur vue ensemble. L’image ci-dessous montre tous les messages dans le journal client pour l’ID de demande client spécifié.

journal des erreurs 404 du client

À l’aide des données affichées dans les dispositions d’affichage de ces deux onglets, vous pouvez analyser les données de requête pour déterminer ce qui peut avoir provoqué l’erreur. Vous pouvez également examiner les demandes qui ont précédé celle-ci pour voir si un événement précédent peut avoir entraîné l’erreur 404. Par exemple, vous pouvez consulter les entrées du journal client précédant cet ID de demande client pour déterminer si l’objet blob a peut-être été supprimé ou si l’erreur était due à l’application cliente appelant une API CreateIfNotExists sur un conteneur ou un objet blob. Dans le journal du client, vous pouvez trouver l’adresse de l’objet blob dans le champ Description; dans les journaux de suivi du serveur et du réseau, ces informations apparaissent dans le champ Résumé.

Une fois que vous connaissez l’adresse de l’objet blob qui a généré l’erreur 404, vous pouvez examiner plus en détail. Si vous recherchez les entrées de journal pour d’autres messages associés aux opérations sur le même objet blob, vous pouvez vérifier si le client a précédemment supprimé l’entité.

Analyser d’autres types d’erreurs de stockage

Maintenant que vous êtes familiarisé avec l’utilisation de Message Analyzer pour analyser vos données de journal, vous pouvez analyser d’autres types d’erreurs à l’aide de dispositions d’affichage, de règles de couleur et de recherche/filtrage. Les tableaux ci-dessous répertorient certains problèmes que vous pouvez rencontrer et les critères de filtre que vous pouvez utiliser pour les localiser. Pour plus d’informations sur la construction de filtres et la langue de filtrage de Message Analyzer, consultez filtrage des données de message.

Pour enquêter...	Utiliser l’expression de filtre …	Expression s’applique au log (client, serveur, réseau, tout)
Les retards inattendus dans la livraison de messages sur une file d’attente	AzureStorageClientDotNetV4.Description contient « Nouvelle tentative d’opération ayant échoué ».	Client
Augmentation de l'erreur de limitation en pourcentage HTTP	HTTP. Response.StatusCode == 500 || HTTP. Response.StatusCode == 503	Réseau
Augmentation de l'erreur de délai d'expiration (PercentTimeoutError)	HTTP. Response.StatusCode == 500	Réseau
Augmentation de PercentTimeoutError (tous)	*StatusCode == 500	Tous
Augmentation du pourcentage d'erreur réseau	AzureStorageClientDotNetV4.EventLogEntry.Level < 2	Client
Messages HTTP 403 (Interdit)	HTTP. Response.StatusCode == 403	Réseau
Messages HTTP 404 (non trouvé)	HTTP. Response.StatusCode == 404	Réseau
Erreur 404 (tous)	*StatusCode == 404	Tous
Problème d’autorisation de la Signature d'Accès Partagé (SAS)	AzureStorageLog.RequestStatus == « SASAuthorizationError »	Réseau
Messages HTTP 409 (Conflit)	HTTP. Response.StatusCode == 409	Réseau
409 (tout)	*StatusCode == 409	Tous
Les entrées de journal de l'analyse ou avec un faible percentSuccess comprennent des opérations avec un état de transaction de ClientOtherErrors.	AzureStorageLog.RequestStatus == « ClientOtherError »	Serveur
Avertissement Nagle	((AzureStorageLog.EndToEndLatencyMS - AzureStorageLog.ServerLatencyMS) > (AzureStorageLog.ServerLatencyMS * 1.5)) et (AzureStorageLog.RequestPacketSize < 1460) et (AzureStorageLog.EndToEndLatencyMS - AzureStorageLog.ServerLatencyMS > = 200)	Serveur
Intervalle de temps dans les journaux de serveur et de réseau	#Timestamp >= 2014-10-20T16:36:38 et #Timestamp <= 2014-10-20T16:36:39	Serveur, réseau
Intervalle de temps dans les journaux du serveur	AzureStorageLog.Timestamp >= 2014-10-20T16:36:38 et AzureStorageLog.Timestamp <= 2014-10-20T16:36:39	Serveur

Étapes suivantes

Pour plus d’informations sur la résolution des problèmes liés aux scénarios de bout en bout dans stockage Azure, consultez les ressources suivantes :

• Analyser, diagnostiquer et dépanner Microsoft Azure Storage
• Analyse du stockage
• Surveiller un compte de stockage dans le portail Azure
• Transfert de données avec l’utilitaire de ligne de commande AzCopy
• Guide d'utilisation Microsoft Message Analyzer