Egyéni Service Fabric-állapotjelentések hozzáadása

  • Cikk

Az Azure Service Fabric egy olyan állapotmodellt vezet be, amelynek célja a nem kifogástalan fürt- és alkalmazásfeltételek megjelölése adott entitásokon. Az állapotmodell állapotjelentéseket (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 állapotot, 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 (magán- vagy Azure-ban).

A Service Fabric-riporterek figyelik az azonosított érdeklődési feltételeket. Ezekről a feltételekről a helyi nézetük alapján számolnak be. Az állapottároló az összes riporter által küldött állapotadatokat összesíti 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ó téves 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ő legjobb módon rögzítik az érdeklődési feltételeket.

Az állapotjelentések tervezéséhez és implementálásához a figyelőknek és a rendszerösszetevőknek a következőkre van szükség:

  • 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.
  • Állapítsa meg, hogy hol történik a jelentéskészítés a szolgáltatáson belül, vagy egy belső vagy külső figyelőtől.
  • Definiáljon egy forrást, amely a riporter azonosítására szolgál.
  • Válasszon ki egy jelentéskészítési stratégiát, akár rendszeres időközönként, akár áttűnések esetén. Az ajánlott módszer rendszeres időközönként történik, mivel egyszerűbb kódot igényel, és kevésbé hajlamos a hibákra.
  • Határozza meg, hogy a nem megfelelő állapotú állapotokat jelző jelentés mennyi ideig maradjon az állapottárolóban, és hogyan kell törölni. Ezen információk alapján döntse el a jelentés élettartamát és a lejáratkor történő eltávolítási viselkedést.

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ő figyelők (például állapot nélküli Service Fabric-szolgáltatás, amely feltételeket figyel és jelentéseket ad ki). A watchdogok üzembe helyezhetők az összes csomóponton, vagy affinithatók a figyelt szolgáltatáshoz.
  • Belső figyelők, amelyek a Service Fabric-csomópontokon futnak, de nem Service Fabric-szolgáltatásként vannak implementálva.
  • Külső figyelők, amelyek a Service Fabric-fürtön kívülről (például a Gomezhez hasonló monitorozási szolgáltatásból) ellenőrzik az erőforrást.

Megjegyzé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 a rendszer által már létrehozott állapotentitásokon kell elküldeni.

Ha az állapotjelentések kialakítása egyértelmű, az állapotjelentések egyszerűen elküldhetők. A FabricClient használatával jelentést készíthet az állapotról, ha a fürt nem biztonságos , vagy ha a hálóügyfél rendszergazdai jogosultságokkal rendelkezik. A jelentéskészítés történhet az API-val a FabricClient.HealthManager.ReportHealth, a PowerShell vagy a REST használatával. A konfigurációs gombok kötegelt jelentései a jobb teljesítmény érdekében.

Megjegyzés

A jelentés állapota szinkron, és csak az ügyféloldali ellenőrzési munkát jelöli. Az a tény, hogy a jelentést az állapotügyfél vagy a Partition vagy CodePackageActivationContext objektumok elfogadják, nem jelenti azt, hogy az áruházban lesz alkalmazva. A rendszer aszinkron módon, esetleg más jelentésekkel kötegelve küldi el. 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élen belül található. Az állapotkezelő az állapottárolóba menti a jelentéseket. 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 való elküldése közötti késleltetés. A jelentések egyetlen üzenetbe való kötegésére szolgál, nem pedig minden jelentéshez egy üzenetet küld. 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őszaka. Ha egy üzenet túllépi az időkorlátot, az állapotügyfél újrapróbálkozásokat végez, amíg az állapotkezelő meg nem erősíti a jelentés feldolgozását. Alapértelmezett: két perc.

Megjegyzés

A jelentések kötegelésekor a hálóügyfélnek életben kell maradnia legalább a HealthReportSendInterval számára, hogy biztosan elküldje ő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álkozási lehetőséget kapjon.

Az ügyfél pufferelése figyelembe veszi a jelentések egyediségét. Ha például egy adott rossz riporter másodpercenként 100 jelentést jelent ugyanazon entitás ugyanazon tulajdonságáról, a jelentések az utolsó verzióra lesznek cserélve. 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özenként csak egy. Ez a jelentés az utolsó hozzáadott jelentés, amely az entitás legfrissebb á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 megadja, hogy a jelentéseket a hozzáadásukkor el kell küldeni. Az újrapróbálkozható időtúllépések és hibák eseté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 . 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 a FabricClient.HealthClient.ReportHealth API-ban lehetőséget. Az azonnali jelentések megkerülik a kötegelési időközt. Ezt a jelzőt körültekintően használja; lehetőség szerint szeretnénk kihasználni az állapotügyfél kötegelésének előnyeit. 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 le kell állítania a mellékhatások elkerülése érdekében). Biztosítja a halmozott jelentések lehető leghatékonyabb küldését. Amikor egy jelentést azonnali jelzővel ad hozzá, az állapotügyfél a legutóbbi küldés óta összes összegyűjtött jelentést kötegeli.

Ugyanezek a paraméterek akkor adhatók meg, ha a PowerShell-lel kapcsolatot hoznak létre egy fürthöz. 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 is elküldhetők kapcsolóval -Immediate , hogy azonnal elküldhetők legyenek, függetlenül az HealthReportSendInterval értéktől.

REST esetén a rendszer elküldi a jelentéseket a Service Fabric-átjárónak, amely egy belső hálóügyfélel 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ötegintervallumot a fürt konfigurációs beállításával HttpGatewayHealthReportSendInterval módosíthatja a következőn: HttpGateway. Ahogy már említettük, jobb megoldás, ha a jelentéseket igaz értékekkel küldi Immediate el.

Megjegyzés

Annak érdekében, hogy a jogosulatlan szolgáltatások ne tudjanak állapotjelentést küldeni a fürt entitásai ellen, konfigurálja a kiszolgálót úgy, hogy csak a biztonságos ügyfelektől érkező kéréseket fogadja el. A FabricClient jelentéskészítéshez használt biztonságnak engedélyezve kell lennie a fürttel való kommunikációhoz (például Kerberos- vagy tanúsítványhitelesítéssel). További információ a fürtbiztonságról.

Jelentés az alacsony jogosultsági szintű szolgáltatásokból

Ha a Service Fabric-szolgáltatások nem rendelkeznek rendszergazdai hozzáféréssel a fürthöz, az aktuális környezetből származó entitások állapotáról jelentést készíthet a vagy CodePackageActivationContexta használatávalPartition.

Megjegyzés

Belsőleg a Partition és a CodePackageActivationContext hold állapotügyfél konfigurálva van az alapértelmezett beállításokkal. 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 lehetőségük legyen elküldeni a jelentést.

Megadhatja HealthReportSendOptions , hogy mikor küld jelentéseket az Partition és CodePackageActivationContext állapot API-kkal. Ha kritikus jelentésekkel rendelkezik, amelyeket a lehető leghamarabb el kell küldeni, 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, óvatosan használja ezt a jelzőt; az állapotügyfél kötegelését szeretnénk kihasználni, amikor csak lehetséges.

Állapotjelentés tervezése

A kiváló minőségű jelentések létrehozásának első lépése az, hogy azonosítja azokat a feltételeket, amelyek hatással lehetnek a szolgáltatás állapotára. Minden olyan feltétel, amely segíthet megjelölni a szolgáltatás vagy a fürt problémáit, amikor az elindul – vagy még jobb, mielőtt probléma merül fel – több milliárd dollárt takaríthat meg. Az előnyök közé tartozik a kevesebb állásidő, 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ódszert a terhelés és a hasznosság közötti egyensúly ellenőrzésére. Vegyük például egy olyan szolgáltatást, amely összetett számításokat végez, amelyek ideiglenes fájlokat használnak egy megosztáson. A figyelőkutya figyelheti 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 megkezdheti a megosztás régebbi fájljainak eltávolítását. 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 az állapot szempontjából vannak leírva: a feltétel állapota, amely kifogástalannak (ok) vagy nem kifogástalannak 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ő a figyelt szolgáltatás része lehet. A szolgáltatáskód például ellenőrizheti a megosztások használatát, majd minden alkalommal jelentést készíthet, 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ásból történő 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. Előfordulhat, hogy nem rendelkezik a meghatározáshoz használható 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 is hatással vannak. Egy másik lehetőség az, hogy a figyelőkutyák 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 állapot nélküli szolgáltatásokként implementálhatók ugyanabban az alkalmazásban, az összes csomóponton vagy a szolgáltatással azonos csomópontokon.

Előfordulhat, hogy a fürtön futó figyelőkutya sem választható. 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. Ott 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ó, kéréseket küld a szolgáltatásnak, és ellenőrzi 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 ésszerű idő alatt 4-et ad vissza?)

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ürtön, akkor különböző entitásokról kell jelentést készíteniük, vagy ha ugyanazon az entitáson jelentenek, eltérő forrásazonosítót vagy tulajdonságot kell használniuk. Így a jelentésük együtt is jelen lehet. 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.

Megjegyzé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át használ az összes adat állapotba való összesítéséhez. Az állapothoz nem kapcsolódó információk küldése (például az OK állapottal rendelkező jelentési állapot) 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 készíteni. A legtöbb esetben a feltétel egyértelműen azonosítja az entitást. Válassza ki a lehető legrészletesebb entitást. 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 gondolatra 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 azt 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 tárolóból (például ha egy entitáson jelentett hiba már nem érvényes).

Lássunk egy példát, amely összehozza az általam leírt pontokat. Vegyünk 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 figyelhető 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 parancsok el lesznek dobva, 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 elküldi a fő elsődleges replikán. Az élettartam két perc, és a rendszer 30 másodpercenként küldi el. Ha az elsődleges érték leáll, a rendszer automatikusan eltávolítja a jelentést a tárolóból. Ha a szolgáltatásreplika működik, de holtponton van, vagy egyéb 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ásodtárak között. A tervtől függően a főkiszolgáló lekérdezheti a második feladat állapotát. Azt is várhatja, hogy a másodküldetek visszaküldjék a nyugtázási jeleket, amikor elkészültek. A második esetben ügyelni kell az olyan helyzetek észlelésére, amikor a másodfokú fájlok meghalnak vagy üzenetek elvesznek. Az egyik lehetőség, hogy a főkiszolgáló ugyanarra a másodlagosra 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 azt 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) történik. 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. A várólistán lévő összes függőben lévő tevékenységhez egy tulajdonság is tartozhat. Ha legalább egy feladat hosszabb időt vesz igénybe, 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 tevékenység megkezdődött, a jelentés állapota rendben van. A tevékenységek állandóak. Ha az elsődleges érték csökken, az újonnan előléptetett elsődleges továbbra is megfelelően tud jelentést készíteni.
  • 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), és ellenőrzi, hogy befejeződtek-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 is küld jelentést, amely tartalmazza a tevékenységazonosítót, például PendingTask+taskId. A jelentéseket csak nem kifogástalan állapotú állapotokban szabad elküldeni. Állítsa be az élettartamot néhány percre, és jelölje meg az eltávolítandó jelentéseket, amikor lejárnak, a törlés érdekében.
  • A feladatjelentéseket végrehajtó másodlagos, ha a futtatás a vártnál több időt vesz igénybe. Jelentést készít a szolgáltatáspéldányról a PendingTasks tulajdonságon. A jelentés rögzíti a problémákat okozó szolgáltatáspéldányt, de nem rögzíti azt a helyzetet, amikor a példány meghal. A jelentések ezután törlődnek. Jelenthet a másodlagos szolgáltatásról. 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 kifogástalan állapotú jelentések elrejtik a fürtön előforduló problémákat, ami nem kívánatos.

Az időszakos jelentéskészítéshez a watchdog egy időzítővel valósítható meg. Az időzítő visszahívása esetén a watchdog ellenőrizheti az állapotot, és elküldhet egy jelentést az aktuális állapot alapján. Nem kell látni, hogy melyik jelentést küldték el 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 újrapróbálkezik belsőleg, amíg az állapottároló nem 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 megváltoznak. Ennek a megközelítésnek az a hátránya, 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 megvizsgálhassa őket az állapotváltozások meghatározásához. Feladatátvételkor ügyelni kell a hozzáadott jelentésekre, de még nem küldhetők el az állapottárolóba. A sorszámnak folyamatosan növekvőnek kell lennie. Ha nem, a jelentések elavultként lesznek elutasítva. Azokban a ritka esetekben, amikor adatvesztés történik, szinkronizálásra lehet szükség a riporter állapota és az állapottár között.

Az áttűnésekről való jelentéskészítésnek akkor van értelme, ha a szolgáltatások magukról, a vagy CodePackageActivationContexta rendszeren keresztül Partition jelentenek jelentést. A helyi objektum (replika vagy üzembe helyezett szolgáltatáscsomag/üzembe helyezett alkalmazás) eltávolításakor a rendszer az összes jelentését is eltávolítja. Ez az automatikus tisztítá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 vonatkozik, ü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

Az entitás és a jelentés adatainak egyértelművé tétele után az állapotjelentések elküldése az API-val, a PowerShell-lel vagy a REST-lel végezhető el.

API

Ha az API-n keresztül szeretne jelentést készíteni, létre kell hoznia egy állapotjelentést, amely az entitástípusra vonatkozik, amelyről 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 a megfelelő jelentéskészítési módszereknek az PartitionCodePackageActivationContext aktuális entitásokon vagy azok jelentésére.

Az alábbi példa a fürtön belüli figyelőkutya rendszeres jelentéseit mutatja be. A watchdog ellenőrzi, hogy egy külső erőforrás elérhető-e egy csomóponton belül. Az erőforrásra egy szolgáltatásjegyzéknek van szüksége az alkalmazásban. 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ópontot hiba alapján értékeli ki a rendszer. Ha a cpu egy küszöbérték felett van, a jelentés állapota figyelmeztetés. Ha a processzor a konfigurált időnél hosszabb ideig egy küszöbérték felett marad, a rendszer hibaként jelenti. Ellenkező esetben a riporter ok á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 PowershellWatcherbő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 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ás-rendszergazdák átgondolhatják az információk felhasználásának módját. Beállíthatnak például riasztásokat az állapotuk alapján, hogy elkapják a súlyos problémákat, mielőtt kimaradásokat váltanak ki. 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ések megtekintése

A szolgáltatás állapotának jelentése és ellenőrzése

Rendszerállapot-jelentések használata hibaelhárításhoz

A szolgáltatások helyi figyelése és diagnosztikája

Service Fabric-alkalmazás frissítése