Kiszolgáló nélküli eseményfeldolgozás monitorozása

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 a környezet holisztikus nézetének kialakításában, a korábbi trendek lekérésében, a különböző tényezők korrelációjában, valamint a teljesítmény, a fogyasztás vagy a hibaarány változásainak mérésében. 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 amikor az adott környezet szempontjából különös érdeklődésre számot tartó feltételek merülnek fel.

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

Feltételezések

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

• Az események Azure Event Hubs é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 elkezdhetnénk hasznos megállapításokat megfogalmazni az architektúráról. Minden erőforrás különböző feladatokat hajt végre, és ezáltal különböző metrikákat hoz létre.

Az Event Hubró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érések
• Szabályozott kérelmek
• Sikeres kérések
• 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, ezek a metrikák a Azure Functions é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
• Kérelmek
• 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érések aránya
• A Azure Functions által feldolgozott kérelmek aránya
• Eseményközpont teljes átviteli sebessége
• Felhasználói hibák
• A Azure Functions időtartama
• Végpontok közötti késés
• Késés minden fázisban
• Elveszett üzenetek száma
• A 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élyeznie 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 skálázá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 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, akkor az eseményközpontba történő streamelés lehetősége használható helyette.)

Megjegyzé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ákban jelenik meg egy nevű EntityNamedimenzióban. A Azure Portal egy adott eseményközpont adatai általában az Azure Monitor adott példányán tekinthetők meg. Ha azonban a metrikák adatait a rendszer a naplódiagnosztikára irányítja, az eseményközpontonkénti adatok jelenleg nem tekinthetők meg a EntityName dimenzióra való szűréssel.

Á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

Engedélyezheti, hogy az Application Insights metrikákat és egyéni telemetriákat rögzítsen Azure Functions. Ez lehetővé teszi, hogy a saját céljainak megfelelő elemzéseket definiáljon, és egy másik módot biztosítson a kiszolgáló nélküli eseményfeldolgozási forgatókönyv fontos elemzéseinek lekérésére.

Ez a képernyőkép az Application Insightsban található egyéni metrikák és telemetria példáját mutatja be:

Alapértelmezett egyéni metrikák

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

• 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 ILoggerhasználatával) 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[] az egyéni ILogger üzenet részeként van naplózva, az az Application Insightsban is elérhetővé válik. Ez nagyon hasznos lehet.

A kiszolgáló nélküli eseményfeldolgozási forgatókönyv esetében 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 a következőkkel SystemProperties együtt: x-opt-sequence-number, x-opt-offset, és x-opt-enqueued-time. Annak megállapításához, hogy az egyes üzenetek mikor érkeztek meg az Event Hubtól, a tulajdonságot használja a x-opt-enqueued-time rendszer.

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 mintalekérdezés az alábbi példaeredményhez hasonló üzenetet ad vissza, amelyet a rendszer alapértelmezés szerint naplóz az Application Insightsban. A tulajdonságok Trigger Details segítségével megkereshetők és rögzíthetők a fogadott üzenetekre vonatkozó további megállapítások a per PartitionId, , Offsetés SequenceNumber.

Példa a mintaleké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 és a PartitionID függvényhez való hozzáférést a PartitionContext használata során EventHubTrigger. További információ ebben a GitHub-problémajelentésben.

Üzenetfolyam nyomon követése tranzakcióazonosító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éről Operation Id . 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 a lekérdezésmezőbe írja be, amelyet egy nagyító ikonnal azonosít (és itt látható egy piros mezőben). A fő panel alján a Results lap 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 a következőhöz 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ő datetimesközött.

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éznek ki az Application Insights felületén:

Egyéni metrikák rögzítése Azure Functions

.NET-függvények

A .NET Azure-függvények strukturált naplózást használnak az Egyéni dimenziók rögzítéséhez 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 íme a naplóutasítás a .NET-ben 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);

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)

Megjegyzés

Annak érdekében, hogy meggyőződhessünk arról, hogy nem befolyásoljuk a tesztek teljesítményét, bekapcsoltuk az Application Insights azure-függvénynaplóinak mintavételezési beállításait az host.json alábbi 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 íme a Java TransformingFunctionnaplóutasítása:

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

Megjegyzés

Annak érdekében, hogy meggyőződhessünk arról, hogy nem befolyásoljuk a tesztek teljesítményét, bekapcsoltuk az Application Insights azure-függvénynaplóinak mintavételezési beállításait az host.json alábbi 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ó források (lehet, hogy a cikkek angol nyelvűek)

• 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.
• A kiszolgáló nélküli eseményfeldolgozásban az Event Hubs használatával végzett kötegelt törlés és szűrés részletesebben ismerteti a referenciaarchitektúra ezen részeinek működését.
• Az eseménystreamek feldolgozásának privát kapcsolati forgatókönyve megoldási ötlet egy hasonló architektúra privát végpontokkal rendelkező virtuális hálózaton (VNet) történő implementálásához a biztonság növelése érdekében.
• Az azure Kubernetes az eseménystreamek feldolgozásában egy kiszolgáló nélküli eseményvezérelt architektúra egy változatát ismerteti, amely az Azure Kubernetesen fut a KEDA-skálázóval.