Megosztás a következőn keresztül:

Az Azure Service Fabric monitorozása és diagnosztikái

  • Cikk

Ez a cikk áttekintést nyújt az Azure Service Fabric monitorozásáról és diagnosztikáiról. A monitorozás és a diagnosztika kritikus fontosságú a számítási feladatok fejlesztéséhez, teszteléséhez és üzembe helyezéséhez bármely felhőkörnyezetben. Nyomon követheti például az alkalmazások használatát, a Service Fabric platform által végrehajtott műveleteket, az erőforrás-kihasználtságot teljesítményszámlálókkal, valamint a fürt általános állapotát. Ezekkel az információkkal diagnosztizálhatja és kijavíthatja a problémákat, és megakadályozhatja, hogy a jövőben bekövetkezhessenek. A következő néhány szakasz röviden ismerteti a Service Fabric monitorozásának egyes területeit, amelyeket figyelembe kell venni az éles számítási feladatok esetében.

Feljegyzés

Ez a cikk nemrég frissült, hogy a Log Analytics helyett az Azure Monitor-naplók kifejezést használja. A naplóadatok továbbra is egy Log Analytics-munkaterületen lesznek tárolva, és ugyanazon Log Analytics-szolgáltatás gyűjti és elemzi őket. Frissítjük a terminológiát, hogy jobban tükrözzük a naplók szerepét az Azure Monitorban. Részletekért tekintse meg az Azure Monitor terminológiájának változásait .

Alkalmazásmonitorozás

Az alkalmazásfigyelés nyomon követi az alkalmazás funkcióinak és összetevőinek használatát. Figyelnie kell az alkalmazásokat, hogy a felhasználókat érintő problémákat is megfigyelje. Az alkalmazásfigyelés felelőssége az alkalmazás és szolgáltatásai fejlesztésének felhasználóira hárul, mivel ez egyedi az alkalmazás üzleti logikája szerint. Az alkalmazások monitorozása az alábbi esetekben lehet hasznos:

  • Mekkora forgalmat tapasztal az alkalmazásom? – Skáláznia kell a szolgáltatásokat a felhasználói igényeknek megfelelően, vagy kezelnie kell az alkalmazás esetleges szűk keresztmetszeteit?
  • Sikeresek és nyomon követhetők a szolgáltatáshívások?
  • Milyen műveleteket hajtanak végre az alkalmazás felhasználói? – A telemetriai adatok gyűjtése segíthet a jövőbeli funkciók fejlesztésében és az alkalmazáshibák jobb diagnosztikában
  • Az alkalmazás nem kezelt kivételeket ad ki?
  • Mi történik a tárolókon belül futó szolgáltatásokban?

Az alkalmazásfigyelésben az a nagyszerű, hogy a fejlesztők bármilyen eszközt és keretrendszert használhatnak, mivel az az alkalmazás környezetében található! Az Azure Monitor Application Insights alkalmazásmonitorozási megoldásával kapcsolatos további információk az Application Insights eseményelemzésében. A .NET-alkalmazásokhoz is van egy oktatóanyag, amely bemutatja, hogyan állíthatja be ezt a beállítást. Ez az oktatóanyag bemutatja, hogyan telepítheti a megfelelő eszközöket, hogyan írhat egyéni telemetriát az alkalmazásba, és hogyan tekintheti meg az alkalmazásdiagnosztikát és a telemetriát az Azure Portalon.

Platform (fürt) monitorozása

A felhasználó szabályozza, hogy milyen telemetriai adatok származnak az alkalmazásból, mivel egy felhasználó maga írja a kódot, de mi a helyzet a Service Fabric platform diagnosztikai adataival? A Service Fabric egyik célja, hogy az alkalmazásokat ellenállóvá tegye a hardverhibákkal szemben. Ez a cél úgy érhető el, hogy a platform rendszerszolgáltatásai képesek észlelni az infrastruktúrával kapcsolatos problémákat és gyorsan feladatátvételi számítási feladatokat a fürt más csomópontjaira. De ebben a konkrét esetben mi történik, ha maguk a rendszerszolgáltatások problémákat tapasztalnak? Vagy ha számítási feladat üzembe helyezésére vagy áthelyezésére próbál meg kísérletet tenni, a szolgáltatások elhelyezésére vonatkozó szabályok sérülnek? A Service Fabric diagnosztikát biztosít ezekhez és egyebekhez, hogy biztosan értesüljön a fürtben zajló tevékenységekről. A fürtfigyelés néhány példaforgatókönyve:

A Service Fabric átfogó eseménykészletet biztosít a dobozon kívül. Ezek a Service Fabric-események az EventStore-on vagy az operatív csatornán (a platform által közzétett eseménycsatornán) keresztül érhetők el.

  • Service Fabric-eseménycsatornák – Windows rendszeren a Service Fabric-események egyetlen ETW-szolgáltatótól érhetők el, és az operatív és az adat- és üzenetkezelési csatornák közötti választáshoz szükséges releváns logLevelKeywordFilters halmazt használják – így választjuk el a kimenő Service Fabric-eseményeket, amelyekre szükség szerint szűrni kell. Linux rendszeren a Service Fabric-események ltTngen keresztül érkeznek, és egy Storage-táblába kerülnek, ahonnan szükség szerint szűrhetők. Ezek a csatornák válogatott, strukturált eseményeket tartalmaznak, amelyek a fürt állapotának jobb megértésére használhatók. A diagnosztika alapértelmezés szerint engedélyezve van a fürtlétrehozáskor, amely létrehoz egy Azure Storage-táblát, amelyben a csatornák eseményei a jövőben lekérdezésre kerülnek.

  • EventStore – Az EventStore a platform által kínált szolgáltatás, amely Service Fabric-platformeseményeket biztosít a Service Fabric Explorerben és a REST API-ban. Pillanatképet láthat arról, hogy mi történik a fürtben az egyes entitások, például csomópontok, szolgáltatások, alkalmazások és lekérdezések esetében az esemény időpontja alapján. Az EventStore-ról az EventStore áttekintésében is olvashat bővebben.

Képernyőkép a Csomópontok panel ESEMÉNYEK lapjának több eseményéről, köztük egy NodeDown-eseményről.

A megadott diagnosztikák a dobozon kívüli események átfogó készlete formájában vannak megadva. Ezek a Service Fabric-események a platform által különböző entitásokon, például csomópontokon, alkalmazásokon, szolgáltatásokon, partíciókon végzett műveleteket szemléltetik. A fenti utolsó forgatókönyvben, ha egy csomópont leállna, a platform eseményt NodeDown bocsátana ki, és a választott monitorozási eszköz azonnal értesítené Önt. Egyéb gyakori példák lehetnek például ApplicationUpgradeRollbackStarted a feladatátvétel során vagy PartitionReconfigured közben. Ugyanezek az események windowsos és linuxos fürtökön is elérhetők.

Az eseményeket windowsos és linuxos standard csatornákon keresztül küldi el a rendszer, és bármely olyan monitorozási eszköz képes olvasni, amely támogatja ezeket. Az Azure Monitor-megoldás az Azure Monitor-naplók. Nyugodtan olvassa el az Azure Monitor-naplók integrációját, amely tartalmaz egy egyéni működési irányítópultot a fürthöz, valamint néhány minta lekérdezést, amelyekből riasztásokat hozhat létre. További fürtfigyelési fogalmak érhetők el platformszintű esemény- és naplógeneráláskor.

Állapotfigyelés

A Service Fabric platform tartalmaz egy állapotmodellt, amely bővíthető állapotjelentést biztosít egy fürt entitásainak állapotáról. Minden csomópont, alkalmazás, szolgáltatás, partíció, replika vagy példány folyamatosan frissíthető állapottal rendelkezik. Az állapot lehet "OK", "Figyelmeztetés" vagy "Hiba". A Service Fabric-eseményeket úgy tekintheti, mint a fürt által a különböző entitásokra és az állapotra vonatkozó igéket, mint az egyes entitások melléknevét. Minden alkalommal, amikor egy adott entitás állapota áttűn, egy esemény is ki lesz bocsátva. Így lekérdezéseket és riasztásokat állíthat be az állapoteseményekhez a választott monitorozási eszközben, ugyanúgy, mint bármely más esemény esetében.

Emellett lehetővé tesszük, hogy a felhasználók felülbírálják az entitások állapotát. Ha az alkalmazás frissítésen megy keresztül, és az érvényesítési tesztek sikertelenek, a Health API-val írhat a Service Fabric Health szolgáltatásba, hogy jelezze, hogy az alkalmazás már nem kifogástalan állapotú, és a Service Fabric automatikusan visszaállítja a frissítést! Az állapotmodellről bővebben a Service Fabric állapotmonitorozásának bemutatása

SFX állapot irányítópult

Watchdogs

A watchdog általában egy különálló szolgáltatás, amely figyeli az állapotot és a terhelést a szolgáltatások között, pingeli a végpontokat, és váratlan állapoteseményeket jelent a fürtben. Ez segíthet megelőzni azokat a hibákat, amelyek nem csak egyetlen szolgáltatás teljesítménye alapján észlelhetők. A watchdogok olyan kódot is üzemeltetnek, amely olyan javító műveleteket hajt végre, amelyek nem igényelnek felhasználói beavatkozást, például a naplófájlok bizonyos időközönként történő megtisztítása a tárolóban. Ha teljesen implementált, nyílt forráskód SF watchdog szolgáltatást, amely egy könnyen használható watchdog bővíthetőségi modellt tartalmaz, és amely Windows és Linux fürtökön is fut, tekintse meg a FabricObserver projektet. A FabricObserver éles üzemre kész szoftver. Javasoljuk, hogy telepítse a FabricObservert a teszt- és éles fürtökre, és bővítse ki az igényeinek megfelelően a beépülő modulmodellen keresztül, vagy elágaztatással és saját beépített megfigyelők írásával. Az előbbi (beépülő modulok) az ajánlott megközelítés.

Infrastruktúra (teljesítmény) monitorozása

Most, hogy áttekintettük az alkalmazás és a platform diagnosztikáit, honnan tudjuk, hogy a hardver a várt módon működik? A mögöttes infrastruktúra monitorozása kulcsfontosságú része a fürt állapotának és az erőforrás-kihasználtságnak. A rendszer teljesítményének mérése számos tényezőtől függ, amelyek a számítási feladatoktól függően szubjektívek lehetnek. Ezeket a tényezőket általában teljesítményszámlálókkal mérik. Ezek a teljesítményszámlálók számos forrásból származhatnak, beleértve az operációs rendszert, a .NET-keretrendszert vagy magát a Service Fabric-platformot. Egyes forgatókönyvek, amelyekben hasznosak lennének,

  • Hatékonyan használom a hardveremet? Szeretné használni a hardvert 90%-os processzor- vagy 10%-os cpu-n. Ez hasznos lehet a fürt skálázása vagy az alkalmazás folyamatainak optimalizálása során.
  • Előre jelezhetem az infrastruktúra problémáit proaktív módon? - számos problémát megelőz a teljesítmény hirtelen változása (csökkenése), így a teljesítményszámlálók, például a hálózati I/O és a CPU-kihasználtság használatával proaktív módon jelezheti előre és diagnosztizálhatja a problémákat.

Az infrastruktúra szintjén összegyűjtendő teljesítményszámlálók listája a Teljesítménymetrikákban található.

A Service Fabric teljesítményszámlálókat is biztosít a Reliable Services és az Actors programozási modellekhez. Ha ezek közül a modellek közül bármelyiket használja, ezek a teljesítményszámlálók információt adhatnak arról, hogy a szereplők megfelelően pörögnek fel és le, vagy hogy a megbízható szolgáltatáskéréseket elég gyorsan kezelik. További információ: Monitoring for Reliable Service Remoting and Performance Monitoring for Reliable Actors.

Ezek gyűjtésére az Azure Monitor-megoldás az Azure Monitor-naplók, ugyanúgy, mint a platformszintű monitorozás. A Log Analytics-ügynökkel gyűjtse össze a megfelelő teljesítményszámlálókat, és tekintse meg őket az Azure Monitor-naplókban.

Most, hogy áttekintettük a figyelési és példaforgatókönyvek egyes területeit, íme az Azure monitorozási eszközeinek összegzése, és a fenti területek monitorozásához szükséges beállítás.

  • Alkalmazásfigyelés az Application Insights használatával
  • Fürtfigyelés diagnosztikai ügynökkel és Azure Monitor-naplókkal
  • Infrastruktúra monitorozása Azure Monitor-naplókkal

Az itt található ARM-mintasablon használatával és módosításával automatizálhatja az összes szükséges erőforrás és ügynök üzembe helyezését.

Egyéb naplózási megoldások

Bár az általunk javasolt két megoldás, az Azure Monitor-naplók és az Application Insights a Service Fabricbe integrálódtak, számos eseményt ETW-szolgáltatók írnak ki, és bővíthetők más naplózási megoldásokkal. Az Elastic Stacket is meg kell vizsgálnia (különösen akkor, ha egy fürtöt offline környezetben szeretne futtatni), a Dynatrace-et vagy bármely más, ön által előnyben részesített platformot. Az integrált partnerek listája itt érhető el.

A választott platformok legfontosabb pontjai közé tartozik a felhasználói felület, a lekérdezési képességek, az elérhető egyéni vizualizációk és irányítópultok, valamint a monitorozási élmény fokozása érdekében biztosított további eszközök.

Következő lépések