Statistiken zum Blob-Dienst abrufen

Artikel
02/07/2024

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

Anforderung

Sie können die Get Blob Service Stats Anforderung wie folgt erstellen. Es wird empfohlen, HTTPS zu verwenden. Ersetzen Sie myaccount durch den Namen des Speicherkontos, und beachten Sie, dass das Suffix -secondary erforderlich ist:

Methode	Anforderungs-URI	HTTP-Version
GET	`https://myaccount-secondary.blob.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 zu trennen. Bei diesem Vorgang ist der Pfadteil des URIs leer.

URI-Parameter

Sie können im Anforderungs-URI die folgenden zusätzlichen Parameter angeben:

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 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 Azure Blob 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 ein Vorgang für einen sekundären Standortendpunkt aufgerufen wird, der für einen sekundären Lesevorgang nicht aktiviert ist, gibt er den HTTP-status Code 403 mit einem Fehler zurückInsufficientAccountPermissions.

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 die durchgeführte Anforderung eindeutig, und Sie können sie zur Problembehandlung für die Anforderung verwenden. 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 wird. 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 dem Wert, der nicht mehr als 1.024 sichtbare ASCII-Zeichen beträgt. Wenn der `x-ms-client-request-id` Header in der Anforderung nicht vorhanden ist, ist dieser Header 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 sekundengenauer Datums-/Uhrzeitwert (GMT). Alle primären Schreibvorgänge, die diesem Wert vorangehen, sind garantiert für Lesevorgänge auf dem sekundären Computer 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 der Fall sein, wenn der Replikationsstatus bootstrap oder unavailable 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.

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 sekundengenauer Datums-/Uhrzeitwert (GMT). Alle primären Schreibvorgänge, die diesem Wert vorangehen, sind garantiert für Lesevorgänge auf dem sekundären Computer 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 der Fall sein, wenn der Replikationsstatus `bootstrap` oder `unavailable` 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

Beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage ist eine Autorisierung erforderlich. Sie können den Get Blob Service Stats Vorgang wie unten beschrieben autorisieren.

Azure Storage unterstützt die Verwendung von Microsoft Entra ID zum Autorisieren von Anforderungen für Blobdaten. Mit Microsoft Entra ID können Sie die rollenbasierte Zugriffssteuerung von Azure (Azure RBAC) verwenden, um einem Sicherheitsprinzipal Berechtigungen zu erteilen. Der Sicherheitsprinzipal kann ein Benutzer, eine Gruppe, ein Anwendungsdienstprinzipal oder eine verwaltete Azure-Identität sein. Der Sicherheitsprinzipal wird von Microsoft Entra ID authentifiziert, um ein OAuth 2.0-Token zurückzugeben. Das Token kann anschließend zum Autorisieren einer Anforderung an den Blob-Dienst verwendet werden.

Weitere Informationen zur Autorisierung mit Microsoft Entra ID finden Sie unter Autorisieren des Zugriffs auf Blobs mithilfe von Microsoft Entra ID.

Berechtigungen

Unten sind die RBAC-Aktion aufgeführt, die für einen Microsoft Entra Benutzer, eine Gruppe oder einen Dienstprinzipal erforderlich ist, um den Get Blob Service Stats Vorgang aufzurufen, und die integrierte Azure RBAC-Rolle mit den geringsten Berechtigungen, die diese Aktion enthält:

Azure RBAC-Aktion:Microsoft.Storage/storageAccounts/blobServices/read
Integrierte Rolle mit den geringsten Rechten:Mitwirkender für Speicherkonten

Weitere Informationen zum Zuweisen von Rollen mithilfe von Azure RBAC finden Sie unter Zuweisen einer Azure-Rolle für den Zugriff auf Blobdaten.

Eine Shared Access Signature (SAS) bietet sicheren delegierten Zugriff auf Ressourcen in einem Speicherkonto. Mit einer SAS haben Sie eine präzise Kontrolle darüber, wie ein Client auf Daten zugreifen kann. Sie können angeben, auf welche Ressource der Client zugreifen darf, über welche Berechtigungen er für diese Ressourcen verfügt und wie lange die SAS gültig ist.

Der Get Blob Service Stats Vorgang unterstützt die Autorisierung mithilfe einer Konto-SAS.

Wenn der Zugriff auf freigegebene Schlüssel für das Speicherkonto nicht zulässig ist, wird ein Konto-SAS-Token für eine Anforderung an Blob Storage nicht zulässig. Weitere Informationen finden Sie unter Grundlegendes dazu, wie sich das Aufheben der Zuordnung von freigegebenem Schlüssel auf SAS-Token auswirkt.

Konto-SAS

Eine Konto-SAS wird mit dem Speicherkontoschlüssel geschützt. Eine Konto-SAS delegiert den Zugriff auf Ressourcen in einem oder mehreren der Speicherdienste. Alle Vorgänge, die über eine Dienst-SAS oder eine SAS für die Benutzerdelegierung verfügbar sind, sind auch über eine Konto-SAS verfügbar.

In der folgenden Tabelle sind der signierte Ressourcentyp und die signierten Berechtigungen angegeben, die beim Delegieren des Zugriffs angegeben werden sollen:

Vorgang	Signierter Dienst	Signierter Ressourcentyp	Signierte Berechtigung
Statistiken zum Blob-Dienst abrufen	Blob (b)	Dienst(en)	Lesen (r)

Weitere Informationen zur Konto-SAS finden Sie unter Erstellen einer Konto-SAS.

Der Get Blob Service Stats Vorgang unterstützt die Freigabeschlüsselautorisierung. Die Autorisierung mit Kontoschlüsseln wird für die meisten Szenarien nicht empfohlen, da sie weniger sicher ist. Microsoft empfiehlt, die Autorisierung mit freigegebenem Schlüssel für das Speicherkonto nach Möglichkeit nicht zu verwenden. Weitere Informationen finden Sie unter Verhindern der Autorisierung mit gemeinsam verwendetem Schlüssel.

Hinweise

Bei georedundanter Replikation verwaltet Azure Storage Ihre Daten dauerhaft an zwei Standorten, die Hunderte von Meilen voneinander entfernt sind. An beiden Standorten behält der Azure-Speicher mehrere fehlerfreie Replikate der Daten bei.

Ein georedundantes Paar umfasst Folgendes:

Primärer Speicherort: Der Speicherort, an dem Sie Daten lesen, erstellen, aktualisieren oder löschen. Der primäre Standort befindet sich in der Region, die Sie beim Erstellen eines Kontos über das klassische Azure-Portal (z. B. USA, Norden, Mitte) auswählen.
Ein sekundärer Speicherort: Der Speicherort, an den Ihre Daten repliziert werden. Der sekundäre Standort befindet sich in einer Region, die automatisch geografisch mit der primären Region gekoppelt wird. Schreibgeschützter Zugriff ist vom sekundären Standort aus verfügbar, wenn die georedundante Replikation mit Lesezugriff für Ihr Speicherkonto aktiviert ist. Weitere Informationen zur georedundanten Replikation mit Lesezugriff finden Sie unter Datenredundanz.

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 zum Zeitpunkt der Erstellung eines Kontos über das klassische Azure Management-Azure-Portal ausgewählt haben, z. B. USA, Norden, Mitte. 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 an den Kontonamen im URI an, den Sie zum Lesen aus Blob Storage verwenden. Ein sekundärer URI für den Vorgang "Blob abrufen" ähnelt https://myaccount-secondary.blob.core.windows.net/mycontainer/myblobbeispielsweise .

Abrechnung

Preisanforderungen können von Clients stammen, die Blob Storage-APIs verwenden, entweder direkt über die Blob Storage-REST-API oder aus einer Azure Storage-Clientbibliothek. Für diese Anforderungen fallen Gebühren pro Transaktion an. Die Art der Transaktion wirkt sich auf die Belastung des Kontos aus. Beispielsweise werden Lesetransaktionen in eine andere Abrechnungskategorie als das Schreiben von Transaktionen angewendet. Die folgende Tabelle zeigt die Abrechnungskategorie für Get Blob Service Stats Anforderungen basierend auf dem Speicherkontotyp:

Vorgang	Speicherkontotyp	Abrechnungskategorie
Statistiken zum Blob-Dienst abrufen	Premium, Blockblob Standard „Allgemein v2“	Weitere Vorgänge
Statistiken zum Blob-Dienst abrufen	Standard „Allgemein v1“	Dient zum Lesen von Vorgängen.

Weitere Informationen zu Preisen für die angegebene Abrechnungskategorie finden Sie unter Azure Blob Storage Preise.

Beispielanforderung und -antwort

Hier sehen Sie eine Beispielanforderung für den Get Blob Service Stats Vorgang:

GET http://myaccount-secondary.blob.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-Blob/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 (Blob Storage)