Obter status do serviço Blob

Artigo
02/03/2024

A Get Blob Service Stats operação recupera estatísticas relacionadas à replicação para Armazenamento de Blobs do Azure. A operação só está disponível no ponto de extremidade de localização secundário quando a replicação com redundância geográfica de acesso de leitura está habilitada para a conta de armazenamento.

Solicitação

Você pode construir a solicitação da Get Blob Service Stats seguinte maneira. Recomendamos que você use HTTPS. Substitua myaccount pelo nome da sua conta de armazenamento. Note que o sufixo -secondary é necessário:

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

Observação

O URI sempre deve incluir uma barra (/) para separar o nome do host das partes de caminho e consulta. No caso dessa operação, a parte do caminho do URI fica vazia.

Parâmetros do URI

Você pode especificar os seguintes parâmetros adicionais no URI da solicitação:

Parâmetro	Descrição
`Timeout`	Opcional. O parâmetro `timeout` é expresso em segundos.

Cabeçalhos da solicitação

A tabela a seguir descreve os cabeçalhos de solicitação obrigatórios e opcionais.

Cabeçalho da solicitação	Descrição
`Authorization`	Obrigatórios. Especifica o esquema de autorização, o nome da conta e a assinatura. Para saber mais, confira Autorizar solicitações para o Armazenamento do Azure.
`Date or x-ms-date`	Obrigatórios. Especifica o UTC (Tempo Universal Coordenado) para a solicitação. Para saber mais, confira Autorizar solicitações para o Armazenamento do Azure.
`x-ms-version`	Necessário para todas as solicitações autorizadas. Especifica a versão da operação a ser usada para esta solicitação. Para obter mais informações, consulte Controle de versão para os Serviços de Armazenamento do Azure.
`x-ms-client-request-id`	Opcional. Fornece um valor opaco gerado pelo cliente com um limite de caracteres KiB (1 kibibyte) que é registrado nos logs quando o registro em log é configurado. É altamente recomendável que você use esse cabeçalho para correlacionar atividades do lado do cliente com solicitações recebidas pelo servidor. Para obter mais informações, consulte Monitorar Armazenamento de Blobs do Azure.

Corpo da solicitação

Nenhum.

Resposta

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

Código de status

Uma operação bem-sucedida retorna o código de status 200 (OK). Quando uma operação é chamada em um ponto de extremidade de localização secundário que não está habilitado para uma leitura secundária, ela retorna um código http status 403 com um InsufficientAccountPermissions erro.

Cabeçalhos de resposta

A resposta para esta operação inclui os cabeçalhos a seguir. A resposta também inclui cabeçalhos padrão HTTP 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 a solicitação que foi feita e você pode usá-la para solucionar problemas da solicitação. Para obter mais informações, consulte Solucionar problemas de operações de API.
`x-ms-version`	Especifica a versão da operação usada para a resposta. Para obter mais informações, consulte Controle de versão para os 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 usado para solucionar problemas de solicitações e suas respostas correspondentes. O valor desse cabeçalho será igual ao valor do `x-ms-client-request-id` cabeçalho se ele estiver presente na solicitação e o valor não mais do que 1.024 caracteres ASCII visíveis. Se o `x-ms-client-request-id` cabeçalho não estiver presente na solicitação, esse cabeçalho não estará presente na resposta.

Corpo da resposta

Formato do corpo da resposta:

<?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 seguinte tabela:

Cabeçalho de resposta Descrição

Status O status do local secundário. Os valores possíveis são:

- live: indica que o local secundário está ativo e operacional.
- bootstrap: indica que a sincronização inicial do local primário para o local secundário está em andamento. Isso normalmente ocorre quando a replicação é habilitada pela primeira vez.
- indisponível: indica que o local secundário está temporariamente indisponível.

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

O valor poderá estar vazio se LastSyncTime não estiver disponível. Isso pode ocorrer se o status de replicação é bootstrap ou unavailable.

Embora a replicação geográfica esteja continuamente habilitada, o LastSyncTime resultado pode refletir um valor armazenado em cache do serviço, que é atualizado a cada poucos minutos.

Cabeçalho de resposta	Descrição
`Status`	O status do local secundário. Os valores possíveis são: - `live`: indica que o local secundário está ativo e operacional. - `bootstrap`: indica que a sincronização inicial do local primário para o local secundário está em andamento. Isso normalmente ocorre quando a replicação é habilitada pela primeira vez. - indisponível: indica que o local secundário está temporariamente indisponível.
`LastSyncTime`	Um valor de data/hora GMT, para o segundo. Todas as gravações primárias que precedem esse valor têm a garantia de estarem disponíveis para operações de leitura no secundário. As gravações primárias após esse ponto no tempo podem ou não estar disponíveis para leituras. O valor poderá estar vazio se `LastSyncTime` não estiver disponível. Isso pode ocorrer se o status de replicação é `bootstrap` ou `unavailable`. Embora a replicação geográfica esteja continuamente habilitada, o `LastSyncTime` resultado pode refletir um valor armazenado 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. Você pode autorizar a Get Blob Service Stats operação, conforme descrito abaixo.

Importante

A Microsoft recomenda usar Microsoft Entra ID com identidades gerenciadas para autorizar solicitações ao Armazenamento do Azure. Microsoft Entra ID fornece segurança superior e facilidade de uso em comparação com a autorização de Chave Compartilhada.

O Armazenamento do Azure dá suporte ao uso de Microsoft Entra ID para autorizar solicitações para dados de blob. Com Microsoft Entra ID, você pode usar o RBAC (controle de acesso baseado em função) do Azure para conceder permissões a uma entidade de segurança. A entidade de segurança pode ser um usuário, grupo, entidade de serviço de aplicativo ou identidade gerenciada do Azure. A entidade de segurança é autenticada por Microsoft Entra ID para retornar um token OAuth 2.0. Em seguida, o token pode ser usado para autorizar uma solicitação no serviço de Blob.

Para saber mais sobre a autorização usando Microsoft Entra ID, consulte Autorizar o acesso a blobs usando Microsoft Entra ID.

Permissões

Veja abaixo a ação RBAC necessária para um usuário Microsoft Entra, grupo, identidade gerenciada ou entidade de serviço para chamar a Get Blob Service Stats operação e a função RBAC interna do Azure com menos privilégios que inclui esta ação:

Ação RBAC do Azure:Microsoft.Storage/storageAccounts/blobServices/read
Função interna com privilégios mínimos:Colaborador da Conta de Armazenamento

Para saber mais sobre como atribuir funções usando o RBAC do Azure, confira Atribuir uma função do Azure para acesso aos dados de blob.

Uma SAS (assinatura de acesso compartilhado) fornece acesso delegado seguro aos recursos em uma conta de armazenamento. Com uma SAS, você tem controle granular sobre como um cliente pode acessar dados. Você pode especificar qual recurso o cliente pode acessar, quais permissões eles têm para esses recursos e por quanto tempo a SAS é válida.

A Get Blob Service Stats operação dá suporte à autorização usando uma SAS de conta.

Quando o acesso à Chave Compartilhada não for permitido para a conta de armazenamento, um token SAS de conta não será permitido em uma solicitação para o Armazenamento de Blobs. Para saber mais, confira Entender como a não permissão de Chave Compartilhada afeta tokens SAS.

SAS de Conta

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

A tabela a seguir indica o tipo de recurso assinado e as permissões assinadas a serem especificadas ao delegar o acesso:

Operação	Serviço assinado	Tipo de recurso assinado	Permissão assinada
Obter status do serviço Blob	Blob (b)	Serviço (s)	Leitura (r)

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

A Get Blob Service Stats operação dá suporte à autorização de Chave Compartilhada. A autorização com chaves de conta não é recomendada para a maioria dos cenários, pois é menos segura. A Microsoft recomenda não permitir a autorização de Chave Compartilhada para a conta de armazenamento quando possível. Para obter mais informações, consulte Impedir autorização com chave compartilhada.

Comentários

Com a replicação com redundância geográfica, o Armazenamento do Azure mantém seus dados duravelmente em dois locais com centenas de quilômetros de distância. Em ambos os locais, o Armazenamento do Azure mantém constantemente várias réplicas íntegras de seus dados.

Um par com redundância geográfica inclui:

Um local primário : o local onde você lê, cria, atualiza ou exclui dados. O local principal existe na região que você escolhe ao criar uma conta por meio do portal clássico do Azure (por exemplo, Centro-Norte dos EUA).
Um local secundário : o local para o qual os dados são replicados. O local secundário reside em uma região que é automaticamente emparelhada geograficamente com a região primária. O acesso somente leitura estará disponível no local secundário se a replicação com redundância geográfica de acesso de leitura estiver habilitada para sua conta de armazenamento. Para obter mais informações sobre a replicação com redundância geográfica de acesso de leitura, consulte Redundância de dados.

O local onde você lê, cria, atualiza ou exclui dados é o local da conta de armazenamento principal. O local primário existe na região escolhida no momento em que você cria uma conta por meio do portal clássico do Azure Management Azure, por exemplo, Centro-Norte dos EUA. O local no qual seus dados são replicados é o local secundário. O local secundário reside em uma região que é automaticamente emparelhada geograficamente com a região primária. O acesso somente leitura está disponível no local secundário se a replicação georredundante de acesso de leitura está habilitada para sua conta de armazenamento. Para obter mais detalhes sobre a replicação com redundância geográfica de acesso de leitura, consulte Redundância de dados.

Para construir uma solicitação para uma operação de leitura no ponto de extremidade secundário, acrescente -secondary ao nome da conta no URI que você usa para ler 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.

Cobrança

As solicitações de preços podem ser originadas de clientes que usam APIs de Armazenamento de Blobs, diretamente por meio da API REST do Armazenamento de Blobs ou de uma biblioteca de clientes do Armazenamento do Azure. Essas solicitações acumulam encargos por transação. O tipo de transação afeta a forma como a conta é cobrada. Por exemplo, as transações de leitura se acumulam em uma categoria de cobrança diferente das transações de gravação. A tabela a seguir mostra a categoria de cobrança para Get Blob Service Stats solicitações com base no tipo de conta de armazenamento:

Operação	Tipo de conta de armazenamento	Categoria de cobrança
Obter status do serviço Blob	Blob de blocos Premium Uso geral v2 Standard	Outras operações
Obter status do serviço Blob	Uso geral v1 Standard	Operações de leitura

Para saber mais sobre os preços para a categoria de cobrança especificada, consulte Armazenamento de Blobs do Azure Preços.

Exemplo de solicitação e resposta

Aqui está uma solicitação 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

A solicitação é enviada 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=

Os cabeçalhos de código de status e de resposta são retornados 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>

Confira também

Operações na conta (Armazenamento de Blobs)

Compartilhar via