Bewaking biedt inzicht in het gedrag en de status van uw systemen en helpt bij het bouwen van een holistische weergave van de omgeving, historische trends, correleren van diverse factoren en het meten van wijzigingen in prestaties, verbruik of foutpercentage.
Azure Functions biedt ingebouwde integratie met Application Insights. Vanuit Application Insights kunt u informatie ophalen, zoals het aantal exemplaren van de functie-app of de aanvraag- en afhankelijkheidstelemetrie van een functie. Wanneer u met Functions en Event Hubs werkt, kan Application Insights ook de uitgaande afhankelijkheidstelemetrieën bijhouden naar de Event Hub, de verwerkingstijd berekenen en de end-to-end-stroom van het systeem weergeven dat is verbonden via Event Hubs.
In deze sectie worden nuttige functies en inzichten geïntroduceerd die u kunt verkrijgen uit Application Insights voor uw Event Hubs plus Functions-oplossing.
Toepassingskaart
Toepassingsoverzicht laat zien hoe de onderdelen in een systeem met elkaar communiceren. Vanwege de afhankelijkheidstelemetrie die Application Insights biedt, wordt de stroom gebeurtenissen tussen Azure Functions en Event Hubs toegewezen, inclusief het gemiddelde van elke functie-uitvoering en de gemiddelde duur van een gebeurtenis in Event Hubs, evenals het weergeven van transacties die fouten bevatten die rood zijn gemarkeerd.
Nadat u de verwachte belasting naar uw systeem hebt verzonden, kunt u naar Application Insights in Azure Portal gaan en op de zijbalk toepassingsoverzicht kiezen. Hier volgt een kaart met drie functies, drie Event Hubs en zichtbare fouten bij het schrijven naar een downstreamdatabase:
End-to-end-transactiedetails
End-to-end transactiegegevens laten zien hoe uw systeemonderdelen met elkaar communiceren, in chronologische volgorde. In deze weergave ziet u ook hoe lang een gebeurtenis heeft besteed aan de verwerking. U kunt ook inzoomen op de telemetrie van elk onderdeel vanuit deze weergave, waardoor het eenvoudiger is om problemen op te lossen tussen onderdelen binnen dezelfde aanvraag wanneer er een probleem is opgetreden.
Metrische gegevens en telemetrie van het platform
Door het platform gegenereerde metrische gegevens in Azure Monitor voor Event Hubs en Azure Functions kunnen worden gebruikt voor algemene bewaking van het gedrag en de status van de oplossing:
Metrische gegevens van Azure Event Hubs in Azure Monitor zijn van belang om nuttige inzichten vast te leggen voor Event Hubs (zoals aggregaties van binnenkomende aanvragen, uitgaande aanvragen, vertraagde aanvragen, geslaagde aanvragen, binnenkomende berichten, uitgaande berichten, vastgelegde berichten, binnenkomende bytes, uitgaande bytes, vastgelegde bytes, gebruikersfouten).
Metrische gegevens van Azure Functions delen veel van de metrische gegevens van Azure-app Service, met de toevoeging van het aantal uitvoeringen van functies en functie-uitvoeringseenheden die kunnen worden gebruikt om inzicht te krijgen in het gebruik en de kosten van het verbruiksabonnement. Andere interessante metrische gegevens zijn verbindingen, gegevens in, gegevens-out, gemiddelde hoeveelheid geheugen, aantal threads, aanvragen en reactietijd.
Azure Functions kan worden geïntegreerd met Application Insights om geavanceerde en gedetailleerde telemetrie en inzichten te bieden in de Functions-host en de uitvoering van functies. Zie Azure Functions-telemetrie analyseren in Application Insights voor meer informatie. Wanneer u Application Insights gebruikt om een topologie te bewaken, zijn er verschillende configuraties beschikbaar. Zie Bewaking configureren voor Azure Functions voor meer informatie.
Hier volgt een voorbeeld van extra telemetrie voor door Event Hubs geactiveerde functies die zijn gegenereerd in de traceringentabel :
Trigger Details: PartionId: 6, Offset: 3985758552064-3985758624640, EnqueueTimeUtc: 2022-10-31T12:51:58.1750000+00:00-2022-10-31T12:52:03.8160000+00:00, SequenceNumber: 3712266-3712275, Count: 10
Voor deze informatie moet u de Event Hubs-extensie 4.2.0 of een latere versie gebruiken. Deze gegevens zijn erg nuttig omdat deze informatie bevat over het bericht dat de uitvoering van de functie heeft geactiveerd en kan worden gebruikt voor het uitvoeren van query's en inzichten. Deze bevat de volgende gegevens voor elke keer dat de functie wordt geactiveerd:
- De partitie-id (6)
- Het partitieverschilbereik (3985758552064-3985758624640)
- Het tijdsbereik in de wachtrij in UTC (2022-10-31T12:51:58.1750000+00:00-2022-10-31T12:52:03.8160000+00:00)
- Het reeksnummerbereik 3712266-3712275
- En het aantal berichten (10)
Raadpleeg de sectie Voorbeeld van Application Insights-query's voor voorbeelden over het gebruik van deze telemetrie.
Aangepaste telemetrie is ook mogelijk voor verschillende talen (C#-klassebibliotheek, C# Isolated, C#-script, JavaScript, Java, PowerShell en Python). Deze logboekregistratie wordt weergegeven in de traceringentabel in Application Insights. U kunt uw eigen vermeldingen maken in Application Insights en aangepaste dimensies toevoegen die kunnen worden gebruikt voor het opvragen van gegevens en het maken van aangepaste dashboards.
Ten slotte worden vermeldingen ook naar de tabel Application Insights-afhankelijkheden geschreven wanneer uw functie-app verbinding maakt met een Event Hub met behulp van een uitvoerbinding.
Voor Event Hubs wordt de correlatie geïnjecteerd in de nettolading van de gebeurtenis en ziet u een eigenschap Diagnostic-Id in gebeurtenissen:
Dit volgt de W3C Trace Context-indeling die ook wordt gebruikt als bewerkings-id en bewerkingskoppelingen in telemetrie die zijn gemaakt door Functions, waardoor Application Insights de correlatie tussen event hub-gebeurtenissen en functie-uitvoeringen kan maken, zelfs wanneer ze worden gedistribueerd.
Voorbeeld van Application Insights-query's
Hieronder vindt u een lijst met nuttige Application Insights-query's bij het bewaken van Event Hubs met Azure Functions. Deze query geeft gedetailleerde informatie weer voor de door Event Hub geactiveerde functie met behulp van telemetrie die wordt verzonden door de Event Hubs-extensie 4.2.0 en hoger.
Wanneer steekproeven zijn ingeschakeld in Application Insights, kunnen er hiaten in de gegevens zijn.
Gedetailleerde informatie over gebeurtenisverwerking
De gegevens worden alleen verzonden in de juiste indeling wanneer batchgewijze verzending wordt gebruikt. Batch-verzending betekent dat de functie meerdere gebeurtenissen accepteert voor elke uitvoering, wat wordt aanbevolen voor prestaties. Houd rekening met de volgende overwegingen:
- De
dispatchTimeMillisecondswaarde benadert de tijdsduur tussen het moment waarop de gebeurtenis naar de Event Hub is geschreven en wanneer deze is opgehaald door de functie-app voor verwerking. dispatchTimeMillisecondskan negatief of anderszins onnauwkeurig zijn vanwege klokdrift tussen de Event Hub-server en de functie-app.- Event Hubs-partities worden opeenvolgend verwerkt. Een bericht wordt pas verzonden naar functiecode voor verwerking als alle eerdere berichten zijn verwerkt. Bewaak de uitvoeringstijd van uw functies naarmate langere uitvoeringstijden leiden tot verzendvertragingen.
- De berekening maakt gebruik van de enqueueTime van het eerste bericht in de batch. Verzendtijden kunnen lager zijn voor andere berichten in de batch.
dispatchTimeMillisecondsis gebaseerd op het tijdstip.- Reeksnummers zijn per partitie en dubbele verwerking kan optreden omdat Event Hubs niet garandeert dat berichten exact eenmaal worden bezorgd.
traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| extend dispatchTimeMilliseconds = (timestamp - enqueueTimeStart) / 1ms
| project timestamp, cloud_RoleInstance, operation_Name, processId =
customDimensions.ProcessId, partitionId, messageCount, sequenceNumberStart,
sequenceNumberEnd, enqueueTimeStart, enqueueTimeEnd, dispatchTimeMilliseconds
Visualisatie van de verzendlatentie
Met deze query wordt de latentie van de 50e en 90e percentielgebeurtenisverzending voor een bepaalde door event hub geactiveerde functie gevisualiseerd. Zie de bovenstaande query voor meer informatie en notities.
traces
| where operation_Name == "<ENTER THE NAME OF YOUR FUNCTION HERE>"
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| extend dispatchTimeMilliseconds = (timestamp - enqueueTimeStart) / 1ms
| summarize percentiles(dispatchTimeMilliseconds, 50, 90) by bin(timestamp, 5m)
| render timechart
Samenvatting van de verzendlatentie
Deze query is vergelijkbaar met hierboven, maar toont een samenvattingsweergave.
traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| extend dispatchTimeMilliseconds = (timestamp - enqueueTimeStart) / 1ms
| summarize messageCount = sum(messageCount),
percentiles(dispatchTimeMilliseconds, 50, 90, 99, 99.9, 99.99) by operation_Name
Berichtdistributie over partities
Deze query laat zien hoe u de distributie van berichten over partities kunt visualiseren.
traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| summarize messageCount = sum(messageCount) by cloud_RoleInstance,
bin(timestamp, 5m)
| render areachart kind=stacked
Berichtdistributie tussen exemplaren
Deze query laat zien hoe u de distributie van berichten over exemplaren kunt visualiseren.
traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| summarize messageCount = sum(messageCount) by cloud_RoleInstance,
bin(timestamp, 5m)
| render areachart kind=stacked
Instanties en toegewezen exemplaren uitvoeren
Deze query laat zien hoe u het aantal Azure Functions-exemplaren kunt visualiseren dat gebeurtenissen van Event Hubs verwerkt, en het totale aantal exemplaren (verwerken en wachten op lease). Meestal moeten ze hetzelfde zijn.
traces
| where message startswith "Trigger Details: Parti"
| summarize type = "Executing Instances", Count = dcount(cloud_RoleInstance) by
bin(timestamp, 60s)
| union (
traces
| summarize type = "Allocated Instances", Count = dcount(cloud_RoleInstance) by
bin(timestamp, 60s)
)
| project timestamp, type, Count
| render timechart
Alle telemetriegegevens voor een specifieke functie-uitvoering
Het operation_Id veld kan worden gebruikt in de verschillende tabellen in Application Insights. Voor Door Event Hubs geactiveerde Azure Functions resulteert de volgende query bijvoorbeeld in de triggergegevens, telemetrie van logboeken in de functiecode en afhankelijkheden en uitzonderingen:
union isfuzzy=true requests, exceptions, traces, dependencies
| where * has "<ENTER THE OPERATION_ID OF YOUR FUNCTION EXECUTION HERE>"
| order by timestamp asc
End-to-endlatentie voor een gebeurtenis
Aangezien de eigenschap enqueueTimeUtc in de triggerdetailtracering de tijd in de wachtrij toont van alleen de eerste gebeurtenis van elke batch die door de functie is verwerkt, kan een geavanceerdere query worden gebruikt om de end-to-end latentie van gebeurtenissen tussen twee functies met Event Hubs ertussen te berekenen. Met deze query worden de bewerkingskoppelingen (indien aanwezig) in de aanvraag van de tweede functie uitgebreid en wordt de eindtijd toegewezen aan dezelfde bijbehorende bewerkings-id van de eerste begintijd van de functie.
let start = view(){
requests
| where operation_Name == "FirstFunction"
| project start_t = timestamp, first_operation_Id = operation_Id
};
let link = view(){
requests
| where operation_Name == "SecondFunction"
| mv-expand ex = parse_json(tostring(customDimensions["_MS.links"]))
| extend parent = case(isnotempty(ex.operation_Id), ex.operation_Id, operation_Id )
| project first_operation_Id = parent, second_operation_Id = operation_Id
};
let finish = view(){
traces
| where customDimensions["EventName"] == "FunctionCompleted" and operation_Name
== "SecondFunction"
| project end_t = timestamp, second_operation_Id = operation_Id
};
start
| join kind=inner (
link
| join kind=inner finish on second_operation_Id
) on first_operation_Id
| project start_t, end_t, first_operation_Id, second_operation_Id
| summarize avg(datetime_diff('second', end_t, start_t))
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Hoofdauteur:
- David Barkol | Principal Solution Specialist GBB
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.
Volgende stappen
Raadpleeg de volgende verwante artikelen voor meer informatie:
- Azure Functions-telemetrie analyseren in Application Insights
- Bewaking configureren voor Azure Functions
- Azure Functions-telemetrie analyseren in Application Insights
- Metrische gegevens in Azure Monitor - Azure Event Hubs
- Kusto-querytaal
- Serverloze gebeurtenisverwerking is een referentiearchitectuur met een typische architectuur van dit type, met codevoorbeelden en bespreking van belangrijke overwegingen.