Share via

Bewaking configureren voor Azure Functions

  • Artikel

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 van Function.<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 en Host.Results worden ingesteld op lagere niveaus. Het instellen van logboekregistratieniveaus (met name hoger dan Information) 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 naar Debug of Trace.
{
  "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.Aggregatorop 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 Informationwaarde 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 het Error logboekniveau, verzamelt Azure alleen telemetriegebeurtenissen voor hostuitvoeringen in de requests 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 het Error logboekniveau, stopt het verzamelen van functietelemetriegegevens met betrekking tot dependencies, customMetricsen customEvents voor alle functies, waardoor u geen van deze gegevens in Application Insights kunt weergeven. Azure verzamelt alleen traces geregistreerd op het Error 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 Blobinstelt, 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, Warningen 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.

Schermopname van het inschakelen van Application Insights tijdens het maken van een functie-app.

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.

  1. Zoek en selecteer in Azure Portal de functie-app en selecteer vervolgens uw functie-app.

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

    Schermopname van het inschakelen van Application Insights vanuit de portal.

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

    Schermopname van het maken van een Application Insights-resource.

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

  5. 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 of Error als de standaardwaarde voor alle telemetriecategorieën. Later kunt u bepalen welke categorieën u wilt instellen op het Information niveau, zodat u uw functies goed kunt controleren en diagnosticeren.

  • Uw functiestelemetrie afstemmen: als het standaardlogboekniveau is ingesteld op Error of Warning, 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 de Function.<YOUR_FUNCTION_NAME> categorie en stelt u deze Informationin op , zodat u gedetailleerde informatie kunt verzamelen. Als u wilt voorkomen dat door de gebruiker gegenereerde logboeken op het Information niveau worden verzameld, stelt u de Function.<YOUR_FUNCTION_NAME>.User categorie in op het Error niveau of Warning 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 de flushTimeout instelling, in de verzamelde telemetrie. Als u deze categorie instelt op een andere Informationwaarde, stopt u met het verzamelen van de gegevens in de customMetrics 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:

    Schermopname van de telemetrie host.Aggregator die wordt weergegeven op het tabblad Overzicht van de functie.

    In de volgende schermopname ziet Host.Aggregator u telemetriegegevens in de Application Insights-tabel customMetrics :

    Schermopname van host.Aggregator-telemetrie in de tabel customMetrics Application Insights.

  • 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 dan Information, verzamelt u alleen telemetrie die wordt gegenereerd op het gedefinieerde logboekniveau (of hoger). Als u deze bijvoorbeeld instelt op error 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:

    Schermopname van host.results-telemetrie op het tabblad Functiecontrole.

    In de volgende schermopname ziet Host.Results u telemetriegegevens die worden weergegeven in het Application Insights Performance-dashboard:

    Schermopname van de telemetrie host.results 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 op Error, 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 het Error logboekniveau, worden geaggregeerde gegevens van functieaanroepen niet verzameld in de customMetrics 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 de requests 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 Function1functie stellen we het logboekniveau in op Information. Voor deze concrete functie worden alle telemetriegegevens verzameld (afhankelijkheid, aangepaste metrische gegevens en aangepaste gebeurtenissen). Voor dezelfde functie stellen we de categorie (door de Function1.User gebruiker gegenereerde traceringen) Errorin 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__settingvindt, 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.jsonte 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: