Get Queue Service Stats
Get Queue Service Stats operation retrieves statistics related to replication for Azure Queue Storage. It's available only on the secondary location endpoint when read-access geo-redundant replication is enabled for the storage account.
Get Queue Service Stats request may be constructed as follows. We recommend that you use HTTPS. Replace myaccount with the name of your storage account, and note that the -secondary suffix is required:
|Method||Request URI||HTTP version|
The URI must always include a slash character (/) to separate the hostname from the path and query portions of the URI. In this operation, the path portion of the URI is empty.
The following additional parameters may be specified on the request URI:
The following table describes required and optional request headers.
||Required. Specifies the authorization scheme, account name, and signature. For more information, see Authorize requests to Azure Storage.|
||Required. Specifies the Coordinated Universal Time (UTC) for the request. For more information, see Authorize requests to Azure Storage.|
||Required for all authorized requests. Specifies the version of the operation to use for this request. For more information, see Versioning for the Azure Storage services.|
||Optional. Provides a client-generated, opaque value with a 1-kibibyte (KiB) character limit that's recorded in the logs when logging is configured. We highly recommend that you use this header to correlate client-side activities with requests that the server receives. For more information, see Monitor Azure Queue Storage.|
The response includes an HTTP status code, a set of response headers, and a response body.
A successful operation returns status code 200 (OK). When it's called on a secondary location endpoint that's not enabled for a secondary read, it returns HTTP status code 403 (Insufficient Account Permissions).
The response for this operation includes the following headers. The response also includes additional standard HTTP headers. All standard headers conform to the HTTP/1.1 protocol specification.
||Uniquely identifies the request that was made and can be used to troubleshoot the request. For more information, see Troubleshoot API operations.|
||Specifies the version of the operation that was used for the response. For more information, see Versioning for the Azure Storage services.|
||A UTC date/time value that's generated by the service, which indicates the time when the response was initiated.|
||This header can be used to troubleshoot requests and corresponding responses. The value of this header is equal to the value of the
The format of the response body is as follows:
<?xml version="1.0" encoding="utf-8"?> <StorageServiceStats> <GeoReplication> <Status>live|bootstrap|unavailable</Status> <LastSyncTime>sync-time|<empty></LastSyncTime> </GeoReplication> </StorageServiceStats>
The elements of the response body are described in the following table:
||The status of the secondary location. Possible values are:
- live: Indicates that the secondary location is active and operational.
- bootstrap: Indicates that the initial synchronization from the primary location to the secondary location is in progress. This ordinarily occurs when replication is first enabled.
- unavailable: Indicates that the secondary location is temporarily unavailable.
||A UTC date/time value, in seconds. All primary writes that precede this value are guaranteed to be available for read operations at the secondary write. Primary writes after this point in time might or might not be available for reads.
The value might be empty if
Although geo-replication is continuously enabled, the
Only the account owner may call this operation.
With geo-redundant replication, Azure Storage maintains your data durably in two locations. In both locations, Azure Storage constantly maintains multiple healthy replicas of your data.
The location where you read, create, update, or delete data is the primary storage account location. The primary location exists in the region that you choose when you create an account via the Azure Management Azure classic portal (for example, North Central US).
The location to which your data is replicated is the secondary location. The secondary location resides in a region that's automatically geographically paired with the primary region. Read-only access is available from the secondary location, if read-access geo-redundant replication is enabled for your storage account.
For more information about read-access geo-redundant replication, see Data redundancy.
To construct a request for a read operation against the secondary endpoint, append
-secondary as a suffix to the account name in the URI that you use to read from Queue Storage. For example, a secondary URI for the Peek Messages operation is similar to
Sample request and response
The following is a sample request for the
Get Queue Service Stats operation:
GET http://myaccount-secondary.queue.core.windows.net/?restype=service&comp=stats HTTP/1.1
The request is sent with following headers:
x-ms-version: 2013-08-15 x-ms-date: Wed, 23 Oct 2013 22:08:44 GMT Authorization: SharedKey myaccount:CY1OP3O3jGFpYFbTCBimLn0Xov0vt0khH/E5Gy0fXvg=
The status code and response headers are returned as follows:
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
The response includes the following XML body:
<?xml version="1.0" encoding="utf-8"?> <StorageServiceStats> <GeoReplication> <Status>live</Status> <LastSyncTime> Wed, 23 Oct 2013 22:05:54 GMT</LastSyncTime> </GeoReplication> </StorageServiceStats>