Azure İşlevleri'nde hata işleme ve yeniden deneme

Azure İşlevleri hataların işlenmesi, veri kaybını önlemenize, eksik olaylardan kaçınmanıza ve uygulamanızın durumunu izlemenize yardımcı olmak için önemlidir. 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 önizleme yeniden deneme ilkesi desteği Aralık 2022'de kaldırıldı. Desteklenen tetikleyiciler için yeniden deneme ilkeleri genel kullanıma sunuldu (GA). Şu anda yeniden deneme ilkelerini destekleyen uzantıların listesi için Yeniden denemeler bölümüne bakın.

Hataları işleme

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

• Yerleşik İşlevler tetikleyicilerinin ve bağlamalarının kullanımı.
• Temel alınan Azure hizmetlerinin API'lerine çağrılar.
• REST uç noktalarına çağrılar.
• İstemci kitaplıklarına, paketlere veya üçüncü taraf API'lere yapılan çağrılar.

Veri kaybını veya yanıtsız iletileri önlemek için iyi bir hata işleme uygulaması yapmak önemlidir. 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 İşlevleri hata verilerini, performans verilerini ve çalışma zamanı günlüklerini toplamak için Uygulama Analizler ile tümleşir. İşlev yürütmelerinizde oluşan hataları bulmak ve daha iyi anlamak için Application Analizler kullanmalısınız. Daha fazla bilgi edinmek için bkz. İzleme Azure İşlevleri.
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 tarafından hangi hataların oluşturulabileceği hakkında bilgi için bkz . Bağlama hata kodları. 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	Çeşitli İşlev bağlama uzantıları yeniden denemeler için yerleşik destek sağlar ve diğerleri İşlevler çalışma zamanı tarafından uygulanan yeniden deneme ilkelerini tanımlamanıza olanak tanır. Yeniden deneme davranışları sağlamayan tetikleyiciler için kendi yeniden deneme düzeninizi uygulamayı düşünmelisiniz. Daha fazla bilgi için bkz . Yeniden denemeler.
Bir kez etkililik 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 edinmek için bkz. Özdeş giriş için Azure İşlevleri tasarlama.

Yeniden deneme sayısı

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

• Tek tek tetikleyici uzantılarının yerleşik yeniden deneme davranışları
• İşlevler çalışma zamanı tarafından sağlanan yeniden deneme ilkeleri

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	İlkeleri yeniden deneme	İşlev düzeyi
Blob Depolama	Bağlama uzantısı	host.json
Event Grid	Bağlama uzantısı	Olay aboneliği
Event Hubs	İlkeleri yeniden deneme	İşlev düzeyi
Kafka	İlkeleri yeniden deneme	İşlev düzeyi
Kuyruk Depolama	Bağlama uzantısı	host.json
RabbitMQ	Bağlama uzantısı	Teslim edilemeyen ileti kuyruğu
Service Bus	Bağlama uzantısı	host.json*
Zamanlayıcı	İlkeleri yeniden deneme	İşlev düzeyi

^*Azure Service Bus uzantısının 5.x sürümünü gerektirir. Eski uzantı sürümlerinde, yeniden deneme davranışları Service Bus teslim edilemeyen ileti kuyruğu tarafından uygulanır.

İlkeleri yeniden deneme

Azure İşlevleri, çalışma zamanı tarafından zorlanan belirli tetikleyici türleri için yeniden deneme ilkeleri tanımlamanızı sağlar. Bu 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 İşlevler ç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ü tarafından yürütülen bir işlev yakalanmamış bir özel durum oluşturduğunda 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 tamamlanana kadar Event Hubs denetim noktaları yazılamaz. Bu davranış nedeniyle, geçerli toplu işlem tamamlanana kadar belirli bölümdeki ilerleme duraklatılır.

Event Hubs uzantısının 5.x sürümü, İşlevler konağı ile olay hub'ı arasındaki etkileşimler için ek yeniden deneme özelliklerini destekler. Daha fazla bilgi için bkz clientRetryOptions. Event Hubs host.json başvurusu.

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 geri alma

İ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 alma, yüksek aktarım hızı senaryolarında yeniden denemeleri kademelendirme gecikmelerine bazı küçük rastgeleleştirmeler ekler.

Tüketim planında çalışırken, yalnızca işlev kodunuzun yürütülmekte olduğu 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 nihai hatadan önce yeniden denenme sayısı üst sınırını yapılandırabilirsiniz. Geçerli yeniden deneme sayısı, örneğin belleğinde depolanır.

Bir örneğin yeniden deneme girişimleri arasında bir hata olması mümkündü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ırlanırken toplu işlemi yeni bir örnekte yeniden deneyebilir. 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 yürütme istenen en fazla sayıdan daha fazla yeniden denenebilir. Zamanlayıcı tetikleyicileri için yeniden denemeler istenen en fazla 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>= 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}");
}

Özellik	Açıklama
MaxRetryCount	Gerekli. İşlev yürütme başına izin verilen en fazla yeniden deneme sayısı. -1 süresiz olarak yeniden deneme 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>= 3.0.23 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 deneme 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>= 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;
}

İşlem içi model

Yeniden denemeler için NuGet paketi Microsoft.Azure.WebJobs>= 3.0.23 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 deneme 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.

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

Sabit gecikme

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

Üstel geri alma

{
    "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
Strateji	Gerekli. Kullanılacak yeniden deneme stratejisi. Geçerli değerler fixedDelay veya exponentialBackoff şeklindedir.
maxRetryCount	Gerekli. İşlev yürütme başına izin verilen en fazla yeniden deneme sayısı. -1 süresiz olarak yeniden deneme 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	Bir strateji kullanırken exponentialBackoff en düşük yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.
maximumInterval	Stratejiyi kullanırken exponentialBackoff en fazla yeniden deneme gecikmesi. 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 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

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

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

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

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

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

Özellik	Açıklama
Strateji	Gerekli. Kullanılacak yeniden deneme stratejisi. Geçerli değerler fixedDelay veya exponentialBackoff şeklindedir.
maxRetryCount	Gerekli. İşlev yürütme başına izin verilen en fazla yeniden deneme sayısı. -1 süresiz olarak yeniden deneme 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	Bir strateji kullanırken exponentialBackoff en düşük yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.
maximumInterval	Stratejiyi kullanırken exponentialBackoff en fazla yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.

Python v2 modeli

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

from azure.functions import FunctionApp, TimerRequest, Context, AuthLevel
import logging

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

Aşağıda üstel geri alma yeniden deneme stratejisi kullanan zamanlayıcı tetikleyicisi işlevi örneği verilmişti:

from azure.functions import FunctionApp, TimerRequest, Context, AuthLevel
import logging

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 function.json dosyasında tanımlanır:

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

Aşağıda, sabit gecikmeli yeniden deneme stratejisi kullanan 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

function.json dosyasında tanımlanan üstel geri alma yeniden deneme ilkesi örneği aşağıda verilmiştır:

{
    "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
Strateji	Gerekli. Kullanılacak yeniden deneme stratejisi. Geçerli değerler fixed_delay veya exponential_backoff şeklindedir.
max_retry_count	Gerekli. İşlev yürütme başına izin verilen en fazla yeniden deneme sayısı. -1 süresiz olarak yeniden deneme anlamına gelir.
delay_interval	Bir strateji kullanırken fixed_delay yeniden denemeler arasında kullanılan gecikme. biçiminde HH:mm:ssbir dize olarak belirtin.
minimum_interval	Bir strateji kullanırken exponential_backoff en düşük yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.
maximum_interval	Stratejiyi kullanırken exponential_backoff en fazla yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.

Python v1 modeli

Özellik	Açıklama
Strateji	Gerekli. Kullanılacak yeniden deneme stratejisi. Geçerli değerler fixedDelay veya exponentialBackoff şeklindedir.
maxRetryCount	Gerekli. İşlev yürütme başına izin verilen en fazla yeniden deneme sayısı. -1 süresiz olarak yeniden deneme 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	Bir strateji kullanırken exponentialBackoff en düşük yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.
maximumInterval	Stratejiyi kullanırken exponentialBackoff en fazla 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 geri alma

@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 deneme 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	Bir strateji kullanırken exponentialBackoff en düşük yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.
maximumInterval	Stratejiyi kullanırken exponentialBackoff en fazla yeniden deneme gecikmesi. biçiminde HH:mm:ssbir dize olarak belirtin.

Bağlama hata kodları

Azure hizmetleriyle tümleştirme yaparken 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 Depolama
• Event Grid
• Event Hubs
• IoT Hub
• Notification Hubs
• Kuyruk Depolama
• Service Bus
• Tablo Depolama

Sonraki adımlar

• Azure İşlevleri tetikleyicileri ve bağlama kavramları
• Güvenilir Azure işlevleri için en iyi yöntemler