Gdy trwoga, to do loga. Kilka słów o monitoringu.

oddball-security-signs-5_10760038

Monitoring aplikacji jest absolutnie niezbędny, by wiedzieć czy jest ona dostępna dla użytkowników. Nie każdy jednak wie, że z wnikliwej obserwacji płynie też masa innych korzyści: jesteśmy w stanie minimalizować czasy niedostępności, optymalizować działanie aplikacji, przewidywać nadchodzące problemy, reagować na problemy użytkowników zanim oni je zgłoszą.

Dla nas, testerów, monitoring jest nieprzebranym morzem informacji na temat zachowania użytkowników. Z monitoringu możemy uzyskać informacje na temat faktycznego ruchu, pod którym działa nasza aplikacja by następnie dopiero z informacjami o tym ruchu przystępować do testów wydajnościowych. Wspomoże nas on w odpowiedzeniu na pytania:

  • Czy nowe funkcjonalności nie wprowadzają nowych błędów?
  • Czy naprawa błędu faktycznie spowodowała jego usunięcie, a nie tylko ukrycie?

Jako testerzy nie jesteśmy w stanie wyłapać i uniknąć wszystkich błędów w aplikacji. Dlatego też wspaniałym ratunkiem jest dobry monitoring. Poprawnie skonfigurowany dostarczy nam informacji na temat występujących błędów jak i w przypadku awarii – co jest bezpośrednim jej powodem.

Badanie dostępności dla użytkowników

Klienci, którzy używają naszego oprogramowania zarówno do pracy jak i przyjemności, będą na pewno zdenerwowani w przypadku jej niedostępności. Mogą oni nawet przestać z niej korzystać. Zaufanie użytkownika jest najważniejsze – nasze oprogramowanie musi być stabilne i dostępne o każdej porze dnia czy nocy. Równie ważnym parametrem dostępności aplikacji jest prędkość ładowania się strony. Czas jest cenny i długo ładująca się strona będzie równie frustrująca jak wystąpienie na niej komunikatu o niedostępności. Parametr ten jest również używany jako jedna z metryk w rankingach wyszukiwarek. Warto również badać dostępność aplikacji z innych lokalizacji niż nasza aktualna (zwłaszcza z innych krajów). W zbieraniu tych informacji przydatne mogą być zarówno narzędzia istniejące wewnątrz firmy, jak i te dostępne na zewnątrz:

Śledzenie zachowania użytkowników

Niektóre rodzaje monitoringu pozwalają nam na śledzenie jak klienci używają naszego produktu. Jest to niezwykle ważne dla biznesu, ale my, testerzy, również możemy korzystać z takich danych. Oto przykładowa strona z wizualizacją zachowania użytkowników:

CrazyEgg

Już analizując tą jedną wizualizacje zyskujemy wiedzę o tym, jakie moduły są często odwiedzane przez użytkowników. Będą to moduły, których błędy będą miały wyższy priorytet, jak i historie dotykające tych modułów powinny być dokładniej testowane. Warto również skoncentrować się na sprawdzeniu tych miejsc podczas wdrożeń – w przeciwnym wypadku sprawdzą je użytkownicy. Również Analitics posiada wtyczkę dla przeglądarki Chrome, która pozwala otrzymać wizualizację z procentowymi wartościami używania poszczególnych modułów. Nie mniej w naszym projekcie używamy głownie:

ce_logoheatmap

W następnej kolejności ważne jest badanie jak dużo osób używa zarówno nowo wdrażanych modułów czy funkcjonalności jak i tych wdrożonych już jakiś czas temu. Jeżeli chodzi o nowe funkcjonalności dobrze jest zadbać o podpięcie na przykład kampanii w Google Analitics oraz zbieranie innych dodatkowych statystyk użycia nowo dostarczonego kodu.

Grafana

Na tym przykładowym wykresie możemy obserwować wpływ wdrożeń na jedną z działających już w systemie funkcjonalności. Podobne anomalie pojawiające się na wykresach bez znanej nam przyczyny powinny być bezwzględnie analizowane, a w przypadku wykrycia błędów – naprawiane. W naszym projekcie używamy do tego celu:

Z przepięknym dashingiem zbierającym te wszystkie dane w grafanie:

GrafanaLogo

Na koniec bardzo dobrze jest zaprzyjaźnić się z Google Analitics. Oferuje on nam masę informacji na temat ruchu użytkowników. Przykładowo porównując dni, tygodnie, miesiące ruchu użytkowników możemy wychwytywać anomalie, a następnie analizować ich przyczyny.

Analitics

Dodatkowo Google Analitics może nam dostarczać informacji na temat ilości aktualnie połączonych klientów. Obserwując tą wartość możemy podejmować decyzję na temat wdrożenia kodów na produkcję, a mniejsza lub większa wartość może sugerować awarię.

GA

Obserwowanie zużycia maszyn

Monitorowanie wydajności serwera to bardzo ważna czynnością, szczególnie gdy obserwujemy że system zaczyna zwalniać. Pierwsza rzecz, która rzuca się w oczy włączając podstawowo monitor wydajności systemu to obciążenie procesorów, lecz nie zawsze ten parametr musi być przyczyną problemów. Przechwytywać i analizować powinniśmy wszystkie najważniejsze wskaźniki, takie jak użycie procesora, pamięci, dysku, procesów, usług i sieci, dotyczące serwerów. Pozwala poznać nam to jak używane są nasze maszyny i zaplanować z wyprzedzeniem, jakie są wymagania dotyczące tych zasobów. Mając wiedzę na temat standardowego użycia maszyn możemy również przygotować alerty, kiedy to po przekroczeniu tych wartości otrzymujemy komunikaty. Analizujemy wtedy sytuację czy mamy awarię, czy też należy zmienić śledzone wartości. My używamy w tym celu:

Obserwowanie logów aplikacyjnych

Logi spływające z naszej aplikacji to mój najlepszy przyjaciel. Towarzyszą mi na każdym środowisku, przy każdej godzinie pracy. Nie każdy błąd objawia się niedziałającą aplikacją. Bardzo często błędy pojawiające się w logach (i tylko w logach) jako “Notice” czy “Warning” też powinny zostać naprawione, bo z czasem mogą przerodzić się w awarię. Można by powiedzieć, że wszystkie wymienione w poprzednich akapitach metody uświadamiają nas, że “coś” się dzieje. Logi mówią nam dokładnie co się dzieje.

syslog

Warto pamiętać, że w logach znajduje się masa informacji. Sukcesy, ostrzeżenia, błędy – dla każdej akcji wywołanej przez pojedynczego użytkownika. Dlatego przy większej ilości klientów warto zainwestować w narzędzia do zarządzania logami:

logstash

Czy to wszystkie jest warte zachodu?

Z własnego doświadczenia odpowiem: Stanowczo tak.

W swojej historii miałam już przykład, gdzie funkcjonalność po 20 minutach od odpalenia przez użytkownika zaczynała się odświeżać co kilka sekund. Generowało to nagły i bardzo duży ruch widoczny na wykresach. Wystarczyła chwila – zerknięcie w logi – i wiedzieliśmy, że wszystkie żądania pochodzą od jednego użytkownika. Mieliśmy więc pełnie informacji by przystąpić do błyskawicznej analizy lokalizacji błędu i jego naprawy.

Przygotowując się do dużej kampanii marketingowej korzystaliśmy ze zgromadzonych informacji na temat istniejącego ruchu użytkowników. Do tego dołożyliśmy spodziewany ruch wygenerowany przez osoby pozyskane z kampanii. I dla tak przygotowanych danych przeprowadziliśmy testy wydajnościowe by wykryć przy jakim ruchu zaczniemy mieć problemy oraz jakiego rodzaju będą to problemy.

Gdy tylko jedna z naszych stron jest niedostępna – otrzymujemy maile, komunikaty na telefon czy komunikaty na HipChat. Staramy się wiedzieć o awarii najszybciej ze wszystkich, by móc od razu podjąć odpowiednie kroki.

Do zapamiętania

Jako testerzy musimy pamiętać głównie o kilku rzeczach:

  • Błędy występujące w logach to błędy do naprawy. Należy bezwzględnie zgłaszać je wszystkie do developerów nawet, jeśli naprawa miałaby polegać na zmianie poziomu logowania z błędu na informację o zdarzeniu.
  • Przy testach nowych funkcjonalności musimy sprawdzać czy zbierają się do niej odpowiednie statystyki oraz czy podczas testów pojawiają się odpowiednie logi informujące o sukcesach, zdarzeniach i wywołaniach błędów.
  • Dbajmy o czytelność nowo odkładających się logów. Jak zawsze – informacji nie powinno być ani za dużo ani za mało. Najlepszy log to taki, który w jednej linijce daje nam jednoznaczną odpowiedź na pytania “Kto? Co? Gdzie? Kiedy?”. Miałam okazję zgłaszać błędy do poprawy przez developerów by poprawili nieczytelne informacje okładające się w logach – nie bójmy się tego.
  • Obserwujmy jak najczęściej logi produkcyjne – zwłaszcza podczas wdrożeń.
  • Monitoring maszyn nie należy tylko do Administratorów, dobrze byśmy też mieli wiedzę gdzie znajdują się wykresy oraz jak je odczytywać.
  • Analiza zachowania użytkowników ma wartość nie tylko dla Biznesu, ale i dla nas przy planowaniu testów i nadawaniu priorytetów błędów.

Więcej o logowaniu możecie poczytać na przykład na ComputerWorld.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s