Kiszolgáló nélküli eseményfeldolgozás figyelése

Ez a cikk útmutatást nyújt a kiszolgáló nélküli eseményvezérelt architektúrák monitorozásához.

A monitorozás betekintést nyújt a rendszerek viselkedésébe és állapotába. Segít holisztikus képet alkotni a környezetről, lekérni a korábbi trendeket, korrelálni a különböző tényezőket, és mérni a teljesítmény, a fogyasztás vagy a hibaarány változásait. A monitorozással riasztásokat határozhat meg, ha olyan feltételek lépnek fel, amelyek hatással lehetnek a szolgáltatás minőségére, vagy ha az adott környezet szempontjából különleges feltételek merülnek fel.

Ez a cikk bemutatja, hogy az Azure Monitor használatával monitorozza az Event Hubs és az Azure Functions használatával létrehozott kiszolgáló nélküli alkalmazásokat. Ismerteti a monitorozáshoz használható hasznos metrikákat, ismerteti az Application Insights integrálását és az egyéni metrikák rögzítését, valamint kódmintákat biztosít.

Feltételezések

Ez a cikk feltételezi, hogy a kiszolgáló nélküli eseményfeldolgozás referenciaarchitektúrájában ismertetett architektúrához hasonló architektúrával rendelkezik. Alapvetően:

• Az események az Azure Event Hubsba érkeznek.
• Egy függvényalkalmazás aktiválódik az esemény kezeléséhez.
• Az Azure Monitor az architektúrához használható.

Metrikák az Azure Monitorból

Először el kell döntenünk, hogy mely metrikákra lesz szükség, mielőtt hasznos megállapításokat kezdhetnénk az architektúráról. Minden erőforrás különböző feladatokat hajt végre, és különböző metrikákat hoz létre.

Az Event Hubból származó metrikák hasznosak lesznek a hasznos megállapítások rögzítéséhez:

• Bejövő kérések
• Kimenő kérelmek
• Szabályozott kérelmek
• Sikeres kérelmek
• Bejövő üzenetek
• Kimenő üzenetek
• Rögzített üzenetek
• Bejövő bájtok
• Kimenő bájtok
• Rögzített bájtok
• Felhasználói hibák

Hasonlóképpen, az Azure Functionsből származó metrikák érdekesek lesznek a hasznos megállapítások rögzítéséhez:

• Függvényvégrehajtások száma
• Kapcsolatok
• Adatok a következőben:
• Adatok ki
• HTTP-kiszolgáló hibái
• maximális száma
• Kérelmek az alkalmazássorban
• Válaszidő

Diagnosztikai naplózás használata az elemzések rögzítéséhez

Együtt elemezve a fenti metrikák a következő megállapítások megfogalmazására és rögzítésére használhatók:

• Az Event Hubs által feldolgozott kérelmek aránya
• Az Azure Functions által feldolgozott kérelmek aránya
• Az Event Hub teljes átviteli sebessége
• Felhasználói hibák
• Az Azure Functions időtartama
• Végpontok közötti késés
• Késés minden fázisban
• Elveszett üzenetek száma
• Többször feldolgozott üzenetek száma

Ahhoz, hogy az Event Hubs rögzítse a szükséges metrikákat, először engedélyezni kell a diagnosztikai naplókat (amelyek alapértelmezés szerint le vannak tiltva). Ezután ki kell jelölnünk a kívánt naplókat, és a megfelelő Log Analytics-munkaterületet kell konfigurálnunk célként.

Az általunk érintett napló- és metrikakategóriák a következők:

• OperationalLogs
• Automatikus méretezési naplók
• KafkaCoordinatorLogs (Apache Kafka számítási feladatokhoz)
• KafkaUserErrorLogs (Apache Kafka számítási feladatokhoz)
• EventHubVNetConnectionEvent
• AllMetrics

Az Azure dokumentációja útmutatást nyújt az Azure-eseményközpont diagnosztikai naplóinak beállításához. Az alábbi képernyőképen egy példa diagnosztikai beállítás konfigurációs panelje látható, amelyen a megfelelő napló- és metrikakategóriák, valamint egy Log Analytics-munkaterület van beállítva célként. (Ha külső rendszert használ a naplók elemzéséhez, a Az eseményközpontba való streamelés használható helyette.)

Feljegyzés

Ahhoz, hogy naplódiagnosztikát használjon az elemzések rögzítéséhez, különböző névterekben kell eseményközpontokat létrehoznia. Ennek oka egy Azure-beli korlátozás.

Az adott Event Hubs-névtérben beállított Event Hubs az Azure Monitor metrikáiban, egy úgynevezett EntityNamedimenzióban jelenik meg. Az Azure Portalon egy adott eseményközpont adatai általában az Azure Monitor adott példányán tekinthetők meg. Ha azonban a metrikák adatai a naplódiagnosztikához vannak irányítva, az eseményközpontonkénti adatok jelenleg nem tekinthetők meg a EntityName dimenzió szűrésével.

Áthidaló megoldásként az eseményközpontok különböző névterekben való létrehozása lehetővé teszi egy adott központ metrikáinak megkeresését.

Az Application Insights használata

Az Application Insights lehetővé teszi metrikák és egyéni telemetriák rögzítését az Azure Functionsből. Ez lehetővé teszi, hogy a saját céljainak megfelelő elemzéseket határozzon meg, így más módon is fontos elemzéseket kaphat a kiszolgáló nélküli eseményfeldolgozási forgatókönyvhöz.

Ez a képernyőkép az Application Insights egyéni metrikáira és telemetriáira mutat be példát:

Alapértelmezett egyéni metrikák

Az Application Insightsban az Azure Functions egyéni metrikái a customMetrics táblában vannak tárolva. A következő értékeket tartalmazza, különböző függvénypéldányok idősorán át:

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

Ezek a metrikák a futtatás során meghívott több függvénypéldány összesített átlagainak hatékony kiszámítására használhatók.

Ez a képernyőkép bemutatja, hogyan néznek ki ezek az alapértelmezett egyéni metrikák az Application Insightsban:

Egyéni üzenetek

Az Azure-függvénykódban (a ILogger) naplózott egyéni üzenetek az Application Insights traces táblából származnak.

A traces táblázat a következő fontos tulajdonságokkal rendelkezik (többek között):

• timestamp
• cloud_RoleInstance
• operation_Id
• operation_Name
• message

Íme egy példa arra, hogyan nézhet ki egy egyéni üzenet az Application Insights felületén:

Ha a bejövő Event Hub-üzenet vagy EventData[] ennek az egyéni ILogger üzenetnek a részeként van naplózva, akkor az az Application Insightsban is elérhetővé válik. Ez nagyon hasznos lehet.

Kiszolgáló nélküli eseményfeldolgozási forgatókönyvünkben naplózzuk az eseményközponttól kapott JSON szerializált üzenettörzset. Ez lehetővé teszi a nyers bájttömb rögzítését, valamint SystemProperties a hasonló x-opt-sequence-number, x-opt-offsetés x-opt-enqueued-time. Annak meghatározásához, hogy az eseményközpont mikor kapta meg az egyes üzeneteket, a rendszer a x-opt-enqueued-time tulajdonságot használja.

Mintalekérdezés:

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

A minta lekérdezés a következő példaeredményhez hasonló üzenetet ad vissza, amelyet alapértelmezés szerint naplóz az Application Insights. A tulajdonságok segítségével Trigger Details további elemzéseket kereshet és rögzíthet a fogadott PartitionIdüzenetekről. OffsetSequenceNumber

Példa a minta lekérdezés eredményére:

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

Figyelmeztetés

Az Azure Java Functions kódtára jelenleg olyan problémával rendelkezik, amely megakadályozza a hozzáférését a használathoz és a PartitionIDPartitionContext használathoz EventHubTrigger. További információ ebben a GitHub-problémajelentésben.

Üzenetfolyam nyomon követése tranzakcióazonosító használatával az Application Insights használatával

Az Application Insightsban megtekintheti az adott tranzakcióhoz kapcsolódó összes telemetriát, ha tranzakciókeresési lekérdezést végez a tranzakció értékére Operation Id vonatkozóan. Ez különösen hasznos lehet az üzenetek átlagos idejének percentilis értékeinek rögzítéséhez, amikor a tranzakció áthalad az eseményfolyam-folyamaton.

Az alábbi képernyőképen egy példa tranzakciókeresés látható az Application Insights felületén. A kívánt Operation ID értéket egy nagyító ikonnal azonosított lekérdezési mezőbe írja be (és itt egy piros mezőben látható). A fő panel alján a Results tabulátor egymást követő sorrendben jeleníti meg az egyező eseményeket. Minden eseménybejegyzésben az Operation ID érték sötétkék színnel van kiemelve az egyszerű ellenőrzés érdekében.

Egy adott műveletazonosítóhoz létrehozott lekérdezés az alábbihoz hasonlóan fog kinézni. Vegye figyelembe, hogy a Operation ID GUID a harmadik sor záradékában where * has van megadva. Ez a példa tovább szűkíti a lekérdezést két különböző 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

Íme egy képernyőkép arról, hogy a lekérdezés és annak egyező eredményei hogyan nézhetnek ki az Application Insights felületén:

Egyéni metrikák rögzítése az Azure Functionsből

.NET-függvények

A strukturált naplózás a .NET Azure-függvényekben egyéni dimenziók rögzítésére szolgál az Application Insights nyomkövetési táblájában. Ezek az egyéni dimenziók ezután felhasználhatók az adatok lekérdezéséhez.

Példaként a .NET TransformingFunctionnaplóutasítását mutatjuk be:

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

Az Application Insightsban létrehozott naplók a fenti paramétereket egyéni dimenziókként tartalmazzák, ahogyan az a képernyőképen látható:

Ezek a naplók az alábbiak szerint kérdezhetők le:

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)

Feljegyzés

Annak érdekében, hogy a tesztek során ne legyen hatással a teljesítményre, bekapcsoltuk az Application Insights azure-függvénynaplóinak mintavételezési beállításait az host.json alább látható fájl használatával. Ez azt jelenti, hogy a naplózásból rögzített összes statisztika átlagértéknek minősül, nem pedig tényleges számnak.

host.json példa:

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

Java-függvények

A Strukturált naplózás jelenleg nem támogatott a Java Azure-függvényekben egyéni dimenziók rögzítéséhez az Application Insights nyomkövetési táblájában.

Példaként a Java TransformingFunctionnaplóutasítását mutatjuk be:

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

Az Application Insightsban létrehozott naplók az alábbi módon tartalmazzák a fenti paramétereket az üzenetben:

Ezek a naplók az alábbiak szerint kérdezhetők le:

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

Feljegyzés

Annak érdekében, hogy a tesztek során ne legyen hatással a teljesítményre, bekapcsoltuk az Application Insights azure-függvénynaplóinak mintavételezési beállításait az host.json alább látható fájl használatával. Ez azt jelenti, hogy a naplózásból rögzített összes statisztika átlagértéknek minősül, nem pedig tényleges számnak.

host.json példa:

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

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

• Rajasa Savant | Vezető szoftvermérnök

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Kapcsolódó erőforrások

• A kiszolgáló nélküli eseményfeldolgozás egy referenciaarchitektúra, amely egy ilyen típusú tipikus architektúrát részletez, kódmintákkal és fontos szempontok megvitatásával.
• Az eseményfolyam-feldolgozás privát kapcsolati forgatókönyve megoldási ötlet egy hasonló architektúra implementálására egy virtuális hálózaton (VNet) privát végpontokkal a biztonság növelése érdekében.
• Az Azure Kubernetes az eseményfolyam-feldolgozásban az Azure Kubernetesben a KEDA-skálázóval futó kiszolgáló nélküli eseményvezérelt architektúra egy változata.