Övervaka serverlös händelsebearbetning

Den här artikeln innehåller vägledning om övervakning av serverlösa händelsedrivna arkitekturer.

Övervakning ger insikt i systemens beteende och hälsa. Det hjälper dig att skapa en holistisk vy över miljön, hämta historiska trender, korrelera olika faktorer och mäta ändringar i prestanda, förbrukning eller felfrekvens. Du kan använda övervakning för att definiera aviseringar när villkor inträffar som kan påverka tjänstens kvalitet, eller när villkor av särskilt intresse för din specifika miljö uppstår.

Den här artikeln visar hur du använder Azure Monitor för att övervaka ett serverlöst program som skapats med Event Hubs och Azure Functions. Den beskriver användbara mått för att övervaka, beskriver hur du integrerar med Application Insights och samlar in anpassade mått och tillhandahåller kodexempel.

Antaganden

Den här artikeln förutsätter att du har en arkitektur som liknar den som beskrivs i referensarkitekturen för serverlös händelsebearbetning. Botten:

• Händelser kommer till Azure Event Hubs.
• En funktionsapp utlöses för att hantera händelsen.
• Azure Monitor är tillgängligt för användning med din arkitektur.

Mått från Azure Monitor

Först måste vi bestämma vilka mått som behövs innan vi kan börja formulera användbara insikter om arkitekturen. Varje resurs utför olika uppgifter och genererar i sin tur olika mått.

Dessa mått från Event Hub är intressanta för att samla in användbara insikter:

• Inkommande begäranden
• Utgående begäranden
• Begränsade begäranden
• Lyckade begäranden
• Inkommande meddelanden
• Utgående meddelanden
• Insamlade meddelanden
• Inkommande byte
• Utgående byte
• Insamlade byte
• Användarfel

På samma sätt är dessa mått från Azure Functions intressanta för att samla in användbara insikter:

• Antal funktionskörningar
• Anslutningar
• Data i
• Utgående data
• HTTP-serverfel
• Begäranden
• Begäranden i programkö
• Svarstid

Använda diagnostikloggning för att samla in insikter

När de analyseras tillsammans kan ovanstående mått användas för att formulera och samla in följande insikter:

• Frekvens för begäranden som bearbetas av Event Hubs
• Frekvens för begäranden som bearbetas av Azure Functions
• Totalt event hub-dataflöde
• Användarfel
• Varaktighet för Azure Functions
• Svarstid från slutpunkt till slutpunkt
• Svarstid i varje steg
• Antal förlorade meddelanden
• Antal meddelanden som bearbetas mer än en gång

För att säkerställa att Event Hubs samlar in nödvändiga mått måste vi först aktivera diagnostikloggar (som är inaktiverade som standard). Vi måste sedan välja vilka loggar som ska vara önskade och konfigurera rätt Log Analytics-arbetsyta som mål för dem.

De logg- och måttkategorier som vi är intresserade av är:

• OperationalLogs
• Autoskalningsloggar
• KafkaCoordinatorLogs (för Apache Kafka-arbetsbelastningar)
• KafkaUserErrorLogs (för Apache Kafka-arbetsbelastningar)
• EventHubVNetConnectionEvent
• AllMetrics

Azure-dokumentationen innehåller instruktioner om hur du konfigurerar diagnostikloggar för en Azure-händelsehubb. Följande skärmbild visar ett exempel på konfigurationspanelen för diagnostikinställning med rätt logg- och måttkategorier valda och en Log Analytics-arbetsyta som mål. (Om ett externt system används för att analysera loggarna kan alternativet Att strömma till en händelsehubb användas i stället.)

Anteckning

För att använda loggdiagnostik för att samla in insikter bör du skapa händelsehubbar i olika namnområden. Detta beror på en begränsning i Azure.

Event Hubs-uppsättningen i en viss Event Hubs-namnrymd representeras i Azure Monitor-mått under en dimension som heter EntityName. I Azure Portal kan data för en specifik händelsehubb normalt visas på den instansen av Azure Monitor. Men när måttdata dirigeras till loggdiagnostiken finns det för närvarande inget sätt att visa data per händelsehubb genom att filtrera på dimensionen EntityName .

En lösning är att skapa händelsehubbar i olika namnområden så att du kan hitta mått för en specifik hubb.

Använda Application Insights

Du kan aktivera Application Insights för att samla in mått och anpassad telemetri från Azure Functions. På så sätt kan du definiera analyser som passar dina egna syften, vilket ger ett annat sätt att få viktiga insikter för det serverlösa händelsebearbetningsscenariot.

Den här skärmbilden visar en exempellista över anpassade mått och telemetri i Application Insights:

Anpassade standardmått

I Application Insights lagras anpassade mått för Azure Functions i customMetrics tabellen. Den innehåller följande värden som sträcker sig över en tidslinje för olika funktionsinstanser:

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

Dessa mått kan användas för att effektivt beräkna de aggregerade medelvärdena för de flera funktionsinstanser som anropas i en körning.

Den här skärmbilden visar hur dessa anpassade standardmått ser ut när de visas i Application Insights:

Anpassade meddelanden

Anpassade meddelanden som loggas i Azure-funktionskoden (med hjälp av ILogger) hämtas från tabellen Application Insights traces .

Tabellen traces har följande viktiga egenskaper (bland annat):

• timestamp
• cloud_RoleInstance
• operation_Id
• operation_Name
• message

Här är ett exempel på hur ett anpassat meddelande kan se ut i Application Insights-gränssnittet:

Om det inkommande Event Hub-meddelandet eller EventData[] loggas som en del av det här anpassade ILogger meddelandet görs det också tillgängligt i Application Insights. Detta kan vara mycket användbart.

I vårt scenario med serverlös händelsebearbetning loggar vi den serialiserade meddelandetexten för JSON som tas emot från händelsehubben. På så sätt kan vi samla in raw byte-matrisen, tillsammans med SystemProperties , x-opt-sequence-numberx-opt-offsetoch x-opt-enqueued-time. Egenskapen används för att avgöra när varje meddelande togs emot av händelsehubben x-opt-enqueued-time .

Exempelfråga:

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"])

Exempelfrågan returnerar ett meddelande som liknar följande exempelresultat, som loggas som standard i Application Insights. Egenskaperna Trigger Details för kan användas för att hitta och samla in ytterligare insikter om meddelanden som tas emot per PartitionId, Offsetoch SequenceNumber.

Exempelresultat av exempelfrågan:

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

Varning

Biblioteket för Azure Java Functions har för närvarande ett problem som förhindrar åtkomst till PartitionID och PartitionContext när du använder EventHubTrigger. Läs mer i den här GitHub-problemrapporten.

Spåra meddelandeflöde med ett transaktions-ID med Application Insights

I Application Insights kan vi visa all telemetri som är relaterad till en viss transaktion genom att göra en transaktionssökningsfråga på transaktionens Operation Id värde. Detta kan vara särskilt användbart för att samla in percentilvärden för genomsnittliga tider för meddelanden när transaktionen rör sig genom händelseströmspipelinen.

Följande skärmbild visar ett exempel på transaktionssökning i Application Insights-gränssnittet. Önskat Operation ID anges i frågefältet, identifieras med en förstoringsglasikon (och visas här i en röd ruta). Längst ned i huvudfönstret Results visas matchande händelser i sekventiell ordning på fliken. I varje händelsepost Operation ID markeras värdet i mörkblå för enkel verifiering.

En fråga som genereras för ett specifikt åtgärds-ID ser ut så här. Observera att Operation ID GUID anges i den tredje radens -sats where * has . Det här exemplet begränsar frågan ytterligare mellan två olika 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

Här är en skärmbild av hur frågan och dess matchande resultat kan se ut i Application Insights-gränssnittet:

Samla in anpassade mått från Azure Functions

.NET-funktioner

Strukturerad loggning används i .NET Azure-funktionerna för att samla in anpassade dimensioner i application insights-spårningstabellen. Dessa anpassade dimensioner kan sedan användas för att fråga efter data.

Här är till exempel loggutdraget i .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 resulterande loggarna som skapats i Application Insights innehåller parametrarna ovan som anpassade dimensioner, som du ser i den här skärmbilden:

Dessa loggar kan efterfrågas på följande sätt:

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)

Anteckning

För att se till att vi inte påverkar prestanda i de här testerna har vi aktiverat samplingsinställningarna för Azure-funktionsloggar för Application Insights med hjälp av host.json filen enligt nedan. Det innebär att all statistik som samlas in från loggning anses vara genomsnittliga värden och inte faktiska antal.

host.json-exempel:

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

Java-funktioner

För närvarande stöds inte strukturerad loggning i Java Azure-funktioner för att samla in anpassade dimensioner i spårningstabellen för Application Insights.

Här är till exempel loggutdraget i Java TransformingFunction:

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

De resulterande loggarna som skapats i Application Insights innehåller parametrarna ovan i meddelandet enligt nedan:

Dessa loggar kan efterfrågas på följande sätt:

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))

Anteckning

För att se till att vi inte påverkar prestanda i de här testerna har vi aktiverat samplingsinställningarna för Azure-funktionsloggar för Application Insights med hjälp av host.json filen enligt nedan. Det innebär att all statistik som samlas in från loggning anses vara genomsnittliga värden och inte faktiska antal.

host.json-exempel:

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

Deltagare

Den här artikeln underhålls av Microsoft. Den skrevs ursprungligen av följande deltagare.

Huvudförfattare:

• Rajasa Savant | Senior programvarutekniker

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Relaterade resurser

• Serverlös händelsebearbetning är en referensarkitektur som beskriver en typisk arkitektur av den här typen, med kodexempel och diskussion om viktiga överväganden.
• Av batchbearbetning och filtrering i serverlös händelsebearbetning med Event Hubs beskriver mer detaljerat hur dessa delar av referensarkitekturen fungerar.
• Scenario med privat länk i bearbetning av händelseströmmar är en lösningsidé för att implementera en liknande arkitektur i ett virtuellt nätverk (VNet) med privata slutpunkter för att förbättra säkerheten.
• Azure Kubernetes i händelseströmbearbetning beskriver en variant av en serverlös händelsedriven arkitektur som körs på Azure Kubernetes med KEDA-skalning.