Come configurare il monitoraggio per Funzioni di Azure

  • Articolo

Funzioni di Azure si integra con Application Insights per consentire di monitorare meglio le app per le funzioni. Application Insights, una funzionalità di Monitoraggio di Azure, è un servizio APM (Extensible Application Performance Management) che raccoglie i dati generati dall'app per le funzioni, incluse le informazioni che l'app scrive nei log. L'integrazione di Application Insights è in genere abilitata quando viene creata l'app per le funzioni. Se l'app non dispone del set di chiavi 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 volume elevato di dati di telemetria.

Nelle sezioni successive di questo articolo viene illustrato come configurare e personalizzare i dati inviati dalle funzioni ad Application Insights. Per un'app per le funzioni, la registrazione è configurata nel file host.json .

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 host.json.

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 differiscono tra la versione 1.x e le versioni successive. Il grafico seguente descrive le categorie principali di log create dal runtime:

Category Tabella Descrizione
Function.<YOUR_FUNCTION_NAME> Dipendenze 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. Il runtime crea Warning anche log a livello, ad esempio quando i messaggi della coda vengono inviati alla coda non elaborata.
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 avviati e completati per le esecuzioni di funzioni specifiche. Per le esecuzioni riuscite, questi log sono a Information livello. Le eccezioni vengono registrate a Error livello. Il runtime crea Warning anche log a livello, ad esempio quando i messaggi della coda vengono inviati alla coda non elaborata.
Function.<YOUR_FUNCTION_NAME>.User traces Log generati dall'utente, che possono essere 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 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 della lingua per le lingue di non-.NET. I log del ruolo di lavoro linguistico 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.

La colonna Table indica la tabella in Application Insights scritta dal log.

Configurare i livelli di log

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

LogLevel Codice Descrizione
Trace 0 Log che contengono i messaggi più dettagliati. Questi messaggi potrebbero contenere dati dell'applicazione sensibili. 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.
Errore 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.
nessuno 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.

L'esempio seguente definisce la registrazione in base alle regole seguenti:

  • Per i log di Host.Results o Function, registra solo gli eventi a Error un livello superiore o superiore.
  • Per i log di Host.Aggregator, registrare tutte le metriche generate (Trace).
  • Per tutti gli altri log, inclusi i log utente, registra solo Information eventi di livello e superiore.
  • Per fileLoggingMode il valore predefinito è debugOnly. Il valore always deve essere usato solo per brevi periodi di tempo per esaminare i log nel file system. Ripristinare questa impostazione al termine del debug.
{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Information",
      "Host.Results": "Error",
      "Function": "Error",
      "Host.Aggregator": "Trace"
    }
  }
}

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 :

{
  "logging": {
    "fileLoggingMode": "always",
    "logLevel": {
      "default": "Information",
      "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 delle categorie su qualsiasi valore diverso da Information impedirà il flusso dei dati di telemetria a tali tabelle. Di conseguenza, non sarà possibile visualizzare i dati correlati nella scheda Application Insights o Monitoraggio funzioni .

Dagli 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 sia nella scheda Application Insights che in 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 di questi dati in Application Insights. Raccoglierà solo traces i dati registrati 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 . 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 in host.json. Ecco un esempio:

{
  "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 funzioni (richieste) e le eccezioni vengano registrate mentre altri tipi di telemetria rimangono soggetti al campionamento.

Se il progetto assume una dipendenza da Application Insights SDK per eseguire il rilevamento manuale dei dati di telemetria, potrebbe verificarsi un comportamento anomalo 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 la query SQL completa.

Configurare i log del controller di scalabilità

Questa funzionalità è disponibile in anteprima.

È possibile fare in modo che il controller di scalabilità Funzioni di Azure emetta log ad Application Insights o all'archiviazione 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 Blobsu , 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 influiscono su 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 dell'interfaccia della riga di comando di Azure seguente 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> rispettivamente con 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 SCALE_CONTROLLER_LOGGING_ENABLED della 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, è necessario conoscere la chiave di strumentazione di una risorsa di Application Insights. La chiave deve essere specificata in un'impostazione dell'app denominata APPINSIGHTS_INSTRUMENTATIONKEY.

Quando si crea l'app per le funzioni nel 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 inun'area geografica di Azure in cui si desidera archiviare i dati.

Screenshot dell'abilitazione di Application Insights durante la creazione di un'app per le funzioni.

Quando si seleziona Crea, viene creata una risorsa di Application Insights con l'app per le funzioni, che include il APPINSIGHTS_INSTRUMENTATIONKEY 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 la chiave di strumentazione dalla risorsa come impostazione dell'applicazione nell'app per le funzioni.

  1. Nella portale di Azure cercare e selezionare l'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.

    Screenshot dell'abilitazione di Application Insights dal portale.

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

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

    Screenshot della creazione di una risorsa di Application Insights.

  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 APPINSIGHTS_INSTRUMENTATIONKEY, 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 la chiave di strumentazione di Application Insights come valore.

Nota

Nelle versioni precedenti di Funzioni veniva usato il servizio di monitoraggio incorporato, che non è più consigliato. Quando si abilita l'integrazione di Application Insights per un'app per queste funzioni, è necessario disabilitare anche la registrazione predefinita.

Disabilitare la registrazione predefinita

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 i trigger o le associazioni di Archiviazione di Azure.

Soluzioni con 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 basate su eventi rapidi, sistemi finanziari a carico elevato e sistemi di integrazione. In questo caso, è consigliabile considerare una configurazione aggiuntiva per ridurre i costi mantenendo l'osservabilità.

I dati di telemetria generati possono essere usati 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 correttamente, operare e diagnosticare le app per le funzioni nell'ambiente di produzione. È possibile considerare le opzioni seguenti:

  • Usare il campionamento: come accennato in precedenza, sarà utile ridurre notevolmente il volume di eventi di telemetria inseriti mantenendo un'analisi statisticamente corretta. Potrebbe verificarsi 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 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. È ora possibile decidere quali categorie impostare a Information livello in modo che sia possibile 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 queste funzioni chiave per il monitoraggio di produzione, definire una voce esplicita per Function.<YOUR_FUNCTION_NAME> la categoria e impostarla su Information, in modo che sia possibile raccogliere informazioni dettagliate. A questo punto, per evitare di raccogliere i log generati dall'utente a Information livello, impostare la Function.<YOUR_FUNCTION_NAME>.User categoria su Error o Warning a livello di log.

  • Categoria Host.Aggregator: come descritto in configurare le categorie, questa categoria fornisce informazioni aggregate delle chiamate alla funzione. Le informazioni di questa categoria vengono raccolte nella tabella di Application Insights customMetrics e vengono visualizzate nella scheda Panoramica della funzione nella portale di Azure. A seconda del modo in cui si configura l'aggregatore, considerare che vi sarà 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 visualizzerà le metriche nella scheda Panoramica della funzione.

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

    Screenshot della telemetria host.Aggregator visualizzata nella scheda Panoramica della funzione.

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

    Screenshot dei dati di telemetria host.Aggregator nella tabella customMetrics Application Insights.

  • Categoria Host.Results: come descritto nelle categorie di configurazione, questa categoria fornisce i log generati dal runtime che indicano l'esito positivo o negativo di una chiamata a una funzione. Le informazioni di questa categoria vengono raccolte nella tabella di Application Insights requests e vengono visualizzate nella scheda Monitoraggio 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 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 esecuzioni non riuscite.

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

    Screenshot della telemetria Host.Results nella scheda Monitoraggio funzioni.

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

    Screenshot della telemetria Host.Results nel dashboard delle prestazioni di Application Insights.

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

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

Con questa configurazione sarà disponibile:

  • Il valore predefinito per tutte le funzioni e le categorie di telemetria è impostato su Warning (incluse le categorie Microsoft e Worker). Quindi, 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 eccezioni e log degli errori (le dipendenze, le metriche generate dall'utente e gli eventi generati dall'utente verranno ignorati).

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

  • Per la categoria, tutte le informazioni sull'esecuzione Host.Results host vengono raccolte nella requests tabella 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, tutti i dati di telemetria vengono raccolti (dipendenze, metriche personalizzate e 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 al secondo, escluso le eccezioni. Questo campionamento verrà eseguito per ogni host del server che esegue l'app per le funzioni. Quindi, 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'avviso. Assicurarsi inoltre di disporre di diagnostica dettagliata in caso di errori imprevisti o malfunzionamenti.

Override della configurazione di monitoraggio in fase di esecuzione

Infine, potrebbero verificarsi situazioni in cui è necessario modificare rapidamente il comportamento di registrazione di una determinata categoria nell'ambiente di produzione e non si vuole apportare 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 nelle 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 disponibile path.to.setting in JSON. Se espresso come impostazione dell'applicazione, il punto (.) usato per indicare che la gerarchia JSON viene sostituita 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 illustrato 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 functionapp config appsettings set --name MyFunctionApp --resource-group MyResourceGroup --settings "AzureFunctionsJobHost__logging__logLevel__Host__Aggregator=Information"

Nota

L'override di tramite la host.json modifica delle impostazioni dell'app riavvierà l'app per le funzioni.

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 di integrità. È anche possibile fare in modo che la funzione esegua controlli aggiuntivi per garantire che i servizi dipendenti siano raggiungibili e funzionanti.

Passaggi successivi

Per altre informazioni sul monitoraggio, vedere: