Serverloze gebeurtenisverwerking bewaken

Dit artikel bevat richtlijnen voor het bewaken van serverloze gebeurtenisgestuurde architecturen.

Bewaking biedt inzicht in het gedrag en de status van uw systemen. Het helpt u bij het bouwen van een holistische weergave van de omgeving, het ophalen van historische trends, het correleren van diverse factoren en het meten van wijzigingen in prestaties, verbruik of foutpercentage. U kunt bewaking gebruiken om waarschuwingen te definiëren wanneer zich omstandigheden voordoen die van invloed kunnen zijn op de kwaliteit van uw service of wanneer zich omstandigheden voordoen die van bijzonder belang zijn voor uw specifieke omgeving.

In dit artikel wordt gedemonstreerd hoe u Azure Monitor gebruikt voor het bewaken van een serverloze toepassing die is gebouwd met Event Hubs en Azure Functions. Het bespreekt nuttige metrische gegevens die u kunt bewaken, beschrijft hoe u integreert met Application Insights en aangepaste metrische gegevens vastlegt, en biedt codevoorbeelden.

Aannames

In dit artikel wordt ervan uitgegaan dat u een architectuur hebt zoals beschreven in de referentiearchitectuur serverloze gebeurtenisverwerking. Eigenlijk:

• Gebeurtenissen komen aan op Azure Event Hubs.
• Er wordt een functie-app geactiveerd om de gebeurtenis af te handelen.
• Azure Monitor is beschikbaar voor gebruik met uw architectuur.

Metrische gegevens van Azure Monitor

Eerst moeten we beslissen welke metrische gegevens nodig zijn voordat we kunnen beginnen met het formuleren van nuttige inzichten over de architectuur. Elke resource voert verschillende taken uit en genereert op zijn beurt verschillende metrische gegevens.

Deze metrische gegevens van Event Hub zijn van belang om nuttige inzichten vast te leggen:

• Binnenkomende aanvragen
• Uitgaande aanvragen
• Vertraagde aanvragen
• Geslaagde aanvragen
• Inkomende berichten
• Uitgaande berichten
• Vastgelegde berichten
• Binnenkomende bytes
• Uitgaande bytes
• Vastgelegde bytes
• Gebruikersfouten

Op dezelfde manier zijn deze metrische gegevens van Azure Functions van belang om nuttige inzichten vast te leggen:

• Aantal functies uitvoeren
• Verbindingen
• Gegevens in
• Gegevens zijn uit
• HTTP-serverfouten
• Aanvragen
• Aanvragen in toepassingswachtrij
• Reactietijd

Diagnostische logboekregistratie gebruiken om inzichten vast te leggen

Wanneer ze samen worden geanalyseerd, kunnen de bovenstaande metrische gegevens worden gebruikt om de volgende inzichten te formuleren en vast te leggen:

• Aantal aanvragen dat door Event Hubs wordt verwerkt
• Aantal aanvragen verwerkt door Azure Functions
• Totale Event Hub-doorvoer
• Gebruikersfouten
• Duur van Azure Functions
• End-to-end-latentie
• Latentie in elke fase
• Aantal verloren berichten
• Aantal berichten dat meer dan één keer is verwerkt

Om ervoor te zorgen dat Event Hubs de benodigde metrische gegevens vastlegt, moeten we eerst diagnostische logboeken inschakelen (deze zijn standaard uitgeschakeld). Vervolgens moeten we selecteren welke logboeken gewenst zijn en de juiste Log Analytics-werkruimte configureren als bestemming voor deze logboeken.

De logboek- en metrische categorieën waarin we geïnteresseerd zijn, zijn:

• OperationalLogs
• AutoScaleLogs
• KafkaCoordinatorLogs (voor Apache Kafka-workloads)
• KafkaUserErrorLogs (voor Apache Kafka-workloads)
• EventHubVNetConnectionEvent
• AllMetrics

Azure-documentatie bevat instructies voor het instellen van diagnostische logboeken voor een Azure Event Hub. In de volgende schermopname ziet u een voorbeeld van een configuratievenster voor diagnostische instellingen met de juiste logboek- en metrische categorieën geselecteerd en een Log Analytics-werkruimte die is ingesteld als het doel. (Als een extern systeem wordt gebruikt om de logboeken te analyseren, kan in plaats daarvan de optie voor streamen naar een Event Hub worden gebruikt.)

Notitie

Als u logboekdiagnose wilt gebruiken om inzichten vast te leggen, moet u Event Hubs in verschillende naamruimten maken. Dit komt door een beperking in Azure.

De Event Hubs-set in een bepaalde Event Hubs-naamruimte wordt weergegeven in metrische gegevens van Azure Monitor onder een dimensie met de naam EntityName. In de Azure Portal kunnen gegevens voor een specifieke Event Hub normaal gesproken worden weergegeven op dat exemplaar van Azure Monitor. Maar wanneer de metrische gegevens worden doorgestuurd naar de logboekdiagnose, is er momenteel geen manier om gegevens per Event Hub weer te geven door te filteren op de EntityName dimensie.

Als tijdelijke oplossing maakt het maken van Event Hubs in verschillende naamruimten het mogelijk om metrische gegevens voor een specifieke hub te vinden.

Application Insights gebruiken

U kunt Application Insights inschakelen om metrische gegevens en aangepaste telemetriegegevens van Azure Functions vast te leggen. Hiermee kunt u analyses definiëren die aansluiten bij uw eigen doeleinden, waardoor u op een andere manier belangrijke inzichten kunt verkrijgen voor het serverloze gebeurtenisverwerkingsscenario.

In deze schermopname ziet u een voorbeeld van aangepaste metrische gegevens en telemetrie in Application Insights:

Standaard aangepaste metrische gegevens

In Application Insights worden aangepaste metrische gegevens voor Azure Functions opgeslagen in de customMetrics tabel. Het bevat de volgende waarden, verspreid over een tijdlijn voor verschillende functie-exemplaren:

• AvgDurationMs
• MaxDurationMs
• MinDurationMs
• Successes
• Failures
• SuccessRate
• Count

Deze metrische gegevens kunnen worden gebruikt om efficiënt de geaggregeerde gemiddelden te berekenen voor de meerdere functie-exemplaren die in een uitvoering worden aangeroepen.

In deze schermopname ziet u hoe deze standaard aangepaste metrische gegevens eruitzien wanneer ze worden weergegeven in Application Insights:

Aangepaste berichten

Aangepaste berichten die zijn vastgelegd in de Azure-functiecode (met behulp van ) ILoggerworden opgehaald uit de tabel Application Insights traces .

De traces tabel heeft (onder andere) de volgende belangrijke eigenschappen:

• timestamp
• cloud_RoleInstance
• operation_Id
• operation_Name
• message

Hier volgt een voorbeeld van hoe een aangepast bericht eruit kan zien in de Application Insights-interface:

Als het binnenkomende Event Hub-bericht of EventData[] wordt geregistreerd als onderdeel van dit aangepaste ILogger bericht, wordt dat ook beschikbaar gesteld in Application Insights. Dit kan erg handig zijn.

Voor ons scenario voor serverloze gebeurtenisverwerking registreren we de geserialiseerde JSON-berichttekst die is ontvangen van de Event Hub. Hierdoor kunnen we de onbewerkte bytematrix vastleggen, samen met SystemProperties , x-opt-offsetx-opt-sequence-numberen x-opt-enqueued-time. De eigenschap wordt gebruikt om te bepalen wanneer elk bericht is ontvangen door de x-opt-enqueued-time Event Hub.

Voorbeeldquery:

traces
| where timestamp between(min_t .. max_t)
| where message contains "Body"
| extend m = parse_json(message))
| project timestamp = todatetime(m.SystemProperties.["x-opt-enqueued-time"])

De voorbeeldquery retourneert een bericht dat lijkt op het volgende voorbeeldresultaat, dat standaard wordt geregistreerd in Application Insights. De eigenschappen van de Trigger Details kunnen worden gebruikt om aanvullende inzichten te vinden en vast te leggen over berichten die zijn ontvangen per PartitionId, Offseten SequenceNumber.

Voorbeeldresultaat van de voorbeeldquery:

"message": Trigger Details: PartitionId: 26, Offset: 17194119200, EnqueueTimeUtc: 2020-11-03T02:14:01.7740000Z, SequenceNumber: 843572, Count: 10,

Waarschuwing

De bibliotheek voor Azure Java Functions heeft momenteel een probleem waardoor de toegang tot en PartitionID de PartitionContext wordt verhinderd bij gebruik van EventHubTrigger. Meer informatie in dit GitHub-probleemrapport.

Berichtenstroom bijhouden met behulp van een transactie-id met Application Insights

In Application Insights kunnen we alle telemetriegegevens met betrekking tot een bepaalde transactie bekijken door een transactiezoekquery uit te voeren op de waarde van Operation Id de transactie. Dit kan met name handig zijn voor het vastleggen van de percentielwaarden van gemiddelde tijden voor berichten terwijl de transactie de pijplijn van de gebeurtenisstroom doorloopt.

In de volgende schermopname ziet u een voorbeeld van een transactiezoekopdracht in de Interface van Application Insights. Het gewenste Operation ID wordt ingevoerd in het queryveld, aangegeven met een vergrootglaspictogram (en hier weergegeven in een rood vak). Onderaan het hoofdvenster ziet u op het Results tabblad overeenkomende gebeurtenissen in opeenvolgende volgorde. In elke gebeurtenisvermelding wordt de Operation ID waarde gemarkeerd in donkerblauw voor eenvoudige verificatie.

Een query die voor een specifieke bewerkings-id wordt gegenereerd, ziet er als volgt uit. Houd er rekening mee dat de Operation ID GUID is opgegeven in de component van where * has de derde regel. In dit voorbeeld wordt de query verder beperkt tussen twee verschillende datetimes.

union isfuzzy=true availabilityResults, requests, exceptions, pageViews, traces, customEvents, dependencies
| where timestamp > datetime("2020-10-09T06:58:40.024Z") and timestamp < datetime("2020-11-11T06:58:40.024Z")
| where * has "1c8c9d7073a00e4bbdcc8f2e6570e46"
| order by timestamp desc
| take 100

Hier volgt een schermopname van hoe de query en de bijbehorende resultaten eruit kunnen zien in de Application Insights-interface:

Aangepaste metrische gegevens van Azure Functions vastleggen

.NET-functies

Gestructureerde logboekregistratie wordt gebruikt in de .NET Azure-functies voor het vastleggen van aangepaste dimensies in de Application Insights-traceringstabel. Deze aangepaste dimensies kunnen vervolgens worden gebruikt voor het uitvoeren van query's op gegevens.

Hier ziet u bijvoorbeeld de logboekinstructie in .NET TransformingFunction:

log.LogInformation("TransformingFunction: Processed sensorDataJson={sensorDataJson}, " +
    "partitionId={partitionId}, offset={offset} at {enqueuedTimeUtc}, " +
    "inputEH_enqueuedTime={inputEH_enqueuedTime}, processedTime={processedTime}, " +
    "transformingLatencyInMs={transformingLatencyInMs}, processingLatencyInMs={processingLatencyInMs}",
    sensorDataJson,
    partitionId,
    offset,
    enqueuedTimeUtc,
    inputEH_enqueuedTime,
    processedTime,
    transformingLatency,
    processingLatency);

De resulterende logboeken die in Application Insights zijn gemaakt, bevatten de bovenstaande parameters als aangepaste dimensies, zoals wordt weergegeven in deze schermopname:

Deze logboeken kunnen als volgt worden opgevraagd:

traces
| where timestamp between(min_t .. max_t)
// Function name should be of the function consuming from the Event Hub of interest
| where operation_Name == "{Function_Name}"
| where message has "{Function_Name}: Processed"
| project timestamp = todatetime(customDimensions.prop__enqueuedTimeUtc)

Notitie

Om ervoor te zorgen dat de prestaties in deze tests niet worden beïnvloed, hebben we de steekproefinstellingen van Azure Function-logboeken voor Application Insights ingeschakeld met behulp van het host.json bestand, zoals hieronder wordt weergegeven. Dit betekent dat alle statistieken die uit logboekregistratie zijn vastgelegd, worden beschouwd als gemiddelde waarden en niet als werkelijke aantallen.

host.json-voorbeeld:

"logging": {
    "applicationInsights": {
        "samplingExcludedTypes": "Request",
        "samplingSettings": {
            "isEnabled": true
        }
    }
}

Java-functies

Op dit moment wordt gestructureerde logboekregistratie niet ondersteund in Java Azure Functions voor het vastleggen van aangepaste dimensies in de Application Insights-traceringstabel.

Hier volgt bijvoorbeeld de logboekinstructie in Java TransformingFunction:

LoggingUtilities.logSuccessInfo(
    context.getLogger(), 
    "TransformingFunction", 
    "SuccessInfo", 
    offset, 
    processedTimeString, 
    dateformatter.format(enqueuedTime), 
    transformingLatency
);

De resulterende logboeken die zijn gemaakt in Application Insights, bevatten de bovenstaande parameters in het bericht, zoals hieronder wordt weergegeven:

Deze logboeken kunnen als volgt worden opgevraagd:

traces
| where timestamp between(min_t .. max_t)
// Function name should be of the function consuming from the Event Hub of interest
| where operation_Name in ("{Function name}") and message contains "SuccessInfo"
| project timestamp = todatetime(tostring(parse_json(message).enqueuedTime))

Notitie

Om ervoor te zorgen dat de prestaties in deze tests niet worden beïnvloed, hebben we de steekproefinstellingen van Azure Function-logboeken voor Application Insights ingeschakeld met behulp van het host.json bestand, zoals hieronder wordt weergegeven. Dit betekent dat alle statistieken die uit logboekregistratie zijn vastgelegd, worden beschouwd als gemiddelde waarden en niet als werkelijke aantallen.

host.json-voorbeeld:

"logging": {
    "applicationInsights": {
        "samplingExcludedTypes": "Request",
        "samplingSettings": {
            "isEnabled": true
        }
    }
}

Medewerkers

Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzenders.

Hoofdauteur:

• Rajasa Savant | Senior Software Engineer

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Gerelateerde resources

• Serverloze gebeurtenisverwerking is een referentiearchitectuur waarin een typische architectuur van dit type wordt beschreven, met codevoorbeelden en discussie over belangrijke overwegingen.
• Bij het ongedaan maken van batches en filteren in serverloze gebeurtenisverwerking met Event Hubs wordt in meer detail beschreven hoe deze gedeelten van de referentiearchitectuur werken.
• Private Link-scenario in gebeurtenisstroomverwerking is een oplossingsidee voor het implementeren van een vergelijkbare architectuur in een virtueel netwerk (VNet) met privé-eindpunten om de beveiliging te verbeteren.
• Azure Kubernetes in gebeurtenisstroomverwerking beschrijft een variatie van een serverloze gebeurtenisgestuurde architectuur die wordt uitgevoerd op Azure Kubernetes met KEDA-scaler.