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 non ha impostato la chiave di strumentazione, è prima necessario abilitare l'integrazione di Application Insights.

È possibile usare Application Insights senza alcuna operazione di configurazione personalizzata, poiché la configurazione predefinita 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 sui costi di Application Insights, vedere Fatturazione di Application Insights. Per altre informazioni, vedere Soluzioni con volumi elevati di dati di telemetria.

Nelle sezioni successive di questo articolo viene illustrato come configurare e personalizzare i dati inviati dalle funzioni ad Application Insights. La configurazione di registrazione comune può essere impostata nel file host.json. Per impostazione predefinita, queste impostazioni regolano anche i log personalizzati generati dal codice, anche se in alcuni casi questo comportamento può essere disabilitato a favore delle opzioni che offrono un maggiore controllo sulla registrazione. Per altre informazioni, vedere Log applicazioni personalizzati.

Nota

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

Log applicazioni personalizzati

Per impostazione predefinita, i log applicazioni personalizzati scritti vengono inviati all'host funzioni, che li invia quindi ad Application Insights tramite la categoria "Worker". Alcuni stack di linguaggio consentono invece di inviare i log direttamente ad Application Insights, offrendo il controllo completo sul modo in cui vengono generati i log scritti. La pipeline di registrazione passa da worker -> Functions host -> Application Insights a worker -> Application Insights.

La tabella seguente riepiloga le opzioni disponibili per ogni stack:

Stack di linguaggio	Configurazione dei log personalizzati
.NET (modello in-process)	host.json
.NET (modello isolato)	Per impostazione predefinita: host.json Opzione per inviare i log direttamente: Configurare Application Insights in HostBuilder
Node.JS	host.json
Python	host.json
Java	Per impostazione predefinita: host.json Opzione per inviare i log direttamente: configurare l'agente Java di Application Insights
PowerShell	host.json

Quando i log dell'applicazione personalizzati vengono inviati 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. Per controllare il comportamento di tutti i log, potrebbe essere necessario apportare modifiche per 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 di categoria vengono assegnati in modo diverso in Funzioni 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 ILogger<T>anche , ma anziché impostare il nome del 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.

Il grafico seguente descrive le categorie principali di log creati dal runtime:

v2.x+

Category	Table	Descrizione
Function	traces	Include i log di funzione avviati e completati per tutte le esecuzioni di funzioni. Per le esecuzioni riuscite, questi log sono a Information livello. Le eccezioni vengono registrate a Error livello di . Il runtime crea Warning anche log a livello, ad esempio quando i messaggi della coda vengono inviati alla coda non elaborabili.
Function.<YOUR_FUNCTION_NAME>	dependencies	I dati di dipendenza vengono raccolti automaticamente per alcuni servizi. Per le esecuzioni riuscite, questi log sono a Information livello. Per altre informazioni, vedere Dipendenze. Le eccezioni vengono registrate a Error livello di . Il runtime crea Warning anche log a livello, ad esempio quando i messaggi della coda vengono inviati alla coda non elaborabili.
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 esecuzioni di funzioni specifiche. Per le esecuzioni riuscite, questi log sono a Information livello. Le eccezioni vengono registrate a Error livello di . Il runtime crea Warning anche log a livello, ad esempio quando i messaggi della coda vengono inviati alla coda non elaborabili.
Function.<YOUR_FUNCTION_NAME>.User	traces	Log generati dall'utente, che possono essere di qualsiasi 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 conteggi e medie delle chiamate di 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 categoria successiva, non verrà visualizzato alcun dato.
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 categoria successiva, non verrà visualizzato alcun dato.
Microsoft	traces	Categoria di log completa che riflette un componente di runtime .NET richiamato dall'host.
Worker	traces	Log generati dal processo di lavoro linguistico per non-.NET lingue. I log del ruolo di lavoro per la lingua possono anche essere registrati in una Microsoft.* categoria, ad esempio Microsoft.Azure.WebJobs.Script.Workers.Rpc.RpcFunctionInvocationDispatcher. Questi log vengono scritti a Information livello.

Nota

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

v1.x

Category	Table	Descrizione
Function	traces	Log generati dall'utente, che possono essere di qualsiasi 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 conteggi e medie delle chiamate di 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 categoria successiva, non verrà visualizzato alcun dato.
Host.Executor	traces	Include i log di funzioni avviati e di funzione completati per esecuzioni di funzioni specifiche. Per le esecuzioni con esito positivo, questi log si trovano al livello Information. Le eccezioni vengono registrate al livello Error. Il runtime crea Warning anche log a livello, ad esempio quando i messaggi della coda vengono inviati alla coda non elaborabili.
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 categoria successiva, non verrà visualizzato alcun dato.

La colonna Table indica a quale tabella in Application Insights viene scritto il log.

Configurare i livelli di log

A ogni log viene 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 altrimenti 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 la quantità di registrazione inviata da un'app per le funzioni ad Application Insights.

Per ogni categoria, si indica il livello di registrazione minimo da inviare. Le impostazioni 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 impreviste.
• Host.Aggregator e Host.Results sono impostati su livelli inferiori. L'impostazione di questi elementi su un livello troppo elevato (soprattutto superiore Informationa ) può comportare la perdita di metriche e dati sulle prestazioni.
• La registrazione per le esecuzioni di funzioni è impostata su Information. Questo può essere sottoposto a override nello sviluppo locale in Debug o Trace, quando necessario.

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, i log più definiti vengono confrontati per primi. Si consideri l'esempio seguente che registra tutti gli elementi nel runtime, ad eccezione Host.Aggregatordi , a Error livello di :

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 a livello di log di None per impedire la scrittura di log per una categoria.

Attenzione

Funzioni di Azure si integra con Application Insights archiviando gli eventi di telemetria nelle tabelle di Application Insights. L'impostazione di un livello di log di categoria su qualsiasi valore diverso da Information impedirà il flusso dei dati di telemetria a tali tabelle. Come risultato, non sarà possibile visualizzare i dati correlati nella scheda Application Insights o Monitoraggio funzioni .

Da esempi precedenti:

• Se la Host.Results categoria è impostata sul Error livello di log, raccoglierà solo gli eventi di telemetria dell'esecuzione dell'host nella requests tabella per le esecuzioni di funzioni non riuscite, impedendo di visualizzare i dettagli dell'esecuzione host delle esecuzioni riuscite nella scheda Application Insights e Monitoraggio funzioni .
• Se la categoria è impostata sul Error livello di log, interromperà la Function raccolta dei dati di telemetria delle funzioni correlati a dependencies, customMetricse customEvents per tutte le funzioni, impedendo di visualizzare uno qualsiasi di questi dati in Application Insights. Verrà raccolto traces solo con Error il livello.

In entrambi i casi si continuerà a raccogliere gli errori e i dati delle eccezioni nella scheda Application Insights e Monitoraggio funzioni. Per altre informazioni, vedere Soluzioni con volumi elevati 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. Ecco un 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"
      }
    }
  }
}

È possibile escludere determinati tipi di dati di telemetria dal campionamento. In questo esempio i dati di tipo Request e Exception vengono esclusi dal campionamento. Garantisce che tutte le esecuzioni di funzione (richieste) e le eccezioni vengano registrate mentre altri tipi di dati di telemetria rimangono soggetti al campionamento.

v1.x

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

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

Abilitare la raccolta di query SQL

Application Insights raccoglie automaticamente i dati sulle dipendenze per richieste HTTP, chiamate di database e per diverse associazioni. Per altre informazioni, vedere Dipendenze. Per le chiamate SQL, il nome del server e del database viene sempre raccolto e archiviato, 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 impostando (almeno) quanto segue nel file host.json:

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

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

Configurare i log del controller di scalabilità

Questa funzionalità è in anteprima.

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

Per abilitare questa funzionalità, è possibile 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>:

Proprietà	Descrizione
<DESTINATION>	Destinazione a cui vengono 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 informazioni sui trigger che determinano tali decisioni. I log dettagliati includono avvisi di trigger e 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à, influisce sui potenziali costi del monitoraggio dell'app per le funzioni. Valutare la possibilità di abilitare la registrazione fino a quando non sono stati raccolti dati sufficienti per comprendere il comportamento del controller di scalabilità e quindi disabilitarlo.

Ad esempio, il comando seguente dell'interfaccia della riga di comando di Azure attiva la registrazione dettagliata dal controller di scalabilità ad 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> con rispettivamente il nome dell'app per le funzioni e il nome del gruppo di risorse.

Il comando dell'interfaccia della riga di comando di Azure seguente disabilita la registrazione impostando il livello di 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 usando il comando dell'interfaccia della SCALE_CONTROLLER_LOGGING_ENABLED riga di comando di Azure seguente:

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 sui log del controller di scalabilità.

Abilitare l'integrazione di Application Insights

Affinché un'app per le funzioni invii dati ad Application Insights, deve connettersi alla risorsa di Application Insights usando solo una di queste impostazioni dell'applicazione:

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

Quando si crea l'app per le funzioni nella portale di Azure dalla riga di comando usando Funzioni di Azure Core Tools o Visual Studio Code, l'integrazione di Application Insights è abilitata per impostazione predefinita. La risorsa di Application Insights prende lo stesso nome dell'app per le funzioni e viene creata nella stessa area o nell'area più vicina.

Nuova app per le funzioni nel portale

Per verificare la risorsa di Application Insights appena creata, selezionarla per espandere la finestra Application Insights. È possibile modificare il nome della nuova risorsa o selezionare un percorso diverso in un'area geografica di Azure in cui archiviare i dati.

Quando si seleziona Crea, viene creata una risorsa di Application Insights con l'app per le funzioni, che include il APPLICATIONINSIGHTS_CONNECTION_STRING set 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, seguire questa procedura per creare la risorsa. È quindi possibile aggiungere il stringa di connessione da tale risorsa come impostazione dell'applicazione nell'app per le funzioni.

1. Nella portale di Azure cercare e selezionare app per le funzioni e 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 quella 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 selezionare Configurazione in Impostazioni e quindi Impostazioni applicazione. 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 per qualche motivo questa impostazione non esiste, aggiungerla usando application insights stringa di connessione come valore.

Nota

Le app per le funzioni precedenti potrebbero usare APPINSIGHTS_INSTRUMENTATIONKEY anziché APPLICATIONINSIGHTS_CONNECTION_STRING. Quando possibile, è consigliabile aggiornare l'app in modo da usare il 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 la registrazione predefinita viene usata in ambienti di produzione, è possibile che il record di registrazione non sia completo a causa delle limitazioni a livello di Archiviazione di Azure.

Per disabilitare la registrazione predefinita, eliminare l'impostazione app AzureWebJobsDashboard. Per altre informazioni su come eliminare le impostazioni dell'app nella portale di Azure, vedere la sezione Impostazioni applicazione di Come gestire un'app per le funzioni. Prima di eliminare l'impostazione dell'app, assicurarsi che nessuna funzione esistente nella stessa app per le funzioni usi l'impostazione per Archiviazione di Azure trigger o associazioni.

Soluzioni con un volume elevato di dati di telemetria

Le app per le funzioni sono una parte essenziale delle soluzioni che possono causare volumi elevati di dati di telemetria, ad esempio soluzioni IoT, soluzioni rapide basate su eventi, sistemi finanziari a carico elevato e sistemi di integrazione. In questo caso, è consigliabile prendere in considerazione una configurazione aggiuntiva per ridurre i costi mantenendo al contempo 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 consentirà di monitorare, gestire e diagnosticare correttamente le app per le funzioni nell'ambiente di produzione. È possibile considerare le opzioni seguenti:

• Usare il campionamento: come accennato in precedenza, consente di ridurre drasticamente il volume di eventi di telemetria inseriti mantenendo un'analisi statisticamente corretta. Potrebbe accadere che anche usando il campionamento si ottiene ancora un volume elevato di dati di telemetria. Esaminare le opzioni fornite dal campionamento adattivo. Ad esempio, impostare su maxTelemetryItemsPerSecond 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 log predefinito: usare Warning o Error come valore predefinito per tutte le categorie di telemetria. A questo punto, è possibile decidere quali categorie impostare a Information livello 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 verranno raccolte informazioni dettagliate da ogni funzione (dipendenze, metriche personalizzate, eventi personalizzati e tracce). Per le funzioni chiave per il monitoraggio di produzione, definire una voce esplicita per Function.<YOUR_FUNCTION_NAME> la categoria e impostarla su Information, in modo da poter raccogliere informazioni dettagliate. A questo punto, per evitare di raccogliere log generati dall'utente a Information livello, impostare la Function.<YOUR_FUNCTION_NAME>.User categoria su o Warning a Error livello di log.

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

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

  

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

  

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

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

  

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

  

• Host.Aggregator e Host.Results: entrambe le categorie forniscono informazioni dettagliate dettagliate sulle esecuzioni delle funzioni. Se necessario, è possibile rimuovere le informazioni dettagliate da una di queste categorie, in modo da poter usare l'altro per il monitoraggio e l'invio di 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, si avranno:

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

• Il Function livello di log delle categorie è impostato su Error, quindi per tutte le funzioni, per impostazione predefinita, verranno raccolte solo le eccezioni e i log degli errori (dipendenze, metriche generate dall'utente e eventi generati dall'utente verranno ignorati).

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

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

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

  Nota

  La configurazione per funzione non è supportata in v1.x.

• Il campionamento è configurato per inviare un elemento di telemetria al secondo per tipo, escluse le eccezioni. Questo campionamento verrà eseguito per ogni host server che esegue l'app per le funzioni. Pertanto, se sono presenti quattro istanze, questa configurazione genererà quattro elementi 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 assicurarsi di soddisfare i requisiti per la registrazione, il monitoraggio e l'invio di avvisi. Assicurarsi inoltre di avere una diagnostica dettagliata in caso di errori imprevisti o malfunzionamenti.

Override della configurazione di monitoraggio in fase di esecuzione

Infine, potrebbero esserci situazioni in cui è necessario modificare rapidamente il comportamento di registrazione di una determinata categoria nell'ambiente di produzione e non si vuole eseguire un'intera distribuzione solo per una modifica nel file host.json . Per questi casi, è possibile eseguire l'override dei valori host.json.

Per configurare questi valori a livello di impostazioni dell'app (ed evitare la ridistribuzione solo in modifiche host.json ), è necessario eseguire l'override di valori specifici host.json 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 equivalente host.json che si trova path.to.setting in nel codice JSON. Se espresso come impostazione dell'applicazione, il punto (.) usato per indicare la gerarchia JSON viene sostituito da un doppio carattere di sottolineatura (__). Ad esempio, è possibile usare le impostazioni dell'app seguenti per configurare i singoli livelli di log delle funzioni come in host.json precedenza.

Percorso 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 pannello Configurazione app funzione portale di Azure oppure usando un'interfaccia della riga di comando di Azure o uno script di PowerShell.

az cli

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 host.json di tramite la modifica delle impostazioni dell'app riavvierà l'app per le funzioni. Le impostazioni dell'app che contengono un periodo 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 è necessario continuare a usare il file host.json .

Monitorare le app per le funzioni usando Controllo integrità

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

Passaggi successivi

Per altre informazioni sul monitoraggio, vedere:

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