Jak použít sadu Azure WebJobs SDK k událostmi řízenému zpracování na pozadí

Článek
06/13/2024

Tento článek obsahuje pokyny k práci se sadou Azure WebJobs SDK. Pokud chcete začít pracovat s WebJobs hned, přečtěte si téma Začínáme se sadou Azure WebJobs SDK.

Verze sady WebJobs SDK

Toto jsou hlavní rozdíly mezi verzí 3.x a verze 2.x sady WebJobs SDK:

Verze 3.x přidává podporu pro .NET Core.
Ve verzi 3.x, nainstalujete rozšíření vazby úložiště vyžadované sadou WebJobs SDK. Ve verzi 2.x, vazby úložiště jsou součástí sady SDK.
Nástroje sady Visual Studio 2019 pro .NET Core (3)x) projekty se liší od nástrojů pro rozhraní .NET Framework (2.x) projekty. Další informace najdete v tématu Vývoj a nasazení webových úloh pomocí sady Visual Studio – Aplikace Azure Service.

Několik popisů v tomto článku obsahuje příklady pro obě webové úlohy verze 3.x a WebJobs verze 2.x.

Služba Azure Functions je založená na sadě WebJobs SDK.

Azure Functions verze 2.X je postaven na sadě WebJobs SDK verze 3.x.
Azure Functions verze 1.x je založená na sadě WebJobs SDK verze 2.x.

Úložiště zdrojového kódu pro azure Functions i sadu WebJobs SDK používají číslování sady WebJobs SDK. Několik částí tohoto článku s postupy najdete v dokumentaci ke službě Azure Functions.

Další informace najdete v tématu Porovnání sady WebJobs SDK a Azure Functions.

Hostitel webových úloh

Hostitel je kontejner modulu runtime pro funkce. Hostitel naslouchá aktivačním událostem a voláním funkcí. Ve verzi 3.x, hostitel je implementace IHost. Ve verzi 2.x, použijete JobHost objekt. V kódu vytvoříte instanci hostitele a napíšete kód, který přizpůsobí jeho chování.

Jedná se o klíčový rozdíl mezi přímým použitím sady WebJobs SDK a jeho nepřímo prostřednictvím služby Azure Functions. Ve službě Azure Functions řídí služba hostitele a hostitele nemůžete přizpůsobit napsáním kódu. Azure Functions umožňuje přizpůsobit chování hostitele prostřednictvím nastavení v souboru host.json. Toto nastavení jsou řetězce, ne kód a použití těchto řetězců omezuje druhy přizpůsobení, které můžete provést.

Připojení hostitele

Sada WebJobs SDK hledá připojení Azure Storage a Azure Service Bus v souboru local.settings.json při místním spuštění nebo v prostředí webové úlohy při spuštění v Azure. Sada WebJobs SDK ve výchozím nastavení vyžaduje připojení k úložišti s názvem AzureWebJobsStorage.

Když se název připojení přeloží na jednu přesnou hodnotu, modul runtime identifikuje hodnotu jako připojovací řetězec, která obvykle obsahuje tajný kód. Podrobnosti o připojovací řetězec závisí na službě, ke které se připojujete. Název připojení ale může také odkazovat na kolekci více položek konfigurace, které jsou užitečné pro konfiguraci připojení založených na identitě. Proměnné prostředí lze považovat za kolekci pomocí sdílené předpony __, která končí dvojitým podtržítkem . Na skupinu pak můžete odkazovat nastavením názvu připojení na tuto předponu.

Například vlastnost definice triggeru connection objektu blob Azure může být Storage1. Pokud proměnná prostředí pojmenovaná Storage1proměnnou prostředí nenakonfiguruje žádnou hodnotu řetězce, může být použita proměnná prostředí, Storage1__blobServiceUri která by mohla informovat blobServiceUri vlastnost připojení. Vlastnosti připojení se pro každou službu liší. Projděte si dokumentaci ke komponentě, která připojení používá.

Připojení založená na identitách

Pokud chcete v sadě WebJobs SDK používat připojení založená na identitě, ujistěte se, že ve svém projektu používáte nejnovější verze balíčků WebJobs. Měli byste také zajistit, abyste měli odkaz na Microsoft.Azure.WebJobs.Host.Storage. Při nastavování WebJobs v nástroji HostBuilder nezapomeňte zahrnout volání AddAzureStorageCoreServices, protože to umožňuje AzureWebJobsStorage a další triggery a vazby úložiště používat identitu:

    builder.ConfigureWebJobs(b =>
    {
        b.AddAzureStorageCoreServices();
        // other configurations...
    });

Připojení pak můžete nakonfigurovat AzureWebJobsStorage nastavením proměnných prostředí (nebo nastavení aplikace při hostování ve službě App Service):

Proměnná prostředí	Popis	Příklad hodnoty
`AzureWebJobsStorage__blobServiceUri`	Identifikátor URI roviny dat služby blob účtu úložiště pomocí schématu HTTPS.	<https:// storage_account_name.blob.core.windows.net>
`AzureWebJobsStorage__queueServiceUri`	Identifikátor URI roviny dat služby fronty účtu úložiště pomocí schématu HTTPS.	<https:// storage_account_name.queue.core.windows.net>

Pokud konfiguraci zadáte prostřednictvím jiných prostředků než proměnných prostředí, jako appsettings.jsonjsou například proměnné prostředí, budete místo toho muset poskytnout strukturovanou konfiguraci pro připojení a její vlastnosti:

{
    "AzureWebJobsStorage": {
        "blobServiceUri": "https://<storage_account_name>.blob.core.windows.net",
        "queueServiceUri": "https://<storage_account_name>.queue.core.windows.net"
    }
}

Vlastnost můžete vynechat queueServiceUri , pokud neplánujete používat triggery objektů blob.

Když se kód spustí místně, ve výchozím nastavení se použije vaše identita vývojáře podle chování popsaného pro DefaultAzureCredential.

Pokud je váš kód hostovaný ve službě Aplikace Azure Service, konfigurace uvedená výše se ve výchozím nastavení nastaví na spravovanou identitu přiřazenou systémem pro daný prostředek. Pokud chcete místo toho použít identitu přiřazenou uživatelem, která byla přiřazena k aplikaci, musíte pro připojení přidat další vlastnosti, které určují, kterou identitu se má použít. Vlastnost credential (AzureWebJobsStorage__credential jako proměnná prostředí) by měla být nastavena na řetězec "managedidentity". Vlastnost clientId (AzureWebJobsStorage__clientId jako proměnná prostředí) by měla být nastavena na ID klienta spravované identity přiřazené uživatelem, která se má použít. Jako strukturovaná konfigurace by úplný objekt byl:

{
    "AzureWebJobsStorage": {
        "blobServiceUri": "https://<storage_account_name>.blob.core.windows.net",
        "queueServiceUri": "https://<storage_account_name>.queue.core.windows.net",
        "credential": "managedidentity",
        "clientId": "<user-assigned-identity-client-id>"
    }
}

Identita používaná pro AzureWebJobsStorage by měla mít přiřazení rolí, které jí udělí roli Vlastník dat objektů blob služby Storage, Přispěvatel dat fronty úložiště a Přispěvatel účtů úložiště. Pokud neplánujete používat triggery objektů blob, můžete vynechat přispěvatele dat fronty úložiště i přispěvatele účtu úložiště.

Následující tabulka ukazuje předdefinované role, které se doporučují při použití triggerů v vazbách v normálním provozu. Vaše aplikace může vyžadovat další oprávnění na základě kódu, který napíšete.

Vazba	Příklad předdefinovaných rolí
Aktivační událost objektu BLOB	Vlastník dat objektů blob služby Storage a Přispěvatel dat fronty úložiště Viz výše uvedené požadavky `AzureWebJobsStorage` také.
Objekt blob (vstup)	Čtenář dat v objektech blob služby Storage
Objekt blob (výstup)	Vlastník dat v objektech blob služby Storage
Aktivační událost fronty	Čtečka dat fronty úložiště, procesor zpráv fronty úložiště
Fronta (výstup)	Přispěvatel dat fronty úložiště, odesílatel dat fronty úložiště
Trigger^{služby Service Bus 1}	Příjemce dat služby Azure Service Bus, vlastník dat služby Azure Service Bus
Service Bus (výstup)	Odesílatel dat služby Azure Service Bus

¹ Pro aktivaci z témat služby Service Bus musí přiřazení role mít efektivní rozsah nad prostředkem předplatného služby Service Bus. Pokud je zahrnuto pouze téma, dojde k chybě. Někteří klienti, například web Azure Portal, nezpřístupňují prostředek předplatného služby Service Bus jako obor pro přiřazení role. V takových případech se místo toho může použít Azure CLI. Další informace najdete v tématu Předdefinované role Azure pro Azure Service Bus.

Připojovací řetězce ve verzi 2.x

Verze 2.X sady SDK nevyžaduje konkrétní název. Verze 2.X umožňuje používat pro tyto připojovací řetězec vlastní názvy a umožňuje je ukládat jinde. Názvy v kódu můžete nastavit následujícím způsobem JobHostConfiguration:

static void Main(string[] args)
{
    var _storageConn = ConfigurationManager
        .ConnectionStrings["MyStorageConnection"].ConnectionString;

    //// Dashboard logging is deprecated; use Application Insights.
    //var _dashboardConn = ConfigurationManager
    //    .ConnectionStrings["MyDashboardConnection"].ConnectionString;

    JobHostConfiguration config = new JobHostConfiguration();
    config.StorageConnectionString = _storageConn;
    //config.DashboardConnectionString = _dashboardConn;
    JobHost host = new JobHost(config);
    host.RunAndBlock();
}

Poznámka:

Vzhledem k tomu, že verze 3.x používá výchozí rozhraní API konfigurace .NET Core, neexistuje žádné rozhraní API ke změně připojovací řetězec názvů. Viz Vývoj a nasazení webových úloh pomocí sady Visual Studio

Nastavení vývoje hostitele

Hostitele můžete spustit v režimu vývoje, aby byl místní vývoj efektivnější. Tady jsou některá nastavení, která se automaticky mění při spuštění ve vývojovém režimu:

Vlastnost	Nastavení vývoje
`Tracing.ConsoleLevel`	`TraceLevel.Verbose` pro maximalizaci výstupu protokolu.
`Queues.MaxPollingInterval`	Nízká hodnota, která zajistí, že se metody fronty aktivují okamžitě.
`Singleton.ListenerLockPeriod`	15 sekund na pomoc při rychlém iterativním vývoji.

Proces povolení vývojového režimu závisí na verzi sady SDK.

Verze 3.x

Verze 3.x používá standardní rozhraní API ASP.NET Core. Zavolejte metodu UseEnvironment instance HostBuilder . Předejte řetězec s názvem development, jako v tomto příkladu:

static async Task Main()
{
    var builder = new HostBuilder();
    builder.UseEnvironment("development");
    builder.ConfigureWebJobs(b =>
            {
                b.AddAzureStorageCoreServices();
            });
    var host = builder.Build();
    using (host)
    {
        await host.RunAsync();
    }
}

Verze 2.x

Třída JobHostConfiguration má metodu UseDevelopmentSettings , která umožňuje vývojový režim. Následující příklad ukazuje, jak používat nastavení vývoje. Pokud chcete provést config.IsDevelopment vrácení true při místním spuštění, nastavte místní proměnnou prostředí s názvem AzureWebJobsEnv s hodnotou Development.

static void Main()
{
    config = new JobHostConfiguration();

    if (config.IsDevelopment)
    {
        config.UseDevelopmentSettings();
    }

    var host = new JobHost(config);
    host.RunAndBlock();
}

Správa souběžných připojení (verze 2.x)

Ve verzi 3.x, limit připojení je výchozí pro nekonečné připojení. Pokud z nějakého důvodu potřebujete tento limit změnit, můžete použít MaxConnectionsPerServer vlastnost WinHttpHandler třídy.

Ve verzi 2.x, řídíte počet souběžných připojení k hostiteli pomocí rozhraní ServicePointManager.DefaultConnectionLimit API. Ve 2.x, měli byste tuto hodnotu zvýšit z výchozí hodnoty 2 před spuštěním hostitele WebJobs.

Všechny odchozí požadavky HTTP, které provedete z funkce pomocí HttpClient toku přes ServicePointManager. Jakmile se dostanete k hodnotě nastavené v DefaultConnectionLimitčásti , ServicePointManager začne se požadavky před jejich odesláním zařadit do fronty. Předpokládejme, že je vaše DefaultConnectionLimit hodnota nastavená na 2 a váš kód provádí 1 000 požadavků HTTP. Na začátku jsou do operačního systému povoleny pouze dva požadavky. Ostatních 998 se zařadí do fronty, dokud pro ně není místo. To znamená HttpClient , že může dojít k vypršení časového limitu, protože se zdá, že požadavek odeslal, ale operační systém ho nikdy neodeslal na cílový server. Takže se může zdát, že chování, které se zdá být nedává smysl: dokončení požadavku trvá 10 sekund, HttpClient ale vaše služba vrací každý požadavek za 200 ms.

Výchozí hodnota pro ASP.NET aplikace je Int32.MaxValuea je pravděpodobné, že bude dobře fungovat pro webové úlohy spuštěné v plánu služby App Service Basic nebo vyšší. WebJobs obvykle potřebuje nastavení AlwaysOn , které podporuje jenom plány služby App Service Basic a vyšší.

Pokud vaše webová úloha běží v plánu bezplatné nebo sdílené služby App Service, je vaše aplikace omezena sandboxem služby App Service, který má aktuálně limit připojení 300. S limitem nevázaného připojení ServicePointManagerje pravděpodobnější, že se dosáhne prahové hodnoty připojení sandboxu a lokalita se vypne. V takovém případě může nastavení DefaultConnectionLimit na něco nižšího, například 50 nebo 100, zabránit tomu, aby k tomu došlo, a přesto umožnit dostatečnou propustnost.

Nastavení musí být nakonfigurováno před provedením jakýchkoli požadavků HTTP. Z tohoto důvodu by hostitel webových úloh neměl nastavení automaticky upravovat. Před spuštěním hostitele může dojít k požadavkům HTTP, což může vést k neočekávanému chování. Nejlepším přístupem je nastavit hodnotu okamžitě ve vaší Main metodě před inicializací JobHost, jak je znázorněno zde:

static void Main(string[] args)
{
    // Set this immediately so that it's used by all requests.
    ServicePointManager.DefaultConnectionLimit = Int32.MaxValue;

    var host = new JobHost();
    host.RunAndBlock();
}

Aktivační události

Sada WebJobs SDK podporuje stejnou sadu triggerů a vazeb, které služba Azure Functions používá. Upozorňujeme, že v sadě WebJobs SDK jsou triggery specifické pro funkci a nesouvisejí s typem nasazení webové úlohy. Webové úlohy s funkcemi aktivovanými událostmi vytvořenými pomocí sady SDK by se vždy měly publikovat jako průběžná webová úloha s povolenou funkcí AlwaysOn .

Funkce musí být veřejné metody a musí mít jeden atribut triggeru NoAutomaticTrigger nebo atribut.

Automatické triggery

Automatické triggery volají funkci v reakci na událost. Podívejte se na tento příklad funkce aktivované zprávou přidanou do služby Azure Queue Storage. Funkce reaguje čtením objektu blob ze služby Azure Blob Storage:

public static void Run(
    [QueueTrigger("myqueue-items")] string myQueueItem,
    [Blob("samples-workitems/{queueTrigger}", FileAccess.Read)] Stream myBlob,
    ILogger log)
{
    log.LogInformation($"BlobInput processed blob\n Name:{myQueueItem} \n Size: {myBlob.Length} bytes");
}

Atribut QueueTrigger říká modulu runtime, aby volal funkci při každém zobrazení zprávy fronty .myqueue-items Atribut Blob říká modulu runtime, aby pomocí zprávy fronty přečetl objekt blob v kontejneru sample-workitems . Název položky objektu blob v kontejneru samples-workitems se získá přímo z triggeru fronty jako vazbový výraz ({queueTrigger}).

Poznámka:

Webová aplikace může časový limit vyprší po 20 minutách nečinnosti a časovač může resetovat jenom požadavky na skutečnou webovou aplikaci. Zobrazení konfigurace aplikace na webu Azure Portal nebo provádění požadavků na webhttps://<app_name>.scm.azurewebsites.net rozšířených nástrojů () nenuluje časovač. Pokud nastavíte webovou aplikaci, která hostuje vaši úlohu tak, aby běžela nepřetržitě, spouštěla podle plánu nebo používala triggery řízené událostmi, povolte nastavení AlwaysOn na stránce Konfigurace Azure vaší webové aplikace. Nastavení AlwaysOn pomáhá zajistit, aby tyto druhy webových úloh běžely spolehlivě. Tato funkce je dostupná jenom v cenových úrovních Basic, Standard a Premium.

Ruční aktivační události

Pokud chcete funkci aktivovat ručně, použijte NoAutomaticTrigger atribut, jak je znázorněno tady:

[NoAutomaticTrigger]
public static void CreateQueueMessage(
ILogger logger,
string value,
[Queue("outputqueue")] out string message)
{
    message = value;
    logger.LogInformation("Creating queue message: ", message);
}

Proces ruční aktivace funkce závisí na verzi sady SDK.

Verze 3.x

static async Task Main(string[] args)
{
    var builder = new HostBuilder();
    builder.ConfigureWebJobs(b =>
    {
        b.AddAzureStorageCoreServices();
        b.AddAzureStorage();
    });
    var host = builder.Build();
    using (host)
    {
        var jobHost = host.Services.GetService(typeof(IJobHost)) as JobHost;
        var inputs = new Dictionary<string, object>
        {
            { "value", "Hello world!" }
        };

        await host.StartAsync();
        await jobHost.CallAsync("CreateQueueMessage", inputs);
        await host.StopAsync();
    }
}

Verze 2.x

static void Main(string[] args)
{
    JobHost host = new JobHost();
    host.Call(typeof(Program).GetMethod("CreateQueueMessage"), new { value = "Hello world!" });
}

Vstupní a výstupní vazby

Vstupní vazby poskytují deklarativní způsob zpřístupnění dat z Azure nebo služeb třetích stran pro váš kód. Výstupní vazby poskytují způsob aktualizace dat. Článek Začínáme ukazuje příklad každého z nich.

Návratovou hodnotu metody pro výstupní vazbu můžete použít použitím atributu na návratovou hodnotu metody. Podívejte se na příklad použití návratové hodnoty funkce Azure Functions.

Typy vazeb

Proces instalace a správy typů vazeb závisí na tom, jestli používáte verzi 3.x nebo verze 2.x sady SDK. Balíček, který se má nainstalovat pro určitý typ vazby, najdete v části Balíčky v referenčním článku o službě Azure Functions daného typu vazby. Výjimkou je trigger a vazba souborů (pro místní systém souborů), které azure Functions nepodporuje.

Verze 3.x

Ve verzi 3.x, vazby úložiště jsou součástí Microsoft.Azure.WebJobs.Extensions.Storage balíčku. Volejte metodu AddAzureStorage ConfigureWebJobs rozšíření v metodě, jak je znázorněno zde:

static async Task Main()
{
    var builder = new HostBuilder();
    builder.ConfigureWebJobs(b =>
            {
                b.AddAzureStorageCoreServices();
                b.AddAzureStorage();
            });
    var host = builder.Build();
    using (host)
    {
        await host.RunAsync();
    }
}

Pokud chcete použít jiné typy triggerů a vazeb, nainstalujte balíček NuGet, který je obsahuje, a zavolejte metodu Add<binding> rozšíření implementovanou v rozšíření. Pokud například chcete použít vazbu Azure Cosmos DB, nainstalujte Microsoft.Azure.WebJobs.Extensions.CosmosDB a volejte AddCosmosDB, například takto:

static async Task Main()
{
    var builder = new HostBuilder();
    builder.ConfigureWebJobs(b =>
            {
                b.AddAzureStorageCoreServices();
                b.AddCosmosDB();
            });
    var host = builder.Build();
    using (host)
    {
        await host.RunAsync();
    }
}

Pokud chcete použít trigger časovače nebo vazbu Soubory, které jsou součástí základních služeb, volejte AddTimers metody nebo AddFiles metody rozšíření.

Verze 2.x

Tyto typy triggerů a vazeb jsou součástí verze 2.x balíčku Microsoft.Azure.WebJobs :

Blob Storage
Queue Storage
Table Storage

Chcete-li použít jiné typy triggerů a vazeb, nainstalujte balíček NuGet, který je obsahuje, a zavolejte metodu Use<binding> na objektu JobHostConfiguration . Pokud například chcete použít trigger časovače, nainstalujte do metody volání a nainstalujte Microsoft.Azure.WebJobs.Extensions ho UseTimers Main , jak je znázorněno tady:

static void Main()
{
    config = new JobHostConfiguration();
    config.UseTimers();
    var host = new JobHost(config);
    host.RunAndBlock();
}

Chcete-li použít vazbu Soubory, nainstalujte Microsoft.Azure.WebJobs.Extensions a zavolejte UseFiles.

ExecutionContext

WebJobs umožňuje vytvořit vazbu k objektu ExecutionContext. Pomocí této vazby můžete přistupovat ExecutionContext jako parametr v podpisu funkce. Například následující kód používá kontextový objekt pro přístup k ID vyvolání, které můžete použít ke korelaci všech protokolů vytvořených voláním dané funkce.

public class Functions
{
    public static void ProcessQueueMessage([QueueTrigger("queue")] string message,
        ExecutionContext executionContext,
        ILogger logger)
    {
        logger.LogInformation($"{message}\n{executionContext.InvocationId}");
    }
}

Proces vazby ExecutionContext na vazbu závisí na vaší verzi sady SDK.

Verze 3.x

Volejte metodu AddExecutionContextBinding ConfigureWebJobs rozšíření v metodě, jak je znázorněno zde:

static async Task Main()
{
    var builder = new HostBuilder();
    builder.ConfigureWebJobs(b =>
            {
                b.AddAzureStorageCoreServices();
                b.AddExecutionContextBinding();
            });
    var host = builder.Build();
    using (host)
    {
        await host.RunAsync();
    }
}

Verze 2.x

Balíček Microsoft.Azure.WebJobs.Extensions uvedený dříve také poskytuje speciální typ vazby, který můžete zaregistrovat voláním UseCore metody. Tato vazba umožňuje definovat ExecutionContext parametr v podpisu funkce, který je povolený takto:

class Program
{
    static void Main()
    {
        config = new JobHostConfiguration();
        config.UseCore();
        var host = new JobHost(config);
        host.RunAndBlock();
    }
}

Konfigurace vazby

Můžete nakonfigurovat chování některých triggerů a vazeb. Proces jejich konfigurace závisí na verzi sady SDK.

Verze 3.x: Nastavte konfiguraci při Add<Binding> zavolání ConfigureWebJobsmetody .
Verze 2.x: Nastavení konfigurace nastavením vlastností v objektu konfigurace, který předáte JobHost.

Tato nastavení specifická pro vazbu jsou ekvivalentní nastavení v souboru projektu host.json ve službě Azure Functions.

Můžete nakonfigurovat následující vazby:

Trigger služby Azure Cosmos DB
Trigger služby Event Hubs
Trigger služby Queue Storage
Vazba SendGrid
Trigger služby Service Bus

Konfigurace triggeru služby Azure Cosmos DB (verze 3.x)

Tento příklad ukazuje, jak nakonfigurovat trigger služby Azure Cosmos DB:

static async Task Main()
{
    var builder = new HostBuilder();
    builder.ConfigureWebJobs(b =>
    {
        b.AddAzureStorageCoreServices();
        b.AddCosmosDB(a =>
        {
            a.ConnectionMode = ConnectionMode.Gateway;
            a.Protocol = Protocol.Https;
            a.LeaseOptions.LeasePrefix = "prefix1";

        });
    });
    var host = builder.Build();
    using (host)
    {
        await host.RunAsync();
    }
}

Další informace najdete v článku o vazbách služby Azure Cosmos DB.

Konfigurace triggeru event Hubs (verze 3.x)

Tento příklad ukazuje, jak nakonfigurovat trigger služby Event Hubs:

static async Task Main()
{
    var builder = new HostBuilder();
    builder.ConfigureWebJobs(b =>
    {
        b.AddAzureStorageCoreServices();
        b.AddEventHubs(a =>
        {
            a.BatchCheckpointFrequency = 5;
            a.EventProcessorOptions.MaxBatchSize = 256;
            a.EventProcessorOptions.PrefetchCount = 512;
        });
    });
    var host = builder.Build();
    using (host)
    {
        await host.RunAsync();
    }
}

Další informace najdete v článku vazby služby Event Hubs.

Konfigurace triggeru služby Queue Storage

Následující příklady ukazují, jak nakonfigurovat trigger služby Queue Storage.

Verze 3.x

static async Task Main()
{
    var builder = new HostBuilder();
    builder.ConfigureWebJobs(b =>
    {
        b.AddAzureStorageCoreServices();
        b.AddAzureStorage(a => {
            a.BatchSize = 8;
            a.NewBatchThreshold = 4;
            a.MaxDequeueCount = 4;
            a.MaxPollingInterval = TimeSpan.FromSeconds(15);
        });
    });
    var host = builder.Build();
    using (host)
    {
        await host.RunAsync();
    }
}

Další informace najdete v článku vazby služby Queue Storage.

Verze 2.x

static void Main(string[] args)
{
    JobHostConfiguration config = new JobHostConfiguration();
    config.Queues.BatchSize = 8;
    config.Queues.NewBatchThreshold = 4;
    config.Queues.MaxDequeueCount = 4;
    config.Queues.MaxPollingInterval = TimeSpan.FromSeconds(15);
    JobHost host = new JobHost(config);
    host.RunAndBlock();
}

Další informace najdete v referenčních informacích k host.json v1.x.

Konfigurace vazby SendGrid (verze 3.x)

Tento příklad ukazuje, jak nakonfigurovat výstupní vazbu SendGrid:

static async Task Main()
{
    var builder = new HostBuilder();
    builder.ConfigureWebJobs(b =>
    {
        b.AddAzureStorageCoreServices();
        b.AddSendGrid(a =>
        {
            a.FromAddress.Email = "samples@functions.com";
            a.FromAddress.Name = "Azure Functions";
        });
    });
    var host = builder.Build();
    using (host)
    {
        await host.RunAsync();
    }
}

Další informace najdete v článku o vazbě SendGrid.

Konfigurace triggeru služby Service Bus (verze 3.x)

Tento příklad ukazuje, jak nakonfigurovat trigger služby Service Bus:

static async Task Main()
{
    var builder = new HostBuilder();
    builder.ConfigureWebJobs(b =>
    {
        b.AddAzureStorageCoreServices();
        b.AddServiceBus(sbOptions =>
        {
            sbOptions.MessageHandlerOptions.AutoComplete = true;
            sbOptions.MessageHandlerOptions.MaxConcurrentCalls = 16;
        });
    });
    var host = builder.Build();
    using (host)
    {
        await host.RunAsync();
    }
}

Další podrobnosti najdete v článku vazby služby Service Bus.

Konfigurace pro další vazby

Některé typy triggerů a vazeb definují vlastní typy konfigurace. Trigger File například umožňuje zadat kořenovou cestu, kterou chcete monitorovat, jako v následujících příkladech.

Verze 3.x

static async Task Main()
{
    var builder = new HostBuilder();
    builder.ConfigureWebJobs(b =>
    {
        b.AddAzureStorageCoreServices();
        b.AddFiles(a => a.RootPath = @"c:\data\import");
    });
    var host = builder.Build();
    using (host)
    {
        await host.RunAsync();
    }
}

Verze 2.x

static void Main()
{
    config = new JobHostConfiguration();
    var filesConfig = new FilesConfiguration
    {
        RootPath = @"c:\data\import"
    };
    config.UseFiles(filesConfig);
    var host = new JobHost(config);
    host.RunAndBlock();
}

Vazbové výrazy

V parametrech konstruktoru atributů můžete použít výrazy, které se přeloží na hodnoty z různých zdrojů. Například v následujícím kódu cesta pro BlobTrigger atribut vytvoří výraz s názvem filename. Při použití pro výstupní vazbu se filename přeloží na název aktivačního objektu blob.

public static void CreateThumbnail(
    [BlobTrigger("sample-images/{filename}")] Stream image,
    [Blob("sample-images-sm/{filename}", FileAccess.Write)] Stream imageSmall,
    string filename,
    ILogger logger)
{
    logger.Info($"Blob trigger processing: {filename}");
    // ...
}

Další informace o vazbových výrazech najdete v tématu Vazbové výrazy a vzory v dokumentaci ke službě Azure Functions.

Vlastní vazbové výrazy

Někdy chcete místo pevného kódování zadat název fronty, název objektu blob nebo kontejner nebo název tabulky v kódu. Můžete například chtít zadat název fronty pro QueueTrigger atribut v konfiguračním souboru nebo proměnné prostředí.

Můžete to provést předáním vlastního překladače názvů během konfigurace. Do parametrů konstruktoru triggeru nebo vazby zahrnete zástupné symboly a kód překladače poskytuje skutečné hodnoty, které se mají použít místo těchto zástupných symbolů. Zástupné symboly identifikujete tak, že je obklopíte znaménkami procenta (%), jak je znázorněno tady:

public static void WriteLog([QueueTrigger("%logqueue%")] string logMessage)
{
    Console.WriteLine(logMessage);
}

Tento kód umožňuje použít frontu pojmenovanou logqueuetest v testovacím prostředí a frontu pojmenovanou logqueueprod v produkčním prostředí. Místo pevně zakódovaného názvu fronty zadáte název položky v kolekci appSettings .

Výchozí překladač se projeví, pokud nezadáte vlastní překladač. Výchozí hodnota získá hodnoty z nastavení aplikace nebo proměnných prostředí.

Od verze .NET Core 3.1 ConfigurationManager vyžaduje, aby byl balíček NuGet System.Configuration.ConfigurationManager. Ukázka vyžaduje následující using příkaz:

using System.Configuration;

Vaše NameResolver třída získá název fronty z nastavení aplikace, jak je znázorněno tady:

public class CustomNameResolver : INameResolver
{
    public string Resolve(string name)
    {
        return ConfigurationManager.AppSettings[name].ToString();
    }
}

Verze 3.x

Překladač nakonfigurujete pomocí injektáže závislostí. Tyto ukázky vyžadují následující using příkaz:

using Microsoft.Extensions.DependencyInjection;

Překladač přidáte voláním ConfigureServices metody rozšíření on HostBuilder, jak je uvedeno v tomto příkladu:

static async Task Main(string[] args)
{
    var builder = new HostBuilder();
    var resolver = new CustomNameResolver();
    builder.ConfigureWebJobs(b =>
    {
        b.AddAzureStorageCoreServices();
    });
    builder.ConfigureServices(s => s.AddSingleton<INameResolver>(resolver));
    var host = builder.Build();
    using (host)
    {
        await host.RunAsync();
    }
}

Verze 2.x

Předejte předmět NameResolver objektu JobHost , jak je znázorněno tady:

 static void Main(string[] args)
{
    JobHostConfiguration config = new JobHostConfiguration();
    config.NameResolver = new CustomNameResolver();
    JobHost host = new JobHost(config);
    host.RunAndBlock();
}

Azure Functions implementuje INameResolver získání hodnot z nastavení aplikace, jak je znázorněno v příkladu. Když používáte sadu WebJobs SDK přímo, můžete napsat vlastní implementaci, která získá zástupné hodnoty nahrazení z libovolného zdroje, který dáváte přednost.

Vazba za běhu

Pokud potřebujete nějakou práci ve své funkci před použitím atributu vazby, jako Queueje , Blobnebo Table, můžete použít IBinder rozhraní.

Následující příklad přebírá zprávu vstupní fronty a vytvoří novou zprávu se stejným obsahem ve výstupní frontě. Název výstupní fronty je nastaven kódem v těle funkce.

public static void CreateQueueMessage(
    [QueueTrigger("inputqueue")] string queueMessage,
    IBinder binder)
{
    string outputQueueName = "outputqueue" + DateTime.Now.Month.ToString();
    QueueAttribute queueAttribute = new QueueAttribute(outputQueueName);
    CloudQueue outputQueue = binder.Bind<CloudQueue>(queueAttribute);
    outputQueue.AddMessageAsync(new CloudQueueMessage(queueMessage));
}

Další informace najdete v tématu Vazba za běhu v dokumentaci ke službě Azure Functions.

Referenční informace o vazbě

Dokumentace ke službě Azure Functions obsahuje referenční informace o jednotlivých typech vazeb. V každém článku s referenčními informacemi o vazbách najdete následující informace. (Tento příklad je založený na frontě služby Storage.)

Balíčky. Balíček, který je potřeba nainstalovat, aby zahrnoval podporu vazby v projektu sady WebJobs SDK.
Příklady. Ukázky kódu Příklad knihovny tříd jazyka C# se vztahuje na sadu WebJobs SDK. Stačí vynechat FunctionName atribut.
Atributy. Atributy, které se mají použít pro typ vazby.
Konfigurace: Vysvětlení vlastností atributu a parametrů konstruktoru
Využití. Typy, se které můžete svázat, a informace o tom, jak vazba funguje. Například: algoritmus dotazování, zpracování jedové fronty.

Poznámka:

Vazby HTTP, Webhooky a Event Gridu jsou podporovány pouze službou Azure Functions, nikoli sadou WebJobs SDK.

Úplný seznam vazeb podporovaných v modulu runtime Azure Functions najdete v tématu Podporované vazby.

Atributy pro zákaz, vypršení časového limitu a singletonu

Pomocí těchto atributů můžete řídit spouštění funkcí, rušit funkce a zajistit, aby se spustila pouze jedna instance funkce.

Zakázat atribut

Atribut Disable umožňuje řídit, jestli je možné aktivovat funkci.

Pokud má nastavení Disable_TestJob aplikace v následujícím příkladu hodnotu 1 nebo True (nerozlišuje malá a velká písmena), funkce se nespustí. V takovém případě modul runtime vytvoří funkci zprávy protokolu Functions.TestJob je zakázaná.

[Disable("Disable_TestJob")]
public static void TestJob([QueueTrigger("testqueue2")] string message)
{
    Console.WriteLine("Function with Disable attribute executed!");
}

Když změníte hodnoty nastavení aplikace na webu Azure Portal, webová úloha se restartuje, aby se obnovilo nové nastavení.

Atribut lze deklarovat na úrovni parametru, metody nebo třídy. Název nastavení může také obsahovat vazbové výrazy.

Atribut časového limitu

Atribut Timeout způsobí zrušení funkce, pokud se nedokončí v zadaném časovém intervalu. V následujícím příkladu by funkce běžela jeden den bez atributu Timeout. Časový limit způsobí zrušení funkce po 15 sekundách. Pokud je parametr "throwOnError" atributu časového limitu nastavený na hodnotu true, vyvolání funkce se ukončí tím, že při překročení časového limitu dojde k výjimce vyvolané sadou WEBJOBS SDK. Výchozí hodnota throwOnError je false. Při použití atributu časového limitu je výchozím chováním zrušení vyvolání funkce nastavením tokenu zrušení a povolením spuštění vyvolání po neomezenou dobu, dokud kód funkce nevrátí nebo vyvolá výjimku.

[Timeout("00:00:15")]
public static async Task TimeoutJob(
    [QueueTrigger("testqueue2")] string message,
    CancellationToken token,
    TextWriter log)
{
    await log.WriteLineAsync("Job starting");
    await Task.Delay(TimeSpan.FromDays(1), token);
    await log.WriteLineAsync("Job completed");
}

Atribut Timeout můžete použít na úrovni třídy nebo metody a můžete určit globální časový limit pomocí JobHostConfiguration.FunctionTimeout. Časové limity na úrovni třídy nebo metody přepisují globální časové limity.

Singleton – atribut

Atribut Singleton zajišťuje, že se spustí pouze jedna instance funkce, i když existuje více instancí hostitelské webové aplikace. Atribut Singleton používá distribuované uzamčení , aby se zajistilo, že se spustí jedna instance.

V tomto příkladu se v daném okamžiku ProcessImage spustí pouze jedna instance funkce:

[Singleton]
public static async Task ProcessImage([BlobTrigger("images")] Stream image)
{
     // Process the image.
}

SingletonMode.Listener

Některé triggery mají integrovanou podporu pro správu souběžnosti:

QueueTrigger. Nastavte JobHostConfiguration.Queues.BatchSize na hodnotu 1.
ServiceBusTrigger. Nastavte ServiceBusConfiguration.MessageOptions.MaxConcurrentCalls na hodnotu 1.
FileTrigger. Nastavte FileProcessor.MaxDegreeOfParallelism na hodnotu 1.

Pomocí těchto nastavení můžete zajistit, aby se vaše funkce spouštěla jako jednoúčelová instance. Pokud chcete zajistit, aby se při horizontálním navýšení kapacity webové aplikace na více instancí spustila pouze jedna instance funkce, použijte u funkce zámek singletonu na úrovni naslouchacího procesu.[Singleton(Mode = SingletonMode.Listener)] Zámky naslouchacího procesu se získávají při spuštění JobHost. Pokud se všechny tři instance s horizontálním navýšením kapacity spustí současně, získá zámek pouze jedna z instancí a spustí se pouze jeden naslouchací proces.

Poznámka:

Další informace o tom, jak SingletonMode.Function funguje, najdete v tomto úložišti GitHubu.

Hodnoty oboru

Pro singleton můžete zadat výraz nebo hodnotu oboru. Výraz/hodnota zajišťuje, že budou serializována všechna spuštění funkce v určitém oboru. Implementace podrobnějšího zamykání tímto způsobem může umožňovat určitou úroveň paralelismu pro vaši funkci, zatímco serializace jiných vyvolání podle vašich požadavků. Například výraz oboru v následujícím kódu vytvoří vazbu na Region hodnotu příchozí zprávy. Pokud fronta obsahuje tři zprávy v oblastech – východ, Východ a Západ, zprávy, které mají oblast – východ, se spouští sériově. Zpráva s oblastí – západ je spuštěna paralelně s těmi v oblasti – východ.

[Singleton("{Region}")]
public static async Task ProcessWorkItem([QueueTrigger("workitems")] WorkItem workItem)
{
     // Process the work item.
}

public class WorkItem
{
     public int ID { get; set; }
     public string Region { get; set; }
     public int Category { get; set; }
     public string Description { get; set; }
}

SingletonScope.Host

Výchozí obor zámku je SingletonScope.Function, což znamená, že obor zámku (cesta zapůjčení objektu blob) je svázaný s plně kvalifikovaným názvem funkce. Pokud chcete uzamknout všechny funkce, zadejte SingletonScope.Host a použijte název ID oboru, který je stejný pro všechny funkce, které nechcete spouštět současně. V následujícím příkladu je najednou spuštěna pouze jedna instance AddItem nebo RemoveItem spuštění:

[Singleton("ItemsLock", SingletonScope.Host)]
public static void AddItem([QueueTrigger("add-item")] string message)
{
     // Perform the add operation.
}

[Singleton("ItemsLock", SingletonScope.Host)]
public static void RemoveItem([QueueTrigger("remove-item")] string message)
{
     // Perform the remove operation.
}

Zobrazení objektů blob zapůjčení

Sada WebJobs SDK používá zapůjčení objektů blob Azure v rámci krytů k implementaci distribuovaného uzamčení. Objekty blob zapůjčení používané singletonem najdete v azure-webjobs-host kontejneru v AzureWebJobsStorage účtu úložiště v cestě "zámky". Například cesta k objektu blob zapůjčení pro první ProcessImage příklad, který je znázorněn dříve, může být locks/061851c758f04938a4426aa9ab3869c0/WebJobs.Functions.ProcessImage. Všechny cesty zahrnují ID JobHost, v tomto případě 061851c758f04938a426aa9ab3869c0.

Asynchronní funkce

Informace o tom, jak kódovat asynchronní funkce, najdete v dokumentaci ke službě Azure Functions.

Tokeny zrušení

Informace o tom, jak zpracovávat tokeny zrušení, najdete v dokumentaci ke službě Azure Functions o tokenech zrušení a řádném vypnutí.

Několik instancí

Pokud vaše webová aplikace běží na více instancích, běží nepřetržitá webová úloha na každé instanci a naslouchá aktivačním událostem a volajícím funkcím. Různé aktivační vazby jsou navržené tak, aby efektivně sdílely spolupráci napříč instancemi, takže horizontální navýšení kapacity na více instancí umožňuje zpracovat větší zatížení.

I když některé triggery můžou způsobit dvojité zpracování, triggery fronty a úložiště objektů blob automaticky brání funkci ve zpracování zprávy fronty nebo objektu blob více než jednou. Další informace najdete v tématu Navrhování identických vstupů v dokumentaci ke službě Azure Functions.

Trigger časovače automaticky zajišťuje, že se spustí jenom jedna instance časovače, takže v daném naplánovaném čase nebudete mít spuštěných více instancí funkcí.

Pokud chcete zajistit, aby se spustila pouze jedna instance funkce, i když existuje více instancí hostitelské webové aplikace, můžete použít Singleton atribut.

Filtry

Filtry funkcí (Preview) poskytují způsob, jak přizpůsobit kanál spouštění webových úloh vlastní logikou. Filtry se podobají filtrům ASP.NET Core. Můžete je implementovat jako deklarativní atributy, které se použijí na vaše funkce nebo třídy. Další informace najdete v tématu Filtry funkcí.

Protokolování a monitorování

Doporučujeme rozhraní protokolování vyvinuté pro ASP.NET. Článek Začínáme ukazuje, jak ho používat.

Filtrování protokolů

Každý protokol vytvořený ILogger instancí má přidruženou Category a Level. LogLevel je výčet a celočíselná hodnota kódu označuje relativní důležitost:

ÚroveňProtokolu	Kód
Trasování	0
Ladění	0
Informační	2
Upozorňující	3
Chyba	4
Kritické	5
Nic	6

Každou kategorii můžete nezávisle filtrovat na určitou LogLevelkategorii . Můžete například chtít zobrazit všechny protokoly pro zpracování triggeru objektu blob, ale jenom Error a vyšší pro všechno ostatní.

Verze 3.x

Verze 3.X sady SDK spoléhá na filtrování integrované do .NET Core. Třída LogCategories umožňuje definovat kategorie pro konkrétní funkce, triggery nebo uživatele. Definuje také filtry pro konkrétní stavy hostitelů, například Startup a Results. To vám umožní vyladit výstup protokolování. Pokud se v definovaných kategoriích nenajde žádná shoda, filtr se vrátí k hodnotě Default při rozhodování, jestli se má zpráva filtrovat.

LogCategories vyžaduje následující příkaz using:

using Microsoft.Azure.WebJobs.Logging;

Následující příklad vytvoří filtr, který ve výchozím nastavení filtruje všechny protokoly na Warning úrovni. Kategorie Function a results kategorie (ekvivalentní Host.Results ve verzi 2.x) se filtrují na Error úrovni. Filtr porovná aktuální kategorii se všemi registrovanými úrovněmi v LogCategories instanci a zvolí nejdelší shodu. To znamená, že úroveň registrovaná Debug pro Host.Triggers shody Host.Triggers.Queue nebo Host.Triggers.Blob. To vám umožní řídit širší kategorie, aniž byste museli přidávat jednotlivé kategorie.

static async Task Main(string[] args)
{
    var builder = new HostBuilder();
    builder.ConfigureWebJobs(b =>
    {
        b.AddAzureStorageCoreServices();
    });
    builder.ConfigureLogging(logging =>
            {
                logging.SetMinimumLevel(LogLevel.Warning);
                logging.AddFilter("Function", LogLevel.Error);
                logging.AddFilter(LogCategories.CreateFunctionCategory("MySpecificFunctionName"),
                    LogLevel.Debug);
                logging.AddFilter(LogCategories.Results, LogLevel.Error);
                logging.AddFilter("Host.Triggers", LogLevel.Debug);
            });
    var host = builder.Build();
    using (host)
    {
        await host.RunAsync();
    }
}

Verze 2.x

Ve verzi 2.x sady SDK, použijete LogCategoryFilter třídu k řízení filtrování. Default Má LogCategoryFilter vlastnost s počáteční hodnotou Information, což znamená, že všechny zprávy na Information, Warning, Errornebo Critical úrovně jsou protokolovány, ale všechny zprávy na Debug úrovni nebo Trace jsou filtrovány pryč.

LogCategories Stejně jako ve verzi 3.x, CategoryLevels vlastnost umožňuje zadat úrovně protokolu pro konkrétní kategorie, abyste mohli vyladit výstup protokolování. Pokud se ve slovníku CategoryLevels nenajde žádná shoda, filtr se vrátí k hodnotě Default při rozhodování, jestli se má zpráva filtrovat.

Následující příklad vytvoří filtr, který ve výchozím nastavení filtruje všechny protokoly na Warning úrovni. Kategorie Function a Host.Results kategorie se filtrují na Error úrovni. Porovná LogCategoryFilter aktuální kategorii se všemi registrovanými CategoryLevels a zvolí nejdelší shodu. Úroveň registrovaná Debug pro Host.Triggers se tedy bude shodovat Host.Triggers.Queue nebo Host.Triggers.Blob. To vám umožní řídit širší kategorie, aniž byste museli přidávat jednotlivé kategorie.

var filter = new LogCategoryFilter();
filter.DefaultLevel = LogLevel.Warning;
filter.CategoryLevels[LogCategories.Function] = LogLevel.Error;
filter.CategoryLevels[LogCategories.Results] = LogLevel.Error;
filter.CategoryLevels["Host.Triggers"] = LogLevel.Debug;

config.LoggerFactory = new LoggerFactory()
    .AddApplicationInsights(instrumentationKey, filter.Filter)
    .AddConsole(filter.Filter);

Vlastní telemetrie pro Application Insights

Proces implementace vlastní telemetrie pro Application Insights závisí na verzi sady SDK. Informace o konfiguraci Application Insights najdete v tématu Přidání protokolování Application Insights.

Verze 3.x

Vzhledem k tomu, že verze 3.X sady WebJobs SDK spoléhá na obecného hostitele .NET Core, vlastní objekt pro vytváření telemetrie už není k dispozici. Vlastní telemetrii ale můžete do kanálu přidat pomocí injektáže závislostí. Příklady v této části vyžadují následující using příkazy:

using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.ApplicationInsights.Channel;

Následující vlastní implementace ITelemetryInitializer umožňuje přidat vlastní ITelemetry do výchozího TelemetryConfiguration.

internal class CustomTelemetryInitializer : ITelemetryInitializer
{
    public void Initialize(ITelemetry telemetry)
    {
        // Do something with telemetry.
    }
}

Voláním ConfigureServices v tvůrci přidejte vlastní ITelemetryInitializer do kanálu.

static async Task Main()
{
    var builder = new HostBuilder();
    builder.ConfigureWebJobs(b =>
    {
        b.AddAzureStorageCoreServices();
    });
    builder.ConfigureLogging((context, b) =>
    {
        // Add logging providers.
        b.AddConsole();

        // If this key exists in any config, use it to enable Application Insights.
        string appInsightsKey = context.Configuration["APPINSIGHTS_INSTRUMENTATIONKEY"];
        if (!string.IsNullOrEmpty(appInsightsKey))
        {
            // This uses the options callback to explicitly set the instrumentation key.
            b.AddApplicationInsights(o => o.InstrumentationKey = appInsightsKey);
        }
    });
    builder.ConfigureServices(services =>
        {
            services.AddSingleton<ITelemetryInitializer, CustomTelemetryInitializer>();
        });
    var host = builder.Build();
    using (host)
    {
        await host.RunAsync();
    }
}

TelemetryConfiguration Při vytváření jsou zahrnuty všechny registrované typyITelemetryInitializer. Další informace najdete v tématu Application Insights API pro vlastní události a metriky.

Ve verzi 3.x, už nemusíte vyprázdnit TelemetryClient , když se hostitel zastaví. Systém injektáž závislostí .NET Core automaticky vyprázdní zaregistrovaný ApplicationInsightsLoggerProvidersystém , který vyprázdní TelemetryClient.

Verze 2.x

Ve verzi 2.x, TelemetryClient vytvořený interně poskytovatelem Application Insights pro sadu WebJobs SDK používá ServerTelemetryChannel. Pokud koncový bod Application Insights není dostupný nebo ruší příchozí požadavky, tento kanál ukládá žádosti do systému souborů webové aplikace a odešle je později znovu.

Je TelemetryClient vytvořen třídou, která implementuje ITelemetryClientFactory. Ve výchozím nastavení je to .DefaultTelemetryClientFactory

Pokud chcete upravit jakoukoli část kanálu Application Insights, můžete zadat vlastní ITelemetryClientFactorya hostitel použije vaši třídu k vytvoření TelemetryClient. Tento kód například přepíše DefaultTelemetryClientFactory úpravu vlastnosti ServerTelemetryChannel:

private class CustomTelemetryClientFactory : DefaultTelemetryClientFactory
{
    public CustomTelemetryClientFactory(string instrumentationKey, Func<string, LogLevel, bool> filter)
        : base(instrumentationKey, new SamplingPercentageEstimatorSettings(), filter)
    {
    }

    protected override ITelemetryChannel CreateTelemetryChannel()
    {
        ServerTelemetryChannel channel = new ServerTelemetryChannel();

        // Change the default from 30 seconds to 15 seconds.
        channel.MaxTelemetryBufferDelay = TimeSpan.FromSeconds(15);

        return channel;
    }
}

Objekt SamplingPercentageEstimatorSettings konfiguruje adaptivní vzorkování. To znamená, že v určitých scénářích s velkým objemem odesílá Application Insights na server vybranou podmnožinu telemetrických dat.

Po vytvoření objektu pro vytváření telemetrie ji předáte poskytovateli protokolování Application Insights:

var clientFactory = new CustomTelemetryClientFactory(instrumentationKey, filter.Filter);

config.LoggerFactory = new LoggerFactory()
    .AddApplicationInsights(clientFactory);

Další kroky

Tento článek obsahuje fragmenty kódu, které ukazují, jak zpracovávat běžné scénáře práce se sadou WebJobs SDK. Kompletní ukázky najdete v tématu azure-webjobs-sdk-samples.

Sdílet prostřednictvím

Jak použít sadu Azure WebJobs SDK k událostmi řízenému zpracování na pozadí

Verze sady WebJobs SDK

Hostitel webových úloh

Připojení hostitele

Připojení založená na identitách

Připojovací řetězce ve verzi 2.x

Nastavení vývoje hostitele

Verze 3.x

Verze 2.x

Správa souběžných připojení (verze 2.x)

Aktivační události

Automatické triggery

Ruční aktivační události

Verze 3.x

Verze 2.x

Vstupní a výstupní vazby

Typy vazeb

Verze 3.x

Verze 2.x

ExecutionContext

Verze 3.x

Verze 2.x

Konfigurace vazby

Konfigurace triggeru služby Azure Cosmos DB (verze 3.x)

Konfigurace triggeru event Hubs (verze 3.x)

Konfigurace triggeru služby Queue Storage

Verze 3.x

Verze 2.x

Konfigurace vazby SendGrid (verze 3.x)

Konfigurace triggeru služby Service Bus (verze 3.x)

Konfigurace pro další vazby

Verze 3.x

Verze 2.x

Vazbové výrazy

Vlastní vazbové výrazy

Verze 3.x

Verze 2.x

Vazba za běhu

Referenční informace o vazbě

Atributy pro zákaz, vypršení časového limitu a singletonu

Zakázat atribut

Atribut časového limitu

Singleton – atribut

SingletonMode.Listener

Hodnoty oboru

SingletonScope.Host

Zobrazení objektů blob zapůjčení

Asynchronní funkce

Tokeny zrušení

Několik instancí

Filtry

Protokolování a monitorování

Filtrování protokolů

Verze 3.x

Verze 2.x

Vlastní telemetrie pro Application Insights

Verze 3.x

Verze 2.x

Další kroky

Váš názor

Váš názor

Další materiály