Bewaking configureren voor Azure Functions
Azure Functions integreert met Application Insights, zodat je je functie-apps beter kunt bewaken. Application Insights, een functie van Azure Monitor, is een uitbreidbare APM-service (Application Performance Management) die gegevens verzamelt die door uw functie-app worden gegenereerd, inclusief informatie die uw app naar logboeken schrijft. Application Insights-integratie wordt doorgaans ingeschakeld wanneer uw functie-app wordt gemaakt. Als uw app niet beschikt over de instrumentatiesleutelset, moet u eerst Application Insights-integratie inschakelen.
Je kunt Application Insights gebruiken zonder aangepaste configuratie. De standaardconfiguratie kan echter leiden tot grote hoeveelheden gegevens. Als u een Visual Studio Azure-abonnement gebruikt, bereikt u mogelijk uw gegevenslimiet voor Application Insights. Zie Application Insights-facturering voor meer informatie over de kosten van Application Insights. Zie Oplossingen met een groot aantal telemetriegegevens voor meer informatie.
In dit artikel leert u hoe u de gegevens configureert en aanpast die door uw functies naar Application Insights worden verzonden. U kunt algemene configuraties voor logboekregistratie instellen in het host.json-bestand. Deze instellingen bepalen standaard ook aangepaste logboeken die door uw code worden verzonden. In sommige gevallen kan dit gedrag echter worden uitgeschakeld ten gunste van opties die u meer controle geven over logboekregistratie. Zie Aangepaste toepassingslogboeken voor meer informatie.
Notitie
U kunt speciaal geconfigureerde toepassingsinstellingen gebruiken om specifieke instellingen in een host.json-bestand voor een bepaalde omgeving weer te geven. Hierdoor kunt u host.json instellingen effectief wijzigen zonder dat u het host.json-bestand opnieuw hoeft te publiceren in uw project. Voor meer informatie, zie Host.json-waarden overschrijven.
Aangepaste toepassingslogboeken
Aangepaste toepassingslogboeken die u schrijft, worden standaard verzonden naar de Functions-host. Deze worden vervolgens naar Application Insights verzonden onder de categorie Worker. Met sommige taalstacks kunt u in plaats daarvan de logboeken rechtstreeks naar Application Insights verzenden, zodat u volledige controle hebt over hoe logboeken die u schrijft, worden verzonden. In dit geval wordt de logboekpijplijn gewijzigd van worker -> Functions host -> Application Insights
in worker -> Application Insights
.
De volgende tabel bevat een overzicht van de configuratieopties die beschikbaar zijn voor elke stack:
Taalstack | Waar aangepaste logboeken te configureren |
---|---|
.NET (model in proces) | host.json |
.NET (geïsoleerd model) | Standaard (aangepaste logboeken verzenden naar de Functions-host): host.json Als u logboeken rechtstreeks naar Application Insights wilt verzenden, raadpleegt u: Application Insights configureren in hostbuilder |
Node.JS | host.json |
Python | host.json |
Java | Standaard (aangepaste logboeken verzenden naar de Functions-host): host.json Als u logboeken rechtstreeks naar Application Insights wilt verzenden, raadpleegt u: De Application Insights Java-agent configureren |
Powershell | host.json |
Wanneer u aangepaste toepassingslogboeken configureert om rechtstreeks te worden verzonden, verzendt de host deze niet meer en host.json
beheert het gedrag niet meer. Op dezelfde manier zijn de opties die door elke stack worden weergegeven, alleen van toepassing op aangepaste logboeken en wijzigen ze niet het gedrag van de andere runtimelogboeken die in dit artikel worden beschreven. In dit geval moet u mogelijk wijzigingen aanbrengen in beide configuraties om het gedrag van alle logboeken te beheren.
Categorieën configureren
De Azure Functions-logboekregistratie bevat een categorie voor elk logboek. De categorie geeft aan welk deel van de runtime-code of je functiecode het logboek heeft geschreven. Categorieën verschillen tussen versie 1.x en latere versies.
Categorienamen worden anders toegewezen in Functions in vergelijking met andere .NET Frameworks. Wanneer u bijvoorbeeld in ASP.NET gebruikt ILogger<T>
, is de categorie de naam van het algemene type. C#-functies gebruiken ILogger<T>
ook, maar in plaats van de algemene typenaam in te stellen als categorie, wijst de runtime categorieën toe op basis van de bron. Voorbeeld:
- Vermeldingen met betrekking tot het uitvoeren van een functie worden toegewezen aan een categorie van
Function.<FUNCTION_NAME>
. - Vermeldingen die zijn gemaakt door gebruikerscode in de functie, zoals bij het aanroepen
logger.LogInformation()
, krijgen een categorie vanFunction.<FUNCTION_NAME>.User
.
In de volgende tabel worden de belangrijkste categorieën logboeken beschreven die door de runtime worden gemaakt:
Categorie | Table | Beschrijving |
---|---|---|
Function |
Sporen | Bevat gestarte en voltooide logboeken voor alle functieuitvoeringen. Voor geslaagde uitvoeringen zijn deze logboeken op het Information niveau. Uitzonderingen worden vastgelegd op het Error niveau. De runtime maakt Warning ook niveaulogboeken, zoals wanneer wachtrijberichten naar de gifwachtrij worden verzonden. |
Function.<YOUR_FUNCTION_NAME> |
Afhankelijkheden | Afhankelijkheidsgegevens worden automatisch verzameld voor sommige services. Voor geslaagde uitvoeringen zijn deze logboeken op het Information niveau. Zie voor meer informatie Afhankelijkheden. Uitzonderingen worden vastgelegd op het Error niveau. De runtime maakt Warning ook niveaulogboeken, zoals wanneer wachtrijberichten naar de gifwachtrij worden verzonden. |
Function.<YOUR_FUNCTION_NAME> |
customMetrics customEvents |
Met C# en JavaScript SDK's kunt u aangepaste metrische gegevens verzamelen en aangepaste gebeurtenissen registreren. Zie Aangepaste telemetriegegevens voor meer informatie. |
Function.<YOUR_FUNCTION_NAME> |
Sporen | Bevat gestarte en voltooide logboeken voor specifieke functieuitvoeringen. Voor geslaagde uitvoeringen zijn deze logboeken op het Information niveau. Uitzonderingen worden vastgelegd op het Error niveau. De runtime maakt Warning ook niveaulogboeken, zoals wanneer wachtrijberichten naar de gifwachtrij worden verzonden. |
Function.<YOUR_FUNCTION_NAME>.User |
Sporen | Door de gebruiker gegenereerde logboeken, die elk logboekniveau kunnen zijn. Zie Schrijven naar logboeken voor meer informatie over het schrijven naar logboeken vanuit uw functies. |
Host.Aggregator |
customMetrics | Deze door runtime gegenereerde logboeken bieden aantallen en gemiddelden van functie-aanroepen gedurende een configureerbare periode. De standaardperiode is 30 seconden of 1000 resultaten, afhankelijk van wat het eerst voorkomt. Voorbeelden zijn het aantal uitvoeringen, het slagingspercentage en de duur. Al deze logboeken worden op het Information niveau geschreven. Als u filtert op Warning of hoger, ziet u geen van deze gegevens. |
Host.Results |
Verzoeken | Deze door runtime gegenereerde logboeken geven aan dat een functie is geslaagd of mislukt. Al deze logboeken worden op het Information niveau geschreven. Als u filtert op Warning of hoger, ziet u geen van deze gegevens. |
Microsoft |
Sporen | Volledig gekwalificeerde logboekcategorie die overeenkomt met een .NET Runtime-onderdeel dat door de host wordt aangeroepen. |
Worker |
Sporen | Logboeken die zijn gegenereerd door het taalwerkproces voor non-.NET talen. Taalwerklogboeken kunnen ook worden geregistreerd in een Microsoft.* categorie, zoals Microsoft.Azure.WebJobs.Script.Workers.Rpc.RpcFunctionInvocationDispatcher . Deze logboeken worden op het Information niveau geschreven. |
Notitie
Voor .NET-klassenbibliotheekfuncties gaan deze categorieën ervan uit dat u gebruikt ILogger
en niet ILogger<T>
. Zie de documentatie over Functions ILogger voor meer informatie.
De kolom Tabel geeft aan aan welke tabel in Application Insights het logboek is geschreven.
Logboekniveaus configureren
Er wordt een logboekniveau toegewezen aan elk logboek. De waarde is een geheel getal dat het relatieve belang aangeeft:
Logniveau | Code | Beschrijving |
---|---|---|
Trace | 0 | Logboeken die de meest gedetailleerde berichten bevatten. Deze berichten bevatten mogelijk gevoelige toepassingsgegevens. Deze berichten zijn standaard uitgeschakeld en moeten nooit worden ingeschakeld in een productieomgeving. |
Fouten opsporen | 1 | Logboeken die worden gebruikt voor interactief onderzoek tijdens de ontwikkeling. Deze logboeken moeten voornamelijk informatie bevatten die nuttig is voor foutopsporing en geen waarde voor de lange termijn hebben. |
Gegevens | 2 | Logboeken die de algemene stroom van de toepassing bijhouden. Deze logboeken moeten een langetermijnwaarde hebben. |
Waarschuwing | 3 | Logboeken waarin een abnormale of onverwachte gebeurtenis in de toepassingsstroom wordt gemarkeerd, maar anders wordt de uitvoering van de toepassing niet gestopt. |
Error | 4 | Logboeken die markeren wanneer de huidige uitvoeringsstroom wordt gestopt vanwege een fout. Deze fouten moeten duiden op een fout in de huidige activiteit, niet op een toepassingsbrede fout. |
Kritiek | 5 | Logboeken die een onherstelbare toepassing of systeemcrash beschrijven, of een onherstelbare fout waarvoor onmiddellijke aandacht is vereist. |
Geen | 6 | Schakelt logboekregistratie voor de opgegeven categorie uit. |
De configuratie van het host.json-bestand bepaalt hoeveel logboekregistratie een functions-app naar Application Insights verzendt.
Voor elke categorie geeft u het minimale logboekniveau aan dat moet worden verzonden. De host.json-instellingen variëren afhankelijk van de runtimeversie van Functions.
In de volgende voorbeelden wordt logboekregistratie gedefinieerd op basis van de volgende regels:
- Het standaardniveau voor logboekregistratie is zo ingesteld
Warning
dat overmatige logboekregistratie voor onverwachte categorieën wordt voorkomen. Host.Aggregator
enHost.Results
worden ingesteld op lagere niveaus. Het instellen van logboekregistratieniveaus (met name hoger danInformation
) kan leiden tot verlies van metrische gegevens en prestatiegegevens.- Logboekregistratie voor functieuitvoeringen is ingesteld op
Information
. Indien nodig kunt u deze instelling in lokale ontwikkeling overschrijven naarDebug
ofTrace
.
{
"logging": {
"fileLoggingMode": "debugOnly",
"logLevel": {
"default": "Warning",
"Host.Aggregator": "Trace",
"Host.Results": "Information",
"Function": "Information"
}
}
}
Als host.json meerdere logboeken bevat die beginnen met dezelfde tekenreeks, worden de meer gedefinieerde logboeken eerst vergeleken. Bekijk het volgende voorbeeld dat alles in de runtime registreert, behalve Host.Aggregator
op het Error
niveau:
{
"logging": {
"fileLoggingMode": "debugOnly",
"logLevel": {
"default": "Information",
"Host": "Error",
"Function": "Error",
"Host.Aggregator": "Information"
}
}
}
U kunt een instelling None
op logboekniveau gebruiken om te voorkomen dat logboeken voor een categorie worden geschreven.
Let op
Azure Functions kan worden geïntegreerd met Application Insights door telemetrie-gebeurtenissen op te slaan in Application Insights-tabellen. Als u een categorielogboekniveau instelt op een andere Information
waarde dan, voorkomt u dat de telemetrie naar deze tabellen stroomt en u geen gerelateerde gegevens kunt zien op de tabbladen Application Insights en Functiecontrole .
Bijvoorbeeld voor de vorige voorbeelden:
- Als u de
Host.Results
categorie instelt op hetError
logboekniveau, verzamelt Azure alleen telemetriegebeurtenissen voor hostuitvoeringen in derequests
tabel voor mislukte functieuitvoeringen, waardoor de weergave van details van de hostuitvoering van geslaagde uitvoeringen op de tabbladen Application Insights en Function Monitor wordt voorkomen. - Als u de
Function
categorie instelt op hetError
logboekniveau, stopt het verzamelen van functietelemetriegegevens met betrekking totdependencies
,customMetrics
encustomEvents
voor alle functies, waardoor u geen van deze gegevens in Application Insights kunt weergeven. Azure verzamelt alleentraces
geregistreerd op hetError
niveau.
In beide gevallen blijft Azure fouten en uitzonderingen verzamelen op de tabbladen Application Insights en Function Monitor . Zie Oplossingen met een groot aantal telemetriegegevens voor meer informatie.
De aggregator configureren
Zoals u in de vorige sectie hebt genoteerd, worden in de runtime gegevens over functie-uitvoeringen gedurende een bepaalde periode samengevoegd. De standaardperiode is 30 seconden of 1000 uitvoeringen, afhankelijk van wat het eerst voorkomt. U kunt deze instelling configureren in het host.json-bestand. Voorbeeld:
{
"aggregator": {
"batchSize": 1000,
"flushTimeout": "00:00:30"
}
}
Steekproeven configureren
Application Insights heeft een samplingfunctie die u kan beschermen tegen het produceren van te veel telemetriegegevens bij voltooide uitvoeringen op momenten van piekbelasting. Wanneer de snelheid van binnenkomende uitvoeringen een opgegeven drempelwaarde overschrijdt, begint Application Insights een aantal binnenkomende uitvoeringen willekeurig te negeren. De standaardinstelling voor het maximum aantal uitvoeringen per seconde is 20 (vijf in versie 1.x). U kunt steekproeven configureren in host.json. Hier volgt een voorbeeld:
{
"logging": {
"applicationInsights": {
"samplingSettings": {
"isEnabled": true,
"maxTelemetryItemsPerSecond" : 20,
"excludedTypes": "Request;Exception"
}
}
}
}
U kunt bepaalde typen telemetrie uitsluiten van steekproeven. In dit voorbeeld worden gegevens van het type Request
en Exception
uitgesloten van steekproeven. Het zorgt ervoor dat alle uitvoeringen van functies (aanvragen) en uitzonderingen worden geregistreerd terwijl andere typen telemetrie onderhevig blijven aan steekproeven.
Als uw project gebruikmaakt van een afhankelijkheid van de Application Insights SDK voor het handmatig bijhouden van telemetrie, kunt u ongebruikelijk gedrag ervaren als uw steekproefconfiguratie verschilt van de steekproefconfiguratie in uw functie-app. In dergelijke gevallen gebruikt u dezelfde steekproefconfiguratie als de functie-app. Zie Sampling in Application Insights voor meer informatie.
SQL-queryverzameling inschakelen
Application Insights verzamelt automatisch gegevens over afhankelijkheden voor HTTP-aanvragen, databaseaanroepen en voor verschillende bindingen. Zie voor meer informatie Afhankelijkheden. Voor SQL-aanroepen wordt de naam van de server en database altijd verzameld en opgeslagen, maar sql-querytekst wordt niet standaard verzameld. U kunt de logboekregistratie van SQL-queryteksten inschakelen dependencyTrackingOptions.enableSqlCommandTextInstrumentation
met behulp van de volgende instellingen (minimaal) in uw host.json bestand:
"logging": {
"applicationInsights": {
"enableDependencyTracking": true,
"dependencyTrackingOptions": {
"enableSqlCommandTextInstrumentation": true
}
}
}
Zie Geavanceerde SQL-tracering voor meer informatie om een volledige SQL-query op te halen.
Schaalcontrollerlogboeken configureren
Deze functie is beschikbaar als preview-versie.
U kunt de Azure Functions-schaalcontroller logboeken laten verzenden naar Application Insights of blobopslag om beter inzicht te krijgen in de beslissingen die de schaalcontroller neemt voor uw functie-app.
Als u deze functie wilt inschakelen, voegt u een toepassingsinstelling toe met de naam aan SCALE_CONTROLLER_LOGGING_ENABLED
de instellingen van uw functie-app. De volgende waarde van de instelling moet de notatie <DESTINATION>:<VERBOSITY>
hebben. Zie de volgende tabel voor meer informatie:
Eigenschappen | Beschrijving |
---|---|
<DESTINATION> |
Het doel waarnaar logboeken worden verzonden. Geldige waarden zijn AppInsights en Blob .Wanneer u deze gebruikt AppInsights , moet u ervoor zorgen dat Application Insights is ingeschakeld in uw functie-app.Wanneer u het doel Blob instelt, worden logboeken gemaakt in een blobcontainer met de naam azure-functions-scale-controller in het standaardopslagaccount dat is ingesteld in de AzureWebJobsStorage toepassingsinstelling. |
<VERBOSITY> |
Hiermee geeft u het niveau van logboekregistratie op. Ondersteunde waarden zijn None , Warning en Verbose .Wanneer dit is ingesteld Verbose , registreert de schaalcontroller een reden voor elke wijziging in het aantal werknemers en informatie over de triggers die in deze beslissingen van invloed zijn. Uitgebreide logboeken bevatten triggerwaarschuwingen en de hashes die door de triggers worden gebruikt voor en nadat de schaalcontroller wordt uitgevoerd. |
Tip
Houd er rekening mee dat wanneer u de logboekregistratie van de schaalcontroller ingeschakeld laat, dit van invloed is op de mogelijke kosten voor het bewaken van uw functie-app. Overweeg logboekregistratie in te schakelen totdat u voldoende gegevens hebt verzameld om te begrijpen hoe de schaalcontroller werkt en deze vervolgens uit te schakelen.
Met de volgende Azure CLI-opdracht wordt uitgebreide logboekregistratie van de schaalcontroller naar Application Insights ingeschakeld:
az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:Verbose
Vervang in dit voorbeeld <FUNCTION_APP_NAME>
respectievelijk <RESOURCE_GROUP_NAME>
de naam van uw functie-app en de naam van de resourcegroep.
Met de volgende Azure CLI-opdracht wordt logboekregistratie uitgeschakeld door de uitgebreidheid in te stellen op None
:
az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:None
U kunt logboekregistratie ook uitschakelen door de SCALE_CONTROLLER_LOGGING_ENABLED
instelling te verwijderen met behulp van de volgende Azure CLI-opdracht:
az functionapp config appsettings delete --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--setting-names SCALE_CONTROLLER_LOGGING_ENABLED
Als logboekregistratie van de schaalcontroller is ingeschakeld, kunt u nu query's uitvoeren op de logboeken van uw schaalcontroller.
Application Insights-integratie inschakelen
Als een functie-app gegevens naar Application Insights wil verzenden, moet deze verbinding maken met de Application Insights-resource met behulp van slechts een van deze toepassingsinstellingen:
Naam instelling | Beschrijving |
---|---|
APPLICATIONINSIGHTS_CONNECTION_STRING |
Deze instelling wordt aanbevolen en is vereist wanneer uw Application Insights-exemplaar wordt uitgevoerd in een onafhankelijke cloud. De verbindingsreeks ondersteunt andere nieuwe mogelijkheden. |
APPINSIGHTS_INSTRUMENTATIONKEY |
Verouderde instelling, die Application Insights heeft afgeschaft ten gunste van de verbindingsreeks-instelling. |
Wanneer u uw functie-app maakt in Azure Portal vanaf de opdrachtregel met behulp van Azure Functions Core Tools of Visual Studio Code, wordt Application Insights-integratie standaard ingeschakeld. De Application Insights-resource heeft dezelfde naam als uw functie-app en wordt gemaakt in dezelfde regio of in de dichtstbijzijnde regio.
Microsoft Entra-verificatie vereisen
U kunt de APPLICATIONINSIGHTS_AUTHENTICATION_STRING
instelling gebruiken om verbindingen met Application Insights in te schakelen met behulp van Microsoft Entra-verificatie. Hiermee maakt u een consistente verificatie-ervaring voor alle Application Insights-pijplijnen, waaronder Profiler en Snapshot Debugger, evenals van de Functions-host en taalspecifieke agents.
Notitie
Er is geen Ondersteuning voor Entra-verificatie voor lokale ontwikkeling.
De waarde bevat Authorization=AAD
voor een door het systeem toegewezen beheerde identiteit of ClientId=<YOUR_CLIENT_ID>;Authorization=AAD
voor een door de gebruiker toegewezen beheerde identiteit. De beheerde identiteit moet al beschikbaar zijn voor de functie-app, met een toegewezen rol die gelijk is aan De uitgever van metrische gegevens bewaken. Zie Microsoft Entra-verificatie voor Application Insights voor meer informatie.
De APPLICATIONINSIGHTS_CONNECTION_STRING
instelling is nog steeds vereist.
Notitie
APPLICATIONINSIGHTS_AUTHENTICATION_STRING
Wanneer u verbinding maakt met Application Insights met behulp van Microsoft Entra-verificatie, moet u ook lokale verificatie uitschakelen voor Application Insights. Voor deze configuratie is Microsoft Entra-verificatie vereist om telemetrie op te nemen in uw werkruimte.
Nieuwe functie-app in de portal
Als u de Application Insights-resource wilt bekijken die wordt gemaakt, selecteert u deze om het Application Insights-venster uit te vouwen. U kunt de naam van de nieuwe resource wijzigen of een andere locatie selecteren in een Azure-geografie waar u uw gegevens wilt opslaan.
Wanneer u Maken selecteert, wordt er een Application Insights-resource gemaakt met uw functie-app, die is APPLICATIONINSIGHTS_CONNECTION_STRING
ingesteld in toepassingsinstellingen. Alles is klaar om te gaan.
Toevoegen aan een bestaande functie-app
Als er geen Application Insights-resource is gemaakt met uw functie-app, gebruikt u de volgende stappen om de resource te maken. Vervolgens kunt u de verbindingsreeks vanuit die resource toevoegen als toepassingsinstelling in uw functie-app.
Zoek en selecteer in Azure Portal de functie-app en selecteer vervolgens uw functie-app.
Selecteer bovenaan het venster de banner Application Insights is not configured (Application Insights is niet geconfigureerd). Als u deze banner niet ziet staan, is Application Insights al ingeschakeld voor uw app.
Vouw Wijzig uw resource uit en maak een Application Insights-resource met behulp van de instellingen die zijn opgegeven in de volgende tabel:
Instelling Voorgestelde waarde Beschrijving Nieuwe resourcenaam Unieke app-naam Het is het gemakkelijkst om dezelfde naam als voor uw functie-app te gebruiken. Deze naam moet uniek zijn in uw abonnement. Location Europa -west Gebruik indien mogelijk dezelfde regio als uw functie-app of de regio die zich dicht bij die regio bevindt. Selecteer Toepassen.
De Application Insights-resource wordt gemaakt in dezelfde resourcegroep en hetzelfde abonnement als uw functie-app. Nadat de resource is gemaakt, sluit u het Application Insights-venster .
Vouw in uw functie-app Instellingen uit en selecteer vervolgens Omgevingsvariabelen. Als u op het tabblad App-instellingen een app-instelling ziet met de naam
APPLICATIONINSIGHTS_CONNECTION_STRING
, is Application Insights-integratie ingeschakeld voor uw functie-app die wordt uitgevoerd in Azure. Als deze instelling niet bestaat, voegt u deze toe met behulp van uw Application Insights-verbindingsreeks als de waarde.
Notitie
Oudere functie-apps kunnen APPINSIGHTS_INSTRUMENTATIONKEY
in plaats van APPLICATIONINSIGHTS_CONNECTION_STRING
. Werk indien mogelijk uw app bij om de verbindingsreeks te gebruiken in plaats van de instrumentatiesleutel.
Ingebouwde logboekregistratie uitschakelen
Vroege versies van Functions hebben ingebouwde bewaking gebruikt, wat niet meer wordt aanbevolen. Wanneer u Application Insights inschakelt, schakelt u de ingebouwde logboekregistratie uit die gebruikmaakt van Azure Storage. De ingebouwde logboekregistratie is handig voor het testen met lichte werkbelastingen, maar is niet bedoeld voor productiegebruik met hoge belasting. Voor productiebewaking raden we Application Insights aan. Als u ingebouwde logboekregistratie in productie gebruikt, is de logboekregistratierecord mogelijk onvolledig vanwege beperking in Azure Storage.
Als u ingebouwde logboekregistratie wilt uitschakelen, verwijdert u de AzureWebJobsDashboard
app-instelling. Zie de sectie Toepassingsinstellingen van Een functie-app beheren voor meer informatie over het verwijderen van app-instellingen in Azure Portal. Voordat u de app-instelling verwijdert, moet u ervoor zorgen dat er geen bestaande functies in dezelfde functie-app de instelling gebruiken voor Azure Storage-triggers of -bindingen.
Oplossingen met een groot aantal telemetriegegevens
Functie-apps zijn een essentieel onderdeel van oplossingen die grote hoeveelheden telemetrie kunnen veroorzaken, zoals IoT-oplossingen, snelle, gebeurtenisgestuurde oplossingen, financiële systemen met hoge belasting en integratiesystemen. In dit geval moet u rekening houden met extra configuratie om de kosten te verlagen en tegelijkertijd de waarneembaarheid te behouden.
De gegenereerde telemetrie kan worden gebruikt in realtime dashboards, waarschuwingen, gedetailleerde diagnostische gegevens, enzovoort. Afhankelijk van hoe de gegenereerde telemetrie wordt verbruikt, moet u een strategie definiëren om het aantal gegenereerde gegevens te verminderen. Met deze strategie kunt u uw functie-apps in productie correct bewaken, gebruiken en diagnosticeren. Overweeg de volgende opties:
Gebruik steekproeven: zoals eerder vermeld, helpt sampling om het volume van opgenomen telemetriegebeurtenissen aanzienlijk te verminderen terwijl een statistisch juiste analyse wordt gehandhaafd. Het kan gebeuren dat u zelfs met behulp van steekproeven nog steeds een groot aantal telemetriegegevens krijgt. Inspecteer de opties die adaptieve steekproeven voor u bieden. Stel bijvoorbeeld de
maxTelemetryItemsPerSecond
waarde in op een waarde waarmee het volume dat is gegenereerd, wordt afgestemd op uw bewakingsbehoeften. Houd er rekening mee dat de telemetriesampling wordt toegepast per host die uw functie-app uitvoert.Standaardlogboekniveau: gebruik
Warning
ofError
als de standaardwaarde voor alle telemetriecategorieën. Later kunt u bepalen welke categorieën u wilt instellen op hetInformation
niveau, zodat u uw functies goed kunt controleren en diagnosticeren.Uw functiestelemetrie afstemmen: als het standaardlogboekniveau is ingesteld op
Error
ofWarning
, worden er geen gedetailleerde gegevens van elke functie verzameld (afhankelijkheden, aangepaste metrische gegevens, aangepaste gebeurtenissen en traceringen). Voor functies die essentieel zijn voor productiebewaking, definieert u een expliciete vermelding voor deFunction.<YOUR_FUNCTION_NAME>
categorie en stelt u dezeInformation
in op , zodat u gedetailleerde informatie kunt verzamelen. Als u wilt voorkomen dat door de gebruiker gegenereerde logboeken op hetInformation
niveau worden verzameld, stelt u deFunction.<YOUR_FUNCTION_NAME>.User
categorie in op hetError
niveau ofWarning
het logboekniveau.Host.Aggregator-categorie: Zoals beschreven in configuratiecategorieën, biedt deze categorie geaggregeerde informatie over functie-aanroepen. De informatie uit deze categorie wordt verzameld in de Application Insights-tabel
customMetrics
en wordt weergegeven op het tabblad Overzicht van de functie in Azure Portal. Afhankelijk van hoe u de aggregator configureert, moet u er rekening mee houden dat er een vertraging kan zijn, bepaald door deflushTimeout
instelling, in de verzamelde telemetrie. Als u deze categorie instelt op een andereInformation
waarde, stopt u met het verzamelen van de gegevens in decustomMetrics
tabel en worden geen metrische gegevens weergegeven op het tabblad Overzicht van de functie.In de volgende schermopname ziet
Host.Aggregator
u telemetriegegevens die worden weergegeven op het tabblad Overzicht van de functie:In de volgende schermopname ziet
Host.Aggregator
u telemetriegegevens in de Application Insights-tabelcustomMetrics
:Categorie Host.Results: Zoals beschreven in categorieën configureren, biedt deze categorie de door runtime gegenereerde logboeken die aangeven dat een functie aanroep is geslaagd of mislukt. De informatie uit deze categorie wordt verzameld in de Application Insights-tabel
requests
en wordt weergegeven op het tabblad Controle van de functie en in verschillende Application Insights-dashboards (prestaties, fouten, enzovoort). Als u deze categorie instelt op een andere waarde danInformation
, verzamelt u alleen telemetrie die wordt gegenereerd op het gedefinieerde logboekniveau (of hoger). Als u deze bijvoorbeeld instelt operror
resultaten in het bijhouden van aanvragen, worden alleen gegevens bijgehouden voor mislukte uitvoeringen.In de volgende schermopname ziet u de
Host.Results
telemetriegegevens die worden weergegeven op het tabblad Functiecontrole:In de volgende schermopname ziet
Host.Results
u telemetriegegevens die worden weergegeven in het Application Insights Performance-dashboard:Host.Aggregator versus Host.Results: Beide categorieën bieden goede inzichten over functie-uitvoeringen. Indien nodig kunt u de gedetailleerde informatie uit een van deze categorieën verwijderen, zodat u de andere kunt gebruiken voor bewaking en waarschuwingen. Hier volgt een voorbeeld:
{
"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"
}
}
}
}
Met deze configuratie:
De standaardwaarde voor alle functies en telemetriecategorieën is ingesteld op
Warning
(inclusief Microsoft- en Werkrolcategorieën). Alle fouten en waarschuwingen die worden gegenereerd door runtime en aangepaste logboekregistratie, worden dus standaard verzameld.Het
Function
categorielogboekniveau is ingesteld opError
, dus voor alle functies worden standaard alleen uitzonderingen en foutenlogboeken verzameld. Afhankelijkheden, door de gebruiker gegenereerde metrische gegevens en door de gebruiker gegenereerde gebeurtenissen worden overgeslagen.Voor de
Host.Aggregator
categorie, omdat deze is ingesteld op hetError
logboekniveau, worden geaggregeerde gegevens van functieaanroepen niet verzameld in decustomMetrics
Application Insights-tabel en worden er geen gegevens over het aantal uitvoeringen (totaal, geslaagd en mislukt) weergegeven in het dashboard van het functieoverzicht.Voor de
Host.Results
categorie worden alle uitvoeringsinformatie van de host verzameld in derequests
Application Insights-tabel. Alle resultaten van de aanroepen worden weergegeven in het dashboard van de functie Monitor en in Application Insights-dashboards.Voor de aangeroepen
Function1
functie stellen we het logboekniveau in opInformation
. Voor deze concrete functie worden alle telemetriegegevens verzameld (afhankelijkheid, aangepaste metrische gegevens en aangepaste gebeurtenissen). Voor dezelfde functie stellen we de categorie (door deFunction1.User
gebruiker gegenereerde traceringen)Error
in op, zodat alleen aangepaste foutlogboekregistratie wordt verzameld.Notitie
Configuratie per functie wordt niet ondersteund in v1.x van de Functions-runtime.
Sampling is geconfigureerd voor het verzenden van één telemetrie-item per seconde per type, met uitzondering van de uitzonderingen. Deze steekproef vindt plaats voor elke serverhost waarop onze functie-app wordt uitgevoerd. Dus als we vier exemplaren hebben, worden met deze configuratie vier telemetrie-items per seconde per type verzonden en worden alle uitzonderingen die kunnen optreden, verzonden.
Notitie
Metrische tellingen, zoals aanvraagsnelheid en uitzonderingsfrequentie, worden aangepast om de steekproeffrequentie te compenseren, zodat ze ongeveer juiste waarden weergeven in Metric Explorer.
Tip
Experimenteer met verschillende configuraties om ervoor te zorgen dat u voldoet aan uw vereisten voor logboekregistratie, bewaking en waarschuwingen. Zorg er ook voor dat u gedetailleerde diagnostische gegevens hebt in geval van onverwachte fouten of storingen.
Bewakingsconfiguratie tijdens runtime overschrijven
Ten slotte kunnen er situaties zijn waarin u snel het logboekgedrag van een bepaalde categorie in productie moet wijzigen en u niet een hele implementatie wilt maken voor een wijziging in het host.json-bestand . In dergelijke gevallen kunt u de host.json waarden overschrijven.
Als u deze waarden op app-instellingenniveau wilt configureren (en niet opnieuw wilt implementeren bij alleen host.json wijzigingen), moet u specifieke host.json
waarden overschrijven door een equivalente waarde te maken als een toepassingsinstelling. Wanneer de runtime een toepassingsinstelling in de indeling AzureFunctionsJobHost__path__to__setting
vindt, wordt de equivalente host.json
instelling path.to.setting
in de JSON overschreven. Wanneer deze wordt uitgedrukt als een toepassingsinstelling, vervangt een dubbele onderstrepingsteken (__
) de punt (.
) die wordt gebruikt om de JSON-hiërarchie aan te geven. U kunt bijvoorbeeld de volgende app-instellingen gebruiken om afzonderlijke functielogboekniveaus in host.json
te stellen.
Host.json pad | App-instelling |
---|---|
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 |
U kunt de instellingen rechtstreeks overschrijven in het deelvenster Functie-app-configuratie van de Azure-portal of met behulp van een Azure CLI- of PowerShell-script.
az functionapp config appsettings set --name MyFunctionApp --resource-group MyResourceGroup --settings "AzureFunctionsJobHost__logging__logLevel__Host__Aggregator=Information"
Notitie
Als u het host.json
wijzigen van app-instellingen overschrijft, wordt uw functie-app opnieuw gestart.
App-instellingen die een periode bevatten, worden niet ondersteund bij het uitvoeren op Linux in een Elastic Premium-abonnement of een Toegewezen (App Service)-abonnement. In deze hostingomgevingen moet u het host.json-bestand blijven gebruiken.
Functie-apps bewaken met statuscontrole
U kunt de functie Statuscontrole gebruiken om functie-apps te controleren op de Abonnementen Premium (Elastic Premium) en Dedicated (App Service). Statuscontrole is geen optie voor het verbruiksabonnement. Zie App Service-exemplaren bewaken met behulp van statuscontrole voor meer informatie over het configureren ervan. Uw functie-app moet een HTTP-triggerfunctie hebben die reageert met een HTTP-statuscode van 200 op hetzelfde eindpunt als geconfigureerd op de Path
parameter van de statuscontrole. U kunt deze functie ook extra controles laten uitvoeren om ervoor te zorgen dat afhankelijke services bereikbaar en werken.
Gerelateerde inhoud
Zie voor meer informatie over bewaking: