Wskazówki dotyczące monitorowania i diagnostyki

Aplikacje rozproszone i usługi działające w chmurze to z natury złożone oprogramowanie składające się z wielu ruchomych części. W środowisku produkcyjnym ważne jest, aby móc śledzić sposób, w jaki użytkownicy korzystają z systemu, śledzenia wykorzystania zasobów i ogólnie monitorować kondycję i wydajność systemu. Możesz użyć tych informacji jako pomocy diagnostycznej do wykrywania i korygowania problemów, jak również jako pomocy do wykrywania potencjalnych problemów i zapobiegania ich występowaniu.

Scenariusze monitorowania i diagnostyki

Monitorowania możesz użyć do uzyskania szczegółowych informacji o tym, jak dobrze działa system. Monitorowanie jest kluczowym elementem utrzymania docelowej jakości usług. Typowe scenariusze dotyczące zbierania danych monitorowania obejmują:

• Zapewnienie pozostawania systemu w dobrej kondycji.
• Śledzenie dostępności systemu i jego elementów składowych.
• Utrzymanie wydajności w celu zapewnienia przepływności systemu nie zmniejszającej się nieoczekiwanie w miarę zwiększania woluminu pracy.
• Zagwarantowanie realizowania przez system wszelkich umów dotyczących poziomu usług (SLA) zawartych z klientami.
• Ochronę prywatności i bezpieczeństwa systemu, użytkowników i ich danych.
• Śledzenie operacji wykonywanych na potrzeby inspekcji lub przepisów prawa.
• Monitorowanie codziennego użycia systemu i określanie trendów, które mogą prowadzić do problemów, jeśli nie zostaną rozwiązane.
• Śledzenie występujących problemów od początkowego raportu do analizy możliwych przyczyn, naprawy, kolejnych aktualizacji oprogramowania i wdrożenia.
• Śledzenie operacji i debugowanie wersji oprogramowania.

Scenariusze te zostały bardziej szczegółowo opisane w poniższych sekcjach. Informacje dotyczące poszczególnych scenariuszy są omawiane w następującym formacie:

1. Krótkie omówienie scenariusza.
2. Typowe wymagania tego scenariusza.
3. Nieprzetworzone dane instrumentacji wymagane do obsługi scenariusza i możliwe źródła tych informacji.
4. Sposób analizowania i łączenia tych danych pierwotnych w celu wygenerowania znaczących informacji diagnostycznych.

Monitorowanie kondycji

System jest w dobrej kondycji, jeśli jest uruchomiony i może przetwarzać żądania. Celem monitorowania kondycji jest wygenerowanie migawki bieżącej kondycji systemu, aby sprawdzić, czy wszystkie składniki systemu działają zgodnie z oczekiwaniami.

Wymagania dotyczące monitorowania kondycji

Operator powinien otrzymywać alerty szybko (w ciągu kilku sekund), jeśli dowolna część systemu jest uważana za będącą w złej kondycji. Operator powinien mieć możliwość ustalenia, które części systemu działają normalnie, a w których częściach występują problemy. Kondycja systemu może zostać wyróżniona za pomocą systemu sygnalizacji świetlnej:

• Czerwony dla złej kondycji (system się zatrzymał)
• Żółty dla częściowo dobrej kondycji (system działa z ograniczoną funkcjonalnością)
• Zielony dla całkowicie dobrej kondycji

Kompleksowe monitorowanie kondycji systemu umożliwia operatorowi przejście do szczegółów systemu, aby wyświetlić stan kondycji podsystemów i składników. Jeśli na przykład cały system jest przedstawiony jako częściowo w dobrej kondycji, operator powinien móc przejść do jego szczegółów i określić, które funkcje są obecnie niedostępne.

Wymagania dotyczące źródeł danych, instrumentacji i gromadzenia danych

Dane pierwotne, które są wymagane do obsługi monitorowania kondycji, mogą być generowane w wyniku:

• Śledzenia wykonywania żądań użytkownika. Te informacje mogą służyć do określenia żądań, które zakończyły się pomyślnie, które się nie powiodły i jak długo trwa każde żądanie.
• Syntetyczne monitorowanie użytkownika. Ten proces symuluje czynności wykonywane przez użytkownika i wykonuje szereg wstępnie zdefiniowanych kroków. Wynik każdego kroku powinien zostać przechwycony.
• Rejestrowania wyjątków, błędów i ostrzeżeń. Te informacje można przechwycić jako wynik instrukcji śledzenia osadzonych w kodzie aplikacji oraz pobierania informacji z dzienników zdarzeń wszelkich usług, do których odwołuje się system.
• Monitorowania kondycji dowolnych usług innych firm używanych przez system. To monitorowanie może wymagać pobierania i analizowania danych kondycji dostarczanych przez te usługi. Te informacje mogą mieć wiele formatów.
• Monitorowanie punktu końcowego. Ten mechanizm jest opisany bardziej szczegółowo w sekcji „Monitorowanie dostępności”.
• Zbieranie informacji o wydajności otoczenia, takich jak użycie procesora CPU w tle lub operacje wejścia/wyjścia (a w tym w sieci).

Analizowanie danych kondycji

Podstawowym celem monitorowania kondycji jest szybkie wskazywanie, czy system działa. Analiza na gorąco natychmiastowych danych może wyzwalać alert, jeśli zostanie wykryte, że krytyczny składnik jest w złej kondycji. (Nie można na przykład odpowiedzieć na kolejną serię poleceń ping). Operator może następnie podjąć odpowiednie działania naprawcze.

Bardziej zaawansowany system może zawierać element predykcyjny, który wykonuje analizę na zimno dla ostatnich i bieżących obciążeń. Analiza na zimno może wykryć trendy i ustalić, czy system prawdopodobnie pozostanie w dobrej kondycji, czy też będzie potrzebował dodatkowych zasobów. Ten element predykcyjny powinien być oparty na krytycznych metrykach wydajności, takich jak:

• Częstotliwość żądań skierowanych do każdej usługi lub podsystemu.
• Czas odpowiedzi na te żądania.
• Ilość danych przepływających do i z każdej usługi.

Jeśli wartość którejkolwiek metryki przekracza określoną wartość progową, system może zgłosić alert, aby umożliwić operatorowi lub funkcji skalowania automatycznego (jeśli jest dostępna) podjęcie działań zapobiegawczych niezbędnych do utrzymania kondycji systemu. Te akcje mogą obejmować dodawanie zasobów, ponowne uruchamianie co najmniej jednej usługi zakończonej niepowodzeniem lub zastosowanie ograniczania żądań o niższym priorytecie.

Monitorowanie dostępności

System w naprawdę dobrej kondycji wymaga, aby były dostępne składniki i podsystemy, które go tworzą. Monitorowanie dostępności jest ściśle powiązane z monitorowaniem kondycji. Jednak, podczas gdy monitorowanie kondycji zapewnia natychmiastowy widok bieżącej kondycji systemu, monitorowanie dostępności dotyczy śledzenia dostępności systemu i jego składników, aby wygenerować statystyki dotyczące czasu działania systemu.

W wielu systemach niektóre składniki (takie jak bazy danych) są skonfigurowane z wbudowaną nadmiarowością pozwalającą na szybkie przełączanie w tryb failover w przypadku poważnej awarii lub utraty łączności. Najlepiej, aby użytkownicy nie zdawali sobie sprawy, że wystąpiła taka awaria. Ale z punktu widzenia monitorowania dostępności konieczne jest zebranie jak największej ilości informacji na temat takich awarii, aby ustalić przyczynę i przeprowadzić akcje naprawcze w celu uniknięcia ich powtórnego wystąpienia.

Dane wymagane do śledzenia dostępności mogą zależeć od wielu czynników niższego poziomu. Wiele z tych czynników może być specyficznych dla aplikacji, systemu i środowiska. Skuteczny system monitorowania przechwytuje dane o dostępności, które odpowiadają tym czynnikom niskiego poziomu, a następnie agreguje je, aby stworzyć ogólny obraz systemu. Na przykład w systemie handlu elektronicznego funkcje biznesowe, które umożliwiają klientowi składanie zamówień, mogą zależeć od repozytorium, w którym są przechowywane szczegóły zamówienia, i systemu płatności, który obsługuje transakcje pieniężne dla płatności za te zamówienia. Dostępność części systemu do składania zamówień jest więc funkcją dostępności repozytorium i podsystemu płatności.

Wymagania dotyczące monitorowania dostępności

Operator powinien również mieć możliwość wyświetlania historycznej dostępności każdego systemu oraz podsystemu, a także używania tych informacji do określania dowolnych trendów, które mogą powodować, że co najmniej jeden podsystem okresowo ulega awarii. (Czy usługi zaczynają kończyć się niepowodzeniem o określonej porze dnia odpowiadającej godzinom szczytu przetwarzania?)

Rozwiązanie do monitorowania powinno zapewniać natychmiastowy i historyczny widok dostępności lub niedostępności każdego podsystemu. Powinno ono również mieć możliwość szybkiego zgłaszania alertów operatorowi, gdy co najmniej jedna usługa ulegnie awarii lub użytkownicy nie mogą nawiązać połączenia z usługami. To jest kwestią nie tylko monitorowania poszczególnych usług, ale również badania akcji wykonywanych przez każdego użytkownika, jeśli te akcje kończą się niepowodzeniem podczas próby nawiązania połączenia z usługą. Do pewnego stopnia niektóre awarie łączności są normalne i mogą być powodowane błędami przejściowymi. Może jednak być przydatne zezwolenie na to, aby system zgłaszał alert w przypadku pewnej liczby błędów łączności w określonym podsystemie występujących w określonym czasie.

Wymagania dotyczące źródeł danych, instrumentacji i gromadzenia danych

Podobnie jak w przypadku monitorowania kondycji, dane pierwotne wymagane do obsługi monitorowania dostępności można wygenerować w wyniku syntetycznego monitorowania użytkownika i rejestrowania wszelkich wyjątków, błędów i ostrzeżeń, które mogą wystąpić. Ponadto dane dotyczące dostępności można uzyskać, prowadząc monitorowanie punktu końcowego. Aplikacja może uwidocznić przynajmniej jeden punkt końcowy kondycji, który testuje dostęp do obszarów funkcjonalnych w systemie. System monitorowania może wysyłać polecenia ping do każdego punktu końcowego, wykonując zdefiniowany harmonogram i zbierając wyniki (powodzenie lub niepowodzenie).

Wszystkie przekroczenia limitu czasu, awarie połączenia sieciowego i ponowne próby połączenia muszą być rejestrowane. Wszystkie dane powinny być znacznikami czasu.

Analizowanie danych dotyczących dostępności

Dane instrumentacji muszą zostać zagregowane i skorelowane w celu obsługi następujących typów analizy:

• Natychmiastowa dostępność systemu i podsystemów.
• Częstotliwość awarii dostępności systemu i podsystemów. W idealnym przypadku operator powinien mieć możliwość skorelowania błędów z określonymi działaniami: co się wydarzyło, kiedy system uległ awarii?
• Widok historycznych danych dotyczących częstotliwości awarii systemu lub dowolnego podsystemu w dowolnym określonym okresie i obciążenia systemu (na przykład liczba żądań użytkowników), gdy wystąpiła awaria.
• Przyczyny niedostępności systemu lub dowolnego podsystemu. Na przykład przyczyną może być niedziałająca usługa, utrata łączności, połączenie, ale z przekroczeniem limitu czasu, oraz połączenie, ale zwracające błędy.

Procent dostępności usługi w określonym czasie można obliczyć przy użyciu następującej formuły:

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

Jest to przydatne do celów realizacji umowy dotyczącej poziomu usług. (Monitorowanie umowy SLA zostało szczegółowo opisane w dalszej części tego przewodnika). Definicja przestoju zależy od usługi. Na przykład usługa kompilacji usług Visual Studio Team Services określa przestój jako okres (łączną liczbę minut), w którym usługa kompilacji jest niedostępna. Dana minuta jest uznawana za niedostępną, jeśli wszystkie ciągłe żądania HTTP do usługi kompilacji dotyczące wykonania operacji zainicjowanych przez klienta w ciągu tej minuty kończą się kodem błędu lub nie zwracają odpowiedzi.

Monitorowanie wydajności

Ponieważ system znajduje się pod coraz większym obciążeniem (przez zwiększanie liczby użytkowników), rozmiar zestawów danych, do których ci użytkownicy mają dostęp, zwiększa się i możliwość awarii przynajmniej jednego składnika staje się bardziej prawdopodobna. Awarie składnika często są poprzedzone spadkiem wydajności. Jeśli jesteś w stanie wykryć taki spadek, możesz podjąć aktywne kroki, aby rozwiązać ten problem.

Wydajność systemu zależy od wielu czynników. Każdy czynnik zwykle mierzy się za pomocą kluczowych wskaźników wydajności (KPI), takich jak liczba transakcji bazy danych na sekundę lub liczba żądań sieciowych, które zostały pomyślnie obsłużone w określonym horyzoncie czasowym. Niektóre z tych wskaźników KPI mogą być dostępne jako określone miary wydajności, podczas gdy inne mogą pochodzić z kombinacji metryk.

Wymagania dotyczące monitorowania wydajności

Aby zbadać wydajność systemu, operator zazwyczaj potrzebuje informacji, które obejmują:

• Współczynnik odpowiedzi na żądania użytkowników.
• Liczbę równoczesnych żądań użytkowników.
• Wielkość ruchu sieciowego.
• Współczynnik kończenia transakcji biznesowych.
• Średni czas przetwarzania żądań.

Przydatne może być również zapewnienie narzędzi, które umożliwiają operatorowi łatwiejsze wykrywanie korelacji, takich jak:

• Liczba równoczesnych użytkowników w porównaniu z czasami opóźnienia żądania (ile trwa rozpoczęcie przetwarzania żądania po wysłaniu go przez użytkownika).
• Liczba równoczesnych użytkowników w porównaniu ze średnim czasem odpowiedzi (ile trwa ukończenie żądania po rozpoczęciu przetwarzania).
• Liczba żądań w porównaniu z liczbą błędów przetwarzania.

Wraz z tymi informacjami funkcjonalnymi wysokiego poziomu operator powinien móc uzyskać szczegółowy widok wydajności dla każdego składnika systemu. Te dane są zwykle zapewniane za pomocą liczników wydajności niskiego poziomu, które śledzą takie informacje, jak:

• Użycie pamięci.
• Liczba wątków.
• Czas przetwarzania procesora CPU.
• Długość kolejki żądań.
• Szybkość operacji We/Wy dysku lub sieci i błędy.
• Liczba bajtów zapisanych lub odczytanych.
• Wskaźniki oprogramowania pośredniczącego, takie jak długość kolejki.

Wszystkie wizualizacje powinny pozwalać operatorowi na określenie okresu. Wyświetlane dane mogą być migawką bieżącej sytuacji lub historycznego widoku wydajności.

Operator powinien mieć możliwość zgłoszenia alertu na podstawie dowolnej miary wydajności dla dowolnie określonej wartości w dowolnie określonym przedziale czasu.

Wymagania dotyczące źródeł danych, instrumentacji i gromadzenia danych

Dane dotyczące wydajności wysokiego poziomu (przepływności, liczby równoczesnych użytkowników, liczby transakcji biznesowych, częstotliwości błędów itd.) możesz gromadzić, monitorując postęp żądań użytkowników w miarę, jak są one odbierane i przechodzą przez system. Obejmuje to włączenie instrukcji śledzenia w kluczowych punktach kodu aplikacji wraz z informacjami synchronizacji. Wszystkie błędy, wyjątki i ostrzeżenia powinny zostać przechwycone z wystarczającą ilością danych do ich korelacji z żądaniami, które je spowodowały. Dziennik usług Internet Information Services (IIS) jest innym przydatnym źródłem.

Jeśli to możliwe, przechwyć również dane wydajności dla dowolnego systemu zewnętrznego, z którego korzysta aplikacja. Te systemy zewnętrzne mogą udostępniać własne liczniki wydajności lub inne funkcje dla żądania danych wydajności. Jeśli nie jest to możliwe, należy zarejestrować takie informacje, jak czas rozpoczęcia i czas zakończenia każdego żądania wysłanego do systemu zewnętrznego razem ze stanem operacji (powodzenie, niepowodzenie lub ostrzeżenie). Na przykład możesz użyć metody stopera, aby zmierzyć czas żądania: uruchom czasomierz, gdy żądanie zostanie uruchomione, a następnie zatrzymaj go, gdy żądanie się zakończy.

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 systemu Windows i Diagnostyka Azure.

Analizowanie danych wydajności

Większość pracy analitycznej składa się z agregacji danych wydajności według typu żądania użytkownika lub podsystemu lub usługi, do której jest wysyłane każde żądanie. Przykładem żądania użytkownika jest dodawanie elementu do koszyka zakupów lub wykonywanie procesu finalizacji zakupu w systemie handlu elektronicznego.

Innym często spotykanym wymaganiem jest sumowanie danych wydajności w wybranych percentylach. Na przykład operator może określić czasy odpowiedzi dla 99 procent żądań, 95 procent żądań i 70 procent żądań. Dla każdego percentylu mogą istnieć cele umowy SLA lub inne cele. Bieżące wyniki powinny być zgłaszane w czasie prawie rzeczywistym, aby pomóc wykrywać problemy wymagające natychmiastowej reakcji. Wyniki powinny być również agregowane przez dłuższy czas do celów statystycznych.

W przypadku problemów z opóźnieniem wpływających na wydajność operator powinien móc szybko określić przyczynę wąskiego gardła, sprawdzając opóźnienie każdego kroku wykonywanego przez każde żądanie. Dane dotyczące wydajności muszą więc zapewniać środki korelacji miar wydajności dla każdego kroku, aby powiązać je z określonym żądaniem.

W zależności od wymagań wizualizacji przydatne może być generowanie i zapisywanie modułu danych, który zawiera widoki danych pierwotnych. Ten moduł danych umożliwia tworzenie złożonych zapytań ad hoc i analizę informacji o wydajności.

Monitorowanie zabezpieczeń

Wszystkie systemy komercyjne, które zawierają dane poufne, muszą mieć wdrożoną strukturę zabezpieczeń. Złożoność mechanizmu zabezpieczeń jest zwykle funkcją poufności danych. W systemie, który wymaga uwierzytelniania użytkowników, należy rejestrować:

• Wszystkie próby logowania — udane i nieudane.
• Wszystkie operacje wykonywane przez — oraz szczegóły wszystkich zasobów, do których uzyskuje dostęp — uwierzytelnionego użytkownika.
• Gdy użytkownik kończy sesję i wylogowuje się.

Monitorowanie może pomóc wykryć ataki na system. Na przykład duża liczba nieudanych prób logowania może wskazywać na atak metodą siłową. Nieoczekiwany wzrost liczby żądań może być skutkiem ataku typu rozproszona odmowa usługi (DDoS). Należy być przygotowanym do monitorowania wszystkich żądań do wszystkich zasobów niezależnie od źródła tych żądań. System, który ma luki w zabezpieczeniach logowania, może przypadkowo uwidocznić zasoby na zewnątrz bez konieczności rzeczywistego zalogowania się użytkownika.

Wymagania dotyczące monitorowania zabezpieczeń

Najbardziej krytyczne aspekty monitorowania zabezpieczeń powinny umożliwić operatorowi szybkie:

• Wykrycie próby wtargnięcia przez nieuwierzytelnioną jednostkę.
• Zidentyfikowanie próby wykonania przez jednostki operacji na danych, do których nie przyznano im dostępu.
• Określenie, czy system lub jakaś część systemu jest atakowana z zewnątrz lub od wewnątrz. (Na przykład złośliwy uwierzytelniony użytkownik może próbować doprowadzić do wyłączenia systemu).

Aby spełnić te wymagania, operator powinien zostać powiadomiony, jeśli:

• 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ń.

Informacje udostępniane operatorowi powinny zawierać adres hosta źródła każdego żądania. Jeśli naruszenia zabezpieczeń regularnie pochodzą z określonego zakresu adresów, te hosty mogą zostać zablokowane.

Kluczową częścią utrzymania bezpieczeństwa systemu jest możliwość szybkiego wykrywania akcji odbiegających od zwyczajowego wzorca. Informacje takie jak liczba nieudanych lub pomyślnych żądań logowania można wyświetlić wizualnie, aby pomóc wykryć, czy w nietypowym czasie występuje wzrost aktywności. (Przykład takiego działania jest logowanie się użytkowników o godzinie 3:00 i wykonywanie dużej liczby operacji, podczas gdy ich dzień roboczy zaczyna się o 9:00). Te informacje mogą również być używane do skonfigurowania automatycznego skalowania na podstawie czasu. Jeśli na przykład operator obserwuje, że duża liczba użytkowników loguje się regularnie o określonej porze dnia, może on ustawić uruchamianie dodatkowych usług uwierzytelniania, aby obsłużyć tę liczbę zadań, a następnie zamknąć te dodatkowe usługi, gdy godziny szczytu miną.

Wymagania dotyczące źródeł danych, instrumentacji i gromadzenia danych

Zabezpieczenia są obejmującym wszystko aspektem większości systemów rozproszonych. Potrzebne dane są prawdopodobnie generowane w wielu punktach systemu. Należy rozważyć zastosowanie podejścia zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM) do zbierania informacji związanych z zabezpieczeniami będącymi wynikiem zdarzeń zgłoszonych przez aplikację, urządzenia sieciowe, serwery, zapory, oprogramowanie antywirusowe i inne elementy zapobiegania nieautoryzowanemu dostępowi.

Monitorowanie zabezpieczeń może obejmować dane z narzędzi, które nie są częścią Twojej aplikacji. Narzędzia te mogą obejmować narzędzia identyfikujące czynności skanowania portów przez zewnętrzne agencje lub filtry sieci, które wykrywają próby uzyskania nieuwierzytelnionego dostępu do Twoich aplikacji i danych.

We wszystkich przypadkach zebrane dane muszą umożliwiać administratorowi ustalenie natury każdego ataku i podjęcie odpowiednich środków zaradczych.

Analizowanie danych zabezpieczeń

Funkcja monitorowania zabezpieczeń obejmuje różne źródła, w których powstają dane. Różne formaty oraz poziom szczegółowości często wymagają złożonej analizy przechwyconych danych, aby powiązać je razem w spójny wątek informacji. Oprócz najprostszych przypadków (takich jak wykrywanie dużej liczby nieudanych operacji logowania lub wielu prób uzyskania nieautoryzowanego dostępu do krytycznych zasobów) może nie być możliwe wykonanie dowolnego złożonego zautomatyzowanego przetwarzania danych zabezpieczeń. Zamiast tego lepszym rozwiązaniem może być zapisanie tych danych, sygnatura czasowa, ale w przeciwnym razie w oryginalnej postaci, bezpieczne repozytorium, aby umożliwić analizę ręczną ekspertów.

Monitorowanie umowy SLA

Wiele komercyjnych systemów, które obsługują płacących klientów, dają gwarancje dotyczące wydajności systemu w postaci umów dotyczących poziomu usług. Zasadniczo umowa SLA stwierdza, że system może obsłużyć określoną liczbę prac w uzgodnionym horyzoncie czasowym oraz bez utraty krytycznych informacji. Monitorowanie umowy SLA jest powiązane z zapewnieniem, że system może spełnić mierzalne wymagania umów SLA.

Umowy SLA często są definiowane w kategoriach:

• Ogólnej dostępności systemu. Na przykład organizacja może zagwarantować, że system będzie dostępny przez 99,9% czasu. Odpowiada to co najwyżej 9 godzinom przestoju rocznie lub około 10 minutom tygodniowo.
• Przepływności operacyjnej. Ten aspekt często jest wyrażany jako co najmniej jeden znacznik limitu górnego, taki jak zagwarantowanie, że system może obsłużyć do 100 000 równoczesnych żądań użytkowników lub 10 000 równoczesnych transakcji biznesowych.
• Operacyjnego czasu odpowiedzi. System może również gwarantować szybkość przetwarzania żądań. Przykładem może być to, że 99% wszystkich transakcji biznesowych zostanie ukończonych w ciągu 2 sekund i że żadna pojedyncza transakcja nie będzie trwać dłużej niż 10 sekund.

Wymagania dotyczące monitorowania umowy SLA

Na najwyższym poziomie operator powinien móc błyskawicznie ustalić, czy system spełnia uzgodnione umowy SLA. A jeśli nie, operator powinien móc przejść do szczegółów i sprawdzić źródłowe czynniki, aby ustalić przyczyny wydajności poniżej normy.

Typowe wskaźniki wysokiego poziomu, które mogą być przedstawione wizualnie, obejmują:

• Procent czasu działania usługi.
• Przepływność aplikacji (mierzona pod względem pomyślnych transakcji lub operacji na sekundę).
• Liczba udanych/nieudanych żądań aplikacji.
• Liczba błędów, wyjątków i ostrzeżeń aplikacji i systemu.

Wszystkie te wskaźniki powinny mieć możliwość filtrowania wg określonego przedziału czasu.

Aplikacja w chmurze prawdopodobnie będzie składać się z wielu podzespołów i elementów. Operator powinien móc wybrać wskaźnik wysokiego poziomu i zobaczyć, jak on składa się z kondycji podstawowych elementów. Jeśli na przykład czas pracy całego systemu spadnie poniżej akceptowalnej wartości, operator powinien móc powiększyć obraz i ustalić, które elementy przyczyniają się do tej awarii.

Dla celów zgłaszania alertów system powinien móc wywołać zdarzenie, jeśli dowolny wskaźnik wysokiego poziomu przekracza określony próg. Szczegóły niższego poziomu różnych czynników tworzących wskaźnik wysokiego poziomu powinny być dostępne dla systemu zgłaszania alertów jako dane kontekstowe.

Wymagania dotyczące źródeł danych, instrumentacji i gromadzenia danych

Dane pierwotne wymagane do obsługi monitorowania umowy SLA są podobne do danych pierwotnych wymaganych do monitorowania wydajności oraz do łączenia z pewnymi aspektami monitorowania kondycji i dostępności. (Zobacz te sekcje, aby uzyskać więcej szczegółów). Te dane można przechwycić, wykonując następujące czynności:

• Przeprowadzanie monitorowania punktu końcowego.
• Rejestrowania wyjątków, błędów i ostrzeżeń.
• Śledzenie wykonywania żądań użytkownika.
• Monitorowanie dostępności dowolnych usług innych firm używanych przez system.
• Wykorzystanie metryk wydajności i liczników.

Wszystkie dane muszą być czasowe i znaczniki czasu.

Analizowanie danych umowy SLA

Dane instrumentacji muszą być zagregowane, aby wygenerować obraz ogólnej wydajności systemu. Zagregowane dane muszą również obsługiwać przechodzenie do szczegółów w celu umożliwienia badania wydajności podstawowych podsystemów. Na przykład musisz mieć możliwość:

• Obliczenia całkowitej liczby żądań użytkowników w określonym przedziale czasu i ustalenia częstotliwości sukcesów i niepowodzeń tych żądań.
• Łączenia czasów odpowiedzi żądań użytkownika w celu wygenerowania ogólnego widoku czasów reakcji systemu.
• Analizowania postępu żądań użytkowników, aby dokonać podziału całkowitego czasu odpowiedzi żądania na czasy odpowiedzi poszczególnych elementów roboczych w tym żądaniu.
• Określania ogólnej dostępności systemu jako wartości procentowej czasu pracy dla dowolnego określonego okresu.
• Analizowania wartości procentowej czasu dostępności poszczególnych składników i usług w systemie. Może to obejmować analizowanie dzienników, które wygenerowały usługi innej firmy.

W wielu systemach komercyjnych jest wymagane raportowanie wyników rzeczywistej wydajności w porównaniu z uzgodnionymi umowami SLA w określonym okresie, zazwyczaj w ciągu miesiąca. Te informacje mogą służyć do obliczania kredytów lub innych form zwrotów dla klientów, jeśli w tym okresie nie są spełnione wymagania umów SLA. Dostępność usługi można obliczyć przy użyciu techniki opisanej w sekcji Analizowanie danych dotyczących dostępności.

Do celów wewnętrznych organizacja może również śledzić liczbę i rodzaj zdarzeń, które spowodowały awarię usług. Ustalenie, jak szybko rozwiązać te problemy lub usunąć je całkowicie, pomoże skrócić czas przestoju i spełnić wymagania umów SLA.

Inspekcja

W zależności od rodzaju aplikacji mogą istnieć ustawowe lub inne przepisy prawne, które określają wymagania dotyczące inspekcji operacji użytkowników i rejestrowania dostępu do wszystkich danych. Inspekcja może dostarczyć dowodów łączących klientów z określonymi żądaniami. Nonrepudiation jest ważnym czynnikiem w wielu systemach biznesowych, aby pomóc zachować zaufanie między klientem a organizacją, która jest odpowiedzialna za aplikację lub usługę.

Wymagania dotyczące inspekcji

Analityk musi mieć możliwość śledzenia sekwencji operacji biznesowych, które wykonują użytkownicy, dzięki czemu możesz odtworzyć akcje użytkowników. Może to być konieczne po prostu jako zapis lub jako część śledztwa.

Informacje o inspekcji są poufne. Prawdopodobnie zawierają one dane, które identyfikują użytkowników systemu wraz z zadaniami, które oni wykonują. Z tego powodu informacje o inspekcji najprawdopodobniej będą mieć postać raportów, które są dostępne wyłącznie dla zaufanych analityków, a nie interaktywnego systemu, który obsługuje przechodzenie do szczegółów operacji graficznych. Analityk powinien mieć możliwość wygenerowania zakresu raportów. Na przykład raporty mogą zawierać listę działań wszystkich użytkowników w określonym czasie, szczegóły chronologii działań pojedynczego użytkownika lub listę sekwencji operacji wykonywanych w odniesieniu do co najmniej jednego zasobu.

Wymagania dotyczące źródeł danych, instrumentacji i gromadzenia danych

Podstawowe źródła informacji dla inspekcji mogą obejmować:

• System zabezpieczeń, który zarządza uwierzytelnianiem użytkowników.
• Dzienniki śledzenia rejestrujące działania użytkownika.
• Dzienniki zabezpieczeń, które śledzą wszystkie możliwe i niemożliwe do zidentyfikowania żądania sieciowe.

Format danych inspekcji i sposób, w jaki są one przechowywane, mogą być wynikiem wymagań przepisów. Na przykład może nie być możliwe wyczyszczenie danych w jakikolwiek sposób. (Musi być rejestrowany w oryginalnym formacie). Dostęp do repozytorium, w którym jest przechowywany, musi być chroniony, aby zapobiec manipulowaniu.

Analizowanie danych inspekcji

Analityk musi mieć możliwość dostępu do danych pierwotnych w całości w ich oryginalnej postaci. Oprócz wymagania generowania wspólnych typowych raportów inspekcji narzędzia do analizowania tych danych mogą być wyspecjalizowane i przechowywane na zewnątrz systemu.

Monitorowanie użycia

Monitorowanie użycia śledzi sposób używania funkcji i składników aplikacji. Operator może wykorzystać zebrane dane w celu:

• Ustalenia funkcji, które są intensywnie używane, oraz wszelkich potencjalnych obszarów aktywności w systemie. Elementy o dużym natężeniu ruchu mogą skorzystać z partycjonowania funkcjonalnego, a nawet replikacji, aby bardziej równomiernie rozłożyć obciążenie. Operator może też użyć tych informacji do ustalenia, które funkcje są rzadko używane i są ewentualnymi kandydatami do wycofania lub zastąpienia w przyszłej wersji systemu.

• Uzyskania informacji na temat zdarzeń operacyjnych systemu w trakcie normalnego użytkowania. Na przykład w witrynie handlu elektronicznego możesz rejestrować informacje statystyczne dotyczące liczby transakcji oraz liczby użytkowników, którzy za nie odpowiadają. Te informacje mogą służyć do planowania wydajności w miarę zwiększania się liczby klientów.

• Wykrywania (prawdopodobnie pośrednio) zadowolenia użytkowników z wydajności lub funkcjonalności systemu. Jeśli na przykład duża liczba klientów w systemie handlu elektronicznego regularnie porzuca swoje koszyki, może to świadczyć o istnieniu problemu z funkcją finalizacji zakupu.

• Wygenerowania informacji o rozliczeniach. Komercyjne aplikacje lub wielodostępne usługi mogą naliczać klientom opłaty za zasoby, których oni używają.

• Wymuszanie limitów przydziałów. Jeśli użytkownik w systemie wielodostępnym przekracza swój opłacony limit przydziału czasu przetwarzania lub użycia zasobów w określonym przedziale czasu, ich dostęp lub przetwarzanie mogą być ograniczone.

Wymagania dotyczące monitorowania użycia

Aby zbadać użycie systemu, operator zazwyczaj potrzebuje informacji, które obejmują:

• Liczbę żądań, które są przetwarzane przez każdy podsystem i kierowane do każdego zasobu.
• Pracę wykonywaną przez każdego użytkownika.
• Rozmiar magazynu danych zajmowany przez każdego użytkownika.
• Zasoby, do których uzyskuje dostęp każdy użytkownik.

Operator powinien też móc generować wykresy. Na przykład wykres może pokazywać najbardziej „zasobożernych” użytkowników lub najczęściej udostępniane zasoby bądź funkcje systemu.

Wymagania dotyczące źródeł danych, instrumentacji i gromadzenia danych

Śledzenie użycia można wykonać na względnie wysokim poziomie. Można zanotować godziny rozpoczęcia i zakończenia każdego żądania oraz rodzaj żądania (odczytu, zapisu itd. w zależności od wybranego zasobu). Możesz uzyskać te informacje w następujący sposób:

• Śledząc działania użytkowników.
• Przechwytując liczniki wydajności mierzące użycie każdego zasobu.
• Monitorując zużycie zasobów przez każdego użytkownika.

W celach pomiarów musisz również mieć możliwość zidentyfikowania użytkowników odpowiedzialnych za wykonywanie operacji oraz zasobów, z których korzystają te operacje. Zebrane informacje powinny być wystarczająco szczegółowe, aby umożliwić dokładne rozliczenia.

Śledzenie problemów

Klienci i inni użytkownicy mogą zgłaszać problemy w przypadku wystąpienia w systemie nieoczekiwanych zdarzeń lub zachowań. Śledzenie problemów dotyczy zarządzania tymi problemami, kojarzenia ich z wysiłkami, aby rozwiązać podstawowe problemy w systemie, i informowania odbiorców o możliwych rozwiązaniach.

Wymagania dotyczące śledzenia problemów

Operatory często śledzą problemy za pomocą oddzielnego systemu umożliwiającego im rejestrowanie i raportowanie szczegółów problemów zgłaszanych przez użytkowników. Szczegóły te mogą obejmować zadania, które użytkownik próbował wykonać, objawy problemu, sekwencję zdarzeń i jakiekolwiek komunikaty o błędach lub ostrzeżenia, które zostały wygenerowane.

Wymagania dotyczące źródeł danych, instrumentacji i gromadzenia danych

Początkowym źródłem danych dla danych śledzenia problemów jest w pierwszej kolejności użytkownik, który zgłosił problem. Użytkownik może mieć możliwość zapewnienia dodatkowych danych, takich jak:

• Zrzut awaryjny (jeśli aplikacja zawiera składnik, który działa na pulpicie użytkownika).
• Migawka ekranu.
• Data i godzina, kiedy wystąpił błąd, oraz wszelkie inne informacje o środowisku, takie jak lokalizacja użytkownika.

Te informacje mogą służyć do ułatwienia debugowania i konstruowania listy prac dla przyszłych wersji oprogramowania.

Analizowanie danych śledzenia problemów

Różni użytkownicy mogą zgłosić ten sam problem. System śledzenia problemów powinien kojarzyć typowe raporty.

Postęp nakładu pracy debugowania powinien być rejestrowany dla każdego raportu problemu. Gdy problem zostanie rozwiązany, klient może zostać poinformowany o rozwiązaniu.

Jeśli użytkownik zgłosi problem, który ma znane rozwiązanie w systemie śledzenia problemów, operator powinien mieć możliwość natychmiastowego poinformowania użytkownika o rozwiązaniu.

Śledzenie operacji i debugowanie wersji oprogramowania

Gdy użytkownik zgłasza problem, użytkownik często zdaje sobie sprawę tylko z natychmiastowego wpływu na jego operacje. Użytkownik może zgłosić operatorowi, który jest odpowiedzialny za utrzymanie systemu, tylko wyniki wynikające z własnego doświadczenia. Te doświadczenia są zwykle tylko widocznym objawem co najmniej jednego problemu podstawowego. W wielu przypadkach analityk musi zapoznać się z chronologią podstawowych operacji w celu ustalenia głównej przyczyny problemu. Ten proces jest nazywany analizą głównych przyczyn.

Wymagania dotyczące śledzenia i debugowania

W celu śledzenia nieoczekiwanych zdarzeń i innych problemów jest istotne, aby dane monitorowania zawierały wystarczającą ilość informacji umożliwiających analitykowi wyśledzenie źródeł tych problemów i odtworzenie sekwencji zdarzeń, które wystąpiły. Te informacje muszą być wystarczające, aby umożliwić analitykowi zdiagnozowanie głównej przyczyny jakichkolwiek problemów. Deweloper może następnie wprowadzić niezbędne modyfikacje, aby zapobiec ich ponownemu występowaniu.

Wymagania dotyczące źródeł danych, instrumentacji i gromadzenia danych

Rozwiązywanie problemów może obejmować śledzenie wszystkich metod (i ich parametrów) wywoływanych jako część operacji w celu zbudowania drzewa, które przedstawia przepływ logiczny przez system, gdy klient wysyła określone żądanie. Wyjątki i ostrzeżenia, które system generuje w wyniku tego przepływu, muszą być przechwytywane i rejestrowane.

Aby obsłużyć debugowanie, system może zapewnić punkty zaczepienia umożliwiające operatorowi przechwycenie informacji o stanie w kluczowych punktach systemu. Lub system może dostarczać szczegółowych informacji krok po kroku w miarę postępu wybranych operacji. Przechwytywanie danych na tym poziomie szczegółowości może wprowadzić dodatkowe obciążenie systemu i powinno być procesem tymczasowym. Operator używa tego procesu głównie w przypadku wystąpienia wyjątkowej serii zdarzeń, która jest trudna do replikacji, lub gdy nowa wersja przynajmniej jednego elementu w systemie 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. Żaden z opisanych w poprzedniej sekcji scenariuszy nie musi być rozpatrywany w izolacji. Prawdopodobnie dane monitorowania i diagnostyki, które są wymagane w każdej sytuacji, w znacznym stopniu się nakładają, chociaż te dane muszą być przetwarzane i przedstawiane w różny sposób. Z tych powodów należy użyć holistycznego widoku monitorowania i diagnostyki.

Cały proces monitorowania i diagnostyki można przedstawić jako potok, który obejmuje etapy pokazane na rysunku 1.

Rysunek 1. Etapy w potoku monitorowania i diagnostyki.

Rysunek 1 pokazuje, jak dane dotyczące monitorowania i diagnostyki mogą pochodzić z różnych źródeł danych. Etapy instrumentacji i gromadzenia dotyczą identyfikacji źródeł, z których dane mają być przechwycone, określania danych do przechwycenia, sposobu ich przechwycenia i sposobu formatowania tych danych, dzięki czemu można je łatwo sprawdzić. Na etapie analizy/diagnostyki dane pierwotne są pobierane i wykorzystywane do generowania przydatnych informacji, których operator może używać do określenia stanu systemu. Operator może użyć tych informacji do podejmowania decyzji o możliwych do wykonania działaniach, a następnie przesłać wyniki z powrotem do etapów instrumentacji i gromadzenia. Etap wizualizacji/alertów przedstawia eksploatacyjny widok stanu systemu. Może on wyświetlać informacje w czasie prawie rzeczywistym, używając szeregu pulpitów nawigacyjnych. Może on też generować raporty, grafy i wykresy, aby udostępnić widok danych historycznych, który może ułatwić identyfikację trendów długoterminowych. Jeśli informacje wskazują, że kluczowy wskaźnik wydajności prawdopodobnie przekracza dopuszczalne granice, ten etap może także wyzwolić alert dla operatora. W niektórych przypadkach alert może też służyć do wyzwolenia zautomatyzowanego procesu, który próbuje wykonać akcje naprawcze, takie jak skalowanie automatyczne.

Należy pamiętać, że te kroki tworzą proces ciągłego przepływu, gdzie etapy występują równolegle. W idealnym przypadku wszystkie fazy powinny umożliwiać dynamiczną konfigurację. W niektórych punktach, szczególnie w przypadku systemu nowo wdrożonego lub mającego problemy, może być konieczne częstsze zbieranie rozszerzonych danych. W pozostałym czasie powinno być możliwe przywrócenie przechwytywania istotnych informacji na podstawowym poziomie, aby sprawdzić, czy system działa prawidłowo.

Ponadto cały proces monitorowania należy traktować jako ciągłe rozwiązanie na żywo podlegające strojeniu i ulepszaniu na podstawie opinii. Na przykład możesz zacząć od pomiaru wielu czynników w celu określenia kondycji systemu. Analiza w czasie może prowadzić do uściślania w miarę odrzucania miar, które nie są istotne, umożliwiając dokładniejszą koncentrację na potrzebnych danych przy jednoczesnym zmniejszeniu szumów tła.

Źródła danych monitorowania i diagnostyki

Informacje, których używa proces monitorowania, mogą pochodzić z wielu źródeł, jak pokazano na rysunku 1. Na poziomie aplikacji informacje pochodzą z dzienników śledzenia włączonych do kodu systemu. Deweloperzy powinni stosować standardowe podejście do śledzenia przepływu sterowania przy użyciu swojego kodu. Na przykład wpis w metodzie może wysyłać komunikat śledzenia, który określa nazwę metody, bieżący czas, wartość każdego parametru i inne istotne informacje. Rejestrowanie czasu wejścia i wyjścia może też okazać się przydatne.

Należy rejestrować wszystkie wyjątki i ostrzeżenia oraz upewnić się, że jest zachowany pełny ślad wszelkich zagnieżdżonych wyjątków i ostrzeżeń. W idealnym przypadku należy również przechwytywać informacje umożliwiające identyfikację użytkownika, który uruchamia kod, wraz z informacjami o korelacji działania (aby śledzić żądania w miarę ich przechodzenia przez system). Należy też rejestrować próby dostępu do wszystkich zasobów, takich jak kolejki komunikatów, bazy danych, pliki i inne usługi zależne. Te informacje mogą służyć do celów pomiaru i inspekcji.

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. Te platformy mogą umożliwiać konfigurację w celu zapewnienia ich własnych komunikatów śledzenia i nieprzetworzonych informacji diagnostycznych, takich jak częstotliwość transakcji oraz udane i nieudane transmisje danych.

System operacyjny, w ramach którego jest uruchomiona aplikacja, może być źródłem ogólnosystemowych informacji niskiego poziomu, takich jak liczniki wydajności, które wskazują szybkości operacji We/Wy, wykorzystanie pamięci i użycie procesora CPU. Mogą być również zgłaszane błędy systemu operacyjnego (takie jak niepowodzenie poprawnego otwarcia pliku).

Należy również rozważyć podstawową infrastrukturę i składniki, na których działa system. Maszyny wirtualne, sieci wirtualne i usługi magazynu, wszystkie one 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, te usługi mogą publikować własne informacje o śledzeniu, dzienniki i liczniki wydajności. Przykłady obejmują dynamiczne widoki zarządzania programu SQL Server do śledzenia operacji wykonywanych na bazie danych programu SQL Server i dzienniki śledzenia usługi IIS do rejestrowania żądań wysyłanych do serwera internetowego.

W miarę, jak składniki systemu są modyfikowane i nowe wersje są wdrażane, ważne jest, aby mieć możliwość przypisywania problemów, zdarzeń i metryk do każdej wersji. Te informacje należy powiązać z powrotem z potokiem wersji, dzięki czemu problemy z określoną wersją składnika mogą być szybko śledzone i usuwane.

Problemy z zabezpieczeniami mogą wystąpić w dowolnym miejscu w systemie. Na przykład użytkownik może próbować zalogować się przy użyciu nieprawidłowego identyfikatora użytkownika lub hasła. Uwierzytelniony użytkownik może podjąć próbę uzyskania nieautoryzowanego dostępu do zasobu. Lub użytkownik może podać nieprawidłowy lub nieaktualny klucz dostępu do zaszyfrowanych informacji. Zawsze należy rejestrować informacje związane z zabezpieczeniami dla żądań zakończonych powodzeniem i niepowodzeniem.

Sekcja Instrumentacja aplikacji zawiera więcej wskazówek na temat informacji, które należy przechwytywać. Ale do zebrania tych informacji można użyć różnych strategii:

• Monitorowanie aplikacji/systemu. Ta strategia używa wewnętrznych źródeł w aplikacji, struktur aplikacji, systemu operacyjnego i infrastruktury. Kod aplikacji może generować własne dane monitorowania w wartych zauważenia punktach podczas cyklu życia żądania klienta. Aplikacja może zawierać instrukcje śledzenia, które można selektywnie włączać lub wyłączać tak, jak dyktują to okoliczności. Może istnieć również możliwość dynamicznego wprowadzenia diagnostyki za pomocą platformy diagnostyki. Platformy te zapewniają zwykle wtyczki, które można dołączyć do różnych punktów instrumentacji w kodzie i przechwytywać dane śledzenia w tych punktach.

  Ponadto kod lub podstawowa infrastruktura mogą zgłaszać zdarzenia w krytycznych punktach. Agenci monitorowania, którzy są skonfigurowani do nasłuchiwania tych zdarzeń, mogą rejestrować informacje o zdarzeniu.

• Rzeczywiste monitorowanie użytkownika. Ta metoda rejestruje interakcje między użytkownikiem a aplikacją i obserwuje przepływ każdego żądania i odpowiedzi. Te informacje mogą być wykorzystane na dwa sposoby: mogą służyć do mierzenia użycia przez każdego użytkownika oraz do ustalenia, czy użytkownicy otrzymują usługi odpowiedniej jakości (na przykład krótsze czasy odpowiedzi, małe opóźnienia i minimalna liczba błędów). Przechwyconych danych możesz użyć do identyfikacji interesujących obszarów, gdzie najczęściej występują błędy. Tych danych możesz też użyć do identyfikacji elementów, gdzie system spowalnia, prawdopodobnie z powodu obszarów aktywności w aplikacji lub jakiejś innej formy wąskiego gardła. Staranne wdrożenie tego rozwiązania może pozwolić na rekonstrukcję przepływów użytkowników za pomocą aplikacji do debugowania i testowania.

  Ważne

  Dane przechwycone za pomocą monitorowania rzeczywistych użytkowników należy uważać za poufne, ponieważ mogą one zawierać poufne materiały. Jeśli zapisujesz przechwycone dane, zapisz je bezpiecznie. Jeśli chcesz używać danych do monitorowania wydajności lub debugowania, najpierw usuń wszystkie dane osobowe.

• Syntetyczne monitorowanie użytkownika. W takim podejściu piszesz własnego klienta testowego, który symuluje użytkownika i możliwą do konfigurowania, ale typową serię operacji. Możesz śledzić wydajność klienta testowego, aby ułatwić określenie stanu systemu. Możesz też użyć wielu wystąpień klienta testowego w ramach operacji testowania obciążenia w celu ustalenia sposobu reagowania systemu pod obciążeniem i tego, jaki rodzaj danych wyjściowych monitorowania jest generowany w tych warunkach.

  Uwaga

  Możesz zaimplementować rzeczywiste i syntetyczne monitorowanie użytkownika, dołączając kod, który śledzi i synchronizuje wykonanie wywołań metody i innych krytycznych części aplikacji.

• Profilowanie. Takie podejście jest przeznaczone głównie do monitorowania i poprawiania wydajności aplikacji. Zamiast działania na poziomie funkcjonalności rzeczywistego i syntetycznego monitorowania użytkownika powoduje to przechwycenie informacji niższego poziomu w miarę działania aplikacji. Możesz zaimplementować profilowanie, korzystając z okresowego pobierania próbek stanu wykonywania aplikacji (określania, która część kodu jest uruchomiona przez aplikację w danej chwili). Możesz też użyć instrumentacji, która wstawia sondy do kodu w ważnych miejscach połączenia (takich jak początek i koniec wywołania metody) i rejestruje metody, które zostały wywołane, godzinę ich wywołania i czas trwania każdego wywołania. 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. Ta metoda korzysta z przynajmniej jednego diagnostycznego punktu końcowego, który aplikacja udostępnia specjalnie, aby umożliwić monitorowanie. Punkt końcowy zapewnia ścieżkę do kodu aplikacji i może zwrócić informacje o kondycji systemu. Różne punkty końcowe mogą skupiać się na różnych aspektach funkcjonalności. Możesz napisać własnego klienta diagnostyki, 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.

Aby zapewnić maksymalne pokrycie, należy użyć kombinacji tych metod.

Instrumentacja aplikacji

Instrumentacja jest krytyczną częścią procesu monitorowania. Istotne decyzje dotyczące wydajności i kondycji systemu możesz podejmować tylko wtedy, gdy najpierw przechwycisz dane umożliwiające podejmowanie tych decyzji. Informacje, które zgromadzisz za pomocą instrumentacji, powinny być wystarczające do umożliwienia oceny wydajności, zdiagnozowania problemów oraz podejmowania decyzji bez konieczności logowania się na zdalnym serwerze produkcyjnym, aby ręcznie przeprowadzić śledzenie (i debugowanie). Dane instrumentacji zazwyczaj zawierają metryki i informacje zapisywane do dzienników śledzenia.

Zawartość dziennika śledzenia może być wynikiem danych tekstowych zapisywanych przez aplikację lub dane binarne utworzone w wyniku zdarzenia śledzenia, jeśli aplikacja używa funkcji śledzenia dla systemu Windows (ETW). Mogą one być również generowane z dzienników systemu rejestrujących zdarzenia wynikające z części infrastruktury, takich jak serwer internetowy. Komunikaty tekstowe dziennika często mają postać zrozumiałą dla użytkownika, ale powinny one również być zapisywane w formacie, który umożliwia ich łatwe przeanalizowanie przez zautomatyzowany system.

Należy też skategoryzować dzienniki. Nie zapisuj wszystkich danych śledzenia do pojedynczego dziennika, ale użyj oddzielnych dzienników, aby zapisać dane wyjściowe śledzenia z różnych operacyjnych aspektów systemu. Następnie możesz szybko przefiltrować komunikaty w dzienniku, odczytując je z odpowiedniego dziennika, bez konieczności przetwarzania jednego długiego pliku. Nigdy nie zapisuj informacji, które mają inne wymagania dotyczące zabezpieczeń (takich jak informacje inspekcji i dane debugowania), do tego samego dziennika.

Metryki zazwyczaj będą miarą lub liczbą pewnego aspektu lub zasobu w systemie w określonym czasie z przynajmniej jednym skojarzonym tagiem lub wymiarami (czasem nazywane próbką). Pojedyncze wystąpienie metryki zazwyczaj nie jest przydatne w izolacji. Zamiast tego metryki muszą być przechwytywane w czasie. Kluczową kwestią do rozważenia jest to, jaką metrykę należy rejestrować i jak często. Zbyt częste generowanie danych dla metryki może wprowadzać znaczące dodatkowe obciążenia w systemie, natomiast rzadsze przechwytywanie metryki może spowodować przeoczenie okoliczności, które doprowadziły do istotnych zdarzeń. Te kwestie różnią się w zależności od metryki. Na przykład użycie procesora CPU na serwerze może znacznie się różnić z sekundy na sekundę, ale wysokie użycie staje się problem tylko wtedy, gdy jest długotrwałe i trwa kilka minut.

Informacje dotyczące korelacji danych

Możesz łatwo monitorować poszczególne liczniki wydajności na poziomie systemu, przechwytywać metryki dla zasobów i uzyskiwać informacje o śledzeniu aplikacji z różnych plików dziennika. Jednak niektóre formy monitorowania wymagają etapu analizy i diagnostyki w potoku monitorowania w celu skorelowania danych pobieranych z kilku źródeł. Te dane mogą przyjąć kilka postaci w danych pierwotnych, a proces analizy musi mieć zapewnione wystarczające dane instrumentacji, aby mieć możliwość zmapowania tych różnych postaci. Na przykład na poziomie struktury aplikacji zadanie może być identyfikowane przez identyfikator wątku. W ramach aplikacji taka sama praca może być skojarzona z identyfikatorem użytkownika dla użytkownika, który wykonuje to zadanie.

Ponadto jest mało prawdopodobne, aby istniało mapowanie 1:1 między wątkami i żądaniami użytkownika, ponieważ operacje asynchroniczne mogą ponownie używać tych samych wątków do wykonywania operacji w imieniu więcej niż jednego użytkownika. Aby jeszcze bardziej skomplikować sprawy, pojedyncze żądanie może być obsługiwane przez więcej niż jeden wątek w miarę przepływu wykonywania przez system. Jeśli to możliwe, należy skojarzyć każde żądanie z unikatowym identyfikatorem działania, który jest propagowany przez system jako część kontekstu żądania. (Technika generowania i uwzględniania identyfikatorów działania w informacjach śledzenia zależy od technologii używanej do przechwytywania danych śledzenia).

Wszystkie dane monitorowania powinny być znacznikami czasu w taki sam sposób. W celu zachowania spójności należy zarejestrować wszystkie daty i godziny przy użyciu uniwersalnego czasu koordynowanego. Ułatwi Ci to śledzenie sekwencji zdarzeń.

Informacje do uwzględnienia w danych instrumentacji

Podczas wybierania danych instrumentacji, które należy zgromadzić, należy wziąć pod uwagę następujące kwestie:

• Upewnij się, że informacje przechwycone przez zdarzenia śledzenia są czytelne dla maszyn i ludzi. Dla tych informacji stosuj dobrze zdefiniowane schematy, aby ułatwić automatyczne przetwarzanie danych dziennika we wszystkich systemach oraz w celu zapewnienia spójności dla operacji i personelu technicznego czytającego dzienniki. Dołącz informacje o środowisku, takie jak środowisko wdrażania, maszyna na której jest uruchomiony proces, szczegóły procesu i stos wywołań.

• Włącz profilowanie tylko wtedy, gdy jest to konieczne, ponieważ może to wprowadzić znaczne narzuty na system. Profilowanie przy użyciu instrumentacji rejestruje zdarzenie (takie jak wywołanie metody) za każdym razem, gdy się ono pojawia, natomiast 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ą bardzo często, profilowanie za pomocą Instrumentacji może spowodować zbyt duże obciążenie i samo wpływać na ogólną wydajność. W takim przypadku podejście związane z próbkowaniem może być korzystniejsze. Jednak jeśli częstotliwość zdarzeń jest niska, próbkowanie może je pominąć. W takim przypadku instrumentacja może być lepszym rozwiązaniem.

• Zapewnij wystarczający kontekst, aby umożliwić deweloperowi lub administratorowi ustalenie źródła każdego żądania. Może to obejmować jakąś postać identyfikatora działania, który identyfikuje określone wystąpienie żądania. Może to również obejmować informacje, których można użyć do skorelowania tego działania z wykonywaną pracą obliczeniową i używanymi zasobami. Należy pamiętać, że ta praca może przekraczać granice procesu i maszyny. Do pomiarów kontekst powinien również zawierać (bezpośrednio albo za pośrednictwem innych skorelowanych informacji) odwołanie do klienta, który spowodował wykonanie żądania. Ten kontekst udostępnia cenne informacje o stanie aplikacji w czasie przechwytywania danych monitorowania.

• Zarejestruj wszystkie żądania i lokalizacje lub regiony, z których są wykonywane te żądania. Te informacje mogą pomóc w określeniu, czy istnieją jakieś obszary aktywności specyficzne dla lokalizacji. Te informacje mogą też być przydatne przy ustalaniu, czy należy ponownie podzielić na partycje aplikację lub dane, których ona używa.

• Dokładnie rejestruj i przechwytuj szczegóły wyjątków. Często krytyczne informacje debugowania są tracone w wyniku złej obsługi wyjątków. Przechwyć wszystkie szczegóły wyjątków zgłaszanych przez aplikację łącznie ze wszelkimi wyjątkami wewnętrznymi i innymi informacjami kontekstu. Jeśli to możliwe, uwzględnij stos wywołań.

• Zachowaj spójność danych przechwytywanych przez różne elementy aplikacji, ponieważ może to pomóc w analizowaniu zdarzeń i korelowaniu ich z żądaniami użytkowników. Rozważ użycie kompleksowego i konfigurowalnego pakietu rejestrowania, aby zebrać informacje, zamiast polegać na deweloperach, którzy zastosują to samo podejście w miarę implementowania różnych części systemu. Zbierz dane z kluczowych liczników wydajności, takich jak wolumin wykonywanych operacji We/Wy, wykorzystanie sieci, liczba żądań, użycie pamięci i procesora CPU. Niektóre usługi infrastruktury mogą udostępniać własne specyficzne liczniki wydajności, takie jak liczba połączeń z bazą danych, szybkość wykonywania transakcji i liczba transakcji zakończonych powodzeniem lub niepowodzeniem. Aplikacje mogą również definiować własne specyficzne liczniki wydajności.

• Rejestruj wszystkie wywołania 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. Rejestruj informacje o czasie wykonywania każdego wywołania i o powodzeniu lub niepowodzeniu wywołania. Jeśli to możliwe, przechwytuj informacje o wszystkich ponownych próbach i błędach dla wszelkich przejściowych błędów, które wystąpią.

Zapewnianie zgodności z systemami telemetrii

W wielu przypadkach informacje tworzone przez instrumentację są generowane jako szereg zdarzeń i przekazywane do oddzielnego systemu telemetrii w celu przetworzenia i analizy. System telemetrii jest zwykle niezależny od wszelkich określonych aplikacji lub technologii, ale oczekuje, że informacje będą w określonym formacie, który zazwyczaj jest definiowany przez schemat. Schemat skutecznie określa kontrakt definiujący pola danych i typy, które może pozyskiwać system telemetrii. Schemat powinien być uogólniony, aby dopuszczać dane otrzymywane z wielu platform i urządzeń.

Wspólny schemat powinien zawierać pola, które są wspólne dla wszystkich zdarzeń instrumentacji, takie jak nazwa zdarzenia, czas trwania zdarzenia, adres IP nadawcy, i szczegółowe informacje, które są wymagane do korelacji z innymi zdarzeniami (na przykład identyfikator użytkownika, identyfikator urządzenia i identyfikator aplikacji). Pamiętaj, że dowolna liczba urządzeń może zgłosić zdarzenia, więc schemat nie może zależeć od typu urządzenia. Ponadto różne urządzenia mogą zgłaszać zdarzenia dla tej samej aplikacji, zaś aplikacja może obsługiwać roaming lub jakąś inną postać dystrybucji między urządzeniami.

Schemat może również zawierać pola domeny, które mają zastosowanie w danym scenariuszu wspólnym dla różnych aplikacji. Mogą to być informacje o wyjątkach, zdarzeniach uruchamiania i kończenia aplikacji oraz powodzeniu lub niepowodzeniu wywołań interfejsu API usługi internetowej. Wszystkie aplikacje, które używają tego samego zestawu pól domeny, powinny wysyłać ten sam zestaw zdarzeń, umożliwiając utworzenie zestawu typowych raportów i analiz.

Wreszcie schemat może zawierać pola niestandardowe do przechwytywania szczegółów zdarzeń specyficznych dla aplikacji.

Najlepsze rozwiązania dotyczące instrumentacji aplikacji

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

• Zapewnij, żeby dzienniki były łatwe do odczytu i łatwe do analizy. Użyj strukturalnego rejestrowania, jeśli jest to możliwe. Komunikaty dziennika powinny być zwięzłe i opisowe.

• We wszystkich dziennikach zidentyfikuj źródło oraz zapewnij informacje o kontekście i synchronizacji, gdy jest zapisywany każdy rekord dziennika.

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

• Sklasyfikuj dzienniki i zapisz komunikaty w odpowiednim pliku dziennika.

• Nie ujawniaj poufnych informacji o systemie ani danych osobowych użytkowników. Wyczyść te informacje przed ich zarejestrowaniem, ale upewnij się, że odpowiednie szczegóły są zachowane. Na przykład usuń identyfikator i hasło z wszelkich parametrów połączenia bazy danych, ale zapisz pozostałe informacje w dzienniku, aby analityk mógł określić, że system uzyskuje dostęp do właściwej bazy danych. Rejestruj wszystkie wyjątki krytyczne, ale umożliwiaj administratorowi włączanie i wyłączanie rejestrowania na niższych poziomach wyjątków i ostrzeżeń. Ponadto przechwytuj i rejestruj wszystkie informacje logiki ponowień. Może to być przydatne podczas monitorowania przejściowej kondycji systemu.

• Śledź wywołania procesu, takie jak żądania kierowane 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 do tego samego dziennika.

• Upewnij się, że wszystkie wywołania rejestrowania, z wyjątkiem inspekcji zdarzeń, są operacjami samosterującymi, które nie blokują postępu operacji biznesowych. Zdarzenia inspekcji są wyjątkowe, ponieważ są krytyczne dla działalności firmy i mogą być klasyfikowane jako podstawowa część operacji biznesowych.

• Upewnij się, że rejestrowanie jest wszechstronne i nie ma żadnych zależności bezpośrednich dla konkretnego celu. Na przykład zamiast zapisywać informacje za pomocą elementu System.Diagnostics.Trace, zdefiniuj abstrakcyjny interfejs (taki jak ILogger), który udostępnia metody rejestrowania i który może być implementowany przez dowolne odpowiednie środki.

• Upewnij się, że całe rejestrowanie jest odporne na uszkodzenia i nigdy nie wyzwala żadnych 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, a nie tylko wtedy, gdy istnieje problem.

Zbieranie i przechowywanie danych

Etap zbierania procesu monitorowania jest rozpatrywany wraz z pobieraniem informacji generowanych przez instrumentację, formatowaniem tych danych w celu ułatwienia ich wykorzystania przez etap analizy/diagnostyki oraz zapisywaniem przekształconych danych w niezawodnym magazynie. Dane instrumentacji zebrane z różnych części rozproszonego systemu można przechowywać w różnych lokalizacjach i w różnych formatach. Na przykład kod aplikacji może generować pliki dziennika śledzenia i generować dane dziennika zdarzeń aplikacji, natomiast liczniki wydajności monitorujące kluczowe aspekty infrastruktury wykorzystywane przez Twoją aplikację można przechwycić za pomocą innych technologii. Wszelkie składniki i usługi innych firm używane przez aplikację mogą udostępniać informacje instrumentacji w różnych formatach przy użyciu oddzielnych plików śledzenia, magazynu obiektów blob, a nawet niestandardowego magazynu danych.

Zbieranie danych często odbywa się za pośrednictwem usługi zbierania, która może działać autonomicznie od aplikacji generującej dane instrumentacji. Na rysunku 2 przedstawiono przykład tej architektury, wyróżniając podsystem zbierania danych instrumentacji.

Rysunek 2. Zbieranie danych instrumentacji.

Należy pamiętać, że jest to uproszczony widok. Usługa zbierania nie musi być jednym procesem i może zawierać wiele elementów składowych działających na różnych maszynach zgodnie z opisem w poniższych sekcjach. Jeśli ponadto analiza niektórych danych telemetrycznych musi być wykonana szybko (analizy na gorąco zgodnie z opisem w sekcji Obsługa analizy na gorąco, ciepło i zimno w dalszej części tego dokumentu), lokalne składniki działające poza usługą zbierania mogą natychmiast wykonywać zadania analizy. Rysunek 2 pokazuje taką sytuację dla wybranych zdarzeń. Po zakończeniu przetwarzania analitycznego wyniki mogą być wysyłane bezpośrednio do podsystemu wizualizacji i alertów. Dane, które podlegają analizie na ciepło i zimno, są przechowywane w magazynie podczas oczekiwania na przetwarzanie.

Dla aplikacji i usług platformy Azure diagnostyka Azure udostępnia jedno możliwe rozwiązanie do przechwytywania danych. Diagnostyka Azure zbiera dane z następujących źródeł dla każdego węzła obliczeń, agreguje je, a następnie przekazuje do usługi Azure Storage:

• Dzienniki usług IIS
• Dzienniki zakończonych niepowodzeniem żądań usług IIS
• dzienniki zdarzeń systemu Windows
• Liczniki wydajności
• Zrzuty awaryjne
• Dzienniki infrastruktury diagnostyki Azure
• Dzienniki błędów niestandardowych
• Element EventSource platformy .NET
• ETW oparte na manifeście

Aby uzyskać więcej informacji, zobacz artykuł Azure: Telemetry Basics and Troubleshooting (Platforma Azure: podstawy telemetrii i rozwiązywanie problemów).

Strategie zbierania danych instrumentacji

Biorąc pod uwagę elastyczny charakter chmury, a także aby uniknąć konieczności ręcznego pobierania danych telemetrycznych z każdego węzła w systemie, należy zorganizować dane do przekazania do centralnej lokalizacji i skonsolidowania. W systemie obejmującym wiele centrów danych może być korzystne najpierw zebranie, skonsolidowanie i zapisanie danych dla każdego regionu, a następnie zagregowanie regionalnych danych w jednym systemie centralnym.

Aby zoptymalizować wykorzystanie przepustowości, możesz postanowić przesyłać mniej pilne dane we fragmentach jako partie. Jednak dane nie mogą być opóźniane w nieskończoność zwłaszcza, jeśli zawierają informacje zależne od czasu.

Ś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 (model ściągania). Może on także działać jako pasywny odbiornik oczekujący na dane, które mają być wysyłane ze składników tworzących każde wystąpienie aplikacji (model wypychania).

Jedno z podejść do wdrażania modelu ściągania polega na użyciu agentów monitorowania, które działają lokalnie z każdym wystąpieniem aplikacji. Agent monitorowania to oddzielny proces, który okresowo pobiera (ściąga) dane telemetryczne zbierane w węźle lokalnym i zapisuje te informacje bezpośrednio w centralnym magazynie, który współużytkują wszystkie wystąpienia aplikacji. Jest to mechanizm, który implementuje diagnostyki Azure. Każde wystąpienie roli internetowej lub procesu roboczego platformy Azure można skonfigurować do przechwytywania informacji diagnostycznych i innych informacji śledzenia, które są przechowywane lokalnie. Agent monitorowania, który działa obok każdego wystąpienia, kopiuje określone dane do usługi Azure Storage. Artykuł Enabling Diagnostics in Azure Cloud Services and Virtual Machines (Włączanie diagnostyki w usługach Azure Cloud Services i maszynach wirtualnych) zawiera bardziej szczegółowe informacje dotyczące tego procesu. Niektóre elementy, takie jak dzienniki usług IIS, zrzuty awaryjne i niestandardowe dzienniki błędów są zapisywane do magazynu obiektów blob. Dane z dziennika zdarzeń systemu Windows, zdarzenia ETW i liczniki wydajności są rejestrowane w magazynie tabel. Rysunek 3 ilustruje ten mechanizm.

Rysunek 3. Używanie agenta monitorowania do ściągania informacji i zapisywania w magazynie udostępnionym.

Wykonalne jest użycie właśnie opisanego podejścia do przechowywania danych telemetrii dla aplikacji o małej skali uruchomionych na ograniczonej liczbie węzłów w jednej lokalizacji. Jednak złożone, w dużym stopniu skalowalne, globalne aplikacje w chmurze mogą generować olbrzymie ilości danych z setek ról internetowych i procesów roboczych, fragmentów bazy danych i innych usług. Ten zalew danych może łatwo przeciążyć przepustowość We/Wy w jednym, centralnym miejscu. W związku z tym rozwiązanie telemetrii musi być skalowalne, aby zapobiec działaniu jako wąskie gardło w miarę rozszerzania systemu. W idealnym przypadku rozwiązanie powinno zawierać pewien stopień nadmiarowości, aby zmniejszyć ryzyko utraty ważnych informacji monitorowania (takich jak dane inspekcji lub rozliczeń), jeśli część systemu ulegnie awarii.

Aby rozwiązać te problemy, możesz zaimplementować kolejkowanie, jak pokazano na rysunku 4. W tej architekturze agent monitorowania lokalnego (jeśli może zostać odpowiednio skonfigurowany) lub niestandardowa usługa zbierania danych publikują dane w kolejce. Oddzielny proces uruchamiany asynchronicznie (usługa zapisywania do magazynu na rysunku 4) pobiera dane w tej kolejce i zapisuje je do udostępnionego magazynu. Kolejka komunikatów jest odpowiednia dla tego scenariusza, ponieważ udostępnia semantykę „co najmniej raz” pozwalającą zapewnić, że umieszczone w kolejce dane nie zostaną utracone po ich opublikowaniu. Możesz zaimplementować usługę zapisywania do magazynu przy użyciu oddzielnej roli procesu roboczego.

Rysunek 4. Buforowanie danych instrumentacji przy użyciu kolejki.

Usługa zbierania danych lokalnych może dodawać dane do kolejki natychmiast po ich odebraniu. Kolejka pełni rolę bufora, a usługa zapisywania do magazynu może pobierać i zapisywać dane we własnym tempie. Domyślnie kolejka działa na zasadzie „pierwszy na wejściu, pierwszy na wyjściu” (FIFO). Jednak możesz przypisać priorytety do komunikatów w celu przyspieszenia ich przemieszczania w kolejce, jeśli zawierają one dane, które muszą być obsługiwane szybciej. Aby uzyskać więcej informacji, zobacz wzorzec kolejki priorytetowej. Alternatywnie możesz użyć różnych kanałów (na przykład jako tematy usługi Service Bus) do kierowania danych do różnych miejsc docelowych w zależności od postaci wymaganego przetwarzania analitycznego.

W przypadku skalowalności możesz uruchomić wiele wystąpień usługi zapisywania do magazynu. W przypadku dużej liczby zdarzeń możesz użyć centrum zdarzeń do wysyłania danych do różnych zasobów obliczeniowych do przetworzenia i przechowania.

Konsolidowanie danych instrumentacji

Dane instrumentacji pobierane przez usługę zbierania danych z jednego wystąpienia aplikacji dają zlokalizowany widok kondycji i wydajności danego wystąpienia. Aby ocenić ogólną kondycję systemu, należy skonsolidować niektóre aspekty danych w lokalnych widokach. Możesz to wykonać po zapisaniu danych, ale w niektórych przypadkach możesz również uzyskać je w miarę zbierania danych. Zamiast zapisywania bezpośrednio do udostępnionego magazynu dane instrumentacji można przekazać za pośrednictwem oddzielnej usługi konsolidacji, która łączy dane i działa jako filtr i proces oczyszczania. Na przykład można połączyć dane instrumentacji zawierające te same informacje o korelacji, takie jak identyfikator działania. (Istnieje możliwość, że użytkownik rozpocznie wykonywanie operacji biznesowej w jednym węźle, a następnie zostaje przeniesiony do innego węzła w przypadku awarii węzła lub w zależności od konfiguracji równoważenia obciążenia). Ten proces może również wykrywać i usuwać zduplikowane dane (zawsze istnieje możliwość, jeśli usługa telemetrii używa kolejek komunikatów do wypychania danych instrumentacji do magazynu). Rysunek 5 ilustruje przykład tej struktury.

Rysunek 5. Używanie oddzielnej usługi do konsolidacji i czyszczenia danych instrumentacji.

Przechowywanie danych instrumentacji

Poprzednia dyskusja pokazała raczej uproszczony widok sposobu, w jaki są przechowywane dane instrumentacji. W rzeczywistości rozsądnie jest przechowywać różne typy informacji przy użyciu technologii, które są najbardziej odpowiednie do sposobu, w jaki najprawdopodobniej będą używane.

Na przykład magazyny obiektów blob i tabel platformy Azure mają pewne podobieństwa w sposobie uzyskiwania do nich dostępu. Jednak mają one ograniczenia dotyczące operacji, które możesz wykonywać za ich pomocą, a stopień szczegółowości danych, które przechowują, jest zupełnie inny. 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.
• Dzienniki śledzenia mogą być lepiej przechowywane w usłudze Azure Cosmos DB.
• Informacje o zabezpieczeniach można zapisać w systemie plików HDFS.
• Za pośrednictwem usługi Elasticsearch (która może również przyspieszyć wyszukiwania przy użyciu rozbudowanego indeksowania) mogą być przechowywane informacje, które wymagają wyszukiwania pełnotekstowego.

Możesz zaimplementować dodatkową usługę, która okresowo pobiera dane z udostępnionego magazynu, partycji i filtruje dane zgodnie z ich celem, a następnie zapisuje je do odpowiedniego zestawu magazynów danych, jak pokazano na rysunku 6. 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 oraz umożliwia zregenerowanie przynajmniej części danych podzielonych na partycje, jeśli to konieczne (w zależności od ilości danych przechowywanych w udostępnionym magazynie). Jednak zużywa to 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.

Rysunek 6. Partycjonowanie danych zgodnie z wymaganiami analitycznymi i magazynem.

Te same dane instrumentacji mogą być wymagane dla więcej niż jednego celu. Na przykład liczniki wydajności mogą służyć do zapewnienia historycznego widoku 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 przypadkach te same dane mogą być wysyłane do więcej niż jednego miejsca docelowego, takiego jak baza danych dokumentów, która może działać jako długoterminowy magazyn do przechowywania informacji o rozliczeniach i wielowymiarowy magazyn do obsługi złożonych analiz wydajności.

Należy również uwzględnić, na ile pilnie dane są wymagane. Dane zawierające informacje dotyczące alertów muszą być dostępne szybko, więc powinny być przechowywane w szybkim magazynie danych i indeksowane lub strukturyzowane w celu optymalizacji zapytań, które realizuje system zgłaszający alert. W niektórych przypadkach może być konieczne, aby usługa telemetrii, która zbiera dane o każdym węźle, sformatowała i zapisała dane lokalnie tak, aby lokalne wystąpienie systemu zgłaszającego alert mogło szybko powiadomić Cię o wszelkich problemach. 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.

Informacje, które są używane do dokładniejszej analizy, do raportowania i do wykrywania trendów historycznych, są mniej pilne i mogą być przechowywane w sposób obsługujący wyszukiwanie danych i zapytania ad hoc. Aby uzyskać więcej informacji, zobacz sekcję Obsługa analizy na gorąco, ciepło i zimno w dalszej części tego dokumentu.

Rotacja dziennika i przechowywanie danych

Instrumentacja może generować znaczne ilości danych. Te dane można przechowywać w kilku miejscach, począwszy od pierwotnych plików dziennika, plików śledzenia i innych informacji przechwyconych w każdym węźle, aby uzyskać skonsolidowany, oczyszczony i podzielony na partycje widok tych danych przechowywanych w magazynie udostępnionym. W niektórych przypadkach, po przetworzeniu i przesłaniu danych, źródłowe dane pierwotne można usunąć z każdego węzła. W innych przypadkach zapisanie danych pierwotnych może być konieczne lub po prostu użyteczne. Na przykład dane wygenerowane na potrzeby debugowania najlepiej pozostawić dostępne w postaci pierwotnej, ale mogą potem zostać szybko odrzucone po skorygowaniu usterek.

Dane dotyczące wydajności mają często dłuższy czas istnienia, aby można było ich użyć do wykrywania trendów i planowania wydajnoś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ć. Dane zbierane do pomiarów i rozliczeń klientów być może muszą być przechowywane w nieskończoność. Ponadto wymagania przepisów mogą wymuszać, żeby informacje zbierane na potrzeby inspekcji i zabezpieczeń również zostały obowiązkowo zarchiwizowane i zapisane. 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żyte do zatwierdzania fałszerstwa tożsamości. Takie szczegóły powinny zostać usunięte z danych przed ich zachowaniem.

Zmniejszenie częstotliwości próbkowania

Jest to przydatne do przechowywania danych historycznych, dzięki czemu można zauważyć trendy długoterminowe. Zamiast zapisywania starych danych w całości może być możliwe obniżenie częstotliwości próbkowania, aby zmniejszyć jego rozdzielczość i zaoszczędzić na kosztach magazynowania. Na przykład zamiast zapisywania wskaźników wydajności minuta po minucie możesz skonsolidować dane, które mają ponad miesiąc, aby utworzyć widok godzina po godzinie.

Najlepsze rozwiązania dotyczące zbierania i przechowywania informacji rejestrowania

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

• Agent monitorowania lub usługa zbierania danych powinny być uruchamiane jako usługa procesu i powinny być łatwe do wdrożenia.

• Wszystkie dane wyjściowe z agenta monitorowania lub usługi zbierania danych powinny mieć niesprecyzowany format, który jest niezależny od maszyny, systemu operacyjnego lub protokołu sieciowego. Na przykład wyemituj informacje w formacie samoopisującym, takim jak JSON, MessagePack lub Protobuf, a nie ETL/ETW. Użycie standardowego formatu umożliwia systemowi skonstruowanie potoków przetwarzania, przy czym składniki, które odczytują, przekształcają i wysyłają dane w ustalonym formacie, można łatwo zintegrować.

• Proces monitorowania i zbierania danych musi być odporny na uszkodzenia i nie może wyzwalać żadnych warunków błędów kaskadowych.

• W przypadku błędu przejściowego podczas wysyłania informacji do ujścia danych agent monitorowania lub usługa zbierania danych powinny być przygotowane do zmiany kolejności danych telemetrii tak, aby najnowsze informacje były wysyłane najpierw. (Agent monitorowania/usługa zbierania danych mogą postanowić usunąć starsze dane lub zapisać je lokalnie i przesłać je później do uwzględnienia wedle własnego uznania).

Analizowanie danych i diagnozowanie problemów

Ważną częścią procesu monitorowania i diagnostyki jest analizowanie zebranych danych w celu uzyskania ogólnego obrazu stanu systemu. Należy zdefiniować własne kluczowe wskaźniki wydajności i metryki wydajności, a ponadto ważne jest zrozumienie, jak tworzyć struktury danych, które zostały zebrane zgodnie z wymaganiami analizy. Ważne jest też zrozumienie tego, jak są skorelowane dane przechwytywane w różnych metrykach i plikach dziennika, ponieważ te informacje mogą być kluczem do śledzenia sekwencji zdarzeń i diagnozowania powstających problemów.

Zgodnie z opisem w sekcji Konsolidowanie danych instrumentacji dane dla każdej części systemu są zazwyczaj przechwytywane lokalnie, ale ogólnie wymaga to ich połączenia z danymi wygenerowanymi w innych lokacjach uczestniczących w systemie. Te informacje wymagają dokładnej korelacji, aby zapewnić, że dane zostały dokładnie połączone. Na przykład dane użycia dla operacji mogą obejmować węzeł, który jest hostem witryny internetowej, z którą łączy się użytkownik, węzeł, w którym jest uruchomiona oddzielna usługa dostępna w ramach tej operacji, i przechowywanie danych utrzymywanych w innym węźle. Te informacje muszą być powiązane ze sobą, aby zapewnić ogólny widok wykorzystania zasobów i przetwarzania dla operacji. Niektóre wstępne przetwarzanie i filtrowanie danych mogą wystąpić w węźle, na którym są przechwytywane dane, natomiast agregacja i formatowanie są bardziej narażone na wystąpienie w węźle centralnym.

Obsługa analizy na gorąco, ciepło i zimno

Analizowanie i ponowne formatowanie danych do celów wizualizacji, raportowania i zgłaszania alertów może być złożonym procesem, który wykorzystuje własny zestaw zasobów. Niektóre rodzaje monitorowania są wrażliwe na czas i wymagają natychmiastowej analizy danych, aby były skuteczne. Jest to nazywane analizą na gorąco. Do przykładów należą analizy, które są wymagane dla alertów, i pewne aspekty monitorowania zabezpieczeń (na przykład wykrywanie ataku na system). Dane, które są wymagane dla tych celów, muszą być szybko dostępne i mieć strukturę do wydajnego przetwarzania. W niektórych przypadkach może być konieczne przeniesienie przetwarzania analizy do poszczególnych węzłów, w których przechowywane są dane.

Inne formy analizy są mniej wrażliwe na czas i mogą wymagać pewnych obliczeń i agregacji po otrzymaniu danych pierwotnych. Jest to nazywane analizą na ciepło. Analiza wydajności często należy do tej kategorii. W takim przypadku izolowane, pojedyncze zdarzenie wydajności najprawdopodobniej nie będzie statystycznie istotne. (Może to być spowodowane nagłym wzrostem lub usterką). Dane z serii zdarzeń powinny zapewnić bardziej niezawodny obraz wydajności systemu.

Analiza na ciepło może też pomagać w diagnozowaniu problemów dotyczących kondycji. Zdarzenie kondycji jest zazwyczaj przetwarzane za pośrednictwem analizy na gorąco i może natychmiast zgłosić alert. Operator powinien móc przejść do szczegółów przyczyn zdarzenia kondycji, badając dane z ciepłej ścieżki. Te dane powinny zawierać informacje o zdarzeniach prowadzących do problemu, który spowodował zdarzenie kondycji.

Niektóre typy monitorowania generują bardziej długoterminowe dane. Ta analiza może być wykonana w późniejszym terminie, prawdopodobnie zgodnie ze wstępnie zdefiniowanym harmonogramem. W niektórych przypadkach analiza może wymagać przeprowadzenia złożonego filtrowania dużych ilości danych przechwyconych w danym czasie. Jest to nazywane analizą na zimno. Kluczowym wymaganiem jest, aby dane były bezpiecznie przechowywane po przechwyceniu. Na przykład monitorowanie użycia i przeprowadzanie inspekcji wymagają dokładnego obrazu stanu systemu w regularnych odstępach czasu, ale informacje o stanie nie muszą być dostępne do przetwarzania natychmiast po zebraniu.

Operator może również użyć analizy na zimno do dostarczania danych do predykcyjnej analizy kondycji. Operator może zebrać historyczne informacje w określonym czasie i używać ich w połączeniu z bieżącymi danymi kondycji (pobieranymi z gorącej ścieżki), aby wykryć tendencje, które mogą wkrótce spowodować problemy z kondycją. W takich przypadkach może być konieczne zgłoszenie alertu, aby podjąć akcje naprawcze.

Korelowanie danych

Instrumentacja przechwytuje dane, które mogą udostępniać migawkę stanu systemu, ale analiza ma na celu spowodowanie, żeby te dane umożliwiły wykonanie akcji. Na przykład:

• Co spowodowało intensywne obciążenie We/Wy na poziomie systemu w określonym czasie?
• Czy jest to wynikiem dużej liczby operacji bazy danych?
• Czy jest to odzwierciedlone w czasach odpowiedzi bazy danych, liczbie transakcji na sekundę i czasach odpowiedzi aplikacji w tych samych miejscach połączenia?

Jeśli tak, jedną akcją zaradczą, która może zmniejszyć obciążenie, może być podzielenie danych na więcej serwerów. Ponadto wyjątki mogą wystąpić w wyniku awarii na dowolnym poziomie systemu. Wyjątek na jednym poziomie często wyzwala inną awarię na wyższym poziomie.

Z tego względu musisz mieć możliwość skorelowania różnych typów danych monitorowania na każdym poziomie, aby utworzyć ogólny widok stanu systemu i aplikacji, które w nim działają. Następnie możesz użyć tych informacji do podejmowania decyzji o tym, czy system działa w akceptowalny sposób, oraz ustalenia, co można zrobić w celu poprawy jakości systemu.

Zgodnie z opisem w sekcji Informacje dotyczące korelacji danych musisz zapewnić, żeby pierwotne dane instrumentacji zawierały wystarczające informacje o identyfikatorze kontekstu i działania w celu obsługi wymaganych agregacji dla korelacji zdarzeń. Ponadto te dane mogą być przechowywane w różnych formatach i może być konieczne przeanalizowanie tych informacji, aby przekształcić je do standardowego formatu do analizy.

Rozwiązywanie i diagnozowanie problemów

Diagnostyka wymaga możliwości ustalenia przyczyny błędów lub nieoczekiwanego zachowania, a w tym wykonywania analizy głównych przyczyn. Do informacji, które są zazwyczaj wymagane, należą:

• Szczegółowe informacje z dzienników zdarzeń i danych śledzenia dla całego systemu lub dla określonego podsystemu w określonym przedziale czasu.
• Kompletne ślady stosu wynikające z wyjątków i błędów dowolnego określonego poziomu, które wystąpią w systemie lub określonym podsystemie w określonym przedziale czasu.
• Zrzuty awaryjne dla wszelkich procesów zakończonych niepowodzeniem w dowolnym miejscu systemu albo dla określonego podsystemu w określonym przedziale czasu.
• Dzienniki działań rejestrujące operacje, które są wykonywane przez wszystkich użytkowników albo przez wybranych użytkowników w określonym przedziale czasu.

Analizowanie danych na potrzeby rozwiązywania problemów często wymaga głębokiego technicznego zrozumienia architektury systemu i różnych składników, które tworzą rozwiązanie. W związku z tym często wymagany jest duży stopień ręcznej interwencji do interpretowania danych, ustalania przyczyny problemów i zalecania właściwej strategii ich usuwania. Być może należy po prostu zapisać kopię tych informacji w ich oryginalnym formacie i udostępnić je do analizy na zimno przez eksperta.

Wizualizacja danych i zgłaszanie alertów

Ważnym aspektem każdego systemu monitorowania jest możliwość prezentacji danych w taki sposób, że operator może szybko wychwycić wszelkie trendy lub problemy. Równie ważna jest możliwość szybkiego informowania operatora, jeśli wystąpiło istotne zdarzenie, które może wymagać uwagi.

Prezentacja danych może przyjąć kilka postaci, łącznie z wizualizacją za pomocą pulpitów nawigacyjnych, zgłaszania alertów i raportowania.

Wizualizacja przy użyciu pulpitów nawigacyjnych

Najpowszechniejszym sposobem wizualizacji danych jest użycie pulpitów nawigacyjnych, które mogą wyświetlać informacje w postaci serii wykresów, grafów i pewnych innych ilustracji. Te elementy mogą być parametryzowane, a analityk powinien mieć możliwość wyboru ważnych parametrów (na przykład jako przedziału czasu) dla każdej określonej sytuacji.

Pulpity nawigacyjne mogą być zorganizowane hierarchicznie. Pulpity nawigacyjne najwyższego poziomu mogą przedstawiać ogólny widok każdego aspektu systemu, ale też umożliwiać operatorowi przejście do szczegółów. Na przykład pulpit nawigacyjny, który pokazuje ogólne operacje We/Wy dysku dla systemu, powinien pozwalać analitykowi wyświetlać częstotliwości operacji We/Wy dla każdego oddzielnego dysku, aby ustalić, czy przynajmniej jedno określone urządzenie odpowiada za nieproporcjonalnie duży ruch. W idealnym przypadku pulpit nawigacyjny powinien również wyświetlać powiązane informacje, takie jak źródło każdego żądania (użytkownik lub działanie), które generuje tę operację We/Wy. Następnie można użyć tych informacji do ustalenia, czy (i jak) bardziej równomiernie rozłożyć obciążenie na urządzenia oraz czy system będzie działać lepiej po dodaniu większej liczby urządzeń.

Pulpit nawigacyjny może również użyć kodowania kolorami lub pewnych innych wskazówek wizualnych do wskazywania wartości, które wyglądają na nietypowe lub które są poza oczekiwanym zakresem. W poprzednim przykładzie:

• Dysk o częstotliwości operacji We/Wy dochodzącej do maksymalnej wydajności przez dłuższy czas (gorący dysk) może być wyróżniony kolorem czerwonym.
• Dysk o częstotliwości operacji We/Wy, która okresowo działa na swoim maksymalnym ograniczeniu przez krótki czas (ciepły dysk), może być wyróżniony kolorem żółtym.
• Dysk, który wykazuje normalne użycie, może być wyświetlany na zielono.

Należy pamiętać, że aby system pulpitu nawigacyjnego działał efektywnie, musi on pracować z danymi pierwotnymi. 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 zebrać, na jakim poziomie szczegółowości i jak powinny one być sformatowane, aby pulpit nawigacyjny skorzystał z tych danych.

Dobry pulpit nawigacyjny nie tylko wyświetla informacje, ale umożliwia też analitykowi stawianie pytań ad hoc dotyczących tych informacji. Niektóre systemy zapewniają narzędzia do zarządzania, których operator może użyć do wykonywania tych zadań i eksplorowania podstawowych danych. Alternatywnie, w zależności od repozytorium, które służy do przechowywania tych informacji, może być możliwe wysłanie zapytania bezpośrednio do tych danych lub zaimportowanie go do narzędzi, takich jak program Microsoft Excel, do dalszej analizy i raportowania.

Zgłaszanie alertów

Zgłaszanie alertów to proces analizowania danych monitorowania i instrumentacji oraz generowania powiadomienia w przypadku wykrycia istotnego zdarzenia.

Zgłaszanie alertów pomaga zapewnić, żeby system pozostawał w dobrej kondycji, odpowiadał i był bezpieczny. Jest to ważnym elementem każdego systemu, który daje użytkownikom gwarancje wydajności, dostępności i ochrony prywatności, gdy może być konieczne wykonanie natychmiastowej operacji na danych. Może być konieczne powiadamianie operatora o zdarzeniu, które wyzwoliło alert. Zgłaszanie alertów może też służyć do wywołania funkcji systemu, takich jak skalowanie automatyczne.

Zwykle zgłaszanie alertów zależy od następujących danych instrumentacji:

• Zdarzenia zabezpieczeń. Jeśli dzienniki zdarzeń wskazują, że występują powtarzające się błędy uwierzytelniania lub autoryzacji, system może zostać zaatakowany, a operator powinien zostać poinformowany.
• Metryki wydajności. System musi szybko reagować, jeśli określona 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 się na zasób rezerwowy. Powtórne błędy w podsystemie mogą wskazywać na poważniejsze problemy.

Operatorzy mogą otrzymywać informacje o alertach za pomocą wielu kanałów dostarczania, takich jak wiadomości e-mail, urządzenie pager lub wiadomości tekstowe SMS. Alert może również obejmować wskazanie, jak bardzo krytyczna jest sytuacja. Wiele systemów zgłaszania alertów obsługuje grupy subskrybentów i wszyscy operatorzy, którzy są członkami tej samej grupy, mogą otrzymać ten sam zestaw alertów.

System zgłaszania alertów powinien mieć możliwość dostosowania, a odpowiednie wartości z podstawowych danych instrumentacji mogą zostać podane jako parametry. Takie podejście umożliwia operatorowi filtrowanie danych i skoncentrowanie się na tych progach lub kombinacjach wartości, które mogą być interesujące. Należy pamiętać, że w niektórych przypadkach pierwotne dane instrumentacji mogą zostać udostępnione systemowi zgłaszania alertów. W innych sytuacjach może być bardziej odpowiednie dostarczenie zagregowanych danych. (Na przykład alert może zostać wyzwolony, jeśli wykorzystanie procesora CPU dla węzła przekroczyło 90% w ciągu ostatnich 10 minut). Szczegółowe informacje przekazane do systemu zgłaszania alertów powinny również obejmować wszelkie odpowiednie podsumowania i informacje kontekstu. Te dane mogą pomóc zmniejszyć prawdopodobieństwo, że zdarzenia fałszywie dodatnie będą wyzwalać alert.

Raportowanie

Raportowanie służy do generowania ogólnego widoku systemu. Może ono obejmować dane historyczne oraz bieżące informacje. Wymagania raportowania jako takie można podzielić na dwie szerokie kategorie: raportowanie operacyjne i raportowanie zabezpieczeń.

Zazwyczaj raportowanie operacyjne obejmuje następujące aspekty:

• 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 pod względem wdrożonych zasobów i zrozumienie, czy można zmniejszyć ilość zasobów (i powiązanych z nimi kosztów) bez niepotrzebnego wpływu na wydajność.

Raportowanie zabezpieczeń dotyczy śledzenia wykorzystania systemu przez klientów. Może ono obejmować:

• Inspekcja operacji użytkownika. Wymaga to rejestrowania poszczególnych żądań, które wykonuje każdy użytkownik, wraz z datami i godzinami. Dane powinny mieć strukturę umożliwiającą administratorowi szybką rekonstrukcję sekwencji operacji wykonywanych przez użytkownika w określonym czasie.
• Śledzenie użycia zasobów przez użytkownika. Wymaga to rejestracji sposobu, w jaki żądanie użytkownika uzyskuje dostęp do różnych zasobów, które tworzą system, i na jak długo. Administrator musi mieć możliwość użycia tych danych do generowania raportu wykorzystania przez użytkownika w określonym czasie, prawdopodobnie na potrzeby rozliczeń.

W wielu przypadkach procesy wsadowe mogą generować raporty zgodnie ze zdefiniowanym harmonogramem. (Opóźnienie nie jest zwykle problemem). Jednak w razie potrzeby powinny one być również dostępne do generowania w sposób ad hoc. Jeśli na przykład przechowujesz dane w relacyjnej bazie danych, takiej jak Azure SQL Database, możesz użyć narzędzia, takiego jak usługi SQL Server Reporting Services, aby wyodrębnić i sformatować dane oraz pokazać je jako zestaw raportów.

Następne kroki

• Omówienie usługi Azure Monitor
• Monitor, diagnose, and troubleshoot Microsoft Azure Storage (Monitorowanie, diagnozowanie i rozwiązywanie problemów z usługą Microsoft Azure Storage)
• Przegląd alertów na platformie Microsoft Azure
• Wyświetlanie powiadomień dotyczących kondycji usługi za pomocą witryny Azure Portal
• Co to jest Application Insights?
• Diagnostyka wydajności maszyn wirtualnych platformy Azure
• Pobieranie i instalowanie narzędzi SQL Server Data Tools (SSDT) dla programu Visual Studio

Powiązane zasoby

• Wskazówki dotyczące skalowania automatycznego opisują sposób zmniejszenia narzutu na zarządzanie, redukując potrzebę ciągłego monitorowania wydajności systemu przez operatora i podejmowania decyzji o dodaniu lub usunięciu zasobów.
• Wzorzec monitorowania punktu końcowego kondycji opisuje sposób implementowania testów funkcjonalnych w aplikacji, do których narzędzia zewnętrzne mogą uzyskiwać dostęp za pośrednictwem uwidocznionych punktów końcowych w regularnych odstępach czasu.
• Wzorzec kolejki priorytetu pokazuje, jak określić priorytety komunikatów w kolejce, tak aby pilne żądania zostały odebrane i można je przetworzyć przed mniej pilnych komunikatów.