Partager via


Obtention des statistiques du service BLOB

L’opération Get Blob Service Stats récupère les statistiques liées à la réplication pour Stockage Blob Azure. L’opération est disponible uniquement sur le point de terminaison de l’emplacement secondaire lorsque la réplication géoredondante avec accès en lecture est activée pour le compte de stockage.

Requête

Vous pouvez construire la Get Blob Service Stats requête comme suit. Nous vous recommandons d’utiliser HTTPS. Remplacez myaccount par le nom de votre compte de stockage et notez que le suffixe -secondary est obligatoire :

Méthode URI de demande Version HTTP
GET https://myaccount-secondary.blob.core.windows.net/?restype=service&comp=stats HTTP/1.1

Notes

L’URI doit toujours inclure une barre oblique (/) pour séparer le nom d’hôte des parties chemin d’accès et requête. Dans le cadre de cette opération, la partie de chemin d'accès de l'URI est vide.

Paramètres URI

Vous pouvez spécifier les paramètres supplémentaires suivants dans l’URI de requête :

Paramètre Description
Timeout facultatif. Le paramètre timeout est exprimé en secondes.

En-têtes de requête

Le tableau suivant décrit les en-têtes de demande obligatoires ou facultatifs.

En-tête de requête Description
Authorization Obligatoire. Spécifie le schéma d’autorisation, le nom du compte et la signature. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
Date or x-ms-date Obligatoire. Spécifie la date/heure en temps universel coordonné (UTC) pour la requête. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
x-ms-version Obligatoire pour toutes les demandes autorisées. Spécifie la version de l'opération à utiliser pour cette demande. Pour plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft Azure.
x-ms-client-request-id facultatif. Fournit une valeur opaque générée par le client avec une limite de caractères de 1 kibioctet (Kio) enregistrée dans les journaux lors de la configuration de la journalisation. Nous vous recommandons vivement d’utiliser cet en-tête pour mettre en corrélation les activités côté client avec les demandes que le serveur reçoit. Pour plus d’informations, consultez Surveiller Stockage Blob Azure.

Corps de la demande

Aucun.

response

La réponse inclut un code d'état HTTP, un ensemble d'en-têtes de réponse et un corps de réponse.

Code d’état

Une opération réussie envoie le code d'état 200 (OK). Lorsqu’une opération est appelée sur un point de terminaison d’emplacement secondaire qui n’est pas activé pour une lecture secondaire, elle retourne un code http status 403 avec une InsufficientAccountPermissions erreur.

En-têtes de réponse

La réponse de l'opération inclut les en-têtes suivants. La réponse peut également inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification du protocole HTTP/1.1.

En-tête de réponse Description
x-ms-request-id Identifie de manière unique la demande qui a été effectuée et vous pouvez l’utiliser pour résoudre la demande. Pour plus d’informations, consultez Résoudre les problèmes liés aux opérations d’API.
x-ms-version Spécifie la version de l’opération utilisée pour la réponse. Pour plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft Azure.
Date Valeur de date/heure UTC générée par le service, qui indique l’heure à laquelle la réponse a été lancée.
x-ms-client-request-id Peut être utilisé pour résoudre les problèmes liés aux demandes et aux réponses correspondantes. La valeur de cet en-tête est égale à la valeur de l’en-tête x-ms-client-request-id s’il est présent dans la requête et à la valeur ne dépassant pas 1 024 caractères ASCII visibles. Si l’en-tête x-ms-client-request-id n’est pas présent dans la demande, cet en-tête n’est pas présent dans la réponse.

Response body

Le corps de la réponse présente le format suivant :

<?xml version="1.0" encoding="utf-8"?>  
<StorageServiceStats>  
  <GeoReplication>        
      <Status>live|bootstrap|unavailable</Status>  
      <LastSyncTime>sync-time|<empty></LastSyncTime>  
  </GeoReplication>  
</StorageServiceStats>  

Les éléments du corps de la réponse sont décrits dans le tableau suivant :

En-tête de réponse Description
Status État de l'emplacement secondaire. Les valeurs possibles sont les suivantes :

- live: indique que l’emplacement secondaire est actif et opérationnel.
- bootstrap: indique que la synchronisation initiale de l’emplacement principal vers l’emplacement secondaire est en cours. Cela se produit généralement lorsque la réplication est activée pour la première fois.
- indisponible : indique que l’emplacement secondaire est temporairement indisponible.
LastSyncTime Valeur de date/heure GMT, à l'emplacement secondaire. Toutes les écritures primaires qui précèdent cette valeur sont garanties pour être disponibles pour les opérations de lecture au niveau secondaire. Les écritures primaires postérieures à ce point dans le temps peuvent ou non être disponibles pour les lectures.

La valeur peut être vide si LastSyncTime n’est pas disponible. Cela peut se produire si l'état de réplication est bootstrap ou unavailable.

Bien que la géoréplication soit activée en continu, le LastSyncTime résultat peut refléter une valeur mise en cache du service, qui est actualisée toutes les quelques minutes.

Autorisation

Une autorisation est requise lors de l’appel d’une opération d’accès aux données dans stockage Azure. Vous pouvez autoriser l’opération Get Blob Service Stats comme décrit ci-dessous.

Important

Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour autoriser les demandes dans le stockage Azure. Microsoft Entra ID offre une sécurité et une facilité d’utilisation supérieures par rapport à l’autorisation de clé partagée.

Le Stockage Azure prend en charge l’utilisation de Microsoft Entra ID pour autoriser les demandes de données blob. Avec Microsoft Entra ID, vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour accorder des autorisations à un principal de sécurité. Le principal de sécurité peut être un utilisateur, un groupe, un principal de service d’application ou une identité managée Azure. Le principal de sécurité est authentifié par Microsoft Entra ID pour retourner un jeton OAuth 2.0. Le jeton peut ensuite être utilisé pour autoriser une requête auprès du service BLOB.

Pour en savoir plus sur l’autorisation à l’aide de Microsoft Entra ID, consultez Autoriser l’accès aux objets blob à l’aide de Microsoft Entra ID.

Autorisations

Vous trouverez ci-dessous l’action RBAC nécessaire pour qu’un utilisateur, un groupe, une identité managée ou un principal de service Microsoft Entra appelle l’opérationGet Blob Service Stats, ainsi que le rôle RBAC Azure intégré le moins privilégié qui inclut cette action :

Pour en savoir plus sur l’attribution de rôles à l’aide d’Azure RBAC, consultez Attribuer un rôle Azure pour accéder aux données blob.

Remarques

Avec la réplication géoredondante, Stockage Azure conserve durablement vos données dans deux emplacements séparés de plusieurs centaines de kilomètres. Dans les deux emplacements, le stockage Azure conserve constamment plusieurs réplicas sains de vos données.

Une paire géoredondante comprend :

  • Emplacement principal : emplacement où vous lisez, créez, mettez à jour ou supprimez des données. L’emplacement principal existe dans la région que vous choisissez lorsque vous créez un compte via le portail Azure Classic (par exemple, USA Centre-Nord).

  • Emplacement secondaire : emplacement vers lequel vos données sont répliquées. L’emplacement secondaire réside dans une région qui est automatiquement associée géographiquement à la région primaire. L’accès en lecture seule est disponible à partir de l’emplacement secondaire si la réplication géoredondante avec accès en lecture est activée pour votre compte de stockage. Pour plus d’informations sur la réplication géoredondante avec accès en lecture, consultez Redondance des données.

L'emplacement où vous lisez, créez, mettez à jour ou supprimez les données est l'emplacement du compte de stockage principal. L’emplacement principal existe dans la région que vous choisissez au moment de créer un compte via le portail Azure Management Azure Classic, par exemple, USA Centre-Nord. L'emplacement dans lequel vos données sont répliquées est l'emplacement secondaire. L’emplacement secondaire réside dans une région qui est automatiquement associée géographiquement à la région primaire. L'accès en lecture seule est disponible à partir de l'emplacement secondaire, si la réplication géographique redondante avec accès en lecture est activée pour votre compte de stockage. Pour plus d’informations sur la réplication géoredondante avec accès en lecture, consultez Redondance des données.

Pour créer une demande d’opération de lecture sur le point de terminaison secondaire, ajoutez -secondary au nom du compte dans l’URI que vous utilisez pour lire à partir du Stockage Blob. Par exemple, un URI secondaire pour l’opération Get Blob sera similaire à https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob.

Facturation

Les demandes de tarification peuvent provenir de clients qui utilisent des API Stockage Blob, soit directement via l’API REST Stockage Blob, soit à partir d’une bibliothèque cliente stockage Azure. Ces demandes cumulent des frais par transaction. Le type de transaction affecte la façon dont le compte est facturé. Par exemple, les transactions de lecture sont comptabilisées dans une catégorie de facturation différente de celle des transactions en écriture. Le tableau suivant montre la catégorie de facturation pour Get Blob Service Stats les demandes en fonction du type de compte de stockage :

Opération Type de compte de stockage Catégorie de facturation
Obtention des statistiques du service BLOB Objet blob de blocs Premium
Usage général v2 Standard
Autres opérations
Obtention des statistiques du service BLOB Usage général v1 standard Lire les opérations

Pour en savoir plus sur la tarification de la catégorie de facturation spécifiée, consultez Stockage Blob Azure Tarification.

Exemple de requête et de réponse

Voici un exemple de demande pour l’opération Get Blob Service Stats :

GET http://myaccount-secondary.blob.core.windows.net/?restype=service&comp=stats HTTP/1.1  

La demande est envoyée avec les en-têtes suivants :

x-ms-version: 2013-08-15  
x-ms-date: Wed, 23 Oct 2013 22:08:44 GMT  
Authorization: SharedKey myaccount:CY1OP3O3jGFpYFbTCBimLn0Xov0vt0khH/E5Gy0fXvg=  

Le code d'état et les en-têtes de réponse sont renvoyés comme suit :

HTTP/1.1 200 OK  
Content-Type: application/xml  
Date: Wed, 23 Oct 2013 22:08:54 GMT  
x-ms-version: 2013-08-15  
x-ms-request-id: cb939a31-0cc6-49bb-9fe5-3327691f2a30  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  

Cette réponse comprend le corps XML suivant :

<?xml version="1.0" encoding="utf-8"?>  
<StorageServiceStats>  
  <GeoReplication>  
      <Status>live</Status>  
      <LastSyncTime> Wed, 23 Oct 2013 22:05:54 GMT</LastSyncTime>        
  </GeoReplication>  
</StorageServiceStats>  

Voir aussi

Opérations sur le compte (Stockage Blob)