Get Blob Service Stats

Articolo
02/03/2024

L'operazione Get Blob Service Stats recupera le statistiche correlate alla replica per Archiviazione BLOB di Azure. L'operazione è disponibile solo nell'endpoint della posizione secondaria quando la replica con ridondanza geografica e accesso in lettura è abilitata per l'account di archiviazione.

Richiesta

È possibile costruire la Get Blob Service Stats richiesta come indicato di seguito. È consigliabile usare HTTPS. Sostituire myaccount con il nome dell'account di archiviazione in uso e ricordare che è necessario il suffisso -secondary:

Metodo	URI richiesta	Versione HTTP
GET	`https://myaccount-secondary.blob.core.windows.net/?restype=service&comp=stats`	HTTP/1.1

Nota

L'URI deve sempre includere una barra (/) per separare il nome host dalle parti del percorso e della query. Nel caso di questa operazione, la parte del percorso dell'URI è vuota.

Parametri URI

Nell'URI della richiesta puoi specificare i parametri seguenti:

Parametro	Descrizione
`Timeout`	Facoltativa. Il parametro `timeout` viene espresso in secondi.

Intestazioni della richiesta

Nella seguente tabella vengono descritte le intestazioni di richiesta obbligatorie e facoltative.

Intestazione della richiesta	Descrizione
`Authorization`	Obbligatorio. Specifica lo schema di autorizzazione, il nome dell'account e la firma. Per altre informazioni, vedere Autorizzare le richieste ad Archiviazione di Azure.
`Date or x-ms-date`	Obbligatorio. Specifica la data per la richiesta nel fuso orario UTC (Coordinated Universal Time). Per altre informazioni, vedere Autorizzare le richieste ad Archiviazione di Azure.
`x-ms-version`	Obbligatorio per tutte le richieste autorizzate. Specifica la versione dell'operazione da usare per questa richiesta. Per altre informazioni, vedere Controllo delle versioni per i servizi di archiviazione di Azure.
`x-ms-client-request-id`	facoltativo. Fornisce un valore opaco generato dal client con un limite di caratteri di 1 kibibyte (KiB) registrato nei log al momento della configurazione della registrazione. È consigliabile usare questa intestazione per correlare le attività lato client alle richieste ricevute dal server. Per altre informazioni, vedere Monitorare Archiviazione BLOB di Azure.

Testo della richiesta

Nessuno.

Risposta

Nella risposta sono inclusi un codice di stato HTTP, un set di intestazioni per la risposta e il corpo di una risposta.

Codice stato

Un'operazione completata correttamente restituisce 200 (OK). Quando un'operazione viene chiamata su un endpoint della posizione secondaria non abilitata per una lettura secondaria, restituisce un codice di stato HTTP 403 con un InsufficientAccountPermissions errore.

Intestazioni di risposta

Nella risposta per questa operazione sono incluse le intestazioni riportate di seguito; La risposta include inoltre intestazioni HTTP standard aggiuntive. Tutte le intestazioni standard sono conformi alla specifica del protocollo HTTP/1.1.

Intestazione risposta	Descrizione
`x-ms-request-id`	Identifica in modo univoco la richiesta effettuata ed è possibile usarla per risolvere i problemi della richiesta. Per altre informazioni, vedere Risolvere i problemi relativi alle operazioni api.
`x-ms-version`	Specifica la versione dell'operazione utilizzata per la risposta. Per altre informazioni, vedere Controllo delle versioni per i servizi di archiviazione di Azure.
`Date`	Valore di data/ora UTC generato dal servizio, che indica l'ora di avvio della risposta.
`x-ms-client-request-id`	Può essere usato per risolvere i problemi relativi alle richieste e alle risposte corrispondenti. Il valore di questa intestazione è uguale al valore dell'intestazione `x-ms-client-request-id` se è presente nella richiesta e il valore non è più di 1.024 caratteri ASCII visibili. Se l'intestazione `x-ms-client-request-id` non è presente nella richiesta, questa intestazione non è presente nella risposta.

Corpo della risposta

Il formato del corpo della risposta è il seguente:

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

Nella tabella seguente vengono descritti gli elementi del corpo della risposta:

Intestazione risposta Descrizione

Status Stato della posizione secondaria. I valori possibili sono:

- live: indica che la posizione secondaria è attiva e operativa.
- bootstrap: indica che è in corso la sincronizzazione iniziale dal percorso primario al percorso secondario. Questa situazione si verifica normalmente quando la replica è abilitata per la prima volta.
- non disponibile: indica che la posizione secondaria è temporaneamente non disponibile.

LastSyncTime Un valore di data/ora GMT, al secondo. Tutte le scritture primarie che precedono questo valore sono sicuramente disponibili per le operazioni di lettura nel database secondario. Le scritture primarie dopo questo momento potrebbero non essere disponibili o meno per le letture.

Il valore potrebbe essere vuoto se LastSyncTime non è disponibile. Questo può verificarsi se lo stato di replica è bootstrap o unavailable.

Anche se la replica geografica è abilitata continuamente, il LastSyncTime risultato potrebbe riflettere un valore memorizzato nella cache dal servizio, che viene aggiornato ogni pochi minuti.

Intestazione risposta	Descrizione
`Status`	Stato della posizione secondaria. I valori possibili sono: - `live`: indica che la posizione secondaria è attiva e operativa. - `bootstrap`: indica che è in corso la sincronizzazione iniziale dal percorso primario al percorso secondario. Questa situazione si verifica normalmente quando la replica è abilitata per la prima volta. - non disponibile: indica che la posizione secondaria è temporaneamente non disponibile.
`LastSyncTime`	Un valore di data/ora GMT, al secondo. Tutte le scritture primarie che precedono questo valore sono sicuramente disponibili per le operazioni di lettura nel database secondario. Le scritture primarie dopo questo momento potrebbero non essere disponibili o meno per le letture. Il valore potrebbe essere vuoto se `LastSyncTime` non è disponibile. Questo può verificarsi se lo stato di replica è `bootstrap` o `unavailable`. Anche se la replica geografica è abilitata continuamente, il `LastSyncTime` risultato potrebbe riflettere un valore memorizzato nella cache dal servizio, che viene aggiornato ogni pochi minuti.

Autorizzazione

L'autorizzazione è necessaria quando si chiama un'operazione di accesso ai dati in Archiviazione di Azure. È possibile autorizzare l'operazione Get Blob Service Stats come descritto di seguito.

Archiviazione di Azure supporta l'uso di Microsoft Entra ID per autorizzare le richieste ai dati BLOB. Con Microsoft Entra ID è possibile usare il controllo degli accessi in base al ruolo di Azure per concedere le autorizzazioni a un'entità di sicurezza. L'entità di sicurezza può essere un utente, un gruppo, un'entità servizio applicazione o un'identità gestita di Azure. L'entità di sicurezza viene autenticata da Microsoft Entra ID per restituire un token OAuth 2.0. Il token può quindi essere usato per autorizzare una richiesta relativa al servizio BLOB.

Per altre informazioni sull'autorizzazione tramite Microsoft Entra ID, vedere Autorizzare l'accesso ai BLOB usando Microsoft Entra ID.

Autorizzazioni

Di seguito è riportata l'azione controllo degli accessi in base al ruolo necessaria per un utente, un gruppo o un'entità servizio di Microsoft Entra per chiamare l'operazione Get Blob Service Stats e il ruolo controllo degli accessi in base al ruolo di Azure con privilegi minimi che include questa azione:

Azione controllo degli accessi in base al ruolo di Azure:Microsoft.Storage/storageAccounts/blobServices/read
Ruolo predefinito con privilegi minimi:Collaboratore account di archiviazione

Per altre informazioni sull'assegnazione dei ruoli tramite il controllo degli accessi in base al ruolo di Azure, vedere Assegnare un ruolo di Azure per l'accesso ai dati BLOB.

Una firma di accesso condiviso fornisce accesso delegato sicuro alle risorse in un account di archiviazione. Con una firma di accesso condiviso è possibile controllare in modo granulare il modo in cui un client può accedere ai dati. È possibile specificare la risorsa a cui il client può accedere, le autorizzazioni necessarie per tali risorse e il periodo di validità della firma di accesso condiviso.

L'operazione Get Blob Service Stats supporta l'autorizzazione tramite una firma di accesso condiviso dell'account.

Quando l'accesso a chiave condivisa non è consentito per l'account di archiviazione, un token di firma di accesso condiviso dell'account non sarà consentito in una richiesta di archiviazione BLOB. Per altre informazioni, vedere Informazioni su come impedire la condivisione della chiave condivisa influisce sui token di firma di accesso condiviso.

Firma di accesso condiviso dell'account

Una firma di accesso condiviso dell'account è protetta con la chiave dell'account di archiviazione. Una firma di accesso condiviso dell'account delega l'accesso alle risorse in uno o più servizi di archiviazione. Tutte le operazioni disponibili tramite una firma di accesso condiviso del servizio o di delega utente sono disponibili anche tramite una firma di accesso condiviso dell'account.

La tabella seguente indica il tipo di risorsa firmato e le autorizzazioni firmate per specificare quando delega l'accesso:

Operazione	Servizio firmato	Tipo di risorsa firmato	Autorizzazione firmata
Get Blob Service Stats	BLOB (b)	Servizio (s)	Lettura (r)

Per altre informazioni sulla firma di accesso condiviso dell'account, vedere Creare una firma di accesso condiviso dell'account.

L'operazione supporta l'autorizzazioneGet Blob Service Stats chiave condivisa. L'autorizzazione con le chiavi dell'account non è consigliata per la maggior parte degli scenari, perché è meno sicura. Microsoft consiglia di impedire l'autorizzazione di chiave condivisa per l'account di archiviazione quando possibile. Per altre informazioni, vedere Impedire l'autorizzazione con chiave condivisa.

Commenti

Con la replica con ridondanza geografica, Archiviazione di Azure gestisce i dati duramente in due posizioni che sono centinaia di miglia a parte. In entrambe le posizioni Archiviazione di Azure gestisce costantemente più repliche integre dei dati.

Una coppia con ridondanza geografica include:

Percorso primario : percorso in cui si legge, si creano, si aggiornano o si eliminano i dati. La posizione primaria esiste nell'area scelta quando si crea un account tramite il portale di Azure classico(ad esempio, Stati Uniti centro-settentrionali).
Percorso secondario : percorso in cui vengono replicati i dati. La posizione secondaria si trova in un'area associata automaticamente all'area primaria. L'accesso in sola lettura è disponibile dalla posizione secondaria se la replica con ridondanza geografica di accesso in lettura è abilitata per l'account di archiviazione. Per altre informazioni sulla replica con ridondanza geografica di accesso in lettura, vedere Ridondanza dei dati.

La posizione in cui si leggono, creano, aggiornano o eliminano i dati è la posizione dell'account di archiviazione primaria. La posizione primaria esiste nell'area scelta al momento della creazione di un account tramite il portale di Azure Management Azure classico, ad esempio Stati Uniti centro-settentrionali. La posizione in cui i dati vengono replicati è la posizione secondaria. La posizione secondaria si trova in un'area associata automaticamente all'area primaria. Dalla posizione secondaria è disponibile l'accesso in sola lettura se la replica geograficamente ridondante con accesso in lettura è abilitata per l'account di archiviazione. Per altre informazioni sulla replica con ridondanza geografica di accesso in lettura, vedere Ridondanza dei dati.

Per costruire una richiesta per un'operazione di lettura sull'endpoint secondario, aggiungere -secondary al nome dell'account nell'URI usato per leggere da Archiviazione BLOB. Ad esempio, un URI secondario per l'operazione Get BLOB sarà simile a https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob.

Fatturazione

Le richieste di prezzi possono derivare dai client che usano le API di archiviazione BLOB, direttamente tramite l'API REST dell'archiviazione BLOB o da una libreria client di Archiviazione di Azure. Queste richieste accumulano addebiti per transazione. Il tipo di transazione influisce sul modo in cui viene addebitato l'account. Ad esempio, le transazioni di lettura si accumulano in una categoria di fatturazione diversa rispetto alle transazioni di scrittura. Nella tabella seguente viene illustrata la categoria di fatturazione per Get Blob Service Stats le richieste in base al tipo di account di archiviazione:

Operazione	Tipo di account di archiviazione	Categoria di fatturazione
Get Blob Service Stats	BLOB di blocchi Premium Utilizzo generico v2 Standard	Altre operazioni
Get Blob Service Stats	Utilizzo generico standard v1	Operazioni di lettura

Per informazioni sui prezzi per la categoria di fatturazione specificata, vedere prezzi Archiviazione BLOB di Azure.

Richiesta di esempio e risposta

Ecco una richiesta di esempio per l'operazione Get Blob Service Stats :

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

La richiesta viene inviata con le intestazioni seguenti:

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

Il codice di stato e le intestazioni della risposta vengono restituiti nel modo seguente:

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

Nella risposta è incluso il seguente corpo XML:

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

Vedi anche

Operazioni sull'account (archiviazione BLOB)