Condividi tramite

Usare Azure WebJobs SDK per l'elaborazione in background basata su eventi

Questo articolo descrive come usare Azure WebJobs SDK. Per iniziare rapidamente a usare Processi Web, vedere Introduzione ad Azure WebJobs SDK.

Versioni di WebJobs SDK

Differenze principali tra la versione 3. x e versione 2. x di WebJobs SDK sono:

  • La versione 3.x aggiunge il supporto per .NET Core.
  • Nella versione 3. x, si installa l'estensione di associazione di archiviazione richiesta da WebJobs SDK. Nella versione 2.x, le associazioni di archiviazione sono incluse nell'SDK.
  • Gli strumenti di Visual Studio 2019 per i progetti .NET Core (3.x) differiscono dagli strumenti per i progetti .NET Framework (2.x). Per altre informazioni, vedere Sviluppare e distribuire processi Web con Visual Studio.

Alcuni esempi in questo articolo sono forniti sia per la versione 3.x di WebJobs che per la versione 2.x di WebJobs.

Funzioni di Azure è basato su WebJobs SDK:

  • Funzioni di Azure versione 2.x è basato su WebJobs SDK versione 3.x.
  • Funzioni di Azure versione 1.x è basato su WebJobs SDK versione 2.x.

I repository del codice sorgente per le Azure Functions e il WebJobs SDK utilizzano la numerazione del WebJobs SDK. Diverse sezioni di questo articolo sono collegate alla documentazione di Funzioni di Azure.

Per altre informazioni, vedere Confrontare WebJobs SDK e Funzioni di Azure.

Host WebJobs

L'host WebJobs è un contenitore runtime per le funzioni. L'host ascolta i trigger e chiama le funzioni. Nella versione 3.x l'host è un'implementazione di IHost. Nella versione 2.x si usa l'oggetto JobHost. L'utente crea un'istanza host nel codice e scrive il codice per personalizzarne il comportamento.

Questa modifica dell'architettura è una differenza fondamentale tra l'uso diretto di WebJobs SDK e l'uso indiretto tramite Funzioni di Azure. In Funzioni di Azure il servizio controlla l'host. Non è possibile personalizzare l'host scrivendo codice. In Funzioni di Azure si personalizza il comportamento dell'host tramite le impostazioni nel host.json file. Queste impostazioni sono stringhe, non codice e l'uso di queste stringhe limita i tipi di personalizzazioni che è possibile eseguire.

Connessioni host

WebJobs SDK cerca le connessioni di Archiviazione di Azure e del bus di servizio di Azure nel file local.settings.json quando lo si esegue in locale o nell'ambiente del processo Web quando lo si esegue in Azure. Per impostazione predefinita, WebJobs SDK richiede una connessione di archiviazione denominata AzureWebJobsStorage.

Quando il nome della connessione viene risolto in un singolo valore esatto, il runtime identifica il valore come stringa di connessione, che in genere include un segreto. I dettagli di una stringa di connessione dipendono dal servizio a cui ci si connette. Tuttavia, un nome di connessione può anche fare riferimento a una raccolta di più elementi di configurazione. Questo metodo è utile per la configurazione delle connessioni basate su identità. È possibile considerare le variabili di ambiente come una raccolta usando un prefisso condiviso che termina con caratteri di sottolineatura doppia (__). È quindi possibile fare riferimento al gruppo impostando il nome della connessione su questo prefisso.

Ad esempio, la connection proprietà per una definizione di trigger di Archiviazione BLOB di Azure potrebbe essere Storage1. Se non esiste un singolo valore stringa configurato da una variabile di ambiente denominata Storage1, è possibile usare una variabile di ambiente denominata Storage1__blobServiceUri per informare la proprietà blobServiceUri della connessione. Le proprietà di connessione sono diverse per ogni servizio. Fare riferimento alla documentazione relativa al componente che usa la connessione.

Connessioni basate su identità

Per utilizzare connessioni basate sull'identità nell'SDK di WebJobs, assicurati di usare le versioni più recenti dei pacchetti WebJobs nel tuo progetto. Assicurarsi anche di avere un riferimento a Microsoft.Azure.WebJobs.Host.Storage.

L'esempio seguente mostra l'aspetto del file di progetto dopo aver apportato questi aggiornamenti:

<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.42" />
    <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>

Quando si configurano WebJobs nell'istanza di HostBuilder, assicurarsi di includere una chiamata a AddAzureStorageCoreServices. Questa chiamata consente a AzureWebJobsStorage e ad altri trigger e associazioni di archiviazione di usare l'identità.

Ecco un esempio:

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

È quindi possibile configurare la AzureWebJobsStorage connessione impostando le variabili di ambiente (o le impostazioni dell'applicazione quando il codice è ospitato nel servizio app di Azure):

Variabile di ambiente Descrizione Valore di esempio
AzureWebJobsStorage__blobServiceUri URI del piano dati del servizio BLOB dell'account di archiviazione. Usa lo schema HTTPS. <https://storage_account_name.blob.core.windows.net>
AzureWebJobsStorage__queueServiceUri URI del piano dei dati del servizio di coda dell'account di archiviazione. Usa lo schema HTTPS. <https://storage_account_name.queue.core.windows.net>

Se si specifica la configurazione con qualsiasi mezzo diverso dalle variabili di ambiente, ad esempio in un appsettings.json file di configurazione, è invece necessario fornire una configurazione strutturata per la connessione e le relative proprietà:

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

È possibile omettere la queueServiceUri proprietà se non si prevede di usare trigger BLOB.

Quando il codice viene eseguito in locale, l'impostazione predefinita consiste nell'usare l'identità dello sviluppatore come descritto per DefaultAzureCredential.

Quando il codice è ospitato nel servizio app, per impostazione predefinita la configurazione nell'esempio precedente è l'identità gestita assegnata dal sistema per la risorsa. Per usare invece un'identità assegnata dall'utente assegnata all'app, è necessario aggiungere proprietà per la connessione per specificare l'identità da usare. La credential proprietà (AzureWebJobsStorage__credential come variabile di ambiente) deve essere impostata sulla stringa managedidentity. La clientId proprietà (AzureWebJobsStorage__clientId come variabile di ambiente) deve essere impostata sull'ID client dell'identità gestita assegnata dall'utente da usare.

Come configurazione strutturata, l'oggetto completo sarà simile a questo esempio:

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

L'identità usata per AzureWebJobsStorage deve avere assegnazioni di ruolo che le concedono i ruoli Proprietario dei dati del Blob di Archiviazione, Collaboratore Dati Coda Archiviazione e Collaboratore Account di Archiviazione. È possibile omettere i ruoli Collaboratore ai dati della coda di archiviazione e Collaboratore account di archiviazione se non si prevede di usare trigger blob.

La tabella seguente illustra i ruoli predefiniti consigliati quando si usano i trigger nelle associazioni nel normale funzionamento. L'applicazione potrebbe richiedere più autorizzazioni, a seconda del codice scritto.

Vincolo Ruoli predefiniti di esempio
Trigger di BLOB Proprietario dei dati del BLOB di archiviazioneeCollaboratore ai dati della coda di archiviazione
Vedere anche i requisiti precedenti per AzureWebJobsStorage.
BLOB (input) Lettore dei dati del BLOB di archiviazione
BLOB (output) Proprietario dei dati del BLOB di archiviazione
Trigger di accodamento Lettore dei dati della coda di archiviazione, Processore dei messaggi sui dati della coda di archiviazione
Coda (output) Collaboratore ai dati della coda di archiviazione, Mittente del messaggio dei dati della coda di archiviazione
Trigger del bus di servizio1 Ricevitore dei dati del bus di servizio di Azure, Proprietario dei dati del bus di servizio di Azure
Bus di servizio (output) Mittente dei dati del bus di servizio di Azure

1 Per l'attivazione da argomenti del bus di servizio, l'assegnazione di ruolo deve avere un ambito effettivo sulla risorsa di sottoscrizione del bus di servizio. Se viene incluso solo l'argomento, si verifica un errore. Alcuni client, ad esempio il portale di Azure, non espongono la risorsa sottoscrizione del bus di servizio come ambito per l'assegnazione di ruoli. In questi scenari è invece possibile usare l'interfaccia della riga di comando di Azure. Per altre informazioni, vedere Ruoli predefiniti di Azure per il bus di servizio di Azure.

Stringhe di connessione nella versione 2. x

Versione 2. x dell'SDK non richiede un nome specifico per le stringhe di connessione. Nella versione 2. x, è possibile usare nomi personalizzati per queste stringhe di connessione e archiviarli altrove. È possibile impostare i nomi nel codice usando JobHostConfiguration, come nell'esempio seguente:

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

Nota

Perché la versione 3. x usa le API di configurazione predefinite di .NET Core, nessuna API esiste per modificare i nomi delle stringhe di connessione. Per altre informazioni, vedere Sviluppare e distribuire processi Web con Visual Studio.

Impostazioni di sviluppo dell'host

È possibile eseguire l'host in modalità di sviluppo per rendere più efficiente lo sviluppo locale. Ecco alcune delle impostazioni che cambiano automaticamente quando si esegue in modalità di sviluppo:

Proprietà Impostazione di sviluppo
Tracing.ConsoleLevel TraceLevel.Verbose per massimizzare l'output del log.
Queues.MaxPollingInterval Valore basso per garantire che i metodi della coda vengano attivati immediatamente.
Singleton.ListenerLockPeriod 15 secondi per facilitare lo sviluppo iterativo rapido.

Il processo di abilitazione della modalità di sviluppo dipende dalla versione dell'SDK.

Versione 3.x

Nella versione 3. x, si usano le API standard ASP.NET Core per modificare l'ambiente host. Chiamare il metodo UseEnvironment sull'istanza HostBuilder. Passare una stringa denominata development, come nell'esempio seguente:

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

Versione 2.x

La classe JobHostConfiguration ha un metodo UseDevelopmentSettings che abilita la modalità di sviluppo. L'esempio seguente mostra come usare le impostazioni di sviluppo. Per restituire config.IsDevelopment quando true viene eseguito in locale, impostare una variabile di ambiente locale denominata AzureWebJobsEnv con il valore Development.

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

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

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

Gestire le connessioni simultanee (versione 2.x)

Per impostazione predefinita, nella versione 3.x il limite di connessioni è infinito. Se per qualche motivo è necessario modificare questo limite, è possibile usare la proprietà MaxConnectionsPerServer della classe WinHttpHandler.

Nella versione 2. x, è possibile controllare il numero di connessioni simultanee a un host usando la ServicePointManager.DefaultConnectionLimit proprietà . In 2.x, è consigliabile aumentare questo valore rispetto al valore predefinito di 2 prima di avviare l'host dei processi Web.

Tutte le richieste HTTP in uscita effettuate da una funzione attraverso HttpClient passano attraverso ServicePointManager. Quando si raggiunge il valore impostato in DefaultConnectionLimit, ServicePointManager inizia ad accodare le richieste prima di inviarle. DefaultConnectionLimit Si supponga che sia impostato su 2 e che il codice effettui 1.000 richieste HTTP. Inizialmente, al sistema operativo sono consentite solo 2 richieste. Le altre 998 richieste vengono accodate finché non c'è spazio disponibile per loro. Un timeout del HttpClient potrebbe verificarsi in quanto sembra aver effettuato la richiesta, ma la richiesta non è mai stata inviata dal sistema operativo al server di destinazione. È possibile che venga visualizzato un comportamento che non sembra avere senso: l'ambiente locale HttpClient richiede 10 secondi per completare una richiesta, ma il servizio restituisce ogni richiesta in 200 ms.

Il valore predefinito per le applicazioni ASP.NET è Int32.MaxValuee probabilmente funziona correttamente per i processi Web in esecuzione in un piano di servizio app Basic o superiore. WebJobs richiedono in genere l'impostazione Always On, ed è supportata solo dai piani del servizio app di livello Basic o superiore.

Se il tuo WebJob è in esecuzione in un piano di App Service gratuito o condiviso, la tua applicazione è limitata dalla sandbox di App Service, che attualmente ha un limite di connessione di 600. Se si dispone di un limite di connessione illimitato in ServicePointManager, è più probabile che venga raggiunta la soglia della connessione sandbox e che il sito si arresti. In tal caso, l'impostazione su DefaultConnectionLimit un valore inferiore, ad esempio 200, può impedire che questo scenario si verifichi e consenta comunque una velocità effettiva sufficiente.

L'impostazione deve essere configurata prima che venga effettuata qualsiasi richiesta HTTP. Per questo motivo, l'host WebJobs non deve modificare automaticamente l'impostazione. Potrebbero verificarsi richieste HTTP prima dell'avvio dell'host, che possono causare comportamenti imprevisti. L'approccio migliore consiste nell'impostare il valore immediatamente nel Main metodo prima di inizializzare JobHost, come illustrato in questo esempio:

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

Trigger

WebJobs SDK supporta lo stesso set di trigger e binding usati da Funzioni di Azure . Nel WebJobs SDK, i trigger sono specifici delle funzioni e non sono correlati al tipo di distribuzione di WebJob. I processi Web con funzioni attivate dagli eventi create tramite l'SDK devono essere sempre pubblicati come processo Web continuo , con Always On abilitato.

Le funzioni devono essere metodi pubblici e devono avere un attributo trigger o l'attributo NoAutomaticTrigger .

Trigger automatici

I trigger automatici chiamano una funzione in risposta a un evento. Si consideri questo esempio di una funzione attivata da un messaggio aggiunto a una Azure Storage Queue. La funzione risponde leggendo un BLOB dall'archivio BLOB:

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

L'attributo QueueTrigger indica al runtime di chiamare la funzione ogni volta che viene visualizzato un messaggio della coda in myqueue-items. L'attributo Blob indica al runtime di usare il messaggio della coda per leggere un blob nel contenitore sample-workitems. Il nome dell'elemento BLOB nel contenitore samples-workitems viene ottenuto direttamente dal trigger della coda come espressione di associazione ({queueTrigger}).

Nota

Un'app Web può raggiungere il timeout dopo 20 minuti di inattività e solo le richieste all'app Web effettiva possono reimpostare il timer. La visualizzazione della configurazione dell'app nel portale di Azure o l'esecuzione di richieste al sito degli strumenti avanzati non reimposta il timer. Se si imposta l'app Web che ospita il processo per l'esecuzione continua, l'esecuzione in base a una pianificazione o l'uso di trigger basati su eventi, abilitare l'impostazione Always On nel riquadro Configurazione di Azure dell'app Web. L'impostazione AlwaysOn consente di assicurarsi che questi tipi di processi Web vengano eseguiti in modo affidabile. Questa funzionalità è disponibile solo nei piani tariffari Basic, Standard e Premium.

Trigger manuali

Per attivare manualmente una funzione, usare l'attributo NoAutomaticTrigger :

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

Il processo di attivazione manuale della funzione dipende dalla versione dell'SDK.

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

Versione 2.x

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

Associazioni di input e output

Le associazioni di input offrono una modalità dichiarativa per rendere disponibili nel codice i dati dei servizi di Azure o di terze parti. Le associazioni di output garantiscono un modo per aggiornare i dati. L'articolo Introduzione illustra un esempio di ciascun tipo di associazione.

È possibile usare un valore restituito dal metodo per un'associazione di output applicando l'attributo a tale valore. Vedere l'esempio in Uso del valore restituito della funzione di Azure.

Tipi di associazioni

Il processo per l'installazione e la gestione dei tipi di associazione varia a seconda che si usi la versione 3.x o la versione 2.x dell'SDK. È possibile trovare il pacchetto di installazione per un particolare tipo di associazione nella sezione "Pacchetti" dell'articolo di riferimento per Funzioni di Azure. Un'eccezione è il trigger e il binding per i file (per il sistema di file locale), che Azure Functions non supporta.

Versione 3.x

Nella versione 3.x le associazioni di archiviazione sono incluse nel pacchetto Microsoft.Azure.WebJobs.Extensions.Storage. Nel metodo AddAzureStorage, chiamare il metodo di estensione ConfigureWebJobs.

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

Per usare altri tipi di trigger e associazioni, installare il pacchetto NuGet che li contiene e chiamare il metodo di estensione Add<binding> implementato nell'estensione. Ad esempio, se si vuole usare un'associazione di Azure Cosmos DB, installare Microsoft.Azure.WebJobs.Extensions.CosmosDB e chiamare AddCosmosDB:

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

Per usare il trigger Timer o l'associazione File, che fanno parte dei servizi di base, chiamare i metodi di estensione AddTimers o AddFiles.

Versione 2.x

La versione 2.x del pacchetto Microsoft.Azure.WebJobs include i tipi di trigger e associazioni seguenti:

  • Archiviazione BLOB
  • Archiviazione code
  • Archiviazione tabelle

Per usare altri tipi di trigger e associazioni, installare il pacchetto NuGet che li contiene e chiamare un metodo Use<binding> nell'oggetto JobHostConfiguration. Ad esempio, se si vuole usare un Timer trigger, installare Microsoft.Azure.WebJobs.Extensions e chiamare UseTimers nel metodo Main.

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

Per usare l'associazione File, installare Microsoft.Azure.WebJobs.Extensions e chiamare UseFiles.

ExecutionContext

In WebJobs, è possibile eseguire il binding a un'istanza ExecutionContext. Con questo vincolo, puoi accedere a ExecutionContext come parametro nella definizione della tua funzione. Ad esempio, il codice seguente usa l'oggetto di contesto per accedere all'ID di chiamata, che può essere usato per correlare tutti i log prodotti da una determinata chiamata di funzione.

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

Il processo per l'associazione a ExecutionContext dipende dalla tua versione dell'SDK.

Versione 3.x

Nel metodo AddExecutionContextBinding, chiamare il metodo di estensione ConfigureWebJobs.

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

Versione 2.x

Il pacchetto Microsoft.Azure.WebJobs.Extensions citato in precedenza offre anche un tipo di associazione speciale che è possibile registrare chiamando il metodo UseCore. È possibile usare l'associazione per definire un ExecutionContext parametro nella firma della funzione:

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

Configurazione dell'associazione

È possibile configurare il comportamento di alcuni trigger e associazioni. Il processo di configurazione dipende dalla versione dell'SDK.

  • Versione 3.x: impostare la configurazione quando viene chiamato il metodo Add<Binding> in ConfigureWebJobs.
  • Versione 2.x: impostare la configurazione impostando le proprietà in un oggetto di configurazione passato a JobHost.

Queste impostazioni specifiche dell'associazione sono equivalenti alle impostazioni nel file di progetto in Azure Functions.

È possibile configurare le associazioni seguenti:

Configurazione del trigger di Azure Cosmos DB (versione 3.x)

Questo esempio illustra come configurare il trigger per 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();
    }
}

Per ulteriori informazioni, consultare il collegamento di Azure Cosmos DB.

Configurazione del trigger di Azure Event Hubs (versione 3.x)

Questo esempio illustra come configurare il trigger per Hub eventi:

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

Per ulteriori informazioni, vedere Collegamento Hub eventi.

Configurazione del trigger per archiviazione code

Gli esempi seguenti illustrano come configurare il trigger di archiviazione code.

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

Per ulteriori informazioni, consulta Associazione alla memoria di coda.

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

Per altre informazioni, vedere le host.json informazioni di riferimento sulla versione 1.x.

Configurazione dell'associazione SendGrid (versione 3.x)

Questo esempio illustra come configurare l'associazione di output 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();
    }
}

Per altre informazioni, vedere SendGrid Binding.

Configurazione del trigger per bus di servizio (versione 3.x)

Questo esempio illustra come configurare il trigger per bus di servizio:

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

Per ulteriori informazioni, vedere Service Bus binding.

Configurazione per altre associazioni

Alcuni tipi di trigger e associazione definiscono tipi propri di configurazione personalizzata. Ad esempio, è possibile usare il trigger File per specificare il percorso radice da monitorare, come negli esempi seguenti.

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

Espressioni di associazione

Nei parametri dei costruttori di attributi, è possibile usare espressioni che vengono risolte in valori provenienti da varie origini. Ad esempio, nel codice seguente il percorso all'attributo BlobTrigger crea un'espressione denominata filename. Quando viene usato per l'associazione di output, filename risolve il nome del BLOB di attivazione.

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

Per altre informazioni sulle espressioni di associazione, vedere Modelli ed espressioni di associazione nella documentazione di Funzioni di Azure.

Espressioni di associazione personalizzate

A volte si vuole specificare un nome di coda, un nome di BLOB o un contenitore oppure un nome di tabella nel codice anziché impostarlo come hardcoded. Ad esempio, si desidera specificare il nome della coda per l'attributo QueueTrigger in una variabile di ambiente o in un file di configurazione.

È possibile assegnare un nome di coda all'attributo passando un resolver di nomi personalizzato durante la configurazione. Includere segnaposto nei parametri del costruttore dell'attributo di trigger o associazione e il codice del resolver offrirà i valori effettivi da usare in sostituzione di questi segnaposto. È possibile identificare i segnaposto circondandoli con i segni di percentuale (%):

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

In questo codice si usa una coda denominata logqueuetest nell'ambiente di test e una coda denominata logqueueprod nell'ambiente di produzione. Invece di impostare un nome di coda come hardcoded, specificare il nome di una voce nella raccolta appSettings.

Un sistema di risoluzione predefinito diventa effettivo se non ne viene fornito uno personalizzato. Il valore predefinito riceve i valori dalle impostazioni dell'app o dalle variabili di ambiente.

A partire da .NET Core 3.1, l'istanza ConfigurationManager usata richiede il System.Configuration.ConfigurationManager pacchetto NuGet. L'esempio richiede l'istruzione using seguente:

using System.Configuration;

La NameResolver classe ottiene il nome della coda dalle impostazioni dell'applicazione.

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

Versione 3.x

Il resolver viene configurato tramite l'inserimento delle dipendenze. Questi esempi richiedono l'istruzione using seguente:

using Microsoft.Extensions.DependencyInjection;

Il resolver viene aggiunto chiamando il metodo di estensione ConfigureServices su HostBuilder, come nell'esempio seguente:

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

Versione 2.x

Passare la NameResolver classe all'oggetto JobHost :

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

Funzioni di Azure implementa INameResolver per ottenere valori dalle impostazioni dell'app, come mostrato nell'esempio. Quando si usa direttamente WebJobs SDK, è possibile scrivere un'implementazione personalizzata che ottiene i valori da usare in sostituzione dei segnaposto dall'origine preferita.

Associazione in fase di esecuzione

Se è necessario eseguire alcune operazioni nella funzione prima di usare un attributo di associazione come Queue, Blob o Table, è possibile usare l'interfaccia IBinder.

L'esempio seguente accetta un messaggio della coda di input e crea un nuovo messaggio con lo stesso contenuto in una coda di output. Il nome della coda di output viene impostato dal codice nel corpo della funzione.

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

Per altre informazioni, vedere Associazione in fase di esecuzione nella documentazione di Funzioni di Azure.

Informazioni di riferimento sull'associazione

La documentazione di Funzioni di Azure include informazioni di riferimento su ogni tipo di associazione. Le seguenti informazioni sono disponibili in ogni articolo di riferimento di vincolo. Questo esempio si basa su una coda di archiviazione.

  • Pacchetti. Il pacchetto che è necessario installare per includere il supporto per l'associazione in un progetto WebJobs SDK.
  • Esempi. Esempi di codice. L'esempio di libreria di classe C# si applica a WebJobs SDK. È sufficiente omettere l'attributo FunctionName.
  • Attributi. Gli attributi da usare per il tipo di associazione.
  • Configurazione. Le spiegazioni delle proprietà degli attributi e dei parametri del costruttore.
  • Utilizzo. I tipi con cui è possibile effettuare un'associazione e informazioni sul funzionamento dell'associazione. Ad esempio, un algoritmo di polling o l'elaborazione di code di messaggi problematici.

Nota

Le associazioni HTTP, Webhook e Griglia eventi sono supportate solo da Funzioni di Azure, non da WebJobs SDK.

Per un elenco completo delle associazioni supportate nel runtime di Funzioni di Azure, vedere Associazioni supportate.

Attributi: Disable, Timeout e Singleton

È possibile usare questi attributi per controllare l'attivazione delle funzioni, annullare le funzioni e assicurarsi che venga eseguita una sola istanza di una funzione.

Attributo Disable

Usare l'attributo Disable per controllare se è possibile attivare una funzione.

Nell'esempio seguente, se l'impostazione Disable_TestJob dell'app ha un valore pari 1 o True (non specifico del caso), la funzione non viene eseguita. In questo scenario, il runtime crea il messaggio di log Function 'Functions.TestJob' è disabilitata.

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

Quando si modificano i valori delle impostazioni dell'app nel portale di Azure, il processo Web viene riavviato per prelevare la nuova impostazione.

L'attributo può essere dichiarato a livello di parametro, metodo o classe. Il nome dell'impostazione può inoltre contenere espressioni di associazione.

Attributo Timeout

L'attributo Timeout fa sì che una funzione venga annullata se non viene completata entro un periodo di tempo specificato. Nell'esempio seguente la funzione viene eseguita per un giorno senza l'attributo Timeout . Il timeout determina l'annullamento della funzione dopo 15 secondi. Quando il parametro dell'attributo TimeoutthrowOnError è impostato su true, la chiamata alla funzione viene terminata con un'eccezione generata da WebJobs SDK quando viene superato l'intervallo di timeout. Il valore predefinito di throwOnError è false. Quando si usa l'attributo Timeout , il comportamento predefinito consiste nell'annullare la chiamata di funzione impostando il token di annullamento, consentendo l'esecuzione della chiamata per un periodo illimitato fino a quando il codice della funzione non restituisce o genera un'eccezione.

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

È possibile applicare l'attributo Timeout a livello di classe o a livello di metodo ed è possibile specificare un timeout globale usando JobHostConfiguration.FunctionTimeout. I timeout a livello di classe o di metodo sostituiscono i timeout globali.

Attributo Singleton

L'attributo Singleton garantisce che venga eseguita solo un'istanza di una funzione anche se sono presenti più istanze dell'app Web host. L'attributo Singleton usa il blocco distribuito per garantire che venga eseguita una sola istanza.

In questo esempio viene eseguita solo una singola istanza della funzione ProcessImage in un determinato momento:

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

SingletonMode.Listener

Alcuni trigger dispongono del supporto integrato per la gestione della concorrenza:

  • QueueTrigger. Impostare JobHostConfiguration.Queues.BatchSize su 1.
  • ServiceBusTrigger. Impostare ServiceBusConfiguration.MessageOptions.MaxConcurrentCalls su 1.
  • FileTrigger. Impostare FileProcessor.MaxDegreeOfParallelism su 1.

È possibile usare queste impostazioni per assicurarsi che la funzione viene eseguita come singleton in una singola istanza. Per assicurarsi che sia in esecuzione una sola istanza della funzione quando l'app Web aumenta il numero di istanze, applicare un blocco singleton a livello di listener per la funzione ([Singleton(Mode = SingletonMode.Listener)]). I blocchi a livello di listener vengono acquisiti all'avvio di JobHost. Se tutte e tre le istanze aumentate vengono avviate nello stesso momento, una sola istanza acquisisce il blocco e viene avviato un solo listener.

Nota

Per altre informazioni sul SingletonMode.Function funzionamento, vedere il repository GitHub SingletonMode.

Valori di ambito

È possibile specificare un'espressione/valore di ambito per un singleton. L'espressione/valore garantisce che tutte le esecuzioni della funzione in un ambito specifico vengano serializzate. Un'implementazione più granulare del blocco con questo metodo può consentire un certo livello di parallelismo per la funzione, consentendo allo stesso tempo la serializzazione di altre chiamate in base alle esigenze. Nel codice seguente, ad esempio, l'espressione di ambito è associata al valore Region del messaggio in arrivo. Quando la coda contiene tre messaggi nelle aree Orientale, Orientale e Occidentale, i messaggi con area Orientale vengono eseguiti serialmente. Il messaggio della regione Ovest viene eseguito in parallelo con i messaggi nella regione Est.

[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

L'ambito predefinito per un blocco è SingletonScope.Function. L'ambito di blocco (percorso lease blob) è associato al nome completo della funzione. Per applicare un blocco alle funzioni, specificare SingletonScope.Host e usare un nome di ID di ambito identico in tutte le funzioni che non si vuole eseguire simultaneamente. Nell'esempio seguente viene eseguita una sola istanza di AddItem o RemoveItem alla volta:

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

Visualizzazione dei BLOB di lease

L'SDK WebJobs utilizza i noleggi blob di Azure per implementare il blocco distribuito. I BLOB di lease usati da Singleton sono disponibili nel contenitore azure-webjobs-host dell'account di archiviazione AzureWebJobsStorage nel percorso "locks". Ad esempio, il percorso del BLOB di lease per il primo esempio ProcessImage illustrato in precedenza potrebbe essere locks/061851c758f04938a4426aa9ab3869c0/WebJobs.Functions.ProcessImage. Tutti i percorsi includono l'ID JobHost, in questo caso 061851c758f04938a426a9ab3869c0.

Funzioni asincrone

Per informazioni su come codificare le funzioni asincrone, vedere la documentazione di Funzioni di Azure.

Token di annullamento

Per informazioni su come gestire i token di annullamento, vedere la documentazione su token di annullamento e arresto normale di Funzioni di Azure.

Istanze multiple

Se l'app Web viene eseguita in più istanze, WebJob viene eseguito continuativamente in ogni istanza, in ascolto dei trigger e chiamando le funzioni. Le diverse associazioni di trigger sono progettate per condividere in modo efficiente la collaborazione tra le istanze, così che l'aumento delle istanze consenta di gestire un carico maggiore.

Anche se alcuni trigger potrebbero comportare un'elaborazione doppia, i trigger di archiviazione di coda e BLOB impediscono automaticamente a una funzione di elaborare un messaggio della coda o un BLOB più di una volta. Per altre informazioni, vedere Progettazione per input identico nella documentazione di Funzioni di Azure.

Il trigger del timer garantisce automaticamente che venga eseguita una sola istanza del timer, in modo che non si ottenga più di un'istanza della funzione in esecuzione in un determinato momento pianificato.

Se si vuole assicurarsi che venga eseguita una sola istanza di una funzione, anche quando sono presenti più istanze dell'app Web host, è possibile usare l'attributo Singleton .

Filtri

I filtri di funzione (anteprima) consentono di personalizzare la pipeline di esecuzione dei processi Web usando la propria logica. Questi filtri sono simili a ASP.NET filtri Core. Possono essere implementati come attributi dichiarativi che vengono applicati alle funzioni o alle classi. Per altre informazioni, vedere Function Filters.

Registrazione e monitoraggio

È consigliabile usare il framework di registrazione sviluppato per ASP.NET. L'articolo Introduzione illustra come usarlo.

Filtro del log

A ogni log creato da un'istanza ILogger sono associati i valori Category e Level. LogLevel è un'enumerazione e il codice integer ne indica l'importanza relativa:

LogLevel Codice
Traccia 0
Correzione errori di programma 1
Informazioni 2
Avviso 3
Errore 4
Critico 5
Nessuno 6

È possibile filtrare in modo indipendente ogni categoria in base a un determinato LogLevel valore. Ad esempio, si possono visualizzare tutti i log per l'elaborazione dei trigger BLOB, ma solo Error e livelli superiori per tutto il resto.

Versione 3.x

Versione 3. x dell'SDK si basa sul filtro integrato in .NET Core. Usare la LogCategories classe per definire categorie per funzioni, trigger o utenti specifici. La LogCategories classe definisce anche i filtri per stati host specifici, ad esempio Startup e Results, in modo da ottimizzare l'output della registrazione. Se non viene trovata alcuna corrispondenza nelle categorie definite, il filtro ripiega sul valore Default per determinare se filtrare il messaggio.

LogCategories richiede l'istruzione seguente using :

using Microsoft.Azure.WebJobs.Logging;

L'esempio seguente crea un filtro che per impostazione predefinita filtra tutti i log al livello Warning. Le categorie Function o results (equivalenti a Host.Results nella versione 2.x) vengono filtrate al livello Error. Il filtro confronta la categoria corrente con tutti i livelli registrati nell'istanza LogCategories e sceglie la corrispondenza più lunga. Quindi il Debug livello registrato per Host.Triggers corrisponde a Host.Triggers.Queue o Host.Triggers.Blob. È possibile controllare categorie più ampie senza dover aggiungere ognuna di esse.

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

Versione 2.x

Nella versione 2.x dell'SDK la classe LogCategoryFilter viene usata per controllare il filtro. LogCategoryFilter ha una proprietà Default con un valore iniziale Information. Ciò significa che tutti i messaggi con i livelli Information, Warning, Error o Critical vengono registrati, ma tutti i messaggi con i livelli Debug o Trace vengono esclusi.

Come con LogCategories nella versione 3.x, la proprietà CategoryLevels consente di specificare i livelli di log per determinate categorie in modo che sia possibile ottimizzare l'output della registrazione. Se non viene trovata alcuna corrispondenza all'interno del CategoryLevels dizionario, il filtro esegue il fallback al Default valore quando si determina se filtrare il messaggio.

L'esempio seguente crea un filtro che per impostazione predefinita filtra tutti i log al livello Warning. Le categorie Function o Host.Results vengono filtrate al livello Error. LogCategoryFilter confronta la categoria corrente con tutti i valori CategoryLevels registrati e sceglie la corrispondenza più lunga. Quindi il Debug livello registrato per Host.Triggers corrisponde a Host.Triggers.Queue o Host.Triggers.Blob. È possibile controllare categorie più ampie senza dover aggiungere ognuna di esse.

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

Telemetria personalizzata per Application Insights

Il processo di implementazione della telemetria personalizzata per Application Insights dipende dalla versione dell'SDK. Per informazioni su come configurare Application Insights, vedere Aggiungere la registrazione in Application Insights.

Versione 3.x

Dal momento che la versione 3.x di WebJobs SDK si basa sull'host generico di .NET Core, non viene più fornita una factory di telemetria personalizzata. Tuttavia, è possibile aggiungere dati di telemetria personalizzati alla pipeline tramite l'inserimento delle dipendenze. Gli esempi in questa sezione richiedono le istruzioni using seguenti:

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

È possibile usare l'implementazione personalizzata seguente di ITelemetryInitializer per aggiungere la propria ITelemetry istanza all'impostazione predefinita TelemetryConfiguration.

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

Chiamare ConfigureServices nel generatore per aggiungere un'istanza personalizzata ITelemetryInitializer alla pipeline.

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

Quando TelemetryConfiguration viene costruito, vengono inclusi tutti i tipi registrati di ITelemetryInitializer . Per altre informazioni, vedere API di Application Insights per metriche ed eventi personalizzati.

Nella versione 3.x, non è necessario svuotare TelemetryClient quando l'host si arresta. Il sistema di inserimento delle dipendenze di .NET Core elimina automaticamente l'istanza registrata ApplicationInsightsLoggerProvider, che svuota TelemetryClient.

Versione 2.x

Nella versione 2. x, l'istanza TelemetryClient creata internamente dal provider di Application Insights per WebJobs SDK usa ServerTelemetryChannel. Quando l'endpoint di Application Insights non è disponibile o limita le richieste in ingresso, questo canale salva le richieste nel file system dell'app Web e le invia nuovamente in un secondo momento.

TelemetryClient viene creato da una classe che implementa ITelemetryClientFactory. Per impostazione predefinita, questa classe è DefaultTelemetryClientFactory.

Se si vuole modificare qualsiasi parte della pipeline di Application Insights, è possibile fornire la propria istanza di ITelemetryClientFactory. L'host usa quindi la classe per costruire TelemetryClient. Ad esempio, questo codice esegue l'override di DefaultTelemetryClientFactory per modificare una proprietà di 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;
    }
}

L'oggetto SamplingPercentageEstimatorSettings configura il campionamento adattivo. In questo scenario, in alcuni scenari con volumi elevati, Applications Insights invia un subset selezionato di dati di telemetria al server.

Dopo aver creato la factory di telemetria, passarla al provider di log di Application Insights:

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

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

Contenuti correlati

Questo articolo fornisce frammenti di codice che illustrano come gestire scenari comuni per l'uso di WebJobs SDK. Per trovare esempi completi, vedere azure-webjobs-sdk-samples.