Fehlerbehandlung und Wiederholungen in Azure Functions
Das Behandeln von Fehlern in Azure Functions ist wichtig, um verlorene Daten und verpasste Ereignisse zu vermeiden sowie um die Integrität Ihrer Anwendung zu überwachen. Es ist auch eine wichtige Methode, um das Wiederholungsverhalten von ereignisbasierten Triggern zu verstehen.
In diesem Artikel werden allgemeine Strategien für die Fehlerbehandlung und die verfügbaren Wiederholungsstrategien beschrieben.
Wichtig
Die Vorschauunterstützung von Wiederholungsrichtlinien für bestimmte Trigger wurde im Dezember 2022 entfernt. Wiederholungsrichtlinien für unterstützte Trigger sind jetzt allgemein verfügbar. Eine Liste der Erweiterungen, die derzeit Wiederholungsrichtlinien unterstützen, finden Sie im Abschnitt Wiederholungen.
Behandeln von Fehlern
Fehler, die in einer Azure-Funktion auftreten, können folgende Ursachen haben:
- Verwendung integrierter Trigger und Bindungen von Functions
- Aufrufe an APIs zugrunde liegender Azure-Dienste.
- Aufrufe an REST-Endpunkte.
- Aufrufe an Client-Bibliotheken, Pakete oder Drittanbieter-APIs.
Für die Fehlerbehandlung sind bewährte Methoden wichtig, um Datenverluste oder verpasste Nachrichten zu vermeiden. Die folgende Tabelle enthält einige empfohlene Fehlerbehandlungspraktiken sowie Links zu weiteren Informationen:
Empfehlung | Details |
---|---|
Application Insights aktivieren | Azure Functions wird in Application Insights integriert, um Fehlerdaten, Leistungsdaten und Laufzeitprotokolle zu sammeln. Sie sollten Application Insights verwenden, um Fehler zu ermitteln und besser zu verstehen, die in Ihren Funktionsausführungen auftreten. Weitere Informationen finden Sie unter Überwachen von Azure Functions. |
Verwenden strukturierter Fehlerbehandlung | Das Erfassen und Protokollieren von Fehlern ist kritisch für die Überwachung der Integrität Ihrer Anwendung. Die oberste Ebene jedes Funktioncodes sollte einen try/catch-Block enthalten. Im catch-Block können Sie Fehler erfassen und protokollieren. Informationen zu den Fehlern, die durch Bindungen ausgelöst werden können, finden Sie unter Bindungsfehlercodes. Je nach Wiederholungsstrategie kann auch eine neue Ausnahme ausgelöst werden, um die Funktion erneut auszuführen. |
Planen Ihrer Wiederholungsstrategie | Mehrere Functions-Bindungserweiterungen bieten integrierte Unterstützung von Wiederholungen. Andere ermöglichen es Ihnen, Wiederholungsrichtlinien zu definieren, die von der Functions-Runtime implementiert werden. Für Trigger ohne Wiederholungsverhalten empfiehlt es sich gegebenenfalls, ein eigenes Wiederholungsschema zu implementieren. Weitere Informationen finden Sie unter Wiederholungsversuche. |
Design für Idempotenz | Das Auftreten von Fehlern beim Verarbeiten von Daten kann ein Problem für Ihre Funktionen darstellen, insbesondere bei der Verarbeitung von Nachrichten. Es ist wichtig, zu berücksichtigen, was geschieht, wenn der Fehler auftritt, und wie Sie doppelte Verarbeitung vermeiden. Weitere Informationen finden Sie unter Entwerfen von Azure Functions für identische Eingaben. |
Wiederholungsversuche
Es gibt zwei Arten von Wiederholungen, die für Ihre Funktionen verfügbar sind:
- Integrierte Wiederholungsverhalten einzelner Triggererweiterungen
- Von der Functions-Runtime bereitgestellte Wiederholungsrichtlinien
In der folgenden Tabelle wird angegeben, welche Trigger Wiederholungen unterstützen und wo das Wiederholungsverhalten konfiguriert ist. Außerdem enthält sie Links zu weiteren Informationen zu Fehlern, die aus den zugrunde liegenden Diensten stammen.
Trigger/Bindung | Wiederholen der Quelle | Konfiguration |
---|---|---|
Azure Cosmos DB | Wiederholungsrichtlinien | Funktionsebene |
Blob Storage | Bindungserweiterung | host.json |
Event Grid | Bindungserweiterung | Ereignisabonnement |
Event Hubs | Wiederholungsrichtlinien | Funktionsebene |
Kafka | Wiederholungsrichtlinien | Funktionsebene |
Queue Storage | Bindungserweiterung | host.json |
RabbitMQ | Bindungserweiterung | Warteschlange für unzustellbare Nachrichten |
Service Bus | Bindungserweiterung | host.json* |
Timer | Wiederholungsrichtlinien | Funktionsebene |
* Erfordert Version 5.x der Azure Service Bus-Erweiterung. In älteren Erweiterungsversionen wird Wiederholungsverhalten durch die Service Bus-Warteschlange für unzustellbare Nachrichten implementiert.
Wiederholungsrichtlinien
Mit Azure Functions können Sie Wiederholungsrichtlinien für bestimmte Triggertypen definieren, die von der Runtime erzwungen werden. Wiederholungsrichtlinien werden derzeit von folgenden Triggertypen unterstützt:
Die Wiederholungsunterstützung ist für v1- und v2-Python-Programmiermodelle gleich.
Wiederholungsrichtlinien werden in der Version 1.x der Functions-Runtime nicht unterstützt.
Die Wiederholungsrichtlinie teilt der Laufzeit mit, eine fehlgeschlagene Ausführung erneut auszuführen, bis entweder eine erfolgreiche Fertigstellung auftritt oder die maximale Anzahl von Wiederholungen erreicht wird.
Eine Wiederholungsrichtlinie wird ausgewertet, wenn eine durch einen unterstützten Triggertyp ausgeführte Funktion eine nicht abgefangene Ausnahme auslöst. Es hat sich bewährt, alle Ausnahmen in Ihrem Code abzufangen und neue Ausnahmen für Fehler auszulösen, die zu einem Wiederholungsversuch führen sollten.
Wichtig
Event Hubs-Prüfpunkte werden erst geschrieben, wenn die Wiederholungsrichtlinie für die Ausführung abgeschlossen ist. Aufgrund dieses Verhaltens wird der Fortschritt auf der spezifischen Partition angehalten, bis die Verarbeitung des aktuellen Batchs abgeschlossen ist.
Die Version 5.x der Event Hubs-Erweiterung unterstützt zusätzliche Wiederholungsfunktionen für Interaktionen zwischen dem Functions-Host und dem Event Hub. Weitere Informationen finden Sie in der Event Hubs-Referenzdokumentation zu „host.json“ unter clientRetryOptions
.
Wiederholungsstrategien
Sie können zwei Wiederholungsstrategien konfigurieren, die von der Richtlinie unterstützt werden:
Zwischen den einzelnen Wiederholungsversuchen kann eine angegebene Zeitspanne vergehen.
Bei Verwendung eines Verbrauchsplans wird Ihnen nur die Zeit in Rechnung gestellt, in der Ihr Funktionscode ausgeführt wird. Die Wartezeit zwischen Ausführungen wird bei keiner dieser Wiederholungsstrategien in Rechnung gestellt.
Max. Wiederholungsanzahl
Sie können die maximale Anzahl von Wiederholungsversuchen für eine Ausführung konfigurieren, bis diese endgültig als fehlerhaft gilt. Die aktuelle Wiederholungsanzahl wird im Arbeitsspeicher der Instanz gespeichert.
Es kann vorkommen, dass bei einer Instanz zwischen Wiederholungsversuchen ein Fehler auftritt. Wenn auf einer Instanz während einer Wiederholungsrichtlinie ein Fehler auftritt, geht die Zählung der Wiederholungsversuche verloren. Bei Instanz-Fehlern ist Event Hubs in der Lage, den Prozess fortzusetzen und den Batch der neuen Instanz wiederholen wobei die Wiederholungsanzahl auf null zurückgesetzt wird. Der Zeitgebertrigger wird in einer neuen Instanz nicht fortgesetzt.
Aufgrund dieses Verhaltens kann die Einhaltung der maximalen Wiederholungsanzahl nicht garantiert werden. In seltenen Fällen können auch mehr Wiederholungsversuche erfolgen. Für Zeitgebertrigger kann die Anzahl von Wiederholungsversuchen geringer als die angeforderte maximale Anzahl sein.
Beispiele für Wiederholungsversuche
Beispiele sind sowohl für die Strategie mit fester Verzögerung als auch für die Strategie mit exponentiellem Backoff verfügbar. Um Beispiele für eine bestimmte Strategie anzuzeigen, müssen Sie erst die gewünschte Strategie auf der vorherigen Registerkarte auswählen.
Wiederholungsversuche auf Funktionsebene werden mit den folgenden NuGet-Paketen unterstützt:
- 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}");
}
Eigenschaft | BESCHREIBUNG |
---|---|
MaxRetryCount | Erforderlich. Die maximale Anzahl zulässiger Wiederholungen pro Funktionsausführung. -1 bedeutet unbegrenzte Wiederholungen. |
DelayInterval | Die zwischen Wiederholungsversuchen verwendete Verzögerung. Geben Sie sie als Zeichenfolge im Format HH:mm:ss an. |
Hier sehen Sie ein Beispiel für eine Wiederholungsrichtlinie, die in der Datei function.json definiert ist:
{
"disabled": false,
"bindings": [
{
....
}
],
"retry": {
"strategy": "fixedDelay",
"maxRetryCount": 4,
"delayInterval": "00:00:10"
}
}
Für Wiederholungsrichtliniendefinitionen können folgende Eigenschaften festgelegt werden:
Eigenschaft | Beschreibung |
---|---|
strategy | Erforderlich. Die Wiederholungsstrategie, die verwendet werden soll. Gültige Werte sind fixedDelay und exponentialBackoff . |
maxRetryCount | Erforderlich. Die maximale Anzahl zulässiger Wiederholungen pro Funktionsausführung. -1 bedeutet unbegrenzte Wiederholungen. |
delayInterval | Die Verzögerung, die bei Verwendung einer Strategie vom Typ fixedDelay zwischen Wiederholungsversuchen verwendet wird. Geben Sie sie als Zeichenfolge im Format HH:mm:ss an. |
MinimumIntervall | Die geringste Wiederholungsverzögerung bei Verwendung der Strategie exponentialBackoff . Geben Sie sie als Zeichenfolge im Format HH:mm:ss an. |
Maximumintervall | Die maximale Wiederholungsverzögerung bei Verwendung der Strategie exponentialBackoff . Geben Sie sie als Zeichenfolge im Format HH:mm:ss an. |
Die Vorgehensweise beim Definieren der Wiederholungsrichtlinie für den Trigger hängt von Ihrer Node.js-Version ab.
Hier sehen Sie ein Beispiel für eine Timer-Triggerfunktion, die eine Wiederholungsstrategie mit fester Verzögerung verwendet:
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.');
}
},
});
Die Vorgehensweise beim Definieren der Wiederholungsrichtlinie für den Trigger hängt von Ihrer Node.js-Version ab.
Hier sehen Sie ein Beispiel für eine Timer-Triggerfunktion, die eine Wiederholungsstrategie mit fester Verzögerung verwendet:
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,
});
Für Wiederholungsrichtliniendefinitionen können folgende Eigenschaften festgelegt werden:
Eigenschaft | Beschreibung |
---|---|
strategy | Erforderlich. Die Wiederholungsstrategie, die verwendet werden soll. Gültige Werte sind fixedDelay und exponentialBackoff . |
maxRetryCount | Erforderlich. Die maximale Anzahl zulässiger Wiederholungen pro Funktionsausführung. -1 bedeutet unbegrenzte Wiederholungen. |
delayInterval | Die Verzögerung, die bei Verwendung einer Strategie vom Typ fixedDelay zwischen Wiederholungsversuchen verwendet wird. Geben Sie sie als Zeichenfolge im Format HH:mm:ss an. |
MinimumIntervall | Die geringste Wiederholungsverzögerung bei Verwendung der Strategie exponentialBackoff . Geben Sie sie als Zeichenfolge im Format HH:mm:ss an. |
Maximumintervall | Die maximale Wiederholungsverzögerung bei Verwendung der Strategie exponentialBackoff . Geben Sie sie als Zeichenfolge im Format HH:mm:ss an. |
Hier sehen Sie ein Beispiel für eine Timer-Triggerfunktion, die eine Wiederholungsstrategie mit fester Verzögerung verwendet:
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")
Für Wiederholungsrichtliniendefinitionen können folgende Eigenschaften festgelegt werden:
Eigenschaft | Beschreibung |
---|---|
strategy | Erforderlich. Die Wiederholungsstrategie, die verwendet werden soll. Gültige Werte sind fixed_delay und exponential_backoff . |
max_retry_count | Erforderlich. Die maximale Anzahl zulässiger Wiederholungen pro Funktionsausführung. -1 bedeutet unbegrenzte Wiederholungen. |
delay_interval | Die Verzögerung, die bei Verwendung einer Strategie vom Typ fixed_delay zwischen Wiederholungsversuchen verwendet wird. Geben Sie sie als Zeichenfolge im Format HH:mm:ss an. |
minimum_interval | Die geringste Wiederholungsverzögerung bei Verwendung der Strategie exponential_backoff . Geben Sie sie als Zeichenfolge im Format HH:mm:ss an. |
maximum_interval | Die maximale Wiederholungsverzögerung bei Verwendung der Strategie exponential_backoff . Geben Sie sie als Zeichenfolge im Format HH:mm:ss an. |
@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());
}
Bindungsfehlercodes
Bei der Integration in Azure-Dienste können Fehler auftreten, deren Ursache in den APIs der zugrunde liegenden Dienste liegt. Informationen zu bindungsspezifischen Fehlern finden Sie im Abschnitt „Ausnahmen und Rückgabecodes“ der folgenden Artikel:
- Azure Cosmos DB
- Blob Storage
- Event Grid
- Event Hubs
- IoT Hub
- Notification Hubs
- Queue Storage
- Service Bus
- Table Storage