Funzioni di Azure - gestione degli errori e dei tentativi di ripetizione

La gestione degli errori in Funzioni di Azure consente di evitare la perdita 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

L'anteprima del supporto dei criteri di ripetizione per determinati trigger è stata rimossa a dicembre 2022. I criteri di ripetizione dei tentativi per i trigger supportati sono ora disponibili a livello generale. Nella sezione Tentativi di questo articolo sono elencate le estensioni che attualmente supportano i criteri di ripetizione.

Gestione degli errori

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

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

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

Recommendation Dettagli
Abilita gli Approfondimenti sull'Applicazione Funzioni di Azure si integra con Application Insights per raccogliere dati sugli errori, dati sulle prestazioni e log di runtime. Usare Application Insights per individuare e comprendere meglio gli errori che si verificano nelle esecuzioni delle funzioni. Per altre informazioni, vedere Monitor executions in 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 superiore di qualsiasi codice di funzione deve includere un blocco try/catch. Nel blocco catch è possibile acquisire e registrare gli errori. Per informazioni su quali errori potrebbe causare il binding, consultare la sezione Codici di errore del binding in questo articolo. A seconda della strategia di ripetizione dei tentativi specifica, è anche possibile generare una nuova eccezione per eseguire di nuovo la funzione.
Pianifica la tua strategia di ritentativo Diverse estensioni di binding in Funzioni di Azure offrono un supporto predefinito per i nuovi tentativi. Altri consentono di definire criteri di ripetizione dei tentativi implementati dal runtime Funzioni di Azure. Per i trigger che non forniscono meccanismi di ripetizione, considera di implementare il tuo schema di ripetizione dei tentativi. Per altre informazioni, vedere Tentativi in questo articolo.
Progettare per l'idempotenza 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 Progettare le funzioni di Azure per input identici.

Suggerimento

Quando si usano associazioni di output, non è possibile gestire gli errori che si verificano dall'accesso al servizio remoto. A causa di questo comportamento, è consigliabile convalidare tutti i dati passati alle associazioni di output per evitare di generare eccezioni note. Se è necessario essere in grado di gestire tali eccezioni nel codice della funzione, è necessario accedere al servizio remoto usando l'SDK client anziché basarsi sulle associazioni di output.

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 di Azure

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 Configurazione
Azure Cosmos DB Criteri di ripetizione dei tentativi Livello di funzione
Archiviazione BLOB di Azure Estensione del binding host.json
Griglia di eventi di Azure Estensione del binding Sottoscrizione dell'evento
Hub eventi di Azure Criteri di ripetizione dei tentativi Livello di funzione
Kafka Criteri di ripetizione dei tentativi Livello di funzione
Archiviazione in coda di Azure Estensione del binding host.json
RabbitMQ (un servizio di messaggistica open-source) Estensione del binding Coda di messaggi non recapitabili
bus di servizio di Azure Estensione del binding host.json*
Temporizzatore 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, la coda dei messaggi non recapitabili del bus di servizio implementa i comportamenti di ripetizione dei tentativi.

Criteri di ripetizione dei tentativi

Con Funzioni di Azure è possibile definire criteri di ripetizione dei tentativi per tipi di trigger specifici. Il runtime applica questi criteri di ripetizione dei tentativi. I tipi di trigger seguenti supportano attualmente i criteri di ripetizione dei tentativi:

Il supporto per i tentativi è lo stesso per i modelli di programmazione sia v1 che v2 Python.

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

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 termine del criterio di ripetizione dei tentativi per l'esecuzione. A causa di questo comportamento, lo stato di avanzamento nella partizione specifica viene sospeso fino al termine dell'elaborazione del batch corrente. Per altre informazioni, vedere Elaborazioni di eventi affidabili con Funzioni di Azure e Hub eventi.

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

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 usa 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 numero di tentativi corrente viene archiviato nella memoria dell'istanza.

È 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 può riprendere l'elaborazione e ripetere il batch 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:

Proprietà Descrizione
MaxRetryCount Obbligatorio. Numero massimo di tentativi consentiti per ogni esecuzione di funzione. Un valore di -1 indica di riprovare per un periodo illimitato.
DelayInterval Ritardo utilizzato tra tentativi. Specificarlo come stringa con il formato HH:mm:ss.

Di seguito è riportato un esempio di criteri di ripetizione dei tentativi definiti nel function.json file:

{
    "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
strategy Obbligatorio. La strategia di ripetizione dei tentativi da usare. I valori validi sono fixedDelay e exponentialBackoff.
maxRetryCount Obbligatorio. Numero massimo di tentativi consentiti per ogni esecuzione di funzione. Un valore di -1 indica di riprovare per un periodo illimitato.
delayInterval Ritardo tra i tentativi quando si usa una strategia fixedDelay. Specificarlo come stringa con il formato HH:mm:ss.
minimumInterval Il ritardo minimo dei tentativi quando si utilizza la strategia exponentialBackoff. Specificarlo come stringa con il formato HH:mm:ss.
maximumInterval Il ritardo massimo dei tentativi quando si utilizza la strategia exponentialBackoff. 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 a ritardo fisso:

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 a ritardo fisso:

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

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

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

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

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

In Go, configura i tentativi di ripetizione quando registri la funzione usando sdk.WithRetry e sdk.RetryOptions:

minimumInterval := 10 * time.Second
maximumInterval := 15 * time.Minute

app.Timer("TimerTriggerGo", timerHandler,
    sdk.WithSchedule("0 */5 * * * *"),
    sdk.WithRetry(&sdk.RetryOptions{
        MaxRetryCount:   5,
        MinimumInterval: &minimumInterval,
        MaximumInterval: &maximumInterval,
        Strategy:        sdk.ExponentialBackoff,
    }),
)

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:

Contenuti correlati

  • Last updated on