GALAKTYKA albo o ucieczce od iluzji

Nowy sposób wizualizacji wydajności systemów autorstwa polskiej firmy szybko zyskuje uznanie. Rozwiązanie stosowane już w kilkudziesięciu polskich firmach brawurowo pokonuje znane słabości rozwiązań APM.

Jednym z elementów, które mogą realizować racjonalne oszczędności w IT, jest grupa narzędzi związanych z zarządzaniem wydajnością aplikacji (Application Performance Management – APM). Duże korporacje inwestują w zakup narzędzi APM. Dostawcy tego typu rozwiązań wdrażają dziesiątki kokpitów, setki wykresów i diagramów przepływów. Definiują tysiące różnych alertów i zasypują skrzynki pocztowe interesariuszy komunikatami o „stanie zdrowia” procesów biznesowych. Ma to za zadanie stworzyć przekonanie o kontroli nad rozproszoną infrastrukturą IT. Wszystko to działa do momentu poważnej awarii. Pracownicy IT, próbując określić przyczynę problemu, analizują miliony nieaktualnych, niepotrzebnych czy błędnych informacji pochodzących z wdrożonych narzędzi.

Zbombardowani alertami

Centrum dowodzenia ma pełne ręce roboty z odsiewaniem fałszywych alarmów. Wdrożeniowcy odpowiedzialni za narzędzia ciągle pracują nad aktualizacją i dostosowaniem dash boardów do często zmieniających się aplikacji lub wymagań na notyfikacje związane z problemami w aplikacji. Tak właśnie działa APM.

Narzędzia do diagnostyki lub monitorowania aplikacji mają znaczenie kluczowe. Dobre narzędzia są drogie – wymagają wielu badań laboratoryjnych, testów, precyzyjnego procesu produkcji. Z kolei dobre i drogie narzędzia są skomplikowane.

Na uwagę zasługuje fakt, że produkty te mają swoistą metodologię związaną z zarządzaniem wydajnością: instalujemy narzędzie, konfigurujemy zakres raportowanych metryk oraz budujemy skomplikowaną aplikację „wczesnego ostrzegania” o problemach występujących w monitorowanych aplikacjach. W praktyce system ostrzega nas o zaistniałym problemie – ale koszt obsługi, utrzymania i rozwoju aplikacji ostrzegającej jest często wyższy, niż zakładano.

Kokpity (dash boards) stały się, paradoksalnie, piętą achillesową tych narzędzi – każda monitorowana aplikacja musi mieć zestaw wielu hierarchicznych kokpitów, dla każdej prezentowanej na niej informacji powinny być określone parametry SLA umożliwiające zmianę „stanu zdrowia” – sygnalizowanego kolorem zielonym, żółtym czy czerwonym. Sygnalizacja ta nie jest jednoznaczna; nie wiadomo, czy chodzi o awarię systemu czy spowolnienie, czy rzecz dotyczy pojedynczej funkcji czy ich zbioru.

Narzędzia bombardują administratorów informacjami. Centrum dowodzenia ma pełne ręce roboty z odsiewaniem fałszywych alarmów od tych odpowiedzialnych za perturbacje w przetwarzaniu danych. Wdrożeniowcy odpowiedzialni za narzędzia ciągle pracują nad aktualizacją i dostosowaniem dash boardów do często zmieniających się aplikacji lub wymagań na notyfikacje związane z problemami w aplikacji.

Grzegorz Rymarski

Grzegorz Rymarski

Flopsar w UFG:

produkcyjne monitorowanie krytycznych aplikacji

Redukcja problemów produkcyjnych związanych z wydajnością aplikacji

Optymalizacja kodu – zmniejszenie czasów odpowiedzi

Redukcja wykorzystania infrastruktury sprzętowej

Jakie jest tempo uczenia się wnioskowania na podstawie wizualizacji flopsarowej?

„Gromadzimy miliony danych o polisach, kierowcach i zdarzeniach drogowych. Zapewnienie niezawodności oraz jakości działania systemów IT realizujących statutowe działania jest krytyczne. Wybraliśmy Flopsar Suite z uwagi na intuicyjność i funkcjonalność rozwiązania. Narzędzie zostało wdrożone w kilka godzin, a jego sprawna obsługa przez zespół administratorów rozpoczęła się natychmiast po wdrożeniu. Za wyborem rozwiązania Flopsar przemawiały także koszty, poziom obsługi posprzedażnej, elastyczność i oferta usług dodatkowych rozwiązań dostawcy. Dane pozyskiwane z monitorowania jednoznacznie wskazują, gdzie powstaje problem, a co za tym idzie, kto ponosi odpowiedzialność za jego obsługę czy naprawę. Dziś informacje pozyskane z oprogramowania Flopsar używamy w wielu przypadkach jako źródła argumentacji w rozmowach z naszymi dostawcami usług  IT” – mówi Grzegorz Rymarski, dyrektor Biura Informatyki, Ubezpieczeniowy Fundusz Gwarancyjny.

W poszukiwaniu intuicyjnego APM

W 2012 r. grupa programistów doświadczonych we wdrożeniach rozwiązań APM i ich administrowaniu powołała firmę. Jej celem było stworzenie rozwiązania pokonującego słabości i ograniczenia systemów monitorowania oraz podnoszenia wydajności aplikacji. „Punktem wyjścia do tworzenia systemu była pewna fundamentalna refleksja: Czy dane pochodzące z monitorowanych systemów, alerty i trendy muszą być przedstawiane w sposób wymagający dużych nakładów?” – mówi Grzegorz Pawluk, CTO i jeden ze współzałożycieli firmy Flopsar Technology.

Może da się pokazać w prosty, intuicyjny sposób, co jest najważniejsze dla służb IT:

  • że właśnie zdarzyła się awaria;
  • że użytkownicy mogą skarżyć się na nieefektywne działanie systemów;
  • że dostawca wdrożył źle napisaną aplikację, która nie może działać w obciążonym środowisku;
  • że aplikacja pochłania zbyt dużo mocy drogiego sprzętu.

Z tych zdroworozsądkowych założeń wywodzi się Flopsar (Flop Search and

Rescue). Twórcy Flopsar Suite zadali sobie jeszcze jedno pytanie: „Co tak naprawdę jest ważne w gąszczu informacji raportowanych z monitorowanego systemu?”. I sformułowali takie odpowiedzi:

  1. Proste wdrożenie, brak potrzeby zaawansowanej konfiguracji; Plug-and-play.
  2. Brak potrzeby treningu dla osób będących beneficjentami narzędzia.
  3. PROSTY, intuicyjny (najlepiej jedno okno) interfejs.
  4. Maksymalna produktywność. Aby wykryć problem i odnaleźć jego przyczynę, użytkownik nie może wykonać więcej niż trzech operacji.
  5. Żadnych „systemów wczesnego ostrzegania” opartych na pracochłonnym dewelopmencie.

Galaktyka Flopsar

Flopsar nie agreguje danych. Nie pokazuje średnich, median czy kwartyli. Przy niestabilnie działających systemach próbka jest zbyt duża, więc mało wiarygodna. Galaktyka pokazuje KAŻDĄ pojedynczą operację wykonaną w monitorowanym systemie. Każde wykonanie przelewu czy zalogowanie się do aplikacji pokazywane jest w postaci kropki, umiejscowionej w skali czasu zajścia zdarzenia (oś X) i skali czasu odpowiedzi (oś Y). Większość „prawidłowych” czasów (posiadających dostateczną jakość przetwarzania) koncentruje się w dolnych rejestrach galaktyki. Kropki tworzą w nich wielobarwną płaszczyznę. Jeżeli aplikacja lub jego funkcja ulega spowolnieniu lub awarii, kropki przenoszą się w górne rejestry galaktyki, tworząc różne wzorce skupień. To fakt występowania w aplikacji skupień jest podstawą do dalszych badań. Skupienia są automatycznie wykrywane przez system oparty na algorytmach sztucznej inteligencji albo można je manualnie zaznaczać w celu określenia przyczyn ich powstawania. Po zaznaczeniu użytkownik dostaje precyzyjną diagnozę, co i dlaczego nie działa w systemie prawidłowo.

Po kilku dniach pracy z systemem Flopsar zaczyna działać „Prawo inżyniera Mamonia”. Administrator na podstawie obserwowanych w przeszłości i zinterpretowanych skupień może stwierdzić: „znów odłączył się system kolejkowy”, „znów nie działa webserwice” albo wręcz zignorować wzorzec jako naturalny.

System obywa się bez konfiguracji – bez potrzeby budowania kokpitów, definiowania statycznego SLA dla wybranych metod, kosztownej pielęgnacji systemu. Po włączeniu systemu monitorowania serwer aplikacji przetwarza dane, na monitorze rysują się skupienia, a administrator szuka nienaturalnych i zaburzonych wzorców skupień.

Innowacyjne przez korzenność

Innowacja przejawia się w podejściu do projektu. Projekt Flopsar rozpoczął się od zaprojektowania infrastruktury: komunikatów, protokołów, silników, struktury danych, mechanizmów równoważenia obciążenia i obchodzenia awarii. Cała infrastruktura została zaprogramowana w języku C.

Czy „galaktyczny” sposób przedstawiania danych jest innowacyjny i unikalny? W statystce scatter-plot używany jest do wizualizacji danych. Grzegorz Pawluk tłumaczy: „Flopsar raportuje każdą transakcję osobno, wykonywaną w monitorowanym systemie. Wywołania łączy w ciągi wywołań (tzw. stack trace) i dopiero sumaryczny czas jej trwania raportuje jako punkt (przy pełnym dostępie do pozostałych danych). Wolumen danych, jaki trzeba zapisać w bazie monitoringowej, związany z tego typu obsługą, jest gigantyczny. Dlatego ‘sercem’ Flopsar, jest nie agent produkujący dane, nie aplikacja raportująca, ale infrastruktura bazy danych (persystencja danych)”.

Innowacja – a może przekornie: powrót do zdrowych korzeni – przejawia się w podejściu do projektu. Projekt Flopsar rozpoczął się od zaprojektowania infrastruktury: komunikatów, protokołów, silników, struktury danych, mechanizmów równoważenia obciążenia i obchodzenia awarii. Cała infrastruktura została zaprogramowana w języku C – najbardziej wydajnym języku programowania. Kod liczący ponad 5 000 000 linii został napisany od zera i w całości bez użycia obcych (np. OpenSource) bibliotek. Inżynierowie i wsparcie Flopsar odpowiadają za 100% rozwiązania. Testy i wdrożenia produkcyjne udowodniają, że Flopsar jest w stanie przetwarzać około 40 000 metryk na sekundę lub skumulowany load na poziomie 200 MB/sek na pojedynczej instancji bazy danych w trybie 24/7/365.

W 2013 r. Flopsar Technology jako jedyny dostawca oprogramowania APM wdrożył swoje rozwiązanie na ok. 100 produkcyjnych serwerach aplikacji na polskim rynku oraz przy współpracy ze strategicznymi partnerami biznesowymi zrealizował kilkadziesiąt projektów optymalizacji krytycznych systemów. Konkurencja notuje w tym czasie sprzedaż w Polsce pojedynczych licencji. Obecnie firma wraz z partnerami prowadzi kilka projektów typu Proof of Concept. „Szacujemy, że do końca 2014 r. liczba wdrożeń produkcyjnych przekroczy 300 monitorowanych serwerów aplikacji w systemach typu mission critical. To sprawi, że Flopsar Technology będzie niekwestionowanym liderem w branży monitoringu i zarządzania wydajnością krytycznych aplikacji opartych na serwerach Java” – mówi Grzegorz Pawluk. Ramki przedstawiają przykłady zastosowania Flopsar w UFG oraz w Grupie Generali – komentują top menedżerowie IT.

Michał Zaremba

Michał Zaremba

Grupa Generali:

produkcyjne monitorowanie systemu związanego z obsługą sprzedaży

Pełna detekcja problemów produkcyjnych (awarie, spowolnienia, błędy)

Pełna kontrola nad procesami dopuszczenia do ruchu wersji produkcyjnych systemów IT –wczesna detekcja problemów, sugestie dotyczące optymalizacji kodów aplikacji, konsultacje problemów architektonicznych i wydajnościowych

Refaktoring kodu – optymalizacja przetwarzania (wzrost wydajności)

Szacowanie zapotrzebowania na moc w okresach zwiększonego procesowania danych

Flopsar Suite – kto powinien zarządzać jakością i efektywnością?

Do niedawna Flopsar Suite w Grupie Generali służył jedynie do wczesnej detekcji problemów wydajnościowych w systemach produkcyjnych. Zajmował się tym zespół odpowiedzialny za monitoring systemów i usług IT. Podczas testów wydajnościowych programiści wykorzystywali go do wykrywania nieefektywnych metod i zapytań. Wraz ze zdobywaniem doświadczeń w obszarze wykorzystania Flopsar Suite wypracowany został inny, bardziej skuteczny model monitoringu wydajności aplikacji.

Gdy przyjrzymy się bliżej specyfice narzędzia, możemy zauważyć, że trudno jednoznacznie określić, czy jest to zaawansowany system monitoringu wydajności serwerów aplikacyjnych, czy też może system raportowy do analizy efektywności operacji wykonywanych w systemie IT. W pierwszym przypadku Flopsar może być odbierany jako kolejny system monitoringu wykorzystywany w działach utrzymaniowych, w drugim jako dodatkowy system wspierający rozwój aplikacji oraz etapy szeroko pojętej fazy przekazania usług z dewelopmentu do utrzymania. Musimy uświadomić sobie jednak, że w celu osiągnięcia wysokiej sprawności w dostarczaniu wartości naszym klientom konieczna jest bardzo głęboka synergia tych obszarów. To jednocześnie otwiera szerokie możliwości w zakresie optymalizacji procesów, dzięki eliminacji elementów niepotrzebnie wykorzystujących zasoby IT, które nie dostarczają wartości odbiorcom usług.

Transformacja struktury departamentu i przejście do działania w koncepcji Dev-

-Ops pozwoliła na zastosowanie Flopsar Suite w miejscu, w którym można w pełni wykorzystać jego możliwości – w zespole odpowiedzialnym za aplikacje i usługi IT – zarówno za rozwój, jak i działania operacyjne. Istotne jest to, że użycie systemu w obu obszarach jest bardzo zbliżone, nie wymaga zmiany stylu i trybu pracy zespole ani dodatkowych szkoleń.

Teoretycznie wnioskowanie i diagnoza we Flopsar są szybkie. Jak szybko i czy w ogóle udało się je przełożyć na optymalizację procesów i produktów IT?

Zastosowanie Flopsar pozwala na znaczne zwiększenie szybkości obsługi incydentów w środowisku produkcyjnym. Czas od powstania anomalii w działającym systemie do podjęcia akcji naprawczej przez zespół jest zredukowany niemal do zera. Dawniej subiektywna informacja użytkownika końcowego o niewydajnie działającym systemie musiała przejść szereg poziomów w organizacji IT. Teraz informacja ta widoczna jest dla specjalisty dokładnie w momencie, w którym użytkownik zaczyna odczuwać spowolnienie pracy systemu. Co prawda, użytkownik nadal zgłasza problemy do service desku, ale ten już wie o nieprawidłowym działaniu systemu i o podjęciu interwencji przez specjalistów. Znacznie skraca się czas niezbędny do rozwiązania incydentu dzięki możliwości odnalezienia problematycznej metody, serwisu czy zapytania w sposób szybki i intuicyjny.

Zoptymalizowane zostały również procesy rozwoju aplikacji i testów. Monitoring aplikacji w środowisku deweloperskim i testowym pozwala na wykrycie operacji, których czas wykonania nie jest akceptowalny.

Dzięki analizie liczby konkretnych wywołań w czasie jesteśmy w stanie zdefiniować wzorce aktywności biznesowej, a w konsekwencji we właściwy sposób realizować zarządzanie pojemnością, wydajnością i popytem usług IT. Właściwość ta pozwala również odpowiednio planować procesy zarządzania zmianą, w tym planowe wyłączenia systemów w celach maintenance.

Czy na podstawie wzorców i statystyk zapytań można pokusić się także o optymalizację innych procesów organizacyjnych, sposobów działania – czy może być źródłem innych innowacji?

Jeśli proces biznesowy realizowany jest w systemie IT, który analizowany jest przez Flopsar, wszystkie operacje wykonywane w systemie są rejestrowane i mogą być analizowane. Charakterystyczna wizualizacja danych pozwala na określenie, jakie czynności w ramach procesu biznesowego wykonywane są nieefektywnie.

Zazwyczaj proces biznesowy, który wykonywany jest w systemie IT, z punktu widzenia użytkownika biznesowego traktowany jest jako operacja mająca w nim swój początek i koniec. W rzeczywistości realizacja procesu obejmuje szereg operacji wychodzących poza ramy aplikacji, dotykając architektury integracyjnej, bazodanowej i innych systemów. W zaawansowanych systemach BPM monitoring aktywności biznesowej (BAM) jest dostępny i może być używany do optymalizacji procesów biznesowych. Jednak w sytuacji, gdy decydujemy się na produkcję własnych aplikacji metodami in-house development, powinniśmy dostarczyć również narzędzie monitoringu procesu biznesowego, który dana aplikacja wspiera. W sytuacji, w której nie decydujemy się na implementowanie tego typu funkcjonalności do produkowanej aplikacji, pomocne może być wnioskowanie na bazie danych, możliwych do uzyskania z systemu Flopsar.

Jak zmieniła się trafność prognoz zapotrzebowania na moc obliczeniową? Czy w ślad za tym udało się zoptymalizować wykorzystanie infrastruktury?

W obszarze optymalizacji infrastruktury pod kątem wydajności aplikacji Generali opiera się na aktywnościach w trzech filarach: monitoringu parametrów technicznych elementów infrastruktury (z wykorzystaniem protokołów SNMP, WMI itp.), optymalizacji równoważenia obciążenia, monitoringu wydajności aplikacji z wykorzystaniem Flopsar Suite.

Pierwszy i drugi filar są znane i stosowane w wielu organizacjach, dopiero badanie współzależności pomiędzy powyższymi trzema daje najlepszy obraz prognozowania mocy obliczeniowej. Jest to możliwe dzięki przełożeniu technicznych parametrów elementów infrastruktury na czas wykonania operacji w monitorowanej aplikacji.

Specyfika przygotowywanych w ostatnim okresie akcji marketingowych Generali wiązała się z tymczasowym kilkukrotnym zwiększeniem operacji w Merkury 2.0 – głównym systemie sprzedażowym wykorzystywanym przez Generali. Początkowo rozważaliśmy liniowe skalowanie elementów infrastruktury serwerowej. Podczas testów rozwiązania z wykorzystaniem Flopsar okazało się, że istnieje wiele innych aspektów, które mogą mieć znaczący wpływ na wydajność i mogą być zmodyfikowane w celu osiągnięcia wzrostu pojemności systemu. Zauważyliśmy, że standardowe techniki równoważenia obciążenia mogą wpływać niekorzystnie na czas przeprowadzenia operacji przez pojedynczego użytkownika. Warunkowanie loadbalancingu na bazie parametrów infrastruktury i systemu pozwoliły nam dostarczyć rozwiązanie, którego wydajność była taka sama dla każdego z użytkowników. Co ciekawe, przeprowadzone testy wykazały, że narzut Flopsar Suite na obciążenie środowisk nie przekracza poziomu 1–2%. Finalnie, po przeprowadzeniu szeregu optymalizacji, doszliśmy do stanu, w którym obsłużenie wzmożonego obciążenia systemu mogliśmy osiągnąć bez modyfikacji infrastruktury serwerowej. Po zakończeniu rzeczonej akcji marketingowej byliśmy w stanie zredukować infrastrukturę.

Jak wyglądała nauka nowego sposobu obserwacji efektywności sprzedaży, zwłaszcza umiejętności interpretacji wizualizacji rozkładów zdarzeń? Czy użytkownicy łatwo odnaleźli sposób  wnioskowania? 

Flopsar Suite jest pakietem intuicyjnym w obsłudze. System używany jest obecnie przez departament IT, ale poważnie rozważamy udostępnienie uzyskanych przez niego danych użytkownikom biznesowym, którzy na tej podstawie będą mogli optymalizować procesy biznesowe.

Trzeba jednak mieć na uwadze fakt, że użytkownicy biznesowi bardzo często wymagają do analizy danych liczbowych, a nie ich prezentacji graficznej. Flopsar, aby mógł być używany do analiz efektywności sprzedaży, warto byłoby wzbogacić o możliwość dostarczenia wyników w postaci liczbowej. Posługując się przykładem: dla departamentów odpowiedzialnych za sprzedaż istotne jest nie tylko to, jak wydajność systemu wpływa na sprzedaż produktów, ale również jak wygląda rozkład operacji wyszukiwania produktów w konkretnych godzinach, dniach miesiąca czy roku.

O nieskomplikowanej obsłudze systemu może świadczyć fakt, że Generali osiągnęło tak zaawansowany poziom wykorzystania narzędzia bez organizacji specjalistycznych szkoleń. Zauważyliśmy też, że kolejne optymalizacje wykorzystania narzędzia mogą być osiągnięte przez nabycie dodatkowej wiedzy z działania pakietu Flopsar zarówno w obszarze analizy, interpretacji wyników, jak też tworzenia rozszerzeń raportowych. Warto wspomnieć, że wszystkie dane gromadzone w bazie Flopsar dostępne są dla naszych programistów przez przeznaczone do tego celu API.

Czy złożoność procesów, czynników, jest ograniczeniem w metodzie wizualizacji wydajności aplikacji zaproponowanej przez Flopsar? Jeśli tak, jak można je obchodzić? 

Najprawdopodobniej każdy, kto zajmował się w swojej pracy optymalizacją wydajności systemów IT, spotkał się z problemem niepewności, czy w interwałach między pomiarami system zachowuje się tak jak w punktach pomiaru. To typowe dla systemów, w których wydajność mierzymy w ustalonych odstępach czasu. We Flopsar analizowana jest każda operacja w systemie. Jeśli nie zdecydowaliśmy się na filtrację konkretnych wywołań w tzw. „galaktyce“, każdy punkt prezentuje jedno z wywołań w systemie. Gdy wykonywane procesy charakteryzują się dużą złożonością, mamy sytuację, w której operujemy na znacznej liczbie geometrycznie skorelowanych punktów. Analiza danych wymaga w tym przypadku weryfikowania konkretnych wywołań spośród znacznie większej ilości wszystkich zmierzonych i zaprezentowanych. To może stanowić ograniczenie ze względu na szybkość analizy danych przez specjalistę. Może również negatywnie wpływać na obciążenie serwera aplikacyjnego pobieraniem danych przez Flopsar. Sytuacja zmienia się jednak w momencie, kiedy zastosujemy techniki wyłączenia konkretnych wywołań, które nie są obiektem naszego zainteresowania. Jest to możliwe z poziomu administracji systemem, co pozwala na przygotowanie monitoringu indywidualnie pod każdą aplikację. Innym sposobem redukcji danych, których nie chcemy analizować, jest możliwość filtracji minimalnych i maksymalnych czasów wykonania operacji w badanym systemie. Finalnie w systemach działających na wielu serwerach aplikacyjnych mamy możliwość zmiany kolorystyki prezentowanych punktów w zależności od serwera. Sądzę, że przydatną funkcjonalnością byłaby możliwość zdefiniowania kolorystyki punktów w inny, wybrany przez użytkownika sposób, np. koloru zależnego od typu wykonywanej operacji w systemie lub czasu jej wykonania.

Szczegółowe kwestie zmian związanych z wdrożeniem rozwiązania APM w Grupie Generali komentuje dla magazynu CIO Michał Zaremba, IT Infrastructure Project Manager w Departamencie Informatyki – Sekcji Wsparcia i Infrastruktury w Grupie Generali.