Monitorowanie zasobów i definiowanie alertów

Monitorowanie zasobów wykorzystywane jest do wykrywania różnego rodzaju problemów związanych z maszyną wirtualną, pod kontrolą pracuje web aplikacja. Przedwczesne wykrycie awarii znacznie zwiększa prawdopodobieństwo na szybkie rozwiązanie zaistniałego problemu. Ponadto nadzór nad konfiguracją poszczególnych elementów App Service Planu może być podstawą do poprawnego i w pełni wydajnego działania web aplikacji.

Monitorowanie zasobów

Najczęściej analizowane informacje znajdziemy odwiedzając zakładkę Omówienie (overview) aplikacji. W tej sekcji można między innymi sprawdzić jak często spotykamy się np. z błędami serwera, jaki jest stosunek danych wejściowych do danych wyjściowych, z jaką liczbą żądań aplikacja miała do czynienia w ostatnim czasie czy jaki był średni czas odpowiedzi na żądanie. Ponadto w zakładce Diagnozowanie i rozwiązywanie problemów (Diagnose and solve problems) można znaleźć podstawowe informacje na temat żywotności aplikacji. Dzięki niej możemy sprawdzić jaki był stan aplikacji przez ostatnie 24 godziny. Jeżeli była ona przez jakiś czas niedostępna, jesteśmy w stanie sprawdzić, kiedy to miało miejsce – można by to nazwać monitorem zdrowia aplikacji (health check monitor):

Monitorowanie zasobów (health check) dla web aplikacji
Monitorowanie zasobów (health check) dla web aplikacji

 

Klikając w linki znajdujące się poniżej wykresu można przejrzeć bardziej szczegółowe metryki takie jak: liczba operacji wejścia wyjścia dla zapisu i odczytu czy zużycie procesora.

No dobrze, wiemy już na czym polega monitorowanie zasobów oraz gdzie znajdują się najpopularniejsze metryki i raporty. Teraz zastanówmy się przez chwilę, jak często należy tam zaglądać i analizować wszystkie te wykresy? Czy powinniśmy, rozpoczynać każdy nowy dzień pracy, popijając świeżo zaparzoną kawę, od nawigacji po portalu i przeglądu wszystkich wygenerowanych przez noc raportów. A co w sytuacji, gdy administrujemy nie jednym, nie dwoma, a dajmy na to trzydziestoma aplikacjami? Z pomocą przychodzi możliwość definiowania własnych alertów.

Definiowanie alertów

Alerty są to pewnego rodzaju reguły, reagujące na zajście jakiegoś, z góry określonego zdarzenia. Załóżmy, że zużycie pamięci osiągnęło poziom 90% pomiędzy godziną 13:00, a 14:00 – właśnie wtedy gdy jesteś na spotkaniu z prezesem. Mogę zdefiniować alert, który będzie kontrolował zużycie pamięci przez cały czas, a w momencie gdy ustalony przeze mnie próg zostanie przekroczony (niech będzie to 90%) w przeciągu przynajmniej 5 minut, powiadomi mnie wysyłając wiadomość email.

Alerty znajdziesz klikając w aplikację, a następnie w zakładkę Alerty (Alerts). Zacznijmy od dodania nowego alertu. Wskazujemy na zasób (web aplikację), podajemy nazwę alertu oraz opis. Alert może monitorować metryki oraz zdarzenia. Na razie zajmiemy się tymi pierwszymi.

Alerty reagujące na zmiany zachodzące w metrykach

Jako metrykę wybierz Średnie zużycie pamięci (Average memory working set). Niżej powinna znajdować się miniaturka wykresu symbolizująca aktualny stan wybranej metryki. Następnie określamy warunek, próg oraz przedział czasu, po przekroczeniu którego alert powinien zareagować. Na samym dole możemy dodać adresy email, na które ma zostać wysłane powiadomienie, w razie przekroczenia zdefiniowanego progu, lub adres webhook. Wśród wszystkich dostępnych metryk powinieneś być w stanie znaleźć coś dla siebie 🙂 Przykładowa konfiguracja:

Definiowanie alertu reagującego na zmiany w metrykach
Definiowanie alertu reagującego na zmiany w metrykach

Alerty reagujące na zdarzenia

Przejdźmy teraz do alertów reagujących na zdarzenia. Możemy monitorować operacje usunięcia, uruchomienia, zatrzymania lub wszystkie na raz. Następnie mamy do dyspozycji stan (powodzenie lub niepowodzenie) oraz deklarację progu oraz liczbę wykonanych operacji, po ilu alert powinien zareagować. Jak można wykorzystać takie zdarzenia? Załóżmy, że chcemy otrzymać powiadomienie, gdf aplikacja zostanie uruchomiona 10 razy w ciągu ostatnich 15 minut. Jest to dosyć dziwne zachowanie nieprawdaż? Można by pomyśleć, że aplikacja nie  chce się uruchomić i jest cały czas restartowana. Warto było by rzucić okiem co się tam wyprawia. Innym przykładem może być wysłanie wiadomości email w sytuacji gdy aplikacja została usunięta:

Definiowanie alertu reagującego na usunięcie web aplikacji
Definiowanie alertu reagującego na usunięcie web aplikacji

Jeżeli web aplikacja zostanie usunięta, email zostanie do mnie wysłany oraz do pozostałych administratorów subskrypcji.

Jak po każdym wpisie PowerShell’a oraz Azure CLI 🙂

PowerShell

Azure CLI