Zalecenia dotyczące projektowania i tworzenia systemu monitorowania

Artykuł
11/15/2023

Dotyczy tej rekomendacji dotyczącej listy kontrolnej doskonałości operacyjnej platformy Azure Well-Architected Framework:

OE:07	Projektowanie i implementowanie systemu monitorowania w celu weryfikacji wyborów projektowych i informowania o przyszłych decyzjach projektowych i biznesowych. Ten system przechwytuje i uwidacznia operacyjne dane telemetryczne, metryki i dzienniki emitujące dane z infrastruktury i kodu obciążenia.

Powiązany przewodnik: Zalecenia dotyczące instrumentowania aplikacji

W tym przewodniku opisano zalecenia dotyczące projektowania i tworzenia systemu monitorowania. Aby efektywnie monitorować obciążenie pod kątem zabezpieczeń, wydajności i niezawodności, potrzebny jest kompleksowy system z własnym stosem, który zapewnia podstawę dla wszystkich funkcji monitorowania, wykrywania i alertów.

Definicje

Okres	Definicja
Dzienniki	Zarejestrowane zdarzenia systemowe. Dzienniki mogą zawierać różne typy danych w formacie tekstowym ustrukturyzowanym lub swobodnym. Zawierają sygnaturę czasową.
Metryki	Wartości liczbowe, które są zbierane w regularnych odstępach czasu. Metryki opisują niektóre aspekty systemu w określonym czasie.

Kluczowe strategie projektowania

Aby zaimplementować kompleksowy projekt systemu monitorowania dla obciążenia, wykonaj następujące podstawowe założenia:

Za każdym razem, gdy jest to praktyczne, skorzystaj z narzędzi do monitorowania dostarczanych przez platformę, które zwykle wymagają bardzo małej konfiguracji i mogą zapewnić szczegółowe informacje o obciążeniu, które w przeciwnym razie mogą być trudne do osiągnięcia.
Zbieranie dzienników i metryk z całego stosu obciążenia. Wszystkie zasoby infrastruktury i funkcje aplikacji powinny być skonfigurowane do tworzenia ustandaryzowanych, znaczących danych oraz do zbierania tych danych.
Przechowuj zebrane dane w ustandaryzowanym, niezawodnym i bezpiecznym rozwiązaniu magazynu.
Przetwarzanie przechowywanych danych w celu obsługi ich przez rozwiązania do analizy i wizualizacji.
Analizowanie przetworzonych danych w celu dokładnego określenia stanu obciążenia.
Wizualizowanie stanu obciążenia w znaczących pulpitach nawigacyjnych lub raportach dla zespołów obciążeń i innych uczestników projektu.
Konfigurowanie alertów z możliwością działania i innych automatycznych odpowiedzi na inteligentnie zdefiniowane progi w celu powiadamiania zespołów obciążeń w przypadku wystąpienia problemów.
Uwzględnij systemy monitorowania i alertów w ogólnych rozwiązaniach dotyczących testowania obciążeń.
Upewnij się, że systemy monitorowania i alertów są w zakresie ciągłego ulepszania. Zachowanie aplikacji i infrastruktury w środowisku produkcyjnym zapewnia możliwości ciągłego uczenia. Uwzględnij te lekcje w projektach monitorowania i zgłaszania alertów.
Związać dane monitorowania, które zbierasz i analizujesz z powrotem do systemu i przepływów użytkownika , aby skorelować kondycję przepływów z danymi oprócz ogólnej kondycji obciążenia. Analizowanie tych danych pod względem przepływów pomoże dostosować strategię obserwacji do modelu kondycji.

Należy zautomatyzować wszystkie funkcje systemu monitorowania tak bardzo, jak to możliwe, i wszystkie powinny działać w sposób ciągły, cały dzień, każdego dnia.

Ten potok przepływu pracy ilustruje system monitorowania:

Kolekcja

Uwaga

Musisz instrumentować aplikację, aby włączyć rejestrowanie. Aby uzyskać więcej informacji, zobacz przewodnik instrumentacji.

Należy skonfigurować wszystkie składniki obciążenia, niezależnie od tego, czy są to zasoby infrastruktury, czy funkcje aplikacji, do przechwytywania danych telemetrycznych i/lub zdarzeń, takich jak dzienniki i metryki.

Dzienniki są przede wszystkim przydatne do wykrywania i badania anomalii. Zazwyczaj dzienniki są generowane przez składnik obciążenia, a następnie wysyłane do platformy monitorowania lub ściągane przez platformę monitorowania za pośrednictwem automatyzacji.

Metryki są przede wszystkim przydatne do tworzenia modelu kondycji i identyfikowania trendów wydajności i niezawodności obciążeń. Metryki są również przydatne do identyfikowania trendów w zachowaniu użycia klientów. Te trendy mogą pomóc w podejmowaniu decyzji dotyczących ulepszeń z perspektywy klienta. Zazwyczaj metryki są definiowane na platformie monitorowania, a platforma monitorowania i inne narzędzia sondują obciążenie w celu przechwycenia metryk.

Dane aplikacji

W przypadku aplikacji usługa zbierania może być narzędziem do zarządzania wydajnością aplikacji (APM), które może działać autonomicznie z poziomu aplikacji, która generuje dane instrumentacji. Po włączeniu funkcji APM masz jasny wgląd w ważne metryki w czasie rzeczywistym i historycznie. Użyj odpowiedniego poziomu rejestrowania. Pełne rejestrowanie może spowodować znaczne koszty. Ustaw poziomy dziennika zgodnie ze środowiskiem. Niższe środowiska nie potrzebują na przykład tego samego poziomu szczegółowości co środowisko produkcyjne.

Dzienniki aplikacji obsługują kompleksowe cykl życia aplikacji. Rejestrowanie jest niezbędne do zrozumienia, jak aplikacja działa w różnych środowiskach, które zdarzenia występują, oraz warunki, w których występują.

Zalecamy zbieranie dzienników i zdarzeń aplikacji we wszystkich głównych środowiskach. Rozdziel dane między środowiskami tak bardzo, jak to możliwe, używając różnych magazynów danych dla każdego środowiska, jeśli tak jest praktyczne. Użyj filtrów, aby upewnić się, że środowiska niekrytyczne nie komplikują interpretacji dzienników produkcyjnych. Na koniec odpowiednie wpisy dziennika w aplikacji powinny przechwytywać identyfikator korelacji dla odpowiednich transakcji.

Zdarzenia aplikacji należy przechwycić w typach danych ze strukturą z punktami danych czytelnymi dla maszyny, a nie typami ciągów bez struktury. Format ustrukturyzowany używający dobrze znanego schematu może ułatwić analizowanie i analizowanie dzienników. Ponadto dane strukturalne można łatwo indeksować i przeszukiwać, a raportowanie można znacznie uprościć.

Dane powinny być w formacie niezależnym od maszyny, systemu operacyjnego lub protokołu sieciowego. Na przykład emituj informacje w formacie samoopisującym, na przykład JSON, MessagePack lub Protobuf, a nie ETL/ETW. Standardowy format umożliwia systemowi konstruowanie potoków przetwarzania. Składniki, które odczytują, przekształcają i wysyłają dane w formacie standardowym, można łatwo zintegrować.

Dane infrastruktury

W przypadku zasobów infrastruktury w obciążeniu upewnij się, że są zbierane zarówno dzienniki, jak i metryki. W przypadku systemów infrastruktury jako usługi (IaaS) należy przechwytywać systemy operacyjne, warstwy aplikacji i dzienniki diagnostyczne oprócz metryk związanych z kondycją obciążenia. W przypadku zasobów platformy jako usługi (PaaS) możesz ograniczyć możliwość przechwytywania dzienników powiązanych z podstawową infrastrukturą, ale upewnij się, że oprócz metryk związanych z kondycją obciążenia można przechwytywać dzienniki diagnostyczne.

Jak najwięcej, zbieraj dzienniki z platformy w chmurze. Możesz zbierać dzienniki aktywności dla subskrypcji i dzienników diagnostycznych dla płaszczyzny zarządzania.

Strategie kolekcji

Unikaj ręcznego pobierania danych telemetrycznych z każdego składnika. Przenieś dane do centralnej lokalizacji i skonsoliduj je tam. W przypadku rozwiązania obejmującego wiele regionów zalecamy najpierw zbieranie, konsolidowanie i przechowywanie danych w poszczególnych regionach, a następnie agregowanie danych regionalnych w jednym systemie centralnym.

Kompromis: należy pamiętać, że istnieją konsekwencje związane z kosztami posiadania regionalnych i scentralizowanych magazynów danych.

Aby zoptymalizować wykorzystanie przepustowości, należy określić priorytety na podstawie znaczenia danych. Mniej pilne dane można przesyłać w partiach. Jednak te dane nie mogą być opóźnione na czas nieokreślony, zwłaszcza jeśli zawierają informacje poufne czasowo.

Istnieją dwa podstawowe modele, których usługa kolekcji może używać do zbierania danych instrumentacji:

Model ściągania: aktywnie pobiera dane z różnych dzienników i innych źródeł dla każdego wystąpienia aplikacji.
Model wypychania: pasywnie czeka na wysłanie danych ze składników, które stanowią każde wystąpienie aplikacji.

Agenci monitorowania

Agentów monitorowania można używać w modelu ściągania. Agenci są uruchamiani lokalnie w osobnym procesie z każdym wystąpieniem aplikacji, okresowo ściągając dane i zapisując informacje bezpośrednio do wspólnego magazynu, który jest współużytkowany przez wszystkie wystąpienia aplikacji.

Uwaga

Używanie agenta monitorowania idealnie nadaje się do przechwytywania danych instrumentacji, które są naturalnie ściągane ze źródła danych. Jest to odpowiednie dla aplikacji o małej skali, która działa w ograniczonej liczbie węzłów w jednej lokalizacji. Przykłady obejmują informacje z dynamicznych widoków zarządzania SQL Server lub długość kolejki Azure Service Bus.

Zagadnienia dotyczące wydajności

Złożona i wysoce skalowalna aplikacja może generować ogromne ilości danych. Ilość danych może łatwo przytłoczyć przepustowość we/wy dostępną dla jednej centralnej lokalizacji. Rozwiązanie telemetryczne nie może działać jako wąskie gardło i musi być skalowalne w miarę rozszerzania systemu. W idealnym przypadku rozwiązanie powinno zawierać stopień nadmiarowości, aby zmniejszyć ryzyko utraty ważnych informacji monitorowania (takich jak inspekcja lub dane rozliczeń), jeśli część systemu ulegnie awarii.

Jednym ze sposobów buforowania danych instrumentacji jest użycie kolejkowania:

W tej architekturze usługa zbierania danych publikuje dane w kolejce. Kolejka komunikatów jest odpowiednia, ponieważ zapewnia semantyka "co najmniej raz", która pomaga zapewnić, że dane umieszczone w kolejce nie zostaną utracone po opublikowaniu. Usługę zapisywania magazynu można zaimplementować przy użyciu oddzielnej roli procesu roboczego. Aby zaimplementować tę architekturę, możesz użyć wzorca kolejki priorytetu .

W celu zapewnienia skalowalności można uruchomić wiele wystąpień usługi zapisywania magazynu. Jeśli monitorowana jest duża liczba zdarzeń lub duża liczba punktów danych, można użyć Azure Event Hubs do wysłania danych do innego wystąpienia obliczeniowego na potrzeby przetwarzania i magazynowania.

Strategie konsolidacji

Dane zebrane z pojedynczego wystąpienia aplikacji zapewniają zlokalizowany widok kondycji i wydajności tego wystąpienia. Aby ocenić ogólną kondycję systemu, należy skonsolidować niektóre aspekty danych z widoków lokalnych. Możesz to zrobić po zapisaniu danych, ale w niektórych przypadkach można to zrobić, gdy dane są zbierane.

Dane instrumentacji mogą przechodzić przez oddzielną usługę konsolidacji danych, która łączy dane i działa jako proces filtrowania i oczyszczania. Na przykład możesz amalgamate danych instrumentacji, które zawierają te same informacje korelacji, takie jak identyfikator działania. (Użytkownik może rozpocząć operację biznesową w jednym węźle, a następnie przenieść do innego węzła, jeśli pierwszy węzeł ulegnie awarii lub ze względu na sposób konfigurowania równoważenia obciążenia). Ten proces może również wykrywać i usuwać wszelkie zduplikowane dane. (Duplikowanie może wystąpić, jeśli usługa telemetrii używa kolejek komunikatów do wypychania danych instrumentacji do magazynu).

Storage

W przypadku wybrania rozwiązania magazynu należy wziąć pod uwagę typ danych, sposób ich użycia i pilny sposób ich użycia.

Uwaga

Używaj oddzielnych rozwiązań magazynu dla środowisk nieprodukcyjnych i produkcyjnych, aby zapewnić łatwe identyfikowanie i zarządzanie danymi z poszczególnych środowisk.

Technologie magazynowania

Należy rozważyć podejście trwałości wielolotowej, w której różne typy informacji są przechowywane w technologiach, które są najbardziej odpowiednie do sposobu, w jaki każdy typ może być używany.

Na przykład dostęp do Azure Blob Storage i usługi Azure Table Storage można uzyskać w podobny sposób. Jednak operacje, które można wykonać na nich, różnią się, podobnie jak stopień szczegółowości przechowywanych danych. Jeśli musisz wykonać więcej operacji analitycznych lub potrzebujesz możliwości wyszukiwania pełnotekstowego w danych, może być bardziej odpowiednie użycie magazynu danych zapewniającego możliwości, które są zoptymalizowane dla określonych typów zapytań i dostępu do danych. Na przykład:

Dane liczników wydajności mogą być przechowywane w bazie danych SQL, aby umożliwić analizę ad hoc.
Lepszym rozwiązaniem może być przechowywanie dzienników śledzenia w dziennikach usługi Azure Monitor lub w usłudze Azure Data Explorer.
Informacje o zabezpieczeniach można przechowywać w rozwiązaniu HDFS.

Te same dane instrumentacji mogą być wymagane dla więcej niż jednego celu. Na przykład można użyć liczników wydajności, aby zapewnić historyczny widok wydajności systemu w czasie. Te informacje mogą być łączone z innymi danymi użycia w celu wygenerowania informacji o rozliczeniach z klientem. W takich sytuacjach te same dane mogą być wysyłane do więcej niż jednego miejsca docelowego, na przykład do bazy danych dokumentów, która może być długoterminowym magazynem do przechowywania informacji rozliczeniowych oraz do wielowymiarowego magazynu do obsługi złożonej analizy wydajności.

Pamiętaj o włączeniu funkcji ochrony danych przed przypadkowym usunięciem, takich jak blokady zasobów i usuwanie nietrwałe.

Upewnij się również, że zabezpieczasz dostęp do magazynu przy użyciu kontroli dostępu opartej na rolach, aby zapewnić, że tylko osoby, które muszą uzyskać dostęp do danych, mogą to zrobić.

Usługa konsolidacji

Można zaimplementować inną usługę, która okresowo pobiera dane z magazynu udostępnionego, partycji i filtrów zgodnie z jego celem, a następnie zapisuje je w odpowiednim zestawie magazynów danych.

Alternatywnym podejściem jest dołączenie tej funkcji w procesie konsolidacji i czyszczenia oraz zapisywanie danych bezpośrednio do tych magazynów, skąd zostały pobrane zamiast zapisywania ich w pośrednim obszarze udostępnionego magazynu.

Każde podejście ma swoje zalety i wady. Implementacja oddzielnej usługi partycjonowania zmniejsza obciążenie usługi konsolidacji i oczyszczania i umożliwia ponowne generowanie co najmniej niektórych partycjonowanych danych w razie potrzeby (w zależności od ilości danych przechowywanych w magazynie udostępnionym). Jednak takie podejście zużywa dodatkowe zasoby. Ponadto mogą wystąpić opóźnienia między odebraniem danych instrumentacji z każdego wystąpienia aplikacji a konwersją tych danych do informacji umożliwiających wykonanie akcji.

Zagadnienia dotyczące wykonywania zapytań

Zastanów się, jak pilnie wymagane są dane. Dane, które generują alerty, muszą być szybko dostępne, więc powinny być przechowywane w szybkim magazynie danych i indeksowane lub ustrukturyzowane w celu zoptymalizowania zapytań, które wykonuje system alertów. W niektórych przypadkach może być konieczne, aby usługa zbierania mogła formatować i zapisywać dane lokalnie, aby lokalne wystąpienie systemu alertów mogło szybko wysyłać powiadomienia. Te same dane mogą być przekazane do usługi zapisywania do magazynu pokazanej na poprzednich diagramach oraz przechowywane centralnie, jeśli jest to wymagane również dla innych celów.

Zagadnienia dotyczące przechowywania danych

W niektórych przypadkach po przetworzeniu i przesłaniu danych można usunąć oryginalne nieprzetworzone dane źródłowe przechowywane lokalnie. W innych przypadkach może być konieczne lub przydatne zapisanie nieprzetworzonych informacji. Na przykład możesz zachować dane wygenerowane do debugowania dostępne w postaci pierwotnej, ale następnie szybko odrzucić je po rozwiązaniu wszelkich usterek.

Dane dotyczące wydajności często mają dłuższy okres życia, dzięki czemu można go używać do wykrywania trendów wydajności i planowania pojemności. Skonsolidowany widok tych danych jest zazwyczaj dostępny w trybie online przez określony czas, aby umożliwić szybki dostęp. Następnie można go zarchiwizować lub odrzucić.

Jest to przydatne do przechowywania danych historycznych, dzięki czemu można zauważyć trendy długoterminowe. Zamiast zapisywać stare dane w całości, możesz w dół próbkować dane, aby zmniejszyć ich rozdzielczość i zmniejszyć koszty magazynowania. Na przykład zamiast zapisywać wskaźniki wydajności minut po minutach, można skonsolidować dane, które mają więcej niż miesiąc, aby utworzyć widok godzinowo-godzinny.

Dane zbierane do pomiarów i rozliczeń klientów być może muszą być przechowywane w nieskończoność. Ponadto wymagania prawne mogą dyktować, że informacje zebrane na potrzeby inspekcji i zabezpieczeń muszą być archiwizowane i zapisywane. Te dane są również poufne i może być konieczne ich szyfrowanie lub zabezpieczenie w inny sposób przed manipulacjami. Nigdy nie należy rejestrować haseł użytkowników ani innych informacji, które mogą być używane do zatwierdzania oszustw związanych z tożsamością. Te szczegóły należy wyczyścić przed zapisaniem danych.

Aby zapewnić zgodność z przepisami i przepisami, zminimalizuj przechowywanie wszelkich możliwych do zidentyfikowania informacji. Jeśli musisz przechowywać informacje możliwe do zidentyfikowania, pamiętaj, aby podczas projektowania rozwiązania uwzględnić wymagania, które umożliwiają osobom żądanie usunięcia ich informacji.

Analiza

Po zebraniu danych z różnych źródeł danych przeanalizuj je, aby ocenić ogólne samopoczucie systemu. Na potrzeby tej analizy należy jasno zrozumieć:

Jak strukturę danych na podstawie zdefiniowanych wskaźników KPI i metryk wydajności.
Jak skorelować dane przechwycone w różnych metrykach i plikach dziennika. Ta korelacja jest ważna podczas śledzenia sekwencji zdarzeń i może pomóc zdiagnozować problemy.

W większości przypadków dane dla każdego składnika architektury są przechwytywane lokalnie, a następnie dokładnie łączone z danymi generowanymi przez inne składniki.

Na przykład aplikacja trójwarstwowa może mieć następujące elementy:

Warstwa prezentacji, która umożliwia użytkownikowi łączenie się z witryną internetową.
Warstwa środkowa, która hostuje zestaw mikrousług, które przetwarzają logikę biznesową.
Warstwa bazy danych, która przechowuje dane skojarzone z operacją.

Dane użycia dla jednej operacji biznesowej mogą obejmować wszystkie trzy warstwy. Te informacje muszą być skorelowane, aby zapewnić ogólny widok użycia zasobów i przetwarzania dla operacji. Korelacja może obejmować pewne wstępne przetwarzanie i filtrowanie danych w warstwie bazy danych. W warstwie środkowej agregacja i formatowanie są typowymi zadaniami.

Zalecenia

Skoreluj dzienniki na poziomie aplikacji i na poziomie zasobu. Oceń dane na obu poziomach, aby zoptymalizować wykrywanie problemów i rozwiązywanie tych problemów. Dane można agregować w jednym ujściu danych lub korzystać z metod, które wysyłają zapytania o zdarzenia na obu poziomach. Zalecamy ujednolicone rozwiązanie, takie jak Azure Log Analytics, w celu agregowania i wykonywania zapytań dotyczących dzienników na poziomie aplikacji i na poziomie zasobów.
Zdefiniuj jasne czasy przechowywania w magazynie na potrzeby analizy zimnej. Zalecamy włączenie analizy historycznej w określonym okresie. Może również pomóc w kontrolowaniu kosztów magazynowania. Zaimplementuj procesy, które zapewniają archiwizowanie danych w tańszym magazynie i agregowanie danych na potrzeby długoterminowej analizy trendów.
Analizowanie długoterminowych trendów w celu przewidywania problemów operacyjnych. Ocena długoterminowych danych w celu utworzenia strategii operacyjnych, a także przewidywania, jakie problemy operacyjne mogą wystąpić i kiedy. Na przykład możesz zauważyć, że średni czas odpowiedzi powoli rośnie wraz z upływem czasu i zbliża się do maksymalnego celu.

Aby uzyskać szczegółowe wskazówki dotyczące tych zaleceń, zobacz Analizowanie danych monitorowania dla aplikacji w chmurze.

Wizualizacja

Pulpity nawigacyjne

Najczęstszym sposobem wizualizacji danych jest użycie pulpitów nawigacyjnych, które mogą wyświetlać informacje jako serię wykresów lub grafów lub w innym formularzu wizualnym. Te elementy można sparametryzować, a analityk może wybrać ważne parametry, takie jak okres, dla każdej konkretnej sytuacji.

Dostosuj pulpity nawigacyjne do modelu kondycji , aby wskazać, kiedy obciążenie lub składniki obciążenia są w dobrej kondycji, obniżonej kondycji lub złej kondycji.

Aby system pulpitu nawigacyjnego działał efektywnie, musi być zrozumiały dla zespołu ds. obciążeń. Wizualizowanie informacji związanych z kondycją obciążenia i możliwość działania. Gdy obciążenie lub składnik jest obniżony lub jest w złej kondycji, członkowie zespołu obciążenia powinni mieć możliwość łatwego zidentyfikowania, skąd pochodzi problem, i rozpoczęcia działań naprawczych lub badań. Z drugiej strony, w tym informacje, które nie są możliwe do działania lub które nie są związane z kondycją obciążenia, mogą sprawić, że pulpit nawigacyjny będzie niepotrzebnie złożony i frustrujący członkom zespołu, którzy próbują rozpoznać hałas w tle z danych z możliwością działania.

Możesz mieć pulpity nawigacyjne dla osób biorących udział w projekcie lub deweloperów, które są dostosowane do wyświetlania tylko danych dotyczących obciążenia, które są odpowiednie. Upewnij się, że zespół ds. obciążeń rozumie typy punktów danych, które inne zespoły są zainteresowane wyświetlaniem i wyświetlaniem podglądu pulpitów nawigacyjnych przed udostępnieniem ich w celu sprawdzenia przejrzystości. Zapewnienie pulpitów nawigacyjnych dotyczących obciążenia dla uczestników projektu jest dobrym sposobem na zapewnienie im obsługi kondycji obciążenia, ale niesie ze sobą ryzyko kontrproduktywności, jeśli uczestnicy projektu nie rozumieją wyraźnie danych, które widzą.

Dobry pulpit nawigacyjny nie wyświetla tylko informacji. Umożliwia również analitykowi zadawanie improwizowanych pytań dotyczących tych informacji. Niektóre systemy udostępniają narzędzia do zarządzania, których operator może używać do wykonywania tych zadań i eksplorowania danych bazowych. Zamiast tego w zależności od repozytorium używanego do przechowywania informacji może być możliwe bezpośrednie wykonywanie zapytań o dane lub importowanie ich do narzędzi, takich jak program Excel w celu dalszej analizy i raportowania.

Uwaga

Ograniczanie dostępu do pulpitu nawigacyjnego do autoryzowanego personelu. Informacje na pulpitach nawigacyjnych mogą być poufne na rynku. Należy również chronić dane bazowe, aby uniemożliwić użytkownikom ich zmianę.

Raportowanie

Raportowanie służy do generowania ogólnego widoku systemu. Może zawierać dane historyczne i bieżące informacje. Wymagania dotyczące raportowania dzielą się na dwie szerokie kategorie: raportowanie operacyjne i raportowanie zabezpieczeń.

Raportowanie operacyjne zwykle obejmuje następujące elementy:

Agregowanie statystyk, których można użyć do zrozumienia wykorzystania zasobów ogólnego systemu lub określonych podsystemów w określonym przedziale czasu.
Identyfikowanie trendów użycia zasobów dla całego systemu lub określonych podsystemów w określonym przedziale czasu.
Monitorowanie wyjątków, które wystąpiły w całym systemie lub w określonych podsystemach w określonym okresie.
Określenie wydajności aplikacji dla wdrożonych zasobów i zrozumienie, czy ilość zasobów i związane z nimi koszty można zmniejszyć bez niepotrzebnego wpływu na wydajność.

Raportowanie zabezpieczeń śledzi użycie systemu przez klienta. Może ono obejmować:

Inspekcję operacji użytkownika. To zadanie wymaga zarejestrowania poszczególnych żądań, które każdy użytkownik ukończy wraz z datami i godzinami. Dane powinny mieć strukturę umożliwiającą administratorowi szybkie odtworzenie sekwencji operacji wykonywanych przez użytkownika w określonym przedziale czasu.
Śledzenie wykorzystania zasobów przez użytkownika. To zadanie wymaga zarejestrowania, jak każde żądanie od użytkownika uzyskuje dostęp do różnych zasobów tworzących system i jak długo. Administrator może użyć tych danych do wygenerowania raportu wykorzystania przez użytkownika przez określony okres, prawdopodobnie na potrzeby rozliczeń.

W wielu przypadkach procesy wsadowe mogą generować raporty zgodnie ze zdefiniowanym harmonogramem. Opóźnienie nie jest zwykle problemem. Należy również mieć procesy wsadowe, które mogą generować raporty spontanicznie zgodnie z potrzebami. Jeśli na przykład dane są przechowywane w relacyjnej bazie danych, takiej jak Azure SQL Database, możesz użyć narzędzia, takiego jak SQL Server Reporting Services, aby wyodrębnić i sformatować dane i przedstawić je jako zestaw raportów.

Alerty

Aby zapewnić, że system pozostanie w dobrej kondycji, dynamiczny i bezpieczny, ustaw alerty, aby operatorzy mogli reagować na nie w odpowiednim czasie. Alert może zawierać wystarczającą ilość informacji kontekstowych, aby ułatwić im szybkie rozpoczęcie pracy z działaniami diagnostycznymi. Alerty mogą służyć do wywoływania funkcji korygowania, takich jak autoskalowanie lub inne mechanizmy samonaprawiania. Alerty mogą również umożliwić rozpoznawanie kosztów, zapewniając wgląd w budżety i limity.

Zalecenia

Zdefiniuj proces reagowania na alert, który identyfikuje odpowiedzialnych właścicieli i akcji.
Skonfiguruj alerty dla dobrze zdefiniowanego zakresu (typów zasobów i grup zasobów) i dostosuj szczegółowość, aby zminimalizować szum.
Użyj zautomatyzowanego rozwiązania do zgłaszania alertów, takiego jak Splunk lub Azure Monitor, zamiast wymagać od osób aktywnego wyszukiwania problemów.
Używaj alertów do operacjonalizacji procesów korygowania. Na przykład automatyczne tworzenie biletów w celu śledzenia problemów i rozwiązań.
Śledź kondycję usług platformy w chmurze w regionach, komunikację na temat awarii, planowane działania konserwacyjne i inne porady dotyczące kondycji.

Progi

Alerty są generowane po przekroczeniu progów wykrytych przez system monitorowania. Upewnij się, że ustawione progi zwykle zapewniają wystarczająco dużo czasu, aby zaimplementować niezbędne zmiany w obciążeniu, aby uniknąć pogorszenia lub awarii. Na przykład ustaw próg automatycznego skalowania, aby zainicjować skalowanie, zanim którykolwiek z uruchomionych systemów zostanie przeciążony do punktu obniżonej wydajności środowiska użytkownika. Bazuj wartości progowe przypisywane w przeszłości w zarządzaniu infrastrukturą i weryfikują je za pomocą testów, które są wykonywane w ramach praktyk testowych.

Aby uzyskać szczegółowe wskazówki dotyczące zgłaszania alertów dotyczących przypadków użycia i innych zagadnień, zobacz Projektowanie niezawodnej strategii monitorowania i zgłaszania alertów.

Ułatwienia dla platformy Azure

Usługa Azure Monitor to kompleksowe rozwiązanie do monitorowania służące do zbierania, analizowania i reagowania na dane monitorowania z chmury i środowisk lokalnych.
Log Analytics to narzędzie w Azure Portal, którego można użyć do edytowania i uruchamiania zapytań dzienników względem danych w obszarze roboczym usługi Log Analytics.

Jeśli używasz wielu obszarów roboczych, zobacz Przewodnik po architekturze obszaru roboczego usługi Log Analytics, aby zapoznać się z najlepszymi rozwiązaniami.
Application Insights to rozszerzenie usługi Azure Monitor. Udostępnia funkcje APM.
Usługa Azure Monitor Insights to zaawansowane narzędzia analityczne dla określonych technologii platformy Azure (takich jak maszyny wirtualne, usługi app services i kontenery). Te narzędzia są częścią usług Azure Monitor i Log Analytics.
Usługa Azure Monitor dla rozwiązań SAP to narzędzie do monitorowania platformy Azure dla środowisk SAP, które działają na platformie Azure.
Azure Policy może pomóc w wymuszaniu standardów organizacyjnych i ocenie zgodności na dużą skalę.

Linki społeczności

Alerty linii bazowej usługi Azure Monitor (AMBA) to centralne repozytorium definicji alertów, których klienci i partnerzy mogą używać do ulepszania ich doświadczeń z obserwacją dzięki wdrożeniu usługi Azure Monitor.

Lista kontrolna doskonałości operacyjnej

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna doskonałości operacyjnej

Zalecenia dotyczące projektowania i tworzenia systemu monitorowania