Come configurare il monitoraggio per Funzioni di Azure

Funzioni di Azure si integra con Application Insights per offrire un monitoraggio migliore delle app per le funzioni. Application Insights, una funzionalità di Monitoraggio di Azure, è un servizio APM (Application Performance Management) estendibile che raccoglie i dati generati dall'app per le funzioni, incluse le informazioni che l'app scrive nei log. L'integrazione di Application Insights viene in genere abilitata quando viene creata l'app per le funzioni. Se l'app per le funzioni non dispone del set di chiavi di strumentazione, occorre prima abilitare l'integrazione di Application Insights.

È possibile usare Application Insights senza alcuna operazione di configurazione personalizzata, La configurazione predefinita, tuttavia, può già produrre elevati volumi di dati. Se si usa una sottoscrizione di Azure di Visual Studio, si potrebbe raggiunge il limite d'uso dati per Application Insights. Per informazioni su Application Insights, vedere Fatturazione di Application Insights. Per altre informazioni, vedere Soluzioni con elevato volume di dati di telemetria.

In questo articolo viene illustrato come configurare e personalizzare i dati inviati dalle funzioni ad Application Insights. È possibile impostare configurazioni di registrazione comuni nel file host.json. Per impostazione predefinita, queste impostazioni regolano anche i log personalizzati emessi dal codice. In alcuni casi, tuttavia, questo comportamento può essere disabilitato a favore di opzioni che consentono un maggiore controllo sulla registrazione. Per altre informazioni, vedere Log di applicazioni personalizzati.

Nota

È possibile usare impostazioni dell'applicazione configurate appositamente per rappresentare impostazioni specifiche in un file host.json per un ambiente particolare. In tal modo, è possibile modificare in modo efficace le impostazioni di host.json senza dover ripubblicare il file host.json nel progetto. Per altre informazioni, vedere Eseguire l'override dei valori di host.json.

Log di applicazioni personalizzati

Per impostazione predefinita, i log di applicazioni personalizzati scritti vengono inviati all'host Funzioni, che li invia ad Application Insights nella categoria Ruolo di lavoro. Alcuni stack di linguaggio, invece, consentono di inviare i log direttamente ad Application Insights, che consente il controllo completo sul modo in cui vengono emessi i log scritti. In questo caso, la pipeline di registrazione passa da worker -> Functions host -> Application Insights a worker -> Application Insights.

La tabella seguente riepiloga le opzioni di configurazione disponibili per ogni stack:

Stack linguaggio	Dove configurare i log personalizzati
.NET (modello In-Process)	host.json
.NET (modello Isolato)	Impostazione predefinita (inviare log personalizzati all'host Funzioni): host.json Per inviare i log direttamente ad Application Insights, vedere: Configurare Application Insights in HostBuilder
Node.JS	host.json
Python	host.json
Java	Impostazione predefinita (inviare log personalizzati all'host Funzioni): host.json Per inviare i log direttamente ad Application Insights, vedere: Configurare l’agente Java di Application Insights
PowerShell	host.json

Quando si configurano log di applicazioni personalizzati da inviare direttamente, l'host non li emette più e host.json non ne controlla più il comportamento. Analogamente, le opzioni esposte da ogni stack si applicano solo ai log personalizzati e non modificano il comportamento degli altri log di runtime descritti in questo articolo. In questo caso, per controllare il comportamento di tutti i log, potrebbe essere necessario apportare modifiche in entrambe le configurazioni.

Configurare le categorie

Il logger di Funzioni di Azure include un categoria per ogni log. La categoria indica quale parte del codice runtime o del codice funzione è stata scritta dal log. Le categorie variano tra la versione 1.x e le versioni successive.

I nomi delle categorie vengono assegnati in Funzioni in modo diverso rispetto ad altri framework .NET. Ad esempio, quando si usa ILogger<T> in ASP.NET, la categoria è il nome del tipo generico. Le funzioni C# usano anche ILogger<T>, ma invece di impostare il nome di tipo generico come categoria, il runtime assegna le categorie in base all'origine. Ad esempio:

• Alle voci correlate all'esecuzione di una funzione viene assegnata una categoria di Function.<FUNCTION_NAME>.
• Alle voci create dal codice utente all'interno della funzione, ad esempio quando si chiama logger.LogInformation(), viene assegnata una categoria di Function.<FUNCTION_NAME>.User.

La tabella seguente descrive le principali categorie di log create dal runtime:

v2.x+

Categoria	Tabella	Descrizione
Function	traces	Include i log di funzione avviati e completati per tutte le esecuzioni di funzioni. Per l’esito positivo delle esecuzioni, questi log si trovano al livello Information. Le eccezioni vengono registrate al livello Error. Il runtime crea anche log di livello Warning, ad esempio messaggi della coda inviati alla coda non elaborabile.
Function.<YOUR_FUNCTION_NAME>	dependencies	Per alcuni servizi vengono raccolti automaticamente dati di dipendenza. Per l’esito positivo delle esecuzioni, questi log si trovano al livello Information. Per altre informazioni, vedere Dipendenze. Le eccezioni vengono registrate al livello Error. Il runtime crea anche log di livello Warning, ad esempio messaggi della coda inviati alla coda non elaborabile.
Function.<YOUR_FUNCTION_NAME>	customMetrics customEvents	Gli SDK C# e JavaScript consentono di raccogliere metriche personalizzate e registrare eventi personalizzati. Per altre informazioni, vedere Dati di telemetria personalizzati.
Function.<YOUR_FUNCTION_NAME>	traces	Include i log di funzione avviati e completati per tutte esecuzioni di funzioni specifiche. Per l’esito positivo delle esecuzioni, questi log si trovano al livello Information. Le eccezioni vengono registrate al livello Error. Il runtime crea anche log di livello Warning, ad esempio messaggi della coda inviati alla coda non elaborabile.
Function.<YOUR_FUNCTION_NAME>.User	traces	Log generati dall'utente, che possono essere di qualunque livello di log. Per altre informazioni sulla scrittura nei log dalle funzioni, vedere Scrittura nei log.
Host.Aggregator	customMetrics	Questi log generati dal runtime forniscono il numero e le medie di chiamate alla funzione in un periodo di tempo configurabile. Il periodo predefinito è 30 secondi o 1000 risultati, ovvero quello che viene prima. Gli esempi indicano il numero di esecuzioni, la percentuale di riuscita e la durata. Tutti questi log vengono scritti al livello Information. Se si filtra per Warning o livello successivo, questi dati non verranno visualizzati.
Host.Results	requests	Questi log generati dal runtime indicano l'esito positivo o negativo di una funzione. Tutti questi log vengono scritti al livello Information. Se si filtra per Warning o livello successivo, questi dati non verranno visualizzati.
Microsoft	traces	Categoria di log completa che riflette un componente di runtime .NET richiamato dall'host.
Worker	traces	Log generati dal processo di lavoro del linguaggio per linguaggi non .NET. I log del ruolo di lavoro del linguaggio possono essere registrati anche in una categoria Microsoft.*, ad esempio Microsoft.Azure.WebJobs.Script.Workers.Rpc.RpcFunctionInvocationDispatcher. Questi log vengono scritti al livello Information.

Nota

Per le funzioni della libreria di classi .NET, queste categorie presuppongono l'uso di ILogger e non ILogger<T>. Per altre informazioni, vedere la documentazione ILogger di Funzioni.

v1.x

Categoria	Tabella	Descrizione
Function	traces	Log generati dall'utente, che possono essere di qualunque livello di log. Per altre informazioni sulla scrittura nei log dalle funzioni, vedere Scrittura nei log.
Host.Aggregator	customMetrics	Questi log generati dal runtime forniscono il numero e le medie di chiamate alla funzione in un periodo di tempo configurabile. Il periodo predefinito è 30 secondi o 1000 risultati, ovvero quello che viene prima. Gli esempi indicano il numero di esecuzioni, la percentuale di riuscita e la durata. Tutti questi log vengono scritti al livello Information. Se si filtra per Warning o livello successivo, questi dati non verranno visualizzati.
Host.Executor	traces	Include log di funzione avviati e log di funzione completati per esecuzioni di funzioni specifiche. Per l’esito positivo delle esecuzioni, questi log si trovano al livello Information. Le eccezioni vengono registrate al livello Error. Il runtime crea anche log di livello Warning, ad esempio quando vengono inviati messaggi della coda alla coda non elaborabile.
Host.Results	requests	Questi log generati dal runtime indicano l'esito positivo o negativo di una funzione. Tutti questi log vengono scritti al livello Information. Se si filtra per Warning o livello successivo, questi dati non verranno visualizzati.

La colonna Tabella indica la tabella in Application Insights in cui è scritto il log.

Configurare i livelli di log

A ogni log è assegnato un livello di log. Il valore è un numero intero che indica l'importanza relativa:

LogLevel	Codice	Descrizione
Traccia	0	Log che contengono i messaggi più dettagliati. Questi messaggi potrebbero contenere dati sensibili dell'applicazione. Questi messaggi sono disabilitati per impostazione predefinita e non devono mai essere abilitati in un ambiente di produzione.
Debug	1	Log usati per l'analisi interattiva durante lo sviluppo. Questi log devono contenere principalmente informazioni utili per il debug e non hanno un valore a lungo termine.
Informazioni	2	Log che tengono traccia del flusso generale dell'applicazione. Questi log devono avere un valore a lungo termine.
Avviso	3	Log che evidenziano un evento anomalo o imprevisto nel flusso dell'applicazione, ma non causano in altro modo l'arresto dell'esecuzione dell'applicazione.
Error	4	Log che evidenziano quando il flusso di esecuzione corrente viene arrestato a causa di un errore. Questi errori devono indicare un errore nell'attività corrente, non un errore a livello di applicazione.
Critico	5	Log che descrivono un arresto anomalo irreversibile di un'applicazione o del sistema o un errore irreversibile che richiede attenzione immediata.
None	6	Disabilita la registrazione per la categoria specificata.

La configurazione del file host.json determina l’entità della registrazione inviata ad Application Insights da un'app per le funzioni.

Per ogni categoria, si indica il livello di registrazione minimo da inviare. Le impostazioni di host.json variano a seconda della versione del runtime di Funzioni.

Gli esempi seguenti definiscono la registrazione in base alle regole seguenti:

• Il livello di registrazione predefinito è impostato su Warning per impedire la registrazione eccessiva per categorie non previste.
• Host.Aggregator e Host.Results sono impostati su livelli inferiori. L'impostazione di livelli di registrazione eccessivi (soprattutto superiori a Information) può comportare la perdita di metriche e dati sulle prestazioni.
• La registrazione per le esecuzioni di funzioni è impostata su Information. Se necessario, è possibile eseguire l’override di questa impostazione nello sviluppo locale in Debug o Trace.

v2.x+

{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Warning",
      "Host.Aggregator": "Trace",
      "Host.Results": "Information",
      "Function": "Information"
    }
  }
}

v1.x

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Warning",
      "categoryLevels": {
        "Host.Results": "Information",
        "Host.Aggregator": "Trace",
        "Function": "Information"
      }
    }
  }
}

Se host.json include più log che iniziano con la stessa stringa, viene rilevata prima la corrispondenza dei log più definiti. Considerare l'esempio seguente che registra tutto nel runtime, tranne Host.Aggregator, a livello Error:

v2.x+

{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Information",
      "Host": "Error",
      "Function": "Error",
      "Host.Aggregator": "Information"
    }
  }
}

v1.x

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Information",
      "categoryLevels": {
        "Host": "Error",
        "Function": "Error",
        "Host.Aggregator": "Information"
      }
    }
  }
}

È possibile usare un'impostazione del livello di log di None per impedire la scrittura di log per una categoria.

Attenzione

Funzioni di Azure si integra con Application Insights archiviando eventi di telemetria in tabelle di Application Insights. Se si imposta un livello di log di una categoria su qualunque valore diverso da Information, viene impedito il flusso di dati di telemetria in tali tabelle e non sarà possibile visualizzare i dati correlati nelle schede Application Insights e Monitoraggio funzioni.

Ad esempio, per gli esempi precedenti:

• Se si imposta la categoria Host.Results sul livello di log Error, Azure raccoglie solo gli eventi di telemetria dell'esecuzione dell’host nella tabella requests per le esecuzioni di funzioni non riuscite, impedendo la visualizzazione dei dettagli di esecuzione dell'host delle esecuzioni riuscite sia nelle schede Application Insights che Monitoraggio funzioni.
• Se si imposta la categoria Function sul livello di log Error, viene interrotta la raccolta dei dati di telemetria delle funzioni correlati a dependencies, customMetrics e customEvents per tutte le funzioni, impedendo la visualizzazione di tali dati in Application Insights. Azure raccoglie solo traces registrati a livello Error.

In entrambi i casi, Azure continua a raccogliere errori ed eccezioni nelle schede Application Insights e Monitoraggio funzioni. Per altre informazioni, vedere Soluzioni con elevato volume di dati di telemetria.

Configurare l'aggregatore

Come indicato nella sezione precedente, il runtime aggrega i dati sulle esecuzioni di funzioni in un periodo di tempo. Il periodo predefinito è 30 secondi o 1000 esecuzioni, ovvero quello che viene prima. È possibile configurare questa impostazione nel file host.json. Ad esempio:

{
    "aggregator": {
      "batchSize": 1000,
      "flushTimeout": "00:00:30"
    }
}

Configurare il campionamento

Application Insights ha una funzionalità di campionamento che consente di evitare la produzione di un numero eccessivo di dati di telemetria sulle esecuzioni completate nei picchi di carico. Quando la frequenza delle esecuzioni in ingresso supera una soglia specificata, Application Insights inizia a ignorare in modo casuale alcune delle esecuzioni in ingresso. Il valore predefinito per il numero massimo di elementi al secondo è 20 (cinque nella versione 1.x). È possibile configurare il campionamento nel file host.json. Ecco un esempio:

v2.x+

{
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond" : 20,
        "excludedTypes": "Request;Exception"
      }
    }
  }
}

Dal campionamento è possibile escludere determinati tipi di dati di telemetria. In questo esempio, dal campionamento sono esclusi dati di tipo Request e Exception. Garantisce la registrazione di tutte le esecuzioni di funzioni (richieste) e le eccezioni, mentre altri tipi di dati di telemetria rimangono soggetti al campionamento.

v1.x

{
  "applicationInsights": {
    "sampling": {
      "isEnabled": true,
      "maxTelemetryItemsPerSecond" : 5
    }
  }
}

Se il progetto usa una dipendenza dall’SDK Application Insights per eseguire il rilevamento manuale dei dati di telemetria, potrebbe verificarsi un comportamento insolito se la configurazione del campionamento è diversa da quella nell'app per le funzioni. In questi casi, usare la stessa configurazione del campionamento dell'app per le funzioni. Per altre informazioni, vedere Campionamento in Application Insights.

Abilitare la raccolta di query SQL

Application Insights raccoglie automaticamente dati sulle dipendenze per richieste HTTP, chiamate di database e diverse associazioni. Per altre informazioni, vedere Dipendenze. Per le chiamate SQL, il nome del server e del database viene sempre raccolto e memorizzato, ma il testo della query SQL non viene raccolto per impostazione predefinita. È possibile usare dependencyTrackingOptions.enableSqlCommandTextInstrumentation per abilitare la registrazione del testo delle query SQL usando le impostazioni seguenti (almeno) nel file host.json:

"logging": {
    "applicationInsights": {
        "enableDependencyTracking": true,    
        "dependencyTrackingOptions": {
            "enableSqlCommandTextInstrumentation": true
        }
    }
}

Per altre informazioni, vedere Rilevamento SQL avanzato per ottenere la query SQL completa.

Configurare i log del controller di scalabilità

Questa funzionalità è in anteprima.

È possibile che il controller di scalabilità di Funzioni di Azure emetta log in Application Insights o nell'archiviazione BLOB per comprendere meglio le decisioni prese dal controller di scalabilità per l'app per le funzioni.

Per abilitare questa funzionalità, aggiungere un'impostazione dell'applicazione denominata SCALE_CONTROLLER_LOGGING_ENABLED alle impostazioni dell'app per le funzioni. Il valore seguente dell'impostazione deve essere nel formato <DESTINATION>:<VERBOSITY>. Per altre informazioni, vedere la tabella seguente:

Proprietà	Descrizione
<DESTINATION>	Destinazione a cui sono inviati i log. I valori validi sono AppInsights e Blob. Quando si usa AppInsights, assicurarsi che Application Insights sia abilitato nell'app per le funzioni. Quando si imposta la destinazione su Blob, i log vengono creati in un contenitore BLOB denominato azure-functions-scale-controller nell'account di archiviazione predefinito impostato nell'impostazione dell'applicazione AzureWebJobsStorage.
<VERBOSITY>	Specifica il livello di registrazione. I valori supportati sono None, Warning e Verbose. Se impostato su Verbose, il controller di scalabilità registra un motivo per ogni modifica nel conteggio dei ruoli di lavoro e le informazioni sui trigger che determinano tali decisioni. I log dettagliati includono avvisi di trigger e codici hash usati dai trigger prima e dopo l'esecuzione del controller di scalabilità.

Suggerimento

Tenere presente che, mentre si lascia abilitata la registrazione del controller di scalabilità, questa influisce sui potenziali costi del monitoraggio dell'app per le funzioni. Valutare la possibilità di abilitare la registrazione fino a quando non saranno stati raccolti dati sufficienti per comprendere il comportamento del controller di scalabilità, quindi disabilitarla.

Ad esempio, il comando seguente dell'interfaccia della riga di comando di Azure attiva la registrazione dettagliata dal controller di scalabilità in Application Insights:

az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:Verbose

In questo esempio, sostituire <FUNCTION_APP_NAME> e <RESOURCE_GROUP_NAME> rispettivamente con il nome dell'app per le funzioni e il nome del gruppo di risorse.

Il comando seguente dell'interfaccia della riga di comando di Azure disabilita la registrazione impostando il dettaglio su None:

az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:None

È anche possibile disabilitare la registrazione rimuovendo l'impostazione SCALE_CONTROLLER_LOGGING_ENABLED usando il comando seguente dell'interfaccia della riga di comando di Azure:

az functionapp config appsettings delete --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--setting-names SCALE_CONTROLLER_LOGGING_ENABLED

Con la registrazione del controller di scalabilità abilitata, ora è possibile eseguire query nei log del controller di scalabilità.

Abilitare l'integrazione di Application Insights

Affinché un'app per le funzioni invii dati ad Application Insights, è necessario conoscere la risorsa di Application Insights che usa solo una delle seguenti impostazioni dell’applicazione:

Nome impostazione	Descrizione
APPLICATIONINSIGHTS_CONNECTION_STRING	Questa impostazione è consigliata e necessaria quando l'istanza di Application Insights viene eseguita in un cloud sovrano. La stringa di connessione supporta altre nuove funzionalità.
APPINSIGHTS_INSTRUMENTATIONKEY	Impostazione legacy, deprecata da Application Insights a favore dell'impostazione della stringa di connessione.

Quando si crea un'app per le funzioni nel portale di Azure dalla riga di comando tramite Azure Functions Core Tools o Visual Studio Code, l'integrazione di Application Insights viene abilitata per impostazione predefinita. La risorsa di Application Insights ha lo stesso nome dell'app per le funzioni e viene creata nella stessa area o in quella più vicina.

Richiedere l'autenticazione Microsoft Entra

È possibile usare l'impostazione APPLICATIONINSIGHTS_AUTHENTICATION_STRING per abilitare le connessioni ad Application Insights usando l'autenticazione Microsoft Entra. Questo crea un'esperienza di autenticazione coerente in tutte le pipeline di Application Insights, inclusi Profiler e Snapshot Debugger, come anche dall'host di Funzioni e da agenti specifici della lingua.

Nota

Non è previsto un supporto per l'autenticazione tramite Entra per lo sviluppo locale.

Il valore contiene Authorization=AAD per un'identità gestita assegnata dal sistema o ClientId=<YOUR_CLIENT_ID>;Authorization=AAD per un'identità gestita assegnata dall'utente. L'identità gestita deve essere già disponibile nell'app per le funzioni, con un ruolo assegnato equivalente ad Autore delle metriche di monitoraggio. Per altre informazioni, vedere Autenticazione di Microsoft Entra per Application Insights.

L'impostazione APPLICATIONINSIGHTS_CONNECTION_STRING è ancora richiesta.

Nota

Quando si usa APPLICATIONINSIGHTS_AUTHENTICATION_STRING per connettersi ad Application Insights tramite l'autenticazione Microsoft Entra, è consigliabile anche disabilitare l'autenticazione locale per Application Insights. Questa configurazione richiede l'autenticazione di Microsoft Entra affinché i dati di telemetria vengano inseriti nell'area di lavoro.

Nuova app per le funzioni nel portale

Per verificare la risorsa di Application Insights appena creata, selezionarla per espandere la finestra Application Insights. È possibile cambiare il Nome nuova risorsa oppure scegliere una Posizione diversa in un’area geografica di Azure in cui si desidera archiviare i dati.

Se si seleziona Crea, viene creata una risorsa di Application Insights con l'app per le funzioni con il parametro APPLICATIONINSIGHTS_CONNECTION_STRING impostato nelle impostazioni dell'applicazione. È tutto pronto per iniziare.

Aggiungere un'app per le funzioni esistente

Se una risorsa di Application Insights non è stata creata con l'app per le funzioni, usare la procedura seguente per creare la risorsa. È possibile, quindi, aggiungere la stringa di connessione da tale risorsa come impostazione dell'applicazione nell'app per le funzioni.

1. Nel portale di Azure, cercare e selezionare l’app per le funzioni, quindi selezionare l’app per le funzioni.

2. Selezionare il banner Application Insights non è configurato nella parte superiore della finestra. Se questo banner non è visibile, Application Insights potrebbe già essere abilitato per l'app.

   

3. Espandere Modificare la risorsa e creare una risorsa di Application Insights usando le impostazioni specificate nella tabella seguente:

   Impostazione	Valore suggerito	Descrizione
   Nuovo nome risorsa	Nome app univoco	È più facile usare lo stesso nome dell'app per le funzioni, che deve essere univoco nella sottoscrizione.
   Location	Europa occidentale	Se possibile, usare la stessa area dell'app per le funzioni o una vicina a tale area.

   

4. Selezionare Applica.

   La risorsa di Application Insights viene creata nella stesso gruppo di risorse e nella stessa sottoscrizione dell'app per le funzioni. Dopo aver creato la risorsa, chiudere la finestra di Application Insights.

5. Nell'app per le funzioni, espandere Impostazionie selezionare Variabili di ambiente. Nella scheda Impostazioni app, se viene visualizzata un’impostazione denominata APPLICATIONINSIGHTS_CONNECTION_STRING, l’integrazione di Application Insights è abilitata per l’app per le funzioni in esecuzione in Azure. Se questa impostazione non esiste, aggiungerla usando la stringa di connessione di Application Insights come valore.

Nota

Altre app per le funzioni meno recenti potrebbero usare APPINSIGHTS_INSTRUMENTATIONKEY anziché APPLICATIONINSIGHTS_CONNECTION_STRING. Quando possibile, aggiornare l'app per usare la stringa di connessione anziché la chiave di strumentazione.

Disabilitare la registrazione predefinita

Nelle versioni precedenti di Funzioni veniva usato il servizio di monitoraggio incorporato, che non è più consigliato. Quando si abilita Application Insights, disabilitare la registrazione predefinita che usa Archiviazione di Azure. La registrazione predefinita risulta utile per i test con carichi di lavoro leggeri, ma non è destinata all'uso in ambienti di produzione con carichi elevati. Per il monitoraggio della produzione, è consigliabile usare Application Insights. Se si usa la registrazione predefinita in produzione, è possibile che il record di registrazione sia incompleto a causa della limitazione delle richieste in Archiviazione di Azure.

Per disabilitare la registrazione predefinita, eliminare l'impostazione app AzureWebJobsDashboard. Per altre informazioni su come eliminare impostazioni dell’app nel portale di Azure, vedere la sezione Impostazioni dell'applicazione in Come gestire un'app per le funzioni. Prima di eliminare l'impostazione dell'app, accertarsi che l'impostazione non sia usata da altre funzioni esistenti nella stessa app per le funzioni per attivazioni o associazioni di Archiviazione di Azure.

Soluzioni con un elevato volume di dati di telemetria

Le app per le funzioni costituiscono una parte essenziale delle soluzioni che possono causare elevati volumi di dati di telemetria, ad esempio soluzioni IoT, soluzioni basate su eventi rapidi, sistemi finanziari ad elevato carico e sistemi di integrazione. In questo caso, è consigliabile considerare una configurazione aggiuntiva per ridurre i costi mantenendo al tempo stesso l'osservabilità.

I dati di telemetria generati possono essere utilizzati in dashboard in tempo reale, avvisi, diagnostica dettagliata e così via. A seconda della modalità di utilizzo dei dati di telemetria generati, è necessario definire una strategia per ridurre il volume di dati generati. Questa strategia consente di monitorare, gestire e diagnosticare correttamente le app per le funzioni in produzione. Valutare le opzioni seguenti:

• Usare il campionamento: come accennato in precedenza, il campionamento consente di ridurre notevolmente il volume degli eventi di telemetria inseriti mantenendo un'analisi statisticamente corretta. Potrebbe accadere che anche usando il campionamento si ottenga ancora un elevato volume di dati di telemetria. Esaminare le opzioni fornite dal campionamento adattivo. Ad esempio, impostare maxTelemetryItemsPerSecond su un valore che bilancia il volume generato con le esigenze di monitoraggio. Tenere presente che il campionamento dei dati di telemetria viene applicato per ogni host che esegue l'app per le funzioni.

• Livello di logo predefinito: usare Warning o Error come valore predefinito per tutte le categorie di telemetria. Successivamente, è possibile decidere quali categorie si desidera impostare a livello Information, in modo da poter monitorare e diagnosticare correttamente le funzioni.

• Ottimizzare i dati di telemetria delle funzioni: con il livello di log predefinito impostato su Error o Warning, non vengono raccolte informazioni dettagliate da ogni funzione (dipendenze, metriche personalizzate, eventi personalizzati e tracce). Per le funzioni chiave per il monitoraggio in produzione, definire una voce esplicita per la categoria Function.<YOUR_FUNCTION_NAME> e impostarla su Information, in modo da poter raccogliere informazioni dettagliate. Per evitare di raccogliere log generati dall'utente a livello Information, impostare la categoria Function.<YOUR_FUNCTION_NAME>.User sul livello di log Error o Warning.

• Categoria Host.Aggregator: come descritto in Configurare le categorie, questa categoria fornisce informazioni aggregate delle chiamate di funzione. Le informazioni da questa categoria vengono raccolte nella tabella customMetrics di Application Insights e vengono visualizzate nella scheda Panoramica delle funzioni nel portale di Azure. A seconda di come si configura l'aggregatore, tenere presente che può verificarsi un ritardo, determinato dall'impostazione flushTimeout, nei dati di telemetria raccolti. Se si imposta questa categoria su un valore diverso da Information, si interrompe la raccolta dei dati nella tabella customMetrics e non vengono visualizzate le metriche nella scheda Panoramica delle funzioni.

  Lo screenshot seguente mostra i dati di telemetria di Host.Aggregator visualizzati nella scheda Panoramica:

  

  Lo screenshot seguente mostra dati di telemetria di Host.Aggregator nella customMetrics tabella di Application Insights:

  

• Categoria Host.Results: come descritto in Configurare le categorie, questa categoria fornisce i log generati dal runtime indicanti l'esito positivo o negativo di una chiamata di funzione. Le informazioni da questa categoria vengono raccolte nella tabella requests di Application Insights e vengono visualizzate nella scheda Monitoraggio delle funzioni e in diversi dashboard di Application Insights (Prestazioni, Errori e così via). Se si imposta questa categoria su un valore diverso da Information, si raccolgono solo i dati di telemetria generati al livello di log definito (o superiore). Ad esempio, impostandolo su error, viene eseguito il rilevamento dei dati delle richieste solo per le esecuzioni non riuscite.

  Lo screenshot seguente mostra i dati di telemetria di Host.Results visualizzati nella scheda Monitoraggio delle funzioni:

  

  Lo screenshot seguente mostra i dati di telemetria di Host.Results visualizzati nel dashboard Prestazioni di Application Insights:

  

• Host.Aggregator e Host.Results: entrambe le categorie forniscono informazioni valide sulle esecuzioni delle funzioni. Se necessario, è possibile rimuovere le informazioni dettagliate da una di queste categorie in modo da poter usare l'altra per il monitoraggio e gli avvisi. Di seguito è riportato un esempio:

v2.x+

{
  "version": "2.0",  
  "logging": {
    "logLevel": {
      "default": "Warning",
      "Function": "Error",
      "Host.Aggregator": "Error",
      "Host.Results": "Information", 
      "Function.Function1": "Information",
      "Function.Function1.User": "Error"
    },
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond": 1,
        "excludedTypes": "Exception"
      }
    }
  }
} 

v1.x

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Warning",
      "categoryLevels": {
        "Function": "Error",
        "Host.Aggregator": "Error",
        "Host.Results": "Information",
        "Host.Executor": "Warning"
      }
    }
  },
  "applicationInsights": {
    "sampling": {
      "isEnabled": true,
      "maxTelemetryItemsPerSecond" : 5
    }
  }
}

Con questa configurazione:

• Il valore predefinito per tutte le funzioni e le categorie di dati di telemetria è impostato su Warning (incluse le categorie Microsoft e Ruolo di lavoro). Di conseguenza, per impostazione predefinita vengono raccolti tutti gli errori e le avvertenze generati dal runtime e dalla registrazione personalizzata.

• Il livello di log della categoria Function è impostato su Error, quindi per tutte le funzioni per impostazione predefinita vengono raccolte solo log di errori ed eccezioni. Le dipendenze, le metriche generate dall'utente e gli eventi generati dall'utente vengono ignorati.

• Per la categoria Host.Aggregator, poiché è impostata sul livello di log Error, le informazioni aggregate dalle chiamate di funzione non vengono raccolte nella tabella customMetrics di Application Insights e le informazioni sui conteggi delle esecuzioni (totale, riuscite e non riuscite) non vengono visualizzate nel dashboard Panoramica delle funzioni.

• Per la categoria Host.Results, tutte le informazioni sull'esecuzione dell'host vengono raccolte nella tabella requests di Application Insights. Tutti i risultati delle chiamate vengono visualizzati nel dashboard Monitoraggio delle funzioni e nei dashboard di Application Insights.

• Per la funzione denominata Function1, si imposta il livello di log su Information. Per questa funzione concreta, quindi, vengono raccolti tutti i dati di telemetria (dipendenza, metriche personalizzate ed eventi personalizzati). Per la stessa funzione, si imposta categoria Function1.User (tracce generate dall'utente) su Error, per cui viene raccolta solo la registrazione degli errori personalizzata.

  Nota

  La configurazione per funzione non è supportata nella versione 1.x del runtime di Funzioni.

• Il campionamento è configurato per inviare una sola voce di telemetria al secondo per tipo, tranne le eccezioni. Questo campionamento viene eseguito per ogni host del server che esegue l'app per le funzioni. Pertanto, se esistono quattro istanze, questa configurazione emette quattro voci di telemetria al secondo per tipo e tutte le eccezioni che potrebbero verificarsi.

  Nota

  I conteggi di metrica, ad esempio la frequenza delle richieste e delle eccezioni, vengono adattati per compensare la frequenza di campionamento, in modo che mostrino i valori corretti in Esplora metriche.

Suggerimento

Sperimentare configurazioni diverse per accertarsi di soddisfare i requisiti per la registrazione, il monitoraggio e gli avvisi. Accertarsi, inoltre, che la diagnostica sia dettagliata in caso di errori imprevisti o malfunzionamenti.

Override della configurazione di monitoraggio durante il runtime

Potrebbero esistere, infine, situazioni in cui è necessario modificare rapidamente il comportamento della registrazione di una determinata categoria in produzione e non si desidera creare un'intera distribuzione solo per una modifica nel file host.json. In questi casi, è possibile eseguire l'override dei valori di host.json.

Per configurare questi valori a livello di impostazioni dell'app (ed evitare la ridistribuzione solo a causa delle modifiche di host.json), è possibile eseguire l'override di valori di host.json specifici creando un valore equivalente come impostazione dell'applicazione. Quando il runtime trova un'impostazione dell'applicazione nel formato AzureFunctionsJobHost__path__to__setting, esegue l'override dell'impostazione host.json equivalente che si trova in path.to.setting in JSON. Se espresso come impostazione dell'applicazione, un doppio carattere di sottolineatura (__) sostituisce il punto (.) usato per indicare la gerarchia JSON. Ad esempio, è possibile usare le impostazioni dell'app seguenti per configurare singoli livelli di log delle funzioni in host.json.

Percorso di host.json	Impostazione app
logging.logLevel.default	AzureFunctionsJobHost__logging__logLevel__default
logging.logLevel.Host.Aggregator	AzureFunctionsJobHost__logging__logLevel__Host.Aggregator
logging.logLevel.Function	AzureFunctionsJobHost__logging__logLevel__Function
logging.logLevel.Function.Function1	AzureFunctionsJobHost__logging__logLevel__Function.Function1
logging.logLevel.Function.Function1.User	AzureFunctionsJobHost__logging__logLevel__Function.Function1.User

È possibile eseguire l'override delle impostazioni direttamente nel riquadro Configurazione app per le funzioni del portale di Azure oppure usando un'interfaccia della riga di comando di Azure o uno script PowerShell.

Interfaccia della riga di comando di Azure

az functionapp config appsettings set --name MyFunctionApp --resource-group MyResourceGroup --settings "AzureFunctionsJobHost__logging__logLevel__Host.Aggregator=Information"

PowerShell

Update-AzFunctionAppSetting -Name MyAppName -ResourceGroupName MyResourceGroupName -AppSetting @{"AzureFunctionsJobHost__logging__logLevel__Host.Aggregator" = "Information"}

Nota

L'override di host.json tramite la modifica delle impostazioni dell'app riavvierà l'app per le funzioni. Le impostazioni dell'app contenenti un punto non sono supportate durante l'esecuzione in Linux in un piano Elastic Premium o in un piano Dedicato (servizio app). In questi ambienti di hosting è consigliabile continuare a usare il file host.json.

Monitorare app per le funzioni usando Controllo integrità

È possibile usare la funzionalità Controllo integrità per monitorare le app per le funzioni nei piani Premium (Elastic Premium) e Dedicato (servizio app). Controllo integrità non è un'opzione per il piano A consumo. Per informazioni su come configurarlo, vedere Monitorare istanze del servizio app usando Controllo integrità. L'app per le funzioni deve avere una funzione trigger HTTP che risponde con un codice di stato HTTP 200 nello stesso endpoint configurato nel parametro Path di Controllo integrità. È anche possibile fare in modo che tale funzione esegua controlli aggiuntivi per garantire che i servizi dipendenti siano raggiungibili e funzionanti.

Contenuto correlato

Per ulteriori informazioni sul monitoraggio, vedere:

• Monitorare Funzioni di Azure
• Analizzare dati di telemetria di Funzioni di Azure in Application Insights
• Panoramica di Application Insights