Modelowanie kondycji dla obciążeń o krytycznym znaczeniu
Monitorowanie aplikacji i infrastruktury jest ważną częścią każdego wdrożenia infrastruktury. W przypadku obciążenia o krytycznym znaczeniu monitorowanie jest krytyczną częścią wdrożenia. Monitorowanie kondycji aplikacji i kluczowych metryk zasobów platformy Azure pomaga zrozumieć, czy środowisko działa zgodnie z oczekiwaniami.
Aby w pełni zrozumieć te metryki i ocenić ogólną kondycję obciążenia, wymaga całościowego zrozumienia wszystkich monitorowanych danych. Model kondycji może pomóc w ocenie ogólnego stanu kondycji, wyświetlając wyraźne wskazanie kondycji obciążenia zamiast nieprzetworzonych metryk. Stan jest często przedstawiany jako wskaźniki "światła drogowego", takie jak czerwony, zielony lub żółty. Reprezentacja modelu kondycji z jasnymi wskaźnikami ułatwia operatorowi zrozumienie ogólnej kondycji obciążenia i szybkie reagowanie na pojawiające się problemy.
Modelowanie kondycji można rozszerzyć na następujące zadania operacyjne dla wdrożenia o krytycznym znaczeniu:
Application Usługa kondycji — składnik aplikacji w klastrze obliczeniowym, który udostępnia interfejs API w celu określenia kondycji sygnatury.
Monitorowanie — zbieranie liczników wydajności i aplikacji, które oceniają kondycję i wydajność aplikacji i infrastruktury.
Alerty — alerty z możliwością działania dotyczące problemów lub awarii w infrastrukturze i aplikacji.
Analiza niepowodzeń — podział i analiza wszelkich awarii, w tym dokumentacja głównej przyczyny.
Te zadania stanowią kompleksowy model kondycji infrastruktury o krytycznym znaczeniu. Opracowywanie modelu kondycji może i powinno być wyczerpującą i integralną częścią każdego wdrożenia o znaczeniu krytycznym.
Aby uzyskać więcej informacji, zobacz Modelowanie kondycji i obserwowanie obciążeń o znaczeniu krytycznym na platformie Azure.
Usługa kondycji aplikacji
Aplikacja Usługa kondycji (HealthService) to składnik aplikacji, który znajduje się z usługą katalogu (CatalogService) i procesorem w tle (BackgroundProcessor) w klastrze obliczeniowym. Usługa HealthService udostępnia interfejs API REST dla usługi Azure Front Door do wywołania w celu określenia kondycji sygnatury. HealthService to złożony składnik, który odzwierciedla stan zależności, oprócz własnego.
Gdy klaster obliczeniowy nie działa, usługa kondycji nie odpowie. Gdy usługi są uruchomione, przeprowadza okresowe kontrole względem następujących składników w infrastrukturze:
Próbuje wykonać zapytanie względem usługi Azure Cosmos DB.
Próbuje wysłać komunikat do usługi Event Hubs. Komunikat jest filtrowany przez proces roboczy w tle.
Wyszukuje plik stanu na koncie magazynu. Ten plik może służyć do wyłączania regionu, nawet jeśli inne testy nadal działają poprawnie. Ten plik może służyć do komunikowania się z innymi procesami. Jeśli na przykład sygnatura ma zostać opuszczona do celów konserwacji, plik można usunąć, aby wymusić stan złej kondycji i przekierować ruch.
Wysyła zapytanie do modelu kondycji, aby określić, czy wszystkie metryki operacyjne znajdują się w wstępnie określonych progach. Gdy model kondycji wskazuje, że sygnatura jest w złej kondycji, ruch nie powinien być kierowany do sygnatury, mimo że inne testy, które usługa HealthService wykonuje pomyślnie. Model kondycji ma bardziej pełny widok stanu kondycji.
Wszystkie wyniki kontroli kondycji są buforowane w pamięci przez konfigurowalną liczbę sekund, domyślnie 10. Ta operacja może spowodować dodanie małego opóźnienia w wykrywaniu awarii, ale gwarantuje, że nie każde zapytanie HealthService wymaga wywołań zaplecza, co zmniejsza obciążenie klastra i usług podrzędnych.
Ten wzorzec buforowania jest ważny, ponieważ liczba zapytań Usługi kondycji znacznie rośnie w przypadku korzystania z routera globalnego, takiego jak Azure Front Door: każdy węzeł brzegowy w każdym centrum danych platformy Azure, które obsługuje żądania, wywoła Usługa kondycji w celu określenia, czy ma funkcjonalne połączenie zaplecza. Buforowanie wyników zmniejsza dodatkowe obciążenie klastra generowane przez kontrole kondycji.
Konfigurowanie
HealthService i CatalogService mają wspólne ustawienia konfiguracji między składnikami, z wyjątkiem następujących ustawień używanych wyłącznie przez usługę HealthService:
| Ustawienie | Wartość |
|---|---|
HealthServiceCacheDurationSeconds |
Określa czas wygaśnięcia pamięci podręcznej w sekundach. |
HealthServiceStorageConnectionString |
Parametry połączenia dla konta magazynu, w którym powinien znajdować się plik stanu. |
HealthServiceBlobContainerName |
Kontener magazynu, w którym powinien znajdować się plik stanu. |
HealthServiceBlobName |
Nazwa pliku stanu — sprawdzanie kondycji będzie szukać tego pliku. |
HealthServiceOverallTimeoutSeconds |
Limit czasu dla całego sprawdzania — wartość domyślna to 3 sekundy. Jeśli sprawdzanie nie zostanie zakończone w tym interwale, usługa zgłasza złą kondycję. |
Implementacja
Wszystkie kontrole są wykonywane asynchronicznie i równolegle. Jeśli którykolwiek z nich zakończy się niepowodzeniem, cała sygnatura zostanie uznana za niedostępną.
Wyniki sprawdzania są buforowane w pamięci przy użyciu standardowego, nieprostrybuowanego ASP.NET Core MemoryCache. Wygaśnięcie pamięci podręcznej jest kontrolowane przez SysConfig.HealthServiceCacheDurationSeconds program i jest domyślnie ustawione na 10 sekund.
Uwaga
Ustawienie SysConfig.HealthServiceCacheDurationSeconds konfiguracji zmniejsza dodatkowe obciążenie generowane przez kontrole kondycji, ponieważ nie każde żądanie spowoduje wywołanie podrzędne usług zależnych.
Poniższa tabela zawiera szczegółowe informacje na temat kontroli kondycji składników w infrastrukturze:
| Składnik | Sprawdzanie kondycji |
|---|---|
| Obiekt blob konta magazynu | Sprawdzanie obiektu blob obecnie służy dwóm celom: 1. Przetestuj, czy jest możliwe dotarcie do usługi Blob Storage. Konto magazynu jest używane przez inne składniki w sygnaturze i jest uznawane za krytyczny zasób. 2. Ręcznie "wyłącz" region, usuwając plik stanu. Podjęto decyzję projektową, że sprawdzanie będzie szukać tylko obecności pliku stanu w określonym kontenerze obiektów blob. Zawartość pliku nie jest przetwarzana. Istnieje możliwość skonfigurowania bardziej zaawansowanego systemu, który odczytuje zawartość pliku i zwraca inny stan na podstawie zawartości pliku. Przykłady zawartości to DOBRA KONDYCJA, ZŁA KONDYCJA I KONSERWACJA. Usunięcie pliku stanu spowoduje wyłączenie sygnatury. Upewnij się, że plik kondycji jest obecny po wdrożeniu aplikacji. Brak pliku kondycji spowoduje, że usługa zawsze odpowiada w złej kondycji. Usługa Front Door nie rozpozna zaplecza jako dostępnego. Plik jest tworzony przez narzędzie Terraform i powinien być obecny po wdrożeniu infrastruktury. |
| Centrum zdarzeń | Raportowanie kondycji usługi Event Hubs jest obsługiwane przez usługę EventHubProducerService. Ta usługa zgłasza dobrą kondycję, jeśli jest w stanie wysłać nową wiadomość do usługi Event Hubs. Do filtrowania ten komunikat ma dodaną właściwość identyfikującą: HEALTHCHECK=TRUE ten komunikat jest ignorowany na końcu odbierania. Ustawienie AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() konfiguracji sprawdza właściwość HEALTHCHECK . |
| Azure Cosmos DB | Raportowanie kondycji usługi Azure Cosmos DB jest obsługiwane przez usługę CosmosDbService, która zgłasza dobrą kondycję, jeśli jest to: 1. Możliwość nawiązywania połączenia z bazą danych usługi Azure Cosmos DB i wykonywania zapytania. 2. Możliwość zapisania dokumentu testowego w bazie danych. Dokument testowy ma krótki zestaw czasu wygaśnięcia, a usługa Azure Cosmos DB automatycznie je usuwa. Usługa HealthService wykonuje dwie oddzielne sondy. Jeśli usługa Azure Cosmos DB jest w stanie, w którym operacje odczytu i zapisu nie działają, te dwie sondy zapewniają wyzwolenie alertu. |
Zapytania usługi Azure Cosmos DB
W przypadku zapytania tylko do odczytu używane jest następujące zapytanie, które nie pobiera żadnych danych i nie ma dużego wpływu na ogólne obciążenie:
SELECT GetCurrentDateTime ()
Zapytanie zapisu tworzy manekin ItemRating z minimalną zawartością:
var testRating = new ItemRating()
{
Id = Guid.NewGuid(),
CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
CreationDate = DateTime.UtcNow,
Rating = 1,
TimeToLive = 10 // will be auto-deleted after 10sec
};
await AddNewRatingAsync(testRating);
Monitorowanie
Usługa Azure Log Analytics jest używana jako centralne dzienniki i metryki magazynu dla wszystkich składników aplikacji i infrastruktury. aplikacja systemu Azure Insights jest używana dla wszystkich danych monitorowania aplikacji. Każda sygnatura w infrastrukturze ma dedykowany obszar roboczy usługi Log Analytics i wystąpienie usługi Application Insights. Oddzielny obszar roboczy usługi Log Analytics jest używany dla zasobów udostępnionych globalnie, takich jak usługi Front Door i Azure Cosmos DB.
Wszystkie sygnatury są krótkotrwałe i stale zastępowane każdym nowym wydaniem. Obszary robocze usługi Log Analytics na sygnaturę są wdrażane jako zasób globalny w oddzielnej grupie zasobów monitorowania jako sygnatura zasobów usługi Log Analytics. Te zasoby nie współużytkują cyklu życia sygnatury.
Aby uzyskać więcej informacji, zobacz Ujednolicony ujście danych na potrzeby skorelowanej analizy.
Monitorowanie: źródła danych
Ustawienia diagnostyczne: wszystkie usługi platformy Azure używane na potrzeby usługi Azure Mission-Critical są skonfigurowane do wysyłania wszystkich danych diagnostycznych, w tym dzienników i metryk do obszaru roboczego usługi Log Analytics specyficznego dla wdrożenia (globalnego lub sygnatury). Ten proces odbywa się automatycznie w ramach wdrożenia programu Terraform. Nowe opcje zostaną zidentyfikowane automatycznie i dodane w ramach elementu
terraform apply.Monitorowanie rozwiązania Kubernetes: ustawienia diagnostyczne służą do wysyłania dzienników i metryk usługi Azure Kubernetes Service (AKS) do usługi Log Analytics. Usługa AKS jest skonfigurowana do używania usługi Container Insights. Usługa Container Insights wdraża moduł OMSAgentForLinus za pośrednictwem zestawu DaemonSet platformy Kubernetes w każdym węźle w klastrach usługi AKS. Narzędzie OMSAgentForLinux może zbierać dodatkowe dzienniki i metryki z klastra Kubernetes i wysyła je do odpowiedniego obszaru roboczego usługi Log Analytics. Te dodatkowe dzienniki i metryki zawierają bardziej szczegółowe dane dotyczące zasobników, wdrożeń, usług i ogólnej kondycji klastra. Aby uzyskać więcej szczegółowych informacji z różnych składników, takich jak ingress-nginx, cert-manager i inne składniki wdrożone na platformie Kubernetes obok obciążenia o krytycznym znaczeniu, można użyć narzędzia Prometheus scraping. Narzędzie Prometheus scraping konfiguruje OMSAgentForLinux do złomowania metryk Rozwiązania Prometheus z różnych punktów końcowych w klastrze.
Telemetria usługi Application Insights: usługa Application Insights służy do zbierania danych telemetrycznych z aplikacji. Kod został instrumentowany w celu zbierania danych dotyczących wydajności aplikacji za pomocą zestawu SDK usługi Application Insights. Informacje krytyczne, takie jak wynikowy kod stanu i czas trwania wywołań zależności i liczniki dla nieobsługiwane wyjątki, są zbierane. Te informacje są używane w modelu kondycji i są dostępne do zgłaszania alertów i rozwiązywania problemów.
Monitorowanie: testy dostępności usługi Application Insights
Aby monitorować dostępność poszczególnych sygnatur i ogólnego rozwiązania z zewnątrz, testy dostępności usługi Application Insights są konfigurowane w dwóch miejscach:
Regionalne testy dostępności: te testy są konfigurowane w regionalnych wystąpieniach usługi Application Insights i są używane do monitorowania dostępności sygnatur. Te testy dotyczą klastrów i kont magazynu statycznego sygnatur bezpośrednio. Aby bezpośrednio wywołać punkty ruchu przychodzącego klastrów, żądania muszą mieć prawidłowy nagłówek identyfikatora usługi Front Door. W przeciwnym razie są one odrzucane przez kontroler ruchu przychodzącego.
Globalny test dostępności: te testy są konfigurowane w globalnym wystąpieniu usługi Application Insights i służą do monitorowania dostępności ogólnego rozwiązania przez wysyłanie poleceń ping do usługi Front Door. Używane są dwa testy: jeden do testowania wywołania interfejsu API względem usługi CatalogService i jednego do testowania strony głównej witryny internetowej.
Monitorowanie: zapytania
Usługa Azure Mission-Critical używa różnych zapytań język zapytań Kusto (KQL) do implementowania niestandardowych zapytań jako funkcji do pobierania danych z usługi Log Analytics. Te zapytania są przechowywane jako pojedyncze pliki w naszym repozytorium kodu, oddzielone wdrożeniami globalnymi i sygnaturami. Są one importowane i stosowane automatycznie za pośrednictwem narzędzia Terraform w ramach każdego uruchomienia potoku infrastruktury.
Takie podejście oddziela logikę zapytania od warstwy wizualizacji. Zapytania usługi Log Analytics są wywoływane bezpośrednio z kodu, na przykład z interfejsu API usługi HealthService. Innym przykładem jest narzędzie do wizualizacji, takie jak pulpity nawigacyjne platformy Azure, skoroszyty monitora lub narzędzie Grafana.
Monitorowanie: wizualizacja
Aby wizualizować wyniki zapytań dotyczących kondycji usługi Log Analytics, użyliśmy narzędzia Grafana w naszej implementacji referencyjnej. Aplikacja Grafana służy do wyświetlania wyników zapytań usługi Log Analytics i nie zawiera żadnej logiki. Stos Grafana nie jest częścią cyklu życia wdrożenia rozwiązania, ale został wydany oddzielnie.
Aby uzyskać więcej informacji, zobacz Wizualizacja.
Generowanie alertów
Alerty są ważną częścią ogólnej strategii operacji. Proaktywne monitorowanie, takie jak korzystanie z pulpitów nawigacyjnych, powinno być używane z alertami, które zwracają natychmiastową uwagę na problemy.
Te alerty tworzą rozszerzenie modelu kondycji, ostrzegając operatora o zmianie stanu kondycji na obniżoną/żółtą lub w złej kondycji/czerwonym stanie. Ustawiając alert w węźle głównym modelu kondycji, operator natychmiast zdaje sobie sprawę z dowolnego poziomu biznesowego, który ma wpływ na stan rozwiązania: Po tym wszystkim ten węzeł główny zmieni kolor na żółty lub czerwony, jeśli którykolwiek z podstawowych przepływów użytkownika lub zasobów raportuje żółtą lub czerwoną metrykę. Operator może zwrócić uwagę na wizualizację Modelu kondycji na potrzeby rozwiązywania problemów.
Aby uzyskać więcej informacji, zobacz Automatyczna odpowiedź na zdarzenia.
Analiza niepowodzeń
Tworzenie analizy niepowodzeń jest głównie teoretycznym ćwiczeniem planowania. To ćwiczenie teoretyczne powinno być używane jako dane wejściowe dla automatycznych iniekcji błędów, które są częścią procesu ciągłej walidacji. Symulując tryby awarii zdefiniowane w tym miejscu, możemy zweryfikować odporność rozwiązania na te błędy, aby upewnić się, że nie doprowadzą one do awarii.
W poniższej tabeli wymieniono przykładowe przypadki awarii różnych składników implementacji referencyjnej Azure Mission-Critical.
Następne kroki
Wdróż implementację referencyjną, aby uzyskać pełną wiedzę na temat zasobów i ich konfiguracji używanej w tej architekturze.