Dodawanie niestandardowych raportów kondycji usługi Service Fabric
Usługa Azure Service Fabric wprowadza model kondycji przeznaczony do flagowania w złej kondycji klastra i warunków aplikacji dla określonych jednostek. Model kondycji używa reporterów kondycji (składników systemowych i watchdogs). Celem jest łatwa i szybka diagnostyka i naprawa. Pisarze usług muszą myśleć z góry o zdrowiu. Każdy warunek, który może mieć wpływ na kondycję, powinien być zgłaszany, zwłaszcza jeśli może pomóc flagować problemy w pobliżu katalogu głównego. Informacje o kondycji mogą zaoszczędzić czas i nakład pracy na debugowaniu i badaniu. Użyteczność jest szczególnie jasna, gdy usługa jest uruchomiona na dużą skalę w chmurze (prywatna lub azure).
Reporterzy usługi Service Fabric monitorują zidentyfikowane warunki zainteresowania. Zgłaszają te warunki na podstawie ich widoku lokalnego. Magazyn kondycji agreguje dane kondycji wysyłane przez wszystkich reporterów, aby określić, czy jednostki są globalnie w dobrej kondycji. Model ma być bogaty, elastyczny i łatwy w użyciu. Jakość raportów kondycji określa dokładność widoku kondycji klastra. Fałszywie dodatnie, które błędnie pokazują problemy ze złą kondycją, mogą negatywnie wpłynąć na uaktualnienia lub inne usługi korzystające z danych dotyczących kondycji. Przykładami takich usług są usługi naprawy i mechanizmy zgłaszania alertów. W związku z tym, niektóre uważa się, że konieczne jest dostarczenie raportów, które przechwytują warunki zainteresowania w najlepszy możliwy sposób.
Aby zaprojektować i wdrożyć raportowanie kondycji, watchdogs i składniki systemu muszą:
- Zdefiniuj interesujący ich warunek, sposób jego monitorowania oraz wpływ na działanie klastra lub aplikacji. Na podstawie tych informacji zdecyduj, czy właściwość raportu kondycji i stan kondycji.
- Określ jednostkę, do którego ma zastosowanie raport.
- Określ, gdzie odbywa się raportowanie, z poziomu usługi lub z wewnętrznego lub zewnętrznego watchdoga.
- Zdefiniuj źródło używane do identyfikowania reportera.
- Wybierz strategię raportowania okresowo lub na przejściach. Zalecany sposób jest okresowo, ponieważ wymaga prostszego kodu i jest mniej podatny na błędy.
- Określ, jak długo raport dotyczący warunków złej kondycji powinien pozostać w magazynie kondycji i jak powinien zostać wyczyszczone. Korzystając z tych informacji, zdecyduj czas wygaśnięcia i usunięcia raportu.
Jak wspomniano, raportowanie można wykonywać z:
- Monitorowana replika usługi Service Fabric.
- Wewnętrznedogi wdrożone jako usługa Service Fabric (na przykład bezstanowa usługa Service Fabric, która monitoruje warunki i problemy raporty). Watchdogs można wdrożyć wszystkie węzły lub można je połączyć z monitorowaną usługą.
- Wewnętrzne elementy watchdog uruchamiane w węzłach usługi Service Fabric, ale nie są implementowane jako usługi Service Fabric.
- Zewnętrzne watchdogi sondujące zasób spoza klastra usługi Service Fabric (na przykład usługa monitorowania, taka jak Gomez).
Uwaga
Poza tym klaster jest wypełniany raportami kondycji wysyłanymi przez składniki systemowe. Przeczytaj więcej na temat korzystania z raportów kondycji systemu na potrzeby rozwiązywania problemów. Raporty użytkowników muszą być wysyłane na jednostki kondycji, które zostały już utworzone przez system.
Gdy projekt raportowania kondycji jest jasny, raporty o kondycji można łatwo wysyłać. Możesz użyć klasy FabricClient do raportowania kondycji, jeśli klaster nie jest bezpieczny lub jeśli klient sieci szkieletowej ma uprawnienia administratora. Raportowanie można wykonywać za pośrednictwem interfejsu API przy użyciu klasy FabricClient.HealthManager.ReportHealth, programu PowerShell lub interfejsu REST. Raporty wsadowe pokrętła konfiguracji w celu zwiększenia wydajności.
Uwaga
Kondycja raportu jest synchroniczna i reprezentuje tylko pracę weryfikacji po stronie klienta. Fakt, że raport jest akceptowany przez klienta kondycji lub obiekty lub Partition CodePackageActivationContext nie oznacza, że jest stosowany w magazynie. Jest on wysyłany asynchronicznie i prawdopodobnie wsadowy z innymi raportami. Przetwarzanie na serwerze może nadal zakończyć się niepowodzeniem: numer sekwencji może być nieaktualny, jednostka, na której należy zastosować raport, została usunięta itp.
Klient kondycji
Raporty kondycji są wysyłane do menedżera kondycji za pośrednictwem klienta kondycji, który znajduje się wewnątrz klienta sieci szkieletowej. Menedżer kondycji zapisuje raporty w magazynie kondycji. Klienta kondycji można skonfigurować przy użyciu następujących ustawień:
- HealthReportSendInterval: opóźnienie między czasem dodania raportu do klienta a czasem wysłania go do menedżera kondycji. Służy do wsadowania raportów do pojedynczego komunikatu, a nie wysyłania jednego komunikatu dla każdego raportu. Przetwarzanie wsadowe zwiększa wydajność. Wartość domyślna: 30 sekund.
- HealthReportRetrySendInterval: interwał, w którym klient kondycji ponownie wyślij raporty o kondycji do menedżera kondycji. Ustawienie domyślne: 30 sekund, minimum: 1 sekunda.
- HealthOperationTimeout: limit czasu komunikatu raportu wysyłanego do menedżera kondycji. Jeśli komunikat zostanie upłynął, klient kondycji ponawia próbę, dopóki menedżer kondycji nie potwierdzi, że raport został przetworzony. Ustawienie domyślne: dwie minuty.
Uwaga
Gdy raporty są wsadowe, klient sieci szkieletowej musi być utrzymywany przy życiu przez co najmniej HealthReportSendInterval, aby upewnić się, że są wysyłane. Jeśli komunikat zostanie utracony lub menedżer kondycji nie może ich zastosować z powodu błędów przejściowych, klient sieci szkieletowej musi być utrzymywany przy życiu dłużej, aby dać mu szansę na ponowienie próby.
Buforowanie na kliencie uwzględnia unikatowość raportów. Jeśli na przykład określony zły reporter zgłasza 100 raportów na sekundę w tej samej właściwości tej samej jednostki, raporty są zastępowane ostatnią wersją. W kolejce klienta istnieje co najwyżej jeden taki raport. Jeśli przetwarzanie wsadowe jest skonfigurowane, liczba raportów wysyłanych do menedżera kondycji to tylko jeden interwał wysyłania. Ten raport jest ostatnim dodanym raportem, który odzwierciedla najbardziej bieżący stan jednostki.
Określ parametry konfiguracji podczas FabricClient tworzenia, przekazując element FabricClientSettings z żądanymi wartościami dla wpisów związanych z kondycją.
Poniższy przykład tworzy klienta sieci szkieletowej i określa, że raporty powinny być wysyłane po dodaniu. W przypadku przekroczenia limitu czasu i błędów, które można ponowić, ponowne próby są wykonywane co 40 sekund.
var clientSettings = new FabricClientSettings()
{
HealthOperationTimeout = TimeSpan.FromSeconds(120),
HealthReportSendInterval = TimeSpan.FromSeconds(0),
HealthReportRetrySendInterval = TimeSpan.FromSeconds(40),
};
var fabricClient = new FabricClient(clientSettings);
Zalecamy zachowanie domyślnych ustawień klienta sieci szkieletowej, które mają wartość HealthReportSendInterval 30 sekund. To ustawienie zapewnia optymalną wydajność z powodu dzielenia na partie. W przypadku krytycznych raportów, które należy wysyłać tak szybko, jak to możliwe, należy użyć polecenia HealthReportSendOptions z interfejsem API Natychmiastowe w elemedycie true FabricClient.HealthClient.ReportHealth . Natychmiastowe raporty pomijają interwał dzielenia na partie. Użyj tej flagi z ostrożnością; Chcemy korzystać z przetwarzania wsadowego klienta kondycji, gdy jest to możliwe. Natychmiastowe wysyłanie jest również przydatne, gdy klient sieci szkieletowej zamyka (na przykład proces określił nieprawidłowy stan i musi zostać zamknięty, aby zapobiec skutkom ubocznym). Zapewnia to najlepsze nakłady pracy nad wysłaniem skumulowanych raportów. Po dodaniu jednego raportu z flagą natychmiastową klient kondycji wsaduje wszystkie skumulowane raporty od ostatniego wysłania.
Te same parametry można określić, gdy połączenie z klastrem jest tworzone za pomocą programu PowerShell. W poniższym przykładzie rozpoczyna się połączenie z klastrem lokalnym:
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
}
Podobnie jak w przypadku interfejsu API, raporty mogą być wysyłane przy użyciu -Immediate przełącznika do natychmiastowego wysyłania HealthReportSendInterval , niezależnie od wartości.
W przypadku interfejsu REST raporty są wysyłane do bramy usługi Service Fabric, która ma wewnętrznego klienta sieci szkieletowej. Domyślnie ten klient jest skonfigurowany do wysyłania raportów wsadowych co 30 sekund. Interwał wsadowy można zmienić za pomocą ustawienia HttpGatewayHealthReportSendInterval konfiguracji klastra w pliku HttpGateway. Jak wspomniano, lepszym rozwiązaniem jest wysłanie raportów z wartością Immediate true.
Uwaga
Aby upewnić się, że nieautoryzowane usługi nie mogą zgłaszać kondycji jednostek w klastrze, skonfiguruj serwer tak, aby akceptował żądania tylko od zabezpieczonych klientów. Funkcja używana do raportowania FabricClient musi mieć włączoną opcję zabezpieczeń, aby móc komunikować się z klastrem (na przykład przy użyciu protokołu Kerberos lub uwierzytelniania certyfikatu). Przeczytaj więcej na temat zabezpieczeń klastra.
Raport z poziomu usług o niskich uprawnieniach
Jeśli usługi Service Fabric nie mają dostępu administratora do klastra, możesz zgłosić kondycję jednostek z bieżącego kontekstu za pośrednictwem Partition lub CodePackageActivationContext.
- W przypadku usług bezstanowych użyj elementu IStatelessServicePartition.ReportInstanceHealth , aby zgłosić bieżące wystąpienie usługi.
- W przypadku usług stanowych użyj elementu IStatefulServicePartition.ReportReplicaHealth , aby raportować bieżącą replikę.
- Użyj elementu IServicePartition.ReportPartitionHealth , aby zgłosić bieżącą jednostkę partycji.
- Użyj polecenia CodePackageActivationContext.ReportApplicationHealth , aby raportować bieżącą aplikację.
- Użyj polecenia CodePackageActivationContext.ReportDeployedApplicationHealth , aby zgłosić bieżącą aplikację wdrożona w bieżącym węźle.
- Użyj polecenia CodePackageActivationContext.ReportDeployedServicePackageHealth , aby zgłosić pakiet usługi dla aplikacji wdrożonej w bieżącym węźle.
Uwaga
Wewnętrznie element Partition i CodePackageActivationContext przechowują klienta kondycji skonfigurowane z ustawieniami domyślnymi. Jak wyjaśniono dla klienta kondycji, raporty są wsadowe i wysyłane na czasomierz. Obiekty powinny być przechowywane przy życiu, aby mieć możliwość wysłania raportu.
Możesz określić HealthReportSendOptions podczas wysyłania raportów za pośrednictwem Partition interfejsów API kondycji i CodePackageActivationContext . Jeśli masz krytyczne raporty, które muszą być wysyłane tak szybko, jak to możliwe, użyj polecenia HealthReportSendOptions z bezpośrednim true. Natychmiastowe raporty pomijają interwał dzielenia na partie wewnętrznego klienta kondycji. Jak wspomniano wcześniej, użyj tej flagi pod opieką; Chcemy korzystać z przetwarzania wsadowego klienta kondycji, gdy jest to możliwe.
Projektowanie raportowania kondycji
Pierwszym krokiem generowania raportów o wysokiej jakości jest zidentyfikowanie warunków, które mogą mieć wpływ na kondycję usługi. Każdy warunek, który może pomóc flagować problemy w usłudze lub klastrze podczas uruchamiania — lub jeszcze lepiej, zanim wystąpi problem — może potencjalnie zaoszczędzić miliardy dolarów. Korzyści obejmują krótszy czas pracy, mniej godzin nocnych spędzonych na badaniach i naprawianiu problemów oraz wyższe zadowolenie klientów.
Po zidentyfikowaniu warunków pisarze watchdog muszą dowiedzieć się, jak najlepiej monitorować je pod kątem równowagi między obciążeniem a użytecznością. Rozważmy na przykład usługę, która wykonuje złożone obliczenia korzystające z niektórych plików tymczasowych w udziale. Watchdog może monitorować udział, aby upewnić się, że wystarczająca ilość miejsca jest dostępna. Może nasłuchiwać powiadomień o zmianach pliku lub katalogu. Może zgłosić ostrzeżenie, jeśli zostanie osiągnięty próg z góry, i zgłosić błąd, jeśli udział jest pełny. Na ostrzeżenie system naprawy może uruchomić czyszczenie starszych plików w udziale. W przypadku błędu system naprawy może przenieść replikę usługi do innego węzła. Zwróć uwagę, w jaki sposób stany warunku są opisane pod względem kondycji: stan warunku, który może być uznawany za w dobrej kondycji (ok) lub w złej kondycji (ostrzeżenie lub błąd).
Po ustawieniu szczegółów monitorowania pisarz watchdog musi dowiedzieć się, jak zaimplementować watchdog. Jeśli warunki można określić z poziomu usługi, watchdog może być częścią monitorowanej usługi. Na przykład kod usługi może sprawdzić użycie udziału, a następnie raport za każdym razem, gdy próbuje napisać plik. Zaletą tego podejścia jest to, że raportowanie jest proste. Należy zachować ostrożność, aby zapobiec wystąpieniu usterek watchdog wpływających na funkcjonalność usługi.
Raportowanie z poziomu monitorowanej usługi nie zawsze jest opcją. Watchdog w usłudze może nie być w stanie wykryć warunków. Może nie mieć logiki ani danych w celu ustalenia. Obciążenie związane z monitorowaniem warunków może być wysokie. Warunki mogą również nie być specyficzne dla usługi, ale zamiast tego wpływają na interakcje między usługami. Inną opcją jest posiadanie obserwatorów w klastrze jako oddzielne procesy. Watchdogs monitorują warunki i zgłaszają, nie wpływając na główne usługi w żaden sposób. Na przykład te elementy watchdogs można zaimplementować jako usługi bezstanowe w tej samej aplikacji, wdrożone we wszystkich węzłach lub w tych samych węzłach co usługa.
Czasami watchdog uruchomiony w klastrze nie jest też opcją. Jeśli monitorowany warunek jest dostępnością lub funkcjonalnością usługi, jak widzą ją użytkownicy, najlepiej jest mieć watchdogs w tym samym miejscu co klienci użytkowników. W tym miejscu mogą przetestować operacje w taki sam sposób, w jaki użytkownicy je nazywają. Na przykład możesz mieć watchdog, który znajduje się poza klastrem, wysyła żądania do usługi i sprawdza opóźnienie i poprawność wyniku. (Na przykład w przypadku usługi kalkulatora wartość 2+2 zwraca wartość 4 w rozsądnym czasie?)
Po sfinalizowaniu szczegółów watchdog należy zdecydować o identyfikatorze źródłowym, który jednoznacznie go identyfikuje. Jeśli w klastrze znajduje się wiele strażników tego samego typu, muszą raportować różne jednostki lub, jeśli raportują o tej samej jednostce, użyj innego identyfikatora źródłowego lub właściwości. W ten sposób ich raporty mogą współistnieć. Właściwość raportu kondycji powinna przechwytywać monitorowany warunek. (W powyższym przykładzie właściwość może być następująca:ShareSize.) Jeśli wiele raportów ma zastosowanie do tego samego warunku, właściwość powinna zawierać pewne informacje dynamiczne, które umożliwiają współistnienie raportów. Jeśli na przykład należy monitorować wiele udziałów, nazwa właściwości może mieć wartość ShareSize-sharename.
Uwaga
Nie używaj magazynu kondycji do przechowywania informacji o stanie. Należy zgłaszać tylko informacje dotyczące kondycji, ponieważ te informacje wpływają na ocenę kondycji jednostki. Magazyn kondycji nie został zaprojektowany jako magazyn ogólnego przeznaczenia. Używa logiki oceny kondycji do agregowania wszystkich danych do stanu kondycji. Wysyłanie informacji niepowiązanych z kondycją (na przykład stanu raportowania ze stanem kondycji OK) nie ma wpływu na zagregowany stan kondycji, ale może negatywnie wpłynąć na wydajność magazynu kondycji.
Następnym punktem decyzyjnym jest jednostka do raportowania. W większości przypadków warunek wyraźnie identyfikuje jednostkę. Wybierz jednostkę z najlepszym możliwym szczegółowością. Jeśli warunek ma wpływ na wszystkie repliki w partycji, zgłoś partycję, a nie w usłudze. Istnieją jednak przypadki, w których potrzebna jest większa myśl. Jeśli warunek ma wpływ na jednostkę, taką jak replika, ale pragnieniem jest oflagowanie warunku przez więcej niż czas trwania okresu eksploatacji repliki, należy zgłosić go na partycji. W przeciwnym razie po usunięciu repliki magazyn kondycji czyści wszystkie raporty. Pisarze watchdog muszą myśleć o okresach istnienia jednostki i raportu. Musi być jasne, kiedy raport powinien zostać wyczyszczony ze sklepu (na przykład gdy w jednostce nie ma już zastosowania błąd).
Przyjrzyjmy się przykładowi, który łączy opisane przeze mnie punkty. Rozważmy aplikację usługi Service Fabric składającą się z głównej stanowej usługi trwałej i pomocniczych usług bezstanowych wdrożonych na wszystkich węzłach (jeden pomocniczy typ usługi dla każdego typu zadania). Wzorzec ma kolejkę przetwarzania zawierającą polecenia, które mają być wykonywane przez moduły pomocnicze. Sekundy wykonują żądania przychodzące i wysyłają sygnały potwierdzenia. Jednym z warunków, które można monitorować, jest długość kolejki przetwarzania głównego. Jeśli długość kolejki głównej osiągnie próg, zostanie zgłoszone ostrzeżenie. Ostrzeżenie wskazuje, że sekundy nie mogą obsłużyć obciążenia. Jeśli kolejka osiągnie maksymalną długość, a polecenia zostaną porzucone, zgłaszany jest błąd, ponieważ usługa nie może odzyskać. Raporty mogą znajdować się we właściwości QueueStatus. Watchdog mieszka wewnątrz usługi i jest okresowo wysyłany do głównej repliki podstawowej. Czas wygaśnięcia wynosi dwie minuty i jest okresowo wysyłany co 30 sekund. Jeśli podstawowy ulegnie awarii, raport zostanie automatycznie wyczyszczony ze sklepu. Jeśli replika usługi jest włączona, ale jest zakleszona lub ma inne problemy, raport wygasa w magazynie kondycji. W takim przypadku jednostka jest oceniana pod kątem błędu.
Innym warunkiem, który można monitorować, jest czas wykonywania zadania. Wzorzec dystrybuuje zadania do serwerów pomocniczych na podstawie typu zadania. W zależności od projektu wzorzec może sondować pomocnicze pod kątem stanu zadania. Może również poczekać na wysłanie sygnałów potwierdzenia zwrotu, gdy zostaną one wykonane. W drugim przypadku należy zachować ostrożność w celu wykrywania sytuacji, w których drugich umiera lub komunikaty są utracone. Jedną z opcji jest wysłanie żądania ping do tego samego pomocniczego żądania ping, które wysyła z powrotem jego stan. Jeśli żaden stan nie zostanie odebrany, serwer główny uzna go za błąd i ponownie przesunie zadanie. To zachowanie zakłada, że zadania są idempotentne.
Monitorowany warunek można przetłumaczyć jako ostrzeżenie, jeśli zadanie nie zostanie wykonane w określonym czasie (t1, na przykład 10 minut). Jeśli zadanie nie zostało ukończone w czasie (t2, na przykład 20 minut), monitorowany warunek można przetłumaczyć jako Błąd. To raportowanie można wykonywać na wiele sposobów:
- Główna replika podstawowa okresowo raportuje się na siebie. Możesz mieć jedną właściwość dla wszystkich oczekujących zadań w kolejce. Jeśli co najmniej jedno zadanie trwa dłużej, stan raportu właściwości PendingTasks jest ostrzeżeniem lub błędem, zgodnie z potrzebami. Jeśli nie ma oczekujących zadań lub wszystkie uruchomione zadania podrzędne, stan raportu to OK. Zadania są trwałe. Jeśli podstawowy ulegnie awarii, nowo podwyższony poziom podstawowy może nadal prawidłowo raportować.
- Inny proces watchdog (w chmurze lub zewnętrznej) sprawdza zadania (spoza, na podstawie żądanego wyniku zadania), aby sprawdzić, czy zostały ukończone. Jeśli nie przestrzegają progów, raport zostanie wysłany w usłudze głównej. Raport jest również wysyłany dla każdego zadania zawierającego identyfikator zadania, na przykład PendingTask+taskId. Raporty powinny być wysyłane tylko w stanach złej kondycji. Ustaw czas wygaśnięcia na kilka minut i oznacz raporty, które mają zostać usunięte po wygaśnięciu, aby zapewnić czyszczenie.
- Pomocniczy, który wykonuje raporty zadań, gdy trwa dłużej niż oczekiwano, aby go uruchomić. Raportuje ono wystąpienie usługi we właściwości PendingTasks. Raport wskazuje wystąpienie usługi, które ma problemy, ale nie przechwytuje sytuacji, w której wystąpienie umiera. Raporty są następnie czyszczone. Może ona zgłaszać usługę pomocniczą. Jeśli pomocnicza ukończy zadanie, wystąpienie pomocnicze wyczyści raport ze sklepu. Raport nie przechwytuje sytuacji, w której komunikat potwierdzenia zostanie utracony, a zadanie nie zostanie zakończone z punktu widzenia głównego.
Jednak raportowanie odbywa się w opisanych powyżej przypadkach, raporty są przechwytywane w kondycji aplikacji po ocenie kondycji.
Raport okresowo a po przejściu
Korzystając z modelu raportowania kondycji, watchdogs mogą wysyłać raporty okresowo lub przy przejściach. Zalecanym sposobem raportowania watchdog jest okresowe, ponieważ kod jest znacznie prostszy i mniej podatny na błędy. Watchdogs muszą starać się być jak najprostsze, aby uniknąć błędów, które wyzwalają nieprawidłowe raporty. Niepoprawne raporty w złej kondycji wpływają na oceny kondycji i scenariusze na podstawie kondycji, w tym uaktualnień. Niepoprawne raporty w dobrej kondycji ukrywają problemy w klastrze, co nie jest pożądane.
W przypadku okresowego raportowania watchdog można zaimplementować za pomocą czasomierza. Na wywołaniu zwrotnym czasomierza watchdog może sprawdzić stan i wysłać raport na podstawie bieżącego stanu. Nie ma potrzeby, aby zobaczyć, który raport został wysłany wcześniej lub dokonać żadnych optymalizacji pod względem obsługi komunikatów. Klient kondycji ma logikę dzielenia na partie, aby pomóc w wydajności. Podczas gdy klient kondycji jest utrzymywany przy życiu, ponawia próbę wewnętrznie, dopóki raport nie zostanie potwierdzony przez magazyn kondycji lub watchdog generuje nowszy raport z tą samą jednostką, właściwością i źródłem.
Raportowanie przejść wymaga starannej obsługi stanu. Watchdog monitoruje niektóre warunki i zgłasza tylko wtedy, gdy warunki się zmienią. Wadą tego podejścia jest to, że potrzebna jest mniejsza liczba raportów. Wadą jest to, że logika watchdog jest złożona. Watchdog musi utrzymywać warunki lub raporty, aby można było je sprawdzić w celu określenia zmian stanu. W trybie failover należy zachować ostrożność z dodanymi raportami, ale nie są jeszcze wysyłane do magazynu kondycji. Liczba sekwencji musi być coraz większa. Jeśli nie, raporty są odrzucane jako nieaktualne. W rzadkich przypadkach, w których występuje utrata danych, może być wymagana synchronizacja między stanem reportera a stanem magazynu kondycji.
Raportowanie na temat przejść ma sens w przypadku usług raportowania dla siebie, za pośrednictwem Partition lub CodePackageActivationContext. Po usunięciu obiektu lokalnego (repliki lub wdrożonego pakietu usługi/wdrożonej aplikacji) wszystkie jego raporty również zostaną usunięte. To automatyczne czyszczenie pozwala złagodzić potrzebę synchronizacji między magazynem reportera i magazynu kondycji. Jeśli raport dotyczy partycji nadrzędnej lub aplikacji nadrzędnej, należy zachować ostrożność w trybie failover, aby uniknąć nieaktualnych raportów w magazynie kondycji. Logikę należy dodać, aby zachować prawidłowy stan i wyczyścić raport ze sklepu, gdy nie będzie już potrzebny.
Implementowanie raportowania kondycji
Gdy szczegóły jednostki i raportu będą jasne, wysyłanie raportów dotyczących kondycji można wykonać za pośrednictwem interfejsu API, programu PowerShell lub rest.
interfejs API
Aby raportować za pośrednictwem interfejsu API, musisz utworzyć raport kondycji specyficzny dla typu jednostki, dla którego chcesz raportować. Nadaj raport klientowi kondycji. Alternatywnie możesz utworzyć informacje o kondycji i przekazać je do poprawnych metod Partition raportowania lub CodePackageActivationContext raportować bieżące jednostki.
W poniższym przykładzie przedstawiono okresowe raportowanie z usługi watchdog w klastrze. Watchdog sprawdza, czy można uzyskać dostęp do zasobu zewnętrznego z poziomu węzła. Zasób jest wymagany przez manifest usługi w aplikacji. Jeśli zasób jest niedostępny, inne usługi w aplikacji mogą nadal działać prawidłowo. W związku z tym raport jest wysyłany do jednostki wdrożonego pakietu usługi co 30 sekund.
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
Wysyłanie raportów dotyczących kondycji za pomocą polecenia Send-ServiceFabricEntityTypeHealthReport.
W poniższym przykładzie przedstawiono okresowe raportowanie wartości procesora CPU w węźle. Raporty powinny być wysyłane co 30 sekund i mają czas wygaśnięcia dwóch minut. Jeśli wygasną, reporter ma problemy, więc węzeł zostanie oceniony pod kątem błędu. Gdy procesor CPU przekracza próg, raport ma stan kondycji ostrzeżenia. Gdy procesor cpu pozostaje powyżej progu przez więcej niż skonfigurowany czas, jest zgłaszany jako błąd. W przeciwnym razie reporter wysyła stan zdrowia OK.
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
Poniższy przykład zgłasza przejściowe ostrzeżenie w repliki. Najpierw pobiera identyfikator partycji, a następnie identyfikator repliki dla usługi, która jest zainteresowana. Następnie wysyła raport z programu PowershellWatcher do właściwości ResourceDependency. Raport jest interesujący tylko przez dwie minuty i jest automatycznie usuwany ze sklepu.
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
Wysyłanie raportów dotyczących kondycji przy użyciu interfejsu REST z żądaniami POST, które przechodzą do żądanej jednostki i mają w treści opis raportu kondycji. Zobacz na przykład, jak wysyłać raporty kondycji klastra REST lub raporty kondycji usługi. Wszystkie jednostki są obsługiwane.
Następne kroki
Na podstawie danych dotyczących kondycji autorzy usług i administratorzy klastra/aplikacji mogą myśleć o sposobach korzystania z tych informacji. Mogą na przykład skonfigurować alerty na podstawie stanu kondycji, aby przechwycić poważne problemy, zanim wywołają awarie. Administratorzy mogą również skonfigurować systemy naprawy w celu automatycznego rozwiązywania problemów.
Wprowadzenie do monitorowania kondycji usługi Service Fabric
Wyświetlanie raportów kondycji usługi Service Fabric
Jak zgłaszać i sprawdzać kondycję usługi
Używanie raportów kondycji systemu do rozwiązywania problemów