Get Table Service Stats (Abrufen der Tabellendienststatistik)

  • Artikel

Der Get Table Service Stats Vorgang ruft Statistiken ab, die sich auf die Replikation für Azure Table Storage beziehen. Sie ist nur auf dem Endpunkt des sekundären Standorts verfügbar, wenn die georedundante Replikation mit Lesezugriff für das Speicherkonto aktiviert ist.

Anforderung

Die Get Table 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 Suffix -secondary erforderlich ist:

Methode Anforderungs-URI HTTP-Version
GET https://myaccount-secondary.table.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. Bei 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

Die erforderlichen und optionalen Anforderungsheader werden in der folgenden Tabelle 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 in den Protokollen aufgezeichnet wird, wenn die Protokollierung konfiguriert ist. 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 Table 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 es auf einem sekundären Standortendpunkt aufgerufen wird, der nicht für einen sekundären Lesevorgang 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 für API-Vorgänge.
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 den Zeitpunkt angibt, zu dem die Antwort initiiert wurde.
x-ms-client-request-id Kann zur Problembehandlung von Anforderungen und deren 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 erste Synchronisierung vom primären Standort zum sekundären Standort 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 bis zur Sekunde. 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 ist möglicherweise leer, 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, spiegelt das LastSyncTime Ergebnis möglicherweise einen zwischengespeicherten Wert aus dem Dienst wider, der alle paar Minuten aktualisiert wird.

Authorization

Dieser Vorgang kann nur vom Kontobesitzer aufgerufen werden.

Hinweise

Mit georedundanter Replikation verwaltet Azure Storage Ihre Daten dauerhaft an zwei Standorten. An beiden Standorten verwaltet Azure Storage ständig mehrere fehlerfreie Replikate der Daten.

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-Portal der Azure-Verwaltung (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 Sie -secondary an den Kontonamen in dem URI an, den Sie zum Lesen aus Dem Tabellenspeicher verwenden. Ein sekundärer URI für den Vorgang Abfrageentitäten ähnelt https://myaccount-secondary.table.core.windows.net/mytable(PartitionKey='<partition-key>',RowKey='<row-key>')beispielsweise .

Beispielanforderung und -antwort

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

GET http://myaccount-secondary.table.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-Table/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 (Tabellendienst)