Monitorování zpracování událostí bez serveru

Tento článek poskytuje pokyny pro monitorování architektury řízených událostmi bez serveru .

Monitorování nabízí přehled o chování a stavu vašich systémů. Pomáhá vytvářet holistický zobrazení prostředí, získávat historické trendy, sladit různé faktory a měřit změny v oblasti výkonu, spotřeby nebo míry chyb. Monitorování můžete použít k definování výstrah v případě, že dojde ke splnění podmínek, které by mohly ovlivnit kvalitu vaší služby, nebo když vznikne stav zvláštního zájmu na konkrétní prostředí.

Tento článek ukazuje použití Azure monitor k monitorování aplikace bez serveru vytvořené pomocí Event Hubs a Azure Functions. popisuje užitečné metriky, které je potřeba monitorovat, popisuje, jak integrovat s Application Insights a zachytit vlastní metriky a poskytuje ukázky kódu.

Předpoklady

V tomto článku se předpokládá, že máte architekturu, která je popsaná v referenční architektuře zpracování událostí bez serveru. V podstatě

• Události přicházejí do Azure Event Hubs.
• Pro zpracování události se aktivuje Function App.
• Azure Monitor je k dispozici pro použití s vaší architekturou.

Metriky z Azure Monitor

Nejdřív musíme rozhodnout, jaké metriky budete potřebovat, aby bylo možné začít formulovat užitečné poznatky o architektuře. Každý prostředek provádí různé úlohy a zase generuje různé metriky.

Tyto metriky z centra událostí budou zajímat užitečné poznatky:

• Příchozí žádosti
• Odchozí požadavky
• Omezené žádosti
• Úspěšné požadavky
• Příchozí zprávy
• Odchozí zprávy
• Zachycené zprávy
• Příchozí bajty
• Odchozí bajty
• Zachycené bajty
• Chyby uživatele

Podobně budou tyto metriky z Azure Functions zajímat užitečné poznatky:

• Počet spuštění funkce
• Připojení
• Data v
• Výstupní data
• Chyby serveru HTTP
• Žádosti
• Žádosti ve frontě aplikací
• Doba odezvy

Shromažďování přehledů pomocí diagnostického protokolování

Při analýze můžete pomocí výše uvedených metrik formulovat a zachytit následující přehledy:

• Frekvence požadavků zpracovaných pomocí Event Hubs
• Frekvence požadavků zpracovaných pomocí Azure Functions
• Celková propustnost centra událostí
• Chyby uživatele
• Trvání Azure Functions
• Koncová latence
• Latence v každé fázi
• Počet ztracených zpráv
• Počet zpracovaných zpráv více než jednou

Abychom zajistili, že Event Hubs zachycuje potřebné metriky, je potřeba nejdřív povolit diagnostické protokoly (které jsou ve výchozím nastavení zakázané). Pak je nutné vybrat, které protokoly jsou požadované, a nakonfigurovat pro ně správný Log Analytics pracovní prostor.

Kategorie protokolů a metrik, které vás zajímá, jsou:

• OperationalLogs
• AutoScaleLogs
• KafkaCoordinatorLogs (pro úlohy Apache Kafka)
• KafkaUserErrorLogs (pro úlohy Apache Kafka)
• EventHubVNetConnectionEvent
• AllMetrics

Dokumentace k Azure poskytuje pokyny, jak nastavit protokoly diagnostiky pro centrum událostí Azure. Následující snímek obrazovky ukazuje příklad konfiguračního panelu nastavení diagnostiky se správnými vybranými kategoriemi protokolů a metrik a Log Analytics pracovní prostor nastavený jako cíl. (Pokud se k analýze protokolů používá externí systém, můžete místo toho použít možnost streamování do centra událostí .)

použití Application Insights

můžete povolit Application Insights zachytávání metrik a vlastní telemetrie z Azure Functions. To vám umožní definovat analýzy, které odpovídají vašim potřebám, a zajistit tak další způsob, jak získat důležité poznatky pro scénář zpracování událostí bez serveru.

tento snímek obrazovky ukazuje příklad seznamu vlastních metrik a telemetrie v rámci Application Insights:

Výchozí vlastní metriky

v Application Insights jsou v tabulce uloženy vlastní metriky pro Azure Functions customMetrics . Zahrnuje následující hodnoty, které jsou rozloženy na časovou osu pro různé instance funkcí:

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

Tyto metriky lze použít k efektivnímu výpočtu agregovaných průměrů napříč instancemi více funkcí, které jsou vyvolány v běhu.

tento snímek obrazovky ukazuje, jak tyto výchozí vlastní metriky vypadají při zobrazení v Application Insights:

Vlastní zprávy

vlastní zprávy zaznamenané v kódu funkce Azure (pomocí ILogger ) se získávají z Application Insightsové traces tabulky.

tracesTabulka má následující důležité vlastnosti (mimo jiné):

• timestamp
• cloud_RoleInstance
• operation_Id
• operation_Name
• message

tady je příklad toho, jak může vypadat vlastní zpráva v rozhraní Application Insights:

pokud je zpráva centra příchozích událostí nebo EventData[] zaprotokolována jako součást této vlastní ILogger zprávy, bude také zpřístupněna v Application Insights. To může být velmi užitečné.

U našich scénářů zpracování událostí bez serveru se protokoluje text zprávy serializovaného ve formátu JSON, který je přijatý z centra událostí. Díky tomu můžeme zachytit nezpracované pole bajtů společně s SystemProperties jako x-opt-sequence-number , x-opt-offset a x-opt-enqueued-time . Tato vlastnost slouží k určení, kdy byla každá zpráva přijata centrem událostí x-opt-enqueued-time .

Vzorový dotaz:

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

vzorový dotaz by vrátil zprávu podobnou následujícímu příkladu výsledku, který se ve výchozím nastavení protokoluje ve Application Insights. Vlastnosti nástroje Trigger Details lze použít k vyhledání a zachycení dalších přehledů o zprávách přijatých na PartitionId , Offset a SequenceNumber .

Příklad výsledku ukázkového dotazu:

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

sledování toku zpráv pomocí ID transakce s Application Insights

v Application Insights můžeme zobrazit veškerou telemetrii týkající se konkrétní transakce provedením dotazu na transakční dotaz na Operation Id hodnotu transakce. To může být zvláště užitečné pro zachycení hodnot percentilu v průměru pro zprávy, protože transakce se přesouvá přes kanál streamování událostí.

následující snímek obrazovky ukazuje příklad hledání transakcí v rozhraní Application Insights. Požadovaná hodnota se zadá do pole dotazu, která je označená ikonou lupy (a je zde Operation ID uvedená v červeném rámečku). V dolní části hlavního podokna se na Results kartě zobrazují odpovídající události v sekvenčním pořadí. V každé položce události je hodnota kvůli snadnému ověření zvýrazněná tmavě modrou Operation ID modře.

Dotaz vygenerovaný pro konkrétní ID operace bude vypadat následovně. Všimněte Operation ID si, že identifikátor GUID je zadaný v klauzuli třetího where * has řádku. Tento příklad dále zúží dotaz mezi dvěma různými 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

Tady je snímek obrazovky s tím, jak může dotaz a jeho odpovídající výsledky v rozhraní Application Přehledy vypadat:

Zachytávání vlastních metrik z Azure Functions

Funkce .NET

Strukturované protokolování se používá ve funkcích Azure .NET k zachytávání vlastních dimenzí v tabulce application Přehledy traces. Tyto vlastní dimenze je pak možné použít k dotazování dat.

Tady je příklad příkazu log v rozhraní TransformingFunction .NET:

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

Výsledné protokoly vytvořené v aplikačním Přehledy obsahují výše uvedené parametry jako vlastní dimenze, jak je znázorněno na tomto snímku obrazovky:

Na tyto protokoly se můžete dotazovat takto:

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.jspříkladu:

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

Funkce Jazyka Java

V současné době není strukturované protokolování podporováno ve funkcích Azure v Javě pro zachytávání vlastních dimenzí v tabulce Application Přehledy traces.

Tady je příklad příkazu log v TransformingFunction Javě:

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

Výsledné protokoly vytvořené v aplikačním Přehledy ve zprávě obsahují výše uvedené parametry, jak je znázorněno níže:

Na tyto protokoly se můžete dotazovat takto:

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.jspříkladu:

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

Související prostředky

• Zpracování událostí bez serveru je referenční architektura, která podrobně popisuje typickou architekturu tohoto typu. Obsahuje ukázky kódu a diskusi o důležitých aspektech.
• Podrobnější popis toho, jak tyto části referenční architektury fungují, Event Hubs bez serveru při zpracování událostí bez serveru.
• Scénář privátního propojení při zpracování datových proudů událostí je řešením pro implementaci podobné architektury ve virtuální síti s privátními koncovými body, aby se zvýšilo zabezpečení.
• Azure Kubernetes ve zpracování datových proudů událostí popisuje variantu architektury bez serveru řízené událostmi běžící v Azure Kubernetes se škálovatérem KEDA.