Monitoramento, diagnóstico e solução de problemas de Armazenamento do Microsoft Azure (clássico)
Este guia mostra como usar recursos como Análise de Armazenamento do Azure, log do lado do cliente na Biblioteca de Clientes do Armazenamento do Azure e outras ferramentas de terceiros para identificar, diagnosticar e solucionar problemas relacionados ao Armazenamento do Azure.
Esse guia deve ser lido primeiramente pelos desenvolvedores de serviços online que usam os Serviços Armazenamento do Azure e profissionais de TI para gerenciar esses serviços online. Os objetivos desse guia são:
- Ajudar a manter a integridade e o desempenho de suas contas de Armazenamento do Azure.
- Oferecer os processos e as ferramentas necessários para ajudá-lo a decidir se um problema em um aplicativo está ou não relacionado ao Armazenamento do Microsoft Azure.
- Oferecer diretrizes de ações para resolver problemas relacionados ao armazenamento do Azure.
Observação
Este artigo se baseia no uso de métricas e logs da Análise de Armazenamento conhecidos como métricas e logs clássicos. Recomendamos o uso de logs e métricas do Armazenamento do Azure no Azure Monitor, em vez dos logs da Análise de Armazenamento. Para saber mais, consulte um dos seguintes artigos:
Visão geral
Questões de diagnóstico e de solução de problemas em um aplicativo distribuído hospedado em um ambiente de nuvem podem ser mais complexas que em ambientes tradicionais. Aplicativos podem ser implantados em uma infraestrutura PaaS ou IaaS, local, em um dispositivo móvel ou em alguma combinação desses ambientes. Normalmente, o tráfego de rede do aplicativo pode atravessar redes públicas e privadas, e seu aplicativo pode usar várias tecnologias de armazenamento, como Tabelas de Armazenamento do Microsoft Azure, Blobs, Filas ou Arquivos, além de outros armazenamentos de dados, como bancos de dados relacionais e de documentos.
Para gerenciar esses aplicativos com sucesso, você deve monitorá-los proativamente e entender como diagnosticar e solucionar problemas de todos os aspectos deles e de 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 normal) e usar o log para coletar dados mais detalhados e analisar um problema em profundidade. As informações de diagnóstico obtidas do monitoramento e do registro em log ajudarão você a determinar a causa raiz do problema encontrado pelo aplicativo. Você poderá solucionar o problema e determinar as etapas apropriadas para corrigi-lo. O Armazenamento do Azure é um serviço principal do Azure e constitui uma parte importante da maioria das soluções que os clientes implantam na infraestrutura do Azure. O Armazenamento do Azure inclui capacidades de simplificar questões de monitoramento, diagnóstico e de soluções de problemas de armazenamento em seus aplicativos em nuvem.
Como esse guia está organizado
A seção Monitorando o serviço de armazenamento descreve como monitorar a integridade e o desempenho dos serviços de Armazenamento do Azure usando as Métricas de Análise de Armazenamento do Azure (Métricas de Armazenamento).
A seção Diagnosticando problemas de armazenamento descreve como diagnosticar problemas usando o Log da Análise de Armazenamento do Azure (Log de Armazenamento). Ele também descreve como habilitar o log do lado do cliente usando os recursos em uma das bibliotecas de cliente, como a Biblioteca de Cliente 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 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 pacotes de rede e Fiddler para analisar mensagens HTTP/HTTPS.
Monitoramento do seu serviço de armazenamento
Se você está acostumado com o monitoramento de desempenho do Windows, é possível entender as Métricas de Armazenamento como equivalentes aos contadores do Monitor de Desempenho do Windows. Em Métricas de Armazenamento, você encontrará um conjunto abrangente de métricas (contadores na terminologia do Monitor de Desempenho do Windows), como disponibilidade do serviço, o número total de solicitações de serviço ou a porcentagem de solicitações de serviço bem-sucedidas. Para obter uma lista completa das métricas disponíveis, confira Esquema da tabela de métricas da análise do armazenamento. Você pode especificar se deseja que o serviço de armazenamento colete e agregue as métricas a cada hora e ou cada minuto. Para mais informações sobre como habilitar as métricas e monitorar suas contas de armazenamento, confira Habilitação das métricas de armazenamento e exibição dos dados de métrica.
Você pode escolher quais intervalos de hora das métricas que você quer exibir no Portal do Azure e configurar as regras de notificação dos administradores por email caso a métrica a cada hora ultrapasse um valor particular. Para obter mais informações, confira Receber notificações de alerta.
Recomendamos que você examine o Azure Monitor for Storage (versão prévia). Trata-se de um recurso do Azure Monitor que oferece monitoramento abrangente das contas do Armazenamento do Microsoft Azure, fornecendo uma exibição unificada de desempenho, capacidade e disponibilidade dos serviços de Armazenamento do Azure. Ele não exige nenhuma habilitação ou configuração e você pode exibir imediatamente essas métricas nos gráficos interativos predefinidos e em 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 as métricas de disponibilidade, total de solicitações e números das médias de latência para uma conta de armazenamento. Uma regra de notificação também foi configurada para alertar um administrador caso uma disponibilidade caia abaixo de um certo nível. A partir da exibição desses dados, uma área possível para investigação é a porcentagem de sucesso do serviço de tabela abaixo de 100% (para obter mais informações, consulte a seção Métricas mostram baixo PercentSuccess ou entradas de log de análise têm operações com status de transação de ClientOtherErrors ).
Monitore continuamente seus aplicativos do Azure para garantir que sua integridade e desempenho estejam como esperados ao:
- Estabelecer algumas métricas de linha de base para o aplicativo que permitirão comparar os dados atuais e identificar alterações significativas no comportamento do armazenamento do Azure e do aplicativo. Os valores de suas métricas de linha de base serão, em muitos casos, específicos do aplicativo, e você deve estabelecê-los ao testar o desempenho do aplicativo.
- Registrar métricas de minuto e usá-las para monitorar ativamente erros e anomalias inesperadas, como picos na contagem de erros ou taxas de solicitação.
- Registrar métricas a cada hora e usá-las para monitorar os valores médios como: médias de contagem de erros ou taxas de solicitação.
- Investigando possíveis problemas usando ferramentas de diagnóstico, conforme discutido posteriormente na seção Diagnosticando problemas de armazenamento.
Os gráficos na imagem a seguir ilustram como a média que acontece nas métricas de hora em hora podem esconder picos em atividade. As métricas de hora em hora parecem mostrar uma taxa constante de solicitações, enquanto as métricas de minuto em minuto revelam as flutuações que estão realmente acontecendo.
O restante desta seção descreve quais as métricas que você deve monitorar e o porquê.
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 no mundo. O monitoramento permite que você veja imediatamente se um problema fora do seu controle está afetando o serviço de armazenamento na região que você usa para seu aplicativo.
O Portal do Azure pode também fornecer notificações de incidentes que afetam os diversos serviços do Azure.
Observação
essa informação estava disponível anteriormente, juntamente com os dados históricos, no Painel de Serviços do Azure. Para obter mais informações sobre o Application Insights para Azure DevOps, consulte o Apêndice 5: Monitoramento com o Application Insights para Azure DevOps.
Monitoramento de capacidade
As métricas de armazenamento apenas armazena as métricas de capacidade do serviço blob porque os blobs normalmente são responsáveis pela maior proporção dos dados armazenados (no momento em que se escreve, não é possível usar as métricas de armazenamento para monitorar a capacidade de suas tabelas e filas). Você pode encontrar esses dados na tabela se tiver habilitado o $MetricsCapacityBlob monitoramento para o serviço Blob. As Métricas de Armazenamento registram esses dados uma vez por dia, e você pode usar o RowKey valor do para determinar se a linha contém uma entidade relacionada aos dados do 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 Esquema de tabela de métricas de Análise de Armazenamento.
Observação
Monitore esses valores por meio de um aviso antecipado de que você está se aproximando dos limites de capacidade de sua conta de armazenamento. No portal do Azure, você pode adicionar regras de alerta para notificá-lo se o uso do armazenamento agregado exceder ou ficar abaixo dos limites especificados.
Para estimar o tamanho de vários objetos de armazenamento, como blobs, consulte a postagem no blog Noções básicas sobre cobrança de armazenamento do Azure – largura de banda, transações e capacidade.
Monitoramento da disponibilidade
Você deve monitorar a disponibilidade dos serviços de armazenamento em sua conta de armazenamento monitorando o Availability valor na coluna nas tabelas de métricas por hora ou minuto — $MetricsHourPrimaryTransactionsBlob, $MetricsHourPrimaryTransactionsTable, $MetricsHourPrimaryTransactionsQueue, $MetricsMinutePrimaryTransactionsBlob, , $MetricsMinutePrimaryTransactionsTable, , $MetricsMinutePrimaryTransactionsQueue, $MetricsCapacityBlob. A Availability coluna contém um valor percentual que indica a disponibilidade do serviço ou da operação de API representada pela linha (mostra RowKey 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 houve falha em algumas solicitações de armazenamento. Você pode ver por que eles estão falhando examinando as outras colunas nos dados de métricas que mostram o número de solicitações com diferentes tipos de erro, como ServerTimeoutError. Você deve esperar uma Availability queda temporária abaixo de 100% por motivos como tempos limite transitórios do servidor enquanto o serviço move partições para solicitações de melhor balanceamento de carga; a lógica de repetição em seu aplicativo cliente deve lidar com essas condições intermitentes. O artigo Operações Registradas e Mensagens de Status da Análise de Armazenamento 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 ficar abaixo de um limite especificado.
A seção Diretrizes de solução de problemas deste guia descreve alguns problemas comuns do serviço de armazenamento relacionados à disponibilidade.
Monitoramento de desempenho
Para monitorar o desempenho dos serviços de armazenamento, você pode usar as seguintes métricas das tabelas de hora em hora ou minuto em minuto.
- Os valores nas
AverageE2ELatencycolunas eAverageServerLatencymostram 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 a latência de rede quando a solicitação chega ao 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 mostram alta AverageE2ELatency e baixa AverageServerLatency mais adiante neste guia para obter uma discussão sobre por que pode haver uma diferença significativa entre esses dois valores. - Os valores nas
TotalIngresscolunas eTotalEgressmostram 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
TotalRequestscoluna 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 alguma métrica de desempenho para esse serviço ficar abaixo ou exceder um limite especificado.
A seção Diretrizes de solução de problemas deste guia descreve alguns problemas comuns do serviço de armazenamento relacionados ao desempenho.
Diagnóstico de problemas de armazenamento
Há inúmeros caminhos que você pode ter para ficar ciente de um problema em seu aplicativo, incluindo:
- Uma falha grave 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.
- Relatórios de usuários do seu aplicativo informando que uma operação em particular não foi concluída como esperado ou que algum recurso não está funcionando.
- Erros gerados dentro do seu aplicativo que aparecem nos arquivos de log ou em outros métodos de notificação.
Normalmente, problemas relacionados aos serviços de armazenamento do Azure estão entre uma das quatro grandes categorias:
- 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 o teste, você pode estar usando o emulador de armazenamento local; Você pode encontrar alguns problemas relacionados especificamente ao uso do emulador de armazenamento.
As seguintes seções apresentam as etapas que você deve seguir para diagnosticar e solucionar os problemas em cada uma dessas quatro categorias. A seção Diretrizes de solução de problemas mais adiante neste guia fornece mais detalhes sobre alguns problemas comuns que você pode encontrar.
Problemas de integridade do serviço
Problemas de integridade do serviço são normalmente fora do seu controle. O portal do Azure fornece informações sobre quaisquer problemas contínuos com os serviços do Azure, incluindo serviços de armazenamento. Se você tiver optado pelo Armazenamento com Redundância Geográfica com Acesso de Leitura quando criou sua conta de armazenamento, então, no caso de seus dados estarem indisponíveis no local principal, o aplicativo pode mudar temporariamente para cópia somente leitura em um local secundário. Para ler do 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 reduzida com dados somente leitura. As bibliotecas do cliente de armazenamento do Azure permitem que você defina uma política de tentativa que pode ler a partir do armazenamento secundário caso a leitura do armazenamento principal falhar. Seu aplicativo também precisa estar ciente que os dados do local secundário são consistentes. Para saber mais, consulte no blog a postagem Opções de redundância do Armazenamento do Azure e armazenamento com redundância geográfica do acesso de leitura.
Problemas de desempenho
O desempenho de um aplicativo pode ser subjetivo, especialmente da perspectiva de um usuário. Por isso, é 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 da perspectiva do aplicativo do cliente. Esses fatores podem operar no serviço de armazenamento, no cliente ou na infra-estrutura de rede; portanto, é importante ter uma estratégia para identificar a origem do problema de desempenho.
Após ter identificado o possível local da causa do problema de desempenho a partir das métricas, você pode usar os arquivos de log para encontrar as informações detalhadas para diagnosticar e solucionar o problema mais profundamente.
A seção Diretrizes de solução de problemas mais adiante neste guia fornece mais informações sobre alguns problemas comuns relacionados ao desempenho que você pode encontrar.
Diagnóstico de erros
Usuários do seu aplicativo podem notificá-lo de erros registrados pelo aplicativo do 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. Enquanto as métricas de armazenamento apenas registram as contagens de diferentes tipos de erros, você obter mais detalhes sobre solicitações individuais ao examinar os logs do servidor, do cliente e da rede. Normalmente, o código de status HTTP que voltam para o serviço de armazenamento darão uma indicação da razão da falha da solicitação.
Observação
Lembre-se de que você deve esperar ver alguns erros intermitentes: por exemplo, erros devido a condições de rede transitórias ou erros de aplicativo.
Os seguintes recursos são úteis para compreender os status relacionados a armazenamento e os códigos de erro:
- Códigos de erro comuns da API REST
- Códigos de erro do Serviço Blob
- Códigos de erro do Serviço de Fila
- Códigos de erro do Serviço Tabela
- Códigos de erro do serviço de arquivo
Problemas de 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 o teste, permitindo que você execute aplicativos que usam os serviços de armazenamento do Azure sem a necessidade de uma assinatura do Azure e uma conta de armazenamento do Azure.
A seção Diretrizes de solução de problemas deste guia descreve alguns problemas comuns encontrados ao usar o emulador de armazenamento.
Ferramentas de log de armazenamento
O log de armazenamento oferece o log do lado do servidor para solicitações de armazenamento na sua conta de armazenamento do Azure. Para saber mais sobre como habilitar o log do lado do servidor e acessar os dados de log, consulte Enabling Storage Logging and Accessing Log Data(Como habilitar o registro em log do armazenamento e o acesso aos dados do log).
A biblioteca do cliente de armazenamento para .NET habilita você a coletar dados de log do cliente relacionados as operações de armazenamento realizadas pelo seu aplicativo. Para saber mais, consulte Registro em log no lado do cliente com a biblioteca do cliente de armazenamento para .NET.
Observação
Em algumas circunstâncias (tais como falhas de autorizações SAS) um usuário pode informar um erro pelo qual você não pode encontrar nenhum dado de solicitação nos logs de armazenamento do lado do cliente. Você pode usar as capacidades de log da biblioteca do cliente de armazenamento para investigar se a causa desse problema está no cliente ou use as as ferramentas de monitoramento de rede para investigar a rede.
Uso de ferramentas de log de rede
Você pode capturar o tráfego entre o cliente e o servidor para dar informações detalhadas sobre os dados que o cliente e o servidor estão trocando e as condições subjacentes de rede. Ferramentas úteis de log de rede incluem:
- Fiddler é um proxy de depuração Web gratuito que permite que você examine os cabeçalhos e dados de conteúdo das solicitações HTTP e HTTPS e as mensagens de resposta. Para obter mais informações, veja o Apêndice 1: Usando o Fiddler para capturar o tráfego HTTP e HTTPS.
- Monitor de Rede da Microsoft (Netmon) e Wireshark são analisadores de protocolo de rede gratuitos que permitem que você exiba informações detalhadas de pacote de uma vasta gama de protocolos de rede. Para obter mais informações sobre o Wireshark, consulte o Apêndice 2: Usando o Wireshark para capturar o tráfego de rede.
- Se você quer realizar um teste de conectividade básico para verificar que a máquina do cliente pode se conectar ao serviço de armazenamento do Azure pela rede, você não pode fazer isso usando a ferramenta padrão ping no cliente. Entretanto, você pode usar a ferramenta tcping para verificar a conectividade.
Em muitos casos, os dados de log a partir do log de armazenamento e da biblioteca do cliente serão suficientes para diagnosticar um problema, porém, em alguns cenários, você poderá precisar de informações mais detalhadas que podem ser providas por essas ferramentas de log de rede. Por exemplo, usando o Fiddler para ver as mensagens HTTP e HTTPS permitem que você exiba o cabeçalho e os dados de carga enviados para e a partir dos serviços de armazenamento, o qual permite que você examine como o aplicativo do cliente repete as operações de armazenamento. Analisadores de protocolo, tais como Wireshark opera em nível de pacote permitindo que você exiba os dados TCP, os quais permitem que você solucione 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 a investigação de potenciais problemas. Você pode usar as informações de data/hora dos seus dados de métricas para indicar por onde começar a procurar nos arquivos de log informações detalhadas para ajudá-lo a solucionar o problema.
Correlacionamento de dados de log
Ao exibir logs de aplicativos cliente, rastreamentos de rede e log de armazenamento do lado do servidor, é fundamental ser capaz de correlacionar solicitações entre os diferentes arquivos de log. Os arquivos de log incluem inúmeros campos diferentes que são úteis como identificadores de correlação. A ID de solicitação do cliente é o campo mais útil para usa para correlacionar entradas em logs diferentes. No entanto, às vezes, pode ser útil usar o ID de solicitação do servidor ou carimbos de data/hora. As seções a seguir fornecem mais detalhes sobre essas opções.
ID de solicitação do cliente
A Biblioteca de Clientes de Armazenamento gera automaticamente uma ID de solicitação do cliente exclusiva para cada solicitação.
- No log do lado do cliente criado pela Biblioteca de Cliente de Armazenamento, a ID da solicitação do cliente aparece no
Client Request IDcampo de cada entrada de log relacionada à solicitação. - Em um rastreamento de rede, como um capturado pelo Fiddler, a ID de solicitação do cliente é visível em mensagens de solicitação como o valor do
x-ms-client-request-idcabeçalho HTTP. - No log de armazenamento do lado do servidor, a ID de solicitação do cliente aparece 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). No caso de novas tentativas do cliente, todas as tentativas compartilham a mesma ID de solicitação do cliente. No caso de um lote enviado pelo cliente, o lote tem uma única ID de solicitação de cliente.
ID de solicitação do servidor
O serviço de armazenamento gera automaticamente IDs de solicitação do servidor.
- No log de Log de Armazenamento do lado do servidor, a ID da solicitação do servidor aparece na
Request ID headercoluna. - Em um rastreamento de rede, como um capturado pelo Fiddler, a ID de solicitação do servidor aparece nas mensagens de resposta como o valor do
x-ms-request-idcabeçalho HTTP. - No log do lado do cliente criado pela Biblioteca de Cliente de Armazenamento, a ID de solicitação do servidor aparece na
Operation Textcoluna da entrada de log que mostra detalhes da resposta do servidor.
Observação
O serviço de armazenamento sempre atribui uma única ID de solicitação de servidor para cada solicitação recebida, de modo que cada tentativa do cliente e cada operação incluída no lote tenha uma ID de solicitação do 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();
}
}
Carimbos de data/hora
Você também pode usar o carimbo de data/hora para localizar as entradas de log relacionadas, porém cuidado com qualquer distorção que possa existir entre o relógio do cliente e do servidor. Pesquise por mais ou menos 15 minutos para coincidir as entradas do lado do servidor com base no carimbo de data/hora do cliente. Lembre-se que os metadados de blob para os blobs contendo 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.
Diretriz de solução de problemas
Essa seção irá ajudá-lo com o diagnóstico e com a solução de alguns dos problemas mais 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 o seu problema específico.
Solucionando problemas de árvore de decisão
O seu problema está relacionado ao desempenho de um dos serviços de armazenamento?
- As métricas mostram alta AverageE2ELatency e baixa AverageServerLatency.
- As métricas mostram baixa AverageE2ELatency e baixa AverageServerLatency, mas o cliente está experimentando alta latência.
- As métricas mostram alta AverageServerLatency.
- Você está enfrentando atrasos inesperados na entrega de mensagens em uma fila.
O seu problema está relacionado à disponibilidade de um dos serviços de armazenamento?
- As métricas mostram um aumento em PercentThrottlingError.
- As métricas mostram um aumento em PercentTimeoutError.
- As métricas mostram um aumento em PercentNetworkError.
O seu aplicativo do cliente está recebendo uma resposta HTTP 4XX (tal como 404) de um serviço de armazenamento?
- O cliente está recebendo mensagens HTTP 403 (Proibido).
- O cliente está recebendo mensagens HTTP 404 (Não encontrado).
- O cliente está recebendo mensagens HTTP 409 (Conflito).
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 ao instalar o SDK do Azure para .NET.
Você tem um problema diferente com um serviço de armazenamento.
As métricas mostram alta AverageE2ELatency e baixa AverageServerLatency
A figura abaixo da ferramenta de monitoramento do portal do Azure mostra um exemplo em que a AverageE2ELatency é significantemente mais alta que a AverageServerLatency.
O serviço de armazenamento calcula apenas a métrica AverageE2ELatency para solicitações de êxito e, ao contrário de AverageServerLatency, inclui o tempo que o cliente leva para enviar os dados e receber a confirmação do serviço de armazenamento. Portanto, uma diferença entre AverageE2ELatency e AverageServerLatency pode ser devido ao aplicativo cliente ser lento para responder ou devido a condições na rede.
Observação
Você também pode exibir E2ELatency e ServerLatency das operações de armazenamento individual nos dados de registro do log de Armazenamento.
Investigação dos 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 estar com poucos recursos, como CPU, memória ou largura de banda de rede. Você pode resolver 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 AverageE2ELatency em comparação com AverageServerLatency. Para obter mais informações, consulte O algoritmo de Nagle não é amigável para solicitações pequenas. Você pode desabilitar o algoritmo Nagle no código usando a ServicePointManager System.Net classe no namespace. Faça isso antes de fazer qualquer chamada para os serviços de tabela ou fila no seu aplicativo já que 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 verificar os logs do lado do cliente para ver quantas solicitações seu aplicativo cliente está enviando e verificar se há dados gerais . NET em seu cliente, como CPU, coleta de lixo do .NET, utilização de rede ou memória. Como ponto de partida para solucionar problemas de aplicativos do cliente .NET, confira Depuração, rastreamento e criação de perfil.
Investigando os problemas de latência de rede
Normalmente a alta 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 o Apêndice 2: Usando o Wireshark para capturar o tráfego de rede.
As métricas mostram baixa AverageE2ELatency e baixa AverageServerLatency, mas o cliente está recebendo uma latência alta
Nesse cenário, o caso mais provável é um atraso nas solicitações de armazenamento chegando no serviço de armazenamento. Investigue porque as solicitações do cliente não estão passando pelo serviço de blob.
Uma das possíveis razões para o atraso do cliente em enviar solicitações é que há um número limitado de conexões ou threads disponíveis.
Além disso, verifique se o cliente está executando várias tentativas e investigue o motivo, se estiver. Para determinar se o cliente está realizando várias tentativas, é possível:
- Examine os logs da Análise de Armazenamento. Se estiverem ocorrendo várias repetições, 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 log detalhado indica que ocorreu uma repetição.
- Depure seu código e verifique as propriedades do
OperationContextobjeto associado à solicitação. Se a operação tiver sido repetida, aRequestResultspropriedade incluirá várias IDs de solicitação de servidor exclusivas. Você também pode verificar as horas de início e término de cada solicitação. Para obter mais informações, veja o exemplo de código na seção ID de solicitação do servidor.
Se não houver problemas no cliente, investigue os possíveis problemas de rede, tais como perda de pacote. 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 o Apêndice 2: Usando o Wireshark para capturar o tráfego de rede.
As métricas mostram alta AverageServerLatency
No caso de alta AverageServerLatency para as 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 para grupos de blobs). Para solicitações de upload 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 estão carregando blocos para o mesmo blob em paralelo. Você também deve verificar 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 As métricas mostram um aumento em PercentTimeoutError.
Se você vir alta AverageServerLatency para solicitações de download de blob quando houver solicitações repetidas para o mesmo blob ou conjunto de blobs, considere armazenar esses blobs em cache usando o Cache do Azure ou a CDN (Rede de Distribuição de Conteúdo) do Azure. Para solicitações de carregamento, você pode aprimorar a produtividade usando um tamanho maior de bloco. Para consultas às tabelas, também é possível implementar o cache no lado do cliente nos clientes que realizam as mesmas operações de consulta e nos casos em que os dados não mudam com frequência.
Valores altos de AverageServerLatency podem também ser um sintoma de tabelas ou consultas mal desenhadas que resultam em operações de digitalização ou que seguem a anti-sequência acrescentar/preceder. Para obter mais informações, consulte As métricas mostram um aumento em PercentThrottlingError.
Observação
Você pode encontrar uma lista de verificação de desempenho abrangente aqui: Lista de verificação de desempenho e escalabilidade do armazenamento do Microsoft Azure.
Você está sofrendo atrasos inesperados na entrega de mensagens na fila
Se você estiver enfrentando um atraso entre o momento em que um aplicativo adiciona uma mensagem a uma fila e o momento em que ela fica disponível para leitura da fila, execute as seguintes etapas para diagnosticar o problema:
- Verifique se o aplicativo está adicionando com êxito as mensagens à fila. Verifique se o aplicativo não está repetindo o
AddMessagemétodo várias vezes antes de ter êxito. Os logs da biblioteca do cliente de armazenamento irá mostrar qualquer tentativa repetida 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 a função de trabalho que lê a mensagem da fila. Uma inclinação de relógio faz parecer que há um atraso no processamento.
- A função de trabalho lê as mensagens da fila que tem falhas. Se um cliente de fila chamar o
GetMessagemétodo, mas não responder com uma confirmação, a mensagem permanecerá invisível na fila até que oinvisibilityTimeoutperíodo expire. Nesse momento, a mensagem se torna disponibilidade para ser processada novamente. - Verifique se o tamanho da fila está aumentando com o 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, verifique as métricas para ver se as solicitações de exclusão estão falhando e a contagem de remoção da fila nas mensagens, o que pode indicar tentativas repetidas com falha de excluir a mensagem.
- Examine os logs de log de armazenamento para qualquer operação de fila que possa estar mais alta do que a E2ELatency esperada e dos valor ServerLatency durante um período mais longo de tempo do que de costume.
As métricas mostram um aumento em PercentThrottlingError
Erros de limitação acontecem quando você excede os alvos de escalabilidade de um serviço de armazenamento. O serviço de armazenamento aplica limitações para garantir que nenhum cliente ou locatário possa usar o serviço à custa de outros. Para saber mais, consulte Metas de desempenho e de escalabilidade para contas de armazenamento padrão para obter detalhes sobre alvos de escalabilidade para contas de armazenamento e alvos de desempenho para partições dentro de contas de armazenamento.
Se a métrica PercentThrottlingError mostrar um aumento na porcentagem de solicitações que estão falhando com um erro de limitação, você precisará investigar um dos dois cenários:
Um aumento em PercentThrottlingError geralmente ocorre ao mesmo tempo que um aumento no número de solicitações de armazenamento ou quando você está testando inicialmente a carga de seu aplicativo. Isso pode também manifestar no cliente como mensagens de status HTTP "503 Server Busy" ou "500 Operation Timeout" a partir das 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, poderá implementar uma estratégia de retirada exponencial (não linear) para novas tentativas em seu cliente. As novas tentativas de retirada reduzem a carga imediata na partição e ajudam seu aplicativo a suavizar picos de tráfego. Para saber mais sobre como implementar políticas de repetição usando a Biblioteca do Cliente de Armazenamento, veja 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 em PercentThrottlingError
Se você estiver vendo um valor consistentemente alto para PercentThrottlingError após um aumento permanente em seus volumes de transações ou quando estiver executando seus testes de carga iniciais em seu aplicativo, precisará avaliar como seu aplicativo está usando partições de armazenamento e se ele está se aproximando das metas 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 distribuir as transações em várias partições. Se você está vendo erros de limitação em uma tabela, você precisa considerar usar um esquema de partições diferentes para espalhar suas transações entre as diversas partições usando uma gama maior de valores chave de partição. Uma causa comum desse problema é o antipadrão de prepend/append 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 um armazenamento de blob pode ser uma solução melhor. Além disso, verifique se a limitação está ocorrendo como resultado de picos no tráfego e investigue maneiras de suavizar seu padrão de solicitações.
Se você distribuir suas transações entre diversas partições, você ainda deve levar em consideração os 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 de 1 KB 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 o uso de várias contas de armazenamento. Você também deve ter em mente que o tamanho de suas solicitações e entidades tem um impacto sobre quando o serviço de armazenamento limita seus clientes. Se você tiver solicitações e entidades maiores, poderá ser limitado mais cedo.
Designs de consultas ineficientes podem causar também que você atinja os limites de escalabilidade para as 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 digitaliza todas as entidades em uma partição precisará ter acesso a cada entidade. Toda entidade lida irá contar para um número total de transações naquela partição, portanto, você pode facilmente atingir os alvos de escalabilidade.
Observação
Seu teste de desempenho deve revelar qualquer design de consulta ineficiente em sua partição.
As métricas mostram um aumento em PercentTimeoutError
Suas métricas mostram um aumento em PercentTimeoutError para um dos seus serviços de armazenamento. Ao mesmo tempo, o cliente recebe um volume alto de mensagens de status HTTP "500 Operation Timeout" a partir das operações de armazenamento.
Observação
Você pode ver temporariamente erros de tempo limite enquanto o serviço de armazenamento balanceia a carga de solicitações movendo um 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 limites do servidor são causados por um erro no servidor. Os tempos limite do cliente ocorrem porque uma operação no servidor excedeu o tempo limite especificado pelo cliente; por exemplo, um cliente que usa a Biblioteca de Cliente de Armazenamento pode definir um tempo limite para uma operação usando a ServerTimeout propriedade da QueueRequestOptions classe.
Os tempos limites indicam um problema com o serviço de armazenamento que requer uma investigação detalhada. Você pode usar as métricas para ver se está atingindo os limites de escalabilidade do servidor e para identificar quaisquer picos de tráfego que pode 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 por atingir os limites de escalabilidade do serviço, acione um problema de suporte. Para tempos 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 de suas mensagens.
As métricas mostram um aumento em PercentNetworkError
Suas métricas mostram um aumento em PercentNetworkError para um dos seus serviços de armazenamento. A métrica PercentNetworkError é uma agregação das seguintes métricas: NetworkError, AnonymousNetworkError e SASNetworkError. Eles ocorrem 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 é um cliente desconectando antes do tempo limite expirar no serviço de armazenamento. Investigue o código no cliente para entender porque e quando o cliente desconecta do serviço de armazenamento. Você também pode usar o Wireshark ou o Tcping para investigar problemas de conectividade de rede do cliente. Essas ferramentas estão descritas nos Anexos.
O cliente está recebendo mensagens HTTP 403 (Proibido)
Se o seu aplicativo do cliente está emitindo erros HTTP 403 (Proibido), uma possível causa é que o cliente esteja usando uma assinatura de acesso compartilhado (SAS) expirada quando envia uma solicitação de armazenamento (embora outras causas possíveis incluem 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 do Log de Armazenamento do lado do servidor. A tabela a seguir mostra um exemplo de log do lado do cliente gerado pela biblioteca do cliente de armazenamento que ilustra esse problema acontecendo:
| Fonte | Detalhamento | Detalhamento | ID de solicitação do cliente | Texto de 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 porque o token de SAS está expirando antes do cliente enviar o token para o servidor:
- Normalmente, você não deve definir uma hora de início ao criar uma SAS para um cliente usar imediatamente. Se houver pequenas diferenças de relógio entre o host que gera a SAS usando a hora atual e o serviço de armazenamento, será possível que o serviço de armazenamento receba uma SAS que ainda não seja válida.
- Não defina um tempo de expiração muito curto em uma SAS. Novamente, pequenas diferenças de clock entre o host que gera a SAS e o serviço de armazenamento podem fazer com que uma SAS aparentemente expire mais cedo do que o previsto.
- O parâmetro version na chave SAS (por exemplo,
sv=2015-04-05) corresponde à versão da Biblioteca de Cliente de Armazenamento que você está usando? Recomendamos usar sempre a versão mais recente da Biblioteca de Cliente de Armazenamento. - Se você regenerar suas chaves de acesso de armazenamento, isso poderá invalidar quaisquer tokens de SAS existentes. Esse problema poderá surgir se você gerar tokens de SAS com um tempo de expiração longo para aplicativos de cliente para o cache.
Se você estiver usando a biblioteca do cliente de armazenamento para gerar tokens de SAS, então será fácil compilar um token válido. Entretanto, se você estiver usando a API REST de Armazenamento e criando tokens de SAS manualmente, consulte Delegando acesso com uma Assinatura de Acesso Compartilhado.
O cliente está recebendo mensagens HTTP 404 (Não encontrado)
Se o aplicativo cliente recebe uma mensagem HTTP 404 (Não encontrado) do servidor, isso implica que o objeto do cliente estava tentando usar (tais como: uma entidade, tabela, blob, contêiner ou fila) não existe no serviço de armazenamento. Existem muitas razões para isso, tais como:
- O cliente ou outro processo excluiu anteriormente o objeto.
- Um problema de autorização SAS (Assinatura de Acesso Compartilhado).
- O código JavaScript do lado do cliente não tem permissão para acessar o objeto.
- Falha de rede.
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. Frequentemente, os dados de log mostram que um outro usuário ou processo excluiu o objeto. No registro de log de armazenamento no lado do servidor, as colunas do tipo de operação e de chave de objeto solicitado mostram quando um cliente excluiu um objeto.
No cenário em que um cliente está tentando inserir um objeto, pode não ser imediatamente óbvio por que isso resulta em uma resposta HTTP 404 (Não encontrado), já 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 localizar 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 a partir da biblioteca do cliente 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 seguinte log do lado do cliente gerado pela biblioteca do cliente de armazenamento ilustra o problema quando o cliente não pode encontrar o contêiner para o blob que está criando. Esse log inclui detalhes das seguintes operações de armazenamento:
| ID de solicitação | Operação |
|---|---|
| 07b26a5d-... | DeleteIfExists para excluir o contêiner de blob. Observe que essa operação inclui uma HEAD solicitação para verificar a existência do contêiner. |
| e2d06d78… | CreateIfNotExists para criar o contêiner de blob. Observe que essa operação inclui uma HEAD solicitação que verifica a existência do contêiner. O retorna HEAD uma mensagem 404, mas continua. |
| de8b1c3c-... | UploadFromStream para criar o blob. A PUT solicitação falha com uma mensagem 404. |
Entradas de log:
| ID de solicitação | Texto de 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 = "0x8D14D2DC63D059B". |
| 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 método (ID de CreateIfNotExists solicitação e2d06d78...) com as UploadFromStream solicitações do método (de8b1c3c-...). Essa intercalação ocorre 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 para o blob nesse contêiner. Idealmente, crie todos os contêineres antes.
Um problema de autorização de assinatura de acesso compartilhado (SAS)
Se o aplicativo cliente tentar usar uma chave de SAS que não inclui as permissões necessárias para a operação, o serviço de armazenamento retorna uma mensagem HTTP 404 (Não encontrado) para o cliente. Ao mesmo tempo, você também verá um valor diferente de zero para SASAuthorizationError nas métricas.
A tabela a seguir mostra um exemplo de mensagem d log do lado do servidor a partir do arquivo de registro de log de armazenamento:
| Nome | Valor |
|---|---|
| Hora de início da solicitação | 2014-05-30T06:17:48.4473697Z |
| Tipo de operação | GetBlobProperties |
| Status da solicitação | SASAuthorizationError |
| Código de status 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&; versão api = 2014-02-14 | |
| Cabeçalho da ID de solicitação | <Cabeçalho da ID da solicitação> |
| ID de solicitação do cliente | <ID de solicitação do cliente> |
Investigue por que seu aplicativo cliente está tentando executar uma operação para a qual não recebeu 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 um serviço de armazenamento está retornando mensagens HTTP 404 (Não encontrado), verifique 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, acesso negado.
Observação
Você pode usar as Ferramentas para Desenvolvedores F12 no Internet Explorer para rastrear as mensagens trocadas entre o navegador e o serviço de armazenamento quando você estiver solucionando os problemas JavaScript do lado do cliente.
Esses erros acontecem porque o navegador da Web implementa a restrição de segurança de política de mesma origem , que impede uma página da Web de chamar uma API em um domínio diferente do domínio de onde a página vem.
Para contornar o problema do JavaScript, você pode configurar o CORS (Cross-Origin Resource Sharing) para o serviço de armazenamento que o cliente está acessando. Para saber mais, veja Suporte de CORS (Compartilhamento de Recursos entre Origens) para os Serviços de Armazenamento do Azure.
O código a seguir mostra como configurar seu serviço blob para permitir que o JavaScript execute o domínio Contoso para acessar um blob no seu serviço de armazenamento de blob:
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 de rede
Em algumas circunstâncias, os pacotes de rede perdidos podem levar o serviço de armazenamento a retornar mensagens HTTP 404 para o cliente. Por exemplo, quando seu aplicativo cliente está excluindo uma entidade do serviço de tabela, você vê o cliente lançar uma exceção de armazenamento relatando uma mensagem de status "HTTP 404 (Não Encontrado)" do serviço de tabela. Quando você investiga a tabela no serviço de armazenamento da tabela, é possível ver que o serviço excluiu a entidade como solicitado.
Os detalhes da 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 do arquivo de log. Você pode também usar as métricas para identificar quando falhas como essa ocorrem e pesquisar os arquivos de log com base no horário que as métricas registraram esse erro. Essa entrada de log mostram a falha excluída com uma mensagem de status "HTTP (404) Outro Erro do Cliente". 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. A operação de exclusão com êxito aconteceu um pouco antes da solicitação de exclusão falhar.
A causa mais provável desse cenário é que o cliente enviou uma solicitação de exclusão da entidade para o serviço de tabela, que foi bem-sucedida, mas não recebeu uma confirmação do servidor (talvez devido a um problema temporário de rede). Em seguida, o cliente 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 ocorre com frequência, investigue porque o cliente não está recebendo as confirmações do serviço de tabela. Se o problema for intermitente, intercepte o erro "HTTP (404) Não encontrado" e log no cliente, mas permita que o cliente continue.
O cliente está recebendo mensagens HTTP 409 (Conflito)
A tabela a seguir mostra uma extração do log do lado do servidor para duas operações de cliente: DeleteIfExists seguida imediatamente pelo CreateIfNotExists uso do mesmo nome de contêiner de blob. Cada operação do cliente resulta em duas solicitações enviadas ao servidor, primeiro uma GetContainerProperties solicitação para verificar se o contêiner existe, seguida pela DeleteContainer solicitação ou CreateContainer .
| Timestamp | Operação | Result | Nome do contêiner | ID de 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, tabelas ou filas de blob, há um breve período antes que o nome fique disponível novamente.
O aplicativo do cliente deve usar nomes de contêiner exclusivos sempre que criar novos contêineres caso o padrão excluir/recriar for comum.
As métricas mostram uma baixa PercentSuccess ou as entradas de log analíticas têm operações com status de transação de ClientOtherErrors
As métricas de PercentSuccess capturam a porcentagem das operações que tiveram êxito com base nos códigos de status HTTP. As operações com códigos de status de 2XX contam como bem-sucedidas, enquanto as operações com códigos de status nos intervalos 3XX, 4XX e 5XX são contadas como malsucedidas e reduzem o valor da métrica PercentSuccess . Nos arquivos de log do lado do servidor, essas operações são registradas com um 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 executam com sucesso, mas que podem resultar em códigos de status HTTP sem sucesso incluem:
- ResourceNotFound (Not Found 404), por exemplo, de uma
GETsolicitação para um blob que não existe. - ResourceAlreadyExists (Conflito 409), por exemplo, de uma
CreateIfNotExistoperação em que o recurso já existe. - ConditionNotMet (Not Modified 304), por exemplo, de uma operação condicional, como quando um cliente envia um
ETagvalor e um cabeçalho HTTPIf-None-Matchpara 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 comuns da API REST.
As métricas de capacidade mostram um aumento inesperado em uso de capacidade de armazenamento
Se você vê mudanças repentinas, inesperadas na capacidade de uso na sua conta de armazenamento, você pode investigar as razões, primeiramente olhando as métricas de disponibilidade; por exemplo, um aumento no número de falhas de solicitações de exclusão pode levar a um aumento na quantidade de armazenamento de blobs que você está usando, já que operações de limpeza específicas de aplicativo que você esperava que estivessem liberando espaço podem não estar funcionando como esperado (por exemplo, porque os tokens SAS usados para liberação de espaço expiraram).
Seu problema apareceu por usar o emulador de armazenamento para desenvolvimento ou teste
Normalmente, você usa o emulador de armazenamento durante o desenvolvimento e o teste para evitar a necessidade de uma conta de armazenamento do Azure. Os problemas comuns que podem ocorrer quando você estiver usando o emulador de armazenamento são:
- O recurso "X" não está funcionando no emulador de armazenamento.
- Erro "O valor de um dos cabeçalhos HTTP não está no formato correto" ao usar o emulador de armazenamento.
- A execução do emulador de armazenamento requer privilégios administrativos.
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 saber mais, confira Usar o Emulador de Armazenamento do Azure para desenvolvimento e teste.
Para os recursos que não são compatíveis com o emulador de armazenamento, use o serviço de armazenamento do Azure em nuvem.
Erro "O valor de um dos cabeçalhos HTTP não está no formato correto" quando o emulador de armazenamento é usado
Você está testando seu aplicativo que usa a Biblioteca de Cliente de Armazenamento no emulador de armazenamento local e chamadas de método, como CreateIfNotExists falha, 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 cliente de armazenamento que você está usando. A Biblioteca de Cliente de Armazenamento adiciona o cabeçalho x-ms-version a todas as solicitações feitas. 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 envio. Você também pode ver o valor do se usar o x-ms-version header Fiddler para rastrear as solicitações do aplicativo cliente.
Esse cenário normalmente acontece se você instalar e usar a versão mais recente da biblioteca do cliente 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.
A execução do emulador de armazenamento requer privilégios administrativos
Você pode solicitar credenciais para o administrador quando você executar o emulador de armazenamento. Isso acontece apenas quando você inicializar o emulador de armazenamento pela primeira vez. Depois de inicializar o emulador de armazenamento, você não precisa de privilégios administrativos para executá-lo novamente.
Para saber mais, confira 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 exige privilégios administrativos.
Você encontrou problemas ao instalar o SDK do Azure para .NET
Quando você tenta instalar o SDK, ele falha ao tentar instalar o emulador de armazenamento em seu 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 o banco de dados
A causa é um problema com a instalação existente do LocalDB. Por padrão, o emulador de armazenamento usa o LocalDB para persistir os dados quando simula os serviços de armazenamento do Azure. Você pode reiniciar a sua instância LocalDB ao executar os seguintes comando na 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 anteriores de solução de problemas não incluem os problemas que você está tendo com o serviço de armazenamento, adote a seguinte abordagem para diagnosticar a solução de seu problema.
- Verifique suas métricas para ver se há alguma alteração em relação ao comportamento esperado da linha de base. A partir das métricas, você pode 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 procurar os dados de log do lado do servidor para obter informações mais detalhadas sobre qualquer erro que esteja ocorrendo. Essa informação pode ajudá-lo a encontrar e a solucionar 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 Cliente 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 o Apêndice 1: Usando o Fiddler para capturar tráfego HTTP e HTTPS.
Para obter mais informações sobre como usar o Wireshark, consulte o Apêndice 2: Usando o Wireshark para capturar o tráfego de rede.
Apêndices
Os anexos descrevem várias ferramentas que você pode achar úteis ao diagnosticar ou solucionar os problemas com o Armazenamento do Microsoft Azure (e outros serviços). Essas ferramentas não fazem parte do Armazenamento do Azure e algumas são produtos de terceiros. Dessa forma, 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 de seu processo de avaliação, você deve examinar as opções de licenciamento e suporte disponíveis nos fornecedores dessas ferramentas.
Apêndice 1: Usando o Fiddler para capturar o tráfego HTTP e HTTPS
Fiddler é uma ferramenta útil para analisar o tráfego HTTP e HTTPS entre o 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 com atenção para entender como ele faz isso e suas implicações de segurança.
Esse anexo dá 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.
Após você ter iniciado o Fiddler, ele começará capturar o tráfego HTTP e HTTPS da sua máquina local. A seguir há alguns comandos úteis para controlar o Fiddler:
- Parar e iniciar a captura de tráfego. No menu principal, vá para Arquivo e selecione Capturar Tráfego para ativar e desativar a captura.
- Salve os dados de tráfego capturados. No menu principal, vá para Arquivo, selecione Salvar e, em seguida, selecione Todas as Sessões. Isso permite que você salve o tráfego em um arquivo de arquivo de sessão. Você pode recarregar um Arquivo Morto de Sessão posteriormente para análise ou enviá-lo, se solicitado, ao 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 contosoemaildist.table.core.windows.net ponto de extremidade de armazenamento:
Apêndice 2: Usando o Wireshark para capturar o tráfego de rede
Wireshark é um analisar de protocolo de rede que permite que você exiba informações detalhadas de pacote de uma vasta gama de protocolos de rede.
O procedimento a seguir mostra como capturar informações detalhadas de pacote para tráfego a partir do computador local onde você instalou o Wireshark para o serviço de tabela na sua conta de armazenamento do Azure.
Habilite o Wireshark no seu computador local.
Na seção Iniciar , selecione a interface de rede local ou as interfaces que estão conectadas à Internet.
Selecione Opções de captura.
Adicione um filtro à caixa de texto Filtro de Captura . Por exemplo,
host contosoemaildist.table.core.windows.netconfigurará o Wireshark para capturar apenas pacotes enviados de ou para o ponto de extremidade do serviço Tabela na conta de armazenamento contosoemaildist . Confira a Lista completa de filtros de captura.
Selecione Iniciar. O Wireshark agora capturará todos os pacotes enviados de ou para o ponto de extremidade do serviço de tabela à medida que você usa seu aplicativo cliente em seu computador local.
Quando terminar, selecione Capturar>parada no menu principal.
Para salvar os dados capturados em um arquivo do Wireshark Capture, selecione Salvar arquivo>no menu principal.
O Wireshark irá realçar qualquer erro que existir na janela packetlist . Você também pode usar a janela Informações do especialista (selecione Analisar>informações do especialista) para exibir um resumo de erros e avisos.
Você também pode escolher exibir os dados de TCP conforme vistos pela camada de aplicativo, clicando com o botão direito do mouse nos dados de TCP e selecionando Seguir o Fluxo TCP. Isso será útil se você tiver capturado o despejo sem o filtro de captura. Para saber mais, confira Como seguir fluxos TCP.
Observação
Para saber mais sobre como usar o Wireshark, veja o Guia de Usuários do Wireshark.
Apêndice 4: Usando o Excel para exibir as métricas e os dados de log
Muitas ferramentas permitem que você baixe os dados de métricas de armazenamento a partir do armazenamento de tabela do Azure em um formato delimitado que o torna fácil para se carregado no Excel para exibição e análise. Os dados de Log de Armazenamento do Armazenamento de Blob do Azure já estão em um formato delimitado que pode ser carregado no Excel. No entanto, você precisará adicionar títulos de coluna apropriados com base nas informações em Formato de log da Análise de Armazenamento e Esquema de tabela de métricas da Análise de Armazenamento.
Para importar os dados de log de armazenamento para o Excel após ter baixado do armazenamento de blob:
- No menu Dados, selecione Do Texto.
- Navegue até o arquivo de log que 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 no Azure DevOps
Você pode também usar o recurso Application Insights no Azure DevOps como parte do seu monitoramento de desempenho e disponibilidade. Essa ferramenta pode:
- Garantir que seu aplicativo da Web esteja disponível e respondendo. Independentemente de seu aplicativo ser 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.
- Diagnostique rapidamente qualquer problema de desempenho ou exceções no seu serviço da Web. Descubra se a CPU ou outros recursos estão sendo alongados, receba rastreamento de linhas de exceções e pesquise facilmente pelos rastreamentos de log. Se o desempenho do aplicativo cair abaixo dos limites aceitáveis, a Microsoft poderá lhe enviar um email. Você pode monitorar os serviços Web .NET e Java.
Você pode encontrar mais informações em O que é o Application Insights.
Próximas etapas
Para obter mais informações sobre análise no Armazenamento do Azure, consulte estes recursos:
- Monitorar uma conta de armazenamento no portal do Azure
- Análise de armazenamento
- Métricas da análise de armazenamento
- Esquema da tabela de métricas da análise de armazenamento
- Logs de análise de armazenamento
- Formato de log de análise de armazenamento
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.