Strategie architektury monitorowania wydajności obciążeń

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

PE:04 Ustanów spójny pomiar wydajności, aby można było porównywać zachowanie z punktami odniesienia, analizować je w czasie oraz wykrywać pogorszenie, nieefektywności i luki w skalowalności.

Bez danych wydajności podstawowe problemy i możliwości optymalizacji są niezauważone, co prowadzi do obniżonej wydajności środowiska użytkownika.

W tym artykule opisano strategie projektowania służące do implementowania wielowarstwowej miary wydajności, która przechwytuje opóźnienia, przepływność i zachowanie zasobów w celu ustanowienia punktów odniesienia i zidentyfikowania obniżenia wydajności w obciążeniu.

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. Zalecenia zawarte w tym przewodniku dotyczą wyłącznie wydajności. Aby uzyskać informacje na temat niezawodności, zobacz Strategie architektury RE:10 dotyczące projektowania niezawodnej strategii monitorowania i zgłaszania alertów.

Definicje

Termin Definicja
Dzienniki aktywności Dzienniki śledzące operacje zarządzania zasobami, takie jak usuwanie zasobu.
Dzienniki aplikacji Dzienniki służące do śledzenia informacji o zdarzeniach aplikacji, błędach i innych działaniach, takich jak logowania i niepowodzenia połączenia z bazami danych.
Narzędzie do monitorowania wydajności aplikacji (APM) Narzędzie, które monitoruje i raportuje wydajność aplikacji.
Baselines Oczekiwane metryki wydajności systemu służące jako punkt odniesienia do wykrywania dryfów, regresji oraz ulepszeń w miarę upływu czasu.
Instrumentacja kodu Bezpośrednie lub pośrednie przechwytywanie metryk wydajności z perspektywy kodu aplikacji. Przechwycone metryki obejmują metryki przepływu, użycie zasobów i metryki specyficzne dla języka lub środowiska uruchomieniowego.
Śledzenie rozproszone Zbieranie i korelowanie metryk między rozproszonymi składnikami obciążenia w celu zrozumienia pełnych przepływów transakcji.
Opóźnienie Opóźnienie czasowe między inicjowaniem żądania a odebraniem odpowiedzi, pomiarem czasu reakcji systemu.
Metrics Pomiary liczbowe, które rejestrują zachowanie wydajności obciążenia w czasie, zwykle agregowane na potrzeby analizy.
Percentyle (p50, p95, p99) Miary statystyczne przedstawiające rozkład wydajności; P50 reprezentuje typową wydajność, p95 pokazuje większość środowiska użytkownika pod obciążeniem, p99 przechwytuje najgorszą wydajność.
Metryki platformy Wartości liczbowe, które rejestrują wydajność obciążenia w określonym czasie.

Korzystanie z metryk opartych na percentylu

Mierzenie metryk wydajności, takich jak opóźnienie, czas odpowiedzi lub czas ładowania, przy użyciu percentyli (p50, p95, p99), a nie średnich. Średnie mogą być mylące. Jeśli większość żądań jest szybka, ale kilka z nich jest bardzo wolnych, średnia może ukryć złe doświadczenie.

Percentyle pokazują zachowanie ogona, co jest ważne dla zrozumienia doświadczenia użytkownika. P50 reprezentuje typową wydajność, p95 pokazuje, co większość użytkowników doświadcza pod obciążeniem, a p99 przechwytuje najgorszą wydajność lub wartości odstające.

Zbieranie danych wydajności przy użyciu narzędzi do monitorowania i przedstawianie ich jako percentyli w zdefiniowanych oknach czasu. Użyj ich jako punktu odniesienia do monitorowania, zgłaszania alertów i analizy wydajności.

Definiowanie granic poprawy wydajności

Zdefiniuj jasne granice wydajności, aby dokładnie wiedzieć, co znajduje się w pomiarach. Dziel opóźnienie w systemie na części zamiast traktować je jako pojedynczą liczbę. Na przykład przypisywać czas do każdej warstwy, takich jak usługi brzegowe, bramy, obliczenia i zależności, aby ustalić, gdzie rzeczywiście występują opóźnienia.

Oddzielaj elementy, które nie kontrolujesz: kodu, usług, infrastruktury i bezpośrednich zależności w porównaniu z czynnikami zewnętrznymi, takimi jak warunki po stronie klienta, rozpoznawanie nazw DNS, opóźnienie usługodawców internetowych lub ograniczenia urządzeń. To rozróżnienie uniemożliwia błędne przypisanie i utrzymuje optymalizację skoncentrowaną na obszarach, w których można wprowadzać zmiany, jednocześnie odzwierciedlając pełne doświadczenie użytkownika końcowego.

Oceń, kiedy i gdzie problemy z wydajnością wpływają na środowisko użytkownika. Kompensuj ten spadek poprzez projektowanie lub łagodź go poprzez wprowadzanie ulepszeń w kontrolowalnych częściach systemu.

Segmentowanie sygnałów według środowiska i celu

Segmentowanie danych wydajności, dzięki czemu każdy sygnał odzwierciedla jasny kontekst. Rozdziel środowisko i cel, aby uniknąć mieszania sygnałów, które zachowują się inaczej lub służą różnym decyzjom.

Zachowaj oddzielone dane produkcyjne i nieprodukcyjne. Dane produkcyjne odzwierciedlają rzeczywisty wpływ użytkownika i powinny prowadzić do monitorowania i alertów. Dane nieprodukcyjne są przydatne do testowania i dostrajania, ale mieszanie ich z produkcją zniekształca wyniki i ukrywa prawdziwe problemy.

Oddzielaj metryki wydajności od metryk biznesowych. Metryki wydajności śledzą zachowanie systemu i kondycję obciążenia, a metryki biznesowe śledzą wyniki. Nawet gdy nakładają się na siebie, zachowaj je w odrębnych strumieniach, aby można było je analizować i używać niezależnie.

Tworzenie alertów dotyczących wydajności z zakresem i możliwością działania

Celem alertów jest wczesne wykrywanie obniżenia wydajności, zanim stanie się ono widoczne dla użytkownika lub wpływa na działalność biznesową. Twórz alerty na dwóch poziomach: doświadczenie użytkownika końcowego i podstawowe transakcje wewnętrzne reprezentujące krytyczne ścieżki systemowe podczas obciążenia.

Używaj pojedynczego, spójnego zestawu danych w każdym środowisku dla celów i alertów. Jeśli alerty są oparte na różnych danych niż cele wydajności, stają się zawodne i trudne do zaufania.

Twórz alerty, które umożliwiają podjęcie działań i są wyraźnie powiązane z wynikami wydajności. Każdy alert powinien wskazywać, jaki próg został trwale przekroczony, potencjalne skutki oraz zaangażowane składniki, aby było jasne, gdzie przeprowadzić dochodzenie i co jest objęte tym wpływem. Zacznij od standardowych, dobrze znanych progów, a następnie uściślij je w czasie w oparciu o zaobserwowane zachowanie systemu i charakterystykę obciążenia.

Jeśli bezpośrednie alerty dotyczące zależności zewnętrznej nie są możliwe, użyj sygnałów pośrednich, takich jak czas trwania wywołania zależności, wskaźniki błędów lub zachowanie przekroczenia limitu czasu, aby oszacować jego wpływ na wydajność systemu.

Monitorowanie elastyczności

Mierz, jak system reaguje na zmiany zapotrzebowania i zdarzenia skalowania.

Śledź opóźnienie przy uruchamianiu cold start i inicjowaniu, aby zrozumieć, jak koszty uruchamiania wpływają na czas odpowiedzi, zwłaszcza podczas zdarzeń związanych ze skalowaniem poziomym. Monitoruj zachowanie skalowania w poziomie i skalowania w pionie, aby ocenić, jak szybko system dostosowuje się do zmian obciążenia i czy działania skalowania nadążają za zapotrzebowaniem.

Śledzenie wydajności w czasie

Śledź, jak wydajność ewoluuje wraz ze zmianami w projekcie i czynnikach zewnętrznych.

Ustanów punkty odniesienia reprezentujące oczekiwaną wydajność systemu, a następnie porównaj bieżące zachowanie z nimi, aby wykryć dryf, w tym regresje i ulepszenia.

Łączenie zmian wydajności ze zdarzeniami operacyjnymi, takimi jak wdrożenia, aktualizacje konfiguracji i akcje skalowania. Dodaj adnotacje do osi czasu z tymi zdarzeniami, aby zmiany zachowania miały jasny kontekst i można je prześledzić z powrotem do prawdopodobnych przyczyn.

Użyj tej ciągłej widoczności jako mechanizmu sprzężenia zwrotnego dla decyzji inżynieryjnych. Przekaż szczegółowe informacje o wydajności do planowania i priorytetyzacji oraz traktuj je jako dane wejściowe do regularnej pracy, a nie tylko reagowania na zdarzenia.

Stale uściślij cele wydajności w miarę rozwoju systemu. Dostosuj cele SLO, progi i oczekiwania na podstawie obserwowanych zachowań i wzorców użycia, aby cele pozostały realistyczne i dostosowane do rzeczywistego środowiska użytkownika.

Zbieranie danych wydajności aplikacji

Musisz mieć metryki wydajności aplikacji, takie jak przepływność, opóźnienie i czasy ukończenia, głównie zebrane za pomocą kodu instrumentacji.

Monitoruj krytyczne ścieżki wykonywania, gdzie wydajność jest najbardziej zauważalna: kluczowe przepływy żądań, operacje intensywnie korzystające z zasobów, oraz punkty, w których występują zależności zewnętrzne lub ponawianie prób. Upewnij się, że kompleksowa widoczność transakcji umożliwia pomiar całkowitego czasu wykonania oraz poszczególnych współtworzących kroków.

Przechwyć trzy podstawowe typy sygnałów wydajności:

  • Metryki dotyczące zagregowanego zachowania wydajności (rozkłady opóźnień, przepływność, współczynniki błędów)
  • Ślady dotyczące sposobu dystrybucji czasu między ścieżkami żądań i składnikami systemu
  • Logi szczegółowego kontekstu wykonywania na określonych krokach lub zdarzeniach

Używaj spójnych metadanych w tych sygnałach, aby dane wydajności mogły być skorelowane między warstwami systemu i usług.

Unikaj duplikowania sygnałów wydajności niższego poziomu, które są już uwidocznione przez platformę, chyba że wymagana jest dodatkowa szczegółowość w celu wyjaśnienia zachowania specyficznego dla obciążenia lub zidentyfikowania wąskich gardeł.

Zbieranie danych dotyczących wydajności zasobów

Zbierz dane dotyczące wydajności na poziomie zasobów, aby zrozumieć, jak składniki infrastruktury zachowują się pod obciążeniem i jak przyczyniają się do ogólnej wydajności obciążenia.

Każda usługa uwidacznia metryki specyficzne dla platformy, które odzwierciedlają jej charakterystykę kondycji i wydajności. Użyj ustawień diagnostycznych, aby wyeksportować te dane i udostępnić je do wykorzystania w alertach, zestawieniach oraz analizach długoterminowych poza krótkoterminowym okresem przechowywania platformy.

Zbierz metryki i dzienniki dla wszystkich zasobów. Śledzenie wykorzystania zasobów obliczeniowych i magazynowania względem oczekiwanych zakresów w celu potwierdzenia, że niedostateczna aprowizacja nie wprowadza opóźnień i obniża wydajności pod obciążeniem. Nadmierne przydzielanie zasobów jest również wykrywane przy użyciu tych danych, sprawdzając, jaki jest użycie P99 i porównując pozostałą rezerwę w stosunku do zasobów.

Monitorowanie ruchu sieciowego w ramach wydajności zasobów. Przeanalizuj przepływ ruchu między podsieciami i granicami usługi, aby zrozumieć opóźnienia, przeciążenia i wzorce transferu danych, które mogą mieć wpływ na wydajność obciążenia.

Zbieranie danych z bazy danych i danych przechowywania

Systemy baz danych i magazynowania generują wyspecjalizowane sygnały wydajności umożliwiające identyfikowanie wąskich gardeł, weryfikowanie pojemności i zrozumienie zachowania obciążenia. Te sygnały zwykle pochodzą z wbudowanych narzędzi do monitorowania i dzienników generowanych przez system.

Skup się na kluczowych wymiarach wydajności:

Obszar Co mierzyć Co to ci mówi
Przepustowość Wolumin odczytu/zapisu w czasie Pojemność transferu danych
Opóźnienie Czas na operację pamięci Czas odpowiedzi pamięci
liczba operacji we/wy na sekundę Operacje odczytu/zapisu na sekundę Możliwość obsługi transakcji
Użycie pojemności Używane i dostępne miejsce do magazynowania Potrzeby dotyczące planowania skalowania i pojemności

W przypadku baz danych rozszerz monitorowanie na zachowanie specyficzne dla obciążenia:

Obszar Co mierzyć Co to ci mówi
Wydajność zapytań Czas wykonywania, częstotliwość, użycie zasobów Wydajność wzorców dostępu do danych
Wydajność transakcji Długość trwania, współbieżność, rywalizacja o blokadę Rywalizacja i efektywność transakcyjna
Wydajność indeksu Fragmentacja, użycie, wpływ optymalizacji Skuteczność struktur przyspieszania zapytań
Użycie zasobów Procesor CPU, pamięć, dysk, sieć Ograniczenia na poziomie systemu
Metryki połączenia Aktywne, nieudane, przerwane połączenia Stabilność i ciśnienie połączenia
Szybkość transakcji Transakcje na sekundę Intensywność obciążenia i zmiany w czasie
Współczynniki błędów Błędy i awarie bazy danych Sygnały o degradacji niezawodności i wydajności

Użyj tych sygnałów razem do rozróżniania powolnych zapytań, nasycenia zasobów i nieefektywności strukturalnej. Umożliwia to optymalizację docelową zarówno w systemach magazynowania, jak i w obciążeniach baz danych.

Zbieranie danych wydajności systemu operacyjnego

W przypadku obciążeń opartych na infrastrukturze zbierz metryki na poziomie systemu operacyjnego, aby zrozumieć, jak są używane zasoby obliczeniowe i gdzie mogą wystąpić ograniczenia zasobów.

Próbkuj liczniki wydajności systemu operacyjnego w regularnych odstępach czasu, aby uchwycić czasowe zachowanie systemu pod obciążeniem.

Obszar Co mierzyć Co wskazuje
CPU Użycie procesora (użytkownik/uprzywilejowany), długość kolejki CPU Nasycenie zasobów obliczeniowych i obciążenie harmonogramu
Processes Liczba wątków, liczba uchwytów Obciążenie procesów na poziomie aplikacji i systemu operacyjnego
Memory Zatwierdzona pamięć, dostępna pamięć, szybkość stronicowania, użycie zamiany Obciążenie pamięci i aktywność stronicowania
Disk Szybkość odczytu/zapisu, przepływność, wykorzystanie dysku Wydajność operacji we/wy magazynu i wąskie gardła
Network Przepływność interfejsu, błędy RX/TX Problemy z pojemnością sieci i transmisją

Użyj tych sygnałów, aby zidentyfikować nasycenie zasobów na poziomie systemu operacyjnego i rozróżnić nieefektywność na poziomie aplikacji i ograniczenia infrastruktury.

Generowanie danych syntetycznych w razie potrzeby

Jeśli system nie jest używany spójnie, trudno stwierdzić, czy będzie działać dobrze, gdy ruch powróci.

Aby rozwiązać ten problem, użyj syntetycznych transakcji, które wysyła automatyczne żądania za pośrednictwem systemu. Symulują rzeczywiste użycie bez wpływu na rzeczywistych użytkowników lub dane. Pomaga to zachować aktywne części systemu, wygenerować spójne metryki wydajności i ujawnić wzorce (takie jak problemy z czasem dnia), które mogą ukrywać nieregularne użycie.

ułatwienia dostępu do Azure

Usługa Azure Monitor udostępnia ujednoliconą platformę do zbierania, analizowania i reagowania na dane wydajności w całym obciążeniu. Agreguje dane z aplikacji, infrastruktury i źródeł zewnętrznych do wspólnej platformy danych.

Zbieranie i przechowywanie danych: użyj obszarów roboczych usługi Log Analytics , aby scentralizować dane wydajności przy użyciu konfigurowalnych zasad przechowywania. Utwórz wiele obszarów roboczych w celu segmentowania danych według wymagań dotyczących środowiska lub zgodności.

Monitorowanie aplikacji: usługa Application Insights zbiera dane telemetryczne na poziomie aplikacji, w tym współczynniki żądań, czasy odpowiedzi i wyjątki. Włącz śledzenie rozproszone w celu skorelowania wydajności między składnikami rozproszonymi.

Monitorowanie infrastruktury: włącz ustawienia diagnostyczne we wszystkich usługach platformy Azure, aby zbierać dzienniki i metryki platformy. Użyj Azure Diagnostics, aby uzyskać szczegółowe dane dotyczące wydajności VM. Zapoznaj się z opcjami telemetrii dla określonej platformy. Na przykład klastry Kubernetes emitują zaawansowaną telemetrię wydajności przez integracje Prometheus.

Baza danych i magazyn: usługa Azure Monitor zapewnia wbudowane monitorowanie usług Azure SQL Database, MySQL, PostgreSQL i storage. Usługa Azure Storage Analytics śledzi kluczowe wskaźniki wydajności, takie jak przepływność i opóźnienie w obiektach blob, tabelach i usłudze Queue Storage.

Alerty i analiza: Utwórz reguły alertów z dostosowywalnymi progami, przedziałami czasowymi i akcjami (wiadomości e-mail, webhooki, Azure Functions). Użyj dzienników usługi Azure Monitor, aby wykonywać zapytania krzyżowe i korelować dane wydajności. Aby uzyskać szczegółowe informacje o cenach, zobacz Cennik usługi Azure Monitor.

Examples

Lista kontrolna efektywności działania

Zapoznaj się z kompletnym zestawem zaleceń.

Lista kontrolna efektywności wydajności

  • Last updated on