Compartilhar via

Análise do modo de falha para aplicativos do Azure

  • Artigo

A FMA (análise do modo de falha) é um processo de criação de resiliência em um sistema por meio da identificação de possíveis pontos de falha no sistema. A FMA deve ser parte das fases de arquitetura e de design para que você possa inserir a recuperação de falha no sistema desde o início.

Veja abaixo o processo geral para realizar uma FMA:

  1. Identifique todos os componentes no sistema. Inclua dependências externas, como provedores de identidade, serviços de terceiros e assim por diante.

  2. Para cada componente, identifique possíveis falhas que possam ocorrer. Um único componente pode ter mais de um modo de falha. Por exemplo, considere a possibilidade de falhas de leitura e de gravação separadamente, porque o impacto e as possíveis etapas de mitigação serão diferentes.

  3. Classifique cada modo de falha de acordo com seu risco geral. Considere estes fatores:

    • Qual é a probabilidade da falha. Ela é relativamente comum? Extremamente raro? Não são necessários números exatos; o objetivo é ajudar a classificar a prioridade.
    • Qual é o impacto no aplicativo em termos de disponibilidade, de perda de dados, do custo monetário e da interrupção dos negócios?

  4. Para cada modo de falha, determinam como o aplicativo responderá e se recuperará. Considere as compensações em relação aos custos e à complexidade do aplicativo.

Como ponto de partida para o seu processo FMA, este artigo contém um catálogo de possíveis modos de falha e suas etapas de mitigação. O catálogo é organizado por tecnologia ou serviço do Azure, além de uma categoria geral para o design em nível do aplicativo. O catálogo não é completo, mas abrange muitos dos principais serviços do Azure.

Observação

Falhas e erros devem ser considerados como coisas distintas. Uma falha é um evento inesperado dentro de um sistema que impede que ele continue funcionando normalmente. Por exemplo, um mau funcionamento de hardware que causa uma partição de rede é uma falha. Normalmente, as falhas requerem intervenção ou design específico para essa classe de falhas. Por outro lado, os erros são uma parte esperada das operações normais, são tratados imediatamente e o sistema continuará funcionando com a mesma capacidade após um erro. Por exemplo, erros descobertos durante a validação de entrada podem ser tratados por meio da lógica de negócios.

Serviço de Aplicativo

Aplicativo do Serviço de Aplicativo desliga.

Detecção. Causas possíveis::

  • Desligamento esperado

    • Um operador desliga o aplicativo, por exemplo, usando o Portal do Azure.
    • O aplicativo foi descarregado porque estava ocioso. (Somente se a configuração Always On estiver desabilitada.)

  • Desligamento inesperado

    • Falha no aplicativo.
    • Uma instância VM do Serviço de Aplicativo torna-se não disponível.

O log Application_End detectará o desligamento do domínio do aplicativo (falha simples de processo) e será a única maneira de detectar os desligamentos do domínio do aplicativo.

Recuperação:

  • Se o desligamento for esperado, use o evento de desligamento do aplicativo para desligá-lo normalmente. Por exemplo, no ASP.NET, use o método Application_End.
  • Se o aplicativo for descarregado quando ocioso, ele será reiniciado automaticamente na próxima solicitação. No entanto, ocorrerá a "inicialização a frio".
  • Para impedir que o aplicativo seja descarregado quando ocioso, habilite a configuração Always On no aplicativo Web. Veja Configurar aplicativos Web no Serviço de Aplicativo do Azure.
  • Para impedir que um operador desligue o aplicativo, defina um bloqueio de recurso com o nível ReadOnly. Veja Bloquear recursos com o Azure Resource Manager.
  • Se o aplicativo falhar ou se uma VM do Serviço de Aplicativo ficar não disponível, o Serviço de Aplicativo reiniciará automaticamente o aplicativo.

Diagnóstico. Logs do aplicativo e logs do servidor Web. Veja Habilitar o registro em log de diagnóstico para aplicativos Web no Serviço de Aplicativo do Azure.

Um usuário específico repetidamente faz solicitações inválidas ou sobrecarrega o sistema.

Detecção. Autentique os usuários e inclua a ID de usuário nos logs do aplicativo.

Recuperação:

Diagnóstico. Registre em log todas as solicitações de autenticação.

Uma atualização inválida foi implantada.

Detecção. Monitore a integridade do aplicativo por meio do portal do Azure (consulte Monitorar o desempenho do aplicativo Web do Azure) ou implemente o padrão de monitoramento de ponto de extremidade de integridade.

Recuperação:. Use vários slots de implantação e reverta para a última implantação válida conhecida. Para obter mais informações, veja Basic web application (Aplicativo Web básico).

Microsoft Entra ID

Falha na autenticação OpenID Connect.

Detecção. Os possíveis modos de falha incluem:

  1. O Microsoft Entra ID não está disponível ou não pode ser acessado devido a um problema de rede. Falha no redirecionamento para o ponto de extremidade de autenticação e o middleware OpenID Connect gera uma exceção.
  2. O locatário do Microsoft Entra não existe. O redirecionamento para o ponto de extremidade de autenticação retorna um código de erro HTTP e o middleware OpenID Connect gera uma exceção.
  3. O usuário não pode se conectar. Nenhuma estratégia de detecção é necessária. O Microsoft Entra ID resolve as falhas de logon.

Recuperação:

  1. Detecte exceções sem tratamento do middleware.
  2. Trate os eventos AuthenticationFailed.
  3. Redirecione o usuário para uma página de erro.
  4. O usuário tenta novamente.

Falha ao gravar dados do Azure Search.

Detecção. Detecte erros Microsoft.Rest.Azure.CloudException.

Recuperação:

O SDK .NET do Search tenta novamente de maneira automática após falhas transitórias. Quaisquer exceções lançadas pelo SDK do cliente devem ser tratadas como erros não transitórios.

A política de novas tentativas padrão usa retirada exponencial. Para usar uma política de novas tentativas diferente, chame SetRetryPolicy na classe SearchIndexClient ou SearchServiceClient. Para obter mais informações, veja Tentativas automáticas.

Diagnóstico. Use a Análise de Tráfego de Pesquisa.

Falha ao ler dados do Azure Search.

Detecção. Detecte erros Microsoft.Rest.Azure.CloudException.

Recuperação:

O SDK .NET do Search tenta novamente de maneira automática após falhas transitórias. Quaisquer exceções lançadas pelo SDK do cliente devem ser tratadas como erros não transitórios.

A política de novas tentativas padrão usa retirada exponencial. Para usar uma política de novas tentativas diferente, chame SetRetryPolicy na classe SearchIndexClient ou SearchServiceClient. Para obter mais informações, veja Tentativas automáticas.

Diagnóstico. Use a Análise de Tráfego de Pesquisa.

Cassandra

Falha de leitura ou de gravação em um nó.

Detecção. Detecte a exceção. Para clientes .NET, normalmente será System.Web.HttpException. Outro cliente pode ter outros tipos de exceção. Para obter mais informações, veja Cassandra error handling done right (Tratamento de erro do Cassandra feito da maneira correta).

Recuperação:

  • Cada cliente Cassandra tem suas próprias políticas de novas tentativas e funcionalidades. Para obter mais informações, veja Cassandra error handling done right (Tratamento de erro do Cassandra feito da maneira correta).
  • Use uma implantação com reconhecimento de rack, com nós de dados distribuídos entre os domínios de falha.
  • Implante em várias regiões com consistência de quorum local. Se ocorrer uma falha não transitória, faça failover para outra região.

Diagnóstico. Logs de aplicativo

Serviço de nuvem

Funções de trabalho ou Web estão sendo desligadas inesperadamente.

Detecção. O evento RoleEnvironment.Stopping é disparado.

Recuperação. Substitua o método RoleEntryPoint.OnStop para executar uma limpeza normal. Para obter mais informações, veja The Right Way to Handle Azure OnStop Events (A maneira correta de tratar eventos OnStop do Azure) (blog).

Azure Cosmos DB

Falha na leitura de dados.

Detecção. Detecte System.Net.Http.HttpRequestException ou Microsoft.Azure.Documents.DocumentClientException.

Recuperação:

  • O SDK tenta novamente de maneira automática em caso de tentativas com falha. Para definir o número de novas tentativas e o tempo de espera máximo, configure ConnectionPolicy.RetryOptions. As exceções que o cliente gera excedem a política de repetição ou não são erros transitórios.
  • Se o Azure Cosmos DB limitar o cliente, ele retornará um erro HTTP 429. Confira o código de status no DocumentClientException. Se você estiver recebendo o erro 429 consistentemente, considere aumentar o valor da taxa de transferência da coleção.
    • Se você estiver usando a API do MongoDB, o serviço retornará o código de erro 16500 durante a limitação.
  • Habilite a redundância de zona ao trabalhar com uma região que ofereça suporte a zonas de disponibilidade. Quando você usa a redundância de zona, o Azure Cosmos DB faz failover automaticamente no caso de uma interrupção de zona. Para obter mais informações, consulte Obter alta disponibilidade com o Azure Cosmos DB.
  • Se você estiver criando uma solução de várias regiões, replique o banco de dados do Azure Cosmos DB em duas ou mais regiões. Todas as réplicas são legíveis. Usando os SDKs cliente, especifique o parâmetro PreferredLocations. Trata-se de uma lista ordenada de regiões do Azure. Todas as leituras serão enviadas para a primeira região disponível na lista. Se a solicitação falhar, o cliente tentará outras regiões na lista, em ordem. Para obter mais informações, consulte Como configurar a distribuição global no Azure Cosmos DB para NoSQL.

Diagnóstico. Registre em log todos os erros no lado do cliente.

Falha na gravação de dados.

Detecção. Detecte System.Net.Http.HttpRequestException ou Microsoft.Azure.Documents.DocumentClientException.

Recuperação:

  • O SDK tenta novamente de maneira automática em caso de tentativas com falha. Para definir o número de novas tentativas e o tempo de espera máximo, configure ConnectionPolicy.RetryOptions. As exceções que o cliente gera excedem a política de repetição ou não são erros transitórios.
  • Se o Azure Cosmos DB limitar o cliente, ele retornará um erro HTTP 429. Confira o código de status no DocumentClientException. Se você estiver recebendo o erro 429 consistentemente, considere aumentar o valor da taxa de transferência da coleção.
  • Habilite a redundância de zona ao trabalhar com uma região que ofereça suporte a zonas de disponibilidade. Quando você usa a redundância de zona, o Azure Cosmos DB replica de forma síncrona todas as gravações entre zonas de disponibilidade. Para obter mais informações, consulte Obter alta disponibilidade com o Azure Cosmos DB.
  • Se você estiver criando uma solução de várias regiões, replique o banco de dados do Azure Cosmos DB em duas ou mais regiões. Se a região primária falhar, outra região será promovida para gravação. Você também pode disparar um failover manual. O SDK faz a descoberta e roteamento automáticos para que o código do aplicativo continue a funcionar após um failover. Durante o período do failover (normalmente alguns minutos), as operações de gravação terão latência mais alta, enquanto o SDK localizar a nova região de gravação. Para obter mais informações, consulte Como configurar a distribuição global no Azure Cosmos DB para NoSQL.
  • Como fallback, mantenha o documento em uma fila de backup e processe a fila mais tarde.

Diagnóstico. Registre em log todos os erros no lado do cliente.

Armazenamento de filas

Falha consistente na gravação de uma mensagem do Armazenamento de Filas do Azure.

Detecção. Depois de N novas tentativas, ainda há falha na operação de gravação.

Recuperação:

  • Armazene os dados em um cache local e encaminhe as gravações para o armazenamento mais tarde, quando o serviço estiver disponível.
  • Crie uma fila secundária e grave nessa fila se a fila principal não estiver disponível.

Diagnóstico. Use métricas de armazenamento.

O aplicativo não pode processar uma mensagem específica da fila.

Detecção. Específico ao aplicativo. Por exemplo, a mensagem contém dados inválidos ou há falha na lógica de negócios por algum motivo.

Recuperação:

Mova a mensagem para uma fila separada. Execute um processo separado para examinar as mensagens na fila.

Considere usar filas de mensagens do Barramento de Serviço do Azure, que fornece uma funcionalidade de fila de mensagens mortas para essa finalidade.

Observação

Se você estiver usando filas de armazenamento com WebJobs, o SDK do WebJobs fornecerá tratamento interno de mensagens suspeitas. Veja Como usar o Armazenamento de Filas do Azure com o SDK do WebJobs.

Diagnóstico. Use o registro em log do aplicativo.

Cache Redis do Azure

Falha na leitura do cache.

Detecção. Detecte StackExchange.Redis.RedisConnectionException.

Recuperação:

  1. Tente novamente em caso de falhas transitórias. O Cache do Azure para Redis dá suporte a tentativas internas. Para obter mais informações, consulte Diretrizes de nova tentativa do Cache do Azure para Redis.
  2. Trate as falhas não transitórias como uma perda no cache e faça fallback para a fonte de dados original.

Diagnóstico. Use Cache do Azure para diagnóstico Redis.

Falha ao gravar no cache.

Detecção. Detecte StackExchange.Redis.RedisConnectionException.

Recuperação:

  1. Tente novamente em caso de falhas transitórias. O Cache do Azure para Redis dá suporte a tentativas internas. Para obter mais informações, consulte Diretrizes de nova tentativa do Cache do Azure para Redis.
  2. Se o erro não for transitório, ignore-o e deixe que outras transações gravem no cache mais tarde.

Diagnóstico. Use Cache do Azure para diagnóstico Redis.

Banco de Dados SQL

Não é possível conectar ao banco de dados na região primária.

Detecção. Falha na conexão.

Recuperação:

  • Habilitar a redundância de zona. Ao habilitar a redundância de zona, o Banco de Dados SQL do Azure replica automaticamente suas gravações em várias zonas de disponibilidade do Azure em regiões com suporte. Para obter mais informações, consulte Disponibilidade com redundância de zona.

  • Habilitar a replicação geográfica. Se você estiver criando uma solução de várias regiões, considere habilitar a replicação geográfica ativa do Banco de dados SQL.

    Pré-requisito: o banco de dados deve estar configurado para replicação geográfica ativa. Veja Replicação geográfica ativa para Banco de Dados SQL.

    A réplica usa uma cadeia de conexão diferente, portanto será necessário atualizar a cadeia de conexão em seu aplicativo.

O cliente fica sem conexões no pool de conexões.

Detecção. Detecte erros System.InvalidOperationException.

Recuperação:

  • Repita a operação.
  • Como plano de mitigação, isole os pools de conexões para cada caso de uso, para que um caso de uso não domine todas as conexões.
  • Aumente os limites máximos dos pools de conexões.

Diagnóstico. Logs do aplicativo.

O limite de conexão de banco de dados foi alcançado.

Detecção. O Banco de Dados SQL do Azure limita o número de trabalhos, logons e sessões simultâneos. Os limites dependem da camada de serviço. Para obter mais informações, veja Limites de recursos do Banco de Dados SQL do Azure.

Para detectar esses erros, detecte System.Data.SqlClient.SqlException e verifique o valor de SqlException.Number para o código de erro SQL. Para obter um lista de códigos de erro relevantes, veja Códigos de erro de SQL para aplicativos cliente do Banco de Dados SQL: erro de conexão de banco de dados e outros problemas.

Recuperação. Esses erros são considerados transitórios, portanto tentar novamente poderá resolver o problema. Se você encontrar consistentemente esses erros, considere dimensionar o banco de dados.

Diagnóstico. - A consulta sys.event_log retorna conexões de banco de dados bem-sucedidas, falhas na conexão e deadlocks.

Mensagens do Barramento de Serviço do Azure

Falha na leitura de uma mensagem de uma fila do Barramento de Serviço.

Detecção. Detecte exceções no SDK do cliente. A classe base para exceções do Barramento de Serviço é MessagingException. Se o erro for transitório, a propriedade IsTransient será true.

Para saber mais, veja Exceções de mensagens do Barramento de Serviço.

Recuperação:

  1. Tente novamente em caso de falhas transitórias. Veja Diretrizes de repetição para Barramento de Serviço.
  2. As mensagens que não podem ser entregues a nenhum receptor são colocadas em um fila de mensagens mortas. Use essa fila para ver quais mensagens não puderam ser recebidas. Não há opções de limpeza automática da fila de mensagens mortas. As mensagens permanecem lá até você explicitamente recuperá-las. Veja Visão geral das filas de mensagens mortas do Barramento de Serviço.

Falha na gravação de uma mensagem em uma fila do Barramento de Serviço.

Detecção. Detecte exceções no SDK do cliente. A classe base para exceções do Barramento de Serviço é MessagingException. Se o erro for transitório, a propriedade IsTransient será true.

Para saber mais, veja Exceções de mensagens do Barramento de Serviço.

Recuperação:

  • O cliente do Barramento de Serviço tenta novamente de maneira automática após erros transitórios. Por padrão, ele usa retirada exponencial. Após a contagem máxima de novas tentativas ou do tempo limite máximo, o cliente gerará uma exceção. Para obter mais informações, veja Diretrizes de repetição para Barramento de Serviço.

  • Se a cota da fila for excedida, o cliente gerará QuotaExceededException. A mensagem de exceção fornece mais detalhes. Retire algumas mensagens da fila antes de tentar novamente e considere usar o padrão de Disjuntor para evitar novas tentativas contínuas enquanto a cota estiver excedida. Além disso, verifique se a propriedade BrokeredMessage.TimeToLive não está definida com um valor muito alto.

  • Em uma região, a resiliência pode ser melhorada usando filas ou tópicos particionados. Uma fila ou um tópico não particionado é atribuído a um repositório de mensagens. Se esse repositório de mensagens não estiver disponível, todas as operações na fila ou no tópico falharão. Uma fila ou tópico particionado é particionado em vários repositórios de mensagens.

  • Use a redundância de zona para replicar automaticamente as alterações entre várias zonas de disponibilidade. Se uma zona de disponibilidade falhar, o failover ocorrerá automaticamente. Para saber mais, confira Práticas recomendadas para isolar aplicativos contra interrupções e desastres do Barramento de Serviço.

  • Se você estiver criando uma solução de várias regiões, crie dois namespaces do Barramento de Serviço em regiões diferentes e replique as mensagens. Você pode usar a replicação ativa ou passiva.

    • Replicação ativa: o cliente envia todas as mensagens para ambas as filas. O receptor escuta em ambas as filas. Marque mensagens com um identificador exclusivo para que o cliente possa descartar mensagens duplicadas.
    • Replicação passiva: o cliente envia a mensagem para uma fila. Se houver um erro, o cliente fará fallback para a outra fila. O receptor escuta em ambas as filas. Essa abordagem reduz o número de mensagens duplicadas enviadas. No entanto, o receptor ainda deve tratar as mensagens duplicadas.

    Para saber mais, veja Exemplo de replicação geográfica e Práticas recomendadas para isolar aplicativos contra interrupções e desastres do Barramento de Serviço.

Duplique a mensagem.

Detecção. Examine as propriedades MessageId e DeliveryCount da mensagem.

Recuperação:

  • Se possível, crie suas próprias operações de processamento de mensagens para serem idempotentes. Caso contrário, armazene as IDs das mensagens já processadas e verifique a ID antes de processar uma mensagem.

  • Habilite detecção de duplicidades criando a fila com RequiresDuplicateDetection definido como true. Com essa configuração, o Barramento de Serviço exclui automaticamente qualquer mensagem enviada com a mesma MessageId que alguma mensagem anterior. Observe o seguinte:

    • Essa configuração impede que mensagens duplicadas sejam colocadas na fila. Ela não impede que um receptor de processar a mesma mensagem mais de uma vez.
    • A detecção de duplicidades tem uma janela de tempo. Se uma duplicata for enviada fora dessa janela, ela não será detectada.

Diagnóstico. Registre em log as mensagens duplicadas.

O aplicativo não pode processar uma mensagem específica da fila.

Detecção. Específico ao aplicativo. Por exemplo, a mensagem contém dados inválidos ou há falha na lógica de negócios por algum motivo.

Recuperação:

Há dois modos de falha a serem considerados.

  • O receptor detecta a falha. Nesse caso, mova a mensagem para a fila de mensagens mortas. Depois, execute um processo separado para examinar as mensagens na fila de mensagens mortas.
  • O receptor encontra uma falha durante o processamento da mensagem, por exemplo, devido a uma exceção sem tratamento. Para tratar esse caso, use o modo PeekLock. Nesse modo, se o bloqueio expirar, a mensagem ficará disponível para outros receptores. Se a mensagem exceder a contagem máxima de entregas ou o tempo de vida, ela será automaticamente movida para a fila de mensagens mortas.

Para saber mais, confira Visão geral das filas de mensagens mortas do Barramento de Serviço.

Diagnóstico. Sempre que o aplicativo mover uma mensagem para a fila de mensagens mortas, grave um evento nos logs do aplicativo.

Armazenamento

Falha na gravação de dados no Armazenamento do Azure

Detecção. O cliente recebe erros durante a gravação.

Recuperação:

  1. Tente a operação novamente para recuperar-se de falhas transitórias. A política de novas tentativas no SDK cliente trata disso automaticamente.

  2. Implemente o padrão de Disjuntor para evitar armazenamento excessivo.

  3. Se houver falha em N novas tentativas, execute um fallback normal. Por exemplo:

    • Armazene os dados em um cache local e encaminhe as gravações para o armazenamento mais tarde, quando o serviço estiver disponível.
    • Se a ação de gravação estiver em um escopo transacional, compense a transação.

Diagnóstico. Use métricas de armazenamento.

Falha na leitura de dados do Armazenamento do Azure.

Detecção. O cliente recebe erros durante a leitura.

Recuperação:

  1. Tente a operação novamente para recuperar-se de falhas transitórias. A política de novas tentativas no SDK cliente trata disso automaticamente.
  2. Para o armazenamento RA-GRS, se houver falha na leitura do ponto de extremidade primário, tente ler do ponto de extremidade secundário. O SDK cliente pode tratar disso automaticamente. Veja Replicação de Armazenamento do Azure.
  3. Se houver falha em N novas tentativas, execute uma ação de fallback para degradar normalmente. Por exemplo, se uma imagem do produto não puder ser recuperada do armazenamento, mostre uma imagem de espaço reservado genérico.

Diagnóstico. Use métricas de armazenamento.

Máquina virtual

Falha na conexão a uma VM de back-end.

Detecção. Erros na conexão de rede.

Recuperação:

  • Implante pelo menos duas VMs de back-end em um conjunto de disponibilidade, atrás de um balanceador de carga.
  • Se o erro na conexão for transitório, às vezes, o TCP tentará enviar a mensagem novamente com êxito.
  • Implemente uma política de novas tentativas no aplicativo.
  • Para erros persistentes ou não transitórios, implemente o padrão de Disjuntor.
  • Se a VM chamando exceder seu limite de saída de rede, a fila de saída será preenchida. Se a fila de saída estiver consistentemente cheia, considere a possibilidade de expansão.

Diagnóstico. Registre em log os eventos nos limites dos serviços.

A instância VM torna-se não disponível ou não íntegra.

Detecção. Configure uma investigação de integridade do balanceador de carga que indique se a instância VM está íntegra. A investigação deve verificar se as funções críticas estão respondendo corretamente.

Recuperação. Para cada camada de aplicativo, coloque várias instâncias de VM no mesmo conjunto de disponibilidade e coloque um balanceador de carga na frente das VMs. Se houver falha na investigação de integridade, o balanceador de carga interromperá o envio de novas conexões para a instância não íntegra.

Diagnóstico. - Use a análise de logs do balanceador de carga.

  • Configure o sistema de monitoramento para monitorar todos os pontos de extremidade de monitoramento de integridade.

O operador desliga uma VM acidentalmente.

Detecção. N/D

Recuperação. Defina um bloqueio de recurso com nível ReadOnly. Veja Bloquear recursos com o Azure Resource Manager.

Diagnóstico. Use os Logs de Atividades do Azure.

WebJobs

A execução de trabalho contínuo é interrompida quando o host do SCM está ocioso.

Detecção. Passe um token de cancelamento para a função WebJob. Para obter mais informações, consulte Desligamento normal.

Recuperação. Habilite a configuração Always On no aplicativo Web. Para obter mais informações, consulte Executar tarefas em segundo plano com o WebJobs.

Design do aplicativo

O aplicativo não pode tratar de um aumento nas solicitações de entrada.

Detecção. Depende do aplicativo. Sintomas comuns:

  • O site é iniciado retornando códigos de erro HTTP 5xx.
  • Serviços dependentes, como o banco de dados ou o armazenamento, iniciam as solicitações de limitação. Procure erros HTTP, como HTTP 429 (Número excessivo de solicitações), dependendo do serviço.
  • O tamanho da Fila HTTP aumenta.

Recuperação:

  • Escala horizontal para tratar do aumento de carga.

  • Mitigue falhas para evitar que falhas em cascata interrompa o aplicativo inteiro. As estratégias de mitigação incluem:

Diagnóstico. Use o registro em log de diagnóstico do Serviço de Aplicativo. Use um serviço como o Azure Log Analytics, o Application Insights ou o New Relic para ajudar na compreensão dos logs de diagnóstico.

Um exemplo está disponível aqui. Ele usa Polly para estas exceções:

  • 429 - Limitação
  • 408 - Tempo limite
  • 401 – não autorizado
  • 503 ou 5xx - Serviço indisponível

Falha em uma das operações em um fluxo de trabalho ou uma transação distribuída.

Detecção. Depois de N novas tentativas, ainda há falha.

Recuperação:

  • Como plano de mitigação, implemente o padrão do Supervisor do Agente do Agendador para gerenciar o fluxo de trabalho inteiro.
  • Não tente novamente quando o tempo limite esgotar. Há uma baixa taxa de êxito para esse erro.
  • Coloque o trabalho na fila para tentar novamente mais tarde.

Diagnóstico. Registre em log todas as operações (bem-sucedidas e com falha), incluindo as ações de compensação. Use as IDs de correlação para que você possa acompanhar todas as operações na mesma transação.

Falha em uma chamada para um serviço remoto.

Detecção. Código de erro HTTP.

Recuperação:

  1. Tente novamente em caso de falhas transitórias.
  2. Se a chamada falhar após N tentativas, execute uma ação de fallback. (Depende do aplicativo.)
  3. Implemente o padrão de Disjuntor para evitar falhas em cascata.

Diagnóstico. Registre em log todas as falhas de chamada remota.

Próximas etapas

Consulte Resiliência e dependências na Estrutura bem arquitetada do Azure. A incorporação da recuperação de falhas ao sistema deve fazer parte das fases de arquitetura e design desde o início para evitar riscos de falha.