Obtention des statistiques du service BLOB

Article
02/07/2024

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 d’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 de chemin d’accès et de 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 reçues par le serveur. 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 de 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 les problèmes de 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 demandes et leurs 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 normalement 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 d’être disponibles pour les opérations de lecture au niveau secondaire. Les écritures primaires passées 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 permanence, le LastSyncTime résultat peut refléter une valeur mise en cache du service, qui est actualisée toutes les quelques minutes.

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 normalement 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 d’être disponibles pour les opérations de lecture au niveau secondaire. Les écritures primaires passées 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 permanence, 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.

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 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 :

Action RBAC Azure :Microsoft.Storage/storageAccounts/blobServices/read
Rôle intégré le moins privilégié :Contributeur de compte de stockage

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

Une signature d’accès partagé (SAP) fournit un accès délégué sécurisé aux ressources d’un compte de stockage. Avec une SAP, vous disposez d’un contrôle granulaire sur la façon dont un client peut accéder aux données. Vous pouvez spécifier la ressource à laquelle le client peut accéder, les autorisations dont il dispose sur ces ressources et la durée de validité de la SAP.

L’opération Get Blob Service Stats prend en charge l’autorisation à l’aide d’une sape de compte.

Lorsque l’accès à la clé partagée est interdit pour le compte de stockage, un jeton SAP de compte n’est pas autorisé lors d’une demande adressée au stockage Blob. Pour plus d’informations, consultez Comprendre comment l’interdiction de la clé partagée affecte les jetons SAP.

SAP de compte

Une SAP de compte est sécurisée à l’aide de la clé de compte de stockage. Une SAP de compte délègue l’accès aux ressources d’un ou plusieurs des services de stockage. Toutes les opérations disponibles via une SAP de service ou de délégation d’utilisateur sont également disponibles via une SAP de compte.

Le tableau suivant indique le type de ressource signé et les autorisations signées à spécifier lors de la délégation de l’accès :

Opération	Service signé	Type de ressource signé	Autorisation signée
Obtention des statistiques du service BLOB	Objet blob (b)	Service(s)	Lecture (r)

Pour en savoir plus sur la SAP de compte, consultez Créer une SAP de compte.

L’opération Get Blob Service Stats prend en charge l’autorisation de clé partagée. L’autorisation avec des clés de compte n’est pas recommandée dans la plupart des scénarios, car elle est moins sécurisée. Microsoft recommande d’interdire l’autorisation de clé partagée pour le compte de stockage lorsque cela est possible. Pour plus d’informations, consultez Empêcher l’autorisation avec une clé partagée.

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)