Gestione degli errori di Funzioni di Azure e tentativi
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 viene rimosso nel runtime per trigger diversi da Timer, Kafka e Hub eventi dopo che questa funzionalità diventa disponibile a livello generale. Il supporto dei criteri di ripetizione dei tentativi di anteprima per tutti i trigger diversi da Timer e Hub eventi è stato rimosso nel dicembre 2022. Per altre informazioni, vedere la sezione Tentativi .
Gestione degli errori
Gli errori che si verificano in una funzione di Azure possono derivare da uno dei seguenti:
- Uso di trigger e associazioni Funzioni di Azure predefiniti
- 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. In questa sezione vengono descritte alcune procedure consigliate per la gestione degli errori e vengono forniti collegamenti ad altre informazioni.
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.
Pianificare la strategia di ripetizione dei tentativi
Diverse estensioni delle associazioni di Funzioni offrono il supporto predefinito per i tentativi. Il runtime consente inoltre di definire criteri di ripetizione dei tentativi per le funzioni attivate da Timer, Kafka e Hub eventi. Per altre informazioni, vedere Tentativi. Per i trigger che non forniscono comportamenti di ripetizione dei tentativi, è possibile implementare uno schema di ripetizione dei tentativi personalizzato.
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 di Azure | Estensione dell'associazione | host.json |
Griglia di eventi di Azure | Estensione dell'associazione | Sottoscrizione evento |
Hub eventi di Azure | Criteri di ripetizione dei tentativi | Livello di funzione |
Archiviazione code di Azure | Estensione dell'associazione | host.json |
RabbitMQ | Estensione dell'associazione | Coda di messaggi non recapitabili |
Bus di servizio di Azure | Estensione dell'associazione | Coda di messaggi non recapitabili |
Timer | Criteri di ripetizione dei tentativi | Livello di funzione |
Kafka | Criteri di ripetizione dei tentativi | Livello di funzione |
Criteri di ripetizione dei tentativi
A partire dalla versione 3.x del runtime di Funzioni di Azure, è possibile definire criteri di ripetizione dei tentativi per timer, Kafka, Hub eventi e trigger di Azure Cosmos DB applicati dal 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 attivata da Timer, Kafka, Hub eventi o Azure Cosmos DB genera un'eccezione non rilevata. Come procedura consigliata, è consigliabile intercettare tutte le eccezioni nel codice e generare nuovamente eventuali errori che si desidera generare un nuovo tentativo.
Importante
I checkpoint di Hub eventi non verranno scritti fino al termine del criterio di ripetizione dei tentativi per l'esecuzione. A causa di questo comportamento, lo stato di avanzamento della partizione specifica viene sospeso fino al termine del batch corrente.
L'estensione Hub eventi v5 supporta funzionalità di ripetizione dei tentativi aggiuntive per le interazioni tra l'host funzioni e l'hub eventi. Per altre informazioni, vedere la clientRetryOptions
sezione Hub eventi del file di 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.
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
I tentativi a livello di funzione sono supportati con i pacchetti NuGet seguenti:
- 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}");
}
Proprietà | Descrizione |
---|---|
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. Specificarlo come stringa con il formato HH:mm:ss . |
Ecco i criteri di ripetizione dei tentativi nel file function.json :
{
"disabled": false,
"bindings": [
{
....
}
],
"retry": {
"strategy": "fixedDelay",
"maxRetryCount": 4,
"delayInterval": "00:00:10"
}
}
function.json 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 . |
Ecco un esempio python che usa il contesto di ripetizione dei tentativi in una funzione:
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")
@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:
- Azure Cosmos DB
- Archiviazione BLOB
- Griglia di eventi
- Hub eventi
- Hub IoT
- Hub di notifica di Azure
- Archiviazione code
- Bus di servizio
- Archiviazione tabelle