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. Hiermee kunt u een holistische weergave van de omgeving bouwen, historische trends ophalen, diverse factoren correleren en wijzigingen in prestaties, verbruik of foutpercentage meten. U kunt bewaking gebruiken om waarschuwingen te definiëren wanneer er omstandigheden optreden die van invloed kunnen zijn op de kwaliteit van uw service of wanneer er omstandigheden zijn die van belang zijn voor uw specifieke omgeving.

In dit artikel wordt gedemonstreerd hoe u Azure Monitor serverloze toepassing kunt bewaken die is gebouwd met Event Hubs en Azure Functions. In dit artikel worden nuttige metrische gegevens besproken die u kunt bewaken, wordt beschreven hoe u kunt integreren met Application Insights en aangepaste metrische gegevens kunt vastleggen en codevoorbeelden kunt bieden.

Aannames

In dit artikel wordt ervan uitgenomen dat u een architectuur hebt die lijkt op de architectuur die wordt beschreven in de referentiearchitectuur voor serverloze gebeurtenisverwerking. Eigenlijk:

• Gebeurtenissen komen aan Azure Event Hubs.
• Een functie-app wordt geactiveerd om de gebeurtenis te verwerken.
• Azure Monitor is beschikbaar voor gebruik met uw architectuur.

Metrische gegevens van Azure Monitor

Eerst moeten we bepalen welke metrische gegevens nodig zijn voordat we nuttige inzichten over de architectuur kunnen formuleren. 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
• Beperkt aantal aanvragen
• Geslaagde aanvragen
• Binnenkomende berichten
• Uitgaande berichten
• Vastgelegde berichten
• Binnenkomende bytes
• Uitgaande bytes
• Vastgelegde bytes
• Gebruikersfouten

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

• Aantal uitvoeringen van functies
• Verbindingen
• Gegevens in
• Gegevens uit
• HTTP-serverfouten
• Aanvragen
• Aanvragen in de toepassingswachtrij
• Reactietijd

Diagnostische logboekregistratie gebruiken om inzichten vast te leggen

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

• Aantal aanvragen dat door de Event Hubs
• Aantal aanvragen dat door de Azure Functions
• Totale Doorvoer van Event Hub
• 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 Event Hubs de benodigde metrische gegevens vast te leggen, moeten we eerst diagnostische logboeken inschakelen (die standaard zijn uitgeschakeld). Vervolgens moeten we selecteren welke logboeken gewenst zijn en de juiste Log Analytics-werkruimte configureren als de 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 ingesteld als bestemming. (Als er een extern systeem wordt gebruikt voor het analyseren van de logboeken, kan in plaats daarvan de optie voor streamen naar een Event Hub worden gebruikt.)

Application Insights

U kunt Application Insights inschakelen om metrische gegevens en aangepaste telemetriegegevens van Azure Functions. Hiermee kunt u analyses definiëren die geschikt zijn voor uw eigen doeleinden en zo een andere manier bieden om belangrijke inzichten te verkrijgen voor het scenario voor serverloze gebeurtenisverwerking.

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, die een tijdlijn voor verschillende functie-exemplaren omvatten:

• 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 run worden aangeroepen.

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

Aangepaste berichten

Aangepaste berichten die zijn vastgelegd in de Azure Function-code (met behulp van de ) worden verkregen uit de ILogger tabel Application Insights traces application.

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

• timestamp
• cloud_RoleInstance
• operation_Id
• operation_Name
• message

Hier ziet u een voorbeeld van hoe een aangepast bericht eruit kan zien in de application Insights interface:

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

Voor ons scenario voor serverloze gebeurtenisverwerking wordt de geseraliseerde bericht-body van JSON die van de Event Hub is ontvangen, in een logboek opgeslagen. Hierdoor kunnen we de onbewerkte byte-matrix vastleggen, samen SystemProperties met x-opt-sequence-number , en x-opt-offset x-opt-enqueued-time . Om te bepalen wanneer elk bericht is ontvangen door de Event Hub, wordt x-opt-enqueued-time de eigenschap gebruikt.

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 retourneerde een bericht dat vergelijkbaar is met het volgende voorbeeldresultaat, dat standaard wordt vastgelegd in Application Insights. De eigenschappen van de kunnen worden gebruikt om aanvullende inzichten te vinden en vast te leggen voor berichten die Trigger Details worden ontvangen per , en PartitionId Offset SequenceNumber .

Voorbeeldresultaat van de voorbeeldquery:

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

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

In Application Insights kunnen we alle telemetrie weergeven die betrekking heeft op een bepaalde transactie door een transactiezoekquery uit te voeren op de waarde van de Operation Id transactie. Dit kan vooral nuttig zijn voor het vastleggen van de percentielwaarden van gemiddelde tijden voor berichten wanneer de transactie zich door de pijplijn van de gebeurtenisstroom verplaatst.

In de volgende schermopname ziet u een voorbeeld van een transactiezoekactie in de application Insights interface. Het gewenste wordt ingevoerd in het queryveld, aangegeven met een vergrootglaspictogram (en hier in een Operation ID rood kader weergegeven). Onderaan het hoofdvenster ziet u op Results het tabblad overeenkomende gebeurtenissen in sequentiële volgorde. In elke gebeurtenisinvoer is Operation ID de waarde donkerblauw gemarkeerd voor eenvoudige verificatie.

Een query die wordt gegenereerd voor een specifieke bewerkings-id ziet er als volgt uit. Houd er rekening mee Operation ID dat de GUID is opgegeven in de component van de derde where * has 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 ziet u een schermopname van hoe de query en de bijbehorende resultaten eruit kunnen zien in de Application Insights interface:

Aangepaste metrische gegevens van Azure Functions

.NET-functies

Gestructureerde logboekregistratie wordt gebruikt in de .NET Azure-functies voor het vastleggen van aangepaste dimensies in de tabel Insights traceringen. Deze aangepaste dimensies kunnen vervolgens worden gebruikt voor het opvragen van gegevens.

Hier is bijvoorbeeld de logboek-instructie in de .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 zijn gemaakt op application Insights 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)

host.jsvoorbeeld:

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

Java-functies

Gestructureerde logboekregistratie wordt momenteel niet ondersteund in Java Azure-functies voor het vastleggen van aangepaste dimensies in de tabel Insights traceringen.

Hier is bijvoorbeeld de logboek-instructie in Java TransformingFunction :

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

De resulterende logboeken die zijn gemaakt op 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))

host.jsvoorbeeld:

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

Gerelateerde resources

• Serverloze gebeurtenisverwerking is een referentiearchitectuur waarin een typische architectuur van dit type wordt beschreven, met codevoorbeelden en een bespreking van belangrijke overwegingen.
• In Batchverwerking en filteren in serverloze gebeurtenisverwerking met Event Hubs wordt gedetailleerder beschreven hoe deze gedeelten van de referentiearchitectuur werken.
• Een Private Link-scenario in de verwerking van gebeurtenisstroom 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 variant van een serverloze gebeurtenisgestuurde architectuur die wordt uitgevoerd op Azure Kubernetes met KEDA-scaler.