Monitoring systemów oraz aplikacji w ING Banku Śląskim

04.06.2019 | Jarosław Kobiałka Michał Skupień

Jak było

Na pewnym etapie firma stanęła przed koniecznością migracji systemu monitoringu IT. Istniejący do tej pory monitoring miał za zadanie integrację istniejących systemów monitoringu, uporządkowanie otrzymanych eventów oraz przeniesienie ich na model usług. Systemy z rodziny Microsoftu opierały monitoring o swój rodzimy produkt, bazy danych miały swój wewnętrzny system alertowania, a nad performance aplikacji czuwał moduł requestów podłączony do loadbalancerów, który monitorował bezpośrednio ruch protokołu http(s). Nie można zapomnieć o infrastrukturze fizycznej w data center, która to uzbrojona w dużą ilość czujników monitorujących parametry pomieszczeń, sprzętu, stanu zasilania, klimatyzatorów itd. posiadała również swój system monitorujący. Do tego dochodzą tysiące urządzeń sieciowych rozsiane po całej Polsce, setki bankomatów, systemy alarmowe, kamery, systemy kontroli dostępu, monitoring UPS i agregatów.

Wszystkie te systemy zwane dalej „systemami dziedzinowymi” w ustalony sposób raportowały do centralnej konsoli w ówczesnym service desku.

Konsola składała się z kilku następujących obszarów:

1. Drzewka organizującego obszary monitoringu
2. Okna szczegółów zawierającego opis danego eventu składającego się z kilku zakładek (np. summary, object, history, source)
3. Listy, na której są wyświetlane wszystkie eventy, gdzie za pomocą filtrów predefiniowanych można było wyświetlać odpowiednią grupę eventów związaną z danym narzędziem monitorującym.

W kolejnym etapie alerty były filtrowane i trafiały jako incydenty do systemu ITSM.

Na ówczesne czasy brzmiało to dumnie i robiło wrażenie. Ale jak wiadomo, technologia idzie do przodu a ilość monitorowanych urządzeń, systemów i aplikacji ciągle rośnie.

Splunk - platforma analityczna jako podstawa monitoringu

A co by było, jak byśmy mogli połączyć dane monitoringu z platformą do analizy danych w czasie rzeczywistym? Moglibyśmy budować dashboardy czasu rzeczywistego obrazujące nie tylko czy coś działa czy nie, ale także jak zmieniają się parametry w czasie, co otwiera drzwi do budowy inteligentnego monitoringu opartego o predykcję i sztuczną inteligencję? Może korelacja wielu metryk ciągłych pozwoli wykrywać rzeczywiste awarie na chwilę przed ich wystąpieniem? Ten scenariusz akurat był bardzo realny. Oczywiście trzeba pamiętać, że cały balast tego, co już mamy, przyzwyczajeń ludzkich będzie nam towarzyszył.

Od dobrych kilku lat używamy Splunka do analizy logów oraz alertowania krytycznych stanów w wybranych aplikacjach. Narzędzie bardzo popularne, w którym – wydawać by się mogło – można wszystko. Od zbierania ciągłych danych z wszelakich źródeł.

Plusem tego rozwiązania jest to, że zbierane dane mogą być modyfikowane, filtrowane oraz agregowane w locie przed zaindeksowaniem na hostach. Następnie trafiają na serwery zwane indekserami. Pod spodem działa mechanizm odwróconych indeksów oparty o bazę danych MongoDB. Głównymi elementami architektury Splunka są serwery dostępowe zwane search headami, na których stoi interfejs webowy aplikacji.

Logika wykonywanych zapytań odbywa się – w zależności od budowy zapytania – częściowo na indekserach (czyli bezpośrednio na bazie danych – charakterystyczne dla optymalnie napisanych zapytań) oraz finalnie dane składane są oraz prezentowane po stronie search headów. Sekret optymalnych zapytań tkwi w tym, aby jak najwięcej operacji filtrowania oraz agregacji wykonało się na indekserach oraz minimalizacji ilości danych oraz obliczeń po stronie search headów. Informacje na temat funkcji strumieniowych (wykonywanych na indekserach) i transformacyjnych (wykonywanych na search headach) dla języka SPL można znaleźć w dokumentacji.

Organizacja węzłów ta pozwala wykonywać operacje filtrowań i złożonych obliczeń w ciągu ułamków sekund, a wyniki użyć do budowania dashboardów z pięknymi wykresami, tworzenia raportów oraz alertów. Warto wspomnieć o dedykowanym typie indeksów przeznaczonym do danych numerycznych – tzw. indeksów metrykalnych, znane z innych systemów do monitoringu, które w porównaniu do indeksów tradycyjnych oferują znacznie większą wydajność przy wykonywaniu obliczeń dla szerszych zakresów czasów. 

Ponadto Splunk oferuje bardzo uniwersalny interfejs i spore możliwości. Jedną z nich jest możliwość cyklicznego uruchamiania zapytań (raportów) oraz ich akcelerowania jeśli ilość wyników jest >100k. W tym przypadku trzeba pamiętać, aby zapytanie SPL zawierało komendę transformacyjną np. chart, timechart, stats lub top. Powoduje to, że wew. mechanizm Splunka po pierwszym wykonaniu raportu wykonuje podsumowanie danych opartych na wynikach zwróconych przez raport. Po ponownym uruchomieniu akcelerowanego raportu wykorzystywane są wcześniej zagregowane dane, następnie mechanizm wylicza brakujące dane zachowując wynik do kolejnego wywołania raportu oszczędzając zasoby i czas. Stosowanie w/w mechanizmu ma sens dla często używanych raportów, z których dane prezentowane są np. na wyświetlanych dashboardach.  

Inną opcją jest definiowanie dodatkowych akcji/alertowania np. gdy zaplanowany raport zwróci określone dane np. wysłanie maila, zgłoszenie incydentu, uruchomienie akcji naprawczej itd. W naszym wypadku integracja ta zakłada m.in. założenie odpowiedniego ticketu w ServiceNow.

Koncepcja wielowarstwowego monitoringu aplikacji

Jak to zbudowaliśmy? W dawnym service desku zorganizowaliśmy burzę mózgów polegającą na znalezieniu odpowiedzi na ważne pytanie - czego nam brakuje aby przekazać kompletną informację do dyżurnego danej technologii/aplikacji. Oprócz tego potrzebowaliśmy wiedzieć, co się dzieje z usługą/aplikacją i natychmiast otrzymać instrukcje o dalszych krokach, a nie tylko przekazać numer incydentu i zawartą w nim treść do dyżurnego aplikacji. Zmuszało go do własnoręcznej analizy i oczekiwania na info zwrotne, co zwykle po czasie kończyło się „odbiciem piłeczki” do kolejnej osoby generując niepotrzebna zwłokę w likwidacji usterki.

Przyjrzeliśmy się naszej ówczesnej konsoli z alertami, eksperymentowaliśmy z dashboardami i zapytaniami w Splunku aby zobaczyć co potrafi. Z każdą godziną nasza wizja stawała się jaśniejsza. Po udokumentowaniu pierwotnej wizji zorganizowaliśmy szereg spotkań z przedstawicielami technologii i aplikacji w celu dalszej ewolucji pomysłu wzbogaconej o doświadczenia i sugestie kolejnych osób.

Głównym założeniem naszego projektu było stworzenie generycznego monitoringu narzucającego standard budowy metryk dla każdej aplikacji. Osoba, która podejmuje wstępną analizę nie powinna mieć problemu we wstępnym określeniu przyczyny awarii.

W naszych głowach kwitła idea wielowarstwowego monitoringu. Założenie mówiło, że mamy trzy warstwy ze względu na poziom ogólności:

1. I poziom – wizualizacja głównych metryk wszystkich aplikacji
2. II poziom – ogólny dla pojedynczej aplikacji z warstwami pośrednimi narzucający standardowy widok metryk
3. III poziom – dla każdej technologii, komponentu aplikacji zapewniająca dowolność budowy dashboardów dla programistów oraz administratorów.

Oraz 5 warstw ze względu na stos technologiczny aplikacji:

1. User experience
2. App components
3. Middleware
4. Operating system
5. Hardware & network

Przyjrzyjmy się takiemu scenariuszowi: klient, logując się do bankowości mobilnej może doświadczyć szeregu spowolnień lub błędów. To jest pierwsza warstwa: User experience. Idąc dalej aplikacje składają się logicznie z wydzielonych części oraz komponentów, które odpowiadają za funkcjonalności w aplikacji czyli App components. Aplikacja jest osadzona na różnego rodzaju technologiach serwerowych, bazodanowych, systemach kolejkowych – jest to warstwa Middleware. Idąc niżej mamy system operacyjny oraz jego parametry: warstwa Operating system. Poniżej warstwą scalającą jest sieć oraz systemy wirtualizacji.

Dla każdej warstwy monitoringu danej aplikacji powinny zostać zdefiniowane metryki w postaci zapytań zwracających wynik w konkretnej formie przebiegu w czasie. Krytyczne metryki powinny być monitorowane w sposób ciągły – pozostałe mają pomagać w analizie podczas awarii. Dla warstw User Experience oraz App Components metryki definiują programiści odpowiedzialni za daną aplikację. A za warstwy Middleware, Operating system oraz Hardware odpowiadają administratorzy poszczególnych technologii. Poniżej przykładowa aplikacja opisana w powyższym ujęciu:

W pierwszym podejściu chcieliśmy wykorzystać standardowe możliwości budowania dashbordów w Splunk. Okazało się, że nie do końca możemy wizualizować dane, ustawiać opcje dla metryk tak jak chcemy. Wtedy podjęliśmy decyzję o napisaniu własnej struktury dashboardów i logiki na platformie Splunk. Po wielu fazach testów i błędów udało się stworzyć coś czym mogliśmy się pochwalić. Nawiązując do tworzenia dashboardów w Splunk mamy trzy poziomy wtajemniczenia:

1. Tworzenie dashbordów z gotowych komponentów dostępnych z GUI
2. W/w dashboardy umożliwiają zaawansowaną edycję poprzez ingerencję w strukturę XML, w której można zmieniać i dodawać elementy niedostępne z poziomu GUI np. interakcje pomiędzy elementami dashboardów
3. Poziom JS i HTML – można pisać dashboardy w języku JS i HTML wykorzystując biblioteki SplunkJS lub je zaimplementować we własnej aplikacji i prezentować zawartość raportów jako elementy wbudowane.

Następnie zbudowaliśmy interfejs do dodawania metryk, który pozwalał na ustawianie progów statycznych oraz zmiennych w czasie. Metryka mogła generować incydenty po przekroczeniu progów. Od technicznej strony Splunk posiada wewnętrzne mechanizmy do przechowywania danych w postaci plików płaskich (lookups) jak i kolekcji zwanych KVstore, które są odpowiednikiem tabel w bazie danych. Poza tym mamy do dyspozycji bogate REST API, które pozwala na automatyzację oraz rozbudowanie formularzy o dodatkowe akcje. Warto wspomnieć, że Splunk posiada system schedulowania zadań z priorytetyzacją, co ma swoje wady i zalety zwłaszcza, że zapytania generowane przez użytkowników lub przez otwierane dashboardy również wchodzą do tej puli.

Pierwsze sukcesy, pierwsze wyzwania

Na pierwsze sukcesy nowego podejścia nie trzeba było długo czekać. Możliwość analizy parametrów ciągłych zaowocowała wykrywaniem anomalii przed faktycznym wystąpieniem awarii oraz jej zapobieganiem. Narzędzie zdobywało coraz większą rzeszę zwolenników co miało swoje konsekwencje.

W przypadku informacji o problemach związanych z daną aplikacją Splunk nie był w stanie obsłużyć działań osób podejmujących szczegółowe analizy danych. I tutaj zaczynają się problemy. Splunk jest zaprojektowany tak aby dostarczyć maksimum zasobów użytkownikowi w możliwie krótkim czasie. Co za tym idzie – liczba użytkowników musi być niewielka, a uruchamiane zapytania i dashboardy muszą być tworzone optymalnie.

W przypadku awarii dotykającej nasze aplikacje – rozpoczynała się walka o utrzymanie przy życiu naszego systemu monitoringu. Problem rozwiązano poprzez wydzielenie instancji Splunk dedykowanej tylko do monitorowania ze specjalnie wydzielonym dostępem oraz części analitycznej dostępnej dla użytkowników.

Powyższa architektura ma swoje wady. Środowisko, na którym dane są replikowane jest wrażliwa na obciążenie systemu, które generuje zwiększone opóźnienia replikacji. Efektem jest nierównomierne opóźnienie na klastrze wtórnym – które według dokumentacji – powinno wynosić do 3s natomiast w rzeczywistości opóźnienia są większe.

Próba stabilizacji środowiska monitorującego udała się, jednak pewnym kosztem. Ograniczenie ilości użytkowników oraz kontrola „schedulowanych” zadań na środowisku monitorującym wyeliminowała problem generowania błędów typu false positive przez mechanizmy Splunka, szczególnie przy dużym obciążeniu lub nawet niedostępności środowiska analitycznego na czas awarii innych aplikacji. Niestety, ogranicza to wgląd programistów na stan środowiska. Teraz, w razie awarii innych aplikacji,  zbyt duże zapotrzebowanie na zasoby w Splunk przez osoby analizujące (i ciekawske – bo przecież każdy chce zobaczyć co się pali) co prawda powoduje chwilowe ograniczenie dostępu na środowisku analitycznym (choć nie zawsze) ale też gwarantuje dostępność platformy monitoringu jako platformy analitycznej dla samego Master Control Room oraz sztabu Disaster Recovery w celu szybkiego i skutecznego wyjścia z awarii.

No dobra, ale co z setkami użytkowników, którzy tak potrzebują Splunka i chcą z niego korzystać na klastrze analitycznym? Tutaj rodzi się inne wyzwanie. Skoro część monitoringowo-raportowo-alertową wyciągnęliśmy z tej części Splunka to należy wprowadzić kontrolę przy próbach uruchamiania ciężkich zapytań, raportów i alertów, które osobnym kanałem informują programistów o problemach w ich aplikacjach. Z reguły zadania te "pożerają" zasoby w sposób ciągły, zabierając je użytkownikom, którzy potrzebują dostępu ad hoc. Jak napisaliśmy wcześniej, Splunk stara się tak koordynować wykonywanymi zadaniami, by obsłużyć je jak najszybciej wszystkimi dostępnymi zasobami. Uruchomienie ciężkiego, długiego zapytania może przytkać na jakiś czas system, stąd wymagana kontrola lub wręcz anulowanie takich zadań, by odciążyć system na czas "czkawki".

Podsumowanie

Splunk jest bardzo dobrym narzędziem analitycznym, umożliwiającym przekrojowy monitoring aplikacji biznesowych,  kondycji systemów, infrastruktury. Funkcje wbudowane w aplikację pozwalają w łatwy i przyjemny sposób działać na danych, które indeksujemy. Dostępność wielu dodatków, możliwość pisana własnych skryptów wzbogacają aplikację, która może zwykłemu użytkownikowi przekazać dane w szybki, przyjemny i przejrzysty sposób. Wkład pracy przeznaczony na wytworzenie kompleksowego podejścia zwrócił się bardzo szybko, dzięki czemu wychwytujemy na bieżąco awarie i spowolnienia w naszych aplikacjach.