Dela via

Hämta statistik för blobtjänsten

  • Artikel

Åtgärden Get Blob Service Stats hämtar statistik som är relaterad till replikering för Azure Blob Storage. Åtgärden är endast tillgänglig på den sekundära platsslutpunkten när geo-redundant replikering med läsbehörighet är aktiverad för lagringskontot.

Förfrågan

Du kan skapa begäran på Get Blob Service Stats följande sätt. Vi rekommenderar att du använder HTTPS. Ersätt myaccount med namnet på ditt lagringskonto och observera att suffixet -secondary krävs:

Metod URI för förfrågan HTTP-version
GET https://myaccount-secondary.blob.core.windows.net/?restype=service&comp=stats HTTP/1.1

Anteckning

URI:n måste alltid innehålla ett snedstreck (/) för att skilja värdnamnet från sökvägen och frågedelarna. När det gäller den här åtgärden är sökvägsdelen av URI:n tom.

URI-parametrar

Du kan ange följande ytterligare parametrar för begärande-URI:n:

Parameter Beskrivning
Timeout Valfritt. Parametern timeout uttrycks i sekunder.

Begärandehuvuden

I följande tabell beskrivs obligatoriska och valfria begärandehuvuden.

Begärandehuvud Beskrivning
Authorization Krävs. Anger auktoriseringsschema, kontonamn och signatur. Mer information finns i Auktorisera begäranden till Azure Storage.
Date or x-ms-date Krävs. Anger Coordinated Universal Time (UTC) för begäran. Mer information finns i Auktorisera begäranden till Azure Storage.
x-ms-version Krävs för alla auktoriserade begäranden. Anger vilken version av åtgärden som ska användas för den här begäran. Mer information finns i Versionshantering för Azure Storage-tjänsterna.
x-ms-client-request-id Valfritt. Tillhandahåller ett klientgenererat, täckande värde med en teckengräns på 1 kibibyte (KiB) som registreras i loggarna när loggningen har konfigurerats. Vi rekommenderar starkt att du använder det här huvudet för att korrelera aktiviteter på klientsidan med begäranden som servern tar emot. Mer information finns i Övervaka Azure Blob Storage.

Begärandetext

Inga.

Svarsåtgärder

Svaret innehåller en HTTP-statuskod, en uppsättning svarshuvuden och en svarstext

Statuskod

En lyckad åtgärd returnerar statuskoden 200 (OK). När en åtgärd anropas på en sekundär platsslutpunkt som inte är aktiverad för en sekundär läsning returneras en HTTP-statuskod på 403 med ett InsufficientAccountPermissions fel.

Svarshuvuden

Svaret för den här åtgärden innehåller följande rubriker. Svaret innehåller även ytterligare HTTP-standardhuvuden. Alla standardhuvuden överensstämmer med HTTP/1.1-protokollspecifikationen.

Svarsrubrik Description
x-ms-request-id Identifierar begäran som gjordes unikt och du kan använda den för att felsöka begäran. Mer information finns i Felsöka API-åtgärder.
x-ms-version Anger vilken version av åtgärden som används för svaret. Mer information finns i Versionshantering för Azure Storage-tjänsterna.
Date Ett UTC-datum/tid-värde som genereras av tjänsten, vilket anger den tid då svaret initierades.
x-ms-client-request-id Kan användas för att felsöka begäranden och deras motsvarande svar. Värdet för det här huvudet är lika med värdet för x-ms-client-request-id huvudet om det finns i begäran och värdet inte är mer än 1 024 synliga ASCII-tecken. x-ms-client-request-id Om rubriken inte finns i begäran finns inte det här huvudet i svaret.

Själva svaret

Formatet för svarstexten är följande:

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

Elementen i svarstexten beskrivs i följande tabell:

Svarsrubrik Description
Status Status för den sekundära platsen. Möjliga värden:

- live: Anger att den sekundära platsen är aktiv och i drift.
- bootstrap: Anger att den inledande synkroniseringen från den primära platsen till den sekundära platsen pågår. Detta inträffar vanligtvis när replikering först aktiveras.
- otillgänglig: Anger att den sekundära platsen är tillfälligt otillgänglig.
LastSyncTime Ett GMT-datum/tid-värde, till det andra. Alla primära skrivningar som föregår det här värdet är garanterade tillgängliga för läsåtgärder på den sekundära. Primära skrivningar efter den här tidpunkten kanske eller kanske inte är tillgängliga för läsningar.

Värdet kan vara tomt om LastSyncTime det inte är tillgängligt. Detta kan inträffa om replikeringsstatusen är bootstrap eller unavailable.

Även om geo-replikering är kontinuerligt aktiverat LastSyncTime kan resultatet återspegla ett cachelagrat värde från tjänsten, som uppdateras med några minuters mellanrum.

Auktorisering

Auktorisering krävs när du anropar en dataåtkomståtgärd i Azure Storage. Du kan auktorisera åtgärden enligt beskrivningen Get Blob Service Stats nedan.

Viktigt

Microsoft rekommenderar att du använder Microsoft Entra ID med hanterade identiteter för att auktorisera begäranden till Azure Storage. Microsoft Entra ID ger överlägsen säkerhet och användarvänlighet jämfört med auktorisering av delad nyckel.

Azure Storage stöder användning av Microsoft Entra ID för att auktorisera begäranden till blobdata. Med Microsoft Entra ID kan du använda rollbaserad åtkomstkontroll i Azure (Azure RBAC) för att bevilja behörigheter till ett säkerhetsobjekt. Säkerhetsobjektet kan vara en användare, grupp, programtjänstens huvudnamn eller en hanterad Azure-identitet. Säkerhetsobjektet autentiseras av Microsoft Entra ID för att returnera en OAuth 2.0-token. Token kan sedan användas för att auktorisera en begäran mot Blob-tjänsten.

Mer information om auktorisering med Microsoft Entra ID finns i Auktorisera åtkomst till blobar med Microsoft Entra ID.

Behörigheter

Nedan visas den RBAC-åtgärd som krävs för att en Microsoft Entra användare, grupp, hanterad identitet eller tjänstens huvudnamn ska anropa Get Blob Service Stats åtgärden och den minst privilegierade inbyggda Azure RBAC-rollen som inkluderar den här åtgärden:

Mer information om hur du tilldelar roller med Azure RBAC finns i Tilldela en Azure-roll för åtkomst till blobdata.

Kommentarer

Med geo-redundant replikering underhåller Azure Storage dina data på två platser som ligger hundratals mil från varandra. På båda platserna underhåller Azure Storage ständigt flera felfria repliker av dina data.

Ett geo-redundant par innehåller:

  • En primär plats: Den plats där du läser, skapar, uppdaterar eller tar bort data. Den primära platsen finns i den region som du väljer när du skapar ett konto via den klassiska Azure-portalen (till exempel USA, norra centrala).

  • En sekundär plats: Den plats som dina data replikeras till. Den sekundära platsen finns i en region som automatiskt paras ihop med den primära regionen. Skrivskyddad åtkomst är tillgänglig från den sekundära platsen om geo-redundant replikering med läsbehörighet är aktiverad för ditt lagringskonto. Mer information om geo-redundant replikering med läsbehörighet finns i Dataredundans.

Platsen där du läser, skapar, uppdaterar eller tar bort data är den primära lagringskontoplatsen. Den primära platsen finns i den region som du väljer när du skapar ett konto via den klassiska Azure-portalen för Azure Management, till exempel USA, norra centrala. Den plats som dina data replikeras till är den sekundära platsen. Den sekundära platsen finns i en region som automatiskt paras ihop med den primära regionen. Skrivskyddad åtkomst är tillgänglig från den sekundära platsen, om geo-redundant replikering med läsbehörighet är aktiverad för ditt lagringskonto. Mer information om geo-redundant replikering med läsåtkomst finns i Dataredundans.

Om du vill skapa en begäran om en läsåtgärd mot den sekundära slutpunkten lägger du -secondary till kontonamnet i den URI som du använder för att läsa från Blob Storage. En sekundär URI för åtgärden Hämta blob liknar till https://myaccount-secondary.blob.core.windows.net/mycontainer/myblobexempel .

Fakturering

Prisbegäranden kan komma från klienter som använder Blob Storage-API:er, antingen direkt via REST-API:et för Blob Storage eller från ett Azure Storage-klientbibliotek. Dessa begäranden ackumulerar avgifter per transaktion. Typen av transaktion påverkar hur kontot debiteras. Lästransaktioner till exempel tillfaller en annan faktureringskategori än skrivtransaktioner. I följande tabell visas faktureringskategorin för Get Blob Service Stats begäranden baserat på lagringskontotypen:

Åtgärd Typ av lagringskonto Faktureringskategori
Hämta statistik för blobtjänsten Premium-blockblob
Standard generell användning v2		 Andra åtgärder
Hämta statistik för blobtjänsten Standard generell användning v1 Läsåtgärder

Mer information om priser för den angivna faktureringskategorin finns i Azure Blob Storage Prissättning.

Exempel på begäran och svar

Här är en exempelbegäran för åtgärden Get Blob Service Stats :

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

Begäran skickas med följande rubriker:

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

Statuskoden och svarshuvudena returneras på följande sätt:

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

Svaret innehåller följande XML-brödtext:

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

Se även

Åtgärder för kontot (Blob Storage)