Så här konfigurerar du övervakning för Azure Functions

Artikel
08/06/2024

Azure Functions integreras med Application Insights så att du kan övervaka dina funktionsappar bättre. Application Insights, en funktion i Azure Monitor, är en utökningsbar tjänst för programprestandahantering (APM) som samlar in data som genereras av funktionsappen, inklusive information som din app skriver till loggar. Application Insights-integrering aktiveras vanligtvis när din funktionsapp skapas. Om din app inte har instrumentationsnyckeln inställd måste du först aktivera Application Insights-integrering.

Du kan använda Application Insights utan någon anpassad konfiguration. Standardkonfigurationen kan dock resultera i stora mängder data. Om du använder en Visual Studio Azure-prenumeration kan du nå datataket för Application Insights. Information om Application Insights-kostnader finns i Application Insights-fakturering. Mer information finns i Lösningar med stora mängder telemetri.

I den här artikeln får du lära dig hur du konfigurerar och anpassar de data som dina funktioner skickar till Application Insights. Du kan ange vanliga loggningskonfigurationer i filen host.json . Som standard styr de här inställningarna även anpassade loggar som genereras av din kod. Men i vissa fall kan det här beteendet inaktiveras till förmån för alternativ som ger dig mer kontroll över loggning. Mer information finns i Anpassade programloggar.

Kommentar

Du kan använda särskilt konfigurerade programinställningar för att representera specifika inställningar i en host.json fil för en viss miljö. På så sätt kan du effektivt ändra host.json inställningar utan att behöva publicera om host.json filen i projektet. Mer information finns i Åsidosätta värden för host.json.

Anpassade programloggar

Som standard skickas anpassade programloggar som du skriver till Functions-värden, som sedan skickar dem till Application Insights under kategorin Worker. Med vissa språkstackar kan du i stället skicka loggarna direkt till Application Insights, vilket ger dig fullständig kontroll över hur loggar som du skriver genereras. I det här fallet ändras loggningspipelinen från worker -> Functions host -> Application Insights till worker -> Application Insights.

I följande tabell sammanfattas de konfigurationsalternativ som är tillgängliga för varje stack:

Språkstacken	Var du kan konfigurera anpassade loggar
.NET (processmodell)	`host.json`
.NET (isolerad modell)	Standard (skicka anpassade loggar till Functions-värden): `host.json` Information om hur du skickar loggar direkt till Application Insights finns i: Konfigurera Application Insights i HostBuilder
Node.JS	`host.json`
Python	`host.json`
Java	Standard (skicka anpassade loggar till Functions-värden): `host.json` Information om hur du skickar loggar direkt till Application Insights finns i: Konfigurera Application Insights Java-agenten
PowerShell	`host.json`

När du konfigurerar att anpassade programloggar ska skickas direkt genererar värden dem inte längre och host.json styr inte längre deras beteende. På samma sätt gäller de alternativ som exponeras av varje stack endast för anpassade loggar, och de ändrar inte beteendet för de andra körningsloggarna som beskrivs i den här artikeln. I det här fallet kan du behöva göra ändringar i båda konfigurationerna för att kontrollera beteendet för alla loggar.

Konfigurera kategorier

Azure Functions-loggaren innehåller en kategori för varje logg. Kategorin anger vilken del av körningskoden eller funktionskoden som skrev loggen. Kategorierna skiljer sig mellan version 1.x och senare versioner.

Kategorinamn tilldelas på olika sätt i Functions jämfört med andra .NET-ramverk. När du till exempel använder ILogger<T> i ASP.NET är kategorin namnet på den generiska typen. C#-funktioner använder ILogger<T>också , men i stället för att ange det generiska typnamnet som en kategori tilldelar körningen kategorier baserat på källan. Till exempel:

Poster som är relaterade till att köra en funktion tilldelas en kategori av Function.<FUNCTION_NAME>.
Poster som skapas av användarkod i funktionen, till exempel när du anropar logger.LogInformation(), tilldelas en kategori av Function.<FUNCTION_NAME>.User.

I följande tabell beskrivs de huvudsakliga kategorier av loggar som körningen skapar:

v2.x+
v1.x

Kategori	Register	beskrivning
`Function`	Spår	Innehåller funktionsstartade och slutförda loggar för alla funktionskörningar. För lyckade körningar är dessa loggar på nivån `Information` . Undantag loggas på nivån `Error` . Körningen skapar `Warning` även nivåloggar, till exempel när kömeddelanden skickas till giftkön.
`Function.<YOUR_FUNCTION_NAME>`	Beroenden	Beroendedata samlas automatiskt in för vissa tjänster. För lyckade körningar är dessa loggar på nivån `Information` . Mer information finns i Beroenden. Undantag loggas på nivån `Error` . Körningen skapar `Warning` även nivåloggar, till exempel när kömeddelanden skickas till giftkön.
`Function.<YOUR_FUNCTION_NAME>`	customMetrics customEvents	Med C# och JavaScript SDK:er kan du samla in anpassade mått och logga anpassade händelser. Mer information finns i Anpassade telemetridata.
`Function.<YOUR_FUNCTION_NAME>`	Spår	Innehåller funktionsstartade och slutförda loggar för specifika funktionskörningar. För lyckade körningar är dessa loggar på nivån `Information` . Undantag loggas på nivån `Error` . Körningen skapar `Warning` även nivåloggar, till exempel när kömeddelanden skickas till giftkön.
`Function.<YOUR_FUNCTION_NAME>.User`	Spår	Användargenererade loggar, som kan vara valfri loggnivå. Mer information om hur du skriver till loggar från dina funktioner finns i Skriva till loggar.
`Host.Aggregator`	customMetrics	Dessa körningsgenererade loggar ger antal och medelvärden för funktionsanrop under en konfigurerbar tidsperiod. Standardperioden är 30 sekunder eller 1 000 resultat, beroende på vilket som kommer först. Exempel är antalet körningar, lyckade körningar och varaktighet. Alla dessa loggar skrivs på `Information` nivån. Om du filtrerar på `Warning` eller högre ser du inga av dessa data.
`Host.Results`	Förfrågningar	Dessa körningsgenererade loggar indikerar att en funktion lyckades eller misslyckades. Alla dessa loggar skrivs på `Information` nivån. Om du filtrerar på `Warning` eller högre ser du inga av dessa data.
`Microsoft`	Spår	Fullständigt kvalificerad loggkategori som återspeglar en .NET-körningskomponent som anropas av värden.
`Worker`	Spår	Loggar som genereras av språkarbetsprocessen för non-.NET språk. Språkarbetsloggar kan också loggas i en `Microsoft.*` kategori, till exempel `Microsoft.Azure.WebJobs.Script.Workers.Rpc.RpcFunctionInvocationDispatcher`. Dessa loggar skrivs på `Information` nivån.

Kommentar

För .NET-klassbiblioteksfunktioner förutsätter dessa kategorier att du använder ILogger och inte ILogger<T>. Mer information finns i dokumentationen om Functions ILogger.

Kategori	Register	beskrivning
`Function`	Spår	Användargenererade loggar, som kan vara valfri loggnivå. Mer information om hur du skriver till loggar från dina funktioner finns i Skriva till loggar.
`Host.Aggregator`	customMetrics	Dessa körningsgenererade loggar ger antal och medelvärden för funktionsanrop under en konfigurerbar tidsperiod. Standardperioden är 30 sekunder eller 1 000 resultat, beroende på vilket som kommer först. Exempel är antalet körningar, lyckade körningar och varaktighet. Alla dessa loggar skrivs på `Information` nivå. Om du filtrerar på `Warning` eller högre ser du inga av dessa data.
`Host.Executor`	Spår	Innehåller funktionsstartad och funktions slutförda loggar för specifika funktionskörningar. För lyckade körningar är dessa loggar på nivån `Information` . Undantag loggas på nivån `Error` . Körningen skapar också loggar på nivån `Warning`, till exempel när kömeddelanden skickas till giftkön.
`Host.Results`	Förfrågningar	Dessa körningsgenererade loggar indikerar att en funktion lyckades eller misslyckades. Alla dessa loggar skrivs på `Information` nivån. Om du filtrerar på `Warning` eller högre ser du inga av dessa data.

Kolumnen Tabell anger till vilken tabell i Application Insights loggen är skriven.

Konfigurera loggnivåer

En loggnivå tilldelas till varje logg. Värdet är ett heltal som anger relativ betydelse:

Loggnivå	Kod	beskrivning
Spårning	0	Loggar som innehåller de mest detaljerade meddelandena. Dessa meddelanden kan innehålla känsliga programdata. Dessa meddelanden är inaktiverade som standard och bör aldrig aktiveras i en produktionsmiljö.
Felsöka	1	Loggar som används för interaktiv undersökning under utveckling. Dessa loggar bör främst innehålla information som är användbar för felsökning och har inget långsiktigt värde.
Information	2	Loggar som spårar programmets allmänna flöde. Dessa loggar bör ha ett långsiktigt värde.
Varning	3	Loggar som markerar en onormal eller oväntad händelse i programflödet, men som annars inte gör att programkörningen stoppas.
Fel	4	Loggar som markerar när det aktuella körningsflödet stoppas på grund av ett fel. Dessa fel bör indikera ett fel i den aktuella aktiviteten, inte ett programomfattande fel.
Kritiskt	5	Loggar som beskriver ett oåterkalleligt program eller en systemkrasch, eller ett oåterkalleligt fel som kräver omedelbar uppmärksamhet.
Ingen	6	Inaktiverar loggning för den angivna kategorin.

Host.json-filkonfigurationen avgör hur mycket loggning en funktionsapp skickar till Application Insights.

För varje kategori anger du den minsta loggnivå som ska skickas. Inställningarna för host.json varierar beroende på functions-körningsversionen.

Följande exempel definierar loggning baserat på följande regler:

Standardloggningsnivån är inställd på att Warning förhindra överdriven loggning för oväntade kategorier.
Host.Aggregator och Host.Results är inställda på lägre nivåer. Om du ställer in loggningsnivåer som är för höga (särskilt högre än Information) kan det leda till förlust av mått och prestandadata.
Loggning för funktionskörningar är inställt på Information. Om det behövs kan du åsidosätta den här inställningen i lokal utveckling till Debug eller Trace.

v2.x+
v1.x

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

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

Om host.json innehåller flera loggar som börjar med samma sträng matchas de mer definierade loggarna först. Tänk på följande exempel som loggar allt i körningen, förutom Host.Aggregator, på nivån Error :

v2.x+
v1.x

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

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

Du kan använda en loggnivåinställning None för för att förhindra att loggar skrivs för en kategori.

Varning

Azure Functions integreras med Application Insights genom att lagra telemetrihändelser i Application Insights-tabeller. Om du anger en kategoriloggnivå till ett annat värde än Informationförhindrar det att telemetrin flödar till dessa tabeller, och du kommer inte att kunna se relaterade data på flikarna Application Insights och Funktionsövervakare .

Till exempel för föregående exempel:

Om du anger Host.Results kategorin till Error loggnivå samlar Azure endast in telemetrihändelser för värdkörning i requests tabellen för misslyckade funktionskörningar, vilket förhindrar visning av värdkörningsinformation om lyckade körningar på flikarna Application Insights och Funktionsövervakaren .
Om du anger Function kategorin till Error loggnivå slutar den att samla in funktionstelemetridata relaterade till dependencies, customMetricsoch customEvents för alla funktioner, vilket hindrar dig från att visa någon av dessa data i Application Insights. Azure samlar endast traces in loggade på nivån Error .

I båda fallen fortsätter Azure att samla in fel och undantagsdata på flikarna Application Insights och Funktionsövervakaren . Mer information finns i Lösningar med stora mängder telemetri.

Konfigurera aggregatorn

Som nämnts i föregående avsnitt aggregerar körningen data om funktionskörningar under en viss tidsperiod. Standardperioden är 30 sekunder eller 1 000 körningar, beroende på vilket som kommer först. Du kan konfigurera den här inställningen i filen host.json . Till exempel:

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

Konfigurera sampling

Application Insights har en samplingsfunktion som kan skydda dig från att producera för mycket telemetridata vid slutförda körningar vid tider med hög belastning. När frekvensen för inkommande körningar överskrider ett angivet tröskelvärde börjar Application Insights slumpmässigt ignorera några av de inkommande körningarna. Standardinställningen för maximalt antal körningar per sekund är 20 (fem i version 1.x). Du kan konfigurera sampling i host.json. Här är ett exempel:

v2.x+
v1.x

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

Du kan undanta vissa typer av telemetri från sampling. I det här exemplet undantas data av typen Request och Exception från sampling. Det säkerställer att alla funktionskörningar (begäranden) och undantag loggas medan andra typer av telemetri fortfarande omfattas av sampling.

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

Om ditt projekt använder ett beroende av Application Insights SDK för manuell telemetrispårning kan det uppstå ett ovanligt beteende om samplingskonfigurationen skiljer sig från samplingskonfigurationen i funktionsappen. I sådana fall använder du samma samplingskonfiguration som funktionsappen. Mer information finns i Sampling i Application Insights.

Aktivera SQL-frågesamling

Application Insights samlar automatiskt in data om beroenden för HTTP-begäranden, databasanrop och för flera bindningar. Mer information finns i Beroenden. För SQL-anrop samlas alltid namnet på servern och databasen in och lagras, men SQL-frågetext samlas inte in som standard. Du kan använda dependencyTrackingOptions.enableSqlCommandTextInstrumentation för att aktivera SQL-frågetextloggning med hjälp av följande inställningar (minst) i din host.json-fil:

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

Mer information finns i Avancerad SQL-spårning för att hämta fullständig SQL-fråga.

Konfigurera skalningskontrollantloggar

Den här funktionen är i förhandsversion.

Du kan låta Skalningskontrollanten i Azure Functions generera loggar till antingen Application Insights eller Blob Storage för att bättre förstå de beslut som skalningskontrollanten fattar för din funktionsapp.

Om du vill aktivera den här funktionen lägger du till en programinställning med namnet SCALE_CONTROLLER_LOGGING_ENABLED i inställningarna för funktionsappen. Följande värde för inställningen måste vara i formatet <DESTINATION>:<VERBOSITY>. Mer information finns i följande tabell:

Property	beskrivning
`<DESTINATION>`	Målet som loggarna skickas till. Giltiga värden är `AppInsights` och `Blob`. När du använder `AppInsights`kontrollerar du att Application Insights är aktiverat i funktionsappen. När du anger målet till `Blob`skapas loggar i en blobcontainer med namnet `azure-functions-scale-controller` i standardlagringskontot som anges i programinställningen `AzureWebJobsStorage` .
`<VERBOSITY>`	Anger loggningsnivån. Värden som stöds är `None`, `Warning`och `Verbose`. När värdet är inställt `Verbose`på loggar skalningskontrollanten en orsak till varje ändring i antalet arbetare och information om utlösarna som påverkar dessa beslut. Utförliga loggar inkluderar utlösarvarningar och hashvärden som används av utlösarna före och efter att skalningskontrollanten körs.

Dricks

Tänk på att även om du låter skalningskontrollantloggning vara aktiverad påverkar det de potentiella kostnaderna för att övervaka din funktionsapp. Överväg att aktivera loggning tills du har samlat in tillräckligt med data för att förstå hur skalningskontrollanten beter sig och sedan inaktivera den.

Följande Azure CLI-kommando aktiverar till exempel utförlig loggning från skalningskontrollanten till Application Insights:

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

I det här exemplet ersätter <FUNCTION_APP_NAME> du och <RESOURCE_GROUP_NAME> med namnet på din funktionsapp respektive resursgruppens namn.

Följande Azure CLI-kommando inaktiverar loggning genom att ange verbosity till None:

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

Du kan också inaktivera loggning genom att ta bort SCALE_CONTROLLER_LOGGING_ENABLED inställningen med följande Azure CLI-kommando:

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

När skalningskontrollantloggning är aktiverad kan du nu köra frågor mot skalningskontrollantloggarna.

Aktivera Application Insights-integrering

För att en funktionsapp ska kunna skicka data till Application Insights måste den ansluta till Application Insights-resursen med endast en av dessa programinställningar:

Inställningsnamn	beskrivning
`APPLICATIONINSIGHTS_CONNECTION_STRING`	Den här inställningen rekommenderas och krävs när Application Insights-instansen körs i ett nationellt moln. Niska veze stöder andra nya funktioner.
`APPINSIGHTS_INSTRUMENTATIONKEY`	Äldre inställning, som Application Insights har föråldrat till förmån för inställningen niska veze.

När du skapar din funktionsapp i Azure-portalen från kommandoraden med hjälp av Azure Functions Core Tools eller Visual Studio Code är Application Insights-integrering aktiverad som standard. Application Insights-resursen har samma namn som din funktionsapp och skapas antingen i samma region eller i närmaste region.

Kräv Microsoft Entra-autentisering

Du kan använda inställningen APPLICATIONINSIGHTS_AUTHENTICATION_STRING för att aktivera anslutningar till Application Insights med hjälp av Microsoft Entra-autentisering. Detta skapar en konsekvent autentiseringsupplevelse för alla Application Insights-pipelines, inklusive Profiler och Snapshot Debugger, samt från Functions-värden och språkspecifika agenter.

Kommentar

Det finns inget Stöd för Entra-autentisering för lokal utveckling.

Värdet innehåller antingen Authorization=AAD för en systemtilldelad hanterad identitet eller ClientId=<YOUR_CLIENT_ID>;Authorization=AAD för en användartilldelad hanterad identitet. Den hanterade identiteten måste redan vara tillgänglig för funktionsappen, med en tilldelad roll som motsvarar Monitoring Metrics Publisher. Mer information finns i Microsoft Entra-autentisering för Application Insights.

Inställningen APPLICATIONINSIGHTS_CONNECTION_STRING krävs fortfarande.

Kommentar

När du använder APPLICATIONINSIGHTS_AUTHENTICATION_STRING för att ansluta till Application Insights med Microsoft Entra-autentisering bör du även inaktivera lokal autentisering för Application Insights. Den här konfigurationen kräver Microsoft Entra-autentisering för att telemetri ska matas in på din arbetsyta.

Ny funktionsapp i portalen

Om du vill granska Application Insights-resursen som skapas väljer du den för att expandera Application Insights-fönstret . Du kan ändra nytt resursnamn eller välja en annan plats i ett Azure-geografiskt område där du vill lagra dina data.

Skärmbild som visar hur du aktiverar Application Insights när du skapar en funktionsapp.

När du väljer Skapa skapas en Application Insights-resurs med din funktionsapp, som har uppsättningen APPLICATIONINSIGHTS_CONNECTION_STRING i programinställningarna. Allt är klart.

Lägg till i en befintlig funktionsapp

Om en Application Insights-resurs inte har skapats med din funktionsapp använder du följande steg för att skapa resursen. Du kan sedan lägga till niska veze från resursen som en programinställning i funktionsappen.

I Azure-portalen söker du efter och väljer funktionsapp och väljer sedan din funktionsapp.
Välj banderollen Application Insights är inte konfigurerad längst upp i fönstret. Om du inte ser den här banderollen kanske din app redan har Application Insights aktiverat.

Expandera Ändra resursen och skapa en Application Insights-resurs med hjälp av inställningarna som anges i följande tabell:

Inställning	Föreslaget värde	beskrivning
Nytt resursnamn	Unikt appnamn	Det är enklast att använda samma namn som din funktionsapp, som måste vara unik i din prenumeration.
Plats	Västeuropa	Använd om möjligt samma region som din funktionsapp eller den som är nära den regionen.

Skärmbild som visar hur du skapar en Application Insights-resurs.

Välj Använd.

Application Insights-resursen skapas i samma resursgrupp och prenumeration som din funktionsapp. När resursen har skapats stänger du fönstret Application Insights .
I funktionsappen expanderar du Inställningar och väljer sedan Miljövariabler. Om du ser en appinställning med namnet APPLICATIONINSIGHTS_CONNECTION_STRINGpå fliken Appinställningar aktiveras Application Insights-integrering för din funktionsapp som körs i Azure. Om den här inställningen inte finns lägger du till den med hjälp av application insights-niska veze som värde.

Kommentar

Äldre funktionsappar kan använda APPINSIGHTS_INSTRUMENTATIONKEY i stället för APPLICATIONINSIGHTS_CONNECTION_STRING. När det är möjligt uppdaterar du appen så att den använder niska veze i stället för instrumentationsnyckeln.

Inaktivera inbyggd loggning

Tidiga versioner av Functions använde inbyggd övervakning, vilket inte längre rekommenderas. När du aktiverar Application Insights inaktiverar du den inbyggda loggning som använder Azure Storage. Den inbyggda loggningen är användbar för testning med lätta arbetsbelastningar, men är inte avsedd för produktion med hög belastning. För produktionsövervakning rekommenderar vi Application Insights. Om du använder inbyggd loggning i produktion kan loggningsposten vara ofullständig på grund av begränsning i Azure Storage.

Om du vill inaktivera inbyggd loggning tar du bort appinställningen AzureWebJobsDashboard . Mer information om hur du tar bort appinställningar i Azure-portalen finns i avsnittet Programinställningar i Hantera en funktionsapp. Innan du tar bort appinställningen kontrollerar du att inga befintliga funktioner i samma funktionsapp använder inställningen för Azure Storage-utlösare eller bindningar.

Lösningar med hög mängd telemetri

Funktionsappar är en viktig del av lösningar som kan orsaka stora mängder telemetri, till exempel IoT-lösningar, snabba händelsedrivna lösningar, finansiella system med hög belastning och integrationssystem. I det här fallet bör du överväga extra konfiguration för att minska kostnaderna samtidigt som du behåller observerbarheten.

Den genererade telemetrin kan användas i realtidsinstrumentpaneler, aviseringar, detaljerad diagnostik och så vidare. Beroende på hur den genererade telemetrin används måste du definiera en strategi för att minska mängden data som genereras. Med den här strategin kan du övervaka, använda och diagnostisera dina funktionsappar i produktion korrekt. Överväg följande alternativ:

Använd sampling: Som tidigare nämnts bidrar samplingen till att avsevärt minska mängden telemetrihändelser som matas in samtidigt som en statistiskt korrekt analys upprätthålls. Det kan hända att även om du använder sampling får du fortfarande en stor mängd telemetri. Granska de alternativ som anpassningsbar sampling ger dig. Ange maxTelemetryItemsPerSecond till exempel till ett värde som balanserar volymen som genereras med dina övervakningsbehov. Tänk på att telemetrisampling tillämpas per värd som kör funktionsappen.
Standardloggnivå: Använd Warning eller Error som standardvärde för alla telemetrikategorier. Senare kan du bestämma vilka kategorier du vill ange på Information nivån, så att du kan övervaka och diagnostisera dina funktioner korrekt.
Justera dina funktioners telemetri: Med standardloggnivån inställd på Error eller Warningsamlas ingen detaljerad information från varje funktion in (beroenden, anpassade mått, anpassade händelser och spårningar). För de funktioner som är viktiga för produktionsövervakning definierar du en explicit post för kategorin och anger den Function.<YOUR_FUNCTION_NAME> till Information, så att du kan samla in detaljerad information. Om du vill undvika att samla in användargenererade loggar på Information nivån anger du Function.<YOUR_FUNCTION_NAME>.User kategorin till Error loggnivån eller Warning .
Kategorin Host.Aggregator: Som beskrivs i konfigurera kategorier innehåller den här kategorin aggregerad information om funktionsanrop. Informationen från den här kategorin samlas in i tabellen Application Insights customMetrics och visas på fliken Funktionsöversikt i Azure-portalen. Beroende på hur du konfigurerar aggregatorn bör du tänka på att det kan uppstå en fördröjning, som bestäms av flushTimeout inställningen, i den insamlade telemetrin. Om du anger den här kategorin till ett annat värde än Informationslutar du att samla in data i customMetrics tabellen och visar inte mått på fliken Funktionsöversikt.

Följande skärmbild visar Host.Aggregator telemetridata som visas på fliken Funktionsöversikt:

Följande skärmbild visar Host.Aggregator telemetridata i tabellen Application Insights customMetrics :
Kategorin Host.Results: Enligt beskrivningen i konfigurera kategorier tillhandahåller den här kategorin de körningsgenererade loggar som anger att en funktionsanrop lyckades eller misslyckades. Informationen från den här kategorin samlas in i tabellen Application Insights requests och visas på fliken Övervaka funktion och på olika Application Insights-instrumentpaneler (prestanda, fel och så vidare). Om du anger den här kategorin till ett annat värde än Informationsamlar du bara in telemetri som genererats på den definierade loggnivån (eller högre). Om du till exempel ställer in den på resulterar det i att error endast data spåras för misslyckade körningar.

Följande skärmbild visar Host.Results telemetridata som visas på fliken Övervaka funktion:

Följande skärmbild visar Host.Results telemetridata som visas på instrumentpanelen för Application Insights-prestanda:
Host.Aggregator jämfört med Host.Results: Båda kategorierna ger bra insikter om funktionskörningar. Om det behövs kan du ta bort detaljerad information från någon av dessa kategorier, så att du kan använda den andra för övervakning och aviseringar. Här är ett exempel:

v2.x+
v1.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"
      }
    }
  }
}

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

Med den här konfigurationen:

Standardvärdet för alla funktioner och telemetrikategorier är inställt på Warning (inklusive Microsoft- och Worker-kategorier). Som standard samlas därför alla fel och varningar som genereras av körning och anpassad loggning in.
Kategoriloggnivån Function är inställd på Error, så för alla funktioner samlas som standard endast undantag och felloggar in. Beroenden, användargenererade mått och användargenererade händelser hoppas över.
Host.Aggregator För kategorin, eftersom den är inställd Error på loggnivån, samlas inte aggregerad information från funktionsanrop in i customMetrics tabellen Application Insights, och information om antal körningar (totalt, lyckat och misslyckat) visas inte på instrumentpanelen för funktionsöversikten.
För kategorin Host.Results samlas all information om värdkörningen in i requests tabellen Application Insights. Alla anropsresultat visas i funktionen Övervaka instrumentpanel och i Application Insights-instrumentpaneler.
För funktionen med namnet Function1anger vi loggnivån till Information. För den här konkreta funktionen samlas därför all telemetri in (beroende, anpassade mått och anpassade händelser). För samma funktion anger Function1.User vi kategorin (användargenererade spårningar) till Error, så att endast anpassad felloggning samlas in.

Kommentar

Konfiguration per funktion stöds inte i v1.x av Functions-körningen.
Sampling har konfigurerats för att skicka ett telemetriobjekt per sekund per typ, exklusive undantagen. Den här samplingen sker för varje servervärd som kör vår funktionsapp. Så om vi har fyra instanser genererar den här konfigurationen fyra telemetriobjekt per sekund per typ och alla undantag som kan inträffa.

Kommentar

Måttantal som begärandefrekvens och undantagsfrekvens justeras för att kompensera för samplingsfrekvensen, så att de visar ungefär korrekta värden i Metric Explorer.

Dricks

Experimentera med olika konfigurationer för att säkerställa att du täcker dina krav för loggning, övervakning och aviseringar. Se också till att du har detaljerad diagnostik vid oväntade fel eller fel.

Åsidosättande övervakningskonfiguration vid körning

Slutligen kan det finnas situationer där du snabbt behöver ändra loggningsbeteendet för en viss kategori i produktion, och du inte vill göra en hel distribution bara för en ändring i host.json-filen. I sådana fall kan du åsidosätta host.json värden.

Om du vill konfigurera dessa värden på appinställningsnivå (och undvika omdistribution på bara host.json ändringar) bör du åsidosätta specifika host.json värden genom att skapa ett motsvarande värde som en programinställning. När körningen hittar en programinställning i formatet AzureFunctionsJobHost__path__to__settingåsidosätter den motsvarande host.json inställning som finns path.to.setting i JSON. När det uttrycks som en programinställning ersätter ett dubbelt understreck (__) punkten (.) som används för att ange JSON-hierarki. Du kan till exempel använda följande appinställningar för att konfigurera enskilda funktionsloggnivåer i host.json.

Host.json sökväg	Appinställning
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

Du kan åsidosätta inställningarna direkt i fönstret Funktionsappkonfiguration i Azure-portalen eller med hjälp av ett Azure CLI- eller PowerShell-skript.

Azure CLI
PowerShell

az functionapp config appsettings set --name MyFunctionApp --resource-group MyResourceGroup --settings "AzureFunctionsJobHost__logging__logLevel__Host__Aggregator=Information"

Update-AzFunctionAppSetting -Name MyAppName -ResourceGroupName MyResourceGroupName -AppSetting @{"AzureFunctionsJobHost__logging__logLevel__Host__Aggregator" = "Information"}

Kommentar

Om du överskrider inställningarna för att ändra app startas funktionsappen host.json om. Appinställningar som innehåller en period stöds inte när de körs på Linux i en Elastic Premium-plan eller en dedikerad (App Service)-plan. I dessa värdmiljöer bör du fortsätta att använda filen host.json .

Övervaka funktionsappar med hälsokontroll

Du kan använda funktionen Hälsokontroll för att övervaka funktionsappar i Premium-abonnemangen (Elastic Premium) och Dedikerad (App Service). Hälsokontroll är inte ett alternativ för förbrukningsplanen. Information om hur du konfigurerar det finns i Övervaka App Service-instanser med hälsokontroll. Din funktionsapp bör ha en HTTP-utlösarfunktion som svarar med en HTTP-statuskod på 200 på samma slutpunkt som konfigurerad för parametern Path för hälsokontrollen. Du kan också låta funktionen utföra extra kontroller för att säkerställa att beroende tjänster kan nås och fungera.

Mer information om övervakning finns i:

Dela via

Så här konfigurerar du övervakning för Azure Functions

Anpassade programloggar

Konfigurera kategorier

Konfigurera loggnivåer

Konfigurera aggregatorn

Konfigurera sampling

Aktivera SQL-frågesamling

Konfigurera skalningskontrollantloggar

Aktivera Application Insights-integrering

Kräv Microsoft Entra-autentisering

Ny funktionsapp i portalen

Lägg till i en befintlig funktionsapp

Inaktivera inbyggd loggning

Lösningar med hög mängd telemetri

Åsidosättande övervakningskonfiguration vid körning

Övervaka funktionsappar med hälsokontroll

Feedback

Ytterligare resurser

Dela via

Så här konfigurerar du övervakning för Azure Functions

Anpassade programloggar

Konfigurera kategorier

Konfigurera loggnivåer

Konfigurera aggregatorn

Konfigurera sampling

Aktivera SQL-frågesamling

Konfigurera skalningskontrollantloggar

Aktivera Application Insights-integrering

Kräv Microsoft Entra-autentisering

Ny funktionsapp i portalen

Lägg till i en befintlig funktionsapp

Inaktivera inbyggd loggning

Lösningar med hög mängd telemetri

Åsidosättande övervakningskonfiguration vid körning

Övervaka funktionsappar med hälsokontroll

Relaterat innehåll

Feedback

Ytterligare resurser