Udostępnij za pośrednictwem

Monitorowanie klastra

  • Artykuł

Ważne jest, aby monitorować na poziomie klastra, aby określić, czy sprzęt i klaster działają zgodnie z oczekiwaniami. Mimo że usługa Service Fabric może nadal działać podczas awarii sprzętu, ale nadal trzeba zdiagnozować, czy w aplikacji lub w podstawowej infrastrukturze występuje błąd. Należy również monitorować klastry, aby lepiej zaplanować pojemność, pomagając w podejmowaniu decyzji dotyczących dodawania lub usuwania sprzętu.

Usługa Service Fabric uwidacznia kilka zdarzeń platformy ustrukturyzowanej, jako zdarzenia usługi Service Fabric, za pośrednictwem magazynu zdarzeń i różnych kanałów rejestrowania gotowego do użycia.

W systemie Windows zdarzenia usługi Service Fabric są dostępne u pojedynczego dostawcy ETW z zestawem odpowiednich logLevelKeywordFilters elementów używanych do wybierania między kanałami operacyjnymi i datami i komunikatami — jest to sposób oddzielania wychodzących zdarzeń usługi Service Fabric do filtrowania zgodnie z potrzebami.

  • Operacyjne operacje wysokiego poziomu wykonywane przez usługę Service Fabric i klaster, w tym zdarzenia dla węzła, wdrażaną nową aplikację lub wycofywanie uaktualnienia itp. Zobacz pełną listę zdarzeń tutaj.

  • Operacyjne — szczegółowe informacje
    Raporty dotyczące kondycji i decyzje dotyczące równoważenia obciążenia.

Dostęp do kanału operacji można uzyskać na różne sposoby, w tym dzienniki zdarzeń ETW/Windows, magazyn zdarzeń (dostępny w systemie Windows w wersjach 6.2 i nowszych dla klastrów systemu Windows). Magazyn zdarzeń zapewnia dostęp do zdarzeń klastra na podstawie jednostki (jednostek, w tym klastra, węzłów, aplikacji, usług, partycji, replik i kontenerów) i uwidacznia je za pośrednictwem interfejsów API REST i biblioteki klienta usługi Service Fabric. Użyj magazynu zdarzeń, aby monitorować klastry tworzenia i testowania oraz uzyskać informacje na temat stanu klastrów produkcyjnych w czasie.

  • Dane i obsługa komunikatów
    Dzienniki krytyczne i zdarzenia generowane w komunikatach (obecnie tylko ReverseProxy) i ścieżki danych (modele niezawodnych usług).

  • Dane i obsługa komunikatów — szczegółowe informacje
    Pełny kanał zawierający wszystkie niekrytyczne dzienniki z danych i komunikatów w klastrze (ten kanał ma dużą liczbę zdarzeń).

Oprócz tych dostępnych jest dwa ustrukturyzowane kanały EventSource, a także dzienniki zbierane do celów pomocy technicznej.

Te różne kanały obejmują większość zalecanych rejestrowania na poziomie platformy. Aby poprawić rejestrowanie na poziomie platformy, rozważ zainwestowanie w lepsze zrozumienie modelu kondycji i dodanie niestandardowych raportów o kondycji oraz dodanie niestandardowych liczników wydajności w celu utworzenia w czasie rzeczywistym zrozumienia wpływu usług i aplikacji na klaster.

Aby móc korzystać z tych dzienników, zdecydowanie zaleca się pozostawienie opcji "Diagnostyka" włączona podczas tworzenia klastra w witrynie Azure Portal. Po włączeniu diagnostyki, gdy klaster jest wdrożony, Diagnostyka Azure jest w stanie potwierdzić kanały operacyjne, reliable services i reliable actors oraz przechowywać dane zgodnie z wyjaśnieniem w artykule Agregowanie zdarzeń za pomocą Diagnostyka Azure.

Raportowanie kondycji i obciążenia usługi Azure Service Fabric

Usługa Service Fabric ma własny model kondycji, który został szczegółowo opisany w następujących artykułach:

Monitorowanie kondycji ma kluczowe znaczenie dla wielu aspektów działania usługi, zwłaszcza podczas uaktualniania aplikacji. Po uaktualnieniu każdej domeny uaktualnienia usługi domena uaktualniania musi przejść testy kondycji przed przejściem wdrożenia do następnej domeny uaktualnienia. Jeśli nie można osiągnąć stanu kondycji OK, wdrożenie zostanie wycofane, aby aplikacja pozostała w znanym stanie OK. Chociaż niektórzy klienci mogą mieć wpływ na wycofanie usług, większość klientów nie napotka problemu. Ponadto rozwiązanie występuje stosunkowo szybko bez konieczności oczekiwania na akcję od operatora ludzkiego. Tym więcej kontroli kondycji jest uwzględnionych w kodzie, tym bardziej odporna jest usługa na problemy z wdrażaniem.

Innym aspektem kondycji usługi jest raportowanie metryk z usługi. Metryki są ważne w usłudze Service Fabric, ponieważ są używane do równoważenia użycia zasobów. Metryki mogą być również wskaźnikiem kondycji systemu. Na przykład może istnieć aplikacja, która ma wiele usług, a każde wystąpienie zgłasza metrykę żądań na sekundę (RPS). Jeśli jedna usługa używa więcej zasobów niż inna usługa, usługa Service Fabric przenosi wystąpienia usługi wokół klastra, aby spróbować zachować nawet wykorzystanie zasobów. Aby uzyskać bardziej szczegółowe wyjaśnienie sposobu działania wykorzystania zasobów, zobacz Zarządzanie użyciem zasobów i ładowaniem w usłudze Service Fabric przy użyciu metryk.

Metryki mogą również pomóc w sposobie działania usługi. W miarę upływu czasu możesz użyć metryk, aby sprawdzić, czy usługa działa w ramach oczekiwanych parametrów. Jeśli na przykład trendy pokazują, że o 9:00 w poniedziałek rano średnia wartość RPS wynosi 1000, możesz skonfigurować raport kondycji, który ostrzega Użytkownika, jeśli PUNKTS jest poniżej 500 lub powyżej 1500. Wszystko może być w porządku, ale warto spojrzeć, aby upewnić się, że twoi klienci mają wspaniałe doświadczenie. Usługa może zdefiniować zestaw metryk, które mogą być zgłaszane do celów kontroli kondycji, ale nie mają wpływu na równoważenie zasobów klastra. W tym celu ustaw wagę metryki na zero. Zalecamy rozpoczęcie wszystkich metryk o wadze zerowej i nie zwiększenie wagi, dopóki nie wiesz, jak wagi metryk wpływają na równoważenie zasobów dla klastra.

Napiwek

Nie używaj zbyt wielu ważonych metryk. Trudno zrozumieć, dlaczego wystąpienia usług są przenoszone na potrzeby równoważenia. Kilka metryk może przejść długą drogę!

Wszelkie informacje, które mogą wskazywać kondycję i wydajność aplikacji, są kandydatem do metryk i raportów dotyczących kondycji. Licznik wydajności procesora CPU może powiedzieć, jak jest używany węzeł, ale nie informuje, czy określona usługa jest w dobrej kondycji, ponieważ wiele usług może być uruchomionych w jednym węźle. Jednak metryki, takie jak RPS, przetworzone elementy i opóźnienie żądań, mogą wskazywać kondycję określonej usługi.

Dzienniki obsługi usługi Service Fabric

Jeśli musisz skontaktować się z pomocą techniczną firmy Microsoft, aby uzyskać pomoc dotyczącą klastra usługi Azure Service Fabric, dzienniki pomocy technicznej są prawie zawsze wymagane. Jeśli klaster jest hostowany na platformie Azure, dzienniki pomocy technicznej są automatycznie konfigurowane i zbierane w ramach tworzenia klastra. Dzienniki są przechowywane na dedykowanym koncie magazynu w grupie zasobów klastra. Konto magazynu nie ma stałej nazwy, ale na koncie zobaczysz kontenery obiektów blob i tabele o nazwach rozpoczynających się od sieci szkieletowej. Aby uzyskać informacje na temat konfigurowania kolekcji dzienników dla klastra autonomicznego, zobacz Tworzenie autonomicznego klastra usługi Azure Service Fabric i ustawienia konfiguracji dla autonomicznego klastra systemu Windows i zarządzanie nimi. W przypadku autonomicznych wystąpień usługi Service Fabric dzienniki powinny być wysyłane do lokalnego udziału plików. Te dzienniki są wymagane do uzyskania pomocy technicznej, ale nie są przeznaczone do użycia przez nikogo spoza zespołu pomocy technicznej firmy Microsoft.

Mierzenie wydajności

Mierzenie wydajności klastra w celu ułatwienia zrozumienia sposobu obsługi obciążenia i podejmowania decyzji dotyczących skalowania klastra (zobacz więcej na temat skalowania klastra na platformie Azure lub w środowisku lokalnym). Dane wydajności są również przydatne w porównaniu z akcjami, które mogły zostać wykonane przez Ciebie lub twoje aplikacje i usługi podczas analizowania dzienników w przyszłości.

Aby uzyskać listę liczników wydajności do zebrania podczas korzystania z usługi Service Fabric, zobacz Metryki wydajności

Poniżej przedstawiono dwa typowe sposoby konfigurowania zbierania danych wydajności dla klastra:

  • Korzystanie z agenta
    Jest to preferowany sposób zbierania wydajności z maszyny, ponieważ agenci zazwyczaj mają listę możliwych metryk wydajności, które można zebrać, i jest to stosunkowo łatwy proces wybierania metryk, które chcesz zebrać lub zmienić. Przeczytaj o usłudze Azure Monitor oferującą dzienniki usługi Azure Monitor w ramach integracji dzienników usługi Azure Monitor usługi Service Fabric i Skonfigurowanie agenta usługi Log Analytics, aby dowiedzieć się więcej o agencie usługi Log Analytics, który jest jednym z takich agentów monitorowania, który może pobierać dane wydajności dla maszyn wirtualnych klastra i wdrożonych kontenerów.

  • Liczniki wydajności w usłudze Azure Table Storage
    Możesz również wysyłać metryki wydajności do tego samego magazynu tabel co zdarzenia. Wymaga to zmiany konfiguracji Diagnostyka Azure w celu pobrania odpowiednich liczników wydajności z maszyn wirtualnych w klastrze i umożliwienia pobierania statystyk platformy Docker, jeśli zostaną wdrożone kontenery. Przeczytaj o konfigurowaniu liczników wydajności w usłudze WAD w usłudze Service Fabric w celu skonfigurowania zbierania liczników wydajności.

Następne kroki