Compartilhar via

Monitorar, diagnosticar e solucionar problemas Armazenamento do Microsoft Azure (clássico)

  • Artigo

Este guia mostra como usar recursos como o Azure Análise de Armazenamento, o log no lado do cliente na Biblioteca de Clientes de Armazenamento do Azure e outras ferramentas de terceiros para identificar, diagnosticar e solucionar problemas relacionados ao Armazenamento do Azure.

Diagrama que mostra o fluxo de informações entre aplicativos cliente e serviços de armazenamento do Azure.

Este guia destina-se a ser lido principalmente por desenvolvedores de serviços online que usam os Serviços de Armazenamento do Azure e profissionais de TI responsáveis pelo gerenciamento desse serviços online. As metas deste guia são:

  • Para ajudar você a manter a integridade e o desempenho de suas contas de Armazenamento do Azure.
  • Para fornecer os processos e ferramentas necessários para ajudá-lo a decidir se um problema ou problema em um aplicativo está relacionado ao Armazenamento do Azure.
  • Para fornecer diretrizes acionáveis para resolver problemas relacionados ao Armazenamento do Azure.

Observação

Este artigo baseia-se no uso de Análise de Armazenamento métricas e logs chamados de métricas e logs clássicos. Recomendamos que você use métricas e logs do Armazenamento do Azure no Azure Monitor em vez de Análise de Armazenamento logs. Para saber mais, confira qualquer um dos seguintes artigos:

Visão Geral

Diagnosticar e solucionar problemas em um aplicativo distribuído hospedado em um ambiente de nuvem pode ser mais complexo do que em ambientes tradicionais. Os aplicativos podem ser implantados em uma infraestrutura de PaaS ou IaaS, localmente, em um dispositivo móvel ou em alguma combinação desses ambientes. Normalmente, o tráfego de rede do aplicativo pode percorrer redes públicas e privadas, e seu aplicativo pode usar várias tecnologias de armazenamento, como Armazenamento do Microsoft Azure Tabelas, Blobs, Filas ou Arquivos, além de outros armazenamentos de dados, como bancos de dados relacionais e de documentos.

Para gerenciar esses aplicativos com êxito, você deve monitorá-los proativamente e entender como diagnosticar e solucionar todos os aspectos deles e suas tecnologias dependentes. Como usuário dos serviços de Armazenamento do Azure, você deve monitorar continuamente os serviços de armazenamento que seu aplicativo usa para quaisquer alterações inesperadas no comportamento (como tempos de resposta mais lentos do que o habitual) e usar o registro em log para coletar dados mais detalhados e analisar um problema em profundidade. A diagnóstico informações obtidas com o monitoramento e o registro em log ajudará você a determinar a causa raiz do problema encontrado pelo aplicativo. Em seguida, você pode solucionar o problema e determinar as etapas apropriadas para corrigi-lo. O Armazenamento do Azure é um serviço principal do Azure e forma uma parte importante da maioria das soluções que os clientes implantam na infraestrutura do Azure. O Armazenamento do Azure inclui recursos para simplificar o monitoramento, o diagnóstico e a solução de problemas de armazenamento em seus aplicativos baseados em nuvem.

Como este guia é organizado

A seção Monitoramento do serviço de armazenamento descreve como monitorar a integridade e o desempenho de seus serviços de Armazenamento do Azure usando as Métricas de Análise de Armazenamento do Azure (Métricas de Armazenamento).

A seção Diagnosticar problemas de armazenamento descreve como diagnosticar problemas usando o Log de Análise de Armazenamento do Azure (Registro em Log de Armazenamento). Ele também descreve como habilitar o log do lado do cliente usando as instalações em uma das bibliotecas de cliente, como a Biblioteca de Clientes de Armazenamento para .NET ou o SDK do Azure para Java.

A seção rastreamento de ponta a ponta descreve como você pode correlacionar as informações contidas em vários arquivos de log e dados de métricas.

A seção De diretrizes de solução de problemas fornece diretrizes de solução de problemas para alguns dos problemas comuns relacionados ao armazenamento que você pode encontrar.

A seção Apêndices inclui informações sobre o uso de outras ferramentas, como Wireshark e Netmon para analisar dados de pacote de rede, e Fiddler para analisar mensagens HTTP/HTTPS.

Monitorando seu serviço de armazenamento

Se você estiver familiarizado com o monitoramento de desempenho do Windows, poderá considerar as Métricas de Armazenamento como sendo um armazenamento do Azure equivalente aos contadores do Windows Monitor de Desempenho. Em Métricas de Armazenamento, você encontrará um conjunto abrangente de métricas (contadores no Windows Monitor de Desempenho terminologia), como disponibilidade de serviço, o número total de solicitações para o serviço ou o percentual de solicitações bem-sucedidas para o serviço. Para obter uma lista completa das métricas disponíveis, consulte Análise de Armazenamento Esquema da Tabela de Métricas. Você pode especificar se deseja que o serviço de armazenamento colete e agregar métricas a cada hora ou a cada minuto. Para obter mais informações sobre como habilitar métricas e monitorar suas contas de armazenamento, consulte Habilitar métricas de armazenamento e exibir dados de métricas.

Você pode escolher quais métricas por hora deseja exibir no portal do Azure e configurar regras que notificam os administradores por email sempre que uma métrica por hora excede um limite específico. Para obter mais informações, confira Receber Notificações de Alerta.

Recomendamos que você examine o Azure Monitor para Armazenamento (versão prévia). É um recurso do Azure Monitor que oferece um monitoramento abrangente de suas contas de Armazenamento do Azure fornecendo uma exibição unificada do desempenho, capacidade e disponibilidade dos serviços de Armazenamento do Azure. Ele não exige que você habilite ou configure nada, e você pode exibir imediatamente essas métricas dos gráficos interativos pré-definidos e outras visualizações incluídas.

O serviço de armazenamento tenta o seu melhor para coletar métricas, mas pode não registrar todas as operações de armazenamento.

No portal do Azure, você pode exibir métricas como disponibilidade, solicitações totais e números médios de latência para uma conta de armazenamento. Uma regra de notificação também foi configurada para alertar um administrador se a disponibilidade cair abaixo de um determinado nível. Ao exibir esses dados, uma área possível para investigação é o percentual de êxito do serviço de tabela abaixo de 100% (para obter mais informações, confira as Métricas mostram que entradas de log percentSuccess ou analytics baixas têm operações com status de transação da seção ClientOtherErrors).

Você deve monitorar continuamente seus aplicativos do Azure para garantir que eles estejam saudáveis e executando conforme o esperado:

  • Estabelecendo algumas métricas de linha de base para o aplicativo que permitirão comparar dados atuais e identificar quaisquer alterações significativas no comportamento do armazenamento do Azure e do seu aplicativo. Os valores de suas métricas de linha de base serão, em muitos casos, específicos do aplicativo e você deve estabelegá-los quando estiver testando seu aplicativo.
  • Registrar métricas de minuto e usá-las para monitorar ativamente erros e anomalias inesperados, como picos na contagem de erros ou taxas de solicitação.
  • Registrar métricas por hora e usá-las para monitorar valores médios, como contagem média de erros e taxas de solicitação.
  • Investigando possíveis problemas usando diagnóstico ferramentas, conforme discutido posteriormente na seção Diagnosticar problemas de armazenamento.

Os gráficos na imagem a seguir ilustram como a média que ocorre para métricas por hora pode ocultar picos na atividade. As métricas por hora parecem mostrar uma taxa constante de solicitações, enquanto as métricas de minuto revelam as flutuações que estão realmente ocorrendo.

Gráficos que mostram como a média que ocorre para métricas por hora pode ocultar picos na atividade.

O restante desta seção descreve quais métricas você deve monitorar e por quê.

Monitoramento da integridade do serviço

Você pode usar o portal do Azure para exibir a integridade do serviço de armazenamento (e outros serviços do Azure) em todas as regiões do Azure em todo o mundo. O monitoramento permite que você veja imediatamente se um problema fora do controle está afetando o serviço de armazenamento na região que você usa para seu aplicativo.

O portal do Azure também pode fornecer notificações de incidentes que afetam os vários serviços do Azure.

Observação

Essas informações estavam disponíveis anteriormente, juntamente com dados históricos, no Painel de Serviço do Azure. Para obter mais informações sobre o Application Insights para Azure DevOps, confira Apêndice 5: Monitoramento com o Application Insights para Azure DevOps.

Capacidade de monitoramento

As Métricas de Armazenamento armazenam apenas métricas de capacidade para o serviço de blob porque os blobs normalmente representam a maior proporção de dados armazenados (no momento da gravação, não é possível usar Métricas de Armazenamento para monitorar a capacidade de suas tabelas e filas). Você pode encontrar esses dados na $MetricsCapacityBlob tabela se tiver o monitoramento habilitado para o serviço de Blob. As Métricas de Armazenamento registram esses dados uma vez por dia e você pode usar o valor do RowKey para determinar se a linha contém uma entidade relacionada a dados de usuário (valor data) ou dados de análise (valor analytics). Cada entidade armazenada contém informações sobre a quantidade de armazenamento usada (Capacity medida em bytes) e o número atual de contêineres (ContainerCount) e blobs (ObjectCount) em uso na conta de armazenamento. Para obter mais informações sobre as métricas de capacidade armazenadas na $MetricsCapacityBlob tabela, consulte Análise de Armazenamento Esquema da Tabela de Métricas.

Observação

Você deve monitorar esses valores para obter um aviso antecipado de que está se aproximando dos limites de capacidade da sua conta de armazenamento. No portal do Azure, você pode adicionar regras de alerta para notificá-lo se o uso de armazenamento agregado exceder ou ficar abaixo dos limites especificados.

Para estimar o tamanho de vários objetos de armazenamento, como blobs, confira a postagem no blog Entendendo a Cobrança de Armazenamento do Azure – Largura de banda, Transações e Capacidade.

Disponibilidade de monitoramento

Você deve monitorar a disponibilidade dos serviços de armazenamento em sua conta de armazenamento monitorando o valor na Availability coluna nas tabelas de métricas por hora ou minutos – $MetricsHourPrimaryTransactionsBlob, , $MetricsHourPrimaryTransactionsTable, $MetricsHourPrimaryTransactionsQueue, $MetricsMinutePrimaryTransactionsBlob, $MetricsMinutePrimaryTransactionsTable, $MetricsMinutePrimaryTransactionsQueue, $MetricsCapacityBlob. A Availability coluna contém um valor percentual que indica a disponibilidade do serviço ou a operação de API representada pela linha (a RowKey mostra se a linha contém métricas para o serviço como um todo ou para uma operação de API específica).

Qualquer valor inferior a 100% indica que algumas solicitações de armazenamento estão falhando. Você pode ver por que elas estão falhando examinando as outras colunas nos dados de métricas que mostram o número de solicitações com tipos de erro diferentes, como ServerTimeoutError. Você deve esperar ver Availability cair temporariamente abaixo de 100% por motivos como tempo limite de servidor transitório, enquanto o serviço move partições para melhores solicitações de balanceamento de carga; a lógica de repetição em seu aplicativo cliente deve lidar com essas condições intermitentes. O artigo Análise de Armazenamento Operações registradas e Mensagens de Status lista os tipos de transação que as Métricas de Armazenamento incluem em seu Availability cálculo.

No portal do Azure, você pode adicionar regras de alerta para notificá-lo se Availability um serviço estiver abaixo de um limite especificado.

A seção de diretrizes de solução de problemas deste guia descreve alguns problemas comuns do serviço de armazenamento relacionados à disponibilidade.

Monitoramento do desempenho

Para monitorar o desempenho dos serviços de armazenamento, você pode usar as seguintes métricas das tabelas de métricas por hora e minutos.

  • Os valores nas AverageE2ELatency colunas e AverageServerLatency mostram o tempo médio que o serviço de armazenamento ou o tipo de operação de API está levando para processar solicitações. AverageE2ELatency é uma medida de latência de ponta a ponta que inclui o tempo necessário para ler a solicitação e enviar a resposta, além do tempo necessário para processar a solicitação (portanto, inclui latência de rede quando a solicitação atinge o serviço de armazenamento); AverageServerLatency é uma medida apenas do tempo de processamento e, portanto, exclui qualquer latência de rede relacionada à comunicação com o cliente. Consulte a seção Métricas mostrar alta MédiaE2ELatency e baixa AverageServerLatency mais tarde neste guia para uma discussão sobre por que pode haver uma diferença significativa entre esses dois valores.
  • Os valores nas TotalIngress colunas e TotalEgress mostram a quantidade total de dados, em bytes, entrando e saindo do serviço de armazenamento ou por meio de um tipo de operação de API específico.
  • Os valores na TotalRequests coluna mostram o número total de solicitações que o serviço de armazenamento da operação de API está recebendo. TotalRequests é o número total de solicitações que o serviço de armazenamento recebe.

Normalmente, você monitorará alterações inesperadas em qualquer um desses valores, pois isso indica que você tem um problema que requer investigação.

No portal do Azure, você pode adicionar regras de alerta para notificá-lo se qualquer métrica de desempenho para esse serviço estiver abaixo ou exceder um limite especificado.

A seção de diretrizes de solução de problemas deste guia descreve alguns problemas comuns do serviço de armazenamento relacionados ao desempenho.

Diagnosticar problemas de armazenamento

Há várias maneiras pelas quais você pode se conscientizar de um problema ou problema em seu aplicativo, incluindo:

  • Uma falha importante que faz com que o aplicativo falhe ou pare de funcionar.
  • Alterações significativas dos valores de linha de base nas métricas que você está monitorando, conforme descrito na seção anterior Monitorando seu serviço de armazenamento.
  • Relata dos usuários do aplicativo que alguma operação específica não foi concluída conforme o esperado ou que algum recurso não está funcionando.
  • Erros gerados em seu aplicativo que aparecem em arquivos de log ou por meio de algum outro método de notificação.

Normalmente, os problemas relacionados aos serviços de armazenamento do Azure se enquadram em uma das quatro categorias amplas:

  • Seu aplicativo tem um problema de desempenho, relatado por seus usuários ou revelado por alterações nas métricas de desempenho.
  • Há um problema com a infraestrutura de Armazenamento do Azure em uma ou mais regiões.
  • Seu aplicativo está encontrando um erro, relatado por seus usuários ou revelado por um aumento em uma das métricas de contagem de erros que você monitora.
  • Durante o desenvolvimento e teste, você pode estar usando o emulador de armazenamento local; você pode encontrar alguns problemas relacionados especificamente ao uso do emulador de armazenamento.

As seções a seguir descrevem as etapas que você deve seguir para diagnosticar e solucionar problemas em cada uma dessas quatro categorias. A seção De diretrizes de solução de problemas posteriormente neste guia fornece mais detalhes para alguns problemas comuns que você pode encontrar.

Integridade do serviço problemas

Integridade do serviço problemas normalmente estão fora do controle. O portal do Azure fornece informações sobre quaisquer problemas em andamento com os serviços do Azure, incluindo serviços de armazenamento. Se você optou por Read-Access Geo-Redundant Armazenamento ao criar sua conta de armazenamento, se os dados ficarem indisponíveis no local principal, seu aplicativo poderá alternar temporariamente para a cópia somente leitura no local secundário. Para ler no secundário, seu aplicativo deve ser capaz de alternar entre o uso dos locais de armazenamento primário e secundário e ser capaz de trabalhar em um modo de funcionalidade reduzido com dados somente leitura. As bibliotecas do Cliente de Armazenamento do Azure permitem que você defina uma política de repetição que pode ser lida do armazenamento secundário caso uma leitura do armazenamento primário falhe. Seu aplicativo também precisa estar ciente de que os dados no local secundário são eventualmente consistentes. Para obter mais informações, consulte a postagem do blog Opções de redundância de armazenamento do Azure e o Armazenamento Com Redundância Geográfica de Acesso de Leitura.

Problemas de desempenho

O desempenho de um aplicativo pode ser subjetivo, especialmente do ponto de vista do usuário. Portanto, é importante ter métricas de linha de base disponíveis para ajudá-lo a identificar onde pode haver um problema de desempenho. Muitos fatores podem afetar o desempenho de um serviço de armazenamento do Azure na perspectiva do aplicativo cliente. Esses fatores podem operar no serviço de armazenamento, no cliente ou na infraestrutura de rede; Portanto, é importante ter uma estratégia para identificar a origem do problema de desempenho.

Depois de identificar o local provável da causa do problema de desempenho das métricas, você poderá usar os arquivos de log para encontrar informações detalhadas para diagnosticar e solucionar o problema ainda mais.

A seção De diretrizes de solução de problemas posteriormente neste guia fornece mais informações sobre alguns problemas comuns relacionados ao desempenho que você pode encontrar.

Diagnosticar erros

Os usuários do aplicativo podem notificá-lo de erros relatados pelo aplicativo cliente. As Métricas de Armazenamento também registram contagens de diferentes tipos de erro de seus serviços de armazenamento, como NetworkError, ClientTimeoutError ou AuthorizationError. Embora as Métricas de Armazenamento registrem apenas contagens de diferentes tipos de erro, você pode obter mais detalhes sobre solicitações individuais examinando logs do lado do servidor, do lado do cliente e da rede. Normalmente, o código HTTP status retornado pelo serviço de armazenamento fornecerá uma indicação de por que a solicitação falhou.

Observação

Lembre-se de que você deve esperar ver alguns erros intermitentes: por exemplo, erros devido a condições transitórias de rede ou erros de aplicativo.

Os recursos a seguir são úteis para entender os códigos de erro e status relacionados ao armazenamento:

Problemas do emulador de armazenamento

O SDK do Azure inclui um emulador de armazenamento que você pode executar em uma estação de trabalho de desenvolvimento. Esse emulador simula a maior parte do comportamento dos serviços de armazenamento do Azure e é útil durante o desenvolvimento e teste, permitindo que você execute aplicativos que usam serviços de armazenamento do Azure sem a necessidade de uma assinatura do Azure e uma conta de armazenamento do Azure.

A seção de diretrizes de solução de problemas deste guia descreve alguns problemas comuns encontrados usando o emulador de armazenamento.

Ferramentas de log de armazenamento

O registro em log de armazenamento fornece log do lado do servidor de solicitações de armazenamento em sua conta de armazenamento do Azure. Para obter mais informações sobre como habilitar o log do lado do servidor e acessar os dados de log, consulte Habilitando log de armazenamento e acessando dados de log.

A Biblioteca de Clientes de Armazenamento para .NET permite coletar dados de log do lado do cliente relacionados às operações de armazenamento executadas pelo seu aplicativo. Para obter mais informações, consulte Log do lado do cliente com a Biblioteca de Clientes de Armazenamento do .NET.

Observação

Em algumas circunstâncias (como falhas de autorização do SAS), um usuário pode relatar um erro para o qual não é possível encontrar dados de solicitação nos logs de armazenamento do lado do servidor. Você pode usar os recursos de log da Biblioteca de Clientes de Armazenamento para investigar se a causa do problema está no cliente ou usar ferramentas de monitoramento de rede para investigar a rede.

Usando ferramentas de log de rede

Você pode capturar o tráfego entre o cliente e o servidor para fornecer informações detalhadas sobre os dados que o cliente e o servidor estão trocando e as condições de rede subjacentes. As ferramentas úteis de log de rede incluem:

Em muitos casos, os dados de log do Log de Armazenamento e da Biblioteca de Clientes de Armazenamento serão suficientes para diagnosticar um problema, mas, em alguns cenários, talvez você precise das informações mais detalhadas que essas ferramentas de log de rede podem fornecer. Por exemplo, usar o Fiddler para exibir mensagens HTTP e HTTPS permite exibir dados de cabeçalho e carga enviados de e para os serviços de armazenamento, o que permitiria examinar como um aplicativo cliente tenta novamente as operações de armazenamento. Analisadores de protocolo, como o Wireshark, operam no nível do pacote, permitindo que você exiba dados TCP, o que permitiria solucionar problemas de pacotes perdidos e problemas de conectividade.

Rastreamento de ponta a ponta

O rastreamento de ponta a ponta usando uma variedade de arquivos de log é uma técnica útil para investigar possíveis problemas. Você pode usar as informações de data/hora de seus dados de métricas para indicar onde começar a procurar nos arquivos de log informações detalhadas para ajudá-lo a solucionar o problema.

Correlacionar dados de log

Ao exibir logs de aplicativos cliente, rastreamentos de rede e log de armazenamento do lado do servidor, é fundamental poder correlacionar solicitações entre os diferentes arquivos de log. Os arquivos de log incluem vários campos diferentes que são úteis como identificadores de correlação. A ID da solicitação do cliente é o campo mais útil a ser usado para correlacionar entradas nos diferentes logs. No entanto, às vezes, pode ser útil usar a ID da solicitação do servidor ou carimbos de data/hora. As seções a seguir fornecem mais detalhes sobre essas opções.

ID da solicitação do cliente

A Biblioteca de Clientes de Armazenamento gera automaticamente uma ID de solicitação de cliente exclusiva para cada solicitação.

  • No log do lado do cliente que a Biblioteca de Clientes de Armazenamento cria, a ID da solicitação do Client Request ID cliente é exibida no campo de cada entrada de log relacionada à solicitação.
  • Em um rastreamento de rede, como um capturado pelo Fiddler, a ID da solicitação do cliente fica visível nas mensagens de solicitação como o valor do x-ms-client-request-id cabeçalho HTTP.
  • No log de Log de Armazenamento do lado do servidor, a ID da solicitação do cliente é exibida na coluna ID da solicitação do cliente.

Observação

É possível que várias solicitações compartilhem a mesma ID de solicitação do cliente porque o cliente pode atribuir esse valor (embora a Biblioteca de Clientes de Armazenamento atribua um novo valor automaticamente). Quando o cliente tenta novamente, todas as tentativas compartilham a mesma ID de solicitação do cliente. No caso de um lote enviado do cliente, o lote tem uma única ID de solicitação do cliente.

ID da solicitação do servidor

O serviço de armazenamento gera automaticamente IDs de solicitação de servidor.

  • No log de Log de Armazenamento do lado do servidor, a ID da solicitação do servidor é exibida na Request ID header coluna.
  • Em um rastreamento de rede, como um capturado pelo Fiddler, a ID da solicitação do servidor aparece em mensagens de resposta como o valor do x-ms-request-id cabeçalho HTTP.
  • No log do lado do cliente que a Biblioteca do Cliente de Armazenamento cria, a ID da solicitação do Operation Text servidor aparece na coluna para a entrada de log mostrando detalhes da resposta do servidor.

Observação

O serviço de armazenamento sempre atribui uma ID de solicitação de servidor exclusiva a cada solicitação recebida, portanto, cada tentativa de repetição do cliente e de cada operação incluída em um lote tem uma ID de solicitação de servidor exclusiva.

O exemplo de código abaixo demonstra como usar uma ID de solicitação de cliente personalizada.

var connectionString = Constants.connectionString;

BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

BlobContainerClient blobContainerClient = blobServiceClient.GetBlobContainerClient("demcontainer");

BlobClient blobClient = blobContainerClient.GetBlobClient("testImage.jpg");

string clientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());

using (HttpPipeline.CreateClientRequestIdScope(clientRequestID))
{
    BlobDownloadInfo download = blobClient.Download();

    using (FileStream downloadFileStream = File.OpenWrite("C:\\testImage.jpg"))
    {
        download.Content.CopyTo(downloadFileStream);
        downloadFileStream.Close();
    }
}

Timestamps

Você também pode usar carimbos de data/hora para localizar entradas de log relacionadas, mas tenha cuidado com qualquer distorção de relógio entre o cliente e o servidor que possa existir. Pesquisa mais ou menos 15 minutos para entradas correspondentes do lado do servidor com base no carimbo de data/hora no cliente. Lembre-se de que os metadados de blob para os blobs que contêm métricas indicam o intervalo de tempo para as métricas armazenadas no blob. Esse intervalo de tempo será útil se você tiver muitos blobs de métricas para o mesmo minuto ou hora.

Diretrizes de solução de problemas

Esta seção ajudará você com o diagnóstico e a solução de problemas de alguns dos problemas comuns que seu aplicativo pode encontrar ao usar os serviços de armazenamento do Azure. Use a lista abaixo para localizar as informações relevantes para seu problema específico.

Árvore de decisão de solução de problemas

O problema está relacionado ao desempenho de um dos serviços de armazenamento?

O problema está relacionado à disponibilidade de um dos serviços de armazenamento?

Seu aplicativo cliente está recebendo uma resposta HTTP 4XX (como 404) de um serviço de armazenamento?

As métricas mostram que entradas de log percentSuccess ou analytics baixas têm operações com status de transação de ClientOtherErrors.

As métricas de capacidade mostram um aumento inesperado no uso da capacidade de armazenamento.

Seu problema surge do uso do emulador de armazenamento para desenvolvimento ou teste.

Você está encontrando problemas para instalar o SDK do Azure para .NET.

Você tem um problema diferente com um serviço de armazenamento.

As métricas mostram média altaE2ELatency e baixa MédiaServerLatency

A ilustração abaixo da ferramenta de monitoramento portal do Azure mostra um exemplo em que o AverageE2ELatency é significativamente maior que o AverageServerLatency.

Ilustração do portal do Azure que mostra um exemplo em que o AverageE2ELatency é significativamente maior que o AverageServerLatency.

O serviço de armazenamento calcula apenas a métrica AverageE2ELatency para solicitações bem-sucedidas e, ao contrário de AverageServerLatency, inclui o tempo que o cliente leva para enviar os dados e receber reconhecimento do serviço de armazenamento. Portanto, uma diferença entre AverageE2ELatency e AverageServerLatency pode ser devido à lentidão da resposta do aplicativo cliente ou devido às condições na rede.

Observação

Você também pode exibir E2ELatency e ServerLatency para operações de armazenamento individuais nos dados de log de armazenamento.

Investigando problemas de desempenho do cliente

Os possíveis motivos para o cliente responder lentamente incluem ter um número limitado de conexões ou threads disponíveis ou ter poucos recursos, como CPU, memória ou largura de banda de rede. Você pode ser capaz de resolve o problema modificando o código do cliente para ser mais eficiente (por exemplo, usando chamadas assíncronas para o serviço de armazenamento) ou usando uma Máquina Virtual maior (com mais núcleos e mais memória).

Para os serviços de tabela e fila, o algoritmo Nagle também pode causar alta MédiaE2ELatency em comparação com AverageServerLatency. Para obter mais informações, confira Algoritmo do Nagle não é amigável para solicitações pequenas. Você pode desabilitar o algoritmo Nagle no código usando a ServicePointManager classe no System.Net namespace. Você deve fazer isso antes de fazer chamadas para a tabela ou serviços de fila em seu aplicativo, pois isso não afeta as conexões que já estão abertas. O exemplo a seguir vem do Application_Start método em uma função de trabalho.

var connectionString = Constants.connectionString;

QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);

ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

Você deve marcar os logs do lado do cliente para ver quantas solicitações seu aplicativo cliente está enviando e marcar para geral . Gargalos de desempenho relacionados à NET em seu cliente, como CPU, coleta de lixo .NET, utilização de rede ou memória. Como ponto de partida para solucionar problemas de aplicativos cliente .NET, consulte Depuração, Rastreamento e Criação de Perfil.

Investigando problemas de latência de rede

Normalmente, a latência de ponta a ponta causada pela rede é devido a condições transitórias. Você pode investigar problemas de rede transitórios e persistentes, como pacotes descartados, usando ferramentas como o Wireshark.

Para obter mais informações sobre como usar o Wireshark para solucionar problemas de rede, consulte Apêndice 2: Usando Wireshark para capturar o tráfego de rede.

As métricas mostram baixa MédiaE2ELatency e baixa MédiaServerLatency, mas o cliente está experimentando alta latência

Nesse cenário, a causa mais provável é um atraso nas solicitações de armazenamento que chegam ao serviço de armazenamento. Você deve investigar por que as solicitações do cliente não estão passando para o serviço de blob.

Um possível motivo para o cliente atrasar o envio de solicitações é que há um número limitado de conexões ou threads disponíveis.

Além disso, marcar se o cliente está executando várias tentativas e investigue o motivo se ele estiver. Para determinar se o cliente está executando várias tentativas, você pode:

  • Examine os logs de Análise de Armazenamento. Se várias tentativas estiverem acontecendo, você verá várias operações com a mesma ID de solicitação do cliente, mas com IDs de solicitação de servidor diferentes.
  • Examine os logs do cliente. O registro em log verboso indicará que ocorreu uma nova tentativa.
  • Depure seu código e marcar as propriedades do OperationContext objeto associado à solicitação. Se a operação tiver sido repetida, a RequestResults propriedade incluirá várias IDs de solicitação de servidor exclusivas. Você também pode marcar os horários de início e término de cada solicitação. Para obter mais informações, consulte o exemplo de código na seção ID da solicitação do servidor.

Se não houver problemas no cliente, você deverá investigar possíveis problemas de rede, como perda de pacotes. Você pode usar ferramentas como o Wireshark para investigar problemas de rede.

Para obter mais informações sobre como usar o Wireshark para solucionar problemas de rede, consulte Apêndice 2: Usando Wireshark para capturar o tráfego de rede.

Métricas mostram alta MédiaServerLatency

No caso de média altaServerLatency para solicitações de download de blob, você deve usar os logs de log de armazenamento para ver se há solicitações repetidas para o mesmo blob (ou conjunto de blobs). Para solicitações de carregamento de blob, você deve investigar qual tamanho de bloco o cliente está usando (por exemplo, blocos com menos de 64 K de tamanho podem resultar em sobrecargas, a menos que as leituras também estejam em partes inferiores a 64 K) e se vários clientes estiverem carregando blocos no mesmo blob em paralelo. Você também deve marcar as métricas por minuto para picos no número de solicitações que resultam em exceder as metas de escalabilidade por segundo. Para obter mais informações, consulte Métricas mostram um aumento no PercentTimeoutError.

Se você vir alta MédiaServerLatency para solicitações de download de blob quando houver solicitações repetidas para o mesmo blob ou conjunto de blobs, considere armazenar esses blobs usando o Cache do Azure ou a CDN (Rede de Distribuição de Conteúdo do Azure). Para solicitações de upload, você pode melhorar a taxa de transferência usando um tamanho de bloco maior. Para consultas em tabelas, também é possível implementar o cache do lado do cliente em clientes que executam as mesmas operações de consulta e em que os dados não são alterados com frequência.

Valores high averageServerLatency também podem ser um sintoma de tabelas ou consultas mal projetadas que resultam em operações de verificação ou que seguem o anti-padrão de apêndice/prepend. Para obter mais informações, consulte Métricas mostram um aumento no PercentThrottlingError.

Observação

Você pode encontrar uma lista de verificação de desempenho abrangente aqui: Armazenamento do Microsoft Azure Lista de verificação de desempenho e escalabilidade.

Você está enfrentando atrasos inesperados na entrega de mensagens em uma fila

Se você estiver enfrentando um atraso entre o tempo em que um aplicativo adiciona uma mensagem a uma fila e a hora em que ele fica disponível para ler na fila, siga as seguintes etapas para diagnosticar o problema:

  • Verifique se o aplicativo está adicionando as mensagens com êxito à fila. Verifique se o aplicativo não está repetindo o AddMessage método várias vezes antes de ter êxito. Os logs da Biblioteca de Clientes de Armazenamento mostrarão novas tentativas repetidas de operações de armazenamento.
  • Verifique se não há distorção de relógio entre a função de trabalho que adiciona a mensagem à fila e à função de trabalho que lê a mensagem da fila. Uma distorção de relógio faz com que pareça que há um atraso no processamento.
  • Verifique se a função de trabalho que lê as mensagens da fila está falhando. Se um cliente de fila chamar o GetMessage método, mas não responder com um reconhecimento, a mensagem permanecerá invisível na fila até que o invisibilityTimeout período expire. Neste ponto, a mensagem fica disponível para processamento novamente.
  • Verifique se o comprimento da fila está crescendo ao longo do tempo. Isso pode ocorrer se você não tiver trabalhadores suficientes disponíveis para processar todas as mensagens que outros trabalhadores estão colocando na fila. Além disso, marcar as métricas para ver se as solicitações de exclusão estão falhando e a contagem de dequeue em mensagens, o que pode indicar tentativas repetidas de falha para excluir a mensagem.
  • Examine os logs de log de armazenamento para quaisquer operações de fila que tenham valores E2ELatency e ServerLatency acima do esperado em um período maior do que o normal.

As métricas mostram um aumento no PercentThrottlingError

Erros de limitação ocorrem quando você excede as metas de escalabilidade de um serviço de armazenamento. O serviço de armazenamento limita para garantir que nenhum cliente ou locatário possa usar o serviço às custas de outras pessoas. Para obter mais informações, consulte Escalabilidade e metas de desempenho para contas de armazenamento padrão para obter detalhes sobre metas de escalabilidade para contas de armazenamento e metas de desempenho para partições em contas de armazenamento.

Se a métrica PercentThrottlingError mostrar um aumento no percentual de solicitações que estão falhando com um erro de limitação, você precisará investigar um dos dois cenários:

Um aumento no PercentThrottlingError geralmente ocorre ao mesmo tempo que um aumento no número de solicitações de armazenamento ou quando você está inicialmente testando o aplicativo. Isso também pode se manifestar no cliente como "503 Server Busy" ou "500 Operation Timeout" HTTP status mensagens de operações de armazenamento.

Aumento transitório em PercentThrottlingError

Se você estiver vendo picos no valor de PercentThrottlingError que coincidem com períodos de alta atividade para o aplicativo, você pode implementar uma estratégia de back-off exponencial (não linear) para repetições em seu cliente. As tentativas de back-off reduzem a carga imediata na partição e ajudam seu aplicativo a suavizar os picos de tráfego. Para obter mais informações sobre como implementar políticas de repetição usando a Biblioteca de Clientes de Armazenamento, consulte o namespace Microsoft.Azure.Storage.RetryPolicies.

Observação

Você também pode ver picos no valor de PercentThrottlingError que não coincidem com períodos de alta atividade para o aplicativo. A causa mais provável é o serviço de armazenamento movendo partições para melhorar o balanceamento de carga.

Aumento permanente no PercentThrottlingError

Se você estiver vendo um valor consistentemente alto para PercentThrottlingError após um aumento permanente em seus volumes de transação ou quando estiver executando seus testes de carga iniciais em seu aplicativo, você precisará avaliar como seu aplicativo está usando partições de armazenamento e se ele está se aproximando dos destinos de escalabilidade para uma conta de armazenamento. Por exemplo, se você estiver vendo erros de limitação em uma fila (que conta como uma única partição), considere usar filas adicionais para espalhar as transações em várias partições. Se você estiver vendo erros de limitação em uma tabela, precisará considerar o uso de um esquema de partição diferente para espalhar suas transações em várias partições usando um intervalo mais amplo de valores de chave de partição. Uma causa comum desse problema é o anti-padrão prepend/acréscimo em que você seleciona a data como a chave de partição e, em seguida, todos os dados em um determinado dia são gravados em uma partição: sob carga, isso pode resultar em um gargalo de gravação. Considere um design de partição diferente ou avalie se usar o armazenamento de blobs pode ser uma solução melhor. Além disso, marcar se a limitação está ocorrendo como resultado de picos no tráfego e investigar maneiras de suavizar seu padrão de solicitações.

Se você distribuir suas transações em várias partições, ainda deverá estar ciente dos limites de escalabilidade definidos para a conta de armazenamento. Por exemplo, se você usou dez filas, cada uma processando o máximo de 2.000 mensagens 1KB por segundo, você estará no limite geral de 20.000 mensagens por segundo para a conta de armazenamento. Se você precisar processar mais de 20.000 entidades por segundo, considere usar várias contas de armazenamento. Você também deve ter em mente que o tamanho de suas solicitações e entidades tem um impacto quando o serviço de armazenamento limita seus clientes. Se você tiver solicitações e entidades maiores, poderá ser limitado mais cedo.

O design de consulta ineficiente também pode fazer com que você atinja os limites de escalabilidade para partições de tabela. Por exemplo, uma consulta com um filtro que seleciona apenas um por cento das entidades em uma partição, mas que verifica todas as entidades em uma partição precisará acessar cada entidade. Cada leitura de entidade contará para o número total de transações nessa partição; Portanto, você pode alcançar facilmente os destinos de escalabilidade.

Observação

Seu teste de desempenho deve revelar quaisquer designs de consulta ineficientes em seu aplicativo.

As métricas mostram um aumento no PercentTimeoutError

Suas métricas mostram um aumento no PercentTimeoutError para um de seus serviços de armazenamento. Ao mesmo tempo, o cliente recebe um grande volume de mensagens HTTP status "500 Operation Timeout" de operações de armazenamento.

Observação

Você pode ver erros de tempo limite temporariamente à medida que o serviço de armazenamento equilibra as solicitações movendo uma partição para um novo servidor.

A métrica PercentTimeoutError é uma agregação das seguintes métricas: ClientTimeoutError, AnonymousClientTimeoutError, SASClientTimeoutError, ServerTimeoutError, AnonymousServerTimeoutError e SASServerTimeoutError.

Os tempos limite do servidor são causados por um erro no servidor. Os tempos limite do cliente acontecem porque uma operação no servidor excedeu o tempo limite especificado pelo cliente; por exemplo, um cliente que usa a Biblioteca de Clientes de Armazenamento pode definir um tempo limite para uma operação usando a ServerTimeout propriedade da QueueRequestOptions classe.

Os tempos limite do servidor indicam um problema com o serviço de armazenamento que requer uma investigação mais aprofundada. Você pode usar métricas para ver se está atingindo os limites de escalabilidade do serviço e identificar quaisquer picos no tráfego que possam estar causando esse problema. Se o problema for intermitente, pode ser devido à atividade de balanceamento de carga no serviço. Se o problema for persistente e não for causado pelo seu aplicativo atingir os limites de escalabilidade do serviço, você deverá gerar um problema de suporte. Para tempo limite do cliente, você deve decidir se o tempo limite está definido como um valor apropriado no cliente e alterar o valor de tempo limite definido no cliente ou investigar como você pode melhorar o desempenho das operações no serviço de armazenamento, por exemplo, otimizando suas consultas de tabela ou reduzindo o tamanho das mensagens.

As métricas mostram um aumento no PercentNetworkError

Suas métricas mostram um aumento no PercentNetworkError para um de seus serviços de armazenamento. A métrica PercentNetworkError é uma agregação das seguintes métricas: NetworkError, AnonymousNetworkError e SASNetworkError. Isso ocorre quando o serviço de armazenamento detecta um erro de rede quando o cliente faz uma solicitação de armazenamento.

A causa mais comum desse erro é a desconexão de um cliente antes que um tempo limite expire no serviço de armazenamento. Investigue o código em seu cliente para entender por que e quando o cliente se desconecta do serviço de armazenamento. Você também pode usar Wireshark ou Tcping para investigar problemas de conectividade de rede do cliente. Essas ferramentas são descritas nos Apêndices.

O cliente está recebendo mensagens HTTP 403 (proibidas)

Se o aplicativo cliente estiver gerando erros HTTP 403 (Proibido), uma causa provável é que o cliente esteja usando uma SAS (Assinatura de Acesso Compartilhado) expirada quando envia uma solicitação de armazenamento (embora outras causas possíveis incluam distorção de relógio, chaves inválidas e cabeçalhos vazios). Se uma chave SAS expirada for a causa, você não verá nenhuma entrada nos dados de log de log de armazenamento do lado do servidor. A tabela a seguir mostra um exemplo do log do lado do cliente gerado pela Biblioteca de Clientes de Armazenamento que ilustra esse problema que ocorre:

Origem Verbosidade Verbosidade ID da solicitação do cliente Texto da operação
Microsoft.Azure.Storage Informações 3 85d077ab-... Starting operation with location Primary per location mode PrimaryOnly.
Microsoft.Azure.Storage Informações 3 85d077ab -... Starting synchronous request to https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Synchronous_request.
Microsoft.Azure.Storage Informações 3 85d077ab -... Waiting for response.
Microsoft.Azure.Storage Aviso 2 85d077ab -... Exception thrown while waiting for response: The remote server returned an error: (403) Forbidden.
Microsoft.Azure.Storage Informações 3 85d077ab -... Response received. Status code = 403, Request ID = <Request ID>, Content-MD5 = , ETag = .
Microsoft.Azure.Storage Aviso 2 85d077ab -... Exception thrown during the operation: The remote server returned an error: (403) Forbidden..
Microsoft.Azure.Storage Informações 3 85d077ab -... Checking if the operation should be retried. Retry count = 0, HTTP status code = 403, Exception = The remote server returned an error: (403) Forbidden..
Microsoft.Azure.Storage Informações 3 85d077ab -... The next location has been set to Primary, based on the location mode.
Microsoft.Azure.Storage Erro 1 85d077ab -... Retry policy did not allow for a retry. Failing with The remote server returned an error: (403) Forbidden.

Nesse cenário, você deve investigar por que o token SAS está expirando antes que o cliente envie o token para o servidor:

  • Normalmente, você não deve definir uma hora de início ao criar um SAS para um cliente usar imediatamente. Se houver pequenas diferenças de relógio entre o host que gera o SAS usando o tempo atual e o serviço de armazenamento, é possível que o serviço de armazenamento receba um SAS que ainda não seja válido.
  • Não defina um tempo de validade muito curto em um SAS. Novamente, pequenas diferenças de relógio entre o host que gera o SAS e o serviço de armazenamento podem levar a uma SAS aparentemente expirando antes do previsto.
  • O parâmetro de versão na chave SAS (por exemplo, sv=2015-04-05) corresponde à versão da Biblioteca de Clientes de Armazenamento que você está usando? Recomendamos que você sempre use a versão mais recente da Biblioteca de Clientes de Armazenamento.
  • Se você regenerar as chaves de acesso ao armazenamento, todos os tokens SAS existentes poderão ser invalidados. Esse problema poderá surgir se você gerar tokens SAS com um longo tempo de validade para os aplicativos cliente armazenarem em cache.

Se você estiver usando a Biblioteca de Clientes de Armazenamento para gerar tokens SAS, será fácil criar um token válido. No entanto, se você estiver usando a API REST de Armazenamento e construindo os tokens SAS manualmente, consulte Delegando acesso com uma Assinatura de Acesso Compartilhado.

O cliente está recebendo mensagens HTTP 404 (não encontradas)

Se o aplicativo cliente receber uma mensagem HTTP 404 (Não encontrada) do servidor, isso implica que o objeto que o cliente estava tentando usar (como uma entidade, tabela, blob, contêiner ou fila) não existe no serviço de armazenamento. Há várias razões possíveis para isso, como:

O cliente ou outro processo excluiu anteriormente o objeto

Em cenários em que o cliente está tentando ler, atualizar ou excluir dados em um serviço de armazenamento, geralmente é fácil identificar nos logs do lado do servidor uma operação anterior que excluiu o objeto em questão do serviço de armazenamento. Geralmente, os dados de log mostram que outro usuário ou processo excluiu o objeto. No log de Log de Armazenamento do lado do servidor, as colunas operation-type e requested-object-key mostram quando um cliente excluiu um objeto.

No cenário em que um cliente está tentando inserir um objeto, talvez não seja imediatamente óbvio por que isso resulta em uma resposta HTTP 404 (Não encontrada), dado que o cliente está criando um novo objeto. No entanto, se o cliente estiver criando um blob, ele deverá ser capaz de localizar o contêiner de blob. Se o cliente estiver criando uma mensagem, ele deverá ser capaz de encontrar uma fila. E se o cliente estiver adicionando uma linha, ele deve ser capaz de encontrar a tabela.

Você pode usar o log do lado do cliente da Biblioteca de Clientes de Armazenamento para obter uma compreensão mais detalhada de quando o cliente envia solicitações específicas para o serviço de armazenamento.

O log do lado do cliente a seguir gerado pela biblioteca cliente de armazenamento ilustra o problema quando o cliente não consegue encontrar o contêiner para o blob que está criando. Este log inclui detalhes das seguintes operações de armazenamento:

ID do Pedido Operação
07b26a5d-... DeleteIfExists método para excluir o contêiner de blob. Observe que essa operação inclui uma solicitação HEAD para marcar para a existência do contêiner.
e2d06d78... CreateIfNotExists método para criar o contêiner de blob. Observe que essa operação inclui uma solicitação HEAD que verifica a existência do contêiner. O HEAD retorna uma mensagem 404, mas continua.
de8b1c3c-... UploadFromStream método para criar o blob. A PUT solicitação falha com uma mensagem 404.

Entradas de log:

ID do Pedido Texto da operação
07b26a5d-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
07b26a5d-... StringToSign = HEAD............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:11 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
07b26a5d-... Waiting for response.
07b26a5d-... Response received. Status code = 200, Request ID = eeead849-...Content-MD5 = , ETag = &quot;0x8D14D2DC63D059B&quot;.
07b26a5d-... Response headers were processed successfully, proceeding with the rest of the operation.
07b26a5d-... Downloading response body.
07b26a5d-... Operation completed successfully.
07b26a5d-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
07b26a5d-... StringToSign = DELETE............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
07b26a5d-... Waiting for response.
07b26a5d-... Response received. Status code = 202, Request ID = 6ab2a4cf-..., Content-MD5 = , ETag = .
07b26a5d-... Response headers were processed successfully, proceeding with the rest of the operation.
07b26a5d-... Downloading response body.
07b26a5d-... Operation completed successfully.
e2d06d78-... Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
e2d06d78-... StringToSign = HEAD............x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
e2d06d78-... Waiting for response.
de8b1c3c-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer/blobCreated.txt.
de8b1c3c-... StringToSign = PUT...64.qCmF+TQLPhq/YYK50mP9ZQ==........x-ms-blob-type:BlockBlob.x-ms-client-request-id:de8b1c3c-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer/blobCreated.txt.
de8b1c3c-... Preparing to write request data.
e2d06d78-... Exception thrown while waiting for response: The remote server returned an error: (404) Not Found..
e2d06d78-... Response received. Status code = 404, Request ID = 353ae3bc-..., Content-MD5 = , ETag = .
e2d06d78-... Response headers were processed successfully, proceeding with the rest of the operation.
e2d06d78-... Downloading response body.
e2d06d78-... Operation completed successfully.
e2d06d78-... Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
e2d06d78-... StringToSign = PUT...0.........x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
e2d06d78-... Waiting for response.
de8b1c3c-... Writing request data.
de8b1c3c-... Waiting for response.
e2d06d78-... Exception thrown while waiting for response: The remote server returned an error: (409) Conflict..
e2d06d78-... Response received. Status code = 409, Request ID = c27da20e-..., Content-MD5 = , ETag = .
e2d06d78-... Downloading error response body.
de8b1c3c-... Exception thrown while waiting for response: The remote server returned an error: (404) Not Found..
de8b1c3c-... Response received. Status code = 404, Request ID = 0eaeab3e-..., Content-MD5 = , ETag = .
de8b1c3c-... Exception thrown during the operation: The remote server returned an error: (404) Not Found..
de8b1c3c-... Retry policy did not allow for a retry. Failing with The remote server returned an error: (404) Not Found..
e2d06d78-... Retry policy did not allow for a retry. Failing with The remote server returned an error: (409) Conflict..

Neste exemplo, o log mostra que o cliente está intercalando solicitações do CreateIfNotExists método (ID da solicitação e2d06d78...) com as solicitações do UploadFromStream método (de8b1c3c-...). Essa intercalação acontece porque o aplicativo cliente está invocando esses métodos de forma assíncrona. Modifique o código assíncrono no cliente para garantir que ele crie o contêiner antes de tentar carregar qualquer dado em um blob nesse contêiner. Idealmente, você deve criar todos os contêineres com antecedência.

Um problema de autorização de SAS (Assinatura de Acesso Compartilhado)

Se o aplicativo cliente tentar usar uma chave SAS que não inclua as permissões necessárias para a operação, o serviço de armazenamento retornará uma mensagem HTTP 404 (Não encontrada) ao cliente. Ao mesmo tempo, você também verá um valor não zero para SASAuthorizationError nas métricas.

A tabela a seguir mostra uma mensagem de log do lado do servidor de exemplo do arquivo de log de log de armazenamento:

Nome Valor
Hora de início da solicitação 2014-05-30T06:17:48.4473697Z
Tipo de operação GetBlobProperties
Solicitar status SASAuthorizationError
Código de status de HTTP 404
Tipo de autenticação Sas
Tipo de serviço Blob
URL de solicitação https://domemaildist.blob.core.windows.net/azureimblobcontainer/blobCreatedViaSAS.txt
  ?sv=2014-02-14&sr=c&si=mypolicy&sig=XXXXX&; api-version=2014-02-14
Cabeçalho ID da solicitação <Cabeçalho ID da solicitação>
ID da solicitação do cliente <ID da solicitação do cliente>

Investigue por que seu aplicativo cliente está tentando executar uma operação para a qual não foi concedida permissões.

O código JavaScript do lado do cliente não tem permissão para acessar o objeto

Se você estiver usando um cliente JavaScript e o serviço de armazenamento estiver retornando mensagens HTTP 404, você marcar para os seguintes erros javaScript no navegador:

SEC7120: origem http://localhost:56309 não encontrada no cabeçalho Access-Control-Allow-Origin.
SCRIPT7002: XMLHttpRequest: erro de rede 0x80070005, o acesso é negado.

Observação

Você pode usar as Ferramentas de Desenvolvedor F12 na Internet Explorer para rastrear as mensagens trocadas entre o navegador e o serviço de armazenamento quando estiver solucionando problemas do JavaScript do lado do cliente.

Esses erros ocorrem porque o navegador da Web implementa a mesma restrição de segurança de política de origem que impede uma página da Web de chamar uma API em um domínio diferente do domínio do qual a página vem.

Para contornar o problema do JavaScript, você pode configurar o CORS (Compartilhamento de Recursos de Origem Cruzada) para o serviço de armazenamento que o cliente está acessando. Para obter mais informações, confira Suporte ao CORS (Compartilhamento de Recursos de Origem Cruzada) para Serviços de Armazenamento do Azure.

O exemplo de código a seguir mostra como configurar o serviço de blob para permitir que o JavaScript em execução no domínio Contoso acesse um blob no serviço de armazenamento de blobs:

var connectionString = Constants.connectionString;

 BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

 BlobServiceProperties sp = blobServiceClient.GetProperties();

 // Set the service properties.
 sp.DefaultServiceVersion = "2013-08-15";
 BlobCorsRule bcr = new BlobCorsRule();
 bcr.AllowedHeaders = "*";

 bcr.AllowedMethods = "GET,POST";
 bcr.AllowedOrigins = "http://www.contoso.com";
 bcr.ExposedHeaders = "x-ms-*";
 bcr.MaxAgeInSeconds = 5;
 sp.Cors.Clear();
 sp.Cors.Add(bcr);
 blobServiceClient.SetProperties(sp);

Falha na rede

Em algumas circunstâncias, pacotes de rede perdidos podem levar o serviço de armazenamento a retornar mensagens HTTP 404 ao cliente. Por exemplo, quando seu aplicativo cliente está excluindo uma entidade do serviço de tabela, você verá o cliente lançar uma exceção de armazenamento relatando uma mensagem "HTTP 404 (Não Encontrado)" status do serviço de tabela. Ao investigar a tabela no serviço de armazenamento de tabelas, você verá que o serviço excluiu a entidade conforme solicitado.

Os detalhes de exceção no cliente incluem a ID da solicitação (7e84f12d...) atribuída pelo serviço de tabela para a solicitação. Você pode usar essas informações para localizar os detalhes da solicitação nos logs de armazenamento do lado do servidor pesquisando na request-id-header coluna no arquivo de log. Você também pode usar as métricas para identificar quando ocorrem falhas como essa e pesquisar os arquivos de log com base na hora em que as métricas registraram esse erro. Essa entrada de log mostra que a exclusão falhou com uma mensagem status "HTTP (404) Client Other Error". A mesma entrada de log também inclui a ID da solicitação gerada pelo cliente na client-request-id coluna (813ea74f...).

O log do lado do servidor também inclui outra entrada com o mesmo client-request-id valor (813ea74f...) para uma operação de exclusão bem-sucedida para a mesma entidade e do mesmo cliente. Essa operação de exclusão bem-sucedida ocorreu pouco antes da solicitação de exclusão com falha.

A causa mais provável desse cenário é que o cliente enviou uma solicitação de exclusão para a entidade para o serviço de tabela, que teve êxito, mas não recebeu um reconhecimento do servidor (talvez devido a um problema temporário de rede). O cliente então repetiu automaticamente a operação (usando o mesmo client-request-id), e essa nova tentativa falhou porque a entidade já havia sido excluída.

Se esse problema ocorrer com frequência, você deverá investigar por que o cliente não está recebendo reconhecimentos do serviço de tabela. Se o problema for intermitente, você deverá capturar o erro "HTTP (404) Não Encontrado" e fazer logon no cliente, mas permitir que o cliente continue.

O cliente está recebendo mensagens HTTP 409 (Conflito)

A tabela a seguir mostra um extrato do log do lado do servidor para duas operações de cliente: DeleteIfExists seguido imediatamente CreateIfNotExists usando o mesmo nome de contêiner de blob. Cada operação de cliente resulta em duas solicitações enviadas ao servidor, primeiro uma solicitação GetContainerProperties para marcar se o contêiner existir, seguido pela solicitação DeleteContainer ouCreateContainer.

Carimbo de data/hora Operação Resultado Nome do contêiner ID da solicitação do cliente
05:10:13.7167225 GetContainerProperties 200 mmcont c9f52c89-...
05:10:13.8167325 DeleteContainer 202 mmcont c9f52c89-...
05:10:13.8987407 GetContainerProperties 404 mmcont bc881924-...
05:10:14.2147723 CreateContainer 409 mmcont bc881924-...

O código no aplicativo cliente exclui e recria imediatamente um contêiner de blob usando o mesmo nome: o CreateIfNotExists método (ID de solicitação do cliente bc881924-...) eventualmente falha com o erro HTTP 409 (Conflito). Quando um cliente exclui contêineres de blob, tabelas ou filas, há um breve período para que o nome fique disponível novamente.

O aplicativo cliente deve usar nomes de contêiner exclusivos sempre que criar novos contêineres se o padrão de exclusão/recriação for comum.

As métricas mostram que entradas de log percentSuccess ou analytics baixas têm operações com status de transação do ClientOtherErrors

A métrica PercentSuccess captura a porcentagem de operações que foram bem-sucedidas com base em seu Código de Status HTTP. As operações com códigos status de 2XX contam como bem-sucedidas, enquanto as operações com códigos status nos intervalos 3XX, 4XX e 5XX são contadas como mal sucedidas e reduzem o valor da métrica PercentSuccess. Nos arquivos de log de armazenamento do lado do servidor, essas operações são registradas com uma status de transação de ClientOtherErrors.

É importante observar que essas operações foram concluídas com êxito e, portanto, não afetam outras métricas, como disponibilidade. Alguns exemplos de operações que são executadas com êxito, mas que podem resultar em códigos http status mal sucedidos incluem:

  • ResourceNotFound (Not Found 404), por exemplo, de uma solicitação GET a um blob que não existe.
  • ResourceAlreadyExists (Conflict 409), por exemplo, de uma CreateIfNotExist operação em que o recurso já existe.
  • ConditionNotMet (Not Modified 304), por exemplo, de uma operação condicional como quando um cliente envia um ETag valor e um cabeçalho HTTP If-None-Match para solicitar uma imagem somente se ela tiver sido atualizada desde a última operação.

Você pode encontrar uma lista de códigos de erro comuns da API REST que os serviços de armazenamento retornam na página Códigos de erro de API REST comuns.

As métricas de capacidade mostram um aumento inesperado no uso da capacidade de armazenamento

Se você vir alterações repentinas e inesperadas no uso da capacidade em sua conta de armazenamento, poderá investigar os motivos primeiro examinando suas métricas de disponibilidade; por exemplo, um aumento no número de solicitações de exclusão com falha pode levar a um aumento na quantidade de armazenamento de blobs que você está usando como operações de limpeza específicas do aplicativo que você poderia esperar estar liberando espaço pode não estar funcionando como esperado (por exemplo, porque os tokens SAS usados para liberar espaço expiraram).

Seu problema surge do uso do emulador de armazenamento para desenvolvimento ou teste

Normalmente, você usa o emulador de armazenamento durante o desenvolvimento e o teste para evitar o requisito de uma conta de armazenamento do Azure. Os problemas comuns que podem ocorrer quando você está usando o emulador de armazenamento são:

O recurso "X" não está funcionando no emulador de armazenamento

O emulador de armazenamento não dá suporte a todos os recursos dos serviços de armazenamento do Azure, como o serviço de arquivo. Para obter mais informações, consulte Usar o Emulador de Armazenamento do Azure para Desenvolvimento e Teste.

Para os recursos que o emulador de armazenamento não dá suporte, use o serviço de armazenamento do Azure na nuvem.

Erro "O valor de um dos cabeçalhos HTTP não está no formato correto" ao usar o emulador de armazenamento

Você está testando seu aplicativo que usa a Biblioteca de Clientes de Armazenamento no emulador de armazenamento local e chamadas de método, como CreateIfNotExists fail com a mensagem de erro "O valor de um dos cabeçalhos HTTP não está no formato correto". Isso indica que a versão do emulador de armazenamento que você está usando não dá suporte à versão da biblioteca de clientes de armazenamento que você está usando. A Biblioteca de Clientes de Armazenamento adiciona o cabeçalho x-ms-version a todas as solicitações que ela faz. Se o emulador de armazenamento não reconhecer o valor no x-ms-version cabeçalho, ele rejeitará a solicitação.

Você pode usar os logs do Cliente da Biblioteca de Armazenamento para ver o valor do x-ms-version header que ele está enviando. Você também pode ver o valor do se você usar Fiddler x-ms-version header para rastrear as solicitações de seu aplicativo cliente.

Normalmente, esse cenário ocorre se você instalar e usar a versão mais recente da Biblioteca de Clientes de Armazenamento sem atualizar o emulador de armazenamento. Você deve instalar a versão mais recente do emulador de armazenamento ou usar o armazenamento em nuvem em vez do emulador para desenvolvimento e teste.

Executar o emulador de armazenamento requer privilégios administrativos

Você é solicitado a obter credenciais de administrador ao executar o emulador de armazenamento. Isso só ocorre quando você está inicializando o emulador de armazenamento pela primeira vez. Depois de inicializar o emulador de armazenamento, você não precisará de privilégios administrativos para executá-lo novamente.

Para obter mais informações, consulte Usar o Emulador de Armazenamento do Azure para Desenvolvimento e Teste. Você também pode inicializar o emulador de armazenamento no Visual Studio, o que também exigirá privilégios administrativos.

Você está encontrando problemas para instalar o SDK do Azure para .NET

Quando você tenta instalar o SDK, ele falha ao tentar instalar o emulador de armazenamento no computador local. O log de instalação contém uma das seguintes mensagens:

  • CAQuietExec: Erro: não é possível acessar a instância do SQL
  • CAQuietExec: Erro: não é possível criar banco de dados

A causa é um problema com a instalação localDB existente. Por padrão, o emulador de armazenamento usa o LocalDB para persistir dados quando simula os serviços de armazenamento do Azure. Você pode redefinir sua instância localDB executando os comandos a seguir em uma janela de prompt de comando antes de tentar instalar o SDK.

sqllocaldb stop v11.0
sqllocaldb delete v11.0
delete %USERPROFILE%\WAStorageEmulatorDb3*.*
sqllocaldb create v11.0

O delete comando remove todos os arquivos de banco de dados antigos de instalações anteriores do emulador de armazenamento.

Você tem um problema diferente com um serviço de armazenamento

Se as seções de solução de problemas anteriores não incluirem o problema que você está tendo com um serviço de armazenamento, você deverá adotar a seguinte abordagem para diagnosticar e solucionar problemas.

  • Verifique suas métricas para ver se há alguma alteração em relação ao comportamento esperado da linha de base. Pelas métricas, você pode ser capaz de determinar se o problema é transitório ou permanente e quais operações de armazenamento o problema está afetando.
  • Você pode usar as informações de métricas para ajudá-lo a pesquisar seus dados de log do lado do servidor para obter informações mais detalhadas sobre quaisquer erros que estejam ocorrendo. Essas informações podem ajudá-lo a solucionar problemas e resolve o problema.
  • Se as informações nos logs do lado do servidor não forem suficientes para solucionar o problema com êxito, você poderá usar os logs do lado do cliente da Biblioteca de Clientes de Armazenamento para investigar o comportamento do aplicativo cliente e ferramentas como Fiddler e Wireshark para investigar sua rede.

Para obter mais informações sobre como usar o Fiddler, consulte Apêndice 1: Usando o Fiddler para capturar o tráfego HTTP e HTTPS.

Para obter mais informações sobre como usar o Wireshark, consulte Apêndice 2: Usando o Wireshark para capturar o tráfego de rede.

Apêndices

Os apêndices descrevem várias ferramentas que você pode achar úteis ao diagnosticar e solucionar problemas com o Armazenamento do Azure (e outros serviços). Essas ferramentas não fazem parte do Armazenamento do Azure e algumas são produtos de terceiros. Como tal, as ferramentas discutidas nesses apêndices não são cobertas por nenhum contrato de suporte que você possa ter com o Microsoft Azure ou o Armazenamento do Azure. Portanto, como parte do processo de avaliação, você deve examinar as opções de licenciamento e suporte disponíveis dos provedores dessas ferramentas.

Apêndice 1: usando Fiddler para capturar o tráfego HTTP e HTTPS

O Fiddler é uma ferramenta útil para analisar o tráfego HTTP e HTTPS entre seu aplicativo cliente e o serviço de armazenamento do Azure que você está usando.

Observação

O Fiddler pode decodificar o tráfego HTTPS. Você deve ler a documentação do Fiddler cuidadosamente para entender como ele faz isso e suas implicações de segurança.

Este apêndice fornece um breve passo a passo de como configurar o Fiddler para capturar o tráfego entre o computador local onde você instalou o Fiddler e os serviços de armazenamento do Azure.

Depois de iniciar o Fiddler, ele começará a capturar o tráfego HTTP e HTTPS em seu computador local. A seguir estão alguns comandos úteis para controlar o Fiddler:

  • Pare e comece a capturar o tráfego. No menu main, vá para Arquivo e selecione Capturar Tráfego para alternar a captura ativada e desativada.
  • Salve os dados de tráfego capturados. No menu main, vá para Arquivo, selecione Salvar e selecione Todas as Sessões. Isso permite salvar o tráfego em um arquivo do Arquivo de Sessão. Você pode recarregar um Arquivo de Sessão posteriormente para análise ou enviá-lo se solicitado para o suporte da Microsoft.

Para limitar a quantidade de tráfego que o Fiddler captura, você pode usar filtros configurados na guia Filtros . A captura de tela a seguir mostra um filtro que captura apenas o tráfego enviado para o ponto de extremidade de contosoemaildist.table.core.windows.net armazenamento:

Captura de tela que mostra um filtro que captura apenas o tráfego enviado para o ponto de extremidade de armazenamento contosoemaildist.table.core.windows.net.

Apêndice 2: usando Wireshark para capturar o tráfego de rede

Wireshark é um analisador de protocolo de rede que permite exibir informações detalhadas do pacote para uma ampla gama de protocolos de rede.

O procedimento a seguir mostra como capturar informações detalhadas do pacote para o tráfego do computador local em que você instalou o Wireshark no serviço de tabela em sua conta de armazenamento do Azure.

  1. Inicie o Wireshark no computador local.

  2. Na seção Iniciar , selecione a interface de rede local ou interfaces conectadas à Internet.

  3. Selecione Opções de Captura.

  4. Adicione um filtro à caixa de texto Filtro de Captura . Por exemplo, host contosoemaildist.table.core.windows.net configurará o Wireshark para capturar apenas pacotes enviados para ou do ponto de extremidade do serviço de tabela na conta de armazenamento contosoemaildist . Confira a lista completa de Filtros de Captura.

    Captura de tela que mostra como adicionar um filtro à caixa de texto Capturar Filtro.

  5. Selecione Iniciar. O Wireshark agora capturará todos os pacotes enviados para ou do ponto de extremidade do serviço de tabela enquanto você usa seu aplicativo cliente em seu computador local.

  6. Quando terminar, selecione Capturar>Parar no menu main.

  7. Para salvar os dados capturados em um arquivo do Wireshark Capture, selecione Salvar arquivos> no menu main.

WireShark destacará todos os erros existentes na janela de lista de pacotes . Você também pode usar a janela Informações de Especialista ( selecione Analisar>Informações de Especialista) para exibir um resumo de erros e avisos.

Captura de tela que mostra a janela Informações de Especialistas em que você pode exibir um resumo de erros e avisos.

Você também pode optar por exibir os dados TCP à medida que a camada do aplicativo os vê clicando com o botão direito do mouse nos dados TCP e selecionando Seguir Stream TCP. Isso será útil se você capturou seu despejo sem um filtro de captura. Para obter mais informações, confira Seguindo fluxos TCP.

Captura de tela que mostra como exibir os dados TCP à medida que a camada do aplicativo os vê.

Observação

Para obter mais informações sobre como usar o Wireshark, consulte o Guia Usuários do Wireshark.

Apêndice 4: usando o Excel para exibir métricas e dados de log

Muitas ferramentas permitem baixar os dados de Métricas de Armazenamento do armazenamento de tabelas do Azure em um formato delimitado que facilita o carregamento dos dados no Excel para exibição e análise. Os dados de registro em log de armazenamento de Armazenamento de Blobs do Azure já estão em um formato delimitado que você pode carregar no Excel. No entanto, você precisará adicionar títulos de coluna apropriados com base nas informações em Análise de Armazenamento Formato de Log e Análise de Armazenamento Esquema de Tabela de Métricas.

Para importar seus dados de registro em log de armazenamento para o Excel depois de baixá-los do armazenamento de blobs:

  • No menu Dados , selecione Em Texto.
  • Navegue até o arquivo de log que você deseja exibir e selecione Importar.
  • Na etapa 1 do Assistente de Importação de Texto, selecione Delimitado.

Na etapa 1 do Assistente de Importação de Texto, selecione Ponto e vírgula como o único delimitador e escolha aspas duplas como o qualificador de texto. Em seguida, selecione Concluir e escolha onde colocar os dados em sua pasta de trabalho.

Apêndice 5: Monitoramento com o Application Insights para Azure DevOps

Você também pode usar o recurso Application Insights para o Azure DevOps como parte do monitoramento de desempenho e disponibilidade. Essa ferramenta pode:

  • Verifique se seu serviço Web está disponível e responsivo. Se seu aplicativo é um site ou um aplicativo de dispositivo que usa um serviço Web, ele pode testar sua URL a cada poucos minutos de locais em todo o mundo e informar se há um problema.
  • Diagnostice rapidamente quaisquer problemas de desempenho ou exceções em seu serviço Web. Descubra se a CPU ou outros recursos estão sendo estendidos, obtenha rastreamentos de pilha de exceções e pesquise facilmente por meio de rastreamentos de log. Se o desempenho do aplicativo cair abaixo dos limites aceitáveis, a Microsoft poderá enviar um email. Você pode monitorar os serviços Web .NET e Java.

Você pode encontrar mais informações no What is Application Insights.

Próximas etapas

Para obter mais informações sobre análise no Armazenamento do Azure, confira estes recursos:

Aviso de isenção de responsabilidade para informações de terceiros

Os produtos de terceiros mencionados neste artigo são produzidos por empresas independentes da Microsoft. A Microsoft não oferece nenhuma garantia, implícita ou não, do desempenho ou da confiabilidade desses produtos.

Entre em contato conosco para obter ajuda

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.