Analyser, diagnostiquer et dépanner Stockage Microsoft Azure (classique)

Ce guide vous montre comment utiliser des fonctionnalités telles que Stockage Azure 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 aux Stockage Azure.

Ce guide est destiné principalement aux développeurs de services en ligne qui utilisent les services Azure Storage et aux professionnels de l’informatique responsables de la gestion de tels services en ligne. Ce guide a pour objectifs de :

• Vous aider à maintenir l'état d'intégrité et les performances de vos comptes Azure Storage.
• Mettre à votre disposition les processus et outils nécessaires pour vous aider à déterminer si un problème rencontré dans une application est lié à Stockage Azure.
• Mettre à votre disposition des mesures concrètes pour la résolution des problèmes liés à Azure Storage.

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 s'avérer plus complexes que dans des 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 les tables Stockage Microsoft Azure, les objets blob, les files d’attente ou les fichiers en plus d’autres magasins de données tels que les bases de données relationnelles et de documents.

Pour gérer ces applications avec succès, vous devez les surveiller de manière proactive et comprendre comment diagnostiquer et dépanner tous les aspects d’entre eux et leurs technologies dépendantes. En tant qu’utilisateur de Stockage Azure services, vous devez surveiller en permanence les services de stockage utilisés par votre application pour toute modification inattendue du comportement (par exemple, les 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 informations de diagnostic que vous obtenez à partir de la surveillance et de la journalisation vous aideront à déterminer la cause racine du problème rencontré par votre application. Vous pouvez alors résoudre le problème et déterminer la procédure appropriée 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. Azure Storage inclut des fonctionnalités qui permettent de simplifier l'analyse, le diagnostic et la résolution des problèmes de stockage rencontrés par vos applications sur le cloud.

Organisation de ce guide

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

La section Diagnostic des problèmes de stockage décrit comment diagnostiquer les problèmes à l’aide de la journalisation Stockage Azure Analytics (journalisation du stockage). Il explique é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.

Analyse de votre service de stockage

Si vous connaissez les outils d’analyse de performances Windows, vous pouvez considérer les métriques de stockage comme l’équivalent, dans Azure Storage, des compteurs de l’Analyseur de performances Windows. Dans les 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 adressées au service ou le pourcentage de demandes réussies au service. Pour obtenir une liste de toutes les métriques disponibles, consultez l’article Schéma de table de métriques Storage Analytics. Vous pouvez spécifier si vous désirez que le service de stockage collecte et agrège les métriques toutes les heures ou toutes les minutes. Pour plus d’informations sur la façon d’activer les métriques et d’analyser vos comptes de stockage, consultez la section Activation de Storage Metrics et affichage des données de métriques.

Vous pouvez sélectionner les métriques horaires à afficher dans le portail Azure et configurer les règles de notification par e-mail des administrateurs lorsqu’une métrique horaire dépasse un seuil spécifique. Pour plus d’informations, consultez Réception de 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 fournit une analyse complète de vos comptes de Stockage Azure en présentant une vue unifiée des performances, de la capacité et de la disponibilité de vos services de Stockage Azure. Vous n’avez pas besoin d’activer ou de configurer quoi que ce soit, et vous pouvez afficher immédiatement ces métriques à partir des graphiques interactifs prédéfinis et d’autres visualisations incluses.

Le service de stockage tente de collecter les métriques, mais peut ne pas enregistrer chaque opération de stockage.

Dans le portail Azure, vous pouvez afficher des métriques telles que la disponibilité, le nombre total de demandes et les valeurs de latence moyenne pour un compte de stockage. Une règle de notification a également été configurée afin d'alerter l'administrateur lorsque la disponibilité chute en dessous d'un certain niveau. À partir de l’affichage de ces données, une zone possible pour l’examen est le pourcentage de réussite du service de table inférieur à 100 % (pour plus d’informations, voir les métriques indiquent que les entrées de journal PercentSuccess ou Analytics ont des opérations avec l’état de transaction de la section ClientOtherErrors ).

Vous devez surveiller en permanence vos applications Azure afin de vous assurer qu’elles sont intègres et fonctionnent comme prévu en :

• Établissement de mesures de référence pour l’application qui vous permettront de comparer les données actuelles et d’identifier les modifications significatives du comportement du stockage Azure et de votre application. Les valeurs de vos métriques de référence seront, 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 de minute et leur utilisation pour surveiller activement les erreurs et anomalies inattendues, telles que les pics de nombre d’erreurs ou les taux de requêtes.
• Enregistrant les métriques horaires et en les utilisant pour analyser les valeurs moyennes telles que le nombre d'erreurs et le taux de demandes moyens.
• Examen des problèmes potentiels à l’aide d’outils de diagnostic, comme indiqué plus loin dans la section Diagnostic des problèmes de stockage.

Les graphiques de l’image suivante illustrent comment la moyenne établie pour les métriques horaires peut cacher certains pics d'activité. Les métriques horaires s'affichent pour indiquer un taux de demandes stable ; les métriques par minute révèlent les fluctuations réelles.

La suite de cette section décrit quelles métriques vous devriez analyser et pourquoi.

Analyse de l’état d’intégrité du service

Vous pouvez utiliser le portail Azure pour afficher l’état du service de stockage (et d’autres services Azure) dans toutes les régions Azure de par le monde. 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 envoyer des notifications des incidents qui affectent les divers services Azure.

Analyse de la capacité

Les métriques de stockage enregistrent uniquement les métriques de capacité pour le service d’objet blob, car les objets blob constituent généralement la majeure partie des données stockées (lors de l'écriture, il n'est pas possible d'utiliser les métriques de stockage pour analyser la capacité de vos tables et files d'attente). Vous trouverez ces données dans la $MetricsCapacityBlob table si vous avez activé la surveillance du service Blob. Les métriques de stockage enregistrent ces données une fois par jour et vous pouvez utiliser la valeur de la RowKey ligne 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 Le schéma de table de métriques Storage Analytics.

Pour estimer la taille de différents objets de stockage tels que les objets blob, consultez le billet de blog Understanding Stockage Azure Billing – Bande passante, Transactions et Capacité.

Supervision de la disponibilité

Vous devez surveiller la disponibilité des services de stockage dans votre compte de stockage en surveillant la valeur de 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 (la RowKey ligne indique 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 ils échouent en examinant les autres colonnes des données de métriques qui affichent le nombre de requêtes avec différents types d’erreurs, tels que ServerTimeoutError. Vous devez vous attendre à une chute temporaire inférieure à Availability 100 % pour des raisons telles que des délais d’expiration de serveur temporaires pendant que le service déplace les partitions pour améliorer l’équilibrage de charge des demandes ; la logique de nouvelle tentative dans votre application cliente doit gérer ces conditions intermittentes. L’article Opérations journalisées et messages d’état Storage Analytics répertorie les types de transactions inclus dans les métriques de stockage dans son Availability calcul.

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

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

Analyse des performances

Pour analyser les performances de vos services de stockage, vous pouvez utiliser les métriques suivantes des tables de métriques horaires ou par minute.

• Les valeurs dans les 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 la latence de bout en bout qui inclut le temps nécessaire à la lecture de la demande et l’envoi de la réponse en plus du temps nécessaire au traitement de la demande (par conséquent, inclut la latence réseau une fois que la demande 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 et low AverageServerLatency plus loin dans ce guide pour une discussion sur la raison pour laquelle il peut y avoir une différence significative entre ces deux valeurs.
• Les valeurs dans les colonnes et TotalEgress les TotalIngress colonnes indiquent la quantité totale de données, en octets, entrant et sortant de votre service de stockage ou via un type d’opération d’API spécifique.
• Les valeurs de la TotalRequests colonne indiquent le nombre total de demandes reçues par le service de stockage de l’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 allez surveiller les modifications inattendues dans l’une de ces valeurs, car cela indique que vous avez un problème qui nécessite une investigation.

Dans le Portail Azure, vous pouvez ajouter des règles d’alerte pour vous avertir si des métriques de performances pour ce service tombent en dessous ou dépassent 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

Il existe différentes façons de savoir si votre application a rencontré un problème :

• Un échec majeur qui provoque le blocage ou l’arrêt de l’application.
• Modifications significatives des valeurs de référence dans les métriques que vous surveillez, comme décrit dans la section précédente Surveillance de votre service de stockage.
• Rapports des utilisateurs de votre application indiquant qu'une certaine opération ne s'est pas effectuée comme prévu ou qu'une fonctionnalité est défectueuse.
• Erreurs générées au sein de votre application et affichées dans les fichiers journaux ou via d'autres méthodes de notification.

Les problèmes associés aux services de stockage Azure se répartissent généralement en quatre catégories principales :

• Votre application a 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 au niveau de l'infrastructure Azure Storage 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 pouvez utiliser l’émulateur de stockage local ; vous pouvez rencontrer certains problèmes liés spécifiquement à l’utilisation de l’émulateur de stockage.

Les sections suivantes expliquent les étapes à suivre pour le diagnostic et la résolution des 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 pour certains problèmes courants que vous pouvez rencontrer.

Problèmes d’état d’intégrité du service

Les problèmes d’état du service sont généralement des problèmes sur lesquels vous n’avez pas de contrôle. Le Portail Azure fournit des informations sur les problèmes en cours liés aux services Azure, y compris les services de stockage. Si vous avez opté pour un stockage géoredondant avec accès en lecture lors de la création de votre compte de stockage, si vos données ne sont plus accessibles depuis l’emplacement principal, votre application peut passer provisoirement à une copie en lecture seule dans l’emplacement secondaire. Pour lire à partir de la base de données secondaire, votre application doit pouvoir basculer entre l’utilisation des emplacements de stockage principal et secondaire et fonctionner en mode de fonctionnalité réduite avec des données en lecture seule. Les bibliothèques clientes Azure Storage vous permettent de définir une stratégie de nouvelle tentative afin de passer à une lecture depuis le stockage secondaire lorsque la lecture depuis le stockage principal échoue. Votre application doit également être capable de reconnaître que les données de l’emplacement secondaire sont cohérentes. Pour plus d’informations, consultez le billet de blog Azure Storage Redundancy Options and Read Access Geo Redundant Storage.

Problèmes de performance

Les performances d’une application peuvent être subjectives, en particulier du point de vue de l’utilisateur. C'est pourquoi il est important de disposer de métriques de base afin de vous aider à identifier les problèmes de performances éventuels. 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 ; il est donc important d’avoir une stratégie pour identifier l’origine du problème de performances.

Après avoir identifié l'emplacement probable de la cause du problème de performances à partir des métriques, vous pouvez utiliser les fichiers journaux afin de disposer d'informations détaillées pour un diagnostic et une résolution en profondeur du problème.

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.

Erreurs de diagnostic

Les utilisateurs de votre application peuvent vous signaler des erreurs identifiées par l'application cliente. Les métriques de stockage enregistrent également le nombre de types d’erreurs différents de vos services de stockage, tels que NetworkError, ClientTimeoutError ou AuthorizationError. Les métriques de stockage enregistrent uniquement les décomptes des différents types d’erreurs, mais vous pouvez obtenir des informations plus détaillées concernant les demandes individuelles en examinant les journaux d’activité côté serveur, côté client et réseau. Le code d'état HTTP renvoyé par le service de stockage peut généralement servir d'indication pour expliquer l'échec de la demande.

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

• Codes d’erreur courants de l’API REST
• Codes d’erreur du service Blob
• Codes d’erreur du service de file d’attente
• Codes d’erreur du service de table
• Codes d’erreur du service de fichiers

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 le test, ce qui vous permet d’exécuter des applications qui utilisent des services de stockage Azure sans avoir besoin d’un abonnement Azure et d’un compte de stockage Azure.

La section Conseils de dépannage 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 permet de journaliser côté serveur les demandes de stockage dans votre compte de stockage Azure. Pour plus d’informations concernant l’activation de la journalisation côté serveur et l’accès aux données de journalisation, consultez Activation de la journalisation du stockage et accès aux données des journaux.

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

Utilisation des outils de journalisation réseau

Vous pouvez capturer le trafic entre le client et le serveur afin d'obtenir des informations détaillées concernant les données échangées entre le client et le serveur, et concernant les conditions réseau sous-jacentes. Parmi les outils de journalisation réseau utiles, on retrouve :

• Fiddler est un proxy de débogage web gratuit qui vous permet d’examiner les en-têtes et données de charge utile des messages de requête et de réponse HTTP et HTTPS. Pour plus d’informations, consultez Annexe 1 : Utilisation de Fiddler pour capturer le trafic HTTP et HTTPS.
• Le Moniteur réseau Microsoft (Netmon) et Wireshark sont des analyseurs de protocole réseau gratuits qui vous permettent d’afficher des informations détaillées concernant les paquets pour de nombreux protocoles réseau. Pour plus d’informations sur Wireshark, consultez l’annexe 2 : Utilisation de Wireshark pour capturer le trafic réseau.
• Si vous souhaitez effectuer un test de connectivité de base pour vérifier que votre ordinateur client peut se connecter au service de stockage Azure via le réseau, vous ne pouvez pas le faire en utilisant l'outil ping standard sur le client. Mais l'outil tcping vous permet de vérifier la connectivité.

Dans de nombreux cas, les données de journalisation issues de la journalisation du stockage et de la bibliothèque cliente de stockage seront suffisantes pour diagnostiquer un problème, mais dans certains scénarios, il se peut que vous ayez besoin de plus d’informations que celles fournies par ces outils de journalisation réseau. Par exemple, utiliser 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 aux et par les services de stockage, ce qui vous permet de vérifier comment une application cliente effectue les nouvelles tentatives d'opérations de stockage. Les analyseurs de protocole tels que Wireshark fonctionnent au niveau des paquets et vous permettent d'afficher les données TCP afin de résoudre les problèmes de perte de paquets et de connectivité.

Suivi de bout en bout

Le suivi de bout en bout basé sur plusieurs fichiers journaux est une technique utile pour l’identification des 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 journalisation

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, utiles en tant qu'identificateurs de corrélation. L’ID de demande client est le champ le plus utile pour mettre en corrélation les entrées dans les différents journaux d’activité. Toutefois, parfois, il peut être utile d’utiliser l’ID de demande de serveur ou les horodatages. Les sections suivantes expliquent plus en détail ces options.

ID de la demande client

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

• 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 requête.
• Dans une trace réseau telle qu’une trace capturée par Fiddler, l’ID de demande client est visible dans les messages de requête comme x-ms-client-request-id valeur d’en-tête HTTP.
• Dans le journal de journalisation du stockage côté serveur, l’ID de demande client s’affiche dans la colonne ID de demande client.

ID de la demande serveur

Le service de stockage génère automatiquement les ID de demande serveur.

• Dans le journal de journalisation du stockage côté serveur, l’ID de demande de serveur s’affiche dans la Request ID header colonne.
• Dans une trace réseau telle qu’une trace capturée par Fiddler, l’ID de requête du serveur apparaît dans les messages de réponse comme x-ms-request-id valeur d’en-tête 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.

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();
    }
}

//Parse the connection string for the storage account.
const string ConnectionString = "DefaultEndpointsProtocol=https;AccountName=account-name;AccountKey=account-key";
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(ConnectionString);
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();

// Create an Operation Context that includes custom ClientRequestId string based on constants defined within the application along with a Guid.
OperationContext oc = new OperationContext();
oc.ClientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());

try
{
    CloudBlobContainer container = blobClient.GetContainerReference("democontainer");
    ICloudBlob blob = container.GetBlobReferenceFromServer("testImage.jpg", null, null, oc);  
    var downloadToPath = string.Format("./{0}", blob.Name);
    using (var fs = File.OpenWrite(downloadToPath))
    {
        blob.DownloadToStream(fs, null, null, oc);
        Console.WriteLine("\t Blob downloaded to file: {0}", downloadToPath);
    }
}
catch (StorageException storageException)
{
    Console.WriteLine("Storage exception {0} occurred", storageException.Message);
    // Multiple results may exist due to client side retry logic - each retried operation will have a unique ServiceRequestId
    foreach (var result in oc.RequestResults)
    {
            Console.WriteLine("HttpStatus: {0}, ServiceRequestId {1}", result.HttpStatusCode, result.ServiceRequestID);
    }
}

Horodatages

Vous pouvez également utiliser les horodatages pour trouver des entrées de journal associées, mais sans oublier les éventuelles variations d'horloges entre le client et le serveur. La recherche des entrées côté serveur correspondantes doit s’appliquer dans une plage de plus ou moins 15 minutes par rapport à l’horodatage sur le client. N’oubliez pas que les métadonnées des 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 plusieurs objets blob de métriques pour une même minute ou heure.

Instructions pour la résolution des problèmes

Cette section est destinée à vous aider à diagnostiquer et résoudre certains des problèmes communs que votre application est susceptible de rencontrer lors de l’utilisation des services de stockage Azure. La liste ci-dessous permet d’identifier les informations pertinentes pour un problème spécifique.

Résolution des problèmes liés à l’arbre de décision

Votre problème concerne-t-il les performances d'un des services de stockage ?

• Les métriques indiquent une valeur averageE2ELatency élevée et une faible moyenneServerLatency.
• Les métriques indiquent une faible latence AverageE2ELatency et une faible moyenneServerLatency, mais le client rencontre une latence élevée.
• Les métriques indiquent une latence MoyenneServerLatency élevée.
• Vous rencontrez des retards inattendus dans la remise des messages sur une file d’attente.

Votre problème concerne-t-il la disponibilité d’un des services de stockage ?

• Les métriques montrent une augmentation de PercentThrottlingError.
• Les métriques montrent une augmentation de PercentTimeoutError.
• Les métriques montrent une augmentation de PercentNetworkError.

Votre application client reçoit-elle une réponse HTTP 4XX (telle que 404) d’un service de stockage ?

• Le client reçoit des messages HTTP 403 (interdits).
• Le client reçoit des messages HTTP 404 (introuvables).
• Le client reçoit des messages HTTP 409 (Conflict).

Les métriques indiquent que les entrées de journal PercentSuccess ou Analytics ont des opérations avec l’état de transaction de ClientOtherErrors.

Les métriques de capacité montrent 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 problème différent avec un service de stockage.

Les mesures indiquent une valeur AverageE2ELatency élevée et une valeur AverageServerLatency faible.

L’illustration de l’outil d’analyse du portail Azure donne un exemple où la valeur AverageE2ELatency est nettement supérieure à la valeur AverageServerLatency.

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

Enquête sur les problèmes de performances client

Les raisons possibles pour le client qui répondent lentement incluent l’utilisation d’un nombre limité de connexions ou de threads disponibles ou d’être faibles sur les ressources telles que le processeur, la mémoire ou la bande passante réseau. Vous pouvez être en mesure de résoudre le problème en modifiant le code client pour être 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 MoyenneE2ELatency é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 System.Net de noms. Cette opération doit être effectuée avant de réaliser des appels vers les services de table et de file d’attente dans votre application, car elle 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;

var storageAccount = CloudStorageAccount.Parse(connStr);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(storageAccount.QueueEndpoint);
queueServicePoint.UseNagleAlgorithm = false;

Vous devez vérifier les journaux côté client pour voir le nombre de demandes que votre application cliente envoie et vérifiez en 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. La première étape pour la résolution des problèmes des applications clientes .NET consiste à consulter la section Débogage, suivi et profilage.

Enquête sur les problèmes de latence du réseau

Une latence de bout en bout élevée, causée par le réseau, est généralement associée à des conditions provisoires. 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 l’annexe 2 : Utilisation de Wireshark pour capturer le trafic réseau.

Les mesures indiquent une valeur AverageE2ELatency faible et une valeur AverageServerLatency faible, mais le client constate une latence élevée.

Dans ce scénario, la cause la plus probable est un retard des demandes de stockage à atteindre le service de stockage. Vous devez enquêter sur la raison pour laquelle les demandes envoyées par le client ne parviennent pas au service d'objet blob.

Les raisons possibles à un retard de l’envoi des demandes par le client incluent un nombre limité de connexions ou threads disponibles.

Vérifiez également si le client effectue plusieurs nouvelles tentatives et examinez la raison de son utilisation. Pour déterminer si le client effectue plusieurs tentatives, vous pouvez :

• Examiner les journaux d’activité d’analyse de stockage. En cas de tentatives répétées, plusieurs opérations avec le même ID de demande client mais différents ID de demande serveur apparaissent.
• Examiner les journaux d’activité du client. Les nouvelles tentatives apparaissent dans la journalisation documentée.
• Déboguez votre code et vérifiez les propriétés de l’objet OperationContext associé à la requête. Si l’opération a retenté, la RequestResults propriété inclut plusieurs ID de demande de serveur uniques. Vous pouvez également vérifier les heures de début et de fin de chaque demande. Pour plus d’informations, voir l’exemple de code de la section « ID de la demande serveur».

En l’absence de problèmes au niveau du client, vous pouvez enquêter sur la présence de problèmes potentiels au niveau du réseau, tels que la perte de paquets. Vous pouvez utiliser des outils tels que Wireshark pour enquêter sur les problèmes de réseau.

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

Les mesures indiquent une valeur AverageServerLatency élevée.

En présence d’une valeur AverageServerLatency élevée pour les demandes de téléchargement d’objet blob, vous devez utiliser les journaux d’activité de journalisation du stockage pour savoir si des demandes répétées ont été envoyé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 inférieurs à 64 K de taille peuvent entraîner des surcharges, sauf si les lectures sont également en moins de 64 K segments) et si plusieurs clients chargent des blocs dans le même objet blob en parallèle. Vous devez également vérifier les métriques par minute pour connaître les pics de demandes qui entraînent un dépassement des cibles d’extensibilité par seconde. Pour plus d’informations, consultez Metrics show an increase in PercentTimeoutError.

Si vous voyez une valeur moyenne AverageServerLatency élevée pour les demandes de téléchargement d’objets blob lorsqu’il existe des requêtes 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 du cache Azure ou du réseau de distribution de contenu Azure (CDN). Pour les demandes de chargement, vous devez améliorer le débit en augmentant la taille des blocs. Pour les requêtes sur des tables, il est également possible d’implémenter une 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.

Des valeurs AverageServerLatency élevées peuvent également indiquer la présence de tables mal conçues ou de requêtes donnant lieu à des opérations d'analyse ou qui suivent l'anti-modèle d'ajout/ajout de préfixe. Pour plus d’informations, consultez Metrics show an increase in PercentThrottlingError.

Vous constatez des retards inattendus dans la livraison des messages d’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ù elle est disponible pour lire à partir de la file d’attente, procédez comme suit pour diagnostiquer le problème :

• Vérifiez que l’application ajoute correctement les messages à la file d’attente. Vérifiez que l’application n’effectue pas plusieurs tentatives de méthode AddMessage avant de réussir. Les journaux d’activité 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 le rend comme s’il y a un délai de traitement.
• Vérifiez si le rôle de travail qui lit les messages à partir 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 n'est qu'à ce moment que le message pourra à nouveau être traité.
• Vérifiez si la longueur de la file d'attente augmente avec le temps. Cela peut se produire si vous n’avez pas suffisamment de workers disponibles pour traiter tous les messages que d’autres travailleurs mettent dans la file d’attente. Vérifiez également les métriques pour voir si les demandes de suppression échouent et que le nombre de files d’attente sur les messages, ce qui peut indiquer des tentatives répétées d’échec de suppression du message.
• Vérifiez dans les journaux d’activité de journalisation du stockage la présence d’opérations de file d’attente présentant des valeurs E2ELatency et ServerLatency supérieures à celles prévues, pendant une période plus longue que prévu.

Les mesures indiquent une augmentation de la valeur PercentThrottlingError.

Les erreurs de limitation se produisent lorsque vous dépassez les valeurs cibles d’évolutivité d’un service de stockage. Le service de stockage connaît des limitations afin de s’assurer qu’aucun client ni locataire ne peut utiliser le service au détriment des autres utilisateurs. Pour plus d’informations sur les objectifs de scalabilité des comptes de stockage et les objectifs de performances des partitions dans les comptes de stockage, consultez Cibles de scalabilité et de performances pour les comptes de stockage standard.

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

• Augmentation provisoire de la valeur PercentThrottlingError
• Augmentation permanente de l’erreur PercentThrottlingError

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. Elle peut également se manifester dans le client sous forme de messages d’état HTTP « 503 Server Busy » ou « 500 Operation Timeout » à partir des opérations de stockage.

Augmentation provisoire de la valeur PercentThrottlingError

Si vous voyez 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 de sauvegarde exponentielle (non linéaire) pour les nouvelles tentatives dans votre client. Les nouvelles tentatives de sauvegarde 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, voir Espace de noms Microsoft.Azure.Storage.RetryPolicies.

Augmentation permanente de PercentThrottlingError

Si vous voyez une valeur constante pour PercentThrottlingError après 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 des partitions de stockage et si elle approche des cibles d’extensibilité d’un compte de stockage. Par exemple, si vous voyez des erreurs de limitation sur une file d’attente (qui comptent en tant que partition unique), envisagez d’utiliser des files d’attente supplémentaires pour répartir les transactions entre plusieurs partitions. Si vous constatez des erreurs de limitation sur une table, vous devez envisager l’utilisation d’un schéma de partitionnement différent afin de distribuer vos transactions à travers plusieurs partitions en utilisant une plage de valeurs de clé de partition plus large. L’une des causes courantes de ce problème est l’anti-modèle prédéfini/ajout dans lequel vous sélectionnez la date comme clé de partition, puis toutes les données d’un jour particulier sont écrites sur une seule partition : en cours de chargement, cela peut entraîner un goulot d’étranglement d’écriture. Pensez à une conception de partitionnement différente ou évaluez s’il ne vaut pas mieux utiliser un stockage d’objets blob. Vérifiez également si la limitation se produit suite à des pics dans votre trafic et examinez les méthodes de lissage de votre modèle de requêtes.

Si vous distribuez vos transactions à travers plusieurs partitions, vous devez tenir compte des limites d'évolutivité définies pour le compte de stockage. Par exemple, si vous avez utilisé dix files d’attente, chacun traitant le maximum de 2 000 messages de 1 Ko par seconde, vous serez à 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 pouvez être limité plus tôt.

Une requête mal conçue peut également vous amener à atteindre les limites d'évolutivité 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 recherche toutes les entités dans une partition devra accéder à chaque entité. Chaque lecture d’entité sera ajoutée au décompte total de transactions dans cette partition, vous amenant à atteindre rapidement les cibles d’évolutivité.

Les mesures indiquent une augmentation de la valeur PercentTimeoutError.

Vos métriques indiquent une augmentation de la valeur PercentTimeoutError pour un de vos services de stockage. En même temps, le client reçoit un grand nombre de messages d'état HTTP « 500 Operation Timeout » à partir des opérations de stockage.

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

Les délais d'expiration du serveur sont provoqué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 au niveau du service de stockage, qui exige une enquête plus approfondie. Vous pouvez utiliser les métriques pour savoir si vous atteignez les limites d'évolutivité pour le service et identifier les pics de trafic susceptibles d'être la cause de ce problème. Si le problème est intermittent, il peut être dû à une activité d'équilibrage de charge dans le service. Si le problème persiste et n'est pas provoqué par le fait que votre application a atteint les limites d'évolutivité du service, vous devez signaler le problème au support. Pour les délais d’expiration du client, vous devez décider si le délai d’attente 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 mesures indiquent une augmentation de la valeur PercentNetworkError.

Vos métriques indiquent une augmentation de la valeur PercentNetworkError pour un de vos services de stockage. La métrique PercentNetworkError est une agrégation des métriques suivantes : NetworkError, AnonymousNetworkError et SASNetworkError. Cela se produit lorsque le service de stockage détecte une erreur de réseau associée à une demande de stockage du client.

La cause la plus fréquente de cette erreur est une déconnexion du client avant l'expiration d'un délai dans le service de stockage. Examinez le code dans votre client afin de 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 du client. Ces outils sont décrits dans la section Annexes.

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

Si votre application client génère des erreurs HTTP403 (Forbidden), l'une des causes probables est l'utilisation par le client d'une signature d'accès partagé (SAS) arrivée à expiration lors de l'envoi d'une demande de stockage (d'autres causes possibles incluent les variations d'horloges, les clés non valides et les en-têtes vides). Si une clé SAP expirée 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 inclut un exemple de journal côté client généré par la bibliothèque cliente de stockage, qui illustre ce type de problème :

Dans ce scénario, vous devez rechercher pourquoi le jeton SAS 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 SAP pour qu’un client utilise immédiatement. S’il existe de petites différences d’horloge entre l’hôte qui génère la SAP à l’aide de l’heure actuelle et le service de stockage, il est possible que le service de stockage reçoive une SAP qui n’est pas encore valide.
• Ne définissez pas une durée d’expiration très courte sur une SAP. Là encore, de petites différences d’horloge entre l’hôte générant la sape et le service de stockage peuvent entraîner une SIGNATURE d’accès partagé apparemment expirée plus tôt que prévu.
• Le paramètre de version de la clé SAS (par exemple, sv=2015-04-05) correspond-il à la version de la bibliothèque cliente de stockage que vous utilisez ? Vous devez 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, les jetons SAS existants risquent d’être invalidés. Ce problème peut survenir si vous générez des jetons SAS avec une durée d’expiration longue pour les applications clientes dans le cache.

Si vous utilisez la bibliothèque de client de stockage pour générer des jetons SAS, il est facile de créer un jeton valide. Néanmoins si vous utilisez l’API REST de Stockage et que vous créez les jetons SAS manuellement, consultez Délégation de l’accès avec une signature d’accès partagé.

Le client reçoit des messages HTTP 404 (Not found)

Si l’application client reçoit un message HTTP 404 (Non trouvé) du serveur, cela signifie que l’objet que le client tentait d’utiliser (tel qu’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 à ce problème, dont :

• Le client ou un autre processus a précédemment supprimé l’objet.
• Problème d’autorisation signature d’accès partagé (SAP).
• Le code JavaScript côté client n’est pas autorisé à accéder à l’objet.
• Échec réseau.

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

Dans les scénarios où le client tente de lire, de mettre à jour ou de 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 journalisation 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 s'affichent lorsqu'un client a supprimé un objet.

Dans le scénario où un client tente d’insérer un objet, il peut ne pas être immédiatement évident pourquoi cela entraîne une réponse HTTP 404 (introuvable), étant donné que le client crée un 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 des informations plus détaillées concernant l'instant 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 d'un client incapable de trouver le conteneur de l'objet blob qu'il est en train de créer. Ce journal inclut les détails des opérations de stockage suivantes :

Entrées du journal :

Dans cet exemple, le journal indique que le client interlace 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 parce que l’application cliente appelle ces méthodes de façon asynchrone. Modifiez le code asynchrone dans le client de façon à ce qu’il crée le conteneur avant de tenter de charger des données dans un objet blob de ce conteneur. Idéalement, vous devriez 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é SAS qui n’inclut pas les autorisations requises pour l’opération, le service de stockage renvoie un message HTTP 404 (Non trouvé) au client. En même temps, vous verrez également une valeur différente de zéro dans SASAuthorizationError les métriques.

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

Examinez pourquoi votre application cliente tente d’effectuer une opération pour laquelle elle n’a pas reçu d’autorisations.

Le code JavaScript côté client n’est pas autorisé à accéder à l’objet

Si vous utilisez un client JavaScript et que le service de stockage renvoie des messages HTTP 404, vous devez vérifier la présence des 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, Access est refusé.

Ces erreurs sont dues au fait que le navigateur implémente la restriction de sécurité same origin policy , qui empêche une page web d’appeler une API dans un domaine différent de celui dont la page provient.

Pour contourner le problème JavaScript, vous pouvez configurer le partage de ressources cross-origin (CORS) pour le service de stockage auquel le client accède. Pour plus d’informations, voir Prise en charge du service Partage des ressources cross-origine (CORS) pour les services Azure Storage.

L'exemple de code suivant montre comment configurer votre service d'objet blob afin de permettre l'exécution de JavaScript dans le domaine Contoso pour 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);

CloudBlobClient client = new CloudBlobClient(blobEndpoint, new StorageCredentials(accountName, accountKey));
// Set the service properties.
ServiceProperties sp = client.GetServiceProperties();
sp.DefaultServiceVersion = "2013-08-15";
CorsRule cr = new CorsRule();
cr.AllowedHeaders.Add("*");
cr.AllowedMethods = CorsHttpMethods.Get | CorsHttpMethods.Put;
cr.AllowedOrigins.Add("http://www.contoso.com");
cr.ExposedHeaders.Add("x-ms-*");
cr.MaxAgeInSeconds = 5;
sp.Cors.CorsRules.Clear();
sp.Cors.CorsRules.Add(cr);
client.SetServiceProperties(sp);

Panne réseau

Dans certaines circonstances, la perte de paquets réseau peut amener le service de stockage à renvoyer des messages HTTP 404 au client. Par exemple, lorsque votre application cliente supprime une entité du service de table, vous voyez que le client lève une exception de stockage signalant un message d’état « HTTP 404 (introuvable) » du service de table. Lorsque vous recherchez la table dans le service de stockage de table, vous constatez que le service a supprimé l'entité comme prévu.

Les détails de l’exception dans le client incluent l’ID de requête (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 recherchant dans la request-id-header colonne du fichier journal. Vous pouvez également utiliser les métriques pour savoir quand ce type d’erreurs se produit, puis effectuer une recherche dans les fichiers journaux sur base de l’heure à laquelle les métriques ont enregistré cette erreur. L’entrée du journal indique que la suppression a échoué avec un message d’état « HTTP (404) Client Other Error ». 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 du même client. Cette opération de suppression réussie s'est produite peu 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 (en utilisant le 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 rechercher pourquoi le client ne reçoit pas les accusés de réception du service de table. Si le problème est intermittent, vous devez capturer l’erreur « HTTP (404) Not Found » et la journaliser dans le client, mais permettre au client de continuer.

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

Le tableau suivant présente un extrait du journal côté serveur pour deux opérations clientes : DeleteIfExists suivi immédiatement CreateIfNotExists à l’aide du même nom de conteneur d’objets blob. Chaque opération cliente génère deux demandes envoyées au serveur, tout d’abord une GetContainerProperties demande pour vérifier si le conteneur existe, suivi de la ou CreateContainer de la DeleteContainer demande.

Le code de l’application cliente supprime, puis recrée immédiatement un conteneur d’objets blob à l’aide du même nom : la CreateIfNotExists méthode (ID de demande client bc881924-...) échoue finalement avec l’erreur HTTP 409 (conflit). Lorsqu’un client supprime des conteneurs d’objets blob, des tables ou des files d’attente, il y a un bref point avant que le nom ne soit à nouveau disponible.

Chaque fois qu'elle crée des conteneurs, l'application cliente utilise des noms de conteneur uniques si le modèle de suppression/recréation est commun.

Les métriques indiquent une valeur PercentSuccess faible ou les entrées du journal d’analyse incluent des opérations avec un statut de transaction ClientOtherErrors

La métrique PercentSuccess capture le pourcentage d'opérations réussies sur base de leur code d'état HTTP. Les opérations avec des codes d’état de 2XX comptent comme ayant réussi, tandis que les opérations avec des codes d’état dans les plages 3XX, 4XX et 5XX sont comptabilisées comme ayant échoué et réduisent la valeur de métrique PercentSuccess . Dans les fichiers journaux de stockage côté serveur, ces opérations sont enregistrées avec un statut de transaction 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 avec succès, mais qui génèrent des codes d'état HTTP d'échec :

• ResourceNotFound (introuvable 404), par exemple, d’une GET requête à 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 d’API REST courants que les services de stockage retournent sur la page Codes d’erreur de l’API REST commune.

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

Si vous constatez des changements soudains, inattendus dans l'utilisation de la capacité de votre compte de stockage, vous pouvez rechercher les raisons en consultant d’abord vos métriques de disponibilité. Par exemple, une augmentation du nombre de demandes de suppression qui échouent peut provoquer une augmentation du volume de stockage blob que vous utilisez, car les opérations de nettoyage spécifiques de l'application supposées libérer de l'espace peuvent ne pas fonctionner comme prévu (par exemple, suite à l'expiration des jetons SAS utilisés pour libérer de l'espace).

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

Vous utilisez généralement l’émulateur de stockage pendant le développement et le test pour éviter l’exigence d’un compte de stockage Azure. Voici les problèmes fréquents que vous êtes susceptible de rencontrer lors de l’utilisation de l’émulateur de stockage :

• La fonctionnalité « X » ne fonctionne pas dans l’émulateur de stockage.
• 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.
• L’exécution de l’émulateur de stockage nécessite des privilèges d’administration.

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, comme le service de fichiers. Pour plus d’informations, consultez Utilisation de l’émulateur de stockage Azure pour le développement et le test.

Pour accéder à ces fonctions non prises en charge par l’émulateur de stockage, vous devez utiliser le service de stockage Azure dans le cloud.

Erreur « The value for one of the HTTP headers is not in the correct format » (Le format de la valeur d’un des en-têtes HTTP est incorrect) 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 les appels de méthode tels que CreateIfNotExists l’échec 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 demandes qu’elle effectue. Si l’émulateur de stockage ne reconnaît pas la valeur dans l’en-tête x-ms-version , elle rejette la demande.

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

Ce scénario se produit généralement lorsque 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 pour le développement et le test.

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

Vous êtes invité à entrer vos informations d'identification d'administrateur lorsque vous exécutez l'émulateur de stockage. Cela ne se produit que lors de la toute première initialisation de l'émulateur de stockage. 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 Utilisation de l’émulateur de stockage Azure pour le développement et le test. Vous pouvez également initialiser l’émulateur de stockage dans Visual Studio, qui exige également des privilèges Administrateur.

Vous rencontrez des problèmes pendant 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 un des messages suivants :

• CAQuietExec: Error: Unable to access SQL instance (CAQuietExec : Erreur : Impossible d’accéder à l’instance SQL)
• CAQuietExec: Error: Unable to create database (CAQuietExec : Erreur : Impossible de créer la base de données)

La cause est un problème lié à 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 de tenter d'installer le Kit de développement logiciel (SDK).

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

La delete commande supprime 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 existe une modification de votre comportement de référence attendu. À partir des métriques, vous pouvez 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 afin de faciliter vos recherches dans vos données de journalisation côté serveur et obtenir des informations plus détaillées concernant les erreurs rencontrées. Ces informations peuvent vous aider à analyser et résoudre le problème.
• Si les informations contenues dans les journaux côté serveur ne suffisent pas 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 l’annexe 1 : Utilisation de Fiddler pour capturer le trafic HTTP et HTTPS.

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

Annexes

Les annexes décrivent plusieurs outils qui peuvent s’avérer utiles lors du diagnostic et de la résolution des problèmes liés à Azure Storage (et aux autres services). Ces outils ne font pas partie de Stockage Azure, et certains sont des produits tiers. Par conséquent, les outils abordés 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 l’analyse du trafic HTTP et HTTPS entre votre application cliente et le service de stockage Azure que vous utilisez.

Cette annexe explique brièvement comment configurer Fiddler pour capturer le trafic entre la machine locale sur laquelle vous avez installé Fiddler et les services de stockage Azure.

Après avoir lancé Fiddler, il commence à capturer le trafic HTTP et HTTPS de votre ordinateur local. Voici quelques commandes utiles pour contrôler Fiddler :

• Arrêt et démarrage de la capture du trafic. Dans le menu principal, accédez à Fichier , puis sélectionnez Capturer le trafic pour activer et désactiver la capture.
• Enregistrement des données de trafic capturées. Dans le menu principal, accédez à Fichier, sélectionnez Enregistrer, puis sélectionnez Toutes les sessions. Cela vous permet d’enregistrer le trafic dans un fichier d’archivage de session. Vous pouvez recharger une archive de session ultérieurement pour l’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 :

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 concernant les paquets pour de nombreux protocoles réseau.

La procédure suivante explique comment capturer des informations détaillées concernant les paquets pour le trafic à partir de la machine locale où vous avez installé Wireshark, vers le service de table de votre compte de stockage Azure.

1. Lancez Wireshark sur votre ordinateur local.

2. Dans la section Start , sélectionnez l'interface réseau locale ou des interfaces connectées à Internet.

3. Sélectionnez Options de capture.

4. Ajoutez un filtre à la zone de texte Capture Filter . 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.

   

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électionnez Capture>Stop dans le menu principal.

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

WireShark met en évidence toutes les erreurs détectées dans la fenêtre packetlist . Vous pouvez également utiliser la fenêtre Informations d’expert (sélectionnez Analyser les>informations d’expert) pour afficher un résumé des erreurs et des avertissements.

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

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

De nombreux outils vous permettent de télécharger les données métriques de stockage à partir du stockage de table Azure dans un format délimité, permettant leur chargement aisé dans Excel afin de les consulter ou les analyser. Les données de journalisation de Stockage Blob Azure sont déjà dans un format délimité qui peut être chargé dans Excel. Toutefois, vous devez ajouter des en-têtes de colonne appropriés en fonction des informations au format du journal Storage Analytics et au schéma de table de métriques Storage Analytics.

Pour importer vos données de journalisation du stockage dans Excel, après les avoir téléchargées à partir stockage d’objets blob :

• Dans le menu Données , sélectionnez À partir du texte.
• Accédez au fichier journal que vous souhaitez afficher et 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 guillemets doubles comme qualificateur de 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 votre analyse des performances et de la disponibilité. Cet outil permet de :

• Vous assurer 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 informer s’il existe un problème.
• Rapidement diagnostiquer tous les problèmes ou exceptions de performances rencontrés par votre service Web. Découvrez si l'UC ou d'autres ressources sont en difficulté, obtenez les traces de la pile à partir des exceptions et effectuez des recherches aisées dans les suivis de journalisation. Si les performances de l’application chutent en deçà des limites acceptables, Microsoft peut vous envoyer un e-mail. Vous pouvez analyser les services Web .NET et Java.

Plus d’informations sont disponibles dans Présentation d’Application Insights.

Étapes suivantes

Pour plus d’informations sur Analytics dans Stockage Azure, consultez ces ressources :

• Surveiller un compte de stockage dans le portail Azure
• Storage Analytics
• Métriques de Storage Analytics
• Schéma de table de métriques Storage Analytics
• Journaux d’activité Storage Analytics
• Format de journal d’activité Storage Analytics

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.