Dodawanie niestandardowych raportów kondycji usługi Service Fabric

  • Artykuł

Usługa Azure Service Fabric wprowadza model kondycji przeznaczony do flagowania złej kondycji klastra i warunków aplikacji w określonych jednostkach. Model kondycji używa reporterów kondycji (składników systemowych i watchdogów). Celem jest łatwa i szybka diagnoza i naprawa. Autorzy 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 blisko katalogu głównego. Informacje o kondycji mogą zaoszczędzić czas i nakład pracy na debugowanie i badanie. 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 lokalnego widoku. Magazyn kondycji agreguje dane kondycji wysyłane przez wszystkich reporterów w celu ustalenia, 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 o kondycji. Przykłady takich usług to usługi naprawy i mechanizmy zgłaszania alertów. W związku z tym niektóre myśli są potrzebne do zapewnienia raportów, które przechwytują warunki zainteresowania w najlepszy możliwy sposób.

Aby zaprojektować i zaimplementować raportowanie kondycji, usługi 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 decydujesz się na właściwość raportu kondycji i stan kondycji.
  • Określ jednostkę , do którego ma zastosowanie raport.
  • Ustal, gdzie odbywa się raportowanie, z poziomu usługi lub z wewnętrznego lub zewnętrznego strażnika.
  • Zdefiniuj źródło używane do identyfikacji reportera.
  • Wybierz strategię raportowania okresowo lub w przypadku przejść. Zalecany sposób jest okresowy, ponieważ wymaga prostszego kodu i jest mniej podatny na błędy.
  • Określ, jak długo raport dotyczący warunków w złej kondycji powinien pozostać w magazynie kondycji i jak powinien zostać wyczyszczone. Korzystając z tych informacji, zdecyduj czas wygaśnięcia raportu i zachowanie usuwania na czas wygaśnięcia.

Jak wspomniano, raportowanie można wykonywać z:

  • Monitorowana replika usługi Service Fabric.
  • Wewnętrzne watchdogs wdrożone jako usługa Service Fabric (na przykład usługa bezstanowa usługi Service Fabric, która monitoruje warunki i problemy raporty). Watchdogs można wdrożyć wszystkie węzły lub być zainicjowane w monitorowanej usłudze.
  • Wewnętrzne elementy watchdog uruchamiane w węzłach usługi Service Fabric, ale nie są implementowane jako usługi Service Fabric.
  • Zewnętrzni obserwatorzy sondujący zasób spoza klastra usługi Service Fabric (na przykład usługę monitorowania, np. Gomez).

Uwaga

Poza tym klaster jest wypełniany raportami kondycji wysyłanymi przez składniki systemowe. Przeczytaj więcej na stronie Korzystanie z raportów kondycji systemu na potrzeby rozwiązywania problemów. Raporty użytkowników muszą być wysyłane w jednostkach kondycji , które zostały już utworzone przez system.

Gdy projekt raportowania kondycji jest jasny, raporty o kondycji można łatwo wysyłać. Element FabricClient umożliwia raportowanie kondycji, jeśli klaster nie jest bezpieczny lub klient sieci szkieletowej ma uprawnienia administratora. Raportowanie można wykonywać za pośrednictwem interfejsu API za pomocą 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ę weryfikacyjną po stronie klienta. Fakt, że raport jest akceptowany przez klienta kondycji lub obiekty lub PartitionCodePackageActivationContext 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. Klient kondycji można skonfigurować przy użyciu następujących ustawień:

  • HealthReportSendInterval: opóźnienie między czasem dodania raportu do klienta i czasu 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 przekazuje skumulowane raporty o kondycji do menedżera kondycji. Ustawienie domyślne: 30 sekund, minimum: 1 sekunda.
  • HealthOperationTimeout: limit czasu dla komunikatu raportu wysł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 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 ich dodaniu. W przypadku przekroczenia limitu czasu i błędów, które można ponowić, ponawianie prób następuje 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 są ustawione HealthReportSendInterval na 30 sekund. To ustawienie zapewnia optymalną wydajność z powodu przetwarzania wsadowego. W przypadku krytycznych raportów, które muszą być wysyłane tak szybko, jak to możliwe, należy użyć z HealthReportSendOptions interfejsem API Natychmiastowe true w elemecie FabricClient.HealthClient.ReportHealth . Natychmiastowe raporty pomijają interwał dzielenia na partie. Użyj tej flagi z opieką; Chcemy skorzystać 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 wysyłane ze 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. Poniższy przykład uruchamia 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 można wysyłać przy użyciu -Immediate przełącznika do natychmiastowego HealthReportSendInterval wysyłania, 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 na .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 względem jednostek w klastrze, skonfiguruj serwer tak, aby akceptował żądania tylko od zabezpieczonych klientów. Używane do raportowania FabricClient muszą mieć włączone zabezpieczenia, aby móc komunikować się z klastrem (na przykład z uwierzytelnianiem kerberos lub certyfikatem). 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 programu Partition lub CodePackageActivationContext.

Uwaga

Wewnętrznie element Partition i CodePackageActivationContext przechowują klienta kondycji skonfigurowanego z ustawieniami domyślnymi. Jak wyjaśniono dla klienta kondycji, raporty są wsadowe i wysyłane na czasomierz. Obiekty powinny być utrzymywane przy życiu, aby móc wysłać raport.

Można 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 z opieką; Chcemy skorzystać z przetwarzania wsadowego klienta kondycji, gdy jest to możliwe.

Projektowanie raportowania kondycji

Pierwszym krokiem generowania raportów 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ższą satysfakcję klientów.

Po zidentyfikowaniu warunków pisarze watchdog muszą ustalić najlepszy sposób monitorowania ich 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 zapewnić dostępność wystarczającej ilości miejsca. Może nasłuchiwać powiadomień o zmianach plików lub katalogów. Może zgłosić ostrzeżenie, jeśli próg z góry zostanie osiągnięty, i zgłosić błąd, jeśli udział jest pełny. W przypadku ostrzeżenia system naprawy może rozpocząć 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ę, jak 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 wpływowi błędów usługi watchdog 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 strażników w klastrze jako oddzielnych procesów. Obserwatorzy monitorują warunki i raport, bez wpływu na główne usługi w żaden sposób. Na przykład te 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 usługa watchdog uruchomiona 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ć strażnika, 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, czy 2+2 zwraca 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 wiele strażników tego samego typu mieszka w klastrze, muszą raportować różne jednostki lub, jeśli raportują o tej samej jednostce, użyj innego identyfikatora źródła lub właściwości. W ten sposób ich raporty mogą współistnieć. Właściwość raportu kondycji powinna przechwytywać monitorowany warunek. (Na przykład powyżej właściwość może być 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 być ShareSize-sharename.

Uwaga

Nie używaj magazynu kondycji, aby przechowywać informacje o stanie. Tylko informacje dotyczące kondycji powinny być zgłaszane jako kondycja, 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 w stanie kondycji. Wysyłanie informacji niepowiązanych z kondycją (na przykład stanu raportowania ze stanem kondycji ok) nie wpływa na stan zagregowanej 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 stopień szczegółowości. Jeśli warunek ma wpływ na wszystkie repliki w partycji, zgłoś partycję, a nie w usłudze. Istnieją przypadki narożne, w których potrzebna jest jednak większa myśl. Jeśli warunek ma wpływ na jednostkę, taką jak replika, ale pragnieniem jest oflagowanie warunku przez dłuższy niż czas trwania okresu życia 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 z magazynu (na przykład gdy błąd zgłoszony w jednostce nie ma już zastosowania).

Przyjrzyjmy się przykładowi, który łączy opisane kwestie. Rozważ aplikację usługi Service Fabric składającą się z głównej usługi trwałej i usług bezstanowych pomocniczych wdrożonych we 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 moduły pomocnicze nie mogą obsłużyć obciążenia. Jeśli kolejka osiągnie maksymalną długość, a polecenia zostaną porzucone, zostanie zgłoszony błąd, ponieważ usługa nie może odzyskać. Raporty mogą znajdować się we właściwości QueueStatus. Watchdog mieszka w usłudze i jest okresowo wysyłany na głównej repliki podstawowej. Czas wygaśnięcia wynosi dwie minuty i jest wysyłany okresowo co 30 sekund. Jeśli podstawowy ulegnie awarii, raport zostanie wyczyszczony automatycznie ze sklepu. Jeśli replika usługi jest w górę, ale jest zakleszona lub ma inne problemy, raport wygaśnie 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ć sekundy stanu zadania. Może również poczekać na wysłanie sygnałów potwierdzenia zwrotu po ich zakończeniu. W drugim przypadku należy zachować ostrożność, aby wykryć sytuacje, w których sekundy umierają lub komunikaty zostaną utracone. Jedną z opcji jest wysłanie żądania ping do tej samej pomocniczej, która wysyła z powrotem jego stan. Jeśli żaden stan nie zostanie odebrany, główny uzna go za niepowodzenie 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 zostało 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ę. Można 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 zadania zostały uruchomione, stan raportu to OK. Zadania są trwałe. Jeśli podstawowy ulegnie awarii, nowo promowana podstawowa może nadal prawidłowo raportować.
  • Inny proces watchdog (w chmurze lub zewnętrznej) sprawdza zadania (z zewnątrz, 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 on 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 raportować usługę pomocniczą. Jeśli pomocnicza zakoń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 ukończone z punktu widzenia wzorca.

Jednak raportowanie odbywa się w opisanych powyżej przypadkach, raporty są przechwytywane w kondycji aplikacji po ocenie kondycji.

Okresowe raportowanie w porównaniu z przejściem

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ą dążyć do jak najprostszego, 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ń. Nieprawidłowe raporty w dobrej kondycji ukrywają problemy w klastrze, co nie jest pożądane.

W przypadku okresowego raportowania watchdog można zaimplementować za pomocą czasomierza. Podczas wywołania zwrotnego czasomierza watchdog może sprawdzić stan i wysłać raport na podstawie bieżącego stanu. Nie ma potrzeby wcześniejszego wysyłania raportu ani dokonywania 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ę zmieniają. 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. Podczas pracy w trybie failover należy zadbać o dodanie raportów, ale nie zostały jeszcze wysłane do magazynu kondycji. Liczba sekwencyjna musi być stale zwiększana. Jeśli nie, raporty zostaną odrzucone jako nieaktualne. W rzadkich przypadkach utraty danych może być wymagana synchronizacja między stanem reportera a stanem magazynu kondycji.

Raportowanie przejść ma sens w przypadku usług raportowania dla samych siebie, za pośrednictwem Partition lub CodePackageActivationContext. Po usunięciu obiektu lokalnego (repliki lub wdrożonej aplikacji usługi/ wdrożonej aplikacji) wszystkie jego raporty są również usuwane. To automatyczne czyszczenie łagodzi potrzebę synchronizacji między magazynem reporterów i kondycji. Jeśli raport dotyczy partycji nadrzędnej lub aplikacji nadrzędnej, należy zachować ostrożność podczas pracy 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 jest już potrzebny.

Implementowanie raportowania kondycji

Gdy szczegóły jednostki i raportu będą jasne, wysyłanie raportów o kondycji można wykonać za pośrednictwem interfejsu API, programu PowerShell lub interfejsu REST.

interfejs API

Aby raportować za pośrednictwem interfejsu API, należy utworzyć raport kondycji specyficzny dla typu jednostki, dla którego ma być raport. Przekaż raport klientowi kondycji. Alternatywnie możesz utworzyć informacje o kondycji i przekazać je w celu skorygowania metod Partition raportowania lub CodePackageActivationContext raportowania bieżących jednostek.

W poniższym przykładzie przedstawiono okresowe raportowanie z usługi watchdog w klastrze. Usługa Watchdog sprawdza, czy dostęp do zasobu zewnętrznego można uzyskać 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 nadal mogą działać prawidłowo. W związku z tym raport jest wysyłany do jednostki wdrożonego pakietu usług 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 o 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 pozostaje powyżej progu przez więcej niż skonfigurowany czas, jest zgłaszany jako błąd. W przeciwnym razie reporter wysyła stan kondycji 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 ostrzeżenie przejściowe 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 o 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, aby automatycznie rozwiązywać problemy.

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

Korzystanie z raportów kondycji systemu na potrzeby rozwiązywania problemów

Lokalne monitorowanie i diagnozowanie usług

Uaktualnianie aplikacji usługi Service Fabric