Czy zastanawiałeś się kiedykolwiek co robi Twoja aplikacja, gdy na nią nie patrzysz? Czy jesteś pewien, że wytworzone przez Ciebie oprogramowanie jest stabilne?
W mojej programistycznej karierze większość czasu spędziłem projektując i wdrażając systemy portalowe. Dziedzina portali jest bardzo specyficzna. Główną cechą charakteryzującą te systemy musi być wysoka wydajność oraz dostępność. Nie można sobie pozwolić na przerwy w działaniu aplikacji. Każda minuta niedostępności serwisu to olbrzymie straty dla Klienta – przede wszystkim utrata odbiorców i czytelników.
Wolno, coraz woooooolnieeej…
Pamiętam jak dziś projekt popularnego portalu informacyjnego o tematyce filmowej. Czas developmentu był trudnym okresem, gdyż wymagania zmieniały się jak w kalejdoskopie i ciężko było zamknąć zakres projektu. Prawdziwe czarne chmury nadeszły w dniu uruchomienia produkcyjnego. Na naszych oczach już w pierwszych minutach portal zaczął „umierać”. Tysiące odsłon serwisu w tym samym momencie wysyciło wszystkie wątki kontenera aplikacji. Możesz sobie wyobrazić nastrój w zespole, napiętą sytuację z Klientem i tysiące oczu wpatrzone w spinner ładowania się strony. Serwery również miały co robić – load serwera 20, całkowicie zużyta pamięć, a praca wentylatorów przypominała suszarkę do włosów. Co robić, jak żyć? Od czego zacząć analizę? Nadszedł czas reaktywacji…
Szybka diagnoza
Gdyby to był mój pierwszy projekt – miałbym poważne kłopoty. Jednak w tym przypadku byliśmy przygotowani na tego typu atrakcje. Z pomocą przyszły nam wszelkiego rodzaju logi aplikacji, timery wykonywania się metod oraz system monitorujący zajętość zasobów (począwszy od przestrzeni dyskowej, poprzez pamięć i procesory, aż do statysyk zaalokowanej pamięci Javy oraz czasu wykonywania się Garbage Collectora). W ruch poszły narzędzia monitoringu i ulubiony zestaw komend linuxowych (less oraz grep). Cóż więc było problemem podczas tej próby wdrożenia? Odpowiedź jest banalna:
- wolno wykonujące się zapytanie (około 1s) powodowało lawinę wysyceń wątków kontenera aplikacji,
- źle dobrane przestrzenie Young i Old Generation dla Garbage Collectora.
Bardziej wnikliwy Czytelnik mógłby stwierdzić: Dlaczego więc nie zrobiliście testów wydajnościowych?. Otóż – zrobiliśmy. Niestety, w scenariuszach testowych nie przewidzieliśmy jednej z pobocznych ścieżek, która była bardzo często wykonywana na produkcji.
Ucz się na cudzych błędach
Droga programistko, drogi programisto – czy masz pewność, że Twoja aplikacja jest responsywna 24/24? Zgodnie ze staropolskim powiedzeniem „Ucz się na cudzych błędach” poniżej zamieszczam kilka porad, które warto wdrożyć już podczas tworzenia oprogramowania:
- Logowanie czasu wykonywania się metod – można to wykonać na setki sposobów począwszy od prostych timer’ów i ręcznego wrzucenia do loga, aż do integracji z zewnętrznymi systemami monitoringu (np. Graphana i Graphite).
- Ciągły monitoring zasobów sprzętowych oraz samej aplikacji. Tutaj jest szerokie spectrum gotowych do użycia aplikacji, np.: Cacti, Zabbix, etc. Koniecznie należy monitorować użycie procesorów, pamięci, przepustowość łącza oraz przestrzeń dyskową. W monitoring warto włączyć dostępność wątków kontenera aplikacji, dostępność bazy danych jak również samego Reverse Proxy i mnóstwo innych rzeczy, która można spotkać w Twojej aplikacji. Narzędzie monitorujące powinno mieć możliwość przejrzenia wykresów i zebranych danych.
- Monitoring webserwisów, z którymi integruje się Twoja aplikacja. Doskonale nadaje się do tego końcówka /health w Spring Boot, która jest wpięta w system monitoringu.
- Logowanie czasu wykonywania się zapytań SQL. Nieoptymalnie napisane zapytania (szczególnie, gdy wykorzystujemy ORM) jest jedną z głównych przyczyn awarii systemów! Logowanie tego typu operacji jest wręcz obowiązkowe.
- Cykliczne sprawdzanie dostępności aplikacji poprzez wywołanie głównych kontekstów aplikacji i podstawowych scenariuszy testowych (np. narzędzie curl).
- Wdrożenie systemu powiadamiania o błędach w aplikacji i problemach sprzętowych (np. alerty w systemie Nagios).
- Uruchomienie narzędzia do zbierania i przeglądania logów – tu z pomocą przychodzi magiczne trio ELK (Elastic Search, Log Stash, Kibana).
- Włączenie logowania czasu wykonywania się Garbage Collectora.
- W pogotowiu powinny być skonfigurowane narzędzia/skrypty umożliwiajce wykonanie Thread Dumpa oraz Heap Dumpa. Warto pokusić się o implementację automatu, który podczas awarii wykonuje Thread Dump, a podczas niedostępności dłuższej niż np. 10 minut – Heap Dump.
- Opracowanie procedury działania podczas awarii systemu, najlepiej lista w postaci TODO. Awaria aplikacji jest zawsze stresująca. Spisana procedura pozwoli na sprawną diagnozę przyczyn problemu.
Jak dziecko we mgle
W systemach, które utrzymywane są przez naszą firmę zawsze są wpięte systemy monitoringu. Nie wyobrażam sobie pracy i analizy problemów bez statystyk, czy też wykresów. Zebrane dane pozwalają na natychmiastową diagnozę problemu i szybką naprawę niedziałającego serwisu. Gdybym nie miał takich narzędzi czułbym się jak dziecko we mgle a reakcja na problem byłaby zdecydowanie dłuższa. Strzeż się – SLA zobowiązuje 🙂
Źródła obrazków:
