Az Azure WebJobs SDK használata eseményalapú háttérfeldolgozáshoz

Cikk
06/13/2024

Ez a cikk útmutatást nyújt az Azure WebJobs SDK használatához. A WebJobs használatának első lépéseit az Azure WebJobs SDK használatának első lépéseiben találhatja meg.

WebJobs SDK-verziók

Ezek a 3. verzió közötti fő különbségek.x és 2-es verzió.x a WebJobs SDK-ból:

3-es verzió.x támogatja a .NET Core-t.
A 3. verzióban.x, telepíti a WebJobs SDK által igényelt Storage-kötési bővítményt. A 2. verzióban.x, a Storage-kötések az SDK részét képezik.
Visual Studio 2019 eszközkészlet a .NET Core-hoz (3.x) a projektek eltérnek a .NET-keretrendszer eszközkészletétől (2.x) projektek. További információ: WebJobs fejlesztése és üzembe helyezése a Visual Studio – Azure-alkalmazás Szolgáltatás használatával.

A cikkben szereplő leírások közül több is példákat mutat be a WebJobs 3-ás verziójára.x és WebJobs 2-es verzió.x.

Az Azure Functions a WebJobs SDK-ra épül.

Az Azure Functions 2-es verziója.x a WebJobs SDK 3-as verziójára épül.x.
Az Azure Functions 1-es verziója.x a WebJobs SDK 2-es verziójára épül.x.

Az Azure Functions és a WebJobs SDK forráskódtárai a WebJobs SDK számozását használják. A cikk több szakasza az Azure Functions dokumentációjára hivatkozik.

További információ: A WebJobs SDK és az Azure Functions összehasonlítása

WebJobs-gazdagép

A gazdagép egy futtatókörnyezeti tároló a függvényekhez. A gazdagép figyeli az eseményindítókat és a hívási függvényeket. A 3. verzióban.x, a gazdagép a .IHost A 2. verzióban.x, az objektumot JobHost használja. Létrehozhat egy gazdagéppéldányt a kódban, és kódot írhat annak viselkedésének testreszabásához.

Ez kulcsfontosságú különbség a WebJobs SDK közvetlen használata és az Azure Functionsen keresztüli közvetett használata között. Az Azure Functionsben a szolgáltatás vezérli a gazdagépet, és kód írásával nem szabhatja testre a gazdagépet. Az Azure Functions lehetővé teszi a gazdagép viselkedésének testreszabását a host.json fájl beállításaival. Ezek a beállítások sztringek, nem kód, és ezeknek a sztringeknek a használata korlátozza a testre szabható beállításokat.

Gazdagépkapcsolatok

A WebJobs SDK az Azure Storage- és Azure Service Bus-kapcsolatokat keresi a local.settings.json fájlban, amikor helyileg vagy a WebJob környezetében fut az Azure-ban. Alapértelmezés szerint a WebJobs SDK-nak szüksége van egy névvel rendelkező tárolókapcsolatra AzureWebJobsStorage.

Amikor a kapcsolat neve egyetlen pontos értékre oldódik fel, a futtatókörnyezet az értéket kapcsolati sztring azonosítja, amely általában egy titkos kulcsot tartalmaz. A kapcsolati sztring részletei attól függenek, hogy melyik szolgáltatáshoz csatlakozik. A kapcsolatnevek azonban több konfigurációelem gyűjteményére is hivatkozhatnak, amelyek az identitásalapú kapcsolatok konfigurálásához hasznosak. A környezeti változók gyűjteményként kezelhetők dupla aláhúzásjelekkel __végződő megosztott előtaggal. A csoportra ezután hivatkozhat úgy, hogy a kapcsolat nevét erre az előtagra állítja.

Előfordulhat például, hogy egy connection Azure Blob-eseményindító definíciójának tulajdonsága .Storage1 Mindaddig, amíg egy névvel ellátott Storage1környezeti változó nem konfigurál egyetlen sztringértéket, egy elnevezett Storage1__blobServiceUri környezeti változóval tájékoztathatja a blobServiceUri kapcsolat tulajdonságát. A kapcsolat tulajdonságai minden szolgáltatás esetében eltérőek. Tekintse meg a kapcsolatot használó összetevő dokumentációját.

Identitásalapú kapcsolatok

Ha identitásalapú kapcsolatokat szeretne használni a WebJobs SDK-ban, győződjön meg arról, hogy a WebJobs-csomagok legújabb verzióit használja a projektben. Azt is meg kell győződnie, hogy rendelkezik a Microsoft.Azure.WebJobs.Host.Storage-ra mutató hivatkozással. Az alábbiakban egy példa látható arra, hogyan nézhet ki a projektfájl a frissítések elvégzése után:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net48</TargetFramework>
    <IsWebJobProject>true</IsWebJobProject>
    <WebJobName>$(AssemblyName)</WebJobName>
    <WebJobType>Continuous</WebJobType>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.WebJobs" Version="3.0.41" />
    <PackageReference Include="Microsoft.Azure.WebJobs.Extensions.Storage.Queues" Version="5.3.1" />
    <PackageReference Include="Microsoft.Azure.WebJobs.Host.Storage" Version="5.0.1" />
    <PackageReference Include="Microsoft.Extensions.Logging.Console" Version="2.1.1" />
  </ItemGroup>

  <ItemGroup>
    <None Update="appsettings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
  </ItemGroup>
</Project>

A WebJobs HostBuilderen belüli beállításakor mindenképpen adjon meg egy hívást AddAzureStorageCoreServices, mivel ez teszi lehetővé AzureWebJobsStorage , hogy más Storage-eseményindítók és kötések használják az identitást:

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

Ezután konfigurálhatja a kapcsolatot a AzureWebJobsStorage környezeti változók (vagy az App Service-ben üzemeltetett alkalmazásbeállítások) beállításával:

Környezeti változó	Leírás	Példaérték
`AzureWebJobsStorage__blobServiceUri`	A tárfiók blobszolgáltatásának adatsík URI-ja a HTTPS-séma használatával.	<https:// storage_account_name.blob.core.windows.net>
`AzureWebJobsStorage__queueServiceUri`	A tárfiók üzenetsor-szolgáltatásának adatsík URI-ja a HTTPS-séma használatával.	<https:// storage_account_name.queue.core.windows.net>

Ha a konfigurációt a környezeti változóktól eltérő módon adja meg, például az egyikkel appsettings.json, akkor ehelyett strukturált konfigurációt kell megadnia a kapcsolathoz és annak tulajdonságaihoz:

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

Kihagyhatja a queueServiceUri tulajdonságot, ha nem tervezi blob-eseményindítók használatát.

Ha a kód helyileg fut, ez alapértelmezés szerint a DefaultAzureCredential esetében leírt viselkedésnek megfelelően használja a fejlesztői identitást.

Ha a kód Azure-alkalmazás szolgáltatásban van üzemeltetve, a fent látható konfiguráció alapértelmezés szerint az erőforrás rendszer által hozzárendelt felügyelt identitása lesz. Ha ehelyett egy felhasználó által hozzárendelt identitást szeretne használni, amelyet hozzárendelt az alkalmazáshoz, további tulajdonságokat kell hozzáadnia a kapcsolathoz, amelyek meghatározzák, hogy melyik identitást kell használni. A credential tulajdonságot (AzureWebJobsStorage__credential környezeti változóként) a "managedidentity" sztringre kell állítani. A clientId tulajdonságot (AzureWebJobsStorage__clientId környezeti változóként) a használni kívánt felhasználó által hozzárendelt felügyelt identitás ügyfélazonosítójára kell beállítani. Strukturált konfigurációként a teljes objektum a következő:

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

A használt AzureWebJobsStorage identitásnak szerepkör-hozzárendelésekkel kell rendelkeznie, amelyek a Storage Blob Data Owner, a Storage Queue Data Közreműködő és a Tárfiók közreműködői szerepköreit biztosítják. Ha nem tervezi blob-eseményindítók használatát, kihagyhatja a Tárolási üzenetsor adatszolgáltatója és a Tárfiók közreműködője szolgáltatását is.

Az alábbi táblázat beépített szerepköröket mutat be, amelyek a normál működésű kötésekben lévő triggerek használatakor ajánlottak. Előfordulhat, hogy az alkalmazás további engedélyeket igényel az Ön által írt kód alapján.

Kötés	Példa beépített szerepkörökre
Blobtrigger	Storage Blob Data Owner and Storage Queue Data Contributor A követelményekről `AzureWebJobsStorage` a fentiekben is olvashat.
Blob (bemenet)	Storage-blobadatok olvasója
Blob (kimenet)	Storage-blobadatok tulajdonosa
Üzenetsor-eseményindító	Storage Queue Data Reader, Storage Queue Data Message Processor
Üzenetsor (kimenet)	Storage Queue Data Contributor, Storage Queue Data Message Sender
Service Bus-eseményindító¹	Azure Service Bus-adatátvevő, Azure Service Bus-adattulajdonos
Service Bus (kimenet)	Azure Service Bus-adatküldő

¹ A Service Bus-témakörökből való aktiváláshoz a szerepkör-hozzárendelésnek hatékony hatókörrel kell rendelkeznie a Service Bus-előfizetés erőforrásán. Ha csak a témakört foglalja bele, hibába fog ütközni. Egyes ügyfelek, például az Azure Portal nem teszik közzé a Service Bus-előfizetési erőforrást a szerepkör-hozzárendelés hatóköreként. Ilyen esetekben az Azure CLI használható. További információ: Azure Beépített Azure-szerepkörök az Azure Service Bushoz.

Kapcsolati sztringek a 2.x verzióban

2-es verzió.Az SDK x-jének nincs szüksége konkrét névre. 2-es verzió.x lehetővé teszi, hogy saját neveket használjon ezekhez a kapcsolati sztring, és lehetővé teszi, hogy máshol tárolja őket. A kódban a következőhöz hasonló módon állíthatja be a JobHostConfigurationneveket:

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

Feljegyzés

Mert a 3-es verzió.x az alapértelmezett .NET Core konfigurációs API-kat használja, nincs API a kapcsolati sztring nevek módosításához. Lásd: WebJobs fejlesztése és üzembe helyezése a Visual Studióval

Gazdagépfejlesztési beállítások

A gazdagépet fejlesztési módban futtatva hatékonyabbá teheti a helyi fejlesztést. Íme néhány beállítás, amely automatikusan megváltozik a fejlesztési módban való futtatáskor:

Tulajdonság	Fejlesztési beállítás
`Tracing.ConsoleLevel`	`TraceLevel.Verbose` a naplókimenet maximalizálása érdekében.
`Queues.MaxPollingInterval`	Alacsony érték annak biztosítására, hogy az üzenetsor-metódusok azonnal aktiválódjanak.
`Singleton.ListenerLockPeriod`	15 másodperc, hogy segítsen a gyors iteratív fejlődés.

A fejlesztési mód engedélyezésének folyamata az SDK-verziótól függ.

3-es verzió.x

3-es verzió.x a standard ASP.NET Core API-kat használja. Hívja meg a UseEnvironment metódust a HostBuilder példányon. Adjon át egy sztringet , developmentahogyan ebben a példában is látható:

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

2-es verzió.x

Az JobHostConfiguration osztály rendelkezik egy UseDevelopmentSettings olyan módszerrel, amely lehetővé teszi a fejlesztési módot. Az alábbi példa a fejlesztési beállítások használatát mutatja be. Ha helyi futtatáskor szeretne visszaadni config.IsDevelopment true, állítson be egy helyi környezeti változót az értékkelDevelopment.AzureWebJobsEnv

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

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

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

Egyidejű kapcsolatok kezelése (2. verzió).x)

A 3. verzióban.x, a kapcsolati korlát alapértelmezés szerint végtelen kapcsolatokra vonatkozik. Ha valamilyen okból módosítania kell ezt a korlátot, használhatja az MaxConnectionsPerServer osztály tulajdonságát WinHttpHandler .

A 2. verzióban.x, a ServicePointManager.DefaultConnectionLimit API használatával szabályozhatja a gazdagéphez való egyidejű kapcsolatok számát. 2-ben.x, ezt az értéket a WebJobs-gazdagép indítása előtt a 2 alapértelmezett értékről kell növelnie.

Az összes kimenő HTTP-kérés, amelyet egy függvényből a folyamaton keresztüli ServicePointManagerforgalom használatával HttpClient küld el. Miután elérte a megadott DefaultConnectionLimitértéket, ServicePointManager a küldés előtt megkezdi a kérelmek várólistára helyezését. Tegyük fel, hogy a DefaultConnectionLimit 2 értékre van állítva, és a kód 1000 HTTP-kérést küld. Kezdetben csak két kérés engedélyezett az operációs rendszer számára. A másik 998-at várják, amíg nincs hely számukra. Ez azt jelenti, hogy időtúllépést HttpClient jelezhet, mert úgy tűnik, hogy a kérést végrehajtotta, de az operációs rendszer soha nem küldte el a kérést a célkiszolgálónak. Így előfordulhat, hogy a viselkedés nem tűnik logikusnak: a helyi HttpClient felhasználó 10 másodpercet vesz igénybe a kérés teljesítéséhez, de a szolgáltatás minden kérést 200 ms-ban ad vissza.

A ASP.NET alkalmazások alapértelmezett értéke, Int32.MaxValueés ez valószínűleg jól működik az alapszintű vagy magasabb App Service-csomagban futó WebJobs-feladatok esetében. A WebJobs általában az Always On beállítást igényli, és ezt csak az alapszintű és a magasabb Szintű App Service-csomagok támogatják.

Ha a WebJob ingyenes vagy megosztott App Service-csomagban fut, az alkalmazást az App Service tesztkörnyezete korlátozza, amelynek kapcsolati korlátja jelenleg 300. Ha nincs kapcsolati korlát ServicePointManager, valószínűbb, hogy eléri a tesztkörnyezet kapcsolati küszöbértékét, és a webhely leáll. Ebben az esetben az alacsonyabb értékre (például 50 vagy 100) való beállítás DefaultConnectionLimit megakadályozhatja ezt, és továbbra is elegendő átviteli sebességet biztosít.

A beállítást a HTTP-kérések előtt kell konfigurálni. Ezért a WebJobs-gazdagépnek nem szabad automatikusan módosítania a beállítást. Előfordulhatnak OLYAN HTTP-kérések, amelyek a gazdagép indítása előtt történnek, ami váratlan viselkedéshez vezethet. A legjobb módszer az érték azonnali beállítása a metódusban az Main inicializálás JobHostelőtt, az itt látható módon:

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

Triggerek

A WebJobs SDK ugyanazokat az eseményindítókat és kötéseket támogatja, amelyeket az Azure Functions használ. Vegye figyelembe, hogy a WebJobs SDK-ban az eseményindítók függvényspecifikusak, és nem kapcsolódnak a WebJob üzembehelyezési típusához. Az SDK használatával létrehozott eseményvezérelt függvényeket tartalmazó WebJobs-feladatokat mindig folyamatos WebJob-feladatként kell közzétenni, az Always bekapcsolva lehetőséggel.

A függvénynek nyilvános metódusoknak kell lenniük, és egy triggerattribútummal vagy attribútummal kell rendelkezniük NoAutomaticTrigger .

Automatikus eseményindítók

Az automatikus eseményindítók meghívnak egy függvényt egy eseményre válaszul. Tekintse meg ezt a példát egy olyan függvényre, amelyet az Azure Queue Storage-hoz hozzáadott üzenet aktivál. A függvény egy blob Azure Blob Storage-ból való olvasásával válaszol:

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

Az QueueTrigger attribútum arra utasítja a futtatókörnyezetet, hogy hívja meg a függvényt, amikor megjelenik egy üzenetsor.myqueue-items Az Blob attribútum arra utasítja a futtatókörnyezetet, hogy az üzenetsor-üzenettel olvasson be egy blobot a sample-workitems tárolóban. A tároló blobelemének nevét közvetlenül samples-workitems az üzenetsor-eseményindítóból szerzi be kötési kifejezésként ({queueTrigger}).

Feljegyzés

A webalkalmazások 20 perc inaktivitás után időtúllépést okozhatnak, és csak a tényleges webalkalmazáshoz érkező kérések állíthatják alaphelyzetbe az időzítőt. Az alkalmazás konfigurációjának megtekintése az Azure Portalon vagy a speciális eszközök webhelyére (https://<app_name>.scm.azurewebsites.net) irányuló kérések esetén nem állítja vissza az időzítőt. Ha úgy állítja be a feladatot üzemeltető webalkalmazást, hogy folyamatosan fusson, ütemezés szerint fusson, vagy eseményvezérelt eseményindítókat használjon, engedélyezze az Always on beállítást a webalkalmazás Azure-konfigurációs lapján. Az Always on beállítás segít meggyőződni arról, hogy az ilyen típusú WebJobs-feladatok megbízhatóan futnak. Ez a funkció csak az alapszintű, standard és prémium tarifacsomagokban érhető el.

Manuális eseményindítók

Ha manuálisan szeretne aktiválni egy függvényt, használja az NoAutomaticTrigger attribútumot az itt látható módon:

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

A függvény manuális aktiválásának folyamata az SDK-verziótól függ.

3-es verzió.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();
    }
}

2-es verzió.x

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

Bemeneti és kimeneti kötések

A bemeneti kötések deklaratív módon teszik elérhetővé az Azure-ból vagy külső szolgáltatásokból származó adatokat a kód számára. A kimeneti kötések lehetővé teszik az adatok frissítését. Az Első lépések című cikk mindegyikre mutat példát.

A kimeneti kötések metódus-visszatérési értékét úgy használhatja, ha az attribútumot a metódus visszatérési értékére alkalmazza. Lásd a példát az Azure-függvény visszatérési értékének használata című témakörben.

Kötéstípusok

A kötéstípusok telepítésének és kezelésének folyamata attól függ, hogy a 3. verziót használja-e.x vagy 2-es verzió.X az SDK-ból. Az adott kötéstípushoz telepíteni kívánt csomagot az adott kötéstípus Azure Functions-referenciacikkének "Csomagok" szakaszában találja. Kivételt képez a Files eseményindítója és kötése (a helyi fájlrendszer esetében), amelyet az Azure Functions nem támogat.

3-es verzió.x

A 3. verzióban.x, a tárolókötéseket a Microsoft.Azure.WebJobs.Extensions.Storage csomag tartalmazza. Hívja meg a AddAzureStorage metódus bővítménymetódusát ConfigureWebJobs az itt látható módon:

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

Más trigger- és kötéstípusok használatához telepítse az őket tartalmazó NuGet-csomagot, és hívja meg a Add<binding> bővítményben implementált bővítménymetódust. Ha például Azure Cosmos DB-kötést szeretne használni, telepítse Microsoft.Azure.WebJobs.Extensions.CosmosDB és hívja meg AddCosmosDBa következőhöz hasonlót:

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

Az időzítő eseményindítójának vagy az alapvető szolgáltatások részét képező Fájlok kötésének használatához hívja meg a AddTimers vagy AddFiles a bővítmény metódusait.

2-es verzió.x

Ezeket az eseményindító- és kötéstípusokat a 2. verzió tartalmazza.x a csomagból Microsoft.Azure.WebJobs :

Blob Storage
Queue Storage
Table Storage

Más trigger- és kötéstípusok használatához telepítse az őket tartalmazó NuGet-csomagot, és hívjon meg egy metódust Use<binding> az JobHostConfiguration objektumon. Ha például időzítő eseményindítót szeretne használni, telepítse Microsoft.Azure.WebJobs.Extensions és hívja meg UseTimers a Main metódust, az itt látható módon:

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

A Fájlok kötés használatához telepítse Microsoft.Azure.WebJobs.Extensions és hívja meg UseFilesa fájlt.

ExecutionContext

A WebJobs lehetővé teszi a kötést egy ExecutionContext. Ezzel a kötéssel paraméterként is hozzáférhet a ExecutionContext függvény aláírásához. Az alábbi kód például a környezeti objektumot használja a hívásazonosító eléréséhez, amellyel korrelálhatja az adott függvényhívás által létrehozott naplókat.

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

Az SDK-verzióhoz ExecutionContext való kötés folyamata az SDK-verziótól függ.

3-es verzió.x

Hívja meg a AddExecutionContextBinding metódus bővítménymetódusát ConfigureWebJobs az itt látható módon:

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

2-es verzió.x

A Microsoft.Azure.WebJobs.Extensions korábban említett csomag egy speciális kötéstípust is biztosít, amelyet a UseCore metódus meghívásával regisztrálhat. Ez a kötés lehetővé teszi, hogy definiáljon egy paramétert ExecutionContext a függvény-aláírásban, amely így van engedélyezve:

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

Kötéskonfiguráció

Konfigurálhatja egyes triggerek és kötések viselkedését. A konfigurálásuk folyamata az SDK-verziótól függ.

3-es verzió.x: Konfigurálás beállítása a Add<Binding> metódus meghívásakor ConfigureWebJobs.
2-es verzió.x: Konfigurálás beállítása a megadott konfigurációs objektum tulajdonságainak JobHostbeállításával.

Ezek a kötésspecifikus beállítások egyenértékűek az Azure Functions host.json projektfájljának beállításaival.

A következő kötéseket konfigurálhatja:

Azure Cosmos DB-eseményindító
Event Hubs-eseményindító
Üzenetsortár-eseményindító
SendGrid-kötés
Service Bus-eseményindító

Az Azure Cosmos DB eseményindítójának konfigurációja (3. verzió).x)

Ez a példa az Azure Cosmos DB-eseményindító konfigurálását mutatja be:

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

További információkért tekintse meg az Azure Cosmos DB kötési cikkét.

Event Hubs-eseményindító konfigurációja (3. verzió).x)

Ez a példa bemutatja, hogyan konfigurálható az Event Hubs-eseményindító:

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

További információkért tekintse meg az Event Hubs kötési cikkét.

Üzenetsortár-eseményindító konfigurálása

Az alábbi példák bemutatják, hogyan konfigurálható a Queue Storage-eseményindító.

3-es verzió.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();
    }
}

További információkért tekintse meg a Queue Storage kötési cikkét.

2-es verzió.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();
}

További információ: host.json v1.x referencia.

A SendGrid kötéskonfigurációja (3. verzió).x)

Ez a példa a SendGrid kimeneti kötés konfigurálását mutatja be:

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

További információt a SendGrid kötési cikkében talál.

Service Bus-eseményindító konfigurációja (3. verzió).x)

Ez a példa a Service Bus-eseményindító konfigurálását mutatja be:

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

További részletekért tekintse meg a Service Bus kötési cikkét.

Egyéb kötések konfigurálása

Egyes trigger- és kötéstípusok saját egyéni konfigurációtípusokat határoznak meg. A Fájl eseményindítójával például megadhatja a figyelendő gyökér elérési útját, ahogyan az alábbi példákban is látható.

3-es verzió.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();
    }
}

2-es verzió.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();
}

Kötéskifejezések

Az attribútumkonstruktor paramétereiben olyan kifejezéseket használhat, amelyek feloldják a különböző forrásokból származó értékeket. Az alábbi kódban például az attribútum elérési útja BlobTrigger létrehoz egy kifejezést.filename Amikor a kimeneti kötéshez használják, filename az aktiváló blob nevére lesz feloldva.

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

További információ a kötési kifejezésekről: Kötési kifejezések és minták az Azure Functions dokumentációjában.

Egyéni kötési kifejezések

Előfordulhat, hogy a kódban lévő üzenetsor nevét, blobnevét vagy tárolóját vagy táblanevét szeretné megadni ahelyett, hogy keményen kódolni szeretné. Előfordulhat például, hogy egy konfigurációs fájlban vagy környezeti változóban meg szeretné adni az QueueTrigger attribútum üzenetsornevét.

Ezt úgy teheti meg, hogy egy egyéni névfeloldót ad át a konfiguráció során. A trigger- vagy kötésattribútum-konstruktorparaméterekben helyőrzőket is megadhat, a feloldókód pedig a helyőrzők helyett használandó tényleges értékeket adja meg. A helyőrzőket százalék (%) jelekkel kell körülvenni, az itt látható módon:

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

Ez a kód lehetővé teszi a tesztkörnyezetben elnevezett logqueuetest és az éles környezetben elnevezett logqueueprod üzenetsor használatát. A nem kódolt üzenetsor neve helyett meg kell adnia egy bejegyzés nevét a appSettings gyűjteményben.

Van egy alapértelmezett feloldó, amely akkor lép érvénybe, ha nem ad meg egyénit. Az alapértelmezett érték az alkalmazásbeállításokból vagy a környezeti változókból származik.

A .NET Core 3.1-től kezdődően a ConfigurationManager használt rendszerhez a System.Configuration.ConfigurationManager NuGet csomag szükséges. A mintához a következő using utasítás szükséges:

using System.Configuration;

Az NameResolver osztály lekéri az üzenetsor nevét az alkalmazásbeállításokból, ahogy az itt látható:

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

3-es verzió.x

A feloldót függőséginjektálással konfigurálhatja. Ezekhez a mintákhoz a következő using utasításra van szükség:

using Microsoft.Extensions.DependencyInjection;

A feloldót úgy adhatja hozzá, hogy meghívja a ConfigureServices bővítménymetódust HostBuildera következő példához hasonlóan:

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

2-es verzió.x

Adja át az NameResolver osztályt az JobHost objektumnak az itt látható módon:

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

Az Azure Functions implementálja INameResolver az alkalmazásbeállítások értékeinek lekérését, ahogyan az a példában is látható. Amikor közvetlenül használja a WebJobs SDK-t, írhat egy egyéni implementációt, amely a helyőrző helyettesítő értékeit bármilyen forrásból lekéri.

Kötés futásidőben

Ha valamilyen munkát kell végeznie a függvényben, mielőtt egy kötésttribútumot használ, például Queue, Blobvagy Table, használhatja az interfészt IBinder .

Az alábbi példa egy bemeneti üzenetsor üzenetét veszi fel, és létrehoz egy új üzenetet ugyanazzal a tartalommal egy kimeneti üzenetsorban. A kimeneti üzenetsor nevét a függvény törzsében lévő kód állítja be.

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

További információ: Kötés futásidőben az Azure Functions dokumentációjában.

Kötési referenciaadatok

Az Azure Functions dokumentációja referenciainformációkat tartalmaz az egyes kötéstípusokról. Az alábbi információkat minden kötési referenciacikkben megtalálja. (Ez a példa a Storage-üzenetsoron alapul.)

Csomagok. A telepíteni kívánt csomag, amely támogatja a kötést egy WebJobs SDK-projektben.
Példák. Kódminták. A C# osztálykódtár példája a WebJobs SDK-ra vonatkozik. Egyszerűen hagyja ki az FunctionName attribútumot.
Attribútumok. A kötéstípushoz használandó attribútumok.
Konfigurálás. Az attribútum tulajdonságainak és konstruktorparamétereinek magyarázata.
Használat – A kötés működésével kapcsolatos információk a kötés típusáról és működéséről. Például: lekérdezési algoritmus, méregsor feldolgozása.

Feljegyzés

A HTTP-, Webhook- és Event Grid-kötéseket csak az Azure Functions támogatja, a WebJobs SDK nem.

Az Azure Functions-futtatókörnyezetben támogatott kötések teljes listáját a Támogatott kötések című témakörben találja.

A Letiltás, az Időtúllépés és a Singleton attribútumai

Ezekkel az attribútumokkal szabályozhatja a függvények aktiválását, a függvények megszakítását, és gondoskodhat arról, hogy egy függvénynek csak egy példánya fusson.

Attribútum letiltása

Az Disable attribútum segítségével szabályozható, hogy aktiválható-e egy függvény.

Az alábbi példában, ha az alkalmazásbeállítás Disable_TestJob értéke 1 vagy (a kis- és True nagybetűk nem érzékenek), a függvény nem fog futni. Ebben az esetben a futtatókörnyezet létrehoz egy "Functions.TestJob" nevű naplóüzenetet , amely le van tiltva.

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

Amikor módosítja az alkalmazásbeállítási értékeket az Azure Portalon, a WebJob újraindul az új beállítás felvételéhez.

Az attribútum deklarálható paraméter, metódus vagy osztályszinten. A beállításnév kötési kifejezéseket is tartalmazhat.

Időtúllépés attribútum

Az Timeout attribútum megszakítja a függvényt, ha nem fejeződik be egy megadott időn belül. Az alábbi példában a függvény egy napig futna az Időtúllépés attribútum nélkül. Az időtúllépés miatt a függvény 15 másodperc után megszakad. Ha az időtúllépési attribútum "throwOnError" paramétere "true" (igaz) értékre van állítva, a függvényhívás leáll azzal, hogy a webjobs SDK kivételt vet ki az időtúllépési időköz túllépésekor. A "throwOnError" alapértelmezett értéke "false". Az Időtúllépés attribútum használatakor az alapértelmezett viselkedés a függvényhívás megszakítása a lemondási jogkivonat beállításával, miközben a meghívás határozatlan ideig fut, amíg a függvénykód vissza nem ad vagy kivételt nem ad vissza.

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

Az Időtúllépés attribútumot az osztály vagy a metódus szintjén alkalmazhatja, és globális időtúllépést is megadhat a használatával JobHostConfiguration.FunctionTimeout. Az osztályszintű vagy metódusszintű időtúllépések felülírják a globális időtúllépéseket.

Singleton attribútum

Az Singleton attribútum biztosítja, hogy egy függvénynek csak egy példánya fusson, még akkor is, ha a gazdagép webalkalmazásának több példánya is van. A Singleton attribútum elosztott zárolással biztosítja, hogy egy példány fusson.

Ebben a példában a függvénynek csak egyetlen példánya ProcessImage fut egyszerre:

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

SingletonMode.Listener

Egyes eseményindítók beépített támogatást nyújtanak az egyidejűség-kezeléshez:

QueueTrigger. Állítsa a JobHostConfiguration.Queues.BatchSize elemet 1 értékre.
ServiceBusTrigger. Állítsa a ServiceBusConfiguration.MessageOptions.MaxConcurrentCalls elemet 1 értékre.
FileTrigger. Állítsa a FileProcessor.MaxDegreeOfParallelism elemet 1 értékre.

Ezekkel a beállításokkal biztosíthatja, hogy a függvény egyetlentonként fusson egyetlen példányon. Annak érdekében, hogy a webalkalmazás több példányra való felskálázásakor a függvénynek csak egyetlen példánya fusson, alkalmazzon egy figyelőszintű egyhangos zárolást a függvényre ([Singleton(Mode = SingletonMode.Listener)]). A figyelőzárak a JobHost indításakor lesznek beolvasva. Ha három felskálázott példány egyszerre indul el, csak az egyik példány szerzi be a zárolást, és csak egy figyelő indul el.

Feljegyzés

A SingletonMode.Function működésével kapcsolatos további információkért tekintse meg ezt a GitHub-adattárat .

Hatókör értékei

Egy adottton megadhat hatókörkifejezést /értéket . A kifejezés/érték biztosítja, hogy a függvény egy adott hatókörben végrehajtott összes végrehajtása szerializálva legyen. A részletesebb zárolás ily módon történő implementálása lehetővé teszi a függvény bizonyos szintű párhuzamosságát, miközben más meghívásokat szerializál a követelményeknek megfelelően. Az alábbi kódban például a hatókörkifejezés a Region bejövő üzenet értékéhez kapcsolódik. Ha az üzenetsor három üzenetet tartalmaz a keleti, a keleti és a nyugati régióban, a keleti régióval rendelkező üzenetek sorozatosan futnak. A Nyugat régióval rendelkező üzenet párhuzamosan fut a keleti régióban lévőkkel.

[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

A zárolás alapértelmezett hatóköre SingletonScope.Functionaz, ami azt jelenti, hogy a zárolási hatókör (a blobbérlet elérési útja) a teljes függvénynévhez van kötve. A függvények közötti zároláshoz adjon meg SingletonScope.Host és használjon olyan hatókörazonosító-nevet, amely megegyezik az összes olyan függvényen, amelyet nem szeretne egyszerre futtatni. Az alábbi példában egyszerre csak egy példány AddItem fut vagy RemoveItem fut:

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

Bérletblobok megtekintése

A WebJobs SDK azure-blobbérleteket használ a fedelek alatt az elosztott zárolás implementálásához. A Singleton által használt bérletblobok a azure-webjobs-host tárfiók tárolójában találhatók a AzureWebJobsStorage "zárolások" elérési út alatt. Például a korábban bemutatott első ProcessImage példa bérletblob elérési útja lehet locks/061851c758f04938a4426aa9ab3869c0/WebJobs.Functions.ProcessImage. Minden elérési út tartalmazza a JobHost azonosítót, ebben az esetben a 061851c758f04938a4426aa9ab3869c0 azonosítót.

Aszinkron függvények

Az aszinkron függvények kódjáról az Azure Functions dokumentációjában talál további információt.

Lemondási jogkivonatok

A lemondási jogkivonatok kezelésével kapcsolatos információkért tekintse meg az Azure Functions lemondási jogkivonatokkal és a kecses leállítással kapcsolatos dokumentációját.

Több példány

Ha a webalkalmazás több példányon fut, minden példányon folyamatos WebJob-feladat fut, figyelve az eseményindítókat és a hívási függvényeket. A különböző triggerkötések úgy vannak kialakítva, hogy hatékonyan oszthassák meg a közös munkát a példányok között, így a több példányra való horizontális felskálázás lehetővé teszi a nagyobb terhelés kezelését.

Bár egyes eseményindítók dupla feldolgozást eredményezhetnek, az üzenetsor- és blobtároló-eseményindítók automatikusan megakadályozzák, hogy egy függvény többször is feldolgozzon egy üzenetsor-üzenetet vagy blobot. További információ: Azonos bemenet tervezése az Azure Functions dokumentációjában.

Az időzítő eseményindítója automatikusan biztosítja, hogy az időzítőnek csak egy példánya fusson, így egynél több függvénypéldány nem fut egy adott ütemezett időpontban.

Ha biztosítani szeretné, hogy egy függvénynek csak egy példánya fusson akkor is, ha a gazdagép webalkalmazásának több példánya is van, használhatja az Singleton attribútumot.

Szűrők

A függvényszűrők (előzetes verzió) lehetővé teszik a WebJobs végrehajtási folyamat testreszabását saját logikával. A szűrők ASP.NET Core-szűrőkhöz hasonlóak. Ezeket deklaratív attribútumokként implementálhatja, amelyek a függvényekre vagy osztályokra vonatkoznak. További információ: Függvényszűrők.

Naplózás és figyelés

Javasoljuk a ASP.NET számára kifejlesztett naplózási keretrendszert. Az Első lépések című cikk bemutatja, hogyan használható.

Naplószűrés

A példányok által ILogger létrehozott naplókhoz társított Category és Level. LogLevel enumerálás, és az egész számkód relatív fontosságot jelez:

Naplózási szint	Kód
Trace	0
Hibakeresés	0
Tájékoztatás	2
Figyelmeztetés	3
Hiba	4
Kritikus	5
Egyik sem	6

Az egyes kategóriákat egymástól függetlenül is szűrheti egy adott LogLevelkategóriára. Előfordulhat például, hogy a blobok eseményindítóinak feldolgozásához szükséges összes naplót látni szeretné, de minden más esetében csak Error és magasabban.

3-es verzió.x

3-es verzió.Az SDK x része a .NET Core-ba beépített szűrésre támaszkodik. Az LogCategories osztály segítségével kategóriákat határozhat meg adott függvényekhez, eseményindítókhoz vagy felhasználókhoz. Emellett szűrőket is definiál adott gazdagépállapotokhoz, például Startup és Results. Ez lehetővé teszi a naplózási kimenet finomhangolását. Ha a megadott kategóriákban nem található egyezés, a szűrő visszaesik az Default értékre, amikor eldönti, hogy szűri-e az üzenetet.

LogCategories a következő utasítást igényli:

using Microsoft.Azure.WebJobs.Logging;

Az alábbi példa egy szűrőt hoz létre, amely alapértelmezés szerint az összes naplót szűri a Warning szinten. A Function kategóriák ( results a 2. verzióval egyenértékűek Host.Results ).x) szűrt szinten Error . A szűrő összehasonlítja az aktuális kategóriát a LogCategories példány összes regisztrált szintjével, és kiválasztja a leghosszabb egyezést. Ez azt jelenti, hogy a Debug mérkőzések Host.Triggers.Queue vagy Host.Triggers.BlobHost.Triggers . Ez lehetővé teszi a szélesebb kategóriák szabályozását anélkül, hogy mindegyikhez hozzá kellene adnia.

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

2-es verzió.x

A 2. verzióban.X az SDK-ból, az osztály használatával szabályozhatja a LogCategoryFilter szűrést. A LogCategoryFilter tulajdonság kezdeti értéke Information, vagyis a , , ErrorWarningvagy Critical szintek összes üzenete Informationnaplózva van, de a rendszer kiszűri a Debug szinteken lévő Trace üzeneteket.Default

A 3- as verzióhoz LogCategories hasonlóan.x, a CategoryLevels tulajdonság lehetővé teszi a naplószintek megadását adott kategóriákhoz, hogy finomhangolhassa a naplózási kimenetet. Ha nem található egyezés a CategoryLevels szótárban, a szűrő visszaesik az Default értékre, amikor eldönti, hogy szűri-e az üzenetet.

Az alábbi példa egy szűrőt hoz létre, amely alapértelmezés szerint az összes naplót szűri a Warning szinten. A Function kategóriák és Host.Results kategóriák szűrése a Error szinten van. Az LogCategoryFilter aktuális kategóriát hasonlítja össze az összes regisztrált CategoryLevels kategóriával, és a leghosszabb egyezést választja ki. Így a Debug regisztrált Host.Triggers szint megegyezik Host.Triggers.Queue vagy Host.Triggers.Blob. Ez lehetővé teszi a szélesebb kategóriák szabályozását anélkül, hogy mindegyikhez hozzá kellene adnia.

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

Egyéni telemetriai adatok az Application Insightshoz

Az Egyéni telemetriai adatok Application Insightshoz való implementálásának folyamata az SDK-verziótól függ. Az Application Insights konfigurálásáról az Application Insights naplózásának hozzáadása című témakörben olvashat.

3-es verzió.x

Mert a 3-es verzió.A WebJobs SDK x része a .NET Core általános gazdagépre támaszkodik, a rendszer már nem biztosít egyéni telemetriai előállítót. Egyéni telemetriát azonban függőséginjektálással adhat hozzá a folyamathoz. Az ebben a szakaszban szereplő példákhoz a következő using utasítások szükségesek:

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

A következő egyéni implementáció ITelemetryInitializer lehetővé teszi, hogy sajátot ITelemetry adjon hozzá az alapértelmezetthez TelemetryConfiguration.

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

Hívja meg ConfigureServices a szerkesztőt, hogy adja hozzá az egyénit ITelemetryInitializer a folyamathoz.

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

A felépítéskor a TelemetryConfiguration rendszer minden regisztrált típust ITelemetryInitializer tartalmaz. További információ: Application Insights API egyéni eseményekhez és metrikákhoz.

A 3. verzióban.x, a továbbiakban nem kell kiüríteni a TelemetryClient gazdagép leállásakor. A .NET Core függőséginjektálási rendszer automatikusan megsemmisíti a regisztráltat ApplicationInsightsLoggerProvider, amely kiüríti a TelemetryClient.

2-es verzió.x

A 2. verzióban.x, a TelemetryClient WebJobs SDK-hoz ServerTelemetryChannelhasznált Application Insights-szolgáltató által belsőleg létrehozott . Ha az Application Insights-végpont nem érhető el, vagy szabályozza a bejövő kéréseket, ez a csatorna menti a kéréseket a webalkalmazás fájlrendszerében, és később újra elküldi őket.

Ezt TelemetryClient egy implementálható ITelemetryClientFactoryosztály hozza létre. Alapértelmezés szerint ez a DefaultTelemetryClientFactory.

Ha módosítani szeretné az Application Insights-folyamat bármely részét, saját elemet adhat meg ITelemetryClientFactory, és a gazdagép az osztályával fog létrehozni egy TelemetryClient. Ez a kód például felülbírálja DefaultTelemetryClientFactory a következő tulajdonság ServerTelemetryChannelmódosítását:

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

Az SamplingPercentageEstimatorSettings objektum adaptív mintavételezést konfigurál. Ez azt jelenti, hogy bizonyos nagy mennyiségű forgatókönyvekben az Application Insights a telemetriaadatok kiválasztott részhalmazát küldi el a kiszolgálónak.

A telemetriai előállító létrehozása után adja át az Application Insights naplózási szolgáltatójának:

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

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

Következő lépések

Ez a cikk olyan kódrészleteket adott meg, amelyek bemutatják, hogyan kezelhetők a WebJobs SDK-val kapcsolatos gyakori forgatókönyvek. A teljes mintákért lásd: azure-webjobs-sdk-samples.

Megosztás a következőn keresztül:

Az Azure WebJobs SDK használata eseményalapú háttérfeldolgozáshoz

WebJobs SDK-verziók

WebJobs-gazdagép

Gazdagépkapcsolatok

Identitásalapú kapcsolatok

Kapcsolati sztringek a 2.x verzióban

Gazdagépfejlesztési beállítások

3-es verzió.x

2-es verzió.x

Egyidejű kapcsolatok kezelése (2. verzió).x)

Triggerek

Automatikus eseményindítók

Manuális eseményindítók

3-es verzió.x

2-es verzió.x

Bemeneti és kimeneti kötések

Kötéstípusok

3-es verzió.x

2-es verzió.x

ExecutionContext

3-es verzió.x

2-es verzió.x

Kötéskonfiguráció

Az Azure Cosmos DB eseményindítójának konfigurációja (3. verzió).x)

Event Hubs-eseményindító konfigurációja (3. verzió).x)

Üzenetsortár-eseményindító konfigurálása

3-es verzió.x

2-es verzió.x

A SendGrid kötéskonfigurációja (3. verzió).x)

Service Bus-eseményindító konfigurációja (3. verzió).x)

Egyéb kötések konfigurálása

3-es verzió.x

2-es verzió.x

Kötéskifejezések

Egyéni kötési kifejezések

3-es verzió.x

2-es verzió.x

Kötés futásidőben

Kötési referenciaadatok

A Letiltás, az Időtúllépés és a Singleton attribútumai

Attribútum letiltása

Időtúllépés attribútum

Singleton attribútum

SingletonMode.Listener

Hatókör értékei

SingletonScope.Host

Bérletblobok megtekintése

Aszinkron függvények

Lemondási jogkivonatok

Több példány

Szűrők

Naplózás és figyelés

Naplószűrés

3-es verzió.x

2-es verzió.x

Egyéni telemetriai adatok az Application Insightshoz

3-es verzió.x

2-es verzió.x

Következő lépések

Visszajelzés

További források