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:

• Azure Cosmos DB
• Event Hubs
• Kafka
• Timer

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:

Feste Verzögerung

Zwischen den einzelnen Wiederholungsversuchen kann eine angegebene Zeitspanne vergehen.

Exponentiales Backoff

Bei der ersten Wiederholung wird die minimale Verzögerung gewartet. Bei nachfolgenden Wiederholungen wird exponentiell Zeit zur anfänglichen Dauer addiert, bis die maximale Verzögerung erreicht ist. Das exponentielle Backoff fügt den Verzögerungen einen geringfügigen Zufallswert hinzu, um Verzögerungen in Szenarien mit hohem Durchsatz zu staffeln.

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.

Isoliertes Workermodell

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.

In-Process-Modell

Für Wiederholungen ist das NuGet-Paket Microsoft.Azure.WebJobs>= 3.0.23 erforderlich.

[FunctionName("EventHubTrigger")]
[FixedDelayRetry(5, "00:00:10")]
public static async Task Run([EventHubTrigger("myHub", Connection = "EventHubConnection")] EventData[] events, ILogger log)
{
// ...
}

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.

Isoliertes Workermodell

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(CosmosDBFunction))]
[ExponentialBackoffRetry(5, "00:00:04", "00:15:00")]
[CosmosDBOutput("%CosmosDb%", "%CosmosContainerOut%", Connection = "CosmosDBConnection", CreateIfNotExists = true)]
public object Run(
    [CosmosDBTrigger(
        "%CosmosDb%",
        "%CosmosContainerIn%",
        Connection = "CosmosDBConnection",
        LeaseContainerName = "leases",
        CreateLeaseContainerIfNotExists = true)] IReadOnlyList<MyDocument> input,
    FunctionContext context)
{
    if (input != null && input.Any())
    {
        foreach (var doc in input)
        {
            _logger.LogInformation("Doc Id: {id}", doc.Id);
        }

        // Cosmos Output
        return input.Select(p => new { id = p.Id });
    }

    return null;
}

In-Process-Modell

Für Wiederholungen ist das NuGet-Paket Microsoft.Azure.WebJobs>= 3.0.23 erforderlich.

[FunctionName("EventHubTrigger")]
[ExponentialBackoffRetry(5, "00:00:04", "00:15:00")]
public static async Task Run([EventHubTrigger("myHub", Connection = "EventHubConnection")] EventData[] events, ILogger log)
{
// ...
}

Eigenschaft	BESCHREIBUNG
MaxRetryCount	Erforderlich. Die maximale Anzahl zulässiger Wiederholungen pro Funktionsausführung. -1 bedeutet unbegrenzte Wiederholungen.
Minimalintervall	Das Minimum an Wiederholungsversuchsverzögerungen. Geben Sie sie als Zeichenfolge im Format HH:mm:ss an.
Maximalintervall	Das Maximum an Wiederholungsversuchsverzögerungen. 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:

Feste Verzögerung

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

Exponentiales Backoff

{
    "disabled": false,
    "bindings": [
        {
            ....
        }
    ],
    "retry": {
        "strategy": "exponentialBackoff",
        "maxRetryCount": 5,
        "minimumInterval": "00:00:10",
        "maximumInterval": "00:15:00"
    }
}

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.

Node.js v4

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

Node.js v3

Hier sehen Sie ein Beispiel für eine Wiederholungsrichtlinie mit fester Verzögerung, die in der Datei function.json definiert ist:

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

Die Vorgehensweise beim Definieren der Wiederholungsrichtlinie für den Trigger hängt von Ihrer Node.js-Version ab.

Node.js v4

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

Node.js v3

Hier sehen Sie ein Beispiel für eine Wiederholungsrichtlinie mit fester Verzögerung, 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.

Python-v2-Modell

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

Python-v2-Modell

Hier sehen Sie ein Beispiel für eine Timer-Triggerfunktion, die eine Wiederholungsstrategie mit exponentiellem Backoff 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="exponential_backoff", max_retry_count="3",
           minimum_interval="00:00:01",
           maximum_interval="00:00:02")
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")

Python-v1-Modell

Die Wiederholungsrichtlinie ist in der Datei „function.json“ definiert:

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

Hier sehen Sie ein Beispiel für eine Timer-Triggerfunktion, die eine Wiederholungsstrategie mit fester Verzögerung verwendet:

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

Python-v1-Modell

Hier sehen Sie ein Beispiel für eine Wiederholungsrichtlinie mit exponentiellem Backoff, die in der Datei function.json definiert ist:

{
    "disabled": false,
    "bindings": [
        {
            ....
        }
    ],
    "retry": {
        "strategy": "exponentialBackoff",
        "maxRetryCount": 5,
        "minimumInterval": "00:00:10",
        "maximumInterval": "00:15:00"
    }
}

Für Wiederholungsrichtliniendefinitionen können folgende Eigenschaften festgelegt werden:

Python-v2-Modell

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.

Python-v1-Modell

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.

Feste Verzögerung

@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());
}

Exponentiales Backoff

@FunctionName("TimerTriggerJava1")
@ExponentialBackoffRetry(maxRetryCount = 5 , maximumInterval = "00:15:00", minimumInterval = "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());
}

Element	BESCHREIBUNG
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.

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

Nächste Schritte

• Konzepte für Azure Functions-Trigger und -Bindungen
• Bewährte Methoden für zuverlässigen Azure Functions-Code