Obter Estatísticas do Serviço blob

Artigo
05/15/2024

A Get Blob Service Stats operação obtém estatísticas relacionadas com a replicação para Armazenamento de Blobs do Azure. A operação só está disponível no ponto final de localização secundária quando a replicação georredundante de acesso de leitura está ativada para a conta de armazenamento.

Pedir

Pode construir o pedido da Get Blob Service Stats seguinte forma. Recomendamos que utilize HTTPS. Substitua myaccount pelo nome da sua conta de armazenamento e tenha em atenção que o -secondary sufixo é necessário:

Método	URI do pedido	Versão HTTP
GET	`https://myaccount-secondary.blob.core.windows.net/?restype=service&comp=stats`	HTTP/1.1

Nota

O URI tem de incluir sempre uma barra (/) para separar o nome do anfitrião das partes de caminho e consulta. No caso desta operação, a parte do caminho do URI está vazia.

Parâmetros URI

Pode especificar os seguintes parâmetros adicionais no URI do pedido:

Parâmetro	Description
`Timeout`	Opcional. O `timeout` parâmetro é expresso em segundos.

Cabeçalhos do pedido

A tabela seguinte descreve os cabeçalhos de pedido obrigatórios e opcionais.

Cabeçalho do pedido	Description
`Authorization`	Obrigatório. Especifica o esquema de autorização, o nome da conta e a assinatura. Para obter mais informações, veja Autorizar pedidos para o Armazenamento do Azure.
`Date or x-ms-date`	Obrigatório. Especifica a Hora Universal Coordenada (UTC) do pedido. Para obter mais informações, veja Autorizar pedidos para o Armazenamento do Azure.
`x-ms-version`	Necessário para todos os pedidos autorizados. Especifica a versão da operação a utilizar para este pedido. Para obter mais informações, veja Controlo de versões dos serviços de Armazenamento do Azure.
`x-ms-client-request-id`	Opcional. Fornece um valor opaco gerado pelo cliente com um limite de carateres de 1 kibibyte (KiB) que é registado nos registos quando o registo é configurado. Recomendamos vivamente que utilize este cabeçalho para correlacionar as atividades do lado do cliente com os pedidos que o servidor recebe. Para obter mais informações, veja Monitorizar Armazenamento de Blobs do Azure.

Corpo do pedido

Nenhum.

Resposta

A resposta inclui um código de estado HTTP, um conjunto de cabeçalhos de resposta e um corpo de resposta

Código de estado

Uma operação bem-sucedida devolve o código de estado 200 (OK). Quando uma operação é chamada num ponto final de localização secundária que não está ativado para uma leitura secundária, devolve um código de estado HTTP de 403 com um InsufficientAccountPermissions erro.

Cabeçalhos de resposta

A resposta para esta operação inclui os seguintes cabeçalhos. A resposta também inclui cabeçalhos HTTP padrão adicionais. Todos os cabeçalhos padrão estão em conformidade com a especificação do protocolo HTTP/1.1.

Cabeçalho de resposta	Descrição
`x-ms-request-id`	Identifica exclusivamente o pedido que foi feito e pode utilizá-lo para resolver o pedido. Para obter mais informações, veja Resolver problemas de operações da API.
`x-ms-version`	Especifica a versão da operação utilizada para a resposta. Para obter mais informações, veja Controlo de versões dos serviços de Armazenamento do Azure.
`Date`	Um valor de data/hora UTC gerado pelo serviço, que indica a hora em que a resposta foi iniciada.
`x-ms-client-request-id`	Pode ser utilizado para resolver problemas de pedidos e respostas correspondentes. O valor deste cabeçalho é igual ao valor do `x-ms-client-request-id` cabeçalho se estiver presente no pedido e o valor não for superior a 1024 carateres ASCII visíveis. Se o `x-ms-client-request-id` cabeçalho não estiver presente no pedido, este cabeçalho não está presente na resposta.

Corpo da resposta

O formato do corpo de resposta é o seguinte:

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

Os elementos do corpo da resposta estão descritos na tabela seguinte:

Cabeçalho de resposta Descrição

Status O estado da localização secundária. Os valores possíveis são:

- live: indica que a localização secundária está ativa e operacional.
- bootstrap: indica que a sincronização inicial da localização primária para a localização secundária está em curso. Normalmente, isto ocorre quando a replicação é ativada pela primeira vez.
- indisponível: indica que a localização secundária está temporariamente indisponível.

LastSyncTime Um valor de data/hora GMT, para o segundo. Todas as escritas primárias que precedem este valor têm a garantia de estarem disponíveis para operações de leitura na secundária. As escritas primárias após este ponto no tempo podem ou não estar disponíveis para leituras.

O valor poderá estar vazio se LastSyncTime não estiver disponível. Isto pode acontecer se o estado de replicação for bootstrap ou unavailable.

Embora a georreplicação esteja continuamente ativada, o LastSyncTime resultado poderá refletir um valor em cache do serviço, que é atualizado a cada poucos minutos.

Cabeçalho de resposta	Descrição
`Status`	O estado da localização secundária. Os valores possíveis são: - `live`: indica que a localização secundária está ativa e operacional. - `bootstrap`: indica que a sincronização inicial da localização primária para a localização secundária está em curso. Normalmente, isto ocorre quando a replicação é ativada pela primeira vez. - indisponível: indica que a localização secundária está temporariamente indisponível.
`LastSyncTime`	Um valor de data/hora GMT, para o segundo. Todas as escritas primárias que precedem este valor têm a garantia de estarem disponíveis para operações de leitura na secundária. As escritas primárias após este ponto no tempo podem ou não estar disponíveis para leituras. O valor poderá estar vazio se `LastSyncTime` não estiver disponível. Isto pode acontecer se o estado de replicação for `bootstrap` ou `unavailable`. Embora a georreplicação esteja continuamente ativada, o `LastSyncTime` resultado poderá refletir um valor em cache do serviço, que é atualizado a cada poucos minutos.

Autorização

A autorização é necessária ao chamar qualquer operação de acesso a dados no Armazenamento do Azure. Pode autorizar a Get Blob Service Stats operação conforme descrito abaixo.

Importante

A Microsoft recomenda a utilização de Microsoft Entra ID com identidades geridas para autorizar pedidos para o Armazenamento do Azure. Microsoft Entra ID fornece segurança e facilidade de utilização superiores em comparação com a autorização de Chave Partilhada.

O Armazenamento do Azure suporta a utilização de Microsoft Entra ID para autorizar pedidos para dados de blobs. Com Microsoft Entra ID, pode utilizar o controlo de acesso baseado em funções do Azure (RBAC do Azure) para conceder permissões a um principal de segurança. O principal de segurança pode ser um utilizador, grupo, principal de serviço de aplicação ou identidade gerida do Azure. O principal de segurança é autenticado por Microsoft Entra ID para devolver um token OAuth 2.0. Em seguida, o token pode ser utilizado para autorizar um pedido contra o serviço Blob.

Para saber mais sobre a autorização através de Microsoft Entra ID, veja Autorizar o acesso a blobs com Microsoft Entra ID.

Permissões

Abaixo estão listadas as ações RBAC necessárias para que um utilizador Microsoft Entra, grupo, identidade gerida ou principal de serviço chame a Get Blob Service Stats operação e a função RBAC do Azure com menos privilégios que inclua esta ação:

Ação RBAC do Azure:Microsoft.Storage/storageAccounts/blobServices/read
Função incorporada com menos privilégios:Contribuidor da Conta de Armazenamento

Para saber mais sobre como atribuir funções com o RBAC do Azure, veja Atribuir uma função do Azure para acesso a dados de blobs.

Uma assinatura de acesso partilhado (SAS) fornece acesso delegado seguro aos recursos numa conta de armazenamento. Com uma SAS, tem controlo granular sobre como um cliente pode aceder aos dados. Pode especificar o recurso a que o cliente pode aceder, que permissões têm para esses recursos e quanto tempo a SAS é válida.

A Get Blob Service Stats operação suporta a autorização através de uma SAS de conta.

Quando o acesso à Chave Partilhada não for permitido para a conta de armazenamento, não será permitido um token de SAS de conta num pedido para o Armazenamento de Blobs. Para saber mais, veja Compreender como a desativação da Chave Partilhada afeta os tokens de SAS.

SAS de Conta

Uma SAS de conta é protegida com a chave da conta de armazenamento. Uma conta SAS delega o acesso aos recursos em um ou mais dos serviços de armazenamento. Todas as operações disponíveis através de um serviço ou saS de delegação de utilizador também estão disponíveis através de uma SAS de conta.

A tabela seguinte indica o tipo de recurso assinado e as permissões assinadas para especificar ao delegar o acesso:

Operação	Serviço assinado	Tipo de recurso assinado	Permissão assinada
Obter Estatísticas do Serviço blob	Blob (b)	Serviço (s)	Ler (r)

Para saber mais sobre a SAS da conta, veja Create uma SAS de conta.

A Get Blob Service Stats operação suporta autorização de Chave Partilhada. A autorização com chaves de conta não é recomendada para a maioria dos cenários, uma vez que é menos segura. A Microsoft recomenda a desativação da autorização da Chave Partilhada para a conta de armazenamento sempre que possível. Para obter mais informações, veja Impedir autorização com Chave Partilhada.

Observações

Com a replicação georredundante, o Armazenamento do Azure mantém os seus dados duravelmente em duas localizações que estão a centenas de quilómetros de distância. Em ambas as localizações, o Armazenamento do Azure mantém constantemente múltiplas réplicas em bom estado de funcionamento dos seus dados.

Um par georredundante inclui:

Uma localização primária : a localização onde lê, cria, atualiza ou elimina dados. A localização primária existe na região que escolher quando cria uma conta através do portal clássico do Azure (por exemplo, E.U.A. Centro-Norte).
Uma localização secundária : a localização para a qual os seus dados são replicados. A localização secundária reside numa região que é automaticamente emparelhada geograficamente com a região primária. O acesso só de leitura está disponível a partir da localização secundária se a replicação georredundante de acesso de leitura estiver ativada para a sua conta de armazenamento. Para obter mais informações sobre a replicação georredundante de acesso de leitura, veja Redundância de dados.

A localização onde lê, cria, atualiza ou elimina dados é a localização da conta de armazenamento principal . A localização primária existe na região que escolher no momento em que cria uma conta através do portal clássico do Azure Management do Azure, por exemplo, E.U.A. Centro-Norte. A localização para a qual os seus dados são replicados é a localização secundária . A localização secundária reside numa região que é automaticamente emparelhada geograficamente com a região primária. O acesso só de leitura está disponível a partir da localização secundária, se a replicação georredundante de acesso de leitura estiver ativada para a sua conta de armazenamento. Para obter mais detalhes sobre a replicação georredundante de acesso de leitura, veja Redundância de dados.

Para construir um pedido para uma operação de leitura no ponto final secundário, acrescente -secondary ao nome da conta no URI que utiliza para ler a partir do Armazenamento de Blobs. Por exemplo, um URI secundário para a operação Obter Blob será semelhante a https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob.

Faturação

Os pedidos de preços podem ter origem em clientes que utilizam APIs de Armazenamento de Blobs, diretamente através da API REST do Armazenamento de Blobs ou a partir de uma biblioteca de cliente do Armazenamento do Azure. Estes pedidos acumulam custos por transação. O tipo de transação afeta a forma como a conta é cobrada. Por exemplo, as transações de leitura acumulam-se numa categoria de faturação diferente das transações de escrita. A tabela seguinte mostra a categoria de faturação dos Get Blob Service Stats pedidos com base no tipo de conta de armazenamento:

Operação	Tipo de conta de armazenamento	Categoria de faturação
Obter Estatísticas do Serviço blob	Blob de bloco premium Standard para fins gerais v2	Outras operações
Obter Estatísticas do Serviço blob	Standard para fins gerais v1	Operações de leitura

Para saber mais sobre os preços da categoria de faturação especificada, veja Armazenamento de Blobs do Azure Preços.

Pedido de exemplo e resposta

Segue-se um pedido de exemplo para a Get Blob Service Stats operação:

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

O pedido é enviado com os seguintes cabeçalhos:

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

O código de estado e os cabeçalhos de resposta são devolvidos da seguinte forma:

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

A resposta inclui o seguinte 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>

Ver também

Operações na conta (Armazenamento de Blobs)

Partilhar via