Zalecenia dotyczące projektowania i tworzenia systemu monitorowania

Artykuł
11/15/2023

Dotyczy tego zalecenia z listy kontrolnej dotyczącej doskonałości operacyjnej platformy Azure Well-Architected Framework:

OE:07	Projektowanie i implementowanie systemu monitorowania w celu weryfikowania 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.

Przewodnik pokrewny: 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 bezpieczeństwa, wydajności i niezawodności, potrzebny jest kompleksowy system z własnym stosem, który stanowi 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 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 udostępnianych 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.
Zbierz dzienniki i metryki z całego stosu obciążenia. Wszystkie zasoby infrastruktury i funkcje aplikacji powinny być skonfigurowane do tworzenia ustandaryzowanych, znaczących danych oraz zbierania 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ń o wystąpieniu problemów.
Uwzględnij systemy monitorowania i zgłaszania alertów w ogólnych rozwiązaniach dotyczących testowania obciążeń.
Upewnij się, że systemy monitorowania i zgłaszania alertów są w zakresie ciągłego ulepszania. Zachowanie aplikacji i infrastruktury w środowisku produkcyjnym zapewnia możliwości ciągłego uczenia się. 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 dopasować 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, przez cały dzień.

Ten potok przepływu pracy ilustruje system monitorowania:

Zbieranie danych instrumentacji

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, w celu przechwytywania danych telemetrycznych i/lub zdarzeń, takich jak dzienniki i metryki.

Dzienniki są szczególnie 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ą przydatne przede wszystkim podczas 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 przechwytywania 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ą cały cykl życia aplikacji. Rejestrowanie jest niezbędne do zrozumienia, w jaki sposób aplikacja działa w różnych środowiskach, które zdarzenia występują i w jakich warunkach występują.

Zalecamy zbieranie dzienników aplikacji i zdarzeń we wszystkich głównych środowiskach. W miarę możliwości rozdziel dane między środowiskami przy użyciu 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 strukturalnych z punktami danych z możliwością odczytu 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 ustrukturyzowane można łatwo indeksować i przeszukiwać, a raportowanie można znacznie uprościć.

Dane powinny być w formacie niezależnym od komputera, systemu operacyjnego lub protokołu sieciowego. Na przykład emituj informacje w formacie samoopisującym, np. 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 standardowym formacie, 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) przechwyć system operacyjny, warstwę 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, zbierz dzienniki z platformy w chmurze. Może być możliwe zbieranie dzienników aktywności dla subskrypcji i dzienników diagnostycznych dla płaszczyzny zarządzania.

Strategie zbierania

Unikaj ręcznego pobierania danych telemetrycznych z każdego składnika. Przenieś dane do centralnej lokalizacji i skonsoliduj je tam. W przypadku rozwiązania z wieloma regionami zalecamy najpierw zbieranie, konsolidację 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, określ 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 wrażliwe na czas.

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 składają się na każde wystąpienie aplikacji.

Monitorowanie agentów

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 współużytkowanego 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 programu SQL Server lub długość kolejki usługi 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 pojedynczej 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 obejmować pewien stopień nadmiarowości, aby zmniejszyć ryzyko utraty ważnych informacji monitorowania (takich jak inspekcja lub dane dotyczące 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 semantykę "co najmniej raz", która pomaga zagwarantować, ż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żna 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żesz użyć usługi Azure Event Hubs do wysłania danych do innego wystąpienia obliczeniowego na potrzeby przetwarzania i przechowywania.

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żna to zrobić po zapisaniu danych, ale w niektórych przypadkach można to zrobić w miarę zbierania danych.

Dane instrumentacji mogą przechodzić przez oddzielną usługę konsolidacji danych, która łączy dane i działa jako proces filtrowania i oczyszczania. Można na przykład 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ć zduplikowane dane. (Duplikowanie może wystąpić, jeśli usługa telemetrii używa kolejek komunikatów do wypychania danych instrumentacji do magazynu).

Przechowywanie danych na potrzeby zapytań i analiz

Po wybraniu 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 każdego środowiska.

Technologie magazynowania

Rozważ podejście do trwałości wielolotowej, w którym 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 usługi Azure Blob Storage i Azure Table Storage są dostępne 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.
Może być lepiej przechowywać dzienniki ś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, aby włączyć funkcje ochrony danych przed przypadkowym usunięciem, takie 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. Implementowanie oddzielnej usługi partycjonowania zmniejsza obciążenie usługi konsolidacji i oczyszczania i umożliwia ponowne wygenerowanie co najmniej niektórych partycjonowanych danych (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 zgłaszania alertów. W niektórych przypadkach może być konieczne, aby usługa zbierania 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 generowane do debugowania dostępne w postaci pierwotnej, ale następnie szybko odrzucić je po rozwiązaniu wszelkich usterek.

Dane wydajności często mają dłuższy czas życia, dzięki czemu można ich używać do odnajdowania 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 zmniejszyć liczbę próbek danych, 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 godzin po godzinie.

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ą. Przed zapisaniem tych danych należy wyczyścić te szczegóły.

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

Analizowanie danych w celu zrozumienia kondycji obciążenia

Po zebraniu danych z różnych źródeł danych przeanalizuj je, aby ocenić ogólne samopoczucie systemu. W przypadku tej analizy należy jasno zrozumieć następujące elementy:

Sposób tworzenia struktury 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 w diagnozowaniu problemów.

W większości przypadków dane dla każdego składnika architektury są przechwytywane lokalnie, a następnie dokładnie łączone z danymi wygenerowanymi 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

Korelowanie dzienników na poziomie aplikacji i na poziomie zasobów. 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 czas 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. Możesz na przykład zauważyć, że średnie czasy odpowiedzi powoli rosną wraz z upływem czasu i zbliżają się do maksymalnego celu.

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

Wizualizowanie raportów kondycji obciążenia

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 innej formie wizualnej. Te elementy można sparametryzować, a analityk może wybrać ważne parametry, takie jak okres, dla każdej konkretnej sytuacji.

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

Aby system pulpitu nawigacyjnego działał efektywnie, musi mieć znaczenie dla zespołu ds. obciążeń. Wizualizowanie informacji odnoszących się do kondycji obciążenia i jest również możliwe do 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 identyfikowania, gdzie w obciążeniu pochodzi problem, i rozpocząć działania naprawcze lub badania. Z drugiej strony uwzględnienie informacji, które nie są możliwe do działania lub które nie są związane z kondycją obciążenia, może sprawić, że pulpit nawigacyjny będzie niepotrzebnie złożony i frustrujący członkom zespołu, którzy próbują odróżnić szum w tle od danych z możliwością działania.

Możesz mieć pulpity nawigacyjne dla osób biorących udział w projekcie lub deweloperów dostosowanych do wyświetlania tylko danych dotyczących obciążenia, które znajdują odpowiednie. Upewnij się, że zespół ds. obciążeń rozumie typy punktów danych, które inne zespoły interesują się wyświetlaniem i wyświetlaniem podglądów pulpitów nawigacyjnych przed udostępnieniem ich w celu sprawdzenia jasności. Udostępnianie pulpitów nawigacyjnych dotyczących obciążenia uczestnikom projektu jest dobrym sposobem na zachowanie ich zachwytu nad kondycją obciążenia, ale niesie ze sobą ryzyko przeciwdziałania produktowi, jeśli osoby biorące udział w projekcie nie rozumieją wyraźnie widocznych danych.

Dobry pulpit nawigacyjny nie tylko wyświetla informacje. Umożliwia również analitykowi tworzenie 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 zapytanie o dane lub zaimportowanie ich do narzędzi, takich jak program Excel w celu dalszej analizy i raportowania.

Uwaga

Ogranicz dostęp do pulpitu nawigacyjnego autoryzowanym personelom. Informacje o pulpitach nawigacyjnych mogą być poufne komercyjnie. 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 należą do dwóch szerokich kategorii: 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 ogólnego systemu lub określonych podsystemów w określonym okresie.
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 mogą zostać zmniejszone 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 być ustrukturyzowane, aby umożliwić 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, które tworzą system i jak długo. Administrator może użyć tych danych do wygenerowania raportu użycia 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.

Definiowanie alertów dla kluczowych zdarzeń

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 działań diagnostycznych. 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 alerty identyfikujących właścicieli i akcji podlegających odpowiedzialności.
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żyj alertów, aby operacjonalizować procesy korygowania. Na przykład automatycznie twórz bilety w celu śledzenia problemów i rozwiązań.
Śledź kondycję usług platformy w chmurze w regionach, komunikację o awariach, 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ący czas na zaimplementowanie niezbędnych zmian w obciążeniu w celu uniknięcia pogorszenia lub awarii. Na przykład ustaw próg automatycznego skalowania, aby zainicjować skalowanie, zanim którykolwiek z uruchomionych systemów zostanie przytłoczony 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 przypadków użycia i innych zagadnień, zobacz Projektowanie niezawodnej strategii monitorowania i alertów.

Ułatwienia platformy Azure

Usługa Azure Monitor to kompleksowe rozwiązanie do monitorowania służące do zbierania, analizowania i reagowania na dane monitorowania ze środowisk w chmurze i środowiskach lokalnych.
Log Analytics to narzędzie w witrynie Azure Portal, za pomocą którego można edytować i uruchamiać zapytania dzienników względem danych w obszarze roboczym usługi Log Analytics.

Jeśli używasz wielu obszarów roboczych, zapoznaj się z przewodnikiem dotyczącym architektury obszaru roboczego usługi Log Analytics, aby uzyskać najlepsze rozwiązania.
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.
Usługa Azure Policy może pomóc w wymuszaniu standardów organizacyjnych i ocenie zgodności na dużą skalę.

Linki społecznościowe

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świadczenia w obserwacji 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

Udostępnij za pośrednictwem

Zalecenia dotyczące projektowania i tworzenia systemu monitorowania