Övervaka serverlös händelsebearbetning

Artikel
12/09/2021
7 minuter för att läsa

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

Övervakning ger inblick i systemets beteende och hälsotillstånd. Det hjälper dig att skapa en holistisk vy över miljön, hämta historiska trender, korrelera olika faktorer och mäta förä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 kvaliteten på din tjänst 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 hjälp Event Hubs och Azure Functions. Den beskriver användbara mått att övervaka, beskriver hur du integrerar med Application Insights och samlar in anpassade mått samt innehåller kodexempel.

Antaganden

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

Händelser tas emot Azure Event Hubs.
En funktionsapp utlöses för att hantera händelsen.
Azure Monitor är tillgänglig 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.

De här måtten från Event Hub är av intresse 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
Avbildade meddelanden
Inkommande byte
Utgående byte
Avbildade byte
Användarfel

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

Antal funktionskörningar
Anslutningar
Data i
Data ut
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 dataflöde för Händelsehubb
Användarfel
Varaktighet för Azure Functions
Svarstid från end-to-end
Svarstid i varje fas
Antal förlorade meddelanden
Antal meddelanden som bearbetats mer än en gång

För att säkerställa 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 önskas 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
AutoScaleLogs
KafkaCoordinatorLogs (för Apache Kafka arbetsbelastningar)
KafkaUserErrorLogs (för Apache Kafka arbetsbelastningar)
EventHubVNetConnectionEvent
AllMetrics

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

Anteckning

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

Den Event Hubs som anges i en Event Hubs namnrymd representeras i Azure Monitor mått under en dimension som kallas 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 går det för närvarande inte att visa data per händelsehubb genom att filtrera på EntityName dimensionen.

Som en tillfällig lösning kan du genom att skapa händelsehubbbar i olika namnrymder göra det möjligt att hitta mått för en specifik hubb.

Använda 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 Program Insights lagras anpassade mått 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 aggregerade medelvärden över 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 Function-koden (med hjälp av ILogger ) hämtas från application Insights tabellen. 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 Händelsehubben-meddelandet eller loggas som en del av det här anpassade meddelandet görs det EventData[] också tillgängligt i Application ILogger Insights. Detta kan vara mycket användbart.

I vårt serverlösa händelsebearbetningsscenario loggar vi den JSON-serialiserade meddelandetexten som tas emot från händelsehubben. På så sätt kan vi fånga den råa bytematrisen, SystemProperties tillsammans med som , och x-opt-sequence-numberx-opt-offsetx-opt-enqueued-time . Egenskapen används för att avgöra när varje meddelande togs emot av x-opt-enqueued-time händelsehubben.

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 för kan Trigger Details användas för att hitta och samla in ytterligare insikter om meddelanden som tas emot per , och PartitionIdOffsetSequenceNumber .

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 när du använder PartitionContextEventHubTrigger . Läs mer i den GitHub rapporten om problem.

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 köra en transaktionssökfrå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ömpipelinen.

Följande skärmbild visar ett exempel på en transaktionssökning i application Insights gränssnittet. Önskad anges i frågefältet, identifierad med en förstoringsglasikon (och visas här Operation ID som beskrivs i en röd ruta). Längst ned i huvudfönstret visar fliken Results matchande händelser i sekventiell ordning. I varje händelsepost Operation ID markeras värdet i mörkblått 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 tabellen Application Insights traces. Dessa anpassade dimensioner kan sedan användas för att köra frågor mot data.

Här är till exempel loggsatsen 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 skapades Insights Application Insights 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 prestandan 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 som visas nedan. Det innebär att all statistik som fångas 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 tabellen Application Insights traces.

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

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

De resulterande loggarna som skapades Insights Application Insights 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

host.json-exempel:

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

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.
Avbatchning och filtrering i serverlös händelsebearbetning med Event Hubs beskriver i detalj hur dessa delar av referensarkitekturen fungerar.
Privat länkscenario vid 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.

Övervaka serverlös händelsebearbetning

Betygsätta din upplevelse

Antaganden

Mått från Azure Monitor

Använda diagnostikloggning för att samla in insikter

Använda Insights

Anpassade standardmått

Anpassade meddelanden

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

Samla in anpassade mått från Azure Functions

.NET-funktioner

Java-funktioner

Relaterade resurser