Najlepsze rozwiązania dotyczące monitorowania i diagnostyki

Rozproszone aplikacje i usługi działające w chmurze to złożone oprogramowanie, które składa się z wielu ruchomych części. W środowisku produkcyjnym ważne jest śledzenie sposobu używania systemu przez klientów, śledzenia wykorzystania zasobów oraz monitorowania kondycji i wydajności systemu. Dzięki tym informacjom można wykrywać i naprawiać problemy oraz przechwytywać potencjalne problemy przed ich wystąpieniem.

Scenariusze monitorowania i diagnostyki

Monitorowanie umożliwia uzyskanie wglądu w to, jak dobrze działa system. Monitorowanie jest kluczową częścią utrzymania celów jakości usług (QoS). Zbierz dane monitorowania dla następujących typowych scenariuszy:

• Upewnij się, że system pozostaje w dobrej kondycji.

• Śledzenie dostępności systemu i jego składników.

• Zachowaj wydajność, aby zapewnić, że przepływność systemu nie ulega nieoczekiwanemu pogorszeniu w miarę wzrostu ilości pracy.

• Zagwarantowanie, że system spełnia umowy dotyczące poziomu usług (SLA).

• Ochrona prywatności i bezpieczeństwa systemu, użytkowników i ich danych.

• Śledzenie inspekcji lub operacji regulacyjnych.

• Monitoruj codzienne użycie systemu i rozwiąż trendy, które mogą prowadzić do problemów.

• Śledź problemy, które występują, od początkowego raportu do analizy możliwych przyczyn, recyfikacji, aktualizacji oprogramowania i wdrażania.

• Śledź operacje i debuguj wersje oprogramowania.

W poniższych sekcjach opisano te scenariusze bardziej szczegółowo.

Monitorowanie kondycji

System w dobrej kondycji działa i może przetwarzać żądania. Użyj monitorowania kondycji, aby wygenerować migawkę bieżącej kondycji systemu, aby sprawdzić, czy wszystkie składniki działają zgodnie z oczekiwaniami.

Konfigurowanie alertów

System powinien zgłosić alert w ciągu kilku sekund, jeśli jakakolwiek część jest w złej kondycji. Alerty mogą wskazywać stan systemu za pomocą sygnałów świetlnych:

• Czerwony oznacza nieprawidłowy stan (system przestał działać)
• Żółty dla częściowej sprawności (system działa z ograniczoną funkcjonalnością)
• Zielony dla dobrej kondycji

Kompleksowy system monitorowania kondycji pokazuje stan kondycji każdego podsystemu i składnika, dzięki czemu można określić, które części działają normalnie i które części mają problemy.

Zbieranie danych dotyczących kondycji

Następujące źródła mogą wygenerować nieprzetworzone dane wymagane do obsługi monitorowania kondycji:

• Śledzenie wykonywania żądań użytkowników. Te informacje umożliwiają określenie, które żądania kończą się powodzeniem lub niepowodzeniem, i mierzyć czas stosowania poszczególnych żądań.

• Monitorowanie użytkowników syntetycznych. Ten proces symuluje akcje wykonywane przez użytkownika i wykonuje wstępnie zdefiniowaną serię kroków. Przechwyć wyniki każdego kroku.

• Rejestrowanie wyjątków, błędów i ostrzeżeń. Te informacje można przechwycić z instrukcji śledzenia osadzonych w kodzie aplikacji oraz z dzienników zdarzeń usług, do których odwołuje się system.

• Monitoruj stan usług innych niż Microsoft używanych przez system. Może być konieczne pobranie i przeanalizowanie danych dotyczących kondycji, które dostarczają te usługi.

• Monitorowanie punktów końcowych.

• Zbierz informacje o wydajności otoczenia, takie jak wykorzystanie procesora CPU w tle lub operacje wejścia/wyjścia (we/wy), w tym działania sieciowe.

Analizowanie danych dotyczących kondycji

Głównym celem monitorowania kondycji jest szybkie wskazanie, czy system jest uruchomiony. Gorąca analiza natychmiastowych danych może wyzwolić alert, jeśli krytyczny składnik jest w złej kondycji.

Bardziej zaawansowany system może obejmować element predykcyjny, który wykonuje zimną analizę ostatnich i bieżących obciążeń. Analiza zimna może identyfikować trendy i określać, czy system prawdopodobnie pozostanie w dobrej kondycji, czy potrzebuje więcej zasobów. Ten element predykcyjny opiera się na następujących krytycznych metrykach wydajności:

• Szybkość żądań skierowanych do każdej usługi lub podsystemu
• Czasy odpowiedzi tych żądań
• Ilość danych, które przepływają do i z każdej usługi

Jeśli wartość dowolnej metryki przekroczy zdefiniowany próg, system może zgłosić alert w celu skalowania w górę. Możesz również dodać zasoby, ponownie uruchomić usługi zakończone niepowodzeniem lub ograniczyć żądania o niższym priorytcie, aby zachować kondycję systemu.

Monitorowanie dostępności

W systemie w dobrej kondycji są dostępne wszystkie składniki i podsystemy. Monitorowanie dostępności jest ściśle związane z monitorowaniem kondycji. Monitorowanie kondycji zapewnia natychmiastowy widok bieżącej kondycji systemu. Monitorowanie dostępności śledzi dostępność systemu i jego składników w celu wygenerowania statystyk dotyczących czasu pracy.

W wielu systemach niektóre składniki, takie jak bazy danych, są skonfigurowane z wbudowaną nadmiarowością, aby umożliwić szybkie przejście w tryb failover w przypadku wystąpienia poważnej awarii lub utraty łączności. Zbierz jak najwięcej informacji na temat tych niepowodzeń, aby określić przyczynę i podjąć działania naprawcze, aby zapobiec cyklowi.

Dane wymagane do śledzenia dostępności mogą zależeć od wielu czynników niższego poziomu, które mogą być specyficzne dla aplikacji, systemu i środowiska. Skuteczny system monitorowania przechwytuje dane dostępności odpowiadające tym czynnikom niskiego poziomu, a następnie agreguje je w celu zapewnienia ogólnego obrazu systemu. Na przykład w systemie handlu elektronicznego funkcjonalność biznesowa, która umożliwia klientowi składania zamówień, może zależeć od repozytorium przechowującego szczegóły zamówienia i system płatności obsługujący transakcje pieniężne. Dostępność funkcji umieszczania zamówień zależy od dostępności repozytorium i podsystemu płatności.

Rozwiązanie do monitorowania dostępności zapewnia bieżące i historyczne widoki stanu dostępności każdego podsystemu. Szybko powiadamia o awarii co najmniej jednej usługi lub gdy użytkownicy nie mogą łączyć się z usługami. Użyj tych informacji, aby zidentyfikować trendy, które mogą spowodować awarię podsystemów. Na przykład można użyć danych dostępności, aby wykryć, które usługi kończą się niepowodzeniem w godzinach przetwarzania szczytu.

Zbieranie danych dotyczących dostępności

Monitoruj syntetycznych użytkowników, rejestruj wyjątki, awarie i ostrzeżenia oraz monitoruj punkty końcowe, aby generować surowe dane wymagane do obsługi monitorowania dostępności. Aplikacja może udostępniać jeden lub więcej punktów końcowych monitorowania kondycji, z których każdy testuje dostęp do obszaru funkcjonalnego systemu. System monitorowania działa zgodnie z określonym harmonogramem, wysyłając polecenie ping do każdego punktu końcowego i zbierając wyniki, takie jak sukces lub niepowodzenie.

Rejestruj wszystkie przekroczenia limitu czasu, błędy łączności sieciowej i próby ponawiania połączenia oraz sygnaturę czasową wszystkich danych.

Analizowanie danych dotyczących dostępności

Agregowanie i korelowanie danych w celu obsługi następujących typów analizy:

• Natychmiastowa dostępność systemu i podsystemów.

• Współczynniki błędów dostępności systemu i podsystemów. Koreluj błędy z określonymi działaniami, aby zrozumieć przyczyny awarii systemu.

• Historyczny widok współczynników awarii w określonym okresie i obciążenie systemu, takie jak liczba żądań użytkowników, w przypadku wystąpienia awarii.

• Przyczyny niedostępności systemu lub podsystemów. Przyczyny te obejmują nieuruchomienie usługi, utratę łączności, przekroczenie limitu czasu lub odpowiedzi z kodem błędu.

Procent dostępności usługi można obliczyć w danym okresie, używając następującej formuły:

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

Użyj tej formuły do monitorowania umowy SLA. Definicja przestoju zależy od usługi. Na przykład usługa kompilacji Azure DevOps definiuje przestój jako okres łączny skumulowany w minutach, w których usługa kompilacji jest niedostępna. Usługa jest uznawana za niedostępną przez jedną minutę, jeśli wszystkie ciągłe żądania HTTP w ciągu tej minuty spowodują wyświetlenie kodu błędu lub nie zwróci odpowiedzi.

Monitorowanie wydajności

Wraz ze wzrostem liczby użytkowników rośnie rozmiar zestawów danych, do których użytkownicy uzyskują dostęp, a możliwość awarii jednego lub większej liczby składników staje się bardziej prawdopodobna. Obniżenie wydajności często występuje przed awarią składnika. Jeśli możesz wykryć spadek, możesz podjąć proaktywne kroki, aby zapobiec awarii.

Wydajność systemu zależy od wielu czynników. Zazwyczaj każdy czynnik jest mierzony za pomocą kluczowych wskaźników wydajności (KPI), takich jak liczba transakcji bazy danych na sekundę lub liczba żądań sieciowych pomyślnie obsłużonych w określonym przedziale czasu. Niektóre z tych wskaźników KPI mogą być dostępne jako konkretne miary wydajności, podczas gdy inne kluczowe wskaźniki wydajności mogą pochodzić z kombinacji metryk.

Wymagania dotyczące monitorowania wydajności

Aby ocenić wydajność systemu, zazwyczaj potrzebne są następujące informacje:

• Współczynniki odpowiedzi dla żądań użytkowników
• Liczba współbieżnych żądań użytkowników
• Liczba ruchu sieciowego
• Stawki, w których system kończy transakcje biznesowe
• Średni czas przetwarzania żądań

Użyj narzędzi, które mogą ułatwić zidentyfikowanie następujących korelacji:

• Liczba równoczesnych użytkowników w porównaniu z opóźnieniami żądań lub czas rozpoczęcia przetwarzania żądania po wysłaniu żądania przez użytkownika

• Liczba równoczesnych użytkowników w porównaniu ze średnim czasem odpowiedzi lub jak długo trwa ukończenie żądania po rozpoczęciu przetwarzania

• Liczba żądań w porównaniu z liczbą błędów przetwarzania

Wraz z tym ogólnymi informacjami funkcjonalnymi uzyskaj szczegółowy widok wydajności dla każdego składnika w systemie. Liczniki wydajności niskiego poziomu zwykle udostępniają te dane. Śledzą następujące informacje:

• Wykorzystanie pamięci
• Liczba wątków
• Czas przetwarzania procesora CPU
• Długość kolejki żądań
• Współczynniki we/wy dysku lub sieci oraz błędy
• Liczba bajtów zapisanych lub odczytanych
• Wskaźniki oprogramowania pośredniczącego, takie jak długość kolejki

Wszystkie wizualizacje powinny umożliwiać określenie okresu. Wyświetlane dane mogą być migawką bieżącej sytuacji lub historycznego widoku wydajności. System powinien zgłaszać alerty na podstawie dowolnego pomiaru wydajności dla dowolnej określonej wartości w dowolnym określonym przedziale czasu.

Zbieranie danych wydajności

Zbierz dane o wysokiej wydajności, takie jak przepływność, liczba równoczesnych użytkowników, liczba transakcji biznesowych i współczynniki błędów, monitorując postęp żądań użytkowników. Dołączanie instrukcji śledzenia i informacji o chronometrażu w kluczowych punktach w kodzie aplikacji. Przechwyć wszystkie błędy, wyjątki i ostrzeżenia z wystarczającą ilością danych i skorelować je z żądaniami, które je spowodowały.

Jeśli to możliwe, przechwyć dane wydajności dla dowolnych systemów zewnętrznych używanych przez aplikację. Te systemy zewnętrzne mogą udostępniać własne liczniki wydajności lub inne funkcje do żądania danych wydajności. Jeśli ta metoda nie jest możliwa, zarejestruj informacje, takie jak godzina rozpoczęcia i godzina zakończenia każdego żądania do systemu zewnętrznego oraz stan powodzenia, niepowodzenia lub ostrzeżenia operacji.

Dane wydajności niskiego poziomu dla poszczególnych składników systemu mogą być dostępne za pośrednictwem funkcji i usług, takich jak liczniki wydajności Windows zbierane przez agenta Azure Monitor.

Analizowanie danych wydajności

Większość analiz agreguje dane wydajności według typu żądania użytkownika lub podsystemu lub usługi, do której wysyłane jest każde żądanie. Przykładem żądania od użytkownika jest dodanie produktu do koszyka lub proces realizacji zakupu w systemie e-commerce.

Innym typowym wymaganiem jest podsumowanie danych wydajności w percentylach. Można na przykład określić czasy odpowiedzi dla 99% żądań, 95% żądań i 70% żądań. Możesz ustawić cele SLA lub inne wartości docelowe dla każdego percentyla. Zgłaszanie bieżących wyników niemal w czasie rzeczywistym w celu natychmiastowego wykrywania problemów. Agregowanie wyników w czasie w celach statystycznych.

Problemy z opóźnieniami mogą również mieć wpływ na wydajność. Aby szybko zidentyfikować przyczyny wąskich gardeł, należy ocenić opóźnienia na każdym etapie realizacji każdego żądania. Dane wydajności muszą zapewnić sposób korelowania metryk wydajności dla każdego kroku, aby skojarzyć je z określonym żądaniem.

W zależności od wymagań dotyczących wizualizacji może być przydatne generowanie i przechowywanie modułu danych zawierającego widoki danych pierwotnych. Ten moduł danych może zezwalać na złożone, nieplanowane wykonywanie zapytań i analizę informacji o wydajności.

Monitorowanie zabezpieczeń

Wszystkie systemy komercyjne zawierające poufne dane muszą implementować strukturę zabezpieczeń. Czułość danych zwykle określa, jak złożony jest mechanizm zabezpieczeń. W systemie, który wymaga uwierzytelnienia użytkowników, zapisz następujące informacje:

• Wszystkie próby logowania i czy kończą się niepowodzeniem, czy powodzeniem

• Wszystkie operacje wykonywane przez uwierzytelnionego użytkownika oraz szczegóły wszystkich zasobów, do których uzyskują dostęp

• Po zakończeniu sesji przez użytkownika i wylogowaniu się

Monitorowanie może pomóc w wykrywaniu ataków na system. Na przykład kilka nieudanych prób logowania może wskazywać na atak siłowy. Nieoczekiwany wzrost liczby żądań może być wynikiem ataku DDoS. Przygotuj się do monitorowania wszystkich żądań do wszystkich zasobów niezależnie od ich źródła. System, który ma lukę w zabezpieczeniach logowania, może przypadkowo uwidocznić zasoby bez konieczności logowania się przez użytkownika.

Wymagania dotyczące monitorowania zabezpieczeń

Dane przechwytywane przez monitorowanie zabezpieczeń mogą pomóc:

• Wykrywanie prób włamań przez nieautoryzowany podmiot.

• Identyfikowanie prób wykonania operacji na danych, do których nie mają dostępu jednostki.

• Ustal, czy nieuwierzytelniony użytkownik, czy złośliwy uwierzytelniony użytkownik próbuje zaatakować system.

Aby obsługiwać te zadania, system powinien wysyłać alerty w następujących przypadkach:

• Jedno konto wykonuje powtarzające się nieudane próby logowania w określonym przedziale czasu.

• Jedno uwierzytelnione konto wielokrotnie próbuje uzyskać dostęp do zabronionego zasobu w określonym okresie.

• W określonym okresie występuje duża liczba nieuwierzytelnionych lub nieautoryzowanych żądań.

Skonfiguruj alerty, aby uwzględnić adres hosta źródła dla każdego żądania. Jeśli naruszenia zabezpieczeń regularnie występują z określonego zakresu adresów, możesz zablokować te hosty.

Kluczową częścią utrzymania bezpieczeństwa systemu jest możliwość szybkiego wykrywania akcji, które odbiegają od zwykłego wzorca. Możesz wyświetlić informacje, takie jak liczba nieudanych lub pomyślnych żądań logowania wizualnie, aby ułatwić wykrywanie skoków aktywności w nietypowych momentach. Te informacje umożliwiają również skonfigurowanie skalowania automatycznego opartego na czasie. Jeśli na przykład widzisz, że wielu użytkowników regularnie loguje się w określonym czasie, możesz uruchomić dodatkowe usługi uwierzytelniania w celu obsługi ilości pracy. Zamknij te usługi po przejściu szczytu.

Zbieranie danych dotyczących zabezpieczeń

Zabezpieczenia to całościowy aspekt większości systemów rozproszonych, a monitorowanie generuje istotne dane w wielu punktach w całym systemie. Przyjęcie podejścia do zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM) w celu zbierania informacji, które wynikają z zdarzeń zgłaszanych przez aplikację, sprzęt sieciowy, serwery, zapory, oprogramowanie antywirusowe i inne elementy zapobiegania włamaniom.

Monitorowanie zabezpieczeń może obejmować dane z narzędzi spoza aplikacji. Te narzędzia obejmują narzędzia identyfikujące działania skanowania portów przez agencje zewnętrzne i filtry sieciowe, które wykrywają próby uzyskania nieuwierzytelnionego dostępu do aplikacji i danych. W niektórych przypadkach narzędzia ciągłej integracji i ciągłego wdrażania (CI/CD) stanowią ważną część cyklu życia aplikacji. Te narzędzia powinny również oznaczać nietypowe zachowanie.

Analizowanie danych zabezpieczeń

Kluczową funkcją monitorowania zabezpieczeń jest to, że zbiera dane z wielu źródeł. Różne formaty i poziomy szczegółów często wymagają złożonej analizy w celu skompilowania danych w spójny wątek informacji. Można wykryć nieudane logowania lub powtarzające się próby uzyskania nieautoryzowanego dostępu do zasobów, ale złożone automatyczne przetwarzanie danych zabezpieczeń może nie być możliwe. W tym scenariuszu musisz zanotować znacznik czasu danych i zapisać je w bezpiecznym repozytorium w oryginalnej formie na potrzeby ręcznej analizy ekspertów.

Monitorowanie umowy SLA

Systemy komercyjne obsługujące płacących klientów zobowiązują się do określonego poziomu wydajności systemu w formie umów SLA. Umowy SLA określają, że system może obsłużyć zdefiniowaną ilość pracy w uzgodnionym przedziale czasu i bez utraty krytycznych informacji. Monitorowanie poziomu usług zapewnia, że system spełnia mierzalne poziomy SLA.

Następujące metryki definiują umowy SLA:

• Ogólna dostępność systemu. Na przykład organizacja może zobowiązać się do zapewnienia dostępności systemu przez 99,9% czasu. Ta wartość procentowa odpowiada nie więcej niż dziewięciu godzinom przestoju rocznie lub około 10 minut tygodniowo.

• Przepływność operacyjna. Ten aspekt jest często wyrażany za pomocą jednej lub większej liczby wartości granicznych, takich jak deklaracja, że system może obsługiwać do 100 000 równoczesnych żądań użytkowników lub przetwarzać 10 000 równoczesnych transakcji biznesowych.

• Czas odpowiedzi operacyjnej. System może również wymagać przetwarzania żądań według zdefiniowanej szybkości. Na przykład 99% wszystkich transakcji biznesowych musi zakończyć się w ciągu 2 sekund, a żadna pojedyncza transakcja nie trwa dłużej niż 10 sekund.

Wymagania dotyczące monitorowania umowy SLA

Powinno być możliwe szybkie określenie, czy system spełnia umowę SLA. Jeśli nie spełnia wymogów SLA, należy ocenić czynniki leżące u podstaw problemu, aby ustalić przyczynę niezadowalającej wydajności.

Można wizualnie przedstawić następujące wskaźniki wysokiego poziomu:

• Procent czasu działania usługi

• Przepływność aplikacji mierzona pod względem pomyślnych transakcji lub operacji na sekundę

• Liczba pomyślnych lub zakończonych niepowodzeniem żądań aplikacji

• Liczba błędów aplikacji i systemu, wyjątków i ostrzeżeń

Upewnij się, że wszystkie te wskaźniki można filtrować według określonego okresu.

Aplikacja w chmurze prawdopodobnie obejmuje wiele podsystemów i składników. Powinien być w stanie wybrać wskaźnik wysokiego poziomu, taki jak ogólny czas pracy systemu, i określić, które elementy bazowe mają wpływ na jego stan kondycji.

W celach ostrzegających system powinien zgłosić zdarzenie, jeśli którykolwiek ze wskaźników wysokiego poziomu przekroczy określony próg. Udostępnij systemowi alertów szczegóły niższego poziomu jako dane kontekstowe.

Zbieranie danych umowy SLA

Wykonaj następujące czynności, aby przechwycić nieprzetworzone dane wymagane do monitorowania umowy SLA:

• Wykonaj monitorowanie punktu końcowego.
• Rejestrowanie wyjątków, błędów i ostrzeżeń.
• Śledzenie wykonywania żądań użytkowników.
• Monitoruj dostępność wszelkich usług innych niż firmy Microsoft, z których korzysta system.
• Użyj metryk wydajności i liczników.

Wszystkie dane muszą być oznaczone czasem i opatrzone znacznikiem czasu.

Analizowanie danych umowy SLA

Agregowanie danych umowy SLA w celu wygenerowania obrazu ogólnej wydajności systemu. Powinno być również możliwe przechodzenie do szczegółów zagregowanych danych w celu oceny podstawowych podsystemów. Na przykład powinno być możliwe wykonanie następujących zadań:

• Oblicz łączną liczbę żądań użytkowników w określonym przedziale czasu i określ współczynnik powodzenia i niepowodzeń tych żądań.

• Połącz czasy odpowiedzi żądań użytkowników, aby wygenerować ogólny widok czasów odpowiedzi systemu.

• Przeanalizuj postęp żądań użytkowników, aby podzielić ogólny czas odpowiedzi na czas odpowiedzi poszczególnych elementów roboczych w żądaniu.

• Określ ogólną dostępność systemu jako procent czasu pracy dla określonego okresu.

• Przeanalizuj dostępność procentowego czasu poszczególnych składników i usług w systemie. Może być konieczne analizowanie dzienników generowanych przez usługi inne niż firmy Microsoft.

Systemy komercyjne muszą zgłaszać rzeczywiste dane dotyczące wydajności względem umów SLA przez określony okres. Te informacje umożliwiają obliczanie kredytów lub innych form spłat dla klientów, jeśli nie spełniasz umów SLA w tym okresie. Dostępność usługi można obliczyć przy użyciu techniki opisanej w temacie Analizowanie danych dostępności.

W celach wewnętrznych organizacja może również śledzić liczbę i charakter zdarzeń, które powodują niepowodzenie usług. Dowiedz się, jak szybko rozwiązać te problemy lub wyeliminować je, aby ograniczyć przestoje i spełnić umowy SLA.

Auditing

W zależności od charakteru aplikacji przepisy prawne mogą określać wymagania dotyczące inspekcji operacji użytkowników i rejestrowania dostępu do wszystkich danych. Inspekcja może dostarczyć dowodów, które łączą klientów z określonymi żądaniami. Niezaprzeczalność jest ważnym czynnikiem w systemach biznesu elektronicznego, pomagając utrzymać zaufanie między klientem a organizacją odpowiedzialną za aplikację lub usługę.

Wymagania dotyczące inspekcji

Musisz mieć możliwość śledzenia sekwencji operacji biznesowych wykonywanych przez użytkowników, aby umożliwić odtworzenie akcji użytkowników. Ten rekord może być niezbędny do celów dokumentacji lub w ramach dochodzenia kryminalistycznego.

Informacje inspekcji są wysoce poufne. Prawdopodobnie obejmuje ona dane identyfikujące użytkowników systemu i zadania, które wykonują. Z tego powodu informacje o inspekcji są najprawdopodobniej dostępne tylko dla zaufanych analityków, a nie w ramach systemu interaktywnego. Analityk generuje szereg raportów, takich jak następujące przykłady:

• Raporty, które wyświetlają listę działań wszystkich użytkowników w określonym przedziale czasu

• Raporty, które szczegółowo opisują chronologię działania dla pojedynczego użytkownika

• Raporty, które wyświetlają sekwencję operacji wykonywanych względem co najmniej jednego zasobu

Zbieranie danych inspekcji

Podstawowe źródła informacji dotyczących inspekcji obejmują:

• System zabezpieczeń, który zarządza uwierzytelnianiem użytkowników.
• Śledzenie dzienników rejestrujących aktywność użytkownika.
• Dzienniki zabezpieczeń, które śledzą wszystkie możliwe do zidentyfikowania i niezidentyfikowalne żądania sieciowe.

Wymagania prawne mogą określać format danych inspekcji i sposób ich przechowywania. Jeśli przepisy wymagają zarejestrowania danych w oryginalnym formacie, może nie być możliwe wyczyszczenie danych. W związku z tym dostęp do repozytorium, w ramach którego jest przechowywany, musi być ściśle chroniony, aby zapobiec manipulowaniu.

Analizowanie danych inspekcji

Musisz mieć dostęp do danych pierwotnych w całości i w oryginalnej formie. Oprócz wymogu generowania typowych raportów inspekcji narzędzia do analizowania tych danych są prawdopodobnie wyspecjalizowane i przechowywane poza systemem.

Monitorowanie użycia

Monitorowanie użycia śledzi sposób używania funkcji i składników aplikacji przez klientów. Możesz użyć tych danych do:

• Zidentyfikuj popularne funkcje i potencjalne hotspoty w systemie. Elementy o dużym natężeniu ruchu mogą korzystać z partycjonowania funkcjonalnego lub replikacji w celu równomiernego rozłożenia obciążenia. Możesz również użyć tych informacji, aby określić, które funkcje są rzadko używane i są możliwymi kandydatami do wycofania lub zastąpienia w przyszłej wersji systemu.

• Uzyskaj informacje o zdarzeniach operacyjnych systemu w normalnym użyciu. Na przykład w witrynie handlu elektronicznego można rejestrować informacje statystyczne dotyczące liczby transakcji i liczby klientów odpowiedzialnych za nie. Te informacje można używać do planowania pojemności w miarę wzrostu liczby klientów.

• Wykrywanie zadowolenia użytkowników z wydajności i funkcjonalności systemu. Jeśli na przykład wielu klientów w systemie handlu elektronicznego regularnie porzuca koszyki, może wystąpić problem z funkcjonalnością zakupu.

• Generowanie informacji rozliczeniowych. Aplikacja komercyjna lub wielodostępna usługa może pobierać opłaty za używane zasoby.

• Wymuszanie przydziałów. Jeśli użytkownik w systemie wielodostępowym przekroczy swój opłacony limit czasu przetwarzania lub użycia zasobów w określonym okresie, możesz ograniczyć jego dostęp lub spowolnić przetwarzanie.

• Wykrywanie hałaśliwych problemów z sąsiadami. Aby ułatwić badanie błędów lub decyzje dotyczące produktów, określ, czy ruch jest równomiernie rozłożony, czy też mały zestaw użytkowników generuje większość ruchu. Jeśli jeden użytkownik generuje znaczący ruch, funkcja może wymagać dostrajania wydajności. Alternatywnie możesz zdecydować się na nałożenie dodatkowych limitów przydziału w celu zmniejszenia ruchu.

Wymagania dotyczące monitorowania użycia

Aby ocenić użycie systemu, zazwyczaj potrzebne są następujące informacje:

• Liczba żądań, które każdy podsystem przetwarza i kieruje do każdego zasobu

• Praca wykonywana przez każdego użytkownika

• Ilość miejsca do magazynowania danych zajmowanego przez każdego użytkownika

• Zasoby, do których uzyskuje dostęp każdy użytkownik

Powinno być również możliwe generowanie grafów. Typowe przykłady obejmują grafy użytkowników korzystających z większości zasobów i najczęściej używanych zasobów lub funkcji systemowych.

Zbieranie danych użycia

Śledzenie użycia wysokiego poziomu można wykonać, zauważając czas rozpoczęcia i zakończenia każdego żądania oraz charakter każdego żądania, na przykład odczyt lub zapis. Aby przechwycić te informacje, wykonaj następujące zadania:

• Śledzenie aktywności użytkownika.
• Zbieraj liczniki wydajności mierzące wykorzystanie każdego zasobu.
• Monitoruj użycie zasobów każdego użytkownika.

W celach pomiarowych należy również zidentyfikować użytkowników, którzy wykonują operacje i zasoby, z których korzystają te operacje. Upewnij się, że zebrane informacje są wystarczająco szczegółowe, aby obsługiwać dokładne rozliczenia.

Śledzenie problemów

Klienci i inni użytkownicy mogą zgłaszać problemy, jeśli w systemie wystąpią nieoczekiwane zdarzenia lub zachowanie. Śledzenie problemów zarządza tymi problemami, kojarzy problemy z wysiłkami, aby je rozwiązać, i informuje klientów o rozwiązaniach.

Wymagania dotyczące śledzenia problemów

Aby śledzić problemy, użyj oddzielnego systemu, który umożliwia rejestrowanie i zgłaszanie szczegółów problemów zgłaszanych przez użytkowników. Te szczegóły obejmują zadania, objawy problemu, sekwencję zdarzeń oraz komunikaty o błędach lub ostrzeżeniach.

Zbieranie danych śledzenia problemów

Początkowe źródło danych do śledzenia problemów to użytkownik, który zgłasza problem. Ten użytkownik może podać następujące informacje:

• Zrzut awaryjny, jeśli aplikacja zawiera składnik uruchamiany na pulpicie użytkownika

• Migawka ekranu

• Data i godzina wystąpienia błędu oraz inne informacje o środowisku, takie jak lokalizacja użytkownika

Te informacje ułatwiają debugowanie systemu i konstruowanie listy prac dla przyszłych wydań oprogramowania.

Analizowanie danych śledzenia problemów

Różni użytkownicy mogą zgłaszać ten sam problem, a system śledzenia problemów powinien kojarzyć typowe raporty.

Zarejestruj postęp wysiłku debugowania dla każdego raportu. Po rozwiązaniu problemu poinformuj klienta o rozwiązaniu.

Jeśli użytkownik zgłosi problem, który ma znane rozwiązanie w systemie śledzenia problemów, możesz natychmiast poinformować użytkownika o rozwiązaniu.

Śledzenie operacji i debugowanie wydań oprogramowania

Gdy użytkownik zgłasza problem, zazwyczaj zdaje sobie sprawę tylko z natychmiastowego wpływu na jego operacje. Użytkownik może zgłaszać wyłącznie wyniki na podstawie własnych doświadczeń. Te doświadczenia są zwykle widocznym objawem jednego lub kilku podstawowych problemów. W wielu przypadkach analityk musi przeanalizować chronologię podstawowych operacji, aby ustalić główną przyczynę problemu. Ten proces jest nazywany analizą głównej przyczyny (RCA).

Wymagania dotyczące śledzenia i debugowania

Aby śledzić nieoczekiwane zdarzenia i inne problemy, dane monitorowania muszą dostarczyć wystarczające informacje, aby umożliwić analitykowi znalezienie źródła problemu i odtworzenie sekwencji zdarzeń. Następnie deweloper może wprowadzić modyfikacje, aby zapobiec ponownemu wystąpieniu problemu.

Zbieranie danych śledzenia i debugowania

Aby rozwiązać problemy, prześledzić wszystkie metody i ich parametry wywoływane w ramach operacji. Następnie utwórz drzewo, które przedstawia logiczny przepływ przez system, gdy klient wysyła określone żądanie. Przechwytuj i rejestruj wyjątki i ostrzeżenia generowane przez system w wyniku działania tego przepływu.

Aby obsługiwać debugowanie, system udostępnia punkty zaczepienia, których można użyć do przechwytywania informacji o stanie w kluczowych punktach systemu. System może również dostarczać szczegółowe informacje krok po kroku w miarę postępu wybranych operacji. Przechwytywanie danych na tym poziomie szczegółowości może zwiększyć obciążenie systemu i powinno być procesem tymczasowym. Użyj tego procesu, gdy wystąpią nietypowe i trudne do zreplikowania zdarzenia lub gdy nowa wersja wymaga dokładnego monitorowania, aby upewnić się, że elementy działają zgodnie z oczekiwaniami.

Potok monitorowania i diagnostyki

Monitorowanie systemów rozproszonych dużej skali stanowi znaczące wyzwanie. Nie należy koniecznie rozpatrywać każdego ze scenariuszy opisanych w poprzednich sekcjach w oderwaniu od siebie. Dane monitorowania i diagnostyki wymagane dla każdej sytuacji nakładają się, ale może być konieczne przetworzenie i przedstawienie tych danych na różne sposoby. Z tych powodów skorzystaj z całościowego wglądu w monitorowanie i diagnostykę.

Możesz sobie wyobrazić cały proces monitorowania i diagnostyki jako potok, który składa się z etapów przedstawionych na poniższym diagramie.

Na diagramie pokazano, jak dane monitorowania i diagnostyki pochodzą z różnych źródeł. Etapy instrumentacji i zbierania ułatwiają identyfikowanie danych, które należy przechwycić, gdzie i jak je przechwycić oraz jak sformatować dane, aby można było je łatwo analizować. Etap analizy i diagnostyki pobiera nieprzetworzone dane i używa ich do generowania znaczących informacji, których można użyć do określenia stanu systemu. Możesz użyć tych informacji, aby określić, jakie działania można podjąć, a następnie przekazać wyniki z powrotem do etapów instrumentacji i zbierania danych. Etap wizualizacji i alertów przedstawia eksploatacyjny widok stanu systemu. Może wyświetlać informacje niemal w czasie rzeczywistym przy użyciu serii pulpitów nawigacyjnych. Umożliwia ona generowanie raportów, grafów i wykresów w celu zapewnienia historycznego widoku danych, które mogą pomóc w identyfikowaniu długoterminowych trendów. Jeśli informacje wskazują, że wskaźnik KPI prawdopodobnie przekroczy dopuszczalne granice, ten etap może również wyzwolić alert. W niektórych przypadkach alert może również wyzwolić zautomatyzowany proces, który próbuje podjąć akcje naprawcze, takie jak skalowanie automatyczne.

Te kroki tworzą proces ciągłego przepływu, w którym etapy są uruchamiane równolegle. Najlepiej, aby wszystkie fazy można było konfigurować dynamicznie. W niektórych momentach, zwłaszcza gdy system jest nowo wdrożony lub występuje problemy, może być konieczne częstsze zbieranie rozszerzonych danych. W innych przypadkach można nadal przechwytywać ogólne, niezbędne informacje, aby sprawdzić, czy system działa prawidłowo.

Traktuj cały proces monitorowania jako aktywne, bieżące rozwiązanie, które wymaga precyzyjnego dostrajania i ulepszeń na podstawie opinii. Na przykład możesz zacząć od zmierzenia wielu czynników w celu określenia kondycji systemu i uściślania analizy w czasie, aby odrzucić miary, które nie są istotne.

Źródła danych monitorowania i diagnostyki

Informacje używane przez proces monitorowania mogą pochodzić z kilku źródeł. Na poziomie aplikacji informacje pochodzą z dzienników śledzenia, które są dołączane do kodu systemu. Deweloperzy powinni postępować zgodnie ze standardowym podejściem do śledzenia przepływu kontroli za pośrednictwem kodu. Na przykład wpis do metody może emitować komunikat śledzenia, który określa nazwę metody, bieżącą godzinę, wartość każdego parametru i inne istotne informacje. Możesz również zarejestrować czas wejścia i wyjścia.

Rejestruj wszystkie wyjątki i ostrzeżenia oraz upewnij się, że zachowasz pełny ślad wszystkich zagnieżdżonych wyjątków i ostrzeżeń. Zbierz informacje identyfikujące użytkownika uruchamiającego kod oraz informacje o korelacji działań, aby śledzić żądania, gdy przechodzą przez system. Rejestruj próby dostępu do wszystkich zasobów, takich jak kolejki komunikatów, bazy danych, pliki i inne usługi zależne. Te informacje umożliwiają pomiary i inspekcję.

Wiele aplikacji używa bibliotek i struktur do wykonywania typowych zadań, takich jak uzyskiwanie dostępu do magazynu danych lub komunikacja za pośrednictwem sieci. Możesz skonfigurować te struktury, aby dostarczać własne komunikaty śledzenia i nieprzetworzone informacje diagnostyczne, takie jak współczynniki transakcji i powodzenia transmisji danych i niepowodzenia.

System operacyjny, na którym działa aplikacja, może być źródłem informacji dotyczących całego systemu, takich jak liczniki wydajności wskazujące współczynniki we/wy, wykorzystanie pamięci i użycie procesora CPU. Może również zgłaszać błędy systemu operacyjnego, takie jak niepowodzenie poprawnego otwarcia pliku.

Należy również wziąć pod uwagę podstawową infrastrukturę i składniki, na których działa system. Maszyny wirtualne, sieci wirtualne i usługi magazynu mogą być źródłami ważnych liczników wydajności na poziomie infrastruktury i innych danych diagnostycznych.

Jeśli aplikacja korzysta z innych usług zewnętrznych, takich jak serwer internetowy lub system zarządzania bazami danych (DBMS), te usługi mogą publikować własne informacje o śledzeniu, dziennikach i licznikach wydajności. Na przykład dynamiczne widoki zarządzania (DMV) w SQL Server śledzą operacje wykonywane względem bazy danych SQL Server. Usługa Application Insights śledzi dzienniki rejestrowania żądań wysyłanych do Azure App Service.

Podczas modyfikowania składników systemu i wdrażania nowych wersji ważne jest, aby przypisywać problemy, zdarzenia i metryki do każdej wersji. Powiąż te informacje z potokiem wydania, aby można było szybko śledzić i rozwiązywać problemy z określoną wersją składnika.

Użyj następujących strategii, aby zebrać dane monitorowania i diagnostyki:

• Monitorowanie aplikacji i systemu korzysta ze źródeł wewnętrznych w aplikacji, strukturach aplikacji, systemie operacyjnym i infrastrukturze. Kod aplikacji może wygenerować własne dane monitorowania w godnych uwagi punktach w cyklu życia żądania klienta. Aplikacja może zawierać instrukcje śledzenia, które można w razie potrzeby włączać i wyłączać. Diagnostykę można również dynamicznie wprowadzać przy użyciu platformy diagnostycznej. Te platformy programistyczne zwykle udostępniają wtyczki, które podłączają się do różnych punktów instrumentacyjnych w kodzie i przechwytują w tych miejscach dane śladowe.

  Twój kod lub bazowa infrastruktura mogą również zgłaszać zdarzenia w krytycznych punktach. Agenci monitorowania skonfigurowani do nasłuchiwania tych zdarzeń mogą rejestrować informacje o zdarzeniu.

• Monitorowanie rzeczywistego użytkownika rejestruje interakcje między użytkownikiem a aplikacją i obserwuje przepływ każdego żądania i odpowiedzi. Te informacje służą do pomiaru użycia przez każdego użytkownika i określania, czy użytkownicy otrzymują odpowiednie QoS, w tym szybkie czasy odpowiedzi, małe opóźnienia i minimalne błędy. Możesz użyć tych danych, aby zidentyfikować obszary, w których najczęściej występują błędy. Możesz również użyć danych, aby zidentyfikować obszary, w których system spowalnia z powodu hotspotów w aplikacji lub innych wąskich gardeł. W przypadku dokładnego zaimplementowania tego podejścia możesz odtworzyć przepływy użytkowników za pośrednictwem aplikacji na potrzeby debugowania i testowania.

  Important

  Traktuj dane przechwycone przez monitorowanie rzeczywistego użytkownika jako wysoce poufne, ponieważ mogą zawierać poufne materiały. Jeśli zapiszesz przechwycone dane, zapisz je bezpiecznie. Jeśli chcesz używać danych do celów monitorowania wydajności lub debugowania, najpierw usuń wszystkie dane osobowe.

• Syntetyczne monitorowanie użytkowników wymaga napisania własnego klienta testowego, który symuluje użytkownika i wykonuje konfigurowalną, ale typową serię operacji. Możesz śledzić wydajność klienta testowego, aby ułatwić określenie stanu systemu. Można również użyć wielu wystąpień klienta testowego w ramach operacji testowania obciążenia, aby ustalić, jak system reaguje pod obciążeniem i dane wyjściowe monitorowania generowane przez te warunki.

  Note

  Można zaimplementować monitorowanie rzeczywistych i syntetycznych użytkowników, włączając kod, który śledzi i mierzy czas wykonywania wywołań metod oraz innych krytycznych części aplikacji.

• Profilowanie pomaga monitorować i poprawiać wydajność aplikacji. W przeciwieństwie do monitorowania rzeczywistego użytkownika i syntetycznego monitorowania użytkowników, które działają na poziomie funkcjonalności, profilowanie przechwytuje informacje niższego poziomu podczas uruchamiania aplikacji. Zaimplementuj profilowanie, okresowo próbkując stan wykonywania aplikacji lub określając, który fragment kodu aplikacja działa w określonym czasie. Można również użyć instrumentacji, która wstawia sondy do kodu w ważnych momentach, takich jak początek i koniec wywołania metody. Sondy rejestrują, które metody zostały wywołane przez dane wywołanie, o której godzinie to nastąpiło i jak długo trwa każde wywołanie. Następnie możesz przeanalizować te dane, aby określić, które części aplikacji mogą powodować problemy z wydajnością.

• Monitorowanie punktu końcowego używa co najmniej jednego punktu końcowego diagnostycznego, które aplikacja uwidacznia specjalnie w celu włączenia monitorowania. Punkt końcowy udostępnia ścieżkę do kodu aplikacji i może zwracać informacje o kondycji systemu. Różne punkty końcowe mogą skupić się na różnych aspektach funkcjonalności. Możesz napisać własnego klienta diagnostycznego, który wysyła okresowe żądania do tych punktów końcowych i asymiluje odpowiedzi. Aby uzyskać więcej informacji, zobacz Wzorzec monitorowania punktu końcowego kondycji.

• Zrzuty awaryjne inicjowane przez użytkownika opierają się na tym, że aplikacja udostępnia mechanizm umożliwiający zebranie zrzutu stanu aplikacji, jeśli nie jest w stanie odzyskać sprawności. Użytkownicy muszą również dobrowolnie udostępniać tę migawkę. Nie można zagwarantować, że zrzut awaryjny zostanie utworzony, ale można użyć dostarczanych przez niego danych niskiego poziomu do określenia pierwotnej przyczyny błędów. Ten scenariusz jest typowy, jeśli błędy występują rzadko lub występują tylko błędy w rzadko używanej funkcji aplikacji.

W celu uzyskania maksymalnego pokrycia należy użyć kombinacji tych technik.

Instrumentacja aplikacji

Instrumentacja jest krytyczną częścią procesu monitorowania. Musisz przechwycić dane, które ułatwiają podejmowanie znaczących decyzji dotyczących wydajności i kondycji systemu. Instrumentacja służy do zbierania wystarczających informacji w celu oceny wydajności, diagnozowania problemów i podejmowania decyzji bez konieczności logowania się do zdalnego serwera produkcyjnego w celu ręcznego śledzenia i debugowania. Dane instrumentacji zwykle obejmują metryki i informacje zapisywane w dziennikach śledzenia.

Dziennik śledzenia może zawierać dane tekstowe, które aplikacja zapisuje lub dane binarne tworzone przez zdarzenie śledzenia, jeśli aplikacja używa śledzenia zdarzeń dla Windows (ETW). Dzienniki systemowe rejestrujące zdarzenia pochodzące z elementów infrastruktury, takich jak serwer WWW, mogą również generować wpisy dziennika śledzenia. Komunikaty dziennika tekstowego są często czytelne dla człowieka, ale zapisują je w formacie, który zautomatyzowany system może również łatwo analizować.

Ponadto kategoryzuj dzienniki. Nie zapisuj wszystkich danych śledzenia w jednym dzienniku. Użyj oddzielnych dzienników, aby rejestrować dane śledzenia z różnych obszarów działania systemu. Następnie można szybko filtrować komunikaty dziennika, odczytując z odpowiedniego dziennika zamiast przetwarzać pojedynczy długi plik. Nigdy nie zapisuj informacji, które mają inne wymagania dotyczące zabezpieczeń, takie jak informacje inspekcji i dane debugowania, do tego samego dziennika.

Metryki są zazwyczaj miarą lub zliczeniem określonego aspektu albo zasobu w systemie w danym momencie, z co najmniej jedną powiązaną etykietą lub wymiarem, nazywanym również próbką. Pojedyncze wystąpienie metryki nie jest przydatne w izolacji. Zamiast tego zbieraj metryki w czasie. Zastanów się, które metryki mają być rejestrowane i jak często. Generowanie danych dla metryk zbyt często może generować zbyt duże obciążenie systemu. Jednak nie przechwycenie wystarczającej ilości danych może spowodować pominięcie okoliczności, które prowadzą do znaczącego zdarzenia. Rozważania różnią się w zależności od metryki. Na przykład użycie procesora na serwerze może wahać się od sekundy do sekundy, ale wysokie wykorzystanie staje się problemem tylko wtedy, gdy utrzymuje się przez kilka minut.

Informacje dotyczące korelowania danych

Można łatwo monitorować poszczególne liczniki wydajności na poziomie systemu, przechwytywać metryki zasobów i uzyskiwać informacje o śledzonej aplikacji z różnych plików dziennika. Jednak niektóre formy monitorowania wymagają etapu analizy i diagnostyki w potoku monitorowania, aby skorelować dane pobrane z kilku źródeł. Te surowe dane mogą przyjmować różne formy, a proces analizy musi dysponować wystarczającymi danymi pomiarowymi, aby odwzorować te różne formy. Na przykład na poziomie platformy aplikacji identyfikator wątku może identyfikować zadanie. W aplikacji ta sama praca może być skojarzona z identyfikatorem użytkownika dla użytkownika, który wykonuje to zadanie.

Mapowanie jeden do jednego prawdopodobnie nie istnieje między wątkami a żądaniami użytkownika, ponieważ operacje asynchroniczne mogą ponownie używać tych samych wątków do wykonywania operacji dla więcej niż jednego użytkownika. Więcej niż jeden wątek może również obsługiwać pojedyncze żądanie, w miarę jak wykonanie przechodzi przez system. Jeśli to możliwe, skojarz każde żądanie z unikatowym identyfikatorem działania propagowanym przez system w ramach kontekstu żądania. Technika generowania i dołączania identyfikatorów działań w informacjach śledzących zależy od technologii używanej do przechwytywania danych śledzących.

Opatruj wszystkie dane monitorujące znacznikami czasu w ten sam sposób. Aby uzyskać spójność, zarejestruj wszystkie daty i godziny przy użyciu czasu UTC. Ta metoda ułatwia śledzenie sekwencji zdarzeń.

Informacje do uwzględnienia w danych instrumentacji

Podczas decydowania, które dane instrumentacji mają być zbierane, należy wziąć pod uwagę następujące kwestie:

• Upewnij się, że informacje przechwycone przez zdarzenia śledzenia są czytelne dla maszyn i czytelne dla człowieka. Przyjęcie dobrze zdefiniowanych schematów dla tych informacji w celu ułatwienia zautomatyzowanego przetwarzania danych dzienników w systemach i zapewnienia spójności dla pracowników operacyjnych i inżynieryjnych, którzy odczytują dzienniki. Uwzględnij informacje o środowisku, takie jak środowisko wdrażania, komputer, na którym jest uruchamiany proces, szczegóły procesu i stos wywołań.

• Włącz profilowanie tylko wtedy, gdy jest to konieczne, ponieważ może zwiększyć znaczne obciążenie systemu. Profilowanie przy użyciu instrumentacji rejestruje zdarzenie, takie jak wywołanie metody, za każdym razem, gdy występuje, podczas gdy próbkowanie rejestruje tylko wybrane zdarzenia. Wybór może być oparty na czasie, raz na n sekund lub na podstawie częstotliwości, raz na n żądań. Jeśli zdarzenia występują często, profilowanie według instrumentacji może spowodować zbyt duże obciążenie i wpłynąć na ogólną wydajność. W takim przypadku preferowane jest podejście do próbkowania. Jeśli jednak częstotliwość zdarzeń jest niska, próbkowanie może ich przegapić. W takim przypadku instrumentacja może być lepszym podejściem.

• Podaj wystarczający kontekst, aby deweloper lub administrator mógł określić źródło każdego żądania. Ten kontekst może zawierać identyfikator działania, który identyfikuje określone wystąpienie żądania lub informacje, które korelują działanie z wykonaną pracą obliczeniową i używanymi zasobami. Ta praca może przekraczać granice procesów i maszyn. W przypadku pomiaru kontekst powinien również zawierać bezpośrednio lub pośrednio za pośrednictwem innych skorelowanych informacji odwołanie do klienta, który zgłasza żądanie. Ten kontekst zawiera cenne informacje o stanie aplikacji podczas przechwytywania danych monitorowania.

• Rejestruj wszystkie żądania oraz lokalizacje lub regiony, z których są wysyłane te żądania. Te informacje mogą pomóc w ustaleniu, czy istnieją jakiekolwiek hotspoty specyficzne dla lokalizacji. Może również pomóc określić, czy należy ponownie podzielić na partycje aplikację czy dane, z których korzysta.

• Rejestruj i przechwyć szczegółowe informacje o wyjątkach dokładnie. Często krytyczne informacje debugowania są tracone w wyniku złej obsługi wyjątków. Przechwyć pełne szczegóły wyjątków zgłaszanych przez aplikację, w tym wszelkie wyjątki wewnętrzne i inne informacje kontekstowe. Dołącz stos wywołań, jeśli to jest możliwe.

• Zachowaj spójność danych przechwyconych przez różne elementy aplikacji. Spójność może pomóc w analizie zdarzeń i skorelować je z żądaniami użytkowników. Rozważ użycie kompleksowego i konfigurowalnego pakietu rejestrowania w celu zebrania informacji, zamiast polegać na deweloperach, aby przyjęli jednolite podejście podczas implementacji różnych części systemu. Zbierz dane z kluczowych liczników wydajności, takich jak wolumin we/wy, wykorzystanie sieci, liczba żądań, użycie pamięci i wykorzystanie procesora CPU. Niektóre usługi infrastruktury mogą udostępniać własne liczniki wydajności, takie jak liczba połączeń z bazą danych, szybkość wykonywania transakcji przez system oraz liczba transakcji zakończonych powodzeniem lub niepowodzeniem. Aplikacje mogą również definiować własne liczniki wydajności.

• Rejestruje wszystkie wywołania wykonywane do usług zewnętrznych, takich jak systemy baz danych, usługi internetowe lub inne usługi na poziomie systemu, które są częścią infrastruktury. Zarejestruj informacje o czasie potrzebnym do wykonania każdego wywołania oraz o tym, czy wywołanie zakończy się powodzeniem, czy niepowodzeniem. Jeśli to możliwe, przechwyć informacje o wszystkich ponownych próbach i niepowodzeniach dla wszelkich przejściowych błędów, które występują.

Zapewnianie zgodności z systemami telemetrii

W wielu przypadkach informacje generowane przez instrumentację są generowane jako seria zdarzeń i przekazywane do oddzielnego systemu telemetrii na potrzeby przetwarzania i analizy. System telemetrii jest zwykle niezależny od określonych aplikacji lub technologii, ale oczekuje, że informacje będą zgodne z określonym formatem zdefiniowanym przez schemat. Schemat określa kontrakt, który definiuje pola danych i typy, które system telemetrii może pozyskiwać. Uogólnij schemat, aby umożliwić korzystanie z danych z różnych platform i urządzeń. Jednym z przykładów powszechnie używanej platformy i schematu jest OpenTelemetry.

Wspólny schemat powinien zawierać pola wspólne dla wszystkich zdarzeń instrumentacji, takie jak nazwa zdarzenia, czas zdarzenia, adres IP nadawcy. Powinna również zawierać szczegółowe informacje wymagane do korelowania z innymi zdarzeniami, takimi jak identyfikator użytkownika, identyfikator urządzenia i identyfikator aplikacji. Należy pamiętać, że dowolna liczba urządzeń może zgłaszać zdarzenia, więc schemat nie powinien zależeć od typu urządzenia. Ponadto różne urządzenia mogą zgłaszać zdarzenia dla tej samej aplikacji, a aplikacja może obsługiwać roaming lub inną formę dystrybucji między urządzeniami.

Schemat może również zawierać pola domeny, które są istotne dla konkretnego scenariusza, który jest wspólny dla różnych aplikacji. Te scenariusze obejmują informacje o wyjątkach, zdarzeniach uruchamiania i kończenia aplikacji oraz powodzeniu lub niepowodzeniu wywołań interfejsu API usługi internetowej. Wszystkie aplikacje korzystające z tego samego zestawu pól domeny powinny emitować ten sam zestaw zdarzeń, aby utworzyć zestaw typowych raportów i analiz.

Na koniec schemat może zawierać pola niestandardowe służące do przechwytywania szczegółów zdarzeń specyficznych dla aplikacji.

Najlepsze rozwiązania dotyczące instrumentowania aplikacji

Poniższa lista zawiera podsumowanie najlepszych rozwiązań dotyczących instrumentowania aplikacji rozproszonej działającej w chmurze:

• Ułatwiaj odczytywanie i analizowanie dzienników. Używaj rejestrowania strukturalnego, jeśli jest to możliwe. Bądź zwięzły i opisowy w komunikatach dziennika.

• We wszystkich dziennikach zidentyfikuj źródło i podaj informacje o kontekście i czasie w momencie zapisywania każdego rekordu dziennika.

• Użyj tej samej strefy czasowej i formatu dla wszystkich sygnatur czasowych. Ta praktyka pomaga skorelować zdarzenia dla operacji obejmujących sprzęt i usługi działające w różnych regionach geograficznych.

• Kategoryzuj dzienniki i zapisuj komunikaty do odpowiedniego pliku dziennika.

• Nie ujawniaj poufnych informacji o systemie ani danych osobowych o użytkownikach. Wyczyść te informacje przed zalogowaniem, ale upewnij się, że zachowasz odpowiednie szczegóły. Na przykład usuń identyfikator i hasło z parametrów połączenia bazy danych. Zapisz pozostałe informacje w dzienniku, aby określić, czy system uzyskuje dostęp do właściwej bazy danych. Rejestruj wszystkie wyjątki krytyczne, ale zezwalaj administratorowi na włączanie i wyłączanie rejestrowania dla niższych poziomów wyjątków i ostrzeżeń. Ponadto przechwyć i zarejestruj wszystkie informacje logiki ponawiania. Te dane umożliwiają monitorowanie przejściowej kondycji systemu.

• Śledzenie wywołań poza procesem, takich jak żądania do zewnętrznych usług internetowych lub baz danych.

• Nie mieszaj komunikatów dziennika z różnymi wymaganiami dotyczącymi zabezpieczeń w tym samym pliku dziennika. Na przykład nie zapisuj informacji dotyczących debugowania i inspekcji w tym samym dzienniku.

• Zainicjuj wywołania logowania, które nadal działają autonomicznie. Tego typu operacje nie blokują postępu operacji biznesowych. Zdarzenia inspekcji są wyjątkiem, ponieważ mają krytyczne znaczenie dla firmy. Klasyfikuj je jako podstawową część operacji biznesowych.

• Upewnij się, że rejestrowanie jest rozszerzalne i nie ma żadnych bezpośrednich zależności od konkretnego celu. Na przykład zamiast pisać informacje przy użyciu elementu System.Diagnostics.Trace, zdefiniuj abstrakcyjny interfejs, taki jak ILogger, który uwidacznia metody rejestrowania i który można zaimplementować za pomocą dowolnego odpowiedniego środka.

• Upewnij się, że mechanizm rejestrowania jest odporny na awarie i nigdy nie powoduje błędów kaskadowych. Rejestrowanie nie może zgłaszać żadnych wyjątków.

• Traktuj instrumentację jako ciągły proces iteracyjny i regularnie przeglądaj dzienniki, nie tylko wtedy, gdy wystąpi problem.

Zbieranie i przechowywanie danych

Etap zbierania pobiera informacje generowane przez instrumentację, formatuje te dane, aby ułatwić korzystanie z nich podczas etapu analizy i diagnostyki oraz zapisuje przekształcone dane w niezawodnym magazynie. Dane instrumentacji można przechowywać z różnych części systemu rozproszonego w różnych lokalizacjach i formatach. Na przykład kod aplikacji może generować pliki dziennika śledzenia i dane dziennika zdarzeń aplikacji. Inne technologie mogą przechwytywać liczniki wydajności, które monitorują kluczowe aspekty infrastruktury używanej przez aplikację. Wszelkie składniki i usługi spoza firmy Microsoft, z których korzysta aplikacja, mogą dostarczać informacje instrumentacyjne w różnych formatach, na przykład za pomocą oddzielnych plików śledzenia, magazynu Blob, a nawet niestandardowego magazynu danych.

Usługa zbierania, która działa autonomicznie z poziomu aplikacji, która generuje dane instrumentacji, zwykle zbiera dane. Na poniższym diagramie przedstawiono przykład tej architektury i wyróżniono podsystem zbierania danych instrumentacji.

Ten diagram przedstawia uproszczony widok zbierania danych. Usługa gromadzenia zwykle składa się z wielu części działających na różnych maszynach. Jeśli chcesz szybko analizować dane telemetryczne, użyj składników lokalnych działających poza usługą zbierania. Po zakończeniu przetwarzania analitycznego składniki wysyłają wyniki bezpośrednio do podsystemu wizualizacji i alertów. Dane podlegające analizie ciepłej lub zimnej są przechowywane w magazynie podczas oczekiwania na przetwarzanie. Aby uzyskać więcej informacji, zobacz Obsługa analizy gorącej, ciepłej i zimnej.

W przypadku Azure aplikacji i usług uruchamianych na maszynach wirtualnych agent Azure Monitor udostępnia rozwiązanie do przechwytywania danych. Definiujesz reguły zbierania danych (DCR), które określają, jakie dane zbierać z każdego węzła obliczeniowego i do którego obszaru roboczego Log Analytics w usłudze Azure Monitor je wysyłać. Agent może zbierać dane z następujących źródeł:

• Dzienniki usług Internet Information Services (IIS)
• Dzienniki zdarzeń systemu Windows
• Liczniki wydajności
• Dziennik systemu z węzłów systemu Linux
• Dzienniki tekstowe i JSON zapisywane przez aplikacje

Strategie zbierania danych instrumentacyjnych

Ze względu na elastyczny charakter chmury oraz aby uniknąć ręcznego pobierania danych telemetrycznych z każdego węzła w systemie, należy zadbać o ich konsolidację i przesyłanie do centralnej lokalizacji. W systemie obejmującym wiele centrów danych można najpierw zbierać, konsolidować i przechowywać dane w poszczególnych regionach, a następnie agregować dane regionalne w jednym systemie centralnym.

Aby zoptymalizować użycie przepustowości, można przesyłać mniej pilne dane jako partie. Nie opóźnij transferu na czas nieokreślony, zwłaszcza jeśli dane zawierają informacje wrażliwe na czas.

Ściąganie i wypychanie danych instrumentacji

Podsystem zbierania danych instrumentacji może aktywnie pobierać dane instrumentacji z różnych dzienników i innych źródeł dla każdego wystąpienia aplikacji. Ta metoda jest nazywana modelem ściągania. Może też działać jako pasywny odbiornik, który czeka na składniki, które składają się na każde wystąpienie aplikacji w celu wysłania danych. Ta metoda jest nazywana modelem wypychania.

Jednym z podejść do modelu pull jest użycie agentów monitorujących, które działają lokalnie przy każdej instancji aplikacji. Agent monitorujący to oddzielny proces, który okresowo pobiera dane telemetryczne zebrane na węźle lokalnym i zapisuje te informacje w scentralizowanej pamięci masowej współużytkowanej przez wszystkie wystąpienia aplikacji. Agent Azure Monitor implementuje ten mechanizm. Konfigurujesz dane zbierane z każdej instancji obliczeniowej za pomocą reguły zbierania danych. Agent monitorowania, który działa obok każdego wystąpienia, zbiera określone dane, takie jak dzienniki usług IIS, dzienniki zdarzeń Windows i liczniki wydajności oraz wysyła je do obszaru roboczego Log Analytics w Azure Monitor, w którym można wykonywać zapytania i analizować je. Na poniższym diagramie przedstawiono przykład tej architektury.

Modele ściągania i wypychania umożliwiają przechowywanie danych telemetrycznych dla aplikacji o małej skali działającej w ograniczonej liczbie węzłów w jednej lokalizacji. Złożona, wysoce skalowalna, globalna aplikacja w chmurze może generować ogromne ilości danych z setek wystąpień obliczeniowych, fragmentów baz danych i innych usług. Ta powódź danych może łatwo przytłoczyć przepustowość we/wy dostępną w jednej lokalizacji centralnej. W związku z tym musisz być w stanie skalować swoje rozwiązanie telemetryczne, aby zapobiec powstaniu wąskiego gardła wraz z rozwojem 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.

Aby rozwiązać te problemy, zaimplementuj kolejkowanie. W poniższej przykładowej architekturze lokalny agent monitorowania lub niestandardowa usługa gromadzenia danych wysyła dane do kolejki. Usługa zapisu do pamięci masowej, oddzielny proces asynchroniczny, pobiera dane z tej kolejki i zapisuje je we współdzielonej pamięci masowej. Kolejka komunikatów jest odpowiednia w tym scenariuszu, ponieważ zapewnia semantykę co najmniej raz, która pomaga zagwarantować, że dane umieszczone w kolejce nie zostaną utracone po ich opublikowaniu. Usługę zapisu do magazynu można zaimplementować za pomocą oddzielnego procesu działającego w tle.

Lokalna usługa gromadzenia danych może dodawać dane do kolejki natychmiast po ich otrzymaniu. Kolejka pełni funkcję bufora, a usługa zapisująca dane do pamięci masowej może pobierać i zapisywać dane we własnym tempie. Domyślnie kolejka działa na zasadzie first-in, first-out. Można jednak określić priorytety komunikatów w celu przyspieszenia ich przez kolejkę, jeśli zawierają one dane, które należy szybko obsłużyć. Aby uzyskać więcej informacji, zobacz Wzorzec kolejki priorytetu. Alternatywnie można użyć różnych kanałów, takich jak tematy usługi Service Bus, aby kierować dane do różnych miejsc docelowych w zależności od wymaganej formy przetwarzania analitycznego.

Aby zapewnić skalowalność, można uruchomić wiele wystąpień usługi zapisu do magazynu danych. W przypadku dużych ilości zdarzeń można użyć centrum zdarzeń do wysyłania danych do różnych zasobów obliczeniowych na potrzeby przetwarzania i magazynowania.

Konsolidacja danych instrumentacji

Dane instrumentacji pobierane przez usługę zbierania danych z jednego wystąpienia aplikacji zapewniają zlokalizowany widok kondycji i wydajności tego wystąpienia. Aby ocenić ogólną kondycję systemu, skonsoliduj aspekty danych w widokach lokalnych. Ten krok można wykonać po przechowywaniu danych, ale w niektórych przypadkach można to zrobić również podczas zbierania danych. Zamiast być zapisywane bezpośrednio do współdzielonej pamięci masowej, dane instrumentacji przechodzą przez oddzielną usługę, która konsoliduje, filtruje i oczyszcza dane. Na przykład dane instrumentacji zawierające te same informacje korelacji, takie jak identyfikator działania, można połączyć. Użytkownik może rozpocząć operację biznesową w jednym węźle, a następnie zostać przeniesiony do innego węzła, jeśli ten węzeł ulegnie awarii lub z powodu równoważenia obciążenia. Ten proces może również wykrywać i usuwać zduplikowane dane; jest to możliwe, jeśli usługa telemetrii używa kolejek komunikatów do przesyłania danych z instrumentacji do magazynu danych. Na poniższym diagramie przedstawiono przykład tej struktury.

Przechowywanie danych instrumentacji

W poprzednich sekcjach przedstawiono uproszczony widok przechowywania danych instrumentacji. W praktyce należy przechowywać różne typy informacji przy użyciu technologii, które odpowiadają sposobom ich używania.

Na przykład Azure Blob Storage i Azure Table Storage mają podobne wzorce dostępu, ale operacje, które mogą wykonywać, są ograniczone, a stopień szczegółowości przechowywanych danych różni się. Jeśli musisz wykonywać operacje analityczne lub wymagać funkcji wyszukiwania pełnotekstowego, może być konieczne użycie magazynu danych, który zapewnia następujące możliwości zapytań i dostępu do danych:

• Przechowuj dane licznika wydajności w bazie danych SQL, aby umożliwić analizy ad hoc.
• Przechowywanie dzienników śledzenia w Azure Cosmos DB.
• Zapisz informacje o zabezpieczeniach w rozproszonym systemie plików Hadoop (HDFS).
• Przechowuj informacje wymagające wyszukiwania pełnotekstowego przy użyciu usługi Elasticsearch, która przyspiesza wyszukiwanie przy użyciu indeksowania zaawansowanego.

Na poniższym diagramie pokazano, jak można zaimplementować dodatkową usługę, która okresowo pobiera dane z udostępnionego magazynu, partycjonuje i filtruje dane zgodnie z jego celem, a następnie zapisuje je w odpowiednim zestawie magazynów danych. Alternatywnym podejściem jest uwzględnienie tej funkcjonalności w procesie konsolidacji i oczyszczania oraz zapisywanie danych bezpośrednio do tych repozytoriów podczas ich pobierania, zamiast zapisywania ich w pośrednim współdzielonym obszarze pamięci masowej. Każde podejście ma zalety i wady. Implementowanie oddzielnej usługi partycjonowania zmniejsza obciążenie usługi konsolidacji i oczyszczania. Pozwala również w razie potrzeby ponownie wygenerować przynajmniej część danych podzielonych na partycje, w zależności od tego, ile danych jest przechowywanych w magazynie współdzielonym. Jednak takie podejście zużywa więcej zasobów. Może to również opóźnić odbiór danych telemetrycznych z każdej instancji aplikacji oraz przekształcanie tych danych w praktyczne informacje.

Mogą być potrzebne te same dane instrumentacji w więcej niż jednym celu. Na przykład liczniki wydajności mogą zapewnić historyczny widok wydajności systemu w czasie. Te informacje można połączyć z innymi danymi użycia, aby wygenerować informacje o rozliczeniach klientów. W tych scenariuszach wyślij te same dane do więcej niż jednego miejsca docelowego, na przykład do bazy danych dokumentów, która przechowuje informacje o rozliczeniach i wielowymiarowy magazyn obsługujący złożoną analizę wydajności.

Zastanów się, jak pilnie potrzebujesz danych. Dane dostarczające informacji na potrzeby alertowania muszą być szybko dostępne, dlatego należy przechowywać je w szybkim systemie magazynowania danych oraz odpowiednio je indeksować lub strukturyzować, aby zoptymalizować zapytania systemu alertowania. W niektórych przypadkach usługa telemetrii, która zbiera dane na każdym węźle, może wymagać sformatowania i zapisania danych lokalnie, aby lokalna instancja systemu alertowania mogła szybko powiadomić Cię o problemach. Możesz wysłać te same dane do usługi zapisującej dane w magazynie, pokazanej na poprzednich diagramach, i przechowywać je centralnie, jeśli potrzebujesz ich do innych celów.

Informacje, których używasz do bardziej złożonej analizy, raportowania i identyfikowania trendów historycznych, są mniej pilne. Przechowuj je w sposób, który obsługuje wyszukiwania danych i nieplanowane zapytania. Aby uzyskać więcej informacji, zobacz Obsługa analizy gorącej, ciepłej i zimnej.

Rotacja dzienników i przechowywanie danych

Instrumentacja generuje dużo danych. W niektórych przypadkach po przetworzeniu i przesłaniu danych można usunąć oryginalne nieprzetworzone dane źródłowe z każdego węzła. Może być też konieczne zapisanie nieprzetworzonych informacji.

Dane wydajności zwykle mają dłuższy okres życia, dzięki czemu można ich używać do identyfikowania trendów wydajności i planowania pojemności. Zachowaj skonsolidowany widok tych danych w trybie online przez ograniczony okres, aby można było szybko uzyskać do niego dostęp. Może być konieczne zapisanie danych zebranych na potrzeby pomiaru i rozliczeń na czas nieokreślony. Ponadto wymagania prawne mogą wymagać archiwizacji i zapisania informacji zebranych na potrzeby inspekcji i zabezpieczeń. Zaszyfruj lub w inny sposób chroń te poufne dane, aby zapobiec manipulacji. Nigdy nie rejestruj haseł użytkowników ani innych danych osobowych. Usuń te informacje z danych przed ich zapisaniem.

Zmniejszenie częstotliwości próbkowania

Przechowywanie danych historycznych w celu wykrycia długoterminowych trendów. Zamiast zapisywać wszystkie stare dane, możesz próbkować dane rzadziej, aby zmniejszyć ich rozdzielczość i obniżyć koszty przechowywania. 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.

Najlepsze praktyki dotyczące zbierania i przechowywania informacji logowania

Poniższa lista zawiera podsumowanie najlepszych rozwiązań dotyczących przechwytywania i przechowywania informacji rejestrowania:

• Agent monitorowania lub usługa zbierania danych powinna działać jako usługa poza procesem i być prosta do wdrożenia.

• Wszystkie dane wyjściowe z agenta monitorowania lub usługi zbierania danych powinny mieć format, który jest niezależny od komputera, systemu operacyjnego czy protokołu sieciowego. Na przykład emituj informacje w formacie samoopisującym, takim jak JSON, MessagePack lub Protobuf, a nie pliki dziennika śledzenia zdarzeń (ETL) w systemie Linux lub ETW. Użyj standardowego formatu, aby system mógł tworzyć potoki przetwarzania. Możesz łatwo zintegrować składniki, które odczytują, przekształcają i wysyłają dane w uzgodnionym formacie.

• Proces monitorowania i zbierania danych musi być bezpieczny i nie może wyzwalać błędów kaskadowych.

• Jeśli błąd przejściowy wysyła informacje do ujścia danych, agent monitorowania lub usługa zbierania danych powinna być przygotowana do zmiany kolejności danych telemetrycznych, tak aby najnowsze informacje zostały wysłane jako pierwsze. Agent monitorowania lub usługa zbierania danych może zdecydować się na usunięcie starszych danych lub zapisanie ich lokalnie i przesłanie ich później w celu nadrobienia zaległości według własnego uznania.

Analizowanie danych i diagnozowanie problemów

Ważną częścią monitorowania i diagnostyki jest analizowanie zebranych danych w celu uzyskania obrazu ogólnej kondycji systemu. Zdefiniuj własne wskaźniki KPI i metryki wydajności oraz dowiedz się, jak utworzyć strukturę danych w celu spełnienia wymagań analizy. Dowiedz się, jak dane przechwycone w różnych metrykach i plikach dziennika są skorelowane, ponieważ te informacje są kluczem do śledzenia sekwencji zdarzeń i diagnozowania problemów.

Dane dla każdej części systemu są zwykle przechwytywane lokalnie, ale następnie należy połączyć je z danymi wygenerowanymi w innych lokacjach uczestniczących w systemie. Dokładnie skoreluj te informacje, aby upewnić się, że dane są dokładnie połączone. Na przykład dane użycia operacji mogą obejmować następujące węzły:

• Węzeł hostujący witrynę internetową, z którą użytkownik nawiązuje połączenie
• Węzeł, który uruchamia oddzielną usługę dostępną w ramach tej operacji
• Węzeł przechowujący magazyn danych

Te informacje należy powiązać razem, aby zapewnić ogólny widok użycia zasobów i przetwarzania dla operacji. Węzeł, który przechwytuje dane, może wstępnie przetworzyć i filtrować je, ale węzły centralne zazwyczaj agregują i formatują dane. Aby uzyskać więcej informacji, zobacz Konsolidowanie danych instrumentacji.

Obsługa gorącej, ciepłej i zimnej analizy

Analizowanie i ponowne formatowanie danych na potrzeby wizualizacji, raportowania i zgłaszania alertów może być złożonym procesem, który zużywa własny zestaw zasobów. Niektóre formy monitorowania wymagają natychmiastowej analizy danych, aby było skuteczne, nazywane również analizą gorącą. Przykłady obejmują analizę alertów i monitorowania zabezpieczeń. Na potrzeby analiz w czasie rzeczywistym udostępnij dane i uporządkuj je do wydajnego przetwarzania. W niektórych przypadkach może być konieczne przeniesienie przetwarzania analizy do poszczególnych węzłów, które przechowują dane.

Inne formy analizy są mniej wrażliwe na czas i mogą wymagać obliczeń i agregacji po odebraniu danych pierwotnych. Ta metoda jest nazywana analizą ciepłą. Analiza wydajności często należy do tej kategorii. W takim przypadku nagły skok lub chwilowe zakłócenie mogą spowodować odosobniony, pojedynczy incydent związany z wydajnością, który nie jest statystycznie istotny. Dane z serii zdarzeń zapewniają bardziej niezawodny obraz wydajności systemu.

Możesz również wykorzystać analizę termiczną do diagnozowania problemów zdrowotnych. Użyj analizy w czasie rzeczywistym, aby przetworzyć zdarzenie dotyczące kondycji systemu i natychmiast wygenerować alert. Następnie użyj analizy w trybie warm do przeanalizowania danych i znalezienia przyczyny zdarzenia dotyczącego kondycji systemu.

Niektóre typy monitorowania generują więcej danych długoterminowych. Tę analizę można wykonać w późniejszym terminie, prawdopodobnie zgodnie ze wstępnie zdefiniowanym harmonogramem. W niektórych przypadkach analiza może wymagać filtrowania dużych ilości danych przechwyconych w czasie. Ta metoda jest nazywana analizą zimną. Kluczowym wymaganiem jest bezpieczne przechowywanie danych po ich przechwyceniu. Na przykład monitorowanie użycia i inspekcja wymagają dokładnego obrazu stanu systemu w regularnych odstępach czasu, ale te informacje o stanie nie muszą być natychmiast dostępne do przetwarzania.

Możesz również użyć analizy zimnej, aby udostępnić dane na potrzeby analizy kondycji predykcyjnej. Zbierz informacje historyczne w określonym przedziale czasu i połącz je z bieżącymi danymi kondycji, aby zobaczyć trendy, które mogą powodować problemy z kondycją. W takich przypadkach może być konieczne wywołanie alertu w celu skorygowania trendu.

Skorelowanie danych

Dane zebrane przez instrumentację mogą zapewnić migawkę stanu systemu, ale celem analizy jest uczynienie tych danych użytecznymi. Na przykład można określić przyczynę intensywnego ładowania we/wy na poziomie systemu w określonym czasie i upewnić się, że czasy odpowiedzi bazy danych, liczba transakcji na sekundę i czasy odpowiedzi aplikacji w tym samym momencie potwierdzają wyniki.

Jednym ze sposobów zmniejszenia obciążenia jest podzielenie danych na więcej serwerów. Wyjątki mogą wystąpić z powodu błędu na dowolnym poziomie systemu. Wyjątek na jednym poziomie często wyzwala kolejny błąd na poziomie powyżej.

Z tych powodów należy skorelować różne typy danych monitorowania na każdym poziomie, aby utworzyć ogólny widok stanu systemu i aplikacji uruchomionych na nim. Użyj tych informacji, aby zdecydować, czy system działa akceptowalnie i określić, co można zrobić, aby poprawić jakość.

Upewnij się, że nieprzetworzone dane instrumentacji zawierają wystarczające informacje o kontekście i identyfikatorze działania, aby obsługiwać wymagane agregacje na potrzeby korelowania zdarzeń. Te dane mogą być przechowywane w różnych formatach, więc może być konieczne przeanalizowanie i przekonwertowanie ich na standardowy format analizy. Aby uzyskać więcej informacji, zobacz Informacje dotyczące korelowania danych.

Rozwiązywanie i diagnozowanie problemów

Aby zdiagnozować problemy, należy przeprowadzić RCA, aby ustalić przyczynę usterek lub nieoczekiwanego działania. Zazwyczaj potrzebne są następujące informacje dla całego systemu lub określonego podsystemu w określonym przedziale czasu:

• Szczegółowe informacje pochodzące z dzienników zdarzeń i śladów śledzenia
• Pełne stosy wywołań dla wyjątków i awarii na dowolnym określonym poziomie
• Zrzuty awaryjne dla wszystkich procesów zakończonych niepowodzeniem
• Dzienniki aktywności rejestrujące operacje wykonywane przez wszystkich użytkowników lub wybranych użytkowników

Aby analizować dane na potrzeby rozwiązywania problemów, potrzebujesz głębokiego zrozumienia technicznego architektury systemu i jej składników. Musisz interpretować dane, ustanowić przyczynę problemów i zalecić strategię ich skorygowania. Inną strategią jest przechowywanie kopii tych informacji w oryginalnym formacie i udostępnienie ich do analizy zimnej przez eksperta.

Wizualizowanie danych i zgłaszanie alertów

Systemy monitorowania muszą przedstawiać dane, aby można było szybko identyfikować trendy lub problemy. Muszą również natychmiast powiadamiać o wystąpieniu zdarzenia wymagającego uwagi.

Prezentacja danych może mieć kilka formularzy, w tym wizualizacje przy użyciu pulpitów nawigacyjnych, alertów i raportowania.

Wizualizacja przy użyciu pulpitów nawigacyjnych

Najczęstszym sposobem wizualizacji danych jest użycie pulpitów nawigacyjnych, które wyświetlają informacje jako serię wykresów, grafów lub innych ilustracji. Można sparametryzować te elementy i wybrać ważne parametry, takie jak okres, dla określonej sytuacji.

Pulpity nawigacyjne można organizować hierarchicznie. Pulpity nawigacyjne najwyższego poziomu zapewniają ogólny widok każdego aspektu systemu i umożliwiają przechodzenie do szczegółów. Na przykład na panelu przedstawiającym ogólną aktywność we/wy dysków w systemie można wyświetlić wskaźniki we/wy dla każdego dysku, aby określić, czy jedno lub więcej konkretnych urządzeń odpowiada za nieproporcjonalnie duży wolumen ruchu. Pulpit nawigacyjny powinien również wyświetlać powiązane informacje, takie jak użytkownik lub działanie, które generuje te we/wy. Te informacje mogą pomóc w równomiernym rozłożeniu obciążenia między urządzeniami.

Pulpit nawigacyjny może również używać kodowania kolorami lub innych wskazówek wizualnych, aby wskazać wartości, które wydają się nietypowe lub które znajdują się poza oczekiwanym zakresem. Rozważmy następujące przykłady kodowania kolorów:

• Czerwony dla dysku z szybkością we/wy zbliżającą się do maksymalnej pojemności w dłuższym okresie lub dysku gorącego

• Żółty oznacza dysk, którego współczynnik operacji we/wy okresowo osiąga maksymalny limit przez krótkie okresy, lub ciepły dysk

• Zielony dla dysku, który wykazuje normalne użycie

Systemy pulpitów nawigacyjnych muszą mieć nieprzetworzone dane, aby efektywnie działać. Jeśli tworzysz własny system pulpitu nawigacyjnego lub używasz pulpitu nawigacyjnego opracowanego przez inną organizację, musisz zrozumieć, które dane instrumentacji należy zbierać, na jakich poziomach szczegółowości i jak go sformatować, aby pulpit nawigacyjny był używany.

Skuteczny pulpit nawigacyjny umożliwia również zadawanie pytań dotyczących informacji. Niektóre systemy udostępniają narzędzia do zarządzania, których można użyć do wykonywania tych zadań i eksplorowania danych bazowych. W zależności od repozytorium, które zawiera informacje, może być możliwe bezpośrednie wykonywanie zapytań o dane lub importowanie ich do narzędzi, takich jak Excel w celu dalszej analizy i raportowania.

Generowanie alertów

Alertowanie analizuje dane monitorowania i telemetrii oraz generuje powiadomienie, jeśli wykryje istotne zdarzenie.

Alerty pomagają zapewnić, że system pozostanie w dobrej kondycji, responsywny i bezpieczny. Jest to ważna część każdego systemu, która gwarantuje użytkownikom wydajność, dostępność i prywatność. Alerting może również powiadamiać Cię o zdarzeniach, które wywołują alerty. Używanie alertów do wywoływania funkcji systemowych, takich jak skalowanie automatyczne.

Alerty zależą od następujących danych instrumentacji:

• Zdarzenia zabezpieczeń: Jeśli dzienniki zdarzeń wskazują, że wystąpią powtarzające się błędy uwierzytelniania lub autoryzacji. W tym scenariuszu alert powinien informować o tym, że system może zostać zaatakowany.

• Metryki wydajności: System musi szybko reagować, jeśli metryka wydajności przekroczy określony próg.

• Informacje o dostępności: W przypadku wykrycia błędu może być konieczne szybkie ponowne uruchomienie co najmniej jednego podsystemu lub przełączenie w tryb failover do zasobu kopii zapasowej. Powtarzające się błędy w podsystemie mogą wskazywać na poważniejsze problemy.

Informacje o alertach można odbierać za pośrednictwem wielu kanałów, takich jak poczta e-mail, pager lub wiadomość SMS. Alert może również zawierać wskazanie, jak krytyczna jest sytuacja. Wiele systemów alertów obsługuje grupy subskrybentów, a wszyscy operatorzy, którzy są członkami tej samej grupy, otrzymują ten sam zestaw alertów.

Wprowadź możliwość dostosowywania systemu alertów i podaj odpowiednie wartości z podstawowych danych instrumentacji jako parametrów. Korzystając z tego podejścia, można filtrować dane pod kątem określonych progów lub kombinacji wartości. W niektórych przypadkach można podać nieprzetworzone dane instrumentacji do systemu alertów. Może też być bardziej odpowiednie dostarczenie zagregowanych danych. Na przykład alert jest wyzwalany, gdy użycie procesora CPU dla węzła przekracza 90% w ciągu ostatnich 10 minut. Dostarcz systemowi alertów odpowiednie podsumowanie i informacje kontekstowe, aby zmniejszyć prawdopodobieństwo wywołania alertu przez zdarzenia fałszywie dodatnie.

Raportowanie

Użyj raportowania, aby wygenerować ogólny widok systemu. Może zawierać dane historyczne i bieżące informacje. Wymagania dotyczące raportowania należą do kategorii operacyjnych i zabezpieczeń.

Raportowanie operacyjne zwykle obejmuje następujące aspekty ogólnego systemu lub określonych podsystemów w określonym przedziale czasu:

• Zagregowane statystyki, których można użyć do zrozumienia wykorzystania zasobów

• Trendy dotyczące użycia zasobów

• Monitorowanie wyjątków

• Wydajność aplikacji pod względem wdrożonych zasobów i tego, czy można zmniejszyć ilość zasobów bez wpływu na wydajność

Raportowanie zabezpieczeń śledzi sposób korzystania z systemu przez klientów. Zwykle obejmuje następujące aspekty:

• Przeprowadź inspekcję operacji użytkownika. Rejestruj poszczególne żądania wykonywane przez każdego użytkownika wraz z datami i godzinami. Skonstruuj dane tak, aby można było szybko odtworzyć sekwencję operacji wykonywanych przez użytkownika w określonym przedziale czasu.

• Śledzenie użycia zasobów dla każdego użytkownika. Rejestruj, jak każde żądanie użytkownika uzyskuje dostęp do zasobów systemowych i jak długo. Użyj tych danych, aby wygenerować raport użycia dla każdego użytkownika w określonym przedziale czasu, prawdopodobnie na potrzeby rozliczeń.

W wielu przypadkach procesy wsadowe mogą generować raporty zgodnie ze zdefiniowanym harmonogramem. Generowanie raportów zwykle nie zwiększa opóźnienia, więc w razie potrzeby można generować raporty na żądanie. Jeśli 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.

Następne kroki

• Omówienie usługi Azure Monitor
• Monitorowanie, diagnozowanie i rozwiązywanie problemów z pamięcią masową
• Przegląd alertów w Azure
• Omówienie usługi Application Insights
• Diagnostyka wydajności dla maszyn wirtualnych Azure

Powiązane zasoby

• Wskazówki dotyczące skalowania automatycznego wyjaśniają sposób wybierania sygnałów skalowania, konfigurowania granic pojemności oraz projektowania bezpiecznego zachowania skalowania w poziomie i skalowania w dół.

• Wzorzec monitorowania punktów końcowych kondycji opisuje sposób implementowania testów funkcjonalnych w aplikacji, dostępnych dla narzędzi zewnętrznych poprzez udostępnione punkty końcowe w regularnych odstępach czasu.

• Wzorzec kolejki priorytetu opisuje sposób określania priorytetów komunikatów w kolejce, tak aby systemy odbierały i przetwarzały pilne żądania przed mniej pilnych komunikatów.