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

Artikel
11/29/2023

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

Senare 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 en vanlig loggningskonfiguration 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 specifik miljö. På så sätt kan du ändra inställningarna för host.json utan att behöva publicera om filen host.json 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 via 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. Loggningspipelinen ändras från worker -> Functions host -> Application Insights till worker -> Application Insights.

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

Språkstacken	Konfiguration av anpassade loggar
.NET (processmodell)	`host.json`
.NET (isolerad modell)	Som standard: `host.json` Alternativ för att skicka loggar direkt: Konfigurera Application Insights i HostBuilder
Node.JS	`host.json`
Python	`host.json`
Java	Som standard: `host.json` Alternativ för att skicka loggar direkt: Konfigurera Application Insights Java-agenten
PowerShell	`host.json`

När anpassade programloggar 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 anpassade loggar, och de ändrar inte beteendet för de andra körningsloggarna som beskrivs i den här artikeln. Om du vill kontrollera beteendet för alla loggar kan du behöva göra ändringar för båda konfigurationerna.

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 diagram beskrivs de viktigaste kategorierna 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å. Om du filtrerar vid `Warning` eller över visas inga av dessa data.
`Host.Results`	Begäranden	Dessa körningsgenererade loggar indikerar att en funktion lyckades eller misslyckades. Alla dessa loggar skrivs på `Information` nivå. Om du filtrerar vid `Warning` eller över visas 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å.

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 vid `Warning` eller över visas 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 `Information` dessa loggar nivå. Undantag loggas på `Error` nivå. Körningen skapar `Warning` även nivåloggar, till exempel när kömeddelanden skickas till giftkön.
`Host.Results`	Begäranden	Dessa körningsgenererade loggar indikerar att en funktion lyckades eller misslyckades. Alla dessa loggar skrivs på `Information` nivå. Om du filtrerar vid `Warning` eller över visas 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.

Konfigurationen av filen host.json 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.

Exemplen nedan 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 dessa på en för hög nivå (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. Detta kan åsidosättas i lokal utveckling till Debug eller Trace, när det behövs.

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 Information hindrar du telemetrin från att flöda till dessa tabeller. Som resultat kommer du inte att kunna se relaterade data på fliken Application Insights eller Funktionsövervakare.

Från ovanstående exempel:

Host.Results Om kategorin är inställd på Error loggnivå samlar den bara in telemetrihändelser för värdkörning i requests tabellen för misslyckade funktionskörningar, vilket förhindrar att värdkörningsinformation om lyckade körningar visas på fliken Application Insights och Funktionsövervakaren.
Function Om kategorin är inställd på Error loggnivå slutar den att samla in funktionstelemetridata relaterade till dependencies, customMetricsoch customEvents för alla funktioner, vilket förhindrar att någon av dessa data visas i Application Insights. Den samlar endast in traces loggad med Error nivå.

I båda fallen fortsätter du att samla in fel och undantagsdata på fliken 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. Här är ett 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 är beroende av Application Insights SDK för manuell telemetrispårning kan det uppstå ett konstigt 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 genom att ange (minst) följande i filen host.json:

"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 kan du lägga 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>:

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	Det här är den rekommenderade inställningen som krävs när Application Insights-instansen körs i ett nationellt moln. anslutningssträng stöder andra nya funktioner.
APPINSIGHTS_INSTRUMENTATIONKEY	Äldre inställning, som är inaktuell av Application Insights till förmån för inställningen anslutningssträng.

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.

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.

Screenshot of enabling Application Insights while creating a function app.

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 anslutningssträng 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.

Screenshot of creating an Application Insights resource.

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 väljer du Konfiguration under Inställningar och sedan Programinställningar. Om du ser en inställning med namnet APPLICATIONINSIGHTS_CONNECTION_STRINGaktiveras Application Insights-integrering för din funktionsapp som körs i Azure. Om den här inställningen av någon anledning inte finns lägger du till den med application insights-anslutningssträng som värde.

Kommentar

Äldre funktionsappar kanske använder APPINSIGHTS_INSTRUMENTATIONKEY i stället för APPLICATIONINSIGHTS_CONNECTION_STRING. När det är möjligt bör du uppdatera appen så att den använder anslutningssträng 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 inbyggd loggning används 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 kommer att förbrukas 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. Du kan överväga följande alternativ:

Använd sampling: Som tidigare nämnts bidrar det 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. Nu kan du bestämma vilka kategorier du vill ange på Information nivå 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 Function.<YOUR_FUNCTION_NAME> kategorin och anger den till Information, så att du kan samla in detaljerad information. För att undvika att samla in användargenererade loggar på Information nivå anger du Function.<YOUR_FUNCTION_NAME>.User kategorin till Error eller Warning loggnivå.
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 kommer att uppstå en fördröjning som bestäms av flushTimeout, i den insamlade telemetrin. Om du ställer in den här kategorin på 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 i 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 genereras 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 har du:

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 endast undantag och felloggar in som standard (beroenden, användargenererade mått och användargenererade händelser hoppas över).
Host.Aggregator För kategorin, eftersom den är inställd på Error loggnivå, 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översikt.
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 Function1har vi angett 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 Function1.User är kategorin (användargenererade spårningar) inställd på Error, så endast anpassad felloggning samlas in.

Kommentar

Konfiguration per funktion stöds inte i v1.x.
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 filen host.json . I sådana fall kan du åsidosätta värden för host.json.

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 den uttrycks som en programinställning ersätts punkten (.) som används för att indikera JSON-hierarkin med ett dubbelt understreck (__). Du kan till exempel använda appinställningarna nedan för att konfigurera enskilda funktionsloggnivåer som i host.json ovan.

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 på bladet Funktionsappkonfiguration i Azure-portalen eller med hjälp av ett Azure CLI- eller PowerShell-skript.

az 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

Funktionen Hälsokontroll kan användas för att övervaka funktionsappar i Premium-planer (Elastic Premium) och Dedikerade (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. Funktionsappen ska ha en HTTP-utlösarfunktion som svarar med en HTTP-statuskod på 200 på samma slutpunkt som konfigurerad på parametern Sökväg i 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.

Nästa steg

Mer information om övervakning finns i:

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

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

Nästa steg

Ytterligare resurser