Statistiken zum Warteschlangendienst abrufen

  • Artikel

Der Get Queue Service Stats Vorgang ruft Statistiken im Zusammenhang mit der Replikation für Azure Queue Storage ab. Sie ist nur auf dem sekundären Standortendpunkt verfügbar, wenn die georedundante Replikation mit Lesezugriff für das Speicherkonto aktiviert ist.

Anforderung

Die Get Queue Service Stats-Anforderung kann wie folgt erstellt werden. Es wird empfohlen, HTTPS zu verwenden. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos, und beachten Sie, dass das sekundäre Suffix erforderlich ist:

Methode Anforderungs-URI HTTP-Version
GET https://myaccount-secondary.queue.core.windows.net/?restype=service&comp=stats HTTP/1.1

Hinweis

Der URI muss immer einen Schrägstrich (/) enthalten, um den Hostnamen von den Pfad- und Abfrageabschnitten des URI zu trennen. In diesem Vorgang ist der Pfadteil des URI leer.

URI-Parameter

Die folgenden zusätzlichen Parameter können für den Anforderungs-URI angegeben werden:

Parameter BESCHREIBUNG
Timeout Optional. Der timeout-Parameter wird in Sekunden angegeben.

Anforderungsheader

In der folgenden Tabelle werden erforderliche und optionale Anforderungsheader beschrieben.

Anforderungsheader BESCHREIBUNG
Authorization Erforderlich. Gibt das Autorisierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
Date or x-ms-date Erforderlich. Gibt die koordinierte Weltzeit (Coordinated Universal Time, UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
x-ms-version Erforderlich für alle autorisierten Anforderungen. Gibt die Version des für die Anforderung zu verwendenden Vorgangs an. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.
x-ms-client-request-id Optional. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem Zeichenlimit von 1 Kibibyte (KiB) bereit, der beim Konfigurieren der Protokollierung in den Protokollen aufgezeichnet wird. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt. Weitere Informationen finden Sie unter Überwachen von Azure Queue Storage.

Anforderungstext

Keine.

Antwort

Die Antwort enthält den HTTP-Statuscode, einen Satz von Antwortheadern und einen Antworttext.

Statuscode

Bei einem erfolgreichen Vorgang wird der Statuscode 200 (OK) zurückgegeben. Wenn er an einem sekundären Standortendpunkt aufgerufen wird, der für einen sekundären Lesevorgang nicht aktiviert ist, wird HTTP-status Code 403 (Unzureichende Kontoberechtigungen) zurückgegeben.

Antwortheader

Die Antwort für diesen Vorgang umfasst die folgenden Header. Die Antwort enthält außerdem weitere HTTP-Standardheader. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

Antwortheader BESCHREIBUNG
x-ms-request-id Identifiziert eindeutig die Anforderung, die gestellt wurde, und kann zur Problembehandlung für die Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung bei API-Vorgängen.
x-ms-version Gibt die Version des Vorgangs an, der für die Antwort verwendet wurde. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.
Date Ein UTC-Datums-/Uhrzeitwert, der vom Dienst generiert wird, der die Uhrzeit angibt, zu der die Antwort initiiert wurde.
x-ms-client-request-id Dieser Header kann zum Behandeln von Anforderungen und entsprechenden Antworten verwendet werden. Der Wert dieses Headers ist gleich dem Wert des x-ms-client-request-id Headers, wenn er in der Anforderung vorhanden ist und der Wert nicht mehr als 1.024 sichtbare ASCII-Zeichen enthält. Wenn der x-ms-client-request-id Header in der Anforderung nicht vorhanden ist, ist er in der Antwort nicht vorhanden.

Antworttext

Der Antworttext weist das folgende Format auf:

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

Die folgende Tabelle erläutert die Elemente des Antworttexts:

Antwortheader BESCHREIBUNG
Status Der Status des sekundären Standorts. Mögliche Werte:

- live: Gibt an, dass der sekundäre Standort aktiv und betriebsbereit ist.
- bootstrap: Gibt an, dass die anfängliche Synchronisierung vom primären Standort zum sekundären Speicherort ausgeführt wird. Dies tritt normalerweise auf, wenn die Replikation zuerst aktiviert wird.
- nicht verfügbar: Gibt an, dass der sekundäre Speicherort vorübergehend nicht verfügbar ist.
LastSyncTime Ein UTC-Datums-/Uhrzeitwert in Sekunden. Alle primären Schreibvorgänge, die diesem Wert vorangehen, sind garantiert für Lesevorgänge beim sekundären Schreibvorgang verfügbar. Primäre Schreibvorgänge nach diesem Zeitpunkt sind möglicherweise für Lesevorgänge verfügbar.

Der Wert kann leer sein, wenn LastSyncTime nicht verfügbar ist. Dies kann passieren, wenn die Replikation status Bootstrap ist oder nicht verfügbar ist.

Obwohl die Georeplikation kontinuierlich aktiviert ist, kann das LastSyncTime Ergebnis einen zwischengespeicherten Wert aus dem Dienst widerspiegeln, der alle paar Minuten aktualisiert wird.

Authorization

Dieser Vorgang kann nur vom Kontobesitzer aufgerufen werden.

Hinweise

Bei georedundanter Replikation verwaltet Azure Storage Ihre Daten dauerhaft an zwei Standorten. An beiden Standorten behält der Azure-Speicher mehrere fehlerfreie Replikate der Daten bei.

Der Standort, an dem Sie Daten lesen, erstellen, aktualisieren oder löschen, ist der primäre Speicherkontostandort. Der primäre Standort befindet sich in der Region, die Sie beim Erstellen eines Kontos über das klassische Azure Management-Azure-Portal (z. B. USA, Norden, Mitte) auswählen.

Als sekundärer Standort wird der Standort bezeichnet, an dem die Daten repliziert werden. Der sekundäre Standort befindet sich in einer Region, die automatisch geografisch mit der primären Region gekoppelt wird. Der schreibgeschützte Zugriff ist über den sekundären Standort verfügbar, wenn die georedundante Replikation mit Lesezugriff für das Speicherkonto aktiviert ist.

Weitere Informationen zur georedundanten Replikation mit Lesezugriff finden Sie unter Datenredundanz.

Um eine Anforderung für einen Lesevorgang für den sekundären Endpunkt zu erstellen, fügen -secondary Sie als Suffix an den Kontonamen im URI an, den Sie zum Lesen aus Warteschlangenspeicher verwenden. Ein sekundärer URI für den Vorgang Peek Messages ähnelt https://myaccount-secondary.queue.core.windows.net/myqueue/messages?peekonly=truebeispielsweise .

Beispielanforderung und -antwort

Im Folgenden finden Sie eine Beispielanforderung für den Get Queue Service Stats-Vorgang:

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

Die Anforderung wird mit den folgenden Headern gesendet:

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

Der Statuscode und die Antwortheader werden wie folgt zurückgegeben:

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

Die Antwort enthält den folgenden XML-Text:

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

Weitere Informationen

Vorgänge für das Konto (Warteschlangendienst)