Egyéni Service Fabric-állapotjelentések hozzáadása
Az Azure Service Fabric egy állapotmodellt vezet be, amelynek célja a nem megfelelő fürt és alkalmazásfeltételek megjelölése adott entitásokon. Az állapotmodell állapot-riportereket (rendszerösszetevőket és figyelőket) használ. A cél egyszerű és gyors diagnosztika és javítás. A szolgáltatásíróknak előre kell gondolniuk az egészségre. Minden olyan feltételt, amely hatással lehet az állapotra, jelenteni kell, különösen akkor, ha segíthet megjelölni a gyökérhöz közeli problémákat. Az állapotinformációk időt és energiát takaríthatnak meg a hibakeresés és a vizsgálat során. A hasznosság különösen akkor egyértelmű, ha a szolgáltatás nagy léptékben működik a felhőben (privát vagy Azure).
A Service Fabric-riporterek figyelik az azonosított feltételeket. Ezekről a feltételekről a helyi nézetük alapján számolnak be. Az állapottár összesíti az összes riporter által küldött állapotadatokat annak megállapításához, hogy az entitások globálisan kifogástalan állapotban vannak-e. A modell gazdag, rugalmas és könnyen használható. Az állapotjelentések minősége határozza meg a fürt állapotnézetének pontosságát. A tévesen kifogástalan állapotú problémákat mutató hamis pozitív értékek negatív hatással lehetnek a frissítésekre vagy az állapotadatokat használó egyéb szolgáltatásokra. Ilyen szolgáltatások például a javítási szolgáltatások és a riasztási mechanizmusok. Ezért némi gondolkodásra van szükség ahhoz, hogy olyan jelentéseket nyújtsunk, amelyek a lehető legjobban rögzítik az érdeklődési feltételeket.
Az állapotjelentések tervezéséhez és implementálásához a watchdogoknak és a rendszerösszetevőknek a következőkkel kell rendelkeznie:
- Határozza meg az őket érdeklő feltételt, a figyelés módját, valamint a fürt vagy az alkalmazás funkcióira gyakorolt hatást. Ezen információk alapján döntse el az állapotjelentés tulajdonságát és állapotát.
- Határozza meg azt az entitást , amelyre a jelentés vonatkozik.
- Határozza meg a jelentéskészítés helyét a szolgáltatáson belülről, vagy egy belső vagy külső figyelőből.
- Adjon meg egy forrást, amely a riporter azonosítására szolgál.
- Válasszon jelentéskészítési stratégiát rendszeres időközönként vagy áttűnések esetén. Az ajánlott módszer rendszeres, mivel egyszerűbb kódot igényel, és kevésbé hajlamos a hibákra.
- Határozza meg, hogy a nem megfelelő állapotú állapotok jelentésének mennyi ideig kell az állapottárolóban maradnia, és hogy hogyan kell törölni. Ezen információk alapján döntse el a jelentés élettartamát és a lejárat utáni viselkedés eltávolítását.
Amint már említettük, a jelentéskészítés a következő forrásból végezhető el:
- A figyelt Service Fabric szolgáltatásreplika.
- Service Fabric-szolgáltatásként üzembe helyezett belső watchdogok (például állapot nélküli Service Fabric-szolgáltatás, amely figyeli a feltételeket és jelentéseket ad ki). A watchdogok üzembe helyezhetők az összes csomóponton, vagy affinithatók a figyelt szolgáltatáshoz.
- A Service Fabric-csomópontokon futó, de Service Fabric-szolgáltatásként nem implementált belső watchdogok.
- Külső watchdogok, amelyek a Service Fabric-fürtön kívülről szondázják az erőforrást (például figyelési szolgáltatás, például Gomez).
Feljegyzés
A fürtöt a rendszerösszetevők által küldött állapotjelentések töltik ki. További információ: Rendszerállapot-jelentések használata hibaelhárításhoz. A felhasználói jelentéseket olyan állapotentitásokon kell elküldeni, amelyeket a rendszer már létrehozott.
Ha az állapotjelentések tervezése egyértelmű, az állapotjelentések egyszerűen elküldhetők. A FabricClient használatával jelentheti az állapotot, ha a fürt nem biztonságos, vagy ha a hálóügyfél rendszergazdai jogosultságokkal rendelkezik. A jelentéskészítés az API-val végezhető el a FabricClient.HealthManager.ReportHealth, a PowerShell vagy a REST használatával. A konfigurációs gombok kötegjelentései a jobb teljesítmény érdekében.
Feljegyzés
A jelentés állapota szinkron, és csak az ügyféloldali ellenőrzési munkát jelöli. Az a tény, hogy az állapotügyfél vagy az Partition CodePackageActivationContext objektumok elfogadják a jelentést, nem jelenti azt, hogy az áruházban lesz alkalmazva. A rendszer aszinkron módon küldi el, és lehetséges, hogy más jelentésekkel kötegelve van. A kiszolgálón a feldolgozás továbbra is sikertelen lehet: a sorszám elavult lehet, az entitás, amelyre a jelentést alkalmazni kell, törölve lett stb.
Állapotügyfél
Az állapotjelentéseket a rendszer egy állapotügyfélen keresztül küldi el az állapotkezelőnek, amely a hálóügyfélben található. Az állapotkezelő a jelentéseket az állapottárba menti. Az állapotügyfél a következő beállításokkal konfigurálható:
- HealthReportSendInterval: A jelentés ügyfélhez való hozzáadása és az állapotkezelőnek küldött idő közötti késés. A jelentések egyetlen üzenetbe való kötegelésére szolgál, ahelyett, hogy minden jelentéshez egy üzenetet küldene. A kötegelés javítja a teljesítményt. Alapértelmezett: 30 másodperc.
- HealthReportRetrySendInterval: Az az időköz, amikor az állapotügyfél újra elküldi a halmozott állapotjelentéseket az állapotkezelőnek. Alapértelmezett: 30 másodperc, minimum: 1 másodperc.
- HealthOperationTimeout: Az állapotkezelőnek küldött jelentésüzenet időtúllépési időtartama. Ha egy üzenet túllépi az időkorlátot, az állapotügyfél újrapróbálkozza, amíg az állapotkezelő meg nem győződik arról, hogy a jelentés feldolgozása megtörtént. Alapértelmezett: két perc.
Feljegyzés
A jelentések kötegelésekor a hálóügyfélnek életben kell maradnia legalább a HealthReportSendInterval számára, hogy meggyőződjön arról, hogy a rendszer elküldi őket. Ha az üzenet elveszik, vagy az állapotkezelő átmeneti hibák miatt nem tudja alkalmazni őket, a hálóügyfélnek tovább kell életben maradnia, hogy újrapróbálkozzon.
Az ügyfél pufferelése figyelembe veszi a jelentések egyediségét. Ha például egy adott rossz riporter 100 jelentést jelent másodpercenként ugyanazon entitás ugyanazon tulajdonságán, a jelentések helyébe az utolsó verzió kerül. Legfeljebb egy ilyen jelentés létezik az ügyfélsoron. Ha a kötegelés konfigurálva van, az állapotkezelőnek küldött jelentések száma küldési időközönként csak egy. Ez a jelentés az utolsó hozzáadott jelentés, amely az entitás aktuális állapotát tükrözi.
Adja meg a konfigurációs paramétereket, amikor FabricClient létrejön a FabricClientSettings átadása az állapottal kapcsolatos bejegyzések kívánt értékeivel.
Az alábbi példa létrehoz egy hálóügyfélt, és meghatározza, hogy a jelentéseket a hozzáadásukkor el kell küldeni. Az újrapróbálkozható időtúllépések és hibák során az újrapróbálkozások 40 másodpercenként történnek.
var clientSettings = new FabricClientSettings()
{
HealthOperationTimeout = TimeSpan.FromSeconds(120),
HealthReportSendInterval = TimeSpan.FromSeconds(0),
HealthReportRetrySendInterval = TimeSpan.FromSeconds(40),
};
var fabricClient = new FabricClient(clientSettings);
Javasoljuk, hogy tartsa meg az alapértelmezett hálóügyfél-beállításokat, amelyek 30 másodpercre állíthatók HealthReportSendInterval be. Ez a beállítás optimális teljesítményt biztosít a kötegelés miatt. A lehető leghamarabb elküldendő kritikus jelentésekhez használja HealthReportSendOptions az Azonnali true in FabricClient.HealthClient.ReportHealth API-t. Az azonnali jelentések megkerülik a kötegelési időközt. Óvatosan használja ezt a jelzőt; lehetőség szerint ki szeretnénk használni az állapotügyfél kötegelését. Az azonnali küldés akkor is hasznos, ha a hálóügyfél bezárul (például a folyamat érvénytelen állapotot állapított meg, és a mellékhatások elkerülése érdekében le kell állítania). Biztosítja a felhalmozott jelentések lehető legjobb küldését. Ha egy jelentést azonnali jelzővel ad hozzá, az állapotügyfél kötegeli a legutóbbi küldés óta felhalmozott összes jelentést.
Ugyanezek a paraméterek akkor adhatók meg, ha a PowerShell-lel létrejön egy fürthöz való kapcsolat. Az alábbi példa elindít egy kapcsolatot egy helyi fürthöz:
PS C:\> Connect-ServiceFabricCluster -HealthOperationTimeoutInSec 120 -HealthReportSendIntervalInSec 0 -HealthReportRetrySendIntervalInSec 40
True
ConnectionEndpoint :
FabricClientSettings : {
ClientFriendlyName : PowerShell-1944858a-4c6d-465f-89c7-9021c12ac0bb
PartitionLocationCacheLimit : 100000
PartitionLocationCacheBucketCount : 1024
ServiceChangePollInterval : 00:02:00
ConnectionInitializationTimeout : 00:00:02
KeepAliveInterval : 00:00:20
HealthOperationTimeout : 00:02:00
HealthReportSendInterval : 00:00:00
HealthReportRetrySendInterval : 00:00:40
NotificationGatewayConnectionTimeout : 00:00:00
NotificationCacheUpdateTimeout : 00:00:00
}
GatewayInformation : {
NodeAddress : localhost:19000
NodeId : 1880ec88a3187766a6da323399721f53
NodeInstanceId : 130729063464981219
NodeName : Node.1
}
Az API-hoz hasonlóan a jelentések a kapcsolóval -Immediate is elküldhetők, és az értéktől függetlenül HealthReportSendInterval azonnal elküldhetők.
REST esetén a jelentések a Service Fabric-átjáróhoz lesznek elküldve, amely belső hálóügyfélekkel rendelkezik. Alapértelmezés szerint ez az ügyfél úgy van konfigurálva, hogy 30 másodpercenként kötegelt jelentéseket küldjön. A köteg időközét a fürtkonfiguráció beállításával HttpGatewayHealthReportSendInterval módosíthatja.HttpGateway Mint már említettük, jobb megoldás, ha igazsal Immediate küldi el a jelentéseket.
Feljegyzés
Annak érdekében, hogy a jogosulatlan szolgáltatások ne tudjanak állapotjelentést tenni a fürt entitásai ellen, konfigurálja a kiszolgálót úgy, hogy csak biztonságos ügyfelektől érkező kéréseket fogadjon el. A FabricClient jelentéskészítéshez használt biztonságnak engedélyeznie kell a fürttel való kommunikációt (például Kerberos vagy tanúsítványhitelesítés). További információ a fürt biztonságáról.
Jelentés az alacsony jogosultsági szintű szolgáltatásokból
Ha a Service Fabric-szolgáltatások nem férnek hozzá rendszergazdai hozzáféréssel a fürthöz, az aktuális környezetből Partition CodePackageActivationContextszármazó entitások állapotának jelentésére is lehetősége van.
- Állapot nélküli szolgáltatások esetén az IStatelessServicePartition.ReportInstanceHealth használatával jelentést készít az aktuális szolgáltatáspéldányról.
- Állapotalapú szolgáltatások esetén az IStatefulServicePartition.ReportReplicaHealth használatával jelentést készít az aktuális replikáról.
- Az IServicePartition.ReportPartitionHealth használatával jelentést készít az aktuális partícióentitásról.
- A CodePackageActivationContext.ReportApplicationHealth használatával jelentést készít az aktuális alkalmazásról.
- A CodePackageActivationContext.ReportDeployedApplicationHealth használatával jelentést készít az aktuális csomóponton üzembe helyezett aktuális alkalmazásról.
- A CodePackageActivationContext.ReportDeployedServicePackageHealth használatával jelentést készít az aktuális csomóponton üzembe helyezett alkalmazás szolgáltatáscsomagján.
Feljegyzés
Belsőleg az Partition alapértelmezett beállításokkal konfigurált állapotügyfél és a CodePackageActivationContext várakoztatás. Az állapotügyfél magyarázata szerint a jelentések kötegelve lesznek, és egy időzítőn lesznek elküldve. Az objektumokat életben kell tartani, hogy legyen esély a jelentés elküldésére.
A jelentések és CodePackageActivationContext az állapot API-k segítségével Partition történő küldésekor megadhatjaHealthReportSendOptions. Ha kritikus jelentésekkel rendelkezik, amelyeket a lehető leghamarabb el kell küldenie, használja HealthReportSendOptions az Azonnali truelehetőséget. Az azonnali jelentések megkerülik a belső állapotügyfél kötegelési időközét. Ahogy korábban említettük, használja ezt a jelzőt óvatosan; lehetőség szerint ki szeretnénk használni az állapotügyfél kötegelését.
Állapotjelentés tervezése
A kiváló minőségű jelentések létrehozásának első lépése a szolgáltatás állapotát befolyásoló feltételek azonosítása. Bármely feltétel, amely segíthet a szolgáltatás vagy a fürt problémáinak megjelölésében, amikor az elindul – vagy még jobb, mielőtt probléma merül fel – akár több milliárd dollárt is megtakaríthat. Az előnyök közé tartozik a kevesebb leállási idő, a problémák kivizsgálásával és javításával töltött kevesebb éjszakai óra, valamint a nagyobb ügyfél-elégedettség.
A feltételek azonosítása után a watchdog íróknak ki kell találniuk a legjobb módot a terhelés és a hasznosság közötti egyensúly ellenőrzésére. Vegyük például azt a szolgáltatást, amely összetett számításokat végez, amelyek ideiglenes fájlokat használnak egy megosztáson. A figyelők figyelhetik a megosztást, hogy elegendő hely álljon rendelkezésre. Figyelheti a fájl- vagy könyvtárváltozásokkal kapcsolatos értesítéseket. Figyelmeztetést jelenthet, ha eléri az előzetes küszöbértéket, és hibát jelezhet, ha a megosztás megtelt. Figyelmeztetés esetén a javítórendszer elkezdheti megtisztítani a megosztás régebbi fájljait. Hiba esetén a javítórendszer áthelyezheti a szolgáltatásreplikát egy másik csomópontra. Figyelje meg, hogy a feltételállapotok hogyan vannak leírva az állapot szempontjából: az állapot, amely kifogástalannak (ok) vagy nem megfelelőnek tekinthető (figyelmeztetés vagy hiba).
A monitorozási adatok beállítása után a watchdog írójának ki kell találnia, hogyan implementálhatja a watchdogot. Ha a feltételek a szolgáltatáson belül határozhatók meg, a figyelő is része lehet a figyelt szolgáltatásnak. A szolgáltatáskód például ellenőrizheti a megosztások használatát, majd jelentést készíthet minden alkalommal, amikor megpróbál fájlokat írni. Ennek a megközelítésnek az az előnye, hogy a jelentéskészítés egyszerű. Ügyelni kell arra, hogy a watchdog hibái ne befolyásolják a szolgáltatás működését.
A figyelt szolgáltatáson belüli jelentéskészítés nem mindig lehetséges. Előfordulhat, hogy a szolgáltatáson belüli figyelő nem tudja észlelni a feltételeket. Lehet, hogy nem rendelkezik a meghatározáshoz szükséges logikával vagy adatokkal. A feltételek monitorozásának többletterhelése magas lehet. Előfordulhat, hogy a feltételek nem egy szolgáltatásra vonatkoznak, hanem a szolgáltatások közötti interakciókra. Egy másik lehetőség az, hogy a watchdogok külön folyamatokként vannak a fürtben. A figyelők figyelik a feltételeket és a jelentést anélkül, hogy bármilyen módon befolyásolnák a fő szolgáltatásokat. Ezek a watchdogok például implementálhatók állapot nélküli szolgáltatásokként ugyanabban az alkalmazásban, az összes csomóponton vagy a szolgáltatással azonos csomópontokon.
Előfordulhat, hogy a fürtön futó watchdog sem megoldás. Ha a figyelt feltétel a szolgáltatás rendelkezésre állása vagy funkciója, ahogy a felhasználók látják, a legjobb, ha a watchdogok ugyanabban a helyen vannak, mint a felhasználói ügyfelek. Itt ugyanúgy tesztelhetik a műveleteket, ahogyan a felhasználók hívják őket. Létrehozhat például egy olyan figyelőt, amely a fürtön kívül található, problémákat intézhet a szolgáltatáshoz, és ellenőrizheti az eredmény késését és helyességét. (Egy számológép szolgáltatás esetében például a 2+2 4-et ad vissza ésszerű idő alatt?)
A watchdog részleteinek véglegesítése után egy olyan forrásazonosítót kell választania, amely egyedileg azonosítja azokat. Ha több azonos típusú watchdog él a fürtben, különböző entitásokról kell jelentést tennie, vagy ha ugyanazon az entitáson jelent, különböző forrásazonosítót vagy tulajdonságot kell használnia. Így a jelentésük egymás mellett is létezhet. Az állapotjelentés tulajdonságának rögzítenie kell a figyelt feltételt. (A fenti példában a tulajdonság lehet ShareSize.) Ha több jelentés is vonatkozik ugyanarra a feltételre, a tulajdonságnak olyan dinamikus információkat kell tartalmaznia, amelyek lehetővé teszik a jelentések egyidejű használatát. Ha például több megosztást kell figyelni, a tulajdonság neve lehet ShareSize-sharename.
Feljegyzés
Ne használja az állapottárolót az állapotadatok megőrzéséhez. Csak az állapottal kapcsolatos információkat kell állapotként jelenteni, mivel ezek az információk hatással vannak egy entitás állapotértékelésére. Az állapottárolót nem általános célú tárolóként tervezték. Állapotértékelési logikával összesíti az összes adatot az állapotban. Az állapottól független információk küldése (például az állapotjelentés állapota OK) nem befolyásolja az összesített állapotot, de negatívan befolyásolhatja az állapottároló teljesítményét.
A következő döntési pont az, amelyről jelentést kell tenni. A legtöbb esetben a feltétel egyértelműen azonosítja az entitást. Válassza ki az entitást a lehető legjobb részletességgel. Ha egy feltétel hatással van egy partíció összes replikájára, jelentse a partíciót, ne a szolgáltatást. Vannak azonban olyan sarki esetek, ahol több gondolkodásra van szükség. Ha a feltétel hatással van egy entitásra, például egy replikára, de a cél az, hogy a feltétel a replika élettartamánál hosszabb ideig legyen megjelölve, akkor a partíción kell jelenteni. Ellenkező esetben a replika törlésekor az állapottároló törli az összes jelentést. A watchdog íróknak az entitás és a jelentés élettartamára kell gondolniuk. Egyértelműnek kell lennie, hogy mikor kell törölni egy jelentést egy áruházból (például ha egy entitáson jelentett hiba már nem érvényes).
Tekintsünk meg egy példát, amely összehozza az általam leírt pontokat. Fontolja meg egy Service Fabric-alkalmazást, amely egy fő állapotalapú állandó szolgáltatásból és az összes csomóponton üzembe helyezett másodlagos állapot nélküli szolgáltatásokból áll (minden tevékenységtípushoz egy másodlagos szolgáltatástípus). A főkiszolgáló rendelkezik egy feldolgozási üzenetsorsal, amely a másodfokú fájlok által végrehajtandó parancsokat tartalmazza. A másodfokok végrehajtják a bejövő kéréseket, és nyugtázási jeleket küldenek vissza. Az egyik monitorozási feltétel a fő feldolgozási üzenetsor hossza. Ha a fő üzenetsor hossza eléri a küszöbértéket, a rendszer figyelmeztetést jelent. A figyelmeztetés azt jelzi, hogy a másodfokok nem tudják kezelni a terhelést. Ha az üzenetsor eléri a maximális hosszt, és a parancsokat elveti, hibaüzenet jelenik meg, mivel a szolgáltatás nem tud helyreállni. A jelentések a QueueStatus tulajdonságban lehetnek. A figyelő a szolgáltatáson belül él, és rendszeres időközönként küldi el a fő elsődleges replikán. Az élettartam két perc, és 30 másodpercenként rendszeres időközönként kerül elküldésre. Ha az elsődleges lemegy, a jelentés automatikusan törlődik az áruházból. Ha a szolgáltatásreplika működik, de holtponton van, vagy más problémákat tapasztal, a jelentés lejár az állapottárolóban. Ebben az esetben az entitás kiértékelése hiba esetén történik.
Egy másik monitorozási feltétel a tevékenységek végrehajtási ideje. A főkiszolgáló a feladattípus alapján osztja el a feladatokat a másodfokon. A tervtől függően a főkiszolgáló lekérdezheti a feladat állapotának második fájljait. Az is előfordulhat, hogy a másodfokú küldöttek nyugtázási jeleket küldenek, amikor elkészültek. A második esetben ügyelni kell az olyan helyzetek észlelésére, amikor a másodfokú személyek meghalnak vagy üzenetek elvesznek. Az egyik lehetőség az, hogy a főkiszolgáló ugyanahhoz a másodlagoshoz küld pingelési kérelmet, amely visszaküldi az állapotát. Ha nem érkezik állapot, a főkiszolgáló hibának tekinti, és átütemezi a feladatot. Ez a viselkedés feltételezi, hogy a tevékenységek idempotensek.
A figyelt feltétel figyelmeztetésként fordítható le, ha a feladat nem egy adott időpontban (t1, például 10 perc) van végrehajtva. Ha a feladat nem fejeződik be időben (t2, például 20 perc), a figyelt feltétel hibaként fordítható le. Ez a jelentés többféleképpen is elvégezhető:
- A fő elsődleges replika rendszeresen jelentéseket készít magáról. Az üzenetsorban lévő összes függőben lévő tevékenységhez egy tulajdonság is tartozhat. Ha legalább egy tevékenység tovább tart, a PendingTasks tulajdonság jelentésállapota adott esetben figyelmeztetés vagy hiba. Ha nincsenek függőben lévő tevékenységek vagy az összes megkezdett tevékenység, a jelentés állapota rendben van. A tevékenységek állandóak. Ha az elsődleges lemegy, az újonnan előléptetett elsődleges továbbra is megfelelően tud jelentést tenni.
- Egy másik figyelőfolyamat (a felhőben vagy külső környezetben) ellenőrzi a tevékenységeket (kívülről, a kívánt tevékenység eredménye alapján), hogy befejeződött-e. Ha nem tartják be a küszöbértékeket, a rendszer jelentést küld a főszolgáltatásnak. A rendszer minden olyan tevékenységről jelentést is küld, amely tartalmazza a tevékenységazonosítót, például PendingTask+taskId. A jelentéseket csak nem megfelelő állapotú állapotokban szabad elküldeni. Állítson be néhány percet az élettartamra, és jelölje meg az eltávolítandó jelentéseket, amikor lejárnak, hogy biztosítsák a törlést.
- A feladatjelentéseket végrehajtó másodlagos, ha a futtatás a vártnál tovább tart. Jelentést készít a Szolgáltatáspéldányról a PendingTasks tulajdonságban. A jelentés rögzíti a problémákat tartalmazó szolgáltatáspéldányt, de nem rögzíti azt a helyzetet, amelyben a példány meghal. A jelentések ekkor törlődnek. Jelentheti a másodlagos szolgáltatást. Ha a másodlagos befejezi a feladatot, a másodlagos példány törli a jelentést az áruházból. A jelentés nem rögzíti azt a helyzetet, amikor a nyugtázási üzenet elveszik, és a feladat nem fejeződik be a főkiszolgáló szempontjából.
A jelentéskészítés azonban a fent leírt esetekben történik, a jelentések az állapot kiértékelésekor az alkalmazás állapotában lesznek rögzítve.
Jelentés időszakosan és áttűnésről
Az állapotjelentési modell használatával a watchdogok rendszeres időközönként vagy áttűnésekről küldhetnek jelentéseket. A watchdog jelentéskészítés ajánlott módja rendszeres, mert a kód sokkal egyszerűbb és kevésbé hajlamos a hibákra. A figyelőkutyáknak a lehető legegyszerűbbnek kell lenniük, hogy elkerüljék a helytelen jelentéseket kiváltó hibákat. A helytelen állapotjelentések hatással vannak az állapotértékelésekre és az állapoton alapuló forgatókönyvekre, beleértve a frissítéseket is. A helytelen állapotú jelentések elrejtik a fürtön előforduló problémákat, ami nem kívánatos.
Rendszeres jelentéskészítéshez a watchdog egy időzítővel implementálható. Időzítővisszahívás esetén a figyelők ellenőrizhetik az állapotot, és az aktuális állapot alapján küldhetnek jelentést. Nem kell látni, hogy melyik jelentést küldték korábban, és nem kell optimalizálni az üzenetküldést. Az állapotügyfél kötegelési logikával rendelkezik, amely segít a teljesítményben. Amíg az állapotügyfél életben marad, addig belsőleg újrapróbálkezik, amíg az állapottároló nyugtázza a jelentést, vagy a figyelő egy újabb jelentést hoz létre ugyanazzal az entitással, tulajdonsággal és forrással.
Az áttűnésekről való jelentéskészítés gondos állapotkezelést igényel. A figyelő csak akkor figyel bizonyos feltételeket és jelentéseket, ha a feltételek változnak. Ennek a megközelítésnek az az előnye, hogy kevesebb jelentésre van szükség. A hátránya az, hogy a watchdog logikája összetett. A figyelőnek fenn kell tartania a feltételeket vagy a jelentéseket, hogy meg lehessen vizsgálni őket az állapotváltozások meghatározásához. Feladatátvételkor ügyelni kell a hozzáadott jelentésekre, de még nem kell elküldeni őket az állapottárolóba. A sorszámnak folyamatosan növekednie kell. Ha nem, a jelentések elavultként lesznek elutasítva. Azokban a ritka esetekben, amikor adatvesztés történik, szükség lehet szinkronizálásra a riporter állapota és az állapottár között.
Az áttűnésekről való jelentéskészítésnek van értelme, ha a szolgáltatások önmagukról, az át- vagy CodePackageActivationContexta Partition . A helyi objektum (replika vagy üzembe helyezett szolgáltatáscsomag/üzembe helyezett alkalmazás) eltávolításakor a rendszer az összes jelentést is eltávolítja. Ez az automatikus törlés ellazítja a riporter és az állapottároló közötti szinkronizálás szükségességét. Ha a jelentés szülőpartícióra vagy szülőalkalmazásra készült, ügyelni kell a feladatátvételre, hogy elkerülje az elavult jelentéseket az állapottárolóban. A logikát hozzá kell adni a megfelelő állapot fenntartásához, és törölni kell a jelentést a tárolóból, ha már nincs rá szükség.
Állapotjelentés implementálása
Ha az entitás és a jelentés adatai egyértelműek, az állapotjelentések elküldése az API-val, a PowerShell-lel vagy a REST-lel végezhető el.
API
Az API-n keresztüli jelentéskészítéshez létre kell hoznia egy állapotjelentést, amely az entitástípusra vonatkozik, amelyen jelentést szeretne készíteni. Adja át a jelentést egy állapotügyfélnek. Másik lehetőségként hozzon létre egy állapotinformációt, és adja át azokat az aktuális entitások Partition jelentéskészítési módszereinek javítására vagy CodePackageActivationContext jelentésére.
Az alábbi példa a fürtön belüli watchdog rendszeres jelentéseit mutatja be. A watchdog ellenőrzi, hogy egy külső erőforrás elérhető-e egy csomóponton belülről. Az erőforrásra az alkalmazásban található szolgáltatásjegyzéknek van szüksége. Ha az erőforrás nem érhető el, az alkalmazás többi szolgáltatása továbbra is megfelelően működhet. Ezért a rendszer 30 másodpercenként küldi el a jelentést az üzembe helyezett szolgáltatáscsomag-entitáson.
private static Uri ApplicationName = new Uri("fabric:/WordCount");
private static string ServiceManifestName = "WordCount.Service";
private static string NodeName = FabricRuntime.GetNodeContext().NodeName;
private static Timer ReportTimer = new Timer(new TimerCallback(SendReport), null, 30 * 1000, 30 * 1000);
private static FabricClient Client = new FabricClient(new FabricClientSettings() { HealthReportSendInterval = TimeSpan.FromSeconds(0) });
public static void SendReport(object obj)
{
// Test whether the resource can be accessed from the node
HealthState healthState = this.TestConnectivityToExternalResource();
// Send report on deployed service package, as the connectivity is needed by the specific service manifest
// and can be different on different nodes
var deployedServicePackageHealthReport = new DeployedServicePackageHealthReport(
ApplicationName,
ServiceManifestName,
NodeName,
new HealthInformation("ExternalSourceWatcher", "Connectivity", healthState));
// TODO: handle exception. Code omitted for snippet brevity.
// Possible exceptions: FabricException with error codes
// FabricHealthStaleReport (non-retryable, the report is already queued on the health client),
// FabricHealthMaxReportsReached (retryable; user should retry with exponential delay until the report is accepted).
Client.HealthManager.ReportHealth(deployedServicePackageHealthReport);
}
PowerShell
Állapotjelentések küldése a Send-ServiceFabricEntityTypeHealthReport használatával.
Az alábbi példa egy csomópont cpu-értékeivel kapcsolatos rendszeres jelentéskészítést mutatja be. A jelentéseket 30 másodpercenként kell elküldeni, és két percig kell élniük. Ha lejárnak, a riporternek problémái vannak, ezért a csomópont kiértékelése hiba esetén történik. Ha a CPU túllép egy küszöbértéket, a jelentés állapotának figyelmeztetési állapota van. Ha a cpu a beállított időnél hosszabb ideig meghaladja a küszöbértéket, hibaként jelenik meg. Ellenkező esetben a riporter OK állapotú állapotot küld.
PS C:\> Send-ServiceFabricNodeHealthReport -NodeName Node.1 -HealthState Warning -SourceId PowershellWatcher -HealthProperty CPU -Description "CPU is above 80% threshold" -TimeToLiveSec 120
PS C:\> Get-ServiceFabricNodeHealth -NodeName Node.1
NodeName : Node.1
AggregatedHealthState : Warning
UnhealthyEvaluations :
Unhealthy event: SourceId='PowershellWatcher', Property='CPU', HealthState='Warning', ConsiderWarningAsError=false.
HealthEvents :
SourceId : System.FM
Property : State
HealthState : Ok
SequenceNumber : 5
SentAt : 4/21/2015 8:01:17 AM
ReceivedAt : 4/21/2015 8:02:12 AM
TTL : Infinite
Description : Fabric node is up.
RemoveWhenExpired : False
IsExpired : False
Transitions : ->Ok = 4/21/2015 8:02:12 AM
SourceId : PowershellWatcher
Property : CPU
HealthState : Warning
SequenceNumber : 130741236814913394
SentAt : 4/21/2015 9:01:21 PM
ReceivedAt : 4/21/2015 9:01:21 PM
TTL : 00:02:00
Description : CPU is above 80% threshold
RemoveWhenExpired : False
IsExpired : False
Transitions : ->Warning = 4/21/2015 9:01:21 PM
Az alábbi példa egy replikára vonatkozó átmeneti figyelmeztetést jelent. Először lekéri a partícióazonosítót, majd annak a szolgáltatásnak a replikaazonosítóját, amely iránt érdeklődik. Ezután jelentést küld a PowershellWatchertől a ResourceDependency tulajdonságról. A jelentés csak két percig érdekes, és automatikusan törlődik az áruházból.
PS C:\> $partitionId = (Get-ServiceFabricPartition -ServiceName fabric:/WordCount/WordCount.Service).PartitionId
PS C:\> $replicaId = (Get-ServiceFabricReplica -PartitionId $partitionId | where {$_.ReplicaRole -eq "Primary"}).ReplicaId
PS C:\> Send-ServiceFabricReplicaHealthReport -PartitionId $partitionId -ReplicaId $replicaId -HealthState Warning -SourceId PowershellWatcher -HealthProperty ResourceDependency -Description "The external resource that the primary is using has been rebooted at 4/21/2015 9:01:21 PM. Expect processing delays for a few minutes." -TimeToLiveSec 120 -RemoveWhenExpired
PS C:\> Get-ServiceFabricReplicaHealth -PartitionId $partitionId -ReplicaOrInstanceId $replicaId
PartitionId : 8f82daff-eb68-4fd9-b631-7a37629e08c0
ReplicaId : 130740415594605869
AggregatedHealthState : Warning
UnhealthyEvaluations :
Unhealthy event: SourceId='PowershellWatcher', Property='ResourceDependency', HealthState='Warning', ConsiderWarningAsError=false.
HealthEvents :
SourceId : System.RA
Property : State
HealthState : Ok
SequenceNumber : 130740768777734943
SentAt : 4/21/2015 8:01:17 AM
ReceivedAt : 4/21/2015 8:02:12 AM
TTL : Infinite
Description : Replica has been created.
RemoveWhenExpired : False
IsExpired : False
Transitions : ->Ok = 4/21/2015 8:02:12 AM
SourceId : PowershellWatcher
Property : ResourceDependency
HealthState : Warning
SequenceNumber : 130741243777723555
SentAt : 4/21/2015 9:12:57 PM
ReceivedAt : 4/21/2015 9:12:57 PM
TTL : 00:02:00
Description : The external resource that the primary is using has been rebooted at 4/21/2015 9:01:21 PM. Expect processing delays for a few minutes.
RemoveWhenExpired : True
IsExpired : False
Transitions : ->Warning = 4/21/2015 9:12:32 PM
REST
Állapotjelentések küldése REST használatával olyan POST-kérésekkel, amelyek a kívánt entitásra kerülnek, és a törzsben szerepel az állapotjelentés leírása. Megtudhatja például, hogyan küldhet REST-fürtállapot-jelentéseket vagy szolgáltatásállapot-jelentéseket. Minden entitás támogatott.
Következő lépések
Az állapotadatok alapján a szolgáltatásírók és a fürt-/alkalmazásgazdák átgondolhatják, hogyan használhatják fel az információkat. Beállíthatnak például állapotalapú riasztásokat, hogy súlyos problémákat észleljenek, mielőtt kimaradásokat idéznének elő. A rendszergazdák javítórendszereket is beállíthatnak a problémák automatikus megoldásához.
A Service Fabric állapotmonitorozásának bemutatása
Service Fabric állapotjelentéseinek megtekintése
A szolgáltatás állapotának jelentése és ellenőrzése
Rendszerállapot-jelentések használata hibaelhárításhoz