Compartilhar via

Solucionar problemas de disponibilidade em contas de armazenamento do Azure

  • Artigo

Este artigo ajuda você a investigar alterações na disponibilidade (como o número de solicitações com falha). Essas alterações na disponibilidade geralmente podem ser identificadas monitorando as métricas de armazenamento no Azure Monitor. Para obter informações gerais sobre como usar métricas e logs no Azure Monitor, consulte os seguintes artigos:

Monitoramento da disponibilidade

Você deve monitorar a disponibilidade dos serviços de armazenamento em sua conta de armazenamento monitorando o valor da métrica Disponibilidade. A métrica Disponibilidade contém um valor percentual. Ele é calculado pegando o valor total de solicitações faturáveis e dividindo-o pelo número de solicitações aplicáveis, incluindo as solicitações que produziram erros inesperados.

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 a dimensão ResponseType em busca de tipos de erro, como ServerTimeoutError. Você deve esperar que a Disponibilidade caia temporariamente 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. A métrica Disponibilidade só estará disponível para períodos de tempo em que as transações também ocorrerem na conta.

Você pode usar recursos no Azure Monitor para alertá-lo se a disponibilidade de um serviço estiver abaixo de um limite especificado.

As métricas mostram um aumento em erros de limitação

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 o valor ClientThrottlingError ou ServerBusyError da dimensão ResponseType mostrar um aumento no percentual de solicitações que estão falhando com um erro de limitação, você precisa investigar um dos dois cenários:

  • Aumento transitório em PercentThrottlingError
  • Aumento permanente em erro de PercentThrottlingError

Um aumento nos erros de limitação geralmente ocorre ao mesmo tempo que um aumento no número de solicitações de armazenamento ou quando você está testando inicialmente a carga do 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 de erros de limitação

Se você estiver vendo picos nos erros de limitação que coincidem com períodos de alta atividade para o aplicativo, implemente 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, confira a propriedade RetryOptions.MaxRetries.

Observação

Você também pode ver picos nos erros de limitação 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 de erros de limitação

Se você estiver vendo um valor consistentemente alto para erros de limitação 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ê estiver vendo erros de limitação em uma tabela, considere usar um esquema de particionamento diferente para distribuir suas transações em várias partições usando uma gama mais ampla de valores de 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 particionamento diferente ou avalie se o uso do armazenamento de blobs pode ser uma solução melhor. Além disso, verifique se a limitação está ocorrendo devido a 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 10 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 afeta 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. Cada entidade lida contará para o número total de transações nessa partição. Portanto, você pode atingir facilmente as metas 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 erros de tempo limite

Erros de tempo limite ocorrem quando a dimensão ResponseType é igual a ServerTimeoutError ou ClientTimeout.

Suas métricas mostram um aumento em erros de tempo limite para um de 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.

Os tempos limites do servidor (ServerTimeOutError) são causados por um erro no servidor. Os tempos limite do cliente (ClientTimeout) 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.

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 erros de rede

Erros de rede ocorrem quando a dimensão ResponseType é igual a NetworkError. Eles ocorrem quando um 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 as ferramentas de análise de rede de terceiros para investigar problemas de conectividade de rede do cliente.

Confira também

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.