Azure Functions hata işleme ve yeniden denemeler

Azure Functions hatalarını işleme, veri kaybını önlemenize, eksik olaylardan kaçınmanıza ve uygulamanızın durumunu izlemenize yardımcı olur. Ayrıca olay tabanlı tetikleyicilerin yeniden deneme davranışlarını anlamanıza yardımcı olmak için de önemli bir yoldur.

Bu makalede hata işlemeye yönelik genel stratejiler ve kullanılabilir yeniden deneme stratejileri açıklanmaktadır.

Önemli

Belirli tetikleyiciler için yeniden deneme ilkesi desteğinin önizlemesi Aralık 2022'de kaldırıldı. Desteklenen tetikleyiciler için yeniden deneme ilkeleri artık genel kullanılabilirlik (GA) aşamasındadır. Bu makalenin Yeniden Denemeler bölümünde, şu anda yeniden deneme ilkelerini destekleyen uzantılar listelenir.

Hataları işleme

bir Azure işlevinde oluşan hatalar aşağıdakilerden gelebilir:

• Yerleşik Azure Functions tetikleyicileri ve bağlamaları kullanımı.
• Altında yatan Azure hizmetlerinin API'lerine çağrılar.
• REST uç noktalarına çağrılar.
• İstemci kitaplıklarına, paketlere veya Microsoft dışı API'lere yapılan çağrılar.

Veri kaybını veya yanıtsız iletileri önlemek için iyi bir hata işleme uygulaması yapmalısınız. Bu tabloda önerilen bazı hata işleme uygulamaları açıklanır ve daha fazla bilgi için bağlantılar sağlanır:

Öneri	Ayrıntılar
Application Insights’ı Etkinleştir	Azure Functions hata verilerini, performans verilerini ve çalışma zamanı günlüklerini toplamak için Application Insights ile tümleşir. İşlev yürütmelerinizde oluşan hataları keşfetmek ve daha iyi anlamak için Application Insights'ı kullanın. Daha fazla bilgi edinmek için bkz. Azure İşlevleri'nde yürütmeleri izleme.
Yapılandırılmış hata işlemeyi kullanma	Hataları yakalamak ve günlüğe kaydetmek, uygulamanızın durumunu izlemek için kritik öneme sahiptir. Herhangi bir işlev kodunun en üst düzeyi bir try/catch bloğu içermelidir. Catch bloğunda hataları yakalayabilir ve günlüğe kaydedebilirsiniz. Bağlamaların oluşturabileceği hatalar hakkında bilgi için bu makaledeki Bağlama hata kodları bölümüne bakın. Belirli yeniden deneme stratejinize bağlı olarak, işlevi yeniden çalıştırmak için yeni bir özel durum da tetikleyebilirsiniz.
Yeniden deneme stratejinizi planlama	Azure Functions'daki çeşitli bağlama uzantıları, yeniden denemeler için yerleşik destek sağlar. Diğerleri, Azure Functions çalışma zamanının uyguladığı yeniden deneme ilkelerini tanımlamanıza olanak tanır. Yeniden deneme davranışları sağlamayan tetikleyiciler için kendi yeniden deneme düzeninizi uygulamayı göz önünde bulundurun. Daha fazla bilgi için bu makaledeki Yeniden denemeler bölümüne bakın.
idempotentlik için tasarım	Verileri işlerken hataların ortaya çıkması, özellikle iletileri işlerken işlevleriniz için sorun olabilir. Hata oluştuğunda ne olacağını ve yinelenen işlemenin nasıl önlen olacağını göz önünde bulundurmak önemlidir. Daha fazla bilgi için bkz. Aynı Girdi için Azure İşlevlerini Tasarlama.

İpucu

Çıkış bağlamalarını kullandığınızda, uzak hizmete erişirken oluşan hataları işleyemezsiniz. Bu davranış nedeniyle bilinen hataları önlemek için, çıkış bağlamlarına aktarılan tüm verileri doğrulamanız gerekir. İşlev kodunuzda bu tür özel durumları işleyebilmeniz gerekiyorsa, çıkış bağlamalarına güvenmek yerine istemci SDK'sını kullanarak uzak hizmete erişmeniz gerekir.

Tekrar Denemeler

İşlevleriniz için iki tür yeniden deneme kullanılabilir:

• Tek tek tetikleyici uzantılarının yerleşik yeniden deneme davranışları
• Azure Functions çalışma zamanının sağladığı ilkeleri yeniden deneme

Aşağıdaki tabloda, hangi tetikleyicilerin yeniden denemeleri desteklediği ve yeniden deneme davranışının nerede yapılandırıldığı gösterilir. Ayrıca, temel alınan hizmetlerden gelen hatalar hakkında daha fazla bilgiye de bağlantı sağlar.

Tetikleyici/bağlama	Kaynağı yeniden deneyin	Yapılandırma
Azure Cosmos DB	Yeniden deneme ilkeleri	İşlev düzeyi
Azure Blob Storage	Bağlama uzantısı	host.json
Azure Event Grid	Bağlama uzantısı	Olay aboneliği
Azure Event Hubs	Yeniden deneme politikaları	İşlev düzeyi
Kafka	Yeniden deneme ilkeleri	İşlev düzeyi
Azure Kuyruk Depolama	Bağlama uzantısı	host.json
RabbitMQ	Bağlama uzantısı	Teslim edilemeyen ileti kuyruğu
Azure Service Bus	Bağlama uzantısı	host.json*
Zamanlayıcı	Yeniden deneme politikaları	İşlev düzeyi

^* Azure Service Bus uzantısının 5.x sürümünü gerektirir. Eski uzantı sürümlerinde Service Bus ölü harf kuyruğu, yeniden deneme davranışlarını uygular.

İlkeleri yeniden deneme

Azure Functions ile belirli tetikleyici türleri için yeniden deneme ilkeleri tanımlayabilirsiniz. Çalışma zamanı bu yeniden deneme ilkelerini zorunlu kılar. Aşağıdaki tetikleyici türleri şu anda yeniden deneme ilkelerini destekler:

• Azure Cosmos DB
• Event Hubs
• Kafka
• Zamanlayıcı

Yeniden deneme desteği hem v1 hem de v2 Python programlama modelleri için aynıdır.

Yeniden deneme ilkeleri, Azure Functions çalışma zamanının 1.x sürümünde desteklenmez.

Yeniden deneme ilkesi, çalışma zamanına başarılı bir tamamlama gerçekleşene veya yeniden deneme sayısı üst sınırına ulaşılana kadar başarısız bir yürütmeyi yeniden çalıştırmasını söyler.

Desteklenen bir tetikleyici türünün yürüttüğü bir işlev yakalanmamış bir özel durum tetiklediğinde yeniden deneme ilkesi değerlendirilir. En iyi yöntem olarak, kodunuzdaki tüm özel durumları yakalamalı ve yeniden denemeyle sonuçlanmasını istediğiniz hatalar için yeni özel durumlar oluşturmalısınız.

Önemli

Yürütme için yeniden deneme ilkesi bitene kadar Event Hubs denetim noktaları yazılamaz. Belirli bölmenin ilerlemesi, bu davranış nedeniyle mevcut işlem grubu tamamlanana kadar duraklatılır. Daha fazla bilgi için bkz. Azure Functions ve Event Hubs ile güvenilir olay işleme.

Event Hubs uzantısının 5.x sürümü, Azure Functions ana bilgisayarı ile olay hub'ı arasındaki etkileşimler için ek yeniden deneme özelliklerini destekler. Daha fazla bilgi için clientRetryOptions, Event Hubs host.json başvurusu bölümüne bakın.

Yeniden deneme stratejileri

İlke tarafından desteklenen iki yeniden deneme stratejisi yapılandırabilirsiniz:

Sabit gecikme

Her yeniden deneme arasında belirtilen sürenin geçmesine izin verilir.

Üstel gerileme

İlk yeniden deneme en düşük gecikmeyi bekler. Sonraki yeniden denemelerde, maksimum gecikmeye ulaşılana kadar her yeniden denemenin başlangıç süresine üstel olarak zaman eklenir. Üstel geri çekilme, yüksek aktarım hızı senaryolarında yeniden denemeleri gecikmelere bazı küçük rastgele unsurlar ekleyerek kademelendirir.

Tüketim planı kullandığınızda, yalnızca işlev kodunuzun çalıştığı süre için faturalandırılırsınız. Bu yeniden deneme stratejilerinden herhangi birinde yürütmeler arasındaki bekleme süresi için faturalandırılamazsınız.

En fazla yeniden deneme sayısı

Bir işlev yürütmesinin başarısız olmadan önce yeniden deneneceği maksimum sayı değerini yapılandırabilirsiniz. Geçerli yeniden deneme sayısı, sistemin belleğinde depolanır.

Bir örneğin yeniden deneme girişimleri arasında bir hata meydana gelmesi olasılığı vardır. Bir örnek yeniden deneme ilkesi sırasında başarısız olduğunda, yeniden deneme sayısı kaybolur. Örnek hataları olduğunda, Event Hubs tetikleyicisi işlemeye devam edebilir ve yeniden deneme sayısı sıfırlanmış olarak toplu işlemi yeni bir örnek üzerinde yeniden başlatabilir. Zamanlayıcı tetikleyicisi yeni bir örnekte devam etmez.

Bu davranış, yeniden deneme sayısı üst sınırının en iyi çaba olduğu anlamına gelir. Bazı nadir durumlarda, bir işlem istenen maksimum sayının üzerinde yeniden denenebilir. Zamanlayıcı tetikleyicileri için yeniden denemeler istenen maksimum sayıdan az olabilir.

Yeniden deneme örnekleri

Hem sabit gecikme hem de üstel geri alma stratejileri için örnekler sağlanır. Belirli bir stratejinin örneklerini görmek için önce önceki sekmede bu stratejiyi seçmeniz gerekir.

Yalıtılmış çalışan modeli

İşlev düzeyinde yeniden denemeler aşağıdaki NuGet paketleriyle desteklenir:

• Microsoft. Azure. Functions.Worker.Sdk sürüm 1.9.0 ve üzeri
• Microsoft. Azure. Functions.Worker.Extensions.EventHubs sürüm 5.2.0 ve üzeri
• Microsoft. Azure. Functions.Worker.Extensions.Kafka sürüm 3.8.0 ve üzeri
• Microsoft. Azure. Functions.Worker.Extensions.Timer sürüm 4.2.0 ve üzeri

[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}");
}

Özellik	Açıklama
MaxRetryCount	Gerekli. İşlev yürütme başına izin verilen en fazla yeniden deneme sayısı. -1 süresiz olarak yeniden deneneceği anlamına gelir.
DelayInterval	Yeniden denemeler arasında kullanılan gecikme. biçiminde HH:mm:ssbir dize olarak belirtin.

İşlem içi model

Yeniden denemeler için NuGet paketi Microsoft.Azure.WebJobs sürüm 3.0.23 veya üzeri gerekir.

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

Özellik	Açıklama
MaxRetryCount	Gerekli. İşlev yürütme başına izin verilen en fazla yeniden deneme sayısı. -1 süresiz olarak yeniden deneneceği anlamına gelir.
DelayInterval	Yeniden denemeler arasında kullanılan gecikme. biçiminde HH:mm:ssbir dize olarak belirtin.

Yalıtılmış çalışan modeli

İşlev düzeyinde yeniden denemeler aşağıdaki NuGet paketleriyle desteklenir:

• Microsoft. Azure. Functions.Worker.Sdk sürüm 1.9.0 veya üzeri
• Microsoft. Azure. Functions.Worker.Extensions.EventHubs sürüm 5.2.0 veya üzeri
• Microsoft. Azure. Functions.Worker.Extensions.Kafka sürüm 3.8.0 veya üzeri
• Microsoft. Azure. Functions.Worker.Extensions.Timer sürüm 4.2.0 veya üzeri

[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;
}

İşlem içi model

Yeniden denemeler için Microsoft.Azure.WebJobs NuGet paketi sürüm 3.0.23 veya üzeri gerekir.

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

Özellik	Açıklama
MaxRetryCount	Gerekli. İşlev yürütme başına izin verilen en fazla yeniden deneme sayısı. -1 süresiz olarak yeniden deneneceği anlamına gelir.
MinimumInterval	En düşük yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.
MaximumInterval	En fazla yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.

Aşağıda dosyada tanımlanan bir yeniden deneme ilkesi örneği verilmişti function.json :

Sabit gecikme

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

Üstel gerileme

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

Bu özellikleri yeniden deneme ilkesi tanımlarında ayarlayabilirsiniz:

Özellik	Açıklama
strategy	Gerekli. Kullanılacak yeniden deneme stratejisi. Geçerli değerler: fixedDelay ve exponentialBackoff.
maxRetryCount	Gerekli. İşlev yürütme başına izin verilen en fazla yeniden deneme sayısı. -1 süresiz olarak yeniden deneneceği anlamına gelir.
delayInterval	Bir strateji kullanırken fixedDelay yeniden denemeler arasında kullanılan gecikme. biçiminde HH:mm:ssbir dize olarak belirtin.
minimumInterval	exponentialBackoff stratejisini kullanırken en düşük yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.
maximumInterval	Bir exponentialBackoff stratejisi kullanırken en fazla yeniden deneme gecikmesi süresi. biçiminde HH:mm:ssbir dize olarak belirtin.

Tetikleyici için yeniden deneme ilkesini tanımlama şekliniz Node.js sürümünüze bağlıdır:

Node.js v4

Aşağıda, sabit gecikmeli yeniden deneme stratejisi kullanan bir zamanlayıcı tetikleyicisi işlevi örneği verilmişti:

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

Dosyada tanımlanan bir sabit gecikmeli yeniden deneme ilkesi örneği aşağıda verilmiştır function.json :

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

Tetikleyici için yeniden deneme ilkesini tanımlama şekliniz Node.js sürümünüze bağlıdır:

Node.js v4

Aşağıda, sabit gecikmeli yeniden deneme stratejisi kullanan bir zamanlayıcı tetikleyicisi işlevi örneği verilmişti:

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

Dosyada tanımlanan bir sabit gecikmeli yeniden deneme ilkesi örneği aşağıda verilmiştır function.json :

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

Bu özellikleri yeniden deneme ilkesi tanımlarında ayarlayabilirsiniz:

Özellik	Açıklama
strategy	Gerekli. Kullanılacak yeniden deneme stratejisi. Geçerli değerler: fixedDelay ve exponentialBackoff.
maxRetryCount	Gerekli. İşlev yürütme başına izin verilen en fazla yeniden deneme sayısı. -1 süresiz olarak yeniden deneneceği anlamına gelir.
delayInterval	Strateji kullanırken fixedDelay yeniden denemeler arasında kullanılan gecikme süresi. biçiminde HH:mm:ssbir dize olarak belirtin.
minimumInterval	exponentialBackoff stratejisi kullanılırken en düşük yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.
maximumInterval	Bir exponentialBackoff stratejisi kullanırken en fazla yeniden deneme süresi gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.

Python v2 modeli

Aşağıda, sabit gecikmeli yeniden deneme stratejisi kullanan bir zamanlayıcı tetikleyicisi işlevi örneği verilmişti:

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 modeli

Üstel geri çekilme yeniden deneme stratejisi kullanan bir zamanlayıcı tetikleyici işlevi örneği verilmiştir.

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 modeli

Yeniden deneme ilkesi dosyasında tanımlanır function.json :

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

Aşağıda, sabit gecikmeli yeniden deneme stratejisi kullanan bir zamanlayıcı tetikleyicisi işlevi örneği verilmişti:

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 modeli

Aşağıda, dosyayla tanımlanan üstel geri çekilme yeniden deneme ilkesi örneği verilmiştir function.json :

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

Bu özellikleri yeniden deneme ilkesi tanımlarında ayarlayabilirsiniz:

Python v2 modeli

Özellik	Açıklama
strategy	Gerekli. Kullanılacak yeniden deneme stratejisi. Geçerli değerler: fixed_delay ve exponential_backoff.
max_retry_count	Gerekli. İşlev yürütme başına izin verilen en fazla yeniden deneme sayısı. -1 süresiz olarak yeniden deneneceği anlamına gelir.
delay_interval	Bir fixed_delay stratejisi kullanırken, yeniden denemeler arasında kullanılan gecikme. biçiminde HH:mm:ssbir dize olarak belirtin.
minimum_interval	Bir exponential_backoff stratejisini kullanırken asgarî yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.
maximum_interval	Bir exponential_backoff stratejisi kullanırken maksimum yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.

Python v1 modeli

Özellik	Açıklama
strategy	Gerekli. Kullanılacak yeniden deneme stratejisi. Geçerli değerler: fixedDelay ve exponentialBackoff.
maxRetryCount	Gerekli. İşlev yürütme başına izin verilen en fazla yeniden deneme sayısı. -1 süresiz olarak yeniden deneneceği anlamına gelir.
delayInterval	Bir fixedDelay stratejisini kullanırken yeniden denemeler arasında kullanılan gecikme. biçiminde HH:mm:ssbir dize olarak belirtin.
minimumInterval	exponentialBackoff stratejisini kullanırken minimum yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.
maximumInterval	Kullandığınız bir exponentialBackoff stratejisinde maksimum yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.

Sabit gecikme

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

Üstel gerileme

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

Öğe	Açıklama
maxRetryCount	Gerekli. İşlev yürütme başına izin verilen en fazla yeniden deneme sayısı. -1 süresiz olarak yeniden deneneceği anlamına gelir.
delayInterval	Bir fixedDelay stratejisini kullanırken yeniden denemeler arasında kullanılan gecikme. biçiminde HH:mm:ssbir dize olarak belirtin.
minimumInterval	exponentialBackoff stratejisini kullanırken minimum yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.
maximumInterval	Kullandığınız bir exponentialBackoff stratejisinde maksimum yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.

Bağlama hata kodları

Azure hizmetleriyle tümleştirdiğinizde, hatalar temel alınan hizmetlerin API'lerinden kaynaklanabilir. Bağlamaya özgü hatalarla ilgili bilgiler, aşağıdaki makalelerin "Özel durumlar ve dönüş kodları" bölümlerinde bulunabilir:

• Azure Cosmos DB
• Blob Storage
• Event Grid
• Event Hubs
• IoT Hub
• Notification Hubs
• Kuyruk Depolama
• Service Bus
• Tablo Saklama

İlgili içerik

• Azure Functions tetikleyicileri ve bağlamaları
• Güvenilir Azure işlevleri için en iyi uygulamalar