Obtention des statistiques du service de File d'attente
L’opération Get Queue Service Stats récupère les statistiques relatives à la réplication pour le Stockage File d’attente Azure. Elle 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
La demande Get Queue Service Stats peut être construite comme indiqué ci-dessous. Nous vous recommandons d’utiliser HTTPS. Remplacez myaccount par le nom de votre compte de stockage et notez que le suffixe -secondary est requis :
| Méthode | URI de demande | Version HTTP |
|---|---|---|
| GET | https://myaccount-secondary.queue.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 de l’URI. Dans cette opération, la partie chemin d’accès de l’URI est vide.
Paramètres URI
Les paramètres supplémentaires suivants peuvent être spécifiés sur 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 |
Optionnel. 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 le stockage File d’attente 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’il est appelé sur un point de terminaison d’emplacement secondaire qui n’est pas activé pour une lecture secondaire, il retourne le code HTTP status 403 (Autorisations de compte insuffisantes).
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 peut être utilisée 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 |
Cet en-tête 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 que la valeur ne contient pas plus de 1 024 caractères ASCII visibles. Si l’en-tête x-ms-client-request-id n’est pas présent dans la demande, il ne sera 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 UTC, en secondes. Toutes les écritures primaires qui précèdent cette valeur sont garanties pour être disponibles pour les opérations de lecture à l’écriture 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 le status de réplication est bootstrap ou non disponible.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
Seul le propriétaire du compte peut appeler cette opération.
Notes
Avec la réplication géoredondante, stockage Azure gère vos données durablement dans deux emplacements. Dans les deux emplacements, le stockage Azure conserve constamment plusieurs réplicas sains de vos 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 lorsque vous créez 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 construire une demande d’opération de lecture sur le point de terminaison secondaire, ajoutez -secondary en tant que suffixe au nom du compte dans l’URI que vous utilisez pour lire à partir du stockage file d’attente. Par exemple, un URI secondaire pour l’opération Aperçu des messages est similaire à https://myaccount-secondary.queue.core.windows.net/myqueue/messages?peekonly=true.
Exemple de requête et de réponse
Cet exemple illustre une demande de l'opération Get Queue Service Stats :
GET http://myaccount-secondary.queue.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-Queue/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>