Blob Service-statistieken ophalen

Met Get Blob Service Stats de bewerking worden statistieken opgehaald die betrekking hebben op replicatie voor Azure Blob Storage. De bewerking is alleen beschikbaar op het eindpunt van de secundaire locatie wanneer geografisch redundante replicatie met leestoegang is ingeschakeld voor het opslagaccount.

Aanvraag

U kunt de Get Blob Service Stats aanvraag als volgt samenstellen. U wordt aangeraden HTTPS te gebruiken. Vervang door myaccount de naam van uw opslagaccount en houd er rekening mee dat het -secondary achtervoegsel vereist is:

Methode	Aanvraag-URI	HTTP-versie
GET	https://myaccount-secondary.blob.core.windows.net/?restype=service&comp=stats	HTTP/1.1

Notitie

De URI moet altijd een slash (/) bevatten om de hostnaam te scheiden van het pad en de querygedeelten. In het geval van deze bewerking is het padgedeelte van de URI leeg.

URI-parameters

U kunt de volgende aanvullende parameters opgeven voor de aanvraag-URI:

Parameter	Beschrijving
Timeout	Optioneel. De timeout parameter wordt uitgedrukt in seconden.

Aanvraagheaders

In de volgende tabel worden vereiste en optionele aanvraagheaders beschreven.

Aanvraagheader	Beschrijving
Authorization	Vereist. Hiermee geeft u het autorisatieschema, de accountnaam en de handtekening. Zie Aanvragen voor Azure Storage autoriseren voor meer informatie.
Date or x-ms-date	Vereist. Geef de Coordinated Universal Time (UTC) op voor de aanvraag. Zie Aanvragen voor Azure Storage autoriseren voor meer informatie.
x-ms-version	Vereist voor alle geautoriseerde aanvragen. Hiermee geeft u de versie van de bewerking te gebruiken voor deze aanvraag. Zie Versiebeheer voor de Azure Storage-services voor meer informatie.
x-ms-client-request-id	Optioneel. Biedt een door de client gegenereerde, ondoorzichtige waarde met een limiet van 1 kibibyte (KiB) die wordt vastgelegd in de logboeken wanneer logboekregistratie is geconfigureerd. We raden u ten zeerste aan deze header te gebruiken om activiteiten aan de clientzijde te correleren met aanvragen die de server ontvangt. Zie Azure Blob Storage bewaken voor meer informatie.

Aanvraagbody

Geen.

Antwoord

Het antwoord bevat een HTTP-statuscode, een set antwoordheaders en een antwoordtekst

Statuscode

Een geslaagde bewerking retourneert statuscode 200 (OK). Wanneer een bewerking wordt aangeroepen op een secundair locatie-eindpunt dat niet is ingeschakeld voor een secundaire leesbewerking, retourneert deze een HTTP-statuscode van 403 met een InsufficientAccountPermissions fout.

Antwoordheaders

Het antwoord voor deze bewerking bevat de volgende headers. Het antwoord bevat ook aanvullende standaard-HTTP-headers. Alle standaardheaders voldoen aan de HTTP/1.1-protocolspecificatie.

Antwoordheader	Description
x-ms-request-id	Identificeert op unieke wijze de aanvraag die is gedaan en u kunt deze gebruiken om problemen met de aanvraag op te lossen. Zie Problemen met API-bewerkingen oplossen voor meer informatie.
x-ms-version	Hiermee geeft u de versie van de bewerking die wordt gebruikt voor het antwoord. Zie Versiebeheer voor de Azure Storage-services voor meer informatie.
Date	Een UTC-datum/tijd-waarde die wordt gegenereerd door de service, die de tijd aangeeft waarop het antwoord is gestart.
x-ms-client-request-id	Kan worden gebruikt om problemen met aanvragen en de bijbehorende antwoorden op te lossen. De waarde van deze header is gelijk aan de waarde van de x-ms-client-request-id header als deze aanwezig is in de aanvraag en de waarde niet meer dan 1024 zichtbare ASCII-tekens. Als de x-ms-client-request-id header niet aanwezig is in de aanvraag, is deze header niet aanwezig in het antwoord.

Hoofdtekst van de reactie

De indeling van de antwoordtekst is als volgt:

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

De elementen van de antwoordtekst worden beschreven in de volgende tabel:

Antwoordheader	Description
Status	De status van de secundaire locatie. Mogelijke waarden zijn: - live: geeft aan dat de secundaire locatie actief en operationeel is. - bootstrap: geeft aan dat de initiële synchronisatie van de primaire locatie naar de secundaire locatie wordt uitgevoerd. Dit gebeurt meestal wanneer replicatie voor het eerst wordt ingeschakeld. - niet beschikbaar: geeft aan dat de secundaire locatie tijdelijk niet beschikbaar is.
LastSyncTime	Een GMT-waarde voor datum/tijd, tot de seconde. Alle primaire schrijfbewerkingen die voorafgaan aan deze waarde zijn gegarandeerd beschikbaar voor leesbewerkingen op de secundaire. Primaire schrijfbewerkingen na dit tijdstip zijn mogelijk wel of niet beschikbaar voor leesbewerkingen. De waarde is mogelijk leeg als LastSyncTime deze niet beschikbaar is. Dit kan gebeuren als de replicatiestatus of unavailableisbootstrap. Hoewel geo-replicatie continu wordt ingeschakeld, kan het resultaat een waarde in de LastSyncTime cache van de service weerspiegelen, die om de paar minuten wordt vernieuwd.

Autorisatie

Autorisatie is vereist bij het aanroepen van een bewerking voor gegevenstoegang in Azure Storage. U kunt de Get Blob Service Stats bewerking autoriseren zoals hieronder wordt beschreven.

Microsoft Entra ID

Azure Storage ondersteunt het gebruik van Microsoft Entra ID om aanvragen voor blobgegevens te autoriseren. Met Microsoft Entra ID kunt u op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruiken om machtigingen te verlenen aan een beveiligingsprincipal. De beveiligingsprincipal kan een gebruiker, groep, toepassingsservice-principal of door Azure beheerde identiteit zijn. De beveiligingsprincipal wordt geverifieerd door Microsoft Entra ID om een OAuth 2.0-token te retourneren. Het token kan vervolgens worden gebruikt om een aanvraag voor de Blob-service te autoriseren.

Zie Toegang tot blobs autoriseren met behulp van Microsoft Entra ID voor meer informatie over autorisatie met behulp van Microsoft Entra ID.

Machtigingen

Hieronder vindt u de RBAC-actie die nodig is voor een Microsoft Entra gebruiker, groep of service-principal om de Get Blob Service Stats bewerking aan te roepen, en de ingebouwde Azure RBAC-rol met de minste bevoegdheden die deze actie omvat:

• Azure RBAC-actie:Microsoft.Storage/storageAccounts/blobServices/read
• Ingebouwde rol met minimale bevoegdheden:Inzender opslagaccount

Zie Een Azure-rol toewijzen voor toegang tot blobgegevens voor meer informatie over het toewijzen van rollen met behulp van Azure RBAC.

Shared Access Signatures (SAS)

Een Shared Access Signature (SAS) biedt beveiligde gedelegeerde toegang tot resources in een opslagaccount. Met een SAS hebt u gedetailleerde controle over hoe een client toegang heeft tot gegevens. U kunt opgeven tot welke resource de client toegang heeft, welke machtigingen ze hebben voor deze resources en hoe lang de SAS geldig is.

De Get Blob Service Stats bewerking ondersteunt autorisatie met behulp van een account-SAS.

Wanneer gedeelde sleuteltoegang niet is toegestaan voor het opslagaccount, wordt een SAS-accounttoken niet toegestaan voor een aanvraag voor Blob Storage. Zie Begrijpen hoe het niet toewijzen van gedeelde sleutel van invloed is op SAS-tokens voor meer informatie.

Account-SAS

Een account-SAS wordt beveiligd met de sleutel van het opslagaccount. Een account-SAS delegeert toegang tot resources in een of meer van de opslagservices. Alle bewerkingen die beschikbaar zijn via een service- of gebruikersdelegatie-SAS zijn ook beschikbaar via een account-SAS.

In de volgende tabel ziet u het ondertekende resourcetype en de ondertekende machtigingen die moeten worden opgegeven bij het delegeren van toegang:

Bewerking	Ondertekende service	Ondertekend resourcetype	Ondertekende machtiging
Blob Service-statistieken ophalen	Blob (b)	Service(s)	Lezen (r)

Zie Een account-SAS maken voor meer informatie over de account-SAS.

Gedeelde sleutel

De Get Blob Service Stats bewerking ondersteunt autorisatie van gedeelde sleutels. Autoriseren met accountsleutels wordt niet aanbevolen voor de meeste scenario's, omdat dit minder veilig is. Microsoft raadt aan om waar mogelijk de autorisatie van een gedeelde sleutel voor het opslagaccount niet toe te staan. Zie Autorisatie met gedeelde sleutel voorkomen voor meer informatie.

Opmerkingen

Met geografisch redundante replicatie onderhoudt Azure Storage uw gegevens duurzaam op twee locaties die honderden kilometers van elkaar liggen. Op beide locaties onderhoudt Azure Storage voortdurend meerdere goede replica's van uw gegevens.

Een geografisch redundant paar omvat:

• Een primaire locatie: de locatie waar u gegevens leest, maakt, bijwerkt of verwijdert. De primaire locatie bestaat in de regio die u kiest wanneer u een account maakt via de klassieke Azure-portal (bijvoorbeeld VS - noord-centraal).

• Een secundaire locatie: de locatie waarnaar uw gegevens worden gerepliceerd. De secundaire locatie bevindt zich in een regio die automatisch geografisch is gekoppeld aan de primaire regio. Alleen-lezentoegang is beschikbaar vanaf de secundaire locatie als geografisch redundante replicatie met leestoegang is ingeschakeld voor uw opslagaccount. Zie Gegevensredundantie voor meer informatie over geografisch redundante replicatie met leestoegang.

De locatie waar u gegevens leest, maakt, bijwerkt of verwijdert, is de primaire opslagaccountlocatie. De primaire locatie bestaat in de regio die u kiest op het moment dat u een account maakt via de klassieke Azure Management Azure-portal, bijvoorbeeld VS - noord-centraal. De locatie waarnaar uw gegevens worden gerepliceerd, is de secundaire locatie. De secundaire locatie bevindt zich in een regio die automatisch geografisch is gekoppeld aan de primaire regio. Alleen-lezentoegang is beschikbaar vanaf de secundaire locatie, als geografisch redundante replicatie met leestoegang is ingeschakeld voor uw opslagaccount. Zie Gegevensredundantie voor meer informatie over geografisch redundante replicatie met leestoegang.

Als u een aanvraag voor een leesbewerking wilt maken voor het secundaire eindpunt, voegt u toe -secondary aan de accountnaam in de URI die u gebruikt om te lezen uit Blob Storage. Een secundaire URI voor de bewerking Blob ophalen is bijvoorbeeld vergelijkbaar met https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob.

Billing

Prijsaanvragen kunnen afkomstig zijn van clients die gebruikmaken van Blob Storage-API's, rechtstreeks via de Blob Storage REST API of vanuit een Azure Storage-clientbibliotheek. Met deze aanvragen worden kosten per transactie in rekening gebracht. Het type transactie is van invloed op de manier waarop de rekening in rekening wordt gebracht. Leestransacties worden bijvoorbeeld toegevoegd aan een andere factureringscategorie dan schrijftransacties. In de volgende tabel ziet u de factureringscategorie voor Get Blob Service Stats aanvragen op basis van het type opslagaccount:

Bewerking	Type opslagaccount	Factureringscategorie
Blob Service-statistieken ophalen	Premium-blok-blob Standard v2 voor algemeen gebruik	Andere bewerkingen
Blob Service-statistieken ophalen	Standard v1 voor algemeen gebruik	Leesbewerkingen

Zie prijzen voor Azure Blob Storage voor meer informatie over prijzen voor de opgegeven factureringscategorie.

Voorbeeld van aanvraag en antwoord

Hier volgt een voorbeeldaanvraag voor de Get Blob Service Stats bewerking:

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

De aanvraag wordt verzonden met de volgende headers:

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

De statuscode en antwoordheaders worden als volgt geretourneerd:

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  

Het antwoord bevat de volgende XML-hoofdtekst:

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

Zie ook

Bewerkingen op het account (Blob Storage)