Condividi tramite

Gestione degli errori di Funzioni di Azure e tentativi

  • Articolo

La gestione degli errori in Funzioni di Azure è importante per evitare perdite di dati, evitare eventi mancanti e monitorare l'integrità dell'applicazione. È anche un modo importante per comprendere i comportamenti di ripetizione dei tentativi dei trigger basati su eventi.

Questo articolo descrive le strategie generali per la gestione degli errori e le strategie di ripetizione dei tentativi disponibili.

Importante

Il supporto dei criteri di ripetizione dei tentativi di anteprima per determinati trigger è stato rimosso nel dicembre 2022. I criteri di ripetizione dei tentativi per i trigger supportati sono ora disponibili a livello generale. Per un elenco delle estensioni che attualmente supportano i criteri di ripetizione dei tentativi, vedere la sezione Tentativi .

Gestione degli errori

Gli errori che si verificano in una funzione di Azure possono provenire da:

  • Uso di trigger e associazioni predefiniti di Funzioni.
  • Chiamate alle API dei servizi di Azure sottostanti.
  • Chiamate agli endpoint REST.
  • Chiamate a librerie client, pacchetti o API di terze parti.

Per evitare la perdita di dati o messaggi persi, è importante eseguire una corretta gestione degli errori. Questa tabella descrive alcune procedure consigliate per la gestione degli errori e fornisce collegamenti ad altre informazioni.

Elemento consigliato Dettagli
Abilita Application Insights Funzioni di Azure si integra con Application Insights per raccogliere dati sugli errori, dati sulle prestazioni e log di runtime. È consigliabile usare Application Insights per individuare e comprendere meglio gli errori che si verificano nelle esecuzioni delle funzioni. Per altre informazioni, vedere Monitorare Funzioni di Azure.
Usare la gestione degli errori strutturati L'acquisizione e la registrazione degli errori è fondamentale per monitorare l'integrità dell'applicazione. Il livello più alto di qualsiasi codice di funzione deve includere un blocco try/catch. Nel blocco catch è possibile acquisire e registrare gli errori. Per informazioni sugli errori che possono essere generati dalle associazioni, vedere Binding error codes .For information about what errors might be generate by binding binding error codes, see Binding error codes. A seconda della strategia di ripetizione dei tentativi specifica, è anche possibile generare una nuova eccezione per eseguire di nuovo la funzione.
Pianificare la strategia di ripetizione dei tentativi Diverse estensioni delle associazioni di Funzioni offrono il supporto predefinito per i tentativi e altri consentono di definire criteri di ripetizione dei tentativi, implementati dal runtime di Funzioni. Per i trigger che non forniscono comportamenti di ripetizione dei tentativi, è consigliabile implementare uno schema di ripetizione dei tentativi. Per altre informazioni, vedere Tentativi.
Progettare per idempotency L'occorrenza di errori durante l'elaborazione dei dati può essere un problema per le funzioni, soprattutto quando si elaborano messaggi. È importante considerare cosa accade quando si verifica l'errore e come evitare l'elaborazione duplicata. Per altre informazioni, vedere Progettazione di Funzioni di Azure per un input identico.

Nuovi tentativi

Per le funzioni sono disponibili due tipi di tentativi:

  • Comportamenti di ripetizione dei tentativi predefiniti delle singole estensioni di trigger
  • Criteri di ripetizione dei tentativi forniti dal runtime di Funzioni

La tabella seguente indica quali trigger supportano i tentativi e dove è configurato il comportamento di ripetizione dei tentativi. Sono inoltre disponibili collegamenti ad altre informazioni sugli errori provenienti dai servizi sottostanti.

Trigger/binding Riprovare l'origine Impostazione
Azure Cosmos DB Criteri di ripetizione dei tentativi Livello di funzione
Archiviazione BLOB Estensione dell'associazione host.json
Griglia di eventi Estensione dell'associazione Sottoscrizione evento
Hub eventi Criteri di ripetizione dei tentativi Livello di funzione
Kafka Criteri di ripetizione dei tentativi Livello di funzione
Archiviazione code Estensione dell'associazione host.json
RabbitMQ Estensione dell'associazione Coda di messaggi non recapitabili
Bus di servizio Estensione dell'associazione host.json*
Timer Criteri di ripetizione dei tentativi Livello di funzione

*Richiede la versione 5.x dell'estensione bus di servizio di Azure. Nelle versioni precedenti dell'estensione, i comportamenti di ripetizione dei tentativi vengono implementati dalla coda di messaggi non recapitabili bus di servizio.

Criteri di ripetizione dei tentativi

Funzioni di Azure consente di definire criteri di ripetizione dei tentativi per tipi di trigger specifici, che vengono applicati dal runtime. Questi tipi di trigger supportano attualmente i criteri di ripetizione dei tentativi:

Il supporto di ripetizione dei tentativi è lo stesso per i modelli di programmazione Python v1 e v2.

I criteri di ripetizione dei tentativi non sono supportati nella versione 1.x del runtime di Funzioni.

Il criterio di ripetizione dei tentativi indica al runtime di eseguire di nuovo un'esecuzione non riuscita fino a quando non si verifica il completamento corretto o viene raggiunto il numero massimo di tentativi.

Un criterio di ripetizione dei tentativi viene valutato quando una funzione eseguita da un tipo di trigger supportato genera un'eccezione non rilevata. Come procedura consigliata, è consigliabile intercettare tutte le eccezioni nel codice e generare nuove eccezioni per eventuali errori che si desidera generare un nuovo tentativo.

Importante

I checkpoint di Hub eventi non vengono scritti fino al completamento dei criteri di ripetizione dei tentativi per l'esecuzione. A causa di questo comportamento, lo stato di avanzamento nella partizione specifica viene sospeso fino a quando il batch corrente non viene completato l'elaborazione.

La versione 5.x dell'estensione Hub eventi supporta funzionalità di ripetizione dei tentativi aggiuntive per le interazioni tra l'host funzioni e l'hub eventi. Per altre informazioni, vedere clientRetryOptions le informazioni di riferimento sull'host.json di Hub eventi.

Strategie di ripetizione dei tentativi

È possibile configurare due strategie di ripetizione dei tentativi supportate dai criteri:

È consentito un intervallo di tempo specificato tra ogni tentativo.

Quando si esegue in un piano a consumo, viene addebitato solo il tempo in cui il codice della funzione è in esecuzione. Non viene addebitato il tempo di attesa tra le esecuzioni in una di queste strategie di ripetizione dei tentativi.

Numero massimo di tentativi

È possibile configurare il numero massimo di tentativi di esecuzione di una funzione prima dell'eventuale errore. Il conteggio dei tentativi corrente viene archiviato in memoria dell'istanza di .

È possibile che un'istanza abbia un errore tra i tentativi di ripetizione. Quando un'istanza ha esito negativo durante un criterio di ripetizione dei tentativi, il numero di tentativi viene perso. In caso di errori di istanza, il trigger di Hub eventi è in grado di riprendere l'elaborazione e ripetere l'elaborazione in una nuova istanza, con il numero di tentativi reimpostato su zero. Il trigger timer non riprende in una nuova istanza.

Questo comportamento indica che il numero massimo di tentativi è un'operazione ottimale. In alcuni rari casi, un'esecuzione potrebbe essere ritentata più del numero massimo di volte richiesto. Per i trigger timer, i tentativi possono essere inferiori al numero massimo richiesto.

Esempi di ripetizione dei tentativi

Sono disponibili esempi per strategie di backoff sia a ritardo fisso che esponenziale. Per visualizzare esempi per una strategia specifica, è prima necessario selezionare tale strategia nella scheda precedente.

I tentativi a livello di funzione sono supportati con i pacchetti NuGet seguenti:

[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}");
}
Proprietà Descrizione
MaxRetryCount Obbligatorio. Numero massimo di tentativi consentiti per ogni esecuzione di funzione. -1 significa riprovare per un periodo illimitato.
DelayInterval Ritardo utilizzato tra tentativi. Specificarlo come stringa con il formato HH:mm:ss.

Ecco un esempio di criteri di ripetizione dei tentativi definiti nel file function.json :

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

È possibile impostare queste proprietà nelle definizioni dei criteri di ripetizione dei tentativi:

Proprietà Descrizione
aziendale Obbligatorio. La strategia di ripetizione dei tentativi da usare. I valori validi sono fixedDelay o exponentialBackoff.
maxRetryCount Obbligatorio. Numero massimo di tentativi consentiti per ogni esecuzione di funzione. -1 significa riprovare per un periodo illimitato.
delayInterval Ritardo usato tra i tentativi quando si usa una fixedDelay strategia. Specificarlo come stringa con il formato HH:mm:ss.
minimumInterval Ritardo minimo dei tentativi quando si usa una exponentialBackoff strategia. Specificarlo come stringa con il formato HH:mm:ss.
maximumInterval Ritardo massimo dei tentativi quando si usa exponentialBackoff la strategia. Specificarlo come stringa con il formato HH:mm:ss.

Il modo in cui si definiscono i criteri di ripetizione dei tentativi per il trigger dipende dalla versione Node.js.

Di seguito è riportato un esempio di funzione trigger Timer che usa una strategia di ripetizione dei tentativi a ritardo fisso:

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.');
        }
    },
});

Il modo in cui si definiscono i criteri di ripetizione dei tentativi per il trigger dipende dalla versione Node.js.

Di seguito è riportato un esempio di funzione trigger Timer che usa una strategia di ripetizione dei tentativi a ritardo fisso:

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,
});

È possibile impostare queste proprietà nelle definizioni dei criteri di ripetizione dei tentativi:

Proprietà Descrizione
aziendale Obbligatorio. La strategia di ripetizione dei tentativi da usare. I valori validi sono fixedDelay o exponentialBackoff.
maxRetryCount Obbligatorio. Numero massimo di tentativi consentiti per ogni esecuzione di funzione. -1 significa riprovare per un periodo illimitato.
delayInterval Ritardo usato tra i tentativi quando si usa una fixedDelay strategia. Specificarlo come stringa con il formato HH:mm:ss.
minimumInterval Ritardo minimo dei tentativi quando si usa una exponentialBackoff strategia. Specificarlo come stringa con il formato HH:mm:ss.
maximumInterval Ritardo massimo dei tentativi quando si usa exponentialBackoff la strategia. Specificarlo come stringa con il formato HH:mm:ss.

Di seguito è riportato un esempio di funzione trigger Timer che usa una strategia di ripetizione dei tentativi a ritardo fisso:

import logging

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

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

È possibile impostare queste proprietà nelle definizioni dei criteri di ripetizione dei tentativi:

Proprietà Descrizione
aziendale Obbligatorio. La strategia di ripetizione dei tentativi da usare. I valori validi sono fixed_delay o exponential_backoff.
max_retry_count Obbligatorio. Numero massimo di tentativi consentiti per ogni esecuzione di funzione. -1 significa riprovare per un periodo illimitato.
delay_interval Ritardo usato tra i tentativi quando si usa una fixed_delay strategia. Specificarlo come stringa con il formato HH:mm:ss.
minimum_interval Ritardo minimo dei tentativi quando si usa una exponential_backoff strategia. Specificarlo come stringa con il formato HH:mm:ss.
maximum_interval Ritardo massimo dei tentativi quando si usa exponential_backoff la strategia. Specificarlo come stringa con il formato 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());
}

Codici degli errori di associazione

Quando si esegue l'integrazione con i servizi di Azure, gli errori potrebbero provenire dalle API dei servizi sottostanti. Le informazioni correlate agli errori specifici dell'associazione sono disponibili nelle sezioni "Eccezioni e codici restituiti" degli articoli seguenti:

Passaggi successivi