Obsługa błędów oraz wykonywanie ponownych prób w usłudze Azure Functions

Obsługa błędów w usłudze Azure Functions jest ważna, aby uniknąć utraconych danych, uniknąć pominiętych zdarzeń i monitorować kondycję aplikacji. Jest to również ważny sposób, aby ułatwić zrozumienie zachowań ponawiania prób wyzwalaczy opartych na zdarzeniach.

W tym artykule opisano ogólne strategie obsługi błędów i dostępne strategie ponawiania prób.

Ważne

Usuwamy obsługę zasad ponawiania prób w środowisku uruchomieniowym dla wyzwalaczy innych niż Czasomierz, Kafka i Event Hubs po tym, jak ta funkcja stanie się ogólnie dostępna . Obsługa zasad ponawiania prób w wersji zapoznawczej dla wszystkich wyzwalaczy innych niż czasomierz i usługa Event Hubs została usunięta w grudniu 2022 r. Aby uzyskać więcej informacji, zobacz sekcję Ponowne próby .

Obsługa błędów

Błędy występujące w funkcji platformy Azure mogą wynikać z dowolnego z następujących elementów:

• Korzystanie z wbudowanych wyzwalaczy i powiązań usługi Azure Functions
• Wywołania do interfejsów API bazowych usług platformy Azure
• Wywołania do punktów końcowych REST
• Wywołania bibliotek klienckich, pakietów lub interfejsów API innych firm

Aby uniknąć utraty danych lub nieodebranych komunikatów, ważne jest, aby przećwiczyć dobrą obsługę błędów. W tej sekcji opisano niektóre zalecane rozwiązania dotyczące obsługi błędów i podano linki do dodatkowych informacji.

Włącz usługę Application Insights

Usługa Azure Functions integruje się z usługą Application Szczegółowe informacje w celu zbierania danych o błędach, danych wydajności i dzienników środowiska uruchomieniowego. Aby odnaleźć i lepiej zrozumieć błędy występujące w wykonywaniach funkcji, należy użyć Szczegółowe informacje Aplikacji. Aby dowiedzieć się więcej, zobacz Monitorowanie usługi Azure Functions.

Korzystanie z obsługi błędów ustrukturyzowanych

Przechwytywanie i rejestrowanie błędów ma kluczowe znaczenie dla monitorowania kondycji aplikacji. Najwyższy poziom dowolnego kodu funkcji powinien zawierać blok try/catch. W bloku catch można przechwytywać i rejestrować błędy. Aby uzyskać informacje o błędach, które mogą być zgłaszane przez powiązania, zobacz Binding error codes (Kody błędów powiązań).

Planowanie strategii ponawiania prób

Kilka rozszerzeń powiązań usługi Functions zapewnia wbudowaną obsługę ponownych prób. Ponadto środowisko uruchomieniowe umożliwia definiowanie zasad ponawiania prób dla funkcji wyzwalanych przez czasomierz, Kafka i Event Hubs. Aby dowiedzieć się więcej, zobacz Ponowne próby. W przypadku wyzwalaczy, które nie zapewniają zachowania ponawiania prób, warto zaimplementować własny schemat ponawiania prób.

Projektowanie pod kątem idempotentności

Występowanie błędów podczas przetwarzania danych może być problemem dla funkcji, zwłaszcza podczas przetwarzania komunikatów. Ważne jest, aby wziąć pod uwagę, co się stanie, gdy wystąpi błąd i jak uniknąć zduplikowanego przetwarzania. Aby dowiedzieć się więcej, zobacz Projektowanie usługi Azure Functions pod kątem identycznych danych wejściowych.

Ponowne próby

Istnieją dwa rodzaje ponownych prób dostępnych dla funkcji:

• Wbudowane zachowania ponawiania poszczególnych rozszerzeń wyzwalacza
• Zasady ponawiania próby udostępniane przez środowisko uruchomieniowe usługi Functions

Poniższa tabela wskazuje, które wyzwalacze obsługują ponawianie prób i gdzie skonfigurowano zachowanie ponawiania. Zawiera również linki do dodatkowych informacji o błędach pochodzących z podstawowych usług.

Wyzwalacz/powiązanie	Ponów próbę źródła	Konfigurowanie
Azure Cosmos DB	Zasady ponawiania prób	Poziom funkcji
Azure Blob Storage	Rozszerzenie powiązania	host.json
Azure Event Grid	Rozszerzenie powiązania	Identyfikator subskrypcji
Azure Event Hubs	Zasady ponawiania prób	Poziom funkcji
Azure Queue Storage	Rozszerzenie powiązania	host.json
RabbitMQ	Rozszerzenie powiązania	Kolejka utraconych listów
Azure Service Bus	Rozszerzenie powiązania	Kolejka utraconych listów
Czasomierz	Zasady ponawiania prób	Poziom funkcji
Kafka	Zasady ponawiania prób	Poziom funkcji

Zasady ponawiania prób

Począwszy od wersji 3.x środowiska uruchomieniowego usługi Azure Functions, można zdefiniować zasady ponawiania prób dla czasomierza, platformy Kafka, usługi Event Hubs i wyzwalaczy usługi Azure Cosmos DB wymuszanych przez środowisko uruchomieniowe usługi Functions.

Zasady ponawiania prób informują środowisko uruchomieniowe o ponownym uruchomieniu nieudanego wykonania do momentu pomyślnego ukończenia lub osiągnięcia maksymalnej liczby ponownych prób.

Zasady ponawiania są oceniane, gdy funkcja czasomierza, platformy Kafka, usługi Event Hubs lub wyzwalanej przez usługę Azure Cosmos DB zgłasza nieuchwycony wyjątek. Najlepszym rozwiązaniem jest przechwycenie wszystkich wyjątków w kodzie i ponowne utworzenie wszelkich błędów, które mają spowodować ponowienie próby.

Ważne

Punkty kontrolne usługi Event Hubs nie zostaną zapisane do momentu zakończenia zasad ponawiania wykonania. Ze względu na to zachowanie postęp w określonej partycji jest wstrzymany do momentu zakończenia bieżącej partii.

Rozszerzenie usługi Event Hubs w wersji 5 obsługuje dodatkowe możliwości ponawiania prób na potrzeby interakcji między hostem usługi Functions a centrum zdarzeń. Aby uzyskać więcej informacji, zapoznaj się z clientRetryOptions sekcją w usłudze Event Hubs w pliku host.json .

Strategie dotyczące ponawiania prób

Można skonfigurować dwie strategie ponawiania, które są obsługiwane przez zasady:

Stałe opóźnienie

Określony czas może upłynąć między poszczególnymi ponownymi próbami.

Wycofywanie wykładnicze

Pierwsza ponowna próba czeka na minimalne opóźnienie. W kolejnych ponownych próbach czas jest dodawany wykładniczo do początkowego czasu dla każdego ponawiania próby, aż do osiągnięcia maksymalnego opóźnienia. Wycofywanie wykładnicze dodaje niewielką losowość, aby opóźniać ponawianie prób w scenariuszach o wysokiej przepływności.

Maksymalna liczba ponownych prób

Maksymalną liczbę ponownych prób wykonania funkcji można skonfigurować przed awarią ostateczną. Bieżąca liczba ponownych prób jest przechowywana w pamięci wystąpienia.

Wystąpienie może mieć błąd między ponownymi próbami. Gdy wystąpienie nie powiedzie się podczas zasad ponawiania próby, liczba ponownych prób zostanie utracona. Jeśli wystąpią błędy wystąpień, wyzwalacz usługi Event Hubs może wznowić przetwarzanie i ponowić próbę wsadu w nowym wystąpieniu, a liczba ponownych prób zostanie zresetowana do zera. Wyzwalacz czasomierza nie jest wznawiany w nowym wystąpieniu.

To zachowanie oznacza, że maksymalna liczba ponownych prób jest najlepszym rozwiązaniem. W niektórych rzadkich przypadkach wykonanie może zostać ponowione więcej niż żądana maksymalna liczba razy. W przypadku wyzwalaczy czasomierza ponowne próby mogą być mniejsze niż maksymalna liczba żądana.

Przykłady ponawiania prób

Model izolowanego procesu roboczego

Ponawianie prób na poziomie funkcji jest obsługiwane w przypadku następujących pakietów NuGet:

• 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}");
}

Właściwości	opis
MaxRetryCount	Wymagany. Maksymalna dozwolona liczba ponownych prób na wykonanie funkcji. -1 oznacza, aby ponowić próbę na czas nieokreślony.
DelayInterval	Opóźnienie, które jest używane między ponownych prób. Określ go jako ciąg w formacie HH:mm:ss.

Model w procesie

Ponowne próby wymagają pakietu 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)
{
// ...
}

Właściwości	opis
MaxRetryCount	Wymagany. Maksymalna dozwolona liczba ponownych prób na wykonanie funkcji. -1 oznacza, aby ponowić próbę na czas nieokreślony.
DelayInterval	Opóźnienie, które jest używane między ponownych prób. Określ go jako ciąg w formacie HH:mm:ss.

Model izolowanego procesu roboczego

Ponawianie prób na poziomie funkcji jest obsługiwane w przypadku następujących pakietów NuGet:

• 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;
}

Model w procesie

Ponowne próby wymagają pakietu 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)
{
// ...
}

Właściwości	opis
MaxRetryCount	Wymagany. Maksymalna dozwolona liczba ponownych prób na wykonanie funkcji. -1 oznacza, aby ponowić próbę na czas nieokreślony.
MinimumInterval	Minimalne opóźnienie ponawiania prób. Określ go jako ciąg w formacie HH:mm:ss.
MaximumInterval	Maksymalne opóźnienie ponawiania prób. Określ go jako ciąg w formacie HH:mm:ss.

Oto zasady ponawiania w pliku function.json :

Stałe opóźnienie

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

Wycofywanie wykładnicze

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

właściwość function.json	opis
Strategii	Wymagany. Strategia ponawiania, która ma zostać użyta. Prawidłowe wartości to fixedDelay i exponentialBackoff.
maxRetryCount	Wymagany. Maksymalna dozwolona liczba ponownych prób na wykonanie funkcji. -1 oznacza, aby ponowić próbę na czas nieokreślony.
delayInterval	Opóźnienie, które jest używane między ponownymi próbami podczas korzystania ze fixedDelay strategii. Określ go jako ciąg w formacie HH:mm:ss.
minimumInterval	Minimalne opóźnienie ponawiania próby podczas korzystania ze exponentialBackoff strategii. Określ go jako ciąg w formacie HH:mm:ss.
maximumInterval	Maksymalne opóźnienie ponawiania próby podczas korzystania ze exponentialBackoff strategii. Określ go jako ciąg w formacie HH:mm:ss.

Oto przykład języka Python, który używa kontekstu ponawiania próby w funkcji:

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

Stałe opóźnienie

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

Wycofywanie wykładnicze

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

Element	opis
maxRetryCount	Wymagany. Maksymalna dozwolona liczba ponownych prób na wykonanie funkcji. -1 oznacza, aby ponowić próbę na czas nieokreślony.
delayInterval	Opóźnienie, które jest używane między ponownymi próbami podczas korzystania ze fixedDelay strategii. Określ go jako ciąg w formacie HH:mm:ss.
minimumInterval	Minimalne opóźnienie ponawiania próby podczas korzystania ze exponentialBackoff strategii. Określ go jako ciąg w formacie HH:mm:ss.
maximumInterval	Maksymalne opóźnienie ponawiania próby podczas korzystania ze exponentialBackoff strategii. Określ go jako ciąg w formacie HH:mm:ss.

Kody błędów powiązania

Podczas integracji z usługami platformy Azure błędy mogą pochodzić z interfejsów API bazowych usług. Informacje dotyczące błędów specyficznych dla powiązania są dostępne w sekcjach "Wyjątki i kody powrotne" w następujących artykułach:

• Azure Cosmos DB
• Blob Storage
• Event Grid
• Event Hubs
• IoT Hub
• Notification Hubs
• Queue Storage
• Service Bus
• Table Storage

Następne kroki

• Pojęcia powiązań i wyzwalaczy usługi Azure Functions
• Najlepsze rozwiązania dotyczące niezawodnych funkcji platformy Azure