Processamento de erros e novas tentativas das Funções do Azure

  • Artigo
  • 8 minutos para ler

O processamento de erros no Funções do Azure é importante para o ajudar a evitar dados perdidos, evitar eventos perdidos e monitorizar o estado de funcionamento da sua aplicação. Também é uma forma importante de o ajudar a compreender os comportamentos de repetição dos acionadores baseados em eventos.

Este artigo descreve estratégias gerais para o processamento de erros e as estratégias de repetição disponíveis.

Importante

Estamos a remover o suporte da política de repetição no runtime para acionadores que não o Temporizador, o Kafka e os Hubs de Eventos depois de esta funcionalidade ficar disponível para o público em geral. O suporte da política de repetição de pré-visualização para todos os acionadores que não o Temporizador e os Hubs de Eventos foi removido em dezembro de 2022. Para obter mais informações, consulte a secção Repetições .

Processar erros

Os erros que ocorrem numa função do Azure podem resultar de qualquer um dos seguintes:

Para evitar a perda de dados ou mensagens perdidas, é importante praticar um bom processamento de erros. Esta secção descreve algumas práticas recomendadas de processamento de erros e fornece ligações para mais informações.

Ativar o Application Insights

Funções do Azure integra-se com o Application Insights para recolher dados de erro, dados de desempenho e registos de runtime. Deve utilizar o Application Insights para detetar e compreender melhor os erros que ocorrem nas execuções de funções. Para saber mais, veja Monitorizar Funções do Azure.

Utilizar o processamento de erros estruturados

Capturar e registar erros é fundamental para monitorizar o estado de funcionamento da sua aplicação. O nível mais alto de qualquer código de função deve incluir um bloco try/catch. No bloco catch, pode capturar e registar erros. Para obter informações sobre os erros que podem ser gerados por enlaces, veja Códigos de erro de enlace.

Planear a estratégia de repetição

Várias extensões de enlaces de Funções fornecem suporte incorporado para repetições. Além disso, o runtime permite-lhe definir políticas de repetição para funções acionadas por Hubs de Eventos, Temporizador, Kafka e Hubs de Eventos. Para saber mais, veja Repetições. Para acionadores que não fornecem comportamentos de repetição, poderá querer implementar o seu próprio esquema de repetição.

Design para idempotência

A ocorrência de erros quando está a processar dados pode ser um problema para as suas funções, especialmente quando está a processar mensagens. É importante considerar o que acontece quando o erro ocorre e como evitar o processamento duplicado. Para saber mais, veja Criar Funções do Azure para entradas idênticas.

Tentativas

Existem dois tipos de repetições disponíveis para as suas funções:

  • Comportamentos de repetição incorporados de extensões de acionador individuais
  • Políticas de repetição fornecidas pelo runtime das Funções

A tabela seguinte indica que acionadores suportam repetições e onde o comportamento de repetição está configurado. Também liga a mais informações sobre erros provenientes dos serviços subjacentes.

Acionador/enlace Repetir origem Configuração
Azure Cosmos DB Políticas de repetição Nível da função
Armazenamento de Blobs do Azure Extensão de enlace host.json
Azure Event Grid Extensão de enlace Subscrição de eventos
Azure Event Hubs Políticas de repetição Nível da função
Armazenamento de Filas do Azure Extensão de enlace host.json
RabbitMQ Extensão de enlace Fila de mensagens não entregues
Service Bus do Azure Extensão de enlace Fila de mensagens não entregues
Temporizador Políticas de repetição Nível da função
Kafka Políticas de repetição Nível da função

Políticas de repetição

A partir da versão 3.x do runtime de Funções do Azure, pode definir políticas de repetição para acionadores de Temporizador, Kafka e Hubs de Eventos que são impostos pelo runtime das Funções.

A política de repetição indica ao runtime para executar novamente uma execução falhada até ocorrer uma conclusão com êxito ou o número máximo de repetições ser atingido.

Uma política de repetição é avaliada quando uma função acionada pelo Temporizador, Kafka ou Hubs de Eventos gera uma exceção não identificada. Como melhor prática, deve detetar todas as exceções no seu código e voltar a gerar quaisquer erros que pretenda que resultem numa repetição.

Importante

Os pontos de verificação dos Hubs de Eventos não serão escritos até que a política de repetição da execução esteja concluída. Devido a este comportamento, o progresso na partição específica é colocado em pausa até que o lote atual seja concluído.

A extensão dos Hubs de Eventos v5 suporta capacidades de repetição adicionais para interações entre o anfitrião das Funções e o hub de eventos. Veja a clientRetryOptionssecção Hubs de Eventos do ficheiro host.json para obter mais informações.

Estratégias de repetição

Pode configurar duas estratégias de repetição que são suportadas pela política:

É permitido decorrido um período de tempo especificado entre cada repetição.

Contagem máxima de repetições

Pode configurar o número máximo de vezes que uma execução de função é repetida antes de uma eventual falha. A contagem de repetições atual é armazenada na memória da instância.

É possível que uma instância tenha uma falha entre tentativas de repetição. Quando uma instância falha durante uma política de repetição, a contagem de repetições é perdida. Quando existem falhas de instâncias, o acionador dos Hubs de Eventos consegue retomar o processamento e repetir o lote numa nova instância, com a reposição da contagem de repetições para zero. O acionador de temporizador não é retomado numa nova instância.

Este comportamento significa que a contagem máxima de repetições é o melhor esforço. Em alguns casos raros, uma execução pode ser repetida mais do que o número máximo de vezes pedido. Para os acionadores de Temporizador, as repetições podem ser inferiores ao número máximo pedido.

Exemplos de repetição

As repetições requerem o pacote NuGet Microsoft.Azure.WebJobs>= 3.0.23

[FunctionName("EventHubTrigger")]
[FixedDelayRetry(5, "00:00:10")]
public static async Task Run([EventHubTrigger("myHub", Connection = "EventHubConnection")] EventData[] events, ILogger log)
{
// ...
}
Propriedade Descrição
MaxRetryCount Obrigatório. O número máximo de repetições permitidas por execução de funções. -1 significa tentar novamente indefinidamente.
DelayInterval O atraso que é utilizado entre repetições. Especifique-a como uma cadeia com o formato HH:mm:ss.

Eis a política de repetição no ficheiro function.json :

{
    "disabled": false,
    "bindings": [
        {
            ....
        }
    ],
    "retry": {
        "strategy": "fixedDelay",
        "maxRetryCount": 4,
        "delayInterval": "00:00:10"
    }
}
propriedade function.json Descrição
estratégia Obrigatório. A estratégia de repetição a utilizar. Os valores válidos são fixedDelay ou exponentialBackoff.
maxRetryCount Obrigatório. O número máximo de repetições permitidas por execução de funções. -1 significa tentar novamente indefinidamente.
delayInterval O atraso que é utilizado entre repetições quando está a utilizar uma fixedDelay estratégia. Especifique-a como uma cadeia com o formato HH:mm:ss.
minimumInterval O atraso mínimo de repetição quando está a utilizar uma exponentialBackoff estratégia. Especifique-a como uma cadeia com o formato HH:mm:ss.
maximumInterval O atraso máximo de repetição quando estiver a utilizar exponentialBackoff a estratégia. Especifique-a como uma cadeia com o formato HH:mm:ss.

Eis um exemplo de Python que utiliza o contexto de repetição numa função:

import azure.functions
import logging


def main(mytimer: azure.functions.TimerRequest, context: azure.functions.Context) -> None:
    logging.info(f'Current retry count: {context.retry_context.retry_count}')

    if context.retry_context.retry_count == context.retry_context.max_retry_count:
        logging.warn(
            f"Max retries of {context.retry_context.max_retry_count} for "
            f"function {context.function_name} has been reached")


@FunctionName("TimerTriggerJava1")
@FixedDelayRetry(maxRetryCount = 4, delayInterval = "00:00:10")
public void run(
    @TimerTrigger(name = "timerInfo", schedule = "0 */5 * * * *") String timerInfo,
    final ExecutionContext context
) {
    context.getLogger().info("Java Timer trigger function executed at: " + LocalDateTime.now());
}

Códigos de erro de enlace

Quando está a integrar com os serviços do Azure, os erros podem ter origem nas APIs dos serviços subjacentes. As informações relacionadas com erros específicos do enlace estão disponíveis nas secções "Exceções e códigos de retorno" dos seguintes artigos:

Passos seguintes