Gestion des erreurs et nouvelles tentatives dans Azure Functions

La gestion des erreurs dans Azure Functions est importante pour vous aider à éviter des pertes de données et des événements manqués, ainsi que pour superviser l’intégrité de votre application. Il s’agit également d’un point important permettant de comprendre les comportements de nouvelle tentative des déclencheurs basés sur des événements.

Cet article décrit les stratégies générales de gestion des erreurs et les stratégies de nouvelles tentatives disponibles.

Important

Nous supprimons la prise en charge de la stratégie de nouvelles tentatives dans le runtime pour des déclencheurs autres que Timer, Kafka et Event Hubs quand cette fonctionnalité passe en disponibilité générale (GA). La prise en charge de la stratégie de nouvelles tentatives en préversion pour tous les déclencheurs autres que Timer et Event Hubs a été supprimée en décembre 2022. Pour plus d’informations, consultez la section Nouvelles tentatives.

Gestion des erreurs

Voici les causes possibles des erreurs se produisant dans une fonction Azure :

• Utilisation des déclencheurs et liaisons intégrés Azure Functions
• Appels aux API des services Azure sous-jacents
• Appels aux points de terminaison REST
• Appels aux bibliothèques clientes, aux packages ou aux API tierces

Les bonnes pratiques de gestion des erreurs sont importantes pour éviter de perdre des données ou de manquer des messages. Cette section décrit certaines pratiques de gestion des erreurs recommandées avec des liens pour obtenir des informations supplémentaires.

Activer Application Insights

Azure Functions s’intègre à Application Insights pour collecter des données d’erreur, des données de performances et des journaux d’exécution. Vous devez utiliser Application Insights pour découvrir et mieux comprendre les erreurs qui se produisent dans vos exécutions de fonction. Pour en savoir plus, consultez Surveiller l’exécution des fonctions Azure.

Utiliser la gestion structurée des erreurs

La capture et la journalisation des erreurs sont essentielles pour superviser l’intégrité de votre application. Le niveau le plus élevé de tout code de fonction doit inclure un bloc try/catch. Dans le bloc catch, vous pouvez capturer et journaliser les erreurs. Pour plus d’informations sur les erreurs susceptibles d’être déclenchées par des liaisons, consultez Codes d’erreur de liaison.

Planifier votre stratégie de nouvelles tentatives

Plusieurs extensions de liaisons Functions fournissent une prise en charge intégrée des nouvelles tentatives. De plus, le runtime vous permet de définir des stratégies de nouvelles tentatives pour les fonctions déclenchées par Timer, Kafka et Event Hubs. Pour plus d’informations, consultez Nouvelles tentatives. Pour les déclencheurs sans comportements de nouvelle tentative, vous pouvez implémenter votre propre schéma de nouvelle tentative.

Concevoir en ayant en vue l’idempotence

L’occurrence d’erreurs lors du traitement des données peut être problématique pour vos fonctions, en particulier lors du traitement des messages. Il est important de prendre en compte ce qui se passe quand l’erreur se produit et d’éviter le traitement en double. Pour plus d'informations, consultez Conception d’Azure Functions pour une entrée identique.

Nouvelle tentatives

Deux types de nouvelles tentatives sont disponibles pour vos fonctions :

• Comportements de nouvelle tentative intégrés d’extensions de déclencheur individuelles
• Stratégies relatives aux nouvelles tentatives fournies par le runtime Functions

Le tableau suivant indique quels déclencheurs prennent en charge les nouvelles tentatives et où le comportement de nouvelle tentative est configuré. Il fournit également des liens pour obtenir des informations supplémentaires sur les erreurs provenant des services sous-jacents.

Déclencheur/liaison	Source de nouvelle tentative	Configuration
Azure Cosmos DB	Stratégies de nouvelle tentative	Au niveau de la fonction
Stockage Blob Azure	Extension de liaison	host.json
Azure Event Grid	Extension de liaison	Abonnement à un événement
Hubs d'événements Azure	Stratégies de nouvelle tentative	Au niveau de la fonction
Stockage File d’attente Azure	Extension de liaison	host.json
RabbitMQ	Extension de liaison	File d’attente de lettres mortes
Azure Service Bus	Extension de liaison	File d’attente de lettres mortes
Minuterie	Stratégies de nouvelle tentative	Au niveau de la fonction
Kafka	Stratégies de nouvelle tentative	Au niveau de la fonction

Stratégies de nouvelle tentative

À compter de la version 3.x du runtime Azure Functions, vous pouvez définir des stratégies de nouvelles tentatives pour les déclencheurs Timer, Kafka, Event Hubs et Azure Cosmos DB appliqués par le runtime Functions.

La stratégie de nouvelles tentatives indique au runtime de réexécuter une exécution ayant échoué jusqu’à ce que l’achèvement réussi se produise ou que le nombre maximal de nouvelles tentatives soit atteint.

Une stratégie de nouvelles tentatives est évaluée quand une fonction déclenchée par Timer, Kafka, Event Hubs ou Azure Cosmos DB lève une exception non interceptée. Il est recommandé d’intercepter toutes les exceptions dans votre code et de regénérer toute erreur susceptible d’entraîner une nouvelle tentative.

Important

Les points de contrôle Event Hubs sont écrits uniquement une fois que la stratégie de nouvelles tentatives de l’exécution est terminée. En raison de ce comportement, la progression sur la partition spécifique est suspendue jusqu’à ce que le lot actuel soit terminé.

L’extension Event Hubs v5 prend en charge des fonctionnalités de nouvelles tentatives pour les interactions entre l’hôte Functions et le hub d’événements. Pour plus d’informations, veuillez vous reporter à la clientRetryOptionssection Event Hubs du fichier host.json .

Stratégie de nouvelle tentative

Vous pouvez configurer deux stratégies de nouvelles tentatives prises en charge par la stratégie :

Délai fixe

Un laps de temps spécifié est autorisé à s’écouler entre chaque nouvelle tentative.

Backoff exponentiel

La première nouvelle tentative attend le délai minimal. Lors des nouvelles tentatives suivantes, le laps de temps est ajouté de manière exponentielle à la durée initiale de chaque nouvelle tentative jusqu’à ce que le délai maximal soit atteint. Le back-off exponentiel ajoute une faible randomisation aux délais pour échelonner les nouvelles tentatives dans les scénarios à débit élevé.

Nombre maximal de nouvelles tentatives

Vous pouvez configurer le nombre maximal de nouvelles tentatives d’exécution de fonction avant un éventuel échec. Le nombre actuel de nouvelles tentatives est stocké dans la mémoire de l’instance.

Il est possible qu’un échec d’instance se produise entre deux nouvelles tentatives. Quand une instance échoue durant une stratégie de nouvelles tentatives, le nombre de nouvelles tentatives est perdu. En cas d’échec d’instance, le déclencheur Event Hubs peut reprendre le traitement et retenter le lot sur une nouvelle instance, le nombre de nouvelles tentatives étant réinitialisé à zéro. Le déclencheur de minuteur ne reprend pas sur une nouvelle instance.

Ce comportement signifie que le nombre maximal de nouvelles tentatives correspond à l’effort optimal. Dans certains cas rares, le nombre de nouvelles tentatives d’exécution peut dépasser le nombre maximal demandé. Pour les déclencheurs de retardateur, les nouvelles tentatives peuvent être inférieures au nombre maximal demandé.

Exemples de nouvelle tentative

Modèle de worker isolé

Les nouvelles tentatives au niveau de la fonction sont prises en charge avec les packages NuGet suivants :

• Microsoft.Azure.Functions.Worker.Sdk>= 1.9.0
• Microsoft.Azure.Functions.Worker.Extensions.EventHubs>= 5.2.0
• Microsoft.Azure.Functions.Worker.Extensions.Kafka>= 3.8.0
• Microsoft.Azure.Functions.Worker.Extensions.Timer>= 4.2.0

[Function(nameof(TimerFunction))]
[FixedDelayRetry(5, "00:00:10")]
public static void Run([TimerTrigger("0 */5 * * * *")] TimerInfo timerInfo,
    FunctionContext context)
{
    var logger = context.GetLogger(nameof(TimerFunction));
    logger.LogInformation($"Function Ran. Next timer schedule = {timerInfo.ScheduleStatus.Next}");
}

Propriété	Description
MaxRetryCount	Obligatoire. Nombre maximal de nouvelles tentatives autorisées par exécution de fonction. -1 signifie qu’il faut effectuer ces nouvelles tentatives indéfiniment.
DelayInterval	Délai utilisé entre les nouvelles tentatives. Spécifiez-le sous forme de chaîne au format HH:mm:ss.

Modèle in-process

Les nouvelles tentatives nécessitent un package 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)
{
// ...
}

Propriété	Description
MaxRetryCount	Obligatoire. Nombre maximal de nouvelles tentatives autorisées par exécution de fonction. -1 signifie qu’il faut effectuer ces nouvelles tentatives indéfiniment.
DelayInterval	Délai utilisé entre les nouvelles tentatives. Spécifiez-le sous forme de chaîne au format HH:mm:ss.

Modèle de worker isolé

Les nouvelles tentatives au niveau de la fonction sont prises en charge avec les packages NuGet suivants :

• Microsoft.Azure.Functions.Worker.Sdk>= 1.9.0
• Microsoft.Azure.Functions.Worker.Extensions.EventHubs>= 5.2.0
• Microsoft.Azure.Functions.Worker.Extensions.Kafka>= 3.8.0
• Microsoft.Azure.Functions.Worker.Extensions.Timer>= 4.2.0

[Function(nameof(CosmosDBFunction))]
[ExponentialBackoffRetry(5, "00:00:04", "00:15:00")]
[CosmosDBOutput("%CosmosDb%", "%CosmosContainerOut%", Connection = "CosmosDBConnection", CreateIfNotExists = true)]
public object Run(
    [CosmosDBTrigger(
        "%CosmosDb%",
        "%CosmosContainerIn%",
        Connection = "CosmosDBConnection",
        LeaseContainerName = "leases",
        CreateLeaseContainerIfNotExists = true)] IReadOnlyList<MyDocument> input,
    FunctionContext context)
{
    if (input != null && input.Any())
    {
        foreach (var doc in input)
        {
            _logger.LogInformation("Doc Id: {id}", doc.Id);
        }

        // Cosmos Output
        return input.Select(p => new { id = p.Id });
    }

    return null;
}

Modèle in-process

Les nouvelles tentatives nécessitent un package NuGet Microsoft.Azure.WebJobs>= 3.0.23

[FunctionName("EventHubTrigger")]
[ExponentialBackoffRetry(5, "00:00:04", "00:15:00")]
public static async Task Run([EventHubTrigger("myHub", Connection = "EventHubConnection")] EventData[] events, ILogger log)
{
// ...
}

Propriété	Description
MaxRetryCount	Obligatoire. Nombre maximal de nouvelles tentatives autorisées par exécution de fonction. -1 signifie qu’il faut effectuer ces nouvelles tentatives indéfiniment.
MinimumInterval	Le retard de nouvelle tentative minimum. Spécifiez-le sous forme de chaîne au format HH:mm:ss.
MaximumInterval	Le retard de nouvelle tentative maximum. Spécifiez-le sous forme de chaîne au format HH:mm:ss.

Voici la stratégie de nouvelles tentatives dans le fichier function.json :

Délai fixe

{
    "disabled": false,
    "bindings": [
        {
            ....
        }
    ],
    "retry": {
        "strategy": "fixedDelay",
        "maxRetryCount": 4,
        "delayInterval": "00:00:10"
    }
}

Backoff exponentiel

{
    "disabled": false,
    "bindings": [
        {
            ....
        }
    ],
    "retry": {
        "strategy": "exponentialBackoff",
        "maxRetryCount": 5,
        "minimumInterval": "00:00:10",
        "maximumInterval": "00:15:00"
    }
}

Propriété function.json	Description
stratégie	Obligatoire. Stratégie de nouvelle tentative à utiliser. Les valeurs valides sont fixedDelay ou exponentialBackoff.
maxRetryCount	Obligatoire. Nombre maximal de nouvelles tentatives autorisées par exécution de fonction. -1 signifie qu’il faut effectuer ces nouvelles tentatives indéfiniment.
delayInterval	Délai utilisé entre les nouvelles tentatives quand vous utilisez une stratégie fixedDelay. Spécifiez-le sous forme de chaîne au format HH:mm:ss.
minimumInterval	Délai minimal de nouvelle tentative quand vous utilisez une stratégie exponentialBackoff. Spécifiez-le sous forme de chaîne au format HH:mm:ss.
maximumInterval	Délai maximal de nouvelle tentative quand vous utilisez une stratégie exponentialBackoff. Spécifiez-le sous forme de chaîne au format HH:mm:ss.

Voici un exemple Python utilisant le contexte de nouvelle tentative dans une fonction :

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")

Délai fixe

@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());
}

Backoff exponentiel

@FunctionName("TimerTriggerJava1")
@ExponentialBackoffRetry(maxRetryCount = 5 , maximumInterval = "00:15:00", minimumInterval = "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());
}

Élément	Description
maxRetryCount	Obligatoire. Nombre maximal de nouvelles tentatives autorisées par exécution de fonction. -1 signifie qu’il faut effectuer ces nouvelles tentatives indéfiniment.
delayInterval	Délai utilisé entre les nouvelles tentatives quand vous utilisez une stratégie fixedDelay. Spécifiez-le sous forme de chaîne au format HH:mm:ss.
minimumInterval	Délai minimal de nouvelle tentative quand vous utilisez une stratégie exponentialBackoff. Spécifiez-le sous forme de chaîne au format HH:mm:ss.
maximumInterval	Délai maximal de nouvelle tentative quand vous utilisez une stratégie exponentialBackoff. Spécifiez-le sous forme de chaîne au format HH:mm:ss.

Codes d’erreur de liaison

Lors de l’intégration aux services Azure, vous pouvez rencontrer des erreurs provenant des API des services sous-jacents. Les informations relatives aux erreurs spécifiques à la liaison sont disponibles dans les sections « Exceptions et codes de retour » des articles suivants :

• Azure Cosmos DB
• Stockage Blob
• Event Grid
• Hubs d'événements
• IoT Hub
• Notification Hubs
• Stockage de files d’attente
• Service Bus
• Stockage Table

Étapes suivantes

• Concepts des déclencheurs et liaisons Azure Functions
• Meilleures pratiques pour des fonctions Azure fiables