Zpracování chyb a opakování ve službě Azure Functions

Zpracování chyb ve službě Azure Functions je důležité, abyste se vyhnuli ztraceným datům, vyhnuli se zmeškaným událostem a monitorovali stav vaší aplikace. Je to také důležitý způsob, jak pochopit chování opakování triggerů založených na událostech.

Tento článek popisuje obecné strategie pro zpracování chyb a dostupné strategie opakování.

Důležité

Podpora zásad opakování ve verzi Preview pro určité triggery byla odebrána v prosinci 2022. Zásady opakování pro podporované triggery jsou teď obecně dostupné (GA). Seznam rozšíření, která aktuálně podporují zásady opakování, najdete v části Opakování .

Zpracování chyb

Chyby, ke kterým dochází ve funkci Azure, mohou pocházet z:

  • Použití integrovaných triggerů a vazeb functions
  • Volání rozhraní API základních služeb Azure
  • Volání koncových bodů REST
  • Volání klientských knihoven, balíčků nebo rozhraní API třetích stran

Abyste se vyhnuli ztrátě dat nebo zmeškaných zpráv, je důležité vyzkoušet správné zpracování chyb. Tato tabulka popisuje některé doporučené postupy zpracování chyb a obsahuje odkazy na další informace.

Doporučení Detaily
Povolit Application Insights Azure Functions se integruje s aplikačními Přehledy za účelem shromažďování dat o chybách, dat o výkonu a protokolů modulu runtime. K zjišťování a lepšímu porozumění chybám, ke kterým dochází při provádění funkce, byste měli použít Přehledy aplikace. Další informace najdete v tématu Monitorování azure Functions.
Použití strukturovaného zpracování chyb Zachytávání a protokolování chyb je důležité pro monitorování stavu vaší aplikace. Nejvyšší úroveň kódu funkce by měla obsahovat blok try/catch. V bloku catch můžete zachytit a protokolovat chyby. Informace o chybách, které mohou být vyvolány vazbami, naleznete v tématu Kódy chyb vazby. V závislosti na konkrétní strategii opakování můžete také vyvolat novou výjimku pro opětovné spuštění funkce.
Plánování strategie opakování Několik rozšíření vazeb Functions poskytují integrovanou podporu opakování a další umožňují definovat zásady opakování, které jsou implementované modulem runtime služby Functions. U triggerů, které neposkytují chování opakování, byste měli zvážit implementaci vlastního schématu opakování. Další informace najdete v tématu Opakování.
Návrh pro idempotenci Výskyt chyb při zpracování dat může být pro vaše funkce problém, zejména při zpracování zpráv. Je důležité zvážit, co se stane, když dojde k chybě a jak se vyhnout duplicitnímu zpracování. Další informace najdete v tématu Návrh služby Azure Functions pro stejný vstup.

Opakování

Pro vaše funkce jsou k dispozici dva druhy opakování:

  • Předdefinované chování opakování jednotlivých rozšíření triggerů
  • Zásady opakování poskytované modulem runtime Služby Functions

Následující tabulka uvádí, které triggery podporují opakování a kde je nakonfigurované chování opakování. Odkazuje také na další informace o chybách, které pocházejí z podkladových služeb.

Aktivační událost nebo vazba Zdroj opakování Konfigurace
Azure Cosmos DB Zásady opakování Úroveň funkce
Blob Storage Rozšíření vazby host.json
Event Grid Rozšíření vazby Předplatné události
Event Hubs Zásady opakování Úroveň funkce
Kafka Zásady opakování Úroveň funkce
Queue Storage Rozšíření vazby host.json
RabbitMQ Rozšíření vazby Fronta nedoručených zpráv
Service Bus Rozšíření vazby host.json*
Časovač Zásady opakování Úroveň funkce

*Vyžaduje verzi 5.x rozšíření Azure Service Bus. Ve starších verzích rozšíření se chování opakování implementuje frontou nedoručených zpráv služby Service Bus.

Zásady opakování pokusů

Azure Functions umožňuje definovat zásady opakování pro konkrétní typy triggerů, které jsou vynuceny modulem runtime. Tyto typy triggerů aktuálně podporují zásady opakování:

Podpora opakování je stejná pro programovací modely v1 i v2 Pythonu.

Zásady opakování nejsou podporovány ve verzi 1.x modulu runtime Služby Functions.

Zásada opakování říká modulu runtime, aby znovu spustil neúspěšné spuštění, dokud nedojde k úspěšnému dokončení, nebo se dosáhne maximálního počtu opakování.

Zásada opakování se vyhodnotí, když funkce spuštěná podporovaným typem triggeru vyvolá nezachycenou výjimku. Osvědčeným postupem je zachytit všechny výjimky v kódu a vyvolat nové výjimky pro všechny chyby, které chcete mít za následek opakování.

Důležité

Kontrolní body služby Event Hubs se nezapisují, dokud se nedokončí zásady opakování spuštění. Kvůli tomuto chování je průběh konkrétního oddílu pozastaven, dokud aktuální dávka neprovede zpracování.

Verze 5.x rozšíření Event Hubs podporuje další možnosti opakování pro interakce mezi hostitelem služby Functions a centrem událostí. Další informace najdete clientRetryOptions v referenčních informacích ke službě Event Hubs host.json.

Strategie opakování

Můžete nakonfigurovat dvě strategie opakování, které jsou podporovány zásadami:

Mezi jednotlivými opakováními je povoleno uplynulo určité množství času.

Při spuštění v plánu Consumption se vám účtuje jenom čas, kdy se kód funkce spouští. V některé z těchto strategií opakování se vám neúčtuje doba čekání mezi spuštěními.

Maximální počet opakování

Můžete nakonfigurovat maximální počet opakování spuštění funkce před případným selháním. Aktuální počet opakování je uložen v paměti instance.

Instance může mít chybu mezi opakovanými pokusy. Pokud instance selže během zásady opakování, počet opakování se ztratí. Pokud dojde k selháním instance, trigger Event Hubs dokáže obnovit zpracování a opakovat dávku v nové instanci s resetováním počtu opakování na nulu. Trigger časovače se v nové instanci neobnoví.

Toto chování znamená, že maximální počet opakování je nejlepším úsilím. V některých výjimečných případech může být provedení opakovat více než požadovaný maximální počet opakování. U aktivačních událostí časovače může být opakování menší než maximální požadovaný počet.

Příklady opakování

Příklady jsou k dispozici pro strategie pevného zpoždění i exponenciálního zpožďování. Pokud chcete zobrazit příklady pro konkrétní strategii, musíte nejprve tuto strategii vybrat na předchozí kartě.

Opakování na úrovni funkce se podporuje s následujícími balíčky NuGet:

[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}");
}
Vlastnost Popis
MaxRetryCount Povinný: Maximální počet opakování povolených pro každé spuštění funkce. -1 znamená opakování po neomezenou dobu.
DelayInterval Zpoždění použité mezi opakovanými pokusy. Zadejte ho jako řetězec s formátem HH:mm:ss.

Tady je příklad zásady opakování definované v souboru function.json :

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

U definic zásad opakování můžete nastavit tyto vlastnosti:

Vlastnost Popis
Strategie Povinný: Používaná strategie opakování. Platné hodnoty jsou fixedDelay nebo exponentialBackoff.
maxRetryCount Povinný: Maximální počet opakování povolených pro každé spuštění funkce. -1 znamená opakování po neomezenou dobu.
delayInterval Zpoždění použité mezi opakovanými pokusy při použití fixedDelay strategie. Zadejte ho jako řetězec s formátem HH:mm:ss.
minimumInterval Minimální prodleva opakování při použití exponentialBackoff strategie. Zadejte ho jako řetězec s formátem HH:mm:ss.
maximumInterval Maximální prodleva opakování při použití exponentialBackoff strategie. Zadejte ho jako řetězec s formátem HH:mm:ss.

Způsob, jakým definujete zásady opakování triggeru, závisí na vaší verzi Node.js.

Tady je příklad funkce triggeru časovače, která používá strategii opakování s pevným zpožděním:

const { app } = require('@azure/functions');

app.timer('timerTriggerWithRetry', {
    schedule: '0 */5 * * * *',
    retry: {
        strategy: 'fixedDelay',
        delayInterval: {
            seconds: 10,
        },
        maxRetryCount: 4,
    },
    handler: (myTimer, context) => {
        if (context.retryContext?.retryCount < 2) {
            throw new Error('Retry!');
        } else {
            context.log('Timer function processed request.');
        }
    },
});

Způsob, jakým definujete zásady opakování triggeru, závisí na vaší verzi Node.js.

Tady je příklad funkce triggeru časovače, která používá strategii opakování s pevným zpožděním:

import { app, InvocationContext, Timer } from '@azure/functions';

export async function timerTriggerWithRetry(myTimer: Timer, context: InvocationContext): Promise<void> {
    if (context.retryContext?.retryCount < 2) {
        throw new Error('Retry!');
    } else {
        context.log('Timer function processed request.');
    }
}

app.timer('timerTriggerWithRetry', {
    schedule: '0 */5 * * * *',
    retry: {
        strategy: 'fixedDelay',
        delayInterval: {
            seconds: 10,
        },
        maxRetryCount: 4,
    },
    handler: timerTriggerWithRetry,
});

U definic zásad opakování můžete nastavit tyto vlastnosti:

Vlastnost Popis
Strategie Povinný: Používaná strategie opakování. Platné hodnoty jsou fixedDelay nebo exponentialBackoff.
maxRetryCount Povinný: Maximální počet opakování povolených pro každé spuštění funkce. -1 znamená opakování po neomezenou dobu.
delayInterval Zpoždění použité mezi opakovanými pokusy při použití fixedDelay strategie. Zadejte ho jako řetězec s formátem HH:mm:ss.
minimumInterval Minimální prodleva opakování při použití exponentialBackoff strategie. Zadejte ho jako řetězec s formátem HH:mm:ss.
maximumInterval Maximální prodleva opakování při použití exponentialBackoff strategie. Zadejte ho jako řetězec s formátem HH:mm:ss.

Tady je příklad funkce triggeru časovače, která používá strategii opakování s pevným zpožděním:

from azure.functions import FunctionApp, TimerRequest, Context, AuthLevel
import logging

app = FunctionApp(http_auth_level=AuthLevel.ANONYMOUS)


@app.timer_trigger(schedule="*/1 * * * * *", arg_name="mytimer",
                   run_on_startup=False,
                   use_monitor=False)
@app.retry(strategy="fixed_delay", max_retry_count="3",
           delay_interval="00:00:01")
def mytimer(mytimer: TimerRequest, context: 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.info(
            f"Max retries of {context.retry_context.max_retry_count} for "
            f"function {context.function_name} has been reached")
    else:
        raise Exception("This is a retryable exception")

U definic zásad opakování můžete nastavit tyto vlastnosti:

Vlastnost Popis
Strategie Povinný: Používaná strategie opakování. Platné hodnoty jsou fixed_delay nebo exponential_backoff.
max_retry_count Povinný: Maximální počet opakování povolených pro každé spuštění funkce. -1 znamená opakování po neomezenou dobu.
delay_interval Zpoždění použité mezi opakovanými pokusy při použití fixed_delay strategie. Zadejte ho jako řetězec s formátem HH:mm:ss.
minimum_interval Minimální prodleva opakování při použití exponential_backoff strategie. Zadejte ho jako řetězec s formátem HH:mm:ss.
maximum_interval Maximální prodleva opakování při použití exponential_backoff strategie. Zadejte ho jako řetězec s formátem HH:mm:ss.
@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());
}

Kódy chyb vazeb

Při integraci se službami Azure můžou chyby pocházet z rozhraní API základních služeb. Informace týkající se chyb specifických pro vazby jsou k dispozici v částech Výjimky a návratové kódy v následujících článcích:

Další kroky