Partager via

Surveiller, diagnostiquer et résoudre les problèmes Stockage Microsoft Azure (classique)

  • Article

Ce guide vous montre comment utiliser des fonctionnalités telles qu’Azure Storage Analytics, la journalisation côté client dans la bibliothèque cliente stockage Azure et d’autres outils tiers pour identifier, diagnostiquer et résoudre les problèmes liés au stockage Azure.

Diagramme montrant le flux d’informations entre les applications clientes et les services de stockage Azure.

Ce guide est destiné à être lu principalement par les développeurs de services en ligne qui utilisent les services de stockage Azure et les professionnels de l’informatique chargés de gérer ces services en ligne. Les objectifs de ce guide sont les suivants :

  • Pour vous aider à maintenir l’intégrité et les performances de vos comptes stockage Azure.
  • Pour vous fournir les processus et outils nécessaires pour vous aider à déterminer si un problème ou un problème dans une application est lié au stockage Azure.
  • Pour vous fournir des conseils actionnables pour résoudre les problèmes liés au stockage Azure.

Remarque

Cet article est basé sur l’utilisation de Storage Analytics métriques et journaux d’activité appelés métriques et journaux classiques. Nous vous recommandons d’utiliser des métriques et des journaux de Stockage Azure dans Azure Monitor au lieu de Storage Analytics journaux. Pour en savoir plus, consultez l’un des articles suivants :

Vue d’ensemble

Le diagnostic et la résolution des problèmes dans une application distribuée hébergée dans un environnement cloud peuvent être plus complexes que dans les environnements traditionnels. Les applications peuvent être déployées dans une infrastructure PaaS ou IaaS, localement, sur un appareil mobile ou dans une combinaison de ces environnements. En règle générale, le trafic réseau de votre application peut traverser des réseaux publics et privés, et votre application peut utiliser plusieurs technologies de stockage telles que des tables Stockage Microsoft Azure, des objets blob, des files d’attente ou des fichiers, en plus d’autres magasins de données tels que les bases de données relationnelles et de documents.

Pour gérer correctement ces applications, vous devez les surveiller de manière proactive et comprendre comment diagnostiquer et dépanner tous les aspects de celles-ci et de leurs technologies dépendantes. En tant qu’utilisateur des services de stockage Azure, vous devez surveiller en permanence les services de stockage utilisés par votre application pour détecter tout changement de comportement inattendu (par exemple, des temps de réponse plus lents que d’habitude) et utiliser la journalisation pour collecter des données plus détaillées et analyser un problème en profondeur. Les diagnostics informations que vous obtenez de la surveillance et de la journalisation vous aideront à déterminer la cause racine du problème rencontré par votre application. Vous pouvez ensuite résoudre le problème et déterminer les étapes appropriées pour y remédier. Stockage Azure est un service Azure de base et constitue une partie importante de la majorité des solutions que les clients déploient sur l’infrastructure Azure. Stockage Azure inclut des fonctionnalités permettant de simplifier la surveillance, le diagnostic et la résolution des problèmes de stockage dans vos applications cloud.

Comment ce guide est organisé

La section Surveillance de votre service de stockage décrit comment surveiller l’intégrité et les performances de vos services de stockage Azure à l’aide des métriques azure Storage Analytics (métriques de stockage).

La section Diagnostic des problèmes de stockage explique comment diagnostiquer les problèmes à l’aide de la journalisation azure Storage Analytics (journalisation du stockage). Il décrit également comment activer la journalisation côté client à l’aide des fonctionnalités de l’une des bibliothèques clientes, telles que la bibliothèque cliente de stockage pour .NET ou le Kit de développement logiciel (SDK) Azure pour Java.

La section Suivi de bout en bout décrit comment mettre en corrélation les informations contenues dans différents fichiers journaux et données de métriques.

La section Conseils de dépannage fournit des conseils de dépannage pour certains des problèmes courants liés au stockage que vous pouvez rencontrer.

La section Annexes contient des informations sur l’utilisation d’autres outils, tels que Wireshark et Netmon pour l’analyse des données de paquets réseau, et Fiddler pour l’analyse des messages HTTP/HTTPS.

Surveillance de votre service de stockage

Si vous êtes familiarisé avec la surveillance des performances Windows, vous pouvez considérer les métriques de stockage comme étant un équivalent de Stockage Azure des compteurs de Analyseur de performances Windows. Dans Métriques de stockage, vous trouverez un ensemble complet de métriques (compteurs dans la terminologie Windows Analyseur de performances), telles que la disponibilité du service, le nombre total de demandes de service ou le pourcentage de demandes de service réussies. Pour obtenir la liste complète des métriques disponibles, consultez Storage Analytics Schéma de table de métriques. Vous pouvez spécifier si vous souhaitez que le service de stockage collecte et agrège les métriques toutes les heures ou toutes les minutes. Pour plus d’informations sur l’activation des métriques et la surveillance de vos comptes de stockage, consultez Activation des métriques de stockage et affichage des données de métriques.

Vous pouvez choisir les métriques horaires que vous souhaitez afficher dans le Portail Azure et configurer des règles qui informent les administrateurs par e-mail chaque fois qu’une métrique horaire dépasse un seuil particulier. Pour plus d’informations, consultez Recevoir des notifications d’alerte.

Nous vous recommandons de consulter Azure Monitor pour le stockage (préversion). Il s’agit d’une fonctionnalité d’Azure Monitor qui offre une surveillance complète de vos comptes stockage Azure en fournissant une vue unifiée des performances, de la capacité et de la disponibilité de vos services de stockage Azure. Il n’est pas nécessaire d’activer ou de configurer quoi que ce soit, et vous pouvez immédiatement afficher ces métriques à partir des graphiques interactifs prédéfinis et d’autres visualisations incluses.

Le service de stockage fait de son mieux pour collecter les métriques, mais peut ne pas enregistrer toutes les opérations de stockage.

Dans le Portail Azure, vous pouvez afficher des métriques telles que la disponibilité, le nombre total de demandes et les nombres de latence moyenne pour un compte de stockage. Une règle de notification a également été configurée pour alerter un administrateur si la disponibilité tombe en dessous d’un certain niveau. À partir de l’affichage de ces données, un domaine d’investigation possible est le pourcentage de réussite du service de table étant inférieur à 100 % (pour plus d’informations, consultez la section Métriques show low PercentSuccess ou analytics log entrées with transaction status of ClientOtherErrors).

Vous devez surveiller en permanence vos applications Azure pour vous assurer qu’elles sont saines et performantes comme prévu par :

  • Établissement de métriques de base pour l’application qui vous permettront de comparer les données actuelles et d’identifier les changements significatifs dans le comportement du stockage Azure et de votre application. Les valeurs de vos métriques de base sont, dans de nombreux cas, spécifiques à l’application, et vous devez les établir lorsque vous testez les performances de votre application.
  • Enregistrement des métriques par minute et utilisation de celles-ci pour surveiller activement les erreurs et anomalies inattendues, telles que les pics de nombre d’erreurs ou les taux de requêtes.
  • Enregistrement des métriques horaires et utilisation de celles-ci pour surveiller les valeurs moyennes telles que le nombre moyen d’erreurs et les taux de demandes.
  • Examen des problèmes potentiels à l’aide d’outils diagnostics comme décrit plus loin dans la section Diagnostic des problèmes de stockage.

Les graphiques de l’image suivante illustrent comment la moyenne qui se produit pour les métriques horaires peut masquer les pics d’activité. Les métriques horaires semblent afficher un taux stable de requêtes, tandis que les métriques de minute révèlent les fluctuations qui se produisent réellement.

Graphiques qui montrent comment la moyenne qui se produit pour les métriques horaires peut masquer les pics d’activité.

Le reste de cette section décrit les métriques à surveiller et pourquoi.

Surveillance de l’intégrité du service

Vous pouvez utiliser le Portail Azure pour afficher l’intégrité du service de stockage (et d’autres services Azure) dans toutes les régions Azure du monde entier. La surveillance vous permet de voir immédiatement si un problème en dehors de votre contrôle affecte le service de stockage dans la région que vous utilisez pour votre application.

Le Portail Azure peut également fournir des notifications d’incidents qui affectent les différents services Azure.

Remarque

Ces informations étaient auparavant disponibles, ainsi que les données historiques, sur le tableau de bord du service Azure. Pour plus d’informations sur Application Insights pour Azure DevOps, consultez Annexe 5 : Surveillance avec Application Insights pour Azure DevOps.

Surveillance de la capacité

Les métriques de stockage stockent uniquement les métriques de capacité pour le service blob, car les objets blob représentent généralement la plus grande proportion des données stockées (au moment de l’écriture, il n’est pas possible d’utiliser des métriques de stockage pour surveiller la capacité de vos tables et files d’attente). Vous trouverez ces données dans la $MetricsCapacityBlob table si vous avez activé la surveillance pour le service Blob. Les métriques de stockage enregistrent ces données une fois par jour, et vous pouvez utiliser la valeur de RowKey pour déterminer si la ligne contient une entité liée aux données utilisateur (valeur data) ou aux données d’analyse (valeur analytics). Chaque entité stockée contient des informations sur la quantité de stockage utilisée (Capacity mesurée en octets) et le nombre actuel de conteneurs (ContainerCount) et d’objets blob (ObjectCount) utilisés dans le compte de stockage. Pour plus d’informations sur les métriques de capacité stockées dans la $MetricsCapacityBlob table, consultez Storage Analytics Schéma de table de métriques.

Remarque

Vous devez surveiller ces valeurs pour un avertissement précoce indiquant que vous approchez des limites de capacité de votre compte de stockage. Dans le Portail Azure, vous pouvez ajouter des règles d’alerte pour vous avertir si l’utilisation agrégée du stockage dépasse ou tombe en dessous des seuils que vous spécifiez.

Pour estimer la taille de différents objets de stockage tels que les objets blob, consultez le billet de blog Understanding Azure Storage Billing – Bandwidth, Transactions, and Capacity.

Surveillance de la disponibilité

Vous devez surveiller la disponibilité des services de stockage dans votre compte de stockage en surveillant la valeur dans la Availability colonne dans les tables de métriques horaires ou minutes : $MetricsHourPrimaryTransactionsBlob, $MetricsHourPrimaryTransactionsTable, $MetricsHourPrimaryTransactionsQueue, $MetricsMinutePrimaryTransactionsBlob$MetricsMinutePrimaryTransactionsTable, , $MetricsMinutePrimaryTransactionsQueue$MetricsCapacityBlob. La Availability colonne contient une valeur de pourcentage qui indique la disponibilité du service ou de l’opération d’API représentée par la ligne (indique RowKey si la ligne contient des métriques pour le service dans son ensemble ou pour une opération d’API spécifique).

Toute valeur inférieure à 100 % indique que certaines demandes de stockage échouent. Vous pouvez voir pourquoi elles échouent en examinant les autres colonnes dans les données de métriques qui indiquent le nombre de demandes avec différents types d’erreur, tels que ServerTimeoutError. Vous devez vous attendre à une Availability baisse temporaire en dessous de 100 % pour des raisons telles que des délais d’expiration temporaires du serveur pendant que le service déplace les partitions pour mieux équilibrer la charge des demandes ; la logique de nouvelle tentative dans votre application cliente doit gérer ces conditions intermittentes. L’article Storage Analytics Opérations journalisées et messages d’état répertorie les types de transactions que les métriques de stockage incluent dans son Availability calcul.

Dans le Portail Azure, vous pouvez ajouter des règles d’alerte pour vous avertir si Availability pour un service tombe en dessous d’un seuil que vous spécifiez.

La section Conseils de résolution des problèmes de ce guide décrit certains problèmes courants liés à la disponibilité du service de stockage.

Surveillance des performances

Pour surveiller les performances des services de stockage, vous pouvez utiliser les métriques suivantes des tables de métriques horaires et minutes.

  • Les valeurs des AverageE2ELatency colonnes et AverageServerLatency indiquent le temps moyen que le service de stockage ou le type d’opération d’API prend pour traiter les demandes. AverageE2ELatency est une mesure de latence de bout en bout qui inclut le temps nécessaire pour lire la demande et envoyer la réponse en plus du temps nécessaire pour traiter la demande (inclut donc la latence réseau une fois que la requête atteint le service de stockage) ; AverageServerLatency est une mesure du temps de traitement et exclut donc toute latence réseau liée à la communication avec le client. Consultez la section Metrics show high AverageE2ELatency and low AverageServerLatency plus loin dans ce guide pour savoir pourquoi il peut y avoir une différence significative entre ces deux valeurs.
  • Les valeurs des TotalIngress colonnes et TotalEgress indiquent la quantité totale de données, en octets, entrantes et sortantes de votre service de stockage ou via un type d’opération API spécifique.
  • Les valeurs de la TotalRequests colonne indiquent le nombre total de demandes reçues par le service de stockage d’une opération d’API. TotalRequests est le nombre total de demandes reçues par le service de stockage.

En règle générale, vous surveillez les modifications inattendues apportées à l’une de ces valeurs, car cela indique que vous rencontrez un problème qui nécessite une investigation.

Dans la Portail Azure, vous pouvez ajouter des règles d’alerte pour vous avertir si des métriques de performances pour ce service sont inférieures ou supérieures à un seuil que vous spécifiez.

La section Conseils de résolution des problèmes de ce guide décrit certains problèmes courants liés aux performances du service de stockage.

Diagnostic des problèmes de stockage

Vous pouvez prendre connaissance d’un problème ou d’un problème dans votre application de plusieurs façons, notamment :

  • Défaillance majeure qui provoque le blocage ou l’arrêt du fonctionnement de l’application.
  • Modifications significatives par rapport aux valeurs de base dans les métriques que vous surveillez, comme décrit dans la section précédente Surveillance de votre service de stockage.
  • Signale des utilisateurs de votre application qu’une opération particulière n’a pas été effectuée comme prévu ou qu’une fonctionnalité ne fonctionne pas.
  • Erreurs générées dans votre application qui apparaissent dans les fichiers journaux ou par le biais d’une autre méthode de notification.

En règle générale, les problèmes liés aux services de stockage Azure appartiennent à l’une des quatre grandes catégories suivantes :

  • Votre application présente un problème de performances, signalé par vos utilisateurs ou révélé par les modifications apportées aux métriques de performances.
  • Il existe un problème avec l’infrastructure de stockage Azure dans une ou plusieurs régions.
  • Votre application rencontre une erreur, signalée par vos utilisateurs ou révélée par une augmentation de l’une des métriques de nombre d’erreurs que vous surveillez.
  • Pendant le développement et les tests, vous utilisez peut-être l’émulateur de stockage local ; vous pouvez rencontrer des problèmes liés spécifiquement à l’utilisation de l’émulateur de stockage.

Les sections suivantes décrivent les étapes à suivre pour diagnostiquer et résoudre les problèmes dans chacune de ces quatre catégories. La section Conseils de résolution des problèmes plus loin dans ce guide fournit plus de détails sur certains problèmes courants que vous pouvez rencontrer.

État des services problèmes

État des services problèmes sont généralement hors de votre contrôle. Le Portail Azure fournit des informations sur les problèmes en cours avec les services Azure, y compris les services de stockage. Si vous avez choisi Read-Access Geo-Redundant Stockage lors de la création de votre compte de stockage, si vos données deviennent indisponibles dans l’emplacement principal, votre application peut basculer temporairement vers la copie en lecture seule dans l’emplacement secondaire. Pour lire à partir de la base de données secondaire, votre application doit être en mesure de basculer entre l’utilisation des emplacements de stockage principal et secondaire et de fonctionner en mode de fonctionnalités réduites avec des données en lecture seule. Les bibliothèques clientes de stockage Azure vous permettent de définir une stratégie de nouvelle tentative qui peut lire à partir du stockage secondaire en cas d’échec d’une lecture à partir du stockage principal. Votre application doit également savoir que les données de l’emplacement secondaire sont finalement cohérentes. Pour plus d’informations, consultez le billet de blog Options de redondance du stockage Azure et Stockage géoredondant avec accès en lecture.

Problèmes de performances

Les performances d’une application peuvent être subjectives, en particulier du point de vue de l’utilisateur. Par conséquent, il est important d’avoir des métriques de base disponibles pour vous aider à identifier les cas où il peut y avoir un problème de performances. De nombreux facteurs peuvent affecter les performances d’un service de stockage Azure du point de vue de l’application cliente. Ces facteurs peuvent fonctionner dans le service de stockage, le client ou l’infrastructure réseau ; par conséquent, il est important d’avoir une stratégie pour identifier l’origine du problème de performances.

Une fois que vous avez identifié l’emplacement probable de la cause du problème de performances à partir des métriques, vous pouvez utiliser les fichiers journaux pour trouver des informations détaillées pour diagnostiquer et résoudre le problème plus en détail.

La section Conseils de résolution des problèmes plus loin dans ce guide fournit plus d’informations sur certains problèmes courants liés aux performances que vous pouvez rencontrer.

Diagnostic des erreurs

Les utilisateurs de votre application peuvent vous informer des erreurs signalées par l’application cliente. Les métriques de stockage enregistrent également le nombre de différents types d’erreurs de vos services de stockage, tels que NetworkError, ClientTimeoutError ou AuthorizationError. Bien que les métriques de stockage enregistrent uniquement le nombre de différents types d’erreurs, vous pouvez obtenir plus de détails sur les demandes individuelles en examinant les journaux côté serveur, côté client et réseau. En règle générale, le code status HTTP retourné par le service de stockage donne une indication de la raison de l’échec de la requête.

Remarque

N’oubliez pas que vous devez vous attendre à voir des erreurs intermittentes : par exemple, des erreurs dues à des conditions réseau temporaires ou des erreurs d’application.

Les ressources suivantes sont utiles pour comprendre les status et les codes d’erreur liés au stockage :

Problèmes liés à l’émulateur de stockage

Le Kit de développement logiciel (SDK) Azure inclut un émulateur de stockage que vous pouvez exécuter sur une station de travail de développement. Cet émulateur simule la plupart du comportement des services de stockage Azure et est utile pendant le développement et les tests, ce qui vous permet d’exécuter des applications qui utilisent les services de stockage Azure sans avoir besoin d’un abonnement Azure et d’un compte de stockage Azure.

La section Conseils de résolution des problèmes de ce guide décrit certains problèmes courants rencontrés à l’aide de l’émulateur de stockage.

Outils de journalisation du stockage

La journalisation du stockage fournit une journalisation côté serveur des demandes de stockage dans votre compte de stockage Azure. Pour plus d’informations sur l’activation de la journalisation côté serveur et l’accès aux données de journal, consultez Activation de la journalisation du stockage et accès aux données de journal.

La bibliothèque cliente de stockage pour .NET vous permet de collecter des données de journal côté client relatives aux opérations de stockage effectuées par votre application. Pour plus d’informations, consultez Journalisation côté client avec la bibliothèque cliente de stockage .NET.

Remarque

Dans certains cas (par exemple, les échecs d’autorisation SAP), un utilisateur peut signaler une erreur pour laquelle vous ne pouvez trouver aucune donnée de demande dans les journaux de stockage côté serveur. Vous pouvez utiliser les fonctionnalités de journalisation de la bibliothèque cliente de stockage pour déterminer si la cause du problème est sur le client ou utiliser les outils de surveillance réseau pour examiner le réseau.

Utilisation des outils de journalisation réseau

Vous pouvez capturer le trafic entre le client et le serveur pour fournir des informations détaillées sur les données que le client et le serveur échangent et sur les conditions réseau sous-jacentes. Les outils de journalisation réseau utiles sont les suivants :

Dans de nombreux cas, les données de journalisation du stockage et de la bibliothèque cliente de stockage sont suffisantes pour diagnostiquer un problème, mais dans certains scénarios, vous aurez peut-être besoin des informations plus détaillées que ces outils de journalisation réseau peuvent fournir. Par exemple, l’utilisation de Fiddler pour afficher les messages HTTP et HTTPS vous permet d’afficher les données d’en-tête et de charge utile envoyées vers et à partir des services de stockage, ce qui vous permet d’examiner comment une application cliente retente les opérations de stockage. Les analyseurs de protocole tels que Wireshark fonctionnent au niveau des paquets, ce qui vous permet d’afficher les données TCP, ce qui vous permet de résoudre les problèmes de perte de paquets et de connectivité.

Suivi de bout en bout

Le suivi de bout en bout à l’aide de divers fichiers journaux est une technique utile pour examiner les problèmes potentiels. Vous pouvez utiliser les informations de date/heure de vos données de métriques pour indiquer où commencer à rechercher dans les fichiers journaux des informations détaillées pour vous aider à résoudre le problème.

Corrélation des données de journal

Lors de l’affichage des journaux à partir d’applications clientes, de traces réseau et de journalisation du stockage côté serveur, il est essentiel de pouvoir mettre en corrélation les demandes entre les différents fichiers journaux. Les fichiers journaux incluent un certain nombre de champs différents qui sont utiles en tant qu’identificateurs de corrélation. L’ID de demande client est le champ le plus utile à utiliser pour mettre en corrélation les entrées dans les différents journaux. Toutefois, il peut parfois être utile d’utiliser l’ID de demande de serveur ou les horodatages. Les sections suivantes fournissent plus de détails sur ces options.

ID de demande client

La bibliothèque cliente de stockage génère automatiquement un ID de demande client unique pour chaque requête.

  • Dans le journal côté client créé par la bibliothèque cliente de stockage, l’ID de demande client apparaît dans le Client Request ID champ de chaque entrée de journal relative à la demande.
  • Dans une trace réseau telle que celle capturée par Fiddler, l’ID de demande client est visible dans les messages de demande en tant que valeur d’en-tête x-ms-client-request-id HTTP.
  • Dans le journal de journalisation du stockage côté serveur, l’ID de demande client apparaît dans la colonne ID de demande client.

Remarque

Il est possible que plusieurs demandes partagent le même ID de demande client, car le client peut attribuer cette valeur (bien que la bibliothèque cliente de stockage attribue automatiquement une nouvelle valeur). Lorsque le client effectue une nouvelle tentative, toutes les tentatives partagent le même ID de demande client. Dans le cas d’un lot envoyé à partir du client, le lot a un ID de demande client unique.

ID de demande de serveur

Le service de stockage génère automatiquement des ID de requête de serveur.

  • Dans le journal de journalisation du stockage côté serveur, l’ID de demande de serveur apparaît dans la Request ID header colonne .
  • Dans une trace réseau telle que celle capturée par Fiddler, l’ID de requête du serveur apparaît dans les messages de réponse en tant que valeur d’en-tête x-ms-request-id HTTP.
  • Dans le journal côté client créé par la bibliothèque cliente de stockage, l’ID de demande de serveur apparaît dans la Operation Text colonne de l’entrée de journal affichant les détails de la réponse du serveur.

Remarque

Le service de stockage attribue toujours un ID de demande de serveur unique à chaque requête qu’il reçoit, de sorte que chaque nouvelle tentative du client et chaque opération incluse dans un lot a un ID de demande de serveur unique.

L’exemple de code ci-dessous montre comment utiliser un ID de demande client personnalisé.

var connectionString = Constants.connectionString;

BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

BlobContainerClient blobContainerClient = blobServiceClient.GetBlobContainerClient("demcontainer");

BlobClient blobClient = blobContainerClient.GetBlobClient("testImage.jpg");

string clientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());

using (HttpPipeline.CreateClientRequestIdScope(clientRequestID))
{
    BlobDownloadInfo download = blobClient.Download();

    using (FileStream downloadFileStream = File.OpenWrite("C:\\testImage.jpg"))
    {
        download.Content.CopyTo(downloadFileStream);
        downloadFileStream.Close();
    }
}

Timestamps

Vous pouvez également utiliser des horodatages pour localiser les entrées de journal associées, mais faites attention à toute asymétrie de l’horloge entre le client et le serveur qui peut exister. Recherche plus ou moins 15 minutes pour les entrées côté serveur correspondantes en fonction de l’horodatage sur le client. N’oubliez pas que les métadonnées d’objet blob pour les objets blob contenant des métriques indiquent l’intervalle de temps pour les métriques stockées dans l’objet blob. Cet intervalle de temps est utile si vous avez de nombreux objets blob de métriques pour la même minute ou la même heure.

Conseils de résolution des problèmes

Cette section vous aidera à diagnostiquer et à résoudre certains des problèmes courants que votre application peut rencontrer lors de l’utilisation des services de stockage Azure. Utilisez la liste ci-dessous pour rechercher les informations relatives à votre problème spécifique.

Arbre de décision de résolution des problèmes

Votre problème est-il lié aux performances de l’un des services de stockage ?

Votre problème est-il lié à la disponibilité de l’un des services de stockage ?

Votre application cliente reçoit-elle une réponse HTTP 4XX (par exemple, 404) d’un service de stockage ?

Les métriques montrent des entrées de journal d’analyse ou percentSuccess faibles ont des opérations avec des status de transaction de ClientOtherErrors.

Les métriques de capacité indiquent une augmentation inattendue de l’utilisation de la capacité de stockage.

Votre problème provient de l’utilisation de l’émulateur de stockage pour le développement ou le test.

Vous rencontrez des problèmes lors de l’installation du Kit de développement logiciel (SDK) Azure pour .NET.

Vous rencontrez un autre problème avec un service de stockage.

Les métriques indiquent une valeur AverageE2ELatency élevée et une latence moyenne MoyenneServeur faible

L’illustration ci-dessous de l’outil de surveillance Portail Azure montre un exemple où averageE2ELatency est considérablement plus élevé que averageServerLatency.

Illustration de la Portail Azure qui montre un exemple où la valeur AverageE2ELatency est considérablement supérieure à averageServerLatency.

Le service de stockage calcule uniquement la métrique AverageE2ELatency pour les requêtes réussies et, contrairement à AverageServerLatency, inclut le temps nécessaire au client pour envoyer les données et recevoir un accusé de réception du service de stockage. Par conséquent, une différence entre AverageE2ELatency et AverageServerLatency peut être due à la lenteur de la réponse de l’application cliente ou à des conditions sur le réseau.

Remarque

Vous pouvez également afficher E2ELatency et ServerLatency pour les opérations de stockage individuelles dans les données du journal de journalisation du stockage.

Examen des problèmes de performances du client

Les raisons possibles pour lesquelles le client répond lentement sont notamment le fait de disposer d’un nombre limité de connexions ou de threads disponibles ou d’une insuffisance de ressources telles que le processeur, la mémoire ou la bande passante réseau. Vous pouvez résoudre le problème en modifiant le code client pour qu’il soit plus efficace (par exemple, en utilisant des appels asynchrones au service de stockage) ou en utilisant une machine virtuelle plus grande (avec plus de cœurs et plus de mémoire).

Pour les services de table et de file d’attente, l’algorithme Nagle peut également entraîner une latence AverageE2ELatency élevée par rapport à AverageServerLatency. Pour plus d’informations, consultez L’algorithme de Nagle n’est pas convivial pour les petites demandes. Vous pouvez désactiver l’algorithme Nagle dans le code à l’aide de la ServicePointManager classe dans l’espace de System.Net noms . Vous devez le faire avant d’effectuer des appels aux services de table ou de file d’attente dans votre application, car cela n’affecte pas les connexions déjà ouvertes. L’exemple suivant provient de la Application_Start méthode dans un rôle de travail.

var connectionString = Constants.connectionString;

QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);

ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

Vous devez case activée les journaux côté client pour voir le nombre de demandes que votre application cliente envoie et case activée pour général. Goulots d’étranglement des performances liés au réseau dans votre client, tels que le processeur, le garbage collection .NET, l’utilisation du réseau ou la mémoire. Comme point de départ pour la résolution des problèmes des applications clientes .NET, consultez Débogage, suivi et profilage.

Examen des problèmes de latence réseau

En règle générale, la latence élevée de bout en bout causée par le réseau est due à des conditions temporaires. Vous pouvez examiner les problèmes réseau temporaires et persistants, tels que les paquets supprimés, à l’aide d’outils tels que Wireshark.

Pour plus d’informations sur l’utilisation de Wireshark pour résoudre les problèmes réseau, consultez Annexe 2 : Utilisation de Wireshark pour capturer le trafic réseau.

Les métriques indiquent une latence MoyenneE2ELatency faible et une latence MoyenneServerLatency faible, mais le client rencontre une latence élevée

Dans ce scénario, la cause la plus probable est un retard dans les demandes de stockage qui atteignent le service de stockage. Vous devez examiner pourquoi les demandes du client ne sont pas envoyées au service blob.

L’une des raisons possibles pour lesquelles le client retarde l’envoi des demandes est qu’il existe un nombre limité de connexions ou de threads disponibles.

En outre, case activée si le client effectue plusieurs nouvelles tentatives et examinez la raison si c’est le cas. Pour déterminer si le client effectue plusieurs nouvelles tentatives, vous pouvez :

  • Examinez les journaux Storage Analytics. Si plusieurs nouvelles tentatives sont effectuées, vous verrez plusieurs opérations avec le même ID de demande client, mais avec des ID de requête de serveur différents.
  • Examinez les journaux du client. La journalisation détaillée indique qu’une nouvelle tentative s’est produite.
  • Déboguez votre code et case activée les propriétés de l’objet OperationContext associé à la requête. Si l’opération a fait une nouvelle tentative, la RequestResults propriété inclut plusieurs ID de demande de serveur uniques. Vous pouvez également case activée les heures de début et de fin de chaque requête. Pour plus d’informations, consultez l’exemple de code dans la section ID de demande de serveur.

S’il n’y a aucun problème dans le client, vous devez examiner les problèmes réseau potentiels tels que la perte de paquets. Vous pouvez utiliser des outils tels que Wireshark pour examiner les problèmes réseau.

Pour plus d’informations sur l’utilisation de Wireshark pour résoudre les problèmes réseau, consultez Annexe 2 : Utilisation de Wireshark pour capturer le trafic réseau.

Les métriques indiquent une latence moyenne moyenne élevée

Dans le cas d’une latence averageServerLatency élevée pour les demandes de téléchargement d’objets blob, vous devez utiliser les journaux de journalisation du stockage pour voir s’il y a des demandes répétées pour le même objet blob (ou ensemble d’objets blob). Pour les demandes de chargement d’objets blob, vous devez examiner la taille de bloc utilisée par le client (par exemple, les blocs d’une taille inférieure à 64 Ko peuvent entraîner des surcharges, sauf si les lectures sont également en moins de 64 000 blocs) et si plusieurs clients chargent des blocs dans le même objet blob en parallèle. Vous devez également case activée les métriques par minute pour les pics du nombre de demandes qui entraînent un dépassement des objectifs d’extensibilité par seconde. Pour plus d’informations, consultez Les métriques affichent une augmentation de PercentTimeoutError.

Si vous voyez une latence moyenne élevée pour les demandes de téléchargement d’objets blob lorsqu’il y a des demandes répétées pour le même objet blob ou le même ensemble d’objets blob, envisagez de mettre en cache ces objets blob à l’aide d’Azure Cache ou du réseau de distribution de contenu (CDN) Azure. Pour les demandes de chargement, vous pouvez améliorer le débit en utilisant une plus grande taille de bloc. Pour les requêtes vers des tables, il est également possible d’implémenter la mise en cache côté client sur les clients qui effectuent les mêmes opérations de requête et où les données ne changent pas fréquemment.

Les valeurs AverageServerLatency élevées peuvent également être un symptôme de tables ou de requêtes mal conçues qui entraînent des opérations d’analyse ou qui suivent l’anti-modèle append/prepend. Pour plus d’informations, consultez Les métriques indiquent une augmentation de PercentThrottlingError.

Remarque

Vous trouverez une liste de contrôle complète des performances ici : Stockage Microsoft Azure liste de contrôle des performances et de l’extensibilité.

Vous rencontrez des retards inattendus dans la remise des messages dans une file d’attente

Si vous rencontrez un délai entre le moment où une application ajoute un message à une file d’attente et le moment où il devient disponible pour la lecture à partir de la file d’attente, effectuez les étapes suivantes pour diagnostiquer le problème :

  • Vérifiez que l’application ajoute correctement les messages à la file d’attente. Vérifiez que l’application n’essaie pas plusieurs fois la AddMessage méthode avant de réussir. Les journaux de la bibliothèque cliente de stockage affichent toutes les tentatives répétées d’opérations de stockage.
  • Vérifiez qu’il n’y a pas d’asymétrie d’horloge entre le rôle de travail qui ajoute le message à la file d’attente et le rôle de travail qui lit le message à partir de la file d’attente. Une asymétrie d’horloge donne l’impression qu’il y a un délai de traitement.
  • Vérifiez si le rôle de travail qui lit les messages de la file d’attente échoue. Si un client de file d’attente appelle la GetMessage méthode mais ne parvient pas à répondre avec un accusé de réception, le message reste invisible dans la file d’attente jusqu’à l’expiration de la invisibilityTimeout période. À ce stade, le message est à nouveau disponible pour traitement.
  • Vérifiez si la longueur de la file d’attente augmente au fil du temps. Cela peut se produire si vous n’avez pas suffisamment de workers disponibles pour traiter tous les messages que les autres workers placent dans la file d’attente. En outre, case activée les métriques pour voir si les demandes de suppression échouent et le nombre de messages de suppression de la file d’attente, ce qui peut indiquer des échecs répétés de tentatives de suppression du message.
  • Examinez les journaux de journalisation du stockage pour rechercher les opérations de file d’attente qui ont des valeurs E2ELatency et ServerLatency plus élevées que prévu sur une période plus longue que d’habitude.

Les métriques indiquent une augmentation de PercentThrottlingError

Des erreurs de limitation se produisent lorsque vous dépassez les objectifs d’extensibilité d’un service de stockage. Le service de stockage limite pour garantir qu’aucun client ou locataire ne peut utiliser le service au détriment d’autres utilisateurs. Pour plus d’informations, consultez Objectifs d’extensibilité et de performances pour les comptes de stockage standard pour plus d’informations sur les objectifs de scalabilité pour les comptes de stockage et les objectifs de performances pour les partitions au sein des comptes de stockage.

Si la métrique PercentThrottlingError indique une augmentation du pourcentage de demandes qui échouent avec une erreur de limitation, vous devez examiner l’un des deux scénarios suivants :

Une augmentation de PercentThrottlingError se produit souvent en même temps qu’une augmentation du nombre de demandes de stockage ou lorsque vous testez initialement votre application. Cela peut également se manifester dans le client sous la forme de messages HTTP status d’opérations « 503 Server Busy » ou « 500 Operation Timeout ».

Augmentation temporaire de PercentThrottlingError

Si vous constatez des pics dans la valeur de PercentThrottlingError qui coïncident avec des périodes d’activité élevée pour l’application, vous pouvez implémenter une stratégie d’interruption exponentielle (non linéaire) pour les nouvelles tentatives dans votre client. Les nouvelles tentatives d’arrêt réduisent la charge immédiate sur la partition et aident votre application à atténuer les pics de trafic. Pour plus d’informations sur la façon d’implémenter des stratégies de nouvelle tentative à l’aide de la bibliothèque cliente de stockage, consultez l’espace de noms Microsoft.Azure.Storage.RetryPolicies.

Remarque

Vous pouvez également voir des pics dans la valeur de PercentThrottlingError qui ne coïncident pas avec des périodes d’activité élevée pour l’application. La cause la plus probable est le déplacement des partitions par le service de stockage pour améliorer l’équilibrage de charge.

Augmentation permanente de PercentThrottlingError

Si vous voyez une valeur constamment élevée pour PercentThrottlingError suite à une augmentation permanente de vos volumes de transactions ou lorsque vous effectuez vos tests de charge initiaux sur votre application, vous devez évaluer la façon dont votre application utilise les partitions de stockage et si elle s’approche des cibles de scalabilité pour un compte de stockage. Par exemple, si vous voyez des erreurs de limitation dans une file d’attente (qui compte comme une seule partition), envisagez d’utiliser des files d’attente supplémentaires pour répartir les transactions sur plusieurs partitions. Si vous voyez des erreurs de limitation sur une table, vous devez envisager d’utiliser un schéma de partitionnement différent pour répartir vos transactions sur plusieurs partitions à l’aide d’un plus large éventail de valeurs de clé de partition. L’une des causes courantes de ce problème est l’anti-modèle ajouté/ajouté dans lequel vous sélectionnez la date comme clé de partition, puis toutes les données d’un jour particulier sont écrites dans une seule partition : en cas de charge, cela peut entraîner un goulot d’étranglement en écriture. Envisagez une conception de partitionnement différente ou évaluez si l’utilisation du stockage d’objets blob peut être une meilleure solution. En outre, case activée si la limitation se produit en raison de pics dans votre trafic et examinez les moyens de lisser votre modèle de requêtes.

Si vous distribuez vos transactions sur plusieurs partitions, vous devez toujours connaître les limites d’extensibilité définies pour le compte de stockage. Par exemple, si vous avez utilisé dix files d’attente, chacune traitant le maximum de 2 000 messages de 1 Ko par seconde, vous êtes à la limite globale de 20 000 messages par seconde pour le compte de stockage. Si vous devez traiter plus de 20 000 entités par seconde, envisagez d’utiliser plusieurs comptes de stockage. Vous devez également garder à l’esprit que la taille de vos requêtes et entités a un impact sur le moment où le service de stockage limite vos clients. Si vous avez des requêtes et des entités plus volumineuses, vous risquez d’être limité plus tôt.

Une conception de requête inefficace peut également vous amener à atteindre les limites de scalabilité pour les partitions de table. Par exemple, une requête avec un filtre qui ne sélectionne qu’un pour cent des entités dans une partition, mais qui analyse toutes les entités d’une partition doit accéder à chaque entité. Chaque lecture d’entité est comptabilisée dans le nombre total de transactions dans cette partition ; par conséquent, vous pouvez facilement atteindre les cibles d’extensibilité.

Remarque

Vos tests de performances doivent révéler toute conception de requête inefficace dans votre application.

Les métriques indiquent une augmentation de PercentTimeoutError

Vos métriques indiquent une augmentation de PercentTimeoutError pour l’un de vos services de stockage. En même temps, le client reçoit un volume élevé de messages http status « 500 délai d’expiration de l’opération » provenant des opérations de stockage.

Remarque

Vous pouvez voir des erreurs de délai d’expiration temporaires lorsque le service de stockage équilibre la charge des requêtes en déplaçant une partition vers un nouveau serveur.

La métrique PercentTimeoutError est une agrégation des métriques suivantes : ClientTimeoutError, AnonymousClientTimeoutError, SASClientTimeoutError, ServerTimeoutError, AnonymousServerTimeoutError et SASServerTimeoutError.

Les délais d’expiration du serveur sont causés par une erreur sur le serveur. Les délais d’expiration du client se produisent parce qu’une opération sur le serveur a dépassé le délai d’expiration spécifié par le client ; Par exemple, un client utilisant la bibliothèque cliente de stockage peut définir un délai d’expiration pour une opération à l’aide de la ServerTimeout propriété de la QueueRequestOptions classe .

Les délais d’expiration du serveur indiquent un problème avec le service de stockage qui nécessite une investigation plus approfondie. Vous pouvez utiliser des métriques pour voir si vous atteignez les limites d’extensibilité du service et identifier les pics de trafic susceptibles d’être à l’origine de ce problème. Si le problème est intermittent, il peut être dû à l’activité d’équilibrage de charge dans le service. Si le problème est persistant et n’est pas dû au fait que votre application atteint les limites de scalabilité du service, vous devez soulever un problème de support. Pour les délais d’expiration du client, vous devez déterminer si le délai d’expiration est défini sur une valeur appropriée dans le client et modifier la valeur de délai d’expiration définie dans le client ou examiner comment vous pouvez améliorer les performances des opérations dans le service de stockage, par exemple, en optimisant vos requêtes de table ou en réduisant la taille de vos messages.

Les métriques indiquent une augmentation de PercentNetworkError

Vos métriques indiquent une augmentation de PercentNetworkError pour l’un de vos services de stockage. La métrique PercentNetworkError est une agrégation des métriques suivantes : NetworkError, AnonymousNetworkError et SASNetworkError. Celles-ci se produisent lorsque le service de stockage détecte une erreur réseau lorsque le client effectue une demande de stockage.

La cause la plus courante de cette erreur est qu’un client se déconnecte avant l’expiration d’un délai d’expiration dans le service de stockage. Examinez le code de votre client pour comprendre pourquoi et quand le client se déconnecte du service de stockage. Vous pouvez également utiliser Wireshark ou Tcping pour examiner les problèmes de connectivité réseau à partir du client. Ces outils sont décrits dans les Annexes.

Le client reçoit des messages HTTP 403 (Interdit)

Si votre application cliente génère des erreurs HTTP 403 (Interdit), une cause probable est que le client utilise une signature d’accès partagé (SAP) expirée lorsqu’il envoie une demande de stockage (bien que d’autres causes possibles incluent l’asymétrie de l’horloge, les clés non valides et les en-têtes vides). Si une clé SAS expirée en est la cause, vous ne verrez aucune entrée dans les données du journal de journalisation du stockage côté serveur. Le tableau suivant présente un exemple du journal côté client généré par la bibliothèque cliente de stockage qui illustre ce problème :

Source Verbosité Verbosité ID de demande client Texte de l’opération
Microsoft.Azure.Storage Information 3 85d077ab-... Starting operation with location Primary per location mode PrimaryOnly.
Microsoft.Azure.Storage Information 3 85d077ab -... Starting synchronous request to https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Synchronous_request.
Microsoft.Azure.Storage Information 3 85d077ab -... Waiting for response.
Microsoft.Azure.Storage Avertissement 2 85d077ab -... Exception thrown while waiting for response: The remote server returned an error: (403) Forbidden.
Microsoft.Azure.Storage Information 3 85d077ab -... Response received. Status code = 403, Request ID = <Request ID>, Content-MD5 = , ETag = .
Microsoft.Azure.Storage Avertissement 2 85d077ab -... Exception thrown during the operation: The remote server returned an error: (403) Forbidden..
Microsoft.Azure.Storage Information 3 85d077ab -... Checking if the operation should be retried. Retry count = 0, HTTP status code = 403, Exception = The remote server returned an error: (403) Forbidden..
Microsoft.Azure.Storage Information 3 85d077ab -... The next location has been set to Primary, based on the location mode.
Microsoft.Azure.Storage Erreur 1 85d077ab -... Retry policy did not allow for a retry. Failing with The remote server returned an error: (403) Forbidden.

Dans ce scénario, vous devez examiner pourquoi le jeton SAP expire avant que le client n’envoie le jeton au serveur :

  • En règle générale, vous ne devez pas définir une heure de début lorsque vous créez une signature d’accès partagé pour un client à utiliser immédiatement. S’il existe de petites différences d’horloge entre l’hôte générant la sape à l’aide de l’heure actuelle et le service de stockage, il est possible que le service de stockage reçoive une signature d’accès partagé qui n’est pas encore valide.
  • Ne définissez pas un délai d’expiration très court sur une signature d’accès partagé. Là encore, de petites différences d’horloge entre l’hôte générant la SAP et le service de stockage peuvent entraîner l’expiration d’une signature d’accès partagé plus tôt que prévu.
  • Le paramètre de version dans la clé SAS (par exemple, sv=2015-04-05) correspond-il à la version de la bibliothèque cliente de stockage que vous utilisez ? Nous vous recommandons de toujours utiliser la dernière version de la bibliothèque cliente de stockage.
  • Si vous régénérez vos clés d’accès de stockage, tous les jetons SAP existants peuvent être invalidés. Ce problème peut survenir si vous générez des jetons SAP avec un délai d’expiration long pour les applications clientes à mettre en cache.

Si vous utilisez la bibliothèque cliente de stockage pour générer des jetons SAS, il est facile de générer un jeton valide. Toutefois, si vous utilisez l’API REST de stockage et que vous construisez les jetons SAP manuellement, consultez Délégation de l’accès avec une signature d’accès partagé.

Le client reçoit des messages HTTP 404 (introuvable)

Si l’application cliente reçoit un message HTTP 404 (introuvable) du serveur, cela implique que l’objet que le client tentait d’utiliser (par exemple, une entité, une table, un objet blob, un conteneur ou une file d’attente) n’existe pas dans le service de stockage. Il existe un certain nombre de raisons possibles à cela, telles que :

Le client ou un autre processus a précédemment supprimé l’objet

Dans les scénarios où le client tente de lire, mettre à jour ou supprimer des données dans un service de stockage, il est généralement facile d’identifier dans les journaux côté serveur une opération précédente qui a supprimé l’objet en question du service de stockage. Souvent, les données de journal indiquent qu’un autre utilisateur ou processus a supprimé l’objet. Dans le journal de journalisation du stockage côté serveur, les colonnes operation-type et requested-object-key indiquent quand un client a supprimé un objet.

Dans le scénario où un client tente d’insérer un objet, la raison pour laquelle cela entraîne une réponse HTTP 404 (Introuvable) n’est peut-être pas immédiatement évidente, étant donné que le client crée un nouvel objet. Toutefois, si le client crée un objet blob, il doit être en mesure de trouver le conteneur d’objets blob. Si le client crée un message, il doit être en mesure de trouver une file d’attente. Et si le client ajoute une ligne, il doit être en mesure de trouver la table.

Vous pouvez utiliser le journal côté client de la bibliothèque cliente de stockage pour obtenir une compréhension plus détaillée du moment où le client envoie des demandes spécifiques au service de stockage.

Le journal côté client suivant généré par la bibliothèque cliente de stockage illustre le problème lorsque le client ne trouve pas le conteneur pour l’objet blob qu’il crée. Ce journal contient les détails des opérations de stockage suivantes :

ID de la demande Opération
07b26a5d-... DeleteIfExists pour supprimer le conteneur d’objets blob. Notez que cette opération inclut une HEAD demande de case activée pour l’existence du conteneur.
e2d06d78... CreateIfNotExists pour créer le conteneur d’objets blob. Notez que cette opération inclut une HEAD requête qui vérifie l’existence du conteneur. Retourne HEAD un message 404, mais continue.
de8b1c3c-... UploadFromStream pour créer l’objet blob. La PUT demande échoue avec un message 404.

Entrées de journal :

ID de la demande Texte de l’opération
07b26a5d-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
07b26a5d-... StringToSign = HEAD............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:11 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
07b26a5d-... Waiting for response.
07b26a5d-... Response received. Status code = 200, Request ID = eeead849-...Content-MD5 = , ETag = &quot;0x8D14D2DC63D059B&quot;.
07b26a5d-... Response headers were processed successfully, proceeding with the rest of the operation.
07b26a5d-... Downloading response body.
07b26a5d-... Operation completed successfully.
07b26a5d-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
07b26a5d-... StringToSign = DELETE............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
07b26a5d-... Waiting for response.
07b26a5d-... Response received. Status code = 202, Request ID = 6ab2a4cf-..., Content-MD5 = , ETag = .
07b26a5d-... Response headers were processed successfully, proceeding with the rest of the operation.
07b26a5d-... Downloading response body.
07b26a5d-... Operation completed successfully.
e2d06d78-... Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
e2d06d78-... StringToSign = HEAD............x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
e2d06d78-... Waiting for response.
de8b1c3c-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer/blobCreated.txt.
de8b1c3c-... StringToSign = PUT...64.qCmF+TQLPhq/YYK50mP9ZQ==........x-ms-blob-type:BlockBlob.x-ms-client-request-id:de8b1c3c-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer/blobCreated.txt.
de8b1c3c-... Preparing to write request data.
e2d06d78-... Exception thrown while waiting for response: The remote server returned an error: (404) Not Found..
e2d06d78-... Response received. Status code = 404, Request ID = 353ae3bc-..., Content-MD5 = , ETag = .
e2d06d78-... Response headers were processed successfully, proceeding with the rest of the operation.
e2d06d78-... Downloading response body.
e2d06d78-... Operation completed successfully.
e2d06d78-... Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
e2d06d78-... StringToSign = PUT...0.........x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
e2d06d78-... Waiting for response.
de8b1c3c-... Writing request data.
de8b1c3c-... Waiting for response.
e2d06d78-... Exception thrown while waiting for response: The remote server returned an error: (409) Conflict..
e2d06d78-... Response received. Status code = 409, Request ID = c27da20e-..., Content-MD5 = , ETag = .
e2d06d78-... Downloading error response body.
de8b1c3c-... Exception thrown while waiting for response: The remote server returned an error: (404) Not Found..
de8b1c3c-... Response received. Status code = 404, Request ID = 0eaeab3e-..., Content-MD5 = , ETag = .
de8b1c3c-... Exception thrown during the operation: The remote server returned an error: (404) Not Found..
de8b1c3c-... Retry policy did not allow for a retry. Failing with The remote server returned an error: (404) Not Found..
e2d06d78-... Retry policy did not allow for a retry. Failing with The remote server returned an error: (409) Conflict..

Dans cet exemple, le journal indique que le client entrelace les requêtes de la CreateIfNotExists méthode (ID de requête e2d06d78...) avec les requêtes de la UploadFromStream méthode (de8b1c3c-...). Cet entrelacement se produit car l’application cliente appelle ces méthodes de manière asynchrone. Modifiez le code asynchrone dans le client pour vous assurer qu’il crée le conteneur avant de tenter de charger des données dans un objet blob dans ce conteneur. Dans l’idéal, vous devez créer tous vos conteneurs à l’avance.

Problème d’autorisation de signature d’accès partagé (SAP)

Si l’application cliente tente d’utiliser une clé SAP qui n’inclut pas les autorisations nécessaires pour l’opération, le service de stockage retourne un message HTTP 404 (Introuvable) au client. En même temps, vous verrez également une valeur différente de zéro pour SASAuthorizationError dans les métriques.

Le tableau suivant présente un exemple de message de journal côté serveur à partir du fichier journal de journalisation du stockage :

Nom Valeur
Heure de début de la demande 2014-05-30T06 :17 :48.4473697Z
Type d’opération GetBlobProperties
Status de requête SASAuthorizationError
Code d’état HTTP 404
Type d’authentification Sas
Type de service Blob
URL de la demande https://domemaildist.blob.core.windows.net/azureimblobcontainer/blobCreatedViaSAS.txt
  ?sv=2014-02-14&sr=c&si=mypolicy&sig=XXXXX& ; api-version=2014-02-14
En-tête d’ID de requête <En-tête d’ID de requête>
ID de demande client <ID de demande client>

Examinez pourquoi votre application cliente tente d’effectuer une opération pour laquelle aucune autorisation n’a été accordée.

Le code JavaScript côté client n’a pas l’autorisation d’accéder à l’objet

Si vous utilisez un client JavaScript et que le service de stockage retourne des messages HTTP 404, vous case activée pour les erreurs JavaScript suivantes dans le navigateur :

SEC7120 : Origine http://localhost:56309 introuvable dans l’en-tête Access-Control-Allow-Origin.
SCRIPT7002 : XMLHttpRequest : erreur réseau 0x80070005, accès refusé.

Remarque

Vous pouvez utiliser les outils de développement F12 dans Internet Explorer pour suivre les messages échangés entre le navigateur et le service de stockage lorsque vous résolvez des problèmes JavaScript côté client.

Ces erreurs se produisent parce que le navigateur web implémente la même restriction de sécurité de stratégie d’origine qui empêche une page web d’appeler une API dans un domaine différent du domaine d’origine de la page.

Pour contourner le problème JavaScript, vous pouvez configurer cors (Cross-Origin Resource Sharing) pour le service de stockage auquel le client accède. Pour plus d’informations, consultez Prise en charge du partage de ressources cross-origin (CORS) pour les services de stockage Azure.

L’exemple de code suivant montre comment configurer votre service blob pour permettre à JavaScript s’exécutant dans le domaine Contoso d’accéder à un objet blob dans votre service de stockage d’objets blob :

var connectionString = Constants.connectionString;

 BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

 BlobServiceProperties sp = blobServiceClient.GetProperties();

 // Set the service properties.
 sp.DefaultServiceVersion = "2013-08-15";
 BlobCorsRule bcr = new BlobCorsRule();
 bcr.AllowedHeaders = "*";

 bcr.AllowedMethods = "GET,POST";
 bcr.AllowedOrigins = "http://www.contoso.com";
 bcr.ExposedHeaders = "x-ms-*";
 bcr.MaxAgeInSeconds = 5;
 sp.Cors.Clear();
 sp.Cors.Add(bcr);
 blobServiceClient.SetProperties(sp);

Réseau défaillant

Dans certains cas, la perte de paquets réseau peut entraîner le renvoi des messages HTTP 404 au client par le service de stockage. Par exemple, lorsque votre application cliente supprime une entité du service de table, vous voyez le client lever une exception de stockage signalant un message status « HTTP 404 (introuvable) » du service de table. Lorsque vous examinez la table dans le service de stockage de table, vous voyez que le service a supprimé l’entité comme demandé.

Les détails de l’exception dans le client incluent l’ID de demande (7e84f12d...) attribué par le service de table pour la requête. Vous pouvez utiliser ces informations pour localiser les détails de la demande dans les journaux de stockage côté serveur en effectuant une recherche dans la request-id-header colonne du fichier journal. Vous pouvez également utiliser les métriques pour identifier les défaillances de ce type, puis rechercher dans les fichiers journaux en fonction de l’heure à laquelle les métriques ont enregistré cette erreur. Cette entrée de journal indique que la suppression a échoué avec un message status « Erreur http (404) autre client ». La même entrée de journal inclut également l’ID de requête généré par le client dans la client-request-id colonne (813ea74f...).

Le journal côté serveur inclut également une autre entrée avec la même client-request-id valeur (813ea74f...) pour une opération de suppression réussie pour la même entité et à partir du même client. Cette opération de suppression réussie a eu lieu très peu de temps avant l’échec de la demande de suppression.

La cause la plus probable de ce scénario est que le client a envoyé une demande de suppression pour l’entité au service de table, qui a réussi mais n’a pas reçu d’accusé de réception du serveur (peut-être en raison d’un problème réseau temporaire). Le client a ensuite retenté automatiquement l’opération (à l’aide du même client-request-id), et cette nouvelle tentative a échoué, car l’entité avait déjà été supprimée.

Si ce problème se produit fréquemment, vous devez examiner pourquoi le client ne parvient pas à recevoir les accusés de réception du service de table. Si le problème est intermittent, vous devez intercepter l’erreur « HTTP (404) Introuvable » et la journaliser dans le client, mais autoriser le client à continuer.

Le client reçoit des messages HTTP 409 (conflit)

Le tableau suivant montre un extrait du journal côté serveur pour deux opérations clientes : DeleteIfExists suivie immédiatement du CreateIfNotExists même nom de conteneur d’objets blob. Chaque opération cliente entraîne deux requêtes envoyées au serveur, d’abord une GetContainerProperties demande de case activée si le conteneur existe, suivie de la DeleteContainer requête ou CreateContainer .

Timestamp Opération Résultat Nom du conteneur ID de demande client
05:10:13.7167225 GetContainerProperties 200 mmcont c9f52c89-...
05:10:13.8167325 DeleteContainer 202 mmcont c9f52c89-...
05:10:13.8987407 GetContainerProperties 404 mmcont bc881924-...
05:10:14.2147723 CreateContainer 409 mmcont bc881924-...

Le code de l’application cliente supprime, puis recrée immédiatement un conteneur d’objets blob avec le même nom : la CreateIfNotExists méthode (ID de requête client bc881924-...) finit par échouer avec l’erreur HTTP 409 (conflit). Lorsqu’un client supprime des conteneurs d’objets blob, des tables ou des files d’attente, il existe un bref délai avant que le nom ne soit à nouveau disponible.

L’application cliente doit utiliser des noms de conteneurs uniques chaque fois qu’elle crée de nouveaux conteneurs si le modèle de suppression/recréation est courant.

Les métriques indiquent que les entrées de journal PercentSuccess ou analytics faibles ont des opérations avec des status de transaction de ClientOtherErrors

La métrique PercentSuccess capture le pourcentage d’opérations qui ont réussi en fonction de leur code d’état HTTP. Les opérations avec des codes status 2XX sont considérées comme ayant réussi, tandis que les opérations avec des codes status dans les plages 3XX, 4XX et 5XX sont comptabilisées comme ayant échoué et réduisent la valeur de la métrique PercentSuccess. Dans les fichiers journaux de stockage côté serveur, ces opérations sont enregistrées avec une transaction status de ClientOtherErrors.

Il est important de noter que ces opérations ont été effectuées avec succès et n’affectent donc pas d’autres métriques, telles que la disponibilité. Voici quelques exemples d’opérations qui s’exécutent correctement, mais qui peuvent entraîner l’échec des codes de status HTTP :

  • ResourceNotFound (404 introuvable), par exemple, à partir d’une GET requête adressée à un objet blob qui n’existe pas.
  • ResourceAlreadyExists (Conflit 409), par exemple, à partir d’une CreateIfNotExist opération où la ressource existe déjà.
  • ConditionNotMet (Non modifié 304), par exemple, à partir d’une opération conditionnelle telle qu’un client envoie une ETag valeur et un en-tête HTTP If-None-Match pour demander une image uniquement si elle a été mise à jour depuis la dernière opération.

Vous trouverez la liste des codes d’erreur courants de l’API REST que les services de stockage retournent dans la page Codes d’erreur d’API REST courants.

Les métriques de capacité montrent une augmentation inattendue de l’utilisation de la capacité de stockage

Si vous constatez des changements soudains et inattendus dans l’utilisation de la capacité dans votre compte de stockage, vous pouvez examiner les raisons en examinant d’abord vos métriques de disponibilité . Par exemple, une augmentation du nombre de demandes de suppression ayant échoué peut entraîner une augmentation de la quantité de stockage d’objets blob que vous utilisez en tant qu’opérations de nettoyage spécifiques à l’application que vous attendiez à libérer de l’espace peut ne pas fonctionner comme prévu (par exemple, parce que les jetons SAP utilisés pour libérer de l’espace ont expiré).

Votre problème provient de l’utilisation de l’émulateur de stockage pour le développement ou le test

Vous utilisez généralement l’émulateur de stockage pendant le développement et les tests pour éviter la nécessité d’un compte de stockage Azure. Les problèmes courants qui peuvent se produire lorsque vous utilisez l’émulateur de stockage sont les suivants :

La fonctionnalité « X » ne fonctionne pas dans l’émulateur de stockage

L’émulateur de stockage ne prend pas en charge toutes les fonctionnalités des services de stockage Azure, telles que le service de fichiers. Pour plus d’informations, consultez Utiliser l’émulateur de stockage Azure pour le développement et le test.

Pour les fonctionnalités que l’émulateur de stockage ne prend pas en charge, utilisez le service de stockage Azure dans le cloud.

Erreur « La valeur de l’un des en-têtes HTTP n’est pas au format correct » lors de l’utilisation de l’émulateur de stockage

Vous testez votre application qui utilise la bibliothèque cliente de stockage sur l’émulateur de stockage local et des appels de méthode tels que CreateIfNotExists fail avec le message d’erreur « La valeur de l’un des en-têtes HTTP n’est pas au format correct ». Cela indique que la version de l’émulateur de stockage que vous utilisez ne prend pas en charge la version de la bibliothèque cliente de stockage que vous utilisez. La bibliothèque cliente de stockage ajoute l’en-tête x-ms-version à toutes les requêtes qu’elle effectue. Si l’émulateur de stockage ne reconnaît pas la valeur dans l’en-tête x-ms-version , il rejette la demande.

Vous pouvez utiliser les journaux client de la bibliothèque de stockage pour voir la valeur du x-ms-version header qu’il envoie. Vous pouvez également voir la valeur de si x-ms-version header vous utilisez Fiddler pour suivre les demandes de votre application cliente.

Ce scénario se produit généralement si vous installez et utilisez la dernière version de la bibliothèque cliente de stockage sans mettre à jour l’émulateur de stockage. Vous devez installer la dernière version de l’émulateur de stockage ou utiliser le stockage cloud au lieu de l’émulateur à des fins de développement et de test.

L’exécution de l’émulateur de stockage nécessite des privilèges d’administration

Vous êtes invité à entrer les informations d’identification de l’administrateur lorsque vous exécutez l’émulateur de stockage. Cela se produit uniquement lorsque vous initialisez l’émulateur de stockage pour la première fois. Une fois que vous avez initialisé l’émulateur de stockage, vous n’avez pas besoin de privilèges d’administration pour l’exécuter à nouveau.

Pour plus d’informations, consultez Utiliser l’émulateur de stockage Azure pour le développement et le test. Vous pouvez également initialiser l’émulateur de stockage dans Visual Studio, ce qui nécessite également des privilèges d’administration.

Vous rencontrez des problèmes lors de l’installation du Kit de développement logiciel (SDK) Azure pour .NET

Lorsque vous essayez d’installer le Kit de développement logiciel (SDK), il échoue lors de la tentative d’installation de l’émulateur de stockage sur votre ordinateur local. Le journal d’installation contient l’un des messages suivants :

  • CAQuietExec : Erreur : Impossible d’accéder à SQL instance
  • CAQuietExec : Erreur : Impossible de créer une base de données

La cause est un problème avec l’installation de LocalDB existante. Par défaut, l’émulateur de stockage utilise LocalDB pour conserver les données lorsqu’il simule les services de stockage Azure. Vous pouvez réinitialiser votre instance LocalDB en exécutant les commandes suivantes dans une fenêtre d’invite de commandes avant d’essayer d’installer le SDK.

sqllocaldb stop v11.0
sqllocaldb delete v11.0
delete %USERPROFILE%\WAStorageEmulatorDb3*.*
sqllocaldb create v11.0

La delete commande supprime tous les anciens fichiers de base de données des installations précédentes de l’émulateur de stockage.

Vous rencontrez un autre problème avec un service de stockage

Si les sections de résolution des problèmes précédentes n’incluent pas le problème que vous rencontrez avec un service de stockage, vous devez adopter l’approche suivante pour diagnostiquer et résoudre votre problème.

  • Vérifiez vos métriques pour voir s’il y a un changement par rapport à votre comportement de base attendu. À partir des métriques, vous serez peut-être en mesure de déterminer si le problème est temporaire ou permanent et quelles opérations de stockage le problème affecte.
  • Vous pouvez utiliser les informations des métriques pour vous aider à rechercher vos données de journal côté serveur pour obtenir des informations plus détaillées sur les erreurs qui se produisent. Ces informations peuvent vous aider à résoudre le problème.
  • Si les informations contenues dans les journaux côté serveur ne sont pas suffisantes pour résoudre le problème correctement, vous pouvez utiliser les journaux côté client de la bibliothèque cliente de stockage pour examiner le comportement de votre application cliente et des outils tels que Fiddler et Wireshark pour examiner votre réseau.

Pour plus d’informations sur l’utilisation de Fiddler, consultez Annexe 1 : Utilisation de Fiddler pour capturer le trafic HTTP et HTTPS.

Pour plus d’informations sur l’utilisation de Wireshark, consultez Annexe 2 : Utilisation de Wireshark pour capturer le trafic réseau.

Annexes

Les annexes décrivent plusieurs outils qui peuvent vous être utiles lorsque vous diagnostiquez et résolvez les problèmes liés au Stockage Azure (et à d’autres services). Ces outils ne font pas partie du Stockage Azure, et certains sont des produits tiers. Par conséquent, les outils décrits dans ces annexes ne sont couverts par aucun contrat de support que vous pouvez avoir avec Microsoft Azure ou Stockage Azure. Par conséquent, dans le cadre de votre processus d’évaluation, vous devez examiner les options de licence et de support disponibles auprès des fournisseurs de ces outils.

Annexe 1 : Utilisation de Fiddler pour capturer le trafic HTTP et HTTPS

Fiddler est un outil utile pour analyser le trafic HTTP et HTTPS entre votre application cliente et le service de stockage Azure que vous utilisez.

Remarque

Fiddler peut décoder le trafic HTTPS. Vous devez lire attentivement la documentation de Fiddler pour comprendre comment elle procède et ses implications en matière de sécurité.

Cette annexe fournit une brève procédure pas à pas pour configurer Fiddler pour capturer le trafic entre l’ordinateur local sur lequel vous avez installé Fiddler et les services de stockage Azure.

Une fois que vous avez lancé Fiddler, il commence à capturer le trafic HTTP et HTTPS sur votre ordinateur local. Voici quelques commandes utiles pour contrôler Fiddler :

  • Arrêtez et commencez à capturer le trafic. Dans le menu main, accédez à Fichier, puis sélectionnez Capturer le trafic pour activer et désactiver la capture.
  • Enregistrez les données de trafic capturées. Dans le menu main, accédez à Fichier, sélectionnez Enregistrer, puis Toutes les sessions. Cela vous permet d’enregistrer le trafic dans un fichier d’archive de session. Vous pouvez recharger une archive de session ultérieurement à des fins d’analyse ou l’envoyer si nécessaire au support Microsoft.

Pour limiter la quantité de trafic capturé par Fiddler, vous pouvez utiliser des filtres que vous configurez sous l’onglet Filtres . La capture d’écran suivante montre un filtre qui capture uniquement le trafic envoyé au point de terminaison de contosoemaildist.table.core.windows.net stockage :

Capture d’écran montrant un filtre qui capture uniquement le trafic envoyé au point de terminaison de stockage contosoemaildist.table.core.windows.net.

Annexe 2 : Utilisation de Wireshark pour capturer le trafic réseau

Wireshark est un analyseur de protocole réseau qui vous permet d’afficher des informations détaillées sur les paquets pour un large éventail de protocoles réseau.

La procédure suivante vous montre comment capturer des informations détaillées sur les paquets pour le trafic de l’ordinateur local sur lequel vous avez installé Wireshark vers le service de table dans votre compte de stockage Azure.

  1. Lancez Wireshark sur votre ordinateur local.

  2. Dans la section Démarrer , sélectionnez l’interface réseau locale ou les interfaces connectées à Internet.

  3. Sélectionnez Options de capture.

  4. Ajoutez un filtre à la zone de texte Filtre de capture. Par exemple, host contosoemaildist.table.core.windows.net configure Wireshark pour capturer uniquement les paquets envoyés vers ou à partir du point de terminaison de service de table dans le compte de stockage contosoemaildist . Consultez la liste complète des filtres de capture.

    Capture d’écran montrant comment ajouter un filtre à la zone de texte Filtre de capture.

  5. Sélectionnez Démarrer. Wireshark capture désormais tous les paquets envoyés vers ou à partir du point de terminaison de service de table lorsque vous utilisez votre application cliente sur votre ordinateur local.

  6. Lorsque vous avez terminé, sélectionnezArrêter la capture> dans le menu main.

  7. Pour enregistrer les données capturées dans un fichier de capture Wireshark, sélectionnez Fichier>Enregistrer dans le menu main.

WireShark met en évidence toutes les erreurs qui existent dans la fenêtre de liste de paquets . Vous pouvez également utiliser la fenêtre Informations sur l’expert (sélectionnez Analyser les>informations d’expert) pour afficher un résumé des erreurs et des avertissements.

Capture d’écran montrant la fenêtre Informations d’expert dans laquelle vous pouvez afficher un résumé des erreurs et des avertissements.

Vous pouvez également choisir d’afficher les données TCP telles que la couche application les voit en cliquant avec le bouton droit sur les données TCP et en sélectionnant Suivre l’Stream TCP. Cela est utile si vous avez capturé votre image mémoire sans filtre de capture. Pour plus d’informations, consultez Suivi de flux TCP.

Capture d’écran montrant comment afficher les données TCP telles que la couche application les voit.

Remarque

Pour plus d’informations sur l’utilisation de Wireshark, consultez le Guide des utilisateurs wireshark.

Annexe 4 : Utilisation d’Excel pour afficher les métriques et les données de journal

De nombreux outils vous permettent de télécharger les données des métriques de stockage à partir du stockage de tables Azure dans un format délimité qui facilite le chargement des données dans Excel à des fins d’affichage et d’analyse. Stockage Les données de journalisation de Stockage Blob Azure sont déjà dans un format délimité que vous pouvez charger dans Excel. Toutefois, vous devez ajouter les en-têtes de colonnes appropriés en fonction des informations figurant dans format de journal Storage Analytics et schéma de table de Storage Analytics métriques.

Pour importer vos données de journalisation du stockage dans Excel après les avoir téléchargées à partir du stockage Blob :

  • Dans le menu Données , sélectionnez À partir du texte.
  • Accédez au fichier journal que vous souhaitez afficher, puis sélectionnez Importer.
  • À l’étape 1 de l’Assistant Importation de texte, sélectionnez Délimité.

À l’étape 1 de l’Assistant Importation de texte, sélectionnez Point-virgule comme seul délimiteur et choisissez guillemet double comme qualificateur texte. Sélectionnez ensuite Terminer et choisissez où placer les données dans votre classeur.

Annexe 5 : Supervision avec Application Insights pour Azure DevOps

Vous pouvez également utiliser la fonctionnalité Application Insights pour Azure DevOps dans le cadre de la surveillance des performances et de la disponibilité. Cet outil peut :

  • Assurez-vous que votre service web est disponible et réactif. Que votre application soit un site web ou une application d’appareil qui utilise un service web, elle peut tester votre URL toutes les quelques minutes à partir d’emplacements dans le monde entier et vous indiquer s’il y a un problème.
  • Diagnostiquez rapidement les problèmes de performances ou les exceptions dans votre service web. Déterminez si le processeur ou d’autres ressources sont étirés, obtenez des traces de pile à partir d’exceptions et recherchez facilement les traces de journal. Si les performances de l’application tombent en dessous des limites acceptables, Microsoft peut vous envoyer un e-mail. Vous pouvez surveiller les services web .NET et Java.

Pour plus d’informations, consultez Qu’est-ce qu’Application Insights ?

Étapes suivantes

Pour plus d’informations sur l’analytique dans Stockage Azure, consultez les ressources suivantes :

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.