Strategie architektury dotyczące monitorowania niezawodności obciążeń

Dotyczy tego zalecenia listy kontrolnej niezawodności platformy Azure Well-Architected Framework:

RE:10 Ciągłe mierzenie i śledzenie kondycji systemu przy użyciu wskaźników czasu pracy i niezawodności w składnikach i przepływach krytycznych. Upewnij się, że te dane są zachowywane i dostępne do obsługi terminowego wykrywania, reagowania i analizy po zdarzeniu.

Monitorowanie niezawodności to praktyka mierzenia, jak dobrze system spełnia wymagania biznesowe w miarę upływu czasu w odniesieniu do odporności i możliwości odzyskiwania. Dobrze zaprojektowany system monitorowania zapewnia widok w czasie rzeczywistym i trendy zachowania systemu przez ustanowienie widoczności między warstwami platformy, infrastruktury i obciążenia.

Dzięki korelowaniu tych sygnałów między składnikami i w czasie monitorowanie umożliwia szybką, pewną analizę zdarzeń i awarii. Utwórz ustrukturyzowane podejście, aby wnioski były istotne, alerty prowadziły do odpowiednich działań, a uczenie się wracało do architektury i operacji.

Kluczowe strategie przedstawione w tym artykule opierają się na podstawowych praktykach operacyjnych obserwacji opisanych w temacie OE:07 Architecture strategies for design a monitoring system (Strategie architektury OE:07 dotyczące projektowania systemu monitorowania). Wskazówki dotyczące wdrażania praktyki monitorowania są dostępne w przewodniku projektowania monitorowania. Zalecamy najpierw przejrzenie tych zasobów.

Definicje

Termin Definicja
Umowa SLA (umowa dotycząca poziomu usług) Zobowiązania zewnętrzne, które otrzymujesz od dostawców lub które otrzymujesz od swoich klientów. Niespełnienie umów SLA może prowadzić do kar finansowych, szkód reputacyjnych lub obniżonego doświadczenia użytkownika.
SLO (cele poziomu usług) Wewnętrzne cele dotyczące wydajności i niezawodności używane do definiowania progów wyzwalających alerty i mierzenia kondycji systemu względem celów biznesowych.
Model kondycji Hierarchiczna reprezentacja stanu systemu przy użyciu jasnych stanów kondycji (w dobrej kondycji, obniżonej kondycji, złej kondycji) z sygnałami w czasie rzeczywistym i możliwością przechodzenia do szczegółów z ogólnego systemu do poszczególnych składników.
Znaczek Jednostka wdrożenia ze zdefiniowanymi limitami pojemności, takimi jak maksymalna liczba równoczesnych użytkowników, przepływność lub progi wykorzystania zasobów. Wiele pieczęci umożliwia skalowanie horyzontalne i dystrybucję regionalną.
FMA (analiza trybu awarii) Systematyczna analiza służąca do identyfikowania potencjalnych punktów awarii w systemie, która służy do kierowania strategią monitorowania i ulepszeniami niezawodności.
RTO (cel czasu odzyskiwania) Maksymalny dopuszczalny czas wykrywania, reagowania na nie i odzyskiwania po awarii lub zdarzeniu.
Cel odtwarzania punktu (RPO) Maksymalna akceptowalna ilość utraty danych mierzona w czasie, reprezentująca ilość danych, które mogą zostać utracone podczas scenariusza awarii.
Transakcje syntetyczne Testy automatyczne, które symulują rzeczywiste akcje użytkownika i kompleksowe interakcje w celu weryfikacji kondycji systemu i wykrywania problemów z perspektywy klienta, zapewniając zewnętrzną walidację dostępności systemu.
Identyfikatory korelacji Unikatowe identyfikatory używane do śledzenia transakcji i żądań w wielu usługach i składnikach, umożliwiając identyfikację problemów i analizę w systemach rozproszonych.
Błędy przejściowe Tymczasowe błędy w zależnościach systemowych, które zazwyczaj są rozwiązywane w krótkim czasie, takie jak przekroczenia limitu czasu sieci lub tymczasowa niedostępność usługi.
Opóźnienie ogona Czas odpowiedzi napotykany przez najwolniejsze żądania, zwykle mierzony przy wysokich percentylach (p95, p99), gdzie problemy z wydajnością często występują jako pierwsze.

Monitorowanie funkcji obciążenia

Monitoruj, co system rzeczywiście dostarcza. Zacznij od śledzenia, czy krytyczne przepływy pracy zakończą się pomyślnie i wygeneruj prawidłowe wyniki. System może wydawać się w dobrej kondycji, mimo że nadal generuje nieprawidłowe lub niekompletne dane wyjściowe, więc samo wykonanie nie jest wystarczające.

Jeśli na przykład obciążenie generuje raporty co sześć godzin, monitorowanie powinno potwierdzić dwie elementy: że zadanie zostało uruchomione zgodnie z harmonogramem i że wygenerowało prawidłowy wynik, taki jak niepusty raport z oczekiwaną zawartością i rozmiarem. Ten rodzaj weryfikacji pomaga zagwarantować, że system nie tylko jest wykonywany, ale także zapewnia funkcjonalność, dla których została zaprojektowana.

Monitorowanie środowiska użytkownika

Monitorowanie niezawodności z perspektywy firmy i użytkownika. W ramach analizy trybu awarii (FMA) należy już zidentyfikować kluczowe przepływy użytkowników. Dla każdego przepływu śledź, jak awarie w dowolnym składniku lub zależności wpływają na środowisko użytkownika i jaki jest oczekiwany wynik. Na przykład, w procesie finalizacji zakupów w handlu elektronicznym, awaria usług związanych z płatnościami lub zapasami albo ich przeciążenie, może uniemożliwić klientom dokonanie zakupów.

Niezawodność odzwierciedla również jakość usług. W procesie płatności użytkownicy powinni mieć możliwość zakończenia zakupów w sposób ciągły. Użyj metryk opóźnień opartych na percentylu, takich jak p50, p95 i p99, aby zrozumieć rzeczywiste środowisko użytkownika, ze szczególnym uwzględnieniem opóźnień końcowych, w których problemy z wydajnością często występują jako pierwsze.

Uwzględnij sygnały użytkownika w modelu kondycji, dzięki czemu obniżona jakość usługi wyzwala zmiany stanu kondycji. Modeluj krytyczne przepływy użytkowników tak, aby degradacja komponentów propagowała się w górę, łącząc wpływ na użytkownika z widocznością systemu. Użyj modeli kondycji Azure Monitor, aby ocenić niezawodność obciążeń Azure.

Ważna

Monitorowanie wydajności zapewnia widok działania systemu pod rzeczywistym obciążeniem przez podzielenie całkowitego opóźnienia między warstwami systemowymi. Łączy zmiany wydajności, dzięki czemu można zrozumieć, co wpłynęło na zmianę zachowania. Może to być spowodowane wdrożeniami, aktualizacjami konfiguracji i zdarzeniami skalowania. Razem monitorowanie niezawodności i wydajności zapewnia pełny obraz zachowania systemu i wyróżnianie, gdzie koncentracja uwagi będzie miała największy wpływ. Aby uzyskać informacje na temat monitorowania wydajności, zobacz Monitorowanie wydajności.

Śledzenie celów dostępności

Śledzenie, jak dobrze system spełnia zdefiniowane cele pod kątem dostępności, przepływności i czasów odpowiedzi. Te cele są często formalizowane jako umowy dotyczące poziomu usług (SLA) i cele poziomu usług (SLO) i odzwierciedlają oczekiwania określone dla użytkowników. Monitorowanie względem nich zapewnia niezawodność zgodną z rzeczywistymi wynikami biznesowymi. Aby uzyskać więcej informacji, zobacz Cele niezawodności i Umowy dotyczące poziomu usług.

Skoncentruj się na kluczowych wskaźnikach, które przyczyniają się do tych celów i śledzą je w czasie. Gdy coś dryfuje, powinno być możliwe przejście do szczegółowych informacji dotyczących określonych składników lub podsystemów. Przechwyć wszystkie istotne sygnały, w tym problemy maskowane przez nadmiarowość lub przełączanie awaryjne, dzięki czemu możesz zrozumieć, co rzeczywiście się stało i zapobiec powtórnym wystąpieniom.

Łączenie świadomości w czasie rzeczywistym z kontekstem historycznym. Sygnały w czasie rzeczywistym pomagają szybko reagować, gdy cele są zagrożone, a trendy w czasie ujawniają wzorce i cykliczne problemy. Klasyfikowanie przyczyn błędów względem celów i agregowanie tych metryk wspiera również przejrzyste raportowanie SLA i pomaga w ciągłym doskonaleniu.

Monitoruj kluczowe umowy SLA udostępniane przez dostawców i usługi platformy (od firmy Microsoft i innych). Powinieneś:

  • Użyj modelu kondycji, aby odzwierciedlić realizację celów SLO, umożliwiając pomiar ogólnej kondycji obciążenia roboczego we wszystkich aspektach jakości, a nie tylko dostępności/czasu działania
  • Śledzenie wskaźników potencjalnych naruszeń umowy SLA w czasie rzeczywistym
  • Przechwyć i zachować dowody wymagane do obsługi roszczenia umowy SLA w przypadku wystąpienia naruszenia

Śledzenie celów odzyskiwania

Śledzenie możliwości odzyskiwania przez traktowanie każdego testu i rzeczywistego zdarzenia jako mierzalnego zdarzenia. Użyj danych monitorowania, aby sprawdzić, czy system i zespół mogą spełnić zdefiniowane cele odzyskiwania w rzeczywistych warunkach.

Mierzenie kluczowych sygnałów, takich jak czas wykrywania, reagowania i odzyskiwania (RTO), wraz z narażeniem na utratę danych (RPO). Uwzględnij wskaźniki, takie jak gotowość i pojemność trybu failover, współczynniki powodzenia pracy w trybie failover oraz czas wykonywania, powodzenie tworzenia i przywracania kopii zapasowej, opóźnienie replikacji oraz wymagana interwencja ręczna.

Te metryki podkreślają również luki operacyjne, takie jak niejasne procedury, opóźnienia decyzji lub dokumentacja trudna do uzyskania dostępu, co może mieć wpływ na wydajność odzyskiwania. Użyj tych szczegółowych informacji, aby wzmocnić zarówno rozwiązania dotyczące projektowania systemu, jak i reagowania na zdarzenia.

Note

Należy zachować ostrożność, że zasady czyszczenia lub przechowywania nie są tak agresywne, że usuwają dzienniki lub dane telemetryczne tylko wtedy, gdy są najbardziej potrzebne. W przypadku każdego scenariusza zapytaj: Jakie dane musimy mieć, aby zrozumieć, co się wydarzyło przed i podczas zdarzenia? Przydatne podejście to przemyślenie różnych typów badań po zdarzeniu, takich jak:

  • Awarie platformy lub infrastruktury
  • Problemy z dostępnością aplikacji (na przykład po zmianie wdrożenia lub konfiguracji)
  • Błędy aplikacji powodujące utratę lub uszkodzenie danych
  • Zdarzenia dotyczące zabezpieczeń

Tworzenie alertów z możliwością działania za pomocą modelu kondycji

Projektuj alerty tak, aby wyraźnie wskazywały na coś, co wymaga działania, i opieraj je na modelu kondycji, który reprezentuje system przy użyciu prostych stanów, takich jak zdrowy, zdegradowany i niezdrowy.

Strukturuj hierarchicznie model kondycji od poszczególnych składników aż do całego systemu, dzięki czemu można szybko śledzić problemy do ich źródła. Zdefiniuj progi przy użyciu celów poziomu usług (SLO) i połącz sygnały, takie jak metryki, dzienniki, ślady i syntetyczne kontrole, aby utworzyć niezawodny obraz kondycji systemu. Zapewnia to operatorom jasny wgląd w to, co działa, co nie jest i gdzie działać bez przeszukiwania nieprzetworzonych danych. Aby uzyskać więcej informacji, zobacz przewodnik projektowania dotyczący modelowania kondycji.

Dostosuj alerty dotyczące rzeczywistych warunków, koncentrując się na doświadczeniu od końca do końca i krytycznych transakcjach, aby faktycznie odzwierciedlały wpływ na użytkowników. Zmniejsz szum poprzez uwzględnianie przejściowych wahań i wyzwalanie istotnych zmian stanu zdrowia, a nie pojedynczych zakłóceń lub skoków. Połącz alerty w czasie rzeczywistym ze szczegółowymi informacjami o trendach, aby przechwycić zarówno natychmiastowe problemy, jak i stopniowe degradacje, pomagając zespołom szybko reagować i być skoncentrowanym.

Ryzyko: Modelowanie kondycji wymaga zbierania znaczących sygnałów w całym systemie. Poleganie tylko na prostych metrykach, takich jak procesor CPU lub pamięć, może przegapić to, co faktycznie ma znaczenie. Uwzględnij dane środowiska użytkownika i testy syntetyczne, aby uzyskać pełny widok. Zdefiniowanie "zdrowego" wymaga synchronizacji, a źle dostrojony próg może powodować szum i zmniejszać skuteczność.

Monitorowanie wszystkich warstw systemu

Monitoruj każdą warstwę systemu, aplikacji, danych/magazynu i sieci, aby zachować pełny widok sygnałów niezawodności.

Model kondycji służy do ujednolicania sygnałów między warstwami systemowymi reprezentującymi zasoby Azure i składniki aplikacji w ramach przepływów użytkownika i systemu.

W warstwie aplikacji śledź powodzenie, niepowodzenie i opóźnienie przy użyciu dzienników, metryk i sond kondycji. Użyj identyfikatorów korelacji, aby śledzić żądania między usługami i ułatwić rozwiązywanie problemów. Zbieraj dzienniki asynchronicznie, aby nie wpływały na wydajność żądań, i utrzymuj oddzielne dzienniki diagnostyczne i audytowe dla przejrzystości. Dodaj syntetyczne transakcje i sondy punktów końcowych, aby potwierdzić, co klienci rzeczywiście doświadczają.

Kompromis. Wybór między rejestrowaniem asynchronicznym i synchronicznym obejmuje równowagę między wydajnością a niezawodnością telemetrii.

  • Rejestrowanie asynchroniczne utrzymuje przetwarzanie poza ścieżką krytyczną, co zmniejsza opóźnienie i poprawia wydajność systemu. Jednak wprowadza ryzyko utraty danych telemetrycznych, zwłaszcza jeśli wystąpi błąd, zanim dzienniki zostaną opróżnione lub utrwalone.

  • Rejestrowanie synchroniczne gwarantuje, że dzienniki są zapisywane przed kontynuowanym przetwarzaniem, co zwiększa trwałość i inspekcję danych. Kompromis polega na zwiększonym opóźnieniu i ściślejszym sprzężeniu między wydajnością aplikacji a systemem rejestrowania.

W większości scenariuszy rejestrowanie asynchroniczne jest preferowaną metodą ze względu na minimalny wpływ na wydajność. Jednak w silnie regulowanych lub wrażliwych na inspekcję środowiskach rejestrowanie synchroniczne może być wymagane, aby zagwarantować, że zdarzenia krytyczne są przechwytywane niezawodnie.

W warstwie danych i magazynu skoncentruj się na dostępności, współczynnikach powodzenia zapisu, opóźnieniu zapytań, przekroczeniu limitu czasu, blokadach i presji zasobów. Przyjrzyj się trendom w miarę upływu czasu, aby zidentyfikować rosnące wąskie gardła i odróżnić problemy krótkotrwałe od długotrwałego pogorszenia.

W warstwie sieciowej monitoruj łączność, opóźnienie, utratę pakietów, przepustowość i wzorce ruchu. Połącz dzienniki przepływu, kontrole punktów końcowych i testy syntetyczne, aby uwidodzić problemy z routingiem, anomalie lub zachowanie związane z zabezpieczeniami. Połącz te sygnały z powrotem z danymi aplikacji i platformy, aby zrozumieć, skąd pochodzą problemy.

Dzienniki operacyjne ułatwiają diagnozowanie problemów, śledzenie wydajności i zrozumienie zachowania systemu. Nie są one zaprojektowane tak, aby służyły jako źródło prawdy dla zdarzeń biznesowych, inspekcji lub raportowania regulacyjnego, które zwykle wymagają silniejszej możliwości śledzenia.

Co należy szczegółowo monitorować dla każdej warstwy, jest omówione w Przewodniku projektowania monitorowania.

Monitorowanie paneli administracyjnych i interfejsów API statusu

Rozszerz monitorowanie do pulpitów nawigacyjnych, interfejsów API stanu i raportów, od których zależą operatory i narzędzia podrzędne dla stanu systemu. Utożsamianie nieprawidłowych lub nieaktualnych wartości z problemem z niezawodnością, co wymaga prawidłowego działania systemu na tym samym poziomie rygoru.

Na przykład w aplikacji do zarządzania zamówieniami panel administracyjny może wyświetlać liczbę oczekujących zamówień z tabeli podsumowującej aktualizowanej przez zadanie działające w tle. Jeśli odświeżanie nie powiedzie się w trybie dyskretnym, zamówienia nadal przepływają, ale pracownicy operacyjni działają na nieaktualnej liście prac. Porównanie w stałych odstępach czasu liczby widocznej na pulpicie z wynikiem zapytania wykonywanego na żywo na tabeli zamówień pozwala wykryć rozbieżność, zanim wpłynie ona na klientów.

Definiowanie i monitorowanie pojemności stempla

Zdefiniuj jasne limity pojemności dla każdej jednostki wdrożenia lub sygnatury i uważnie je monitoruj. Każda sygnatura działa w ramach ograniczonego limitu, niezależnie od tego, czy jest to maksymalna liczba równoczesnych użytkowników, przepływności, czy progów wykorzystania zasobów. Dzięki temu jawne wprowadzenie tych limitów zapewni niezawodny punkt odniesienia do podejmowania decyzji.

Ta widoczność pomaga określić, kiedy znacznik zbliża się do nasycenia, na długo przed tym, jak wpłynie na niezawodność. Obsługuje również decyzje dotyczące skalowania w poziomie, takie jak dodawanie nowych sygnatur lub ponowne dystrybuowanie obciążenia, i potwierdza, że ruch przepływa zgodnie z projektem.

Definiowanie tych limitów nie zawsze jest proste. Wydajność może być trudna do zmierzenia, zwłaszcza gdy zależy od wielu usług bazowych o różnych cechach skalowania. Należy użyć wskazówek dotyczących platformy, takich jak limity przydziału i limity z platformy Microsoft Azure, jako punktu wyjścia. W praktyce pojemność jest często określana za pomocą testowania obciążenia, obserwacji i dostrajania iteracyjnego, a nie precyzyjnego modelowania z góry.

Monitorowanie rozkładu obciążenia pomiędzy redundantnymi instancjami

Podczas uruchamiania obciążenia w wielu nadmiarowych wystąpieniach, w tym przy rozdzielaniu wystąpień na różne regiony lub strefy, ruch i użycie zasobów powinny pozostać zrównoważone pomiędzy tymi wystąpieniami.

Chcesz wykryć nierównowagi, które często wskazują na problemy z routingiem, problemy z konfiguracją lub ograniczenia zależności. Gwarantuje to również, że cele trybu failover mają wystarczającą pojemność, aby w razie potrzeby wchłonąć ruch i potwierdzić, że mechanizmy nadmiarowości zachowują się zgodnie z oczekiwaniami podczas zarówno operacji w stanie stabilnym, jak i w scenariuszach awarii.

Wykrywanie trybów awarii

W ramach ćwiczenia analizy trybu awarii (FMA) należy zidentyfikować potencjalne punkty awarii.

W praktyce monitorowania niezawodności zachowaj ciągłą kontrolę nad tymi punktami. Zacznij od skupienia się na prostszych sygnałach, takich jak błędy przejściowe. Monitoruj zachowanie ponawiania prób i przejściowe współczynniki błędów, aby zrozumieć, jak działają zależności i podstawowe usługi w rzeczywistych warunkach operacyjnych. Sygnały te zapewniają wczesny wgląd w pojawiające się niestabilności. Pomagają one rozpoznać, gdy schematy ponawiania próśb odbiegają od oczekiwanej normy, umożliwiają zachowanie kontroli nad tym, czy system pozostaje w dobrej kondycji pod obciążeniem, i określenie, kiedy zależność lub usługa zewnętrzna zaczyna pogarszać się, zanim wpłynie to na doświadczenie użytkownika.

Obejmują również awarie o większym wpływie, takie jak awarie stref dostępności wpływające na część infrastruktury, awarie usług lub regionalne, które uniemożliwiają działanie całego regionu Azure. Należy nawet obserwować scenariusze zabezpieczeń, takie jak DDoS lub inne złośliwe działania, błędy konfiguracji składników i problemy z wydajnością, ponieważ każdy z nich może mieć wpływ na ogólną niezawodność rozwiązania.

Aby uzyskać informacje na temat fmA, zobacz Strategie architektury na potrzeby analizy trybu awarii.

Informacje o stanie niezawodności platformy

Aby efektywnie zarządzać niezawodnością, potrzebujesz jasnego wglądu w kondycję platformy. Ta świadomość pomaga szybko określić, czy problem pochodzi z obciążenia, czy z bazowej platformy w chmurze.

Usługa Azure Service Health zapewnia wgląd w stan platformy Azure. Skonfiguruj alerty w usłudze Service Health, aby otrzymywać powiadomienia o zmianie warunków platformy. Otrzymujesz aktualizacje dotyczące aktywnych awarii wpływających na zasoby, zdarzenia planowanej konserwacji, które mogą powodować zakłócenia oraz degradacje specyficzne dla regionu lub usługi.

ułatwienia dostępu do Azure

  • Uwzględnij usługi monitorowania i alertów platformy w chmurze, w tym:

  • Usługa Azure Monitor to kompleksowe rozwiązanie do monitorowania, które służy do zbierania, analizowania i reagowania na dane monitorowania ze środowisk w chmurze i środowiskach lokalnych.

  • Modele kondycji usługi Azure Monitor pomagają definiować, mierzyć i wizualizować kondycję obciążeń poprzez korelowanie metryk, logów i śladów w użyteczne stany kondycji w obrębie zasobów i składników platformy Azure.

  • Log Analytics to narzędzie w witrynie Azure Portal, które służy do edytowania i uruchamiania zapytań dzienników względem danych w obszarze roboczym usługi Log Analytics.

  • Application Insights to rozszerzenie usługi Azure Monitor. Zapewnia funkcje monitorowania wydajności aplikacji (APM).

  • Szczegółowe informacje o usłudze Azure Monitor to zaawansowane narzędzia analityczne, które ułatwiają monitorowanie usług platformy Azure, takich jak maszyny wirtualne, usługi aplikacji i kontenery. Wglądy są budowane na bazie usług Azure Monitor i Log Analytics.

  • Usługa Azure Monitor dla rozwiązań SAP to natywny dla platformy Azure produkt do monitorowania dla środowisk SAP uruchamianych na platformie Azure.

  • Monitor połączeń to narzędzie do ciągłego śledzenia łączności sieciowej i wydajności zasobów platformy Azure. Uruchamia testy syntetyczne i udostępnia alerty i diagnostykę w czasie rzeczywistym w celu wczesnego wykrywania błędów. Możesz tworzyć niestandardowe skoroszyty, aby wizualizować kondycję łączności i zagregowane metryki wydajności.

  • Dzienniki przepływu sieci wirtualnej można włączyć dla różnych obciążeń, co pozwala na monitorowanie ruchu sieciowego. Analiza ruchu może służyć do analizowania i wzbogacania tych dzienników przepływu w celu uwidocznienia szczegółowych informacji, takich jak zablokowany ruch, złośliwe przepływy i aktywne porty uwidocznione w Internecie. Tworzenie skoroszytów umożliwia zespołom monitorowanie zachowania ruchu na żywo i odbieranie alertów. Użyj widoków osi czasu i wizualizacji topologii, aby łatwo monitorować wzorce ruchu, które mogą wskazywać na spadek wydajności lub zagrożenia bezpieczeństwa.

  • Aby zapoznać się z najlepszymi rozwiązaniami dotyczącymi wielu obszarów roboczych, zobacz Projektowanie architektury obszaru roboczego usługi Log Analytics.

Example

Przykłady rzeczywistych rozwiązań do monitorowania można znaleźć w temacie Web application monitoring on Azure and Baseline architecture for an Azure Kubernetes Service cluster (Monitorowanie aplikacji internetowych na platformie Azure i architektura linii bazowej dla klastra usługi Azure Kubernetes Service).

Lista kontrolna dotycząca niezawodności

Zapoznaj się z kompletnym zestawem zaleceń.