Webinar – Studium przypadku z Flowmon

Piotr Kałuża:

(…) Jeżeli mówimy o mierzeniu wydajności aplikacji, o dostępności tej aplikacji, to rozróżniamy oczywiście monitorowanie infrastruktury, gdzie sprawdzamy czy w komunikacji nie pojawiają się błędy, albo będziemy mierzyli aplikację za pomocą syntetycznego użytkownika. Syntetycznego, czyli takiego, gdzie to my tworzymy sztuczne zachowanie użytkownika/pracownika, sprawdzamy konkretny pomiar pewnych elementów, wiemy jak one powinny się zachowywać i sprawdzamy czy one cały czas odzwierciedlają się w wydajności naszego systemu. Możemy stosować pomiar takiej aplikacji za pomocą agenta instalowanego na serwerze, co jest rozwiązaniem ciekawym, aczkolwiek obarczonym pewnymi błędami o których będę mówił za chwilę. Analogicznie możemy monitorować na podstawie ruchu sieciowego, czyli wtedy kiedy widzimy kopię tego ruchu i pracujemy na danych, które za chwilę otrzyma rzeczywisty użytkownik. Widzimy w tym momencie kiedy dane rzeczywiście opuściły system, kiedy podążają do użytkownika tego systemu.

Agentowa czy bezagentowa analiza ruchu sieciowego? Patrząc na plusy i minusy instalacji agenta, musimy zastanowić się nad tym jaki system chcemy mierzyć. Nie każdy system będzie dało się mierzyć, dlatego że nie dla każdego systemu będzie agent. Aktualizacja takiej aplikacji może powodować również jakieś niekompatybilności agenta z systemem, co będzie później powodowało pewne problemy. Jest to też dodatkowy element, dodatkowa aplikacja w systemie, która może powodować problemy i wpływać negatywnie na wydajność serwera. Wdrożenie takiego agenta często będzie wiązało się z tym, że system trzeba zatrzymać, zainstalować agenta i zrestartować system. Będzie to wymagało jakiegoś okienka serwisowego i opóźniało cały proces wdrożenia.

Jeżeli monitorujemy ruch, to po stronie serwera nie musimy wdrażać żadnych dodatkowych prac, nie musimy nic dodatkowo robić. Co możemy tutaj uzyskać? Wpięcie się w komunikację sieciową, albo konfigurujemy jakiś SPAN port, albo wpinamy urządzenie typu TAP. W tym momencie w ciągu kilku minut jesteśmy w stanie zobaczyć kopię ruchu i pasywnie, nie obciążając serwera i ruchu sieciowego – bo pracujemy na kopii ruchu więc na sam ruch nie wpływamy już w żaden sposób – jesteśmy w stanie monitorować wydajność tej aplikacji.

W przypadku porównania metody agentowej i bezagentowej, jeżeli sam serwer będzie bardzo obciążony, to może okazać się, że nawet dane dostarczane przez tego agenta będą obarczone pewnym błędem, dlatego że agent nie będzie działał z pełną wydajnością i może nam wysłać niekompletne dane. Kiedy pracujemy już na kopii ruchu, to odcinamy się od warstwy sprzętowej tego serwera, wiemy że pakiety, które do nas trafiają, są tymi które opuściły system, więc uniezależniamy się od jakości czy problemów technicznych z infrastrukturą, kartą sieciową, z jej sterownikiem.

Paweł Deyk:

Jeśli chodzi o narzędzia do monitorowania aplikacji, to mamy tutaj cały wachlarz takich rozwiązań Różnią się one przede wszystkim tym co dokładnie mierzą. Jest dużo rozwiązań na rynku, które obsługują monitorowanie samej infrastruktury i jest to jak najbardziej narzędzie, które warto mieć i które w żaden sposób nie wyklucza użycia innych narzędzi. Flowmon APM zajmuje się przede wszystkim monitorowaniem aplikacji i sprawdzaniem jak dużo operacji mieści się w zakładanym SLA. Mierzonych jest kilka ważnych parametrów istotnych dla działania aplikacji. Co więcej jest jeszcze dodatkowy moduł, który uzupełnia pewną lukę związaną z generowanym ruchem automatycznym. Jest tutaj moduł Traffic Generator, który jest darmowym narzędziem umożliwiającym wzbogacenie testów o formę generowania sztucznego ruchu. W jaki sposób będziemy to generować? Przede wszystkim będziemy zbierać statystyki ruchu sieciowego i flowy za pomocą sondy. Później kolektor będzie przechowywał te informacje. Mamy tutaj również do czynienia z pozostałymi modułami Flowmona. Możemy razem z APM współgrać wgrywanie anomalii i nagrywanie ruchu sieciowego, po to by przeanalizować go jeszcze bardziej szczegółowo, a także chronić infrastrukturę i serwery przed atakami DDoS. Jeśli chodzi o monitorowanie ruchu, przechowywanie statystyk i zaawansowaną analizę, to wszystko to możemy też zrobić na platformach wirtualnych. Mamy tutaj cały szereg rozwiązań, które są kompatybilne z Flowmonem.

Jak to wygląda z punktu widzenia użytkownika? Przede wszystkim otrzymujemy bardzo jasne informacje jak działa sama aplikacja, czyli jak widzą ją użytkownicy. Czy działa ona szybko, czy pracując nie ma się poczucia że coś spowalnia jej działanie, że coś nie działa tak jak powinno lub np. bardzo długo czeka się na wynik jakiejś operacji. Co więcej, możemy szybko zidentyfikować gdzie leży główna przyczyna problemu z wydajnością, bo nie jest to wcale takie oczywiste. Mamy szereg czynników, które na to wpływają. Co więcej, jesteśmy też w stanie zdiagnozować konkretnie którzy użytkownicy i w których konkretnych modułach, odczuwają takie problemy. Bardzo często jest tak, że część użytkowników skarży się na problemy, a druga część mówi że wszystko działa jak należy. Wykorzystanie tego modułu jest bardzo szerokie, bo każda firma która posiada/utrzymuje aplikacje wewnętrzne lub udostępnione na zewnątrz, na pewno jest zainteresowana tym by monitorować jak to wszystko działa. W tym także jest to główne zadanie administratorów aplikacji.

Jeśli chodzi o to jak działa monitorowanie i co możemy monitorować, to mamy tutaj co czynienia głównie z aplikacjami webowymi i bazodanowymi. Możemy tutaj monitorować zarówno aplikacje HTTP jak i wykorzystujące reguły szyfrowania przez HTTPS. Bezagentowy moduł jest w pełni transparentny i nie zakłócający pracy w żaden sposób. Działa w warstwie aplikacji i główne metryki które stosuje to APM Index, która wyraża ogólną wydajność aplikacji i jeszcze dwa ważne parametry –  Server Response Time i Transport Time, które pozwalają rozróżnić po której stronie leży problem. Możemy również monitorować trendy jak użytkownicy korzystają z różnych aplikacji.

Piotr:

Jak działa moduł Flowmon APM? Architektura całego systemu opiera się na monitorowaniu ruchu za pomocą protokołu Netflow. Jest to ruch dostarczany z już istniejących urządzeń sieciowych takich jak switche, routery i firewalle. Dane te są dostarczane do kolektora gdzie są później analizowane. Bardzo często jest tak, że dane te są niepoprawne, niekompletne i wtedy wykorzystujemy sondę, która na podstawie kopii ruchu będzie nam dostarczała taki wzbogacony Netflow – mówimy tutaj o protokole IPFIX – i będzie to ruch wzbogacony o dane pochodzące z warstwy 7.

Mając już sondę, która zobaczy również kopię ruchu aplikacyjnego, jesteśmy w stanie w IPFIX-ie przekazywać dodatkowe informacje o samych transakcjach i ruchu bazodanowym, które widzi sonda. Informacje te trafiają następnie do modułu Application Performance Monitor, gdzie są zbierane, korelowane i wyświetlane w postaci różnego rodzaju statystyk, wykresów i raportów, które pokazują nam jak wygląda wydajność aplikacji. Jak wygląda taki pomiar? Jeżeli użytkownik wysyła zapytanie do serwera, to mierzymy tutaj opóźnienie wprowadzone przez sieć oraz opóźnienie wprowadzone przez aplikacje. Na tej podstawie jesteśmy w stanie zobaczyć, które transakcje w systemie są najwolniejsze i które powodują największe opóźnienia po stronie naszego serwera. Widzimy więc jak wygląda opóźnienie sieciowe i tutaj zbieramy szereg potrzebnych nam informacji. Jeżeli aplikacja komunikuje się dalej z jakimś serwerem bazodanowym, to tutaj możemy również zobaczyć opóźnienia, które pojawiają się w tej komunikacji. To że dla użytkownika aplikacja działa wolno, nie zawsze wynika z tego że serwis aplikacyjny działa wolno. Być może komunikacja pomiędzy serwerem aplikacyjnym, a serwerem bazodanowym działa wolno i stąd właśnie pojawiają się problemy w ruchu sieciowym w tej komunikacji. Dlatego tutaj również mierzymy opóźnienia po stronie komunikacji aplikacja-baza danych i tutaj również jesteśmy w stanie korelować te informacje i zobaczyć, które transakcje webowe, powodują transakcje bazodanowe. Jesteśmy w stanie to pomierzyć, korzystając z kopii całego ruchu, dzięki czemu nie ingerujemy w rzeczywisty ruch, a jesteśmy w stanie wszystko pomierzyć, bo widzimy po prostu całą tę komunikację. Sonda po przechwyceniu komunikacji obrabia to i w postaci metryk wysyła do kolektora, który będzie nam dalej te informacje wizualizował.

Jakie metryki jesteśmy w stanie zbierać, jeżeli chodzi o monitorowanie aplikacji? Przede wszystkim liczbę transakcji, czyli widzimy ile tych transakcji było sumarycznie, ale jesteśmy w stanie również przypisać je do konkretnych użytkowników. Widzimy też ile każdy z użytkowników pracuje, ile każdy z nich wywołał transakcji, jak również widzimy ilu użytkowników równolegle pracuje na tym systemie. Jesteśmy w stanie zobaczyć minimalny, maksymalny i średni czas odpowiedzi aplikacji. Widzimy czas transmisji danych. Jesteśmy w stanie zobaczyć jak zachowuje się aplikacja w odniesieniu do pewnych standardów, które przyjęliśmy. Przyjmujemy tutaj taki parametr jak SLA, czyli szybkość odpowiedzi naszej aplikacji. Widzimy czy wszystkie transakcje mieszczą się w tym SLA. Wtedy nasz APM Index będzie wyższy i będzie wynosił 100. Jeżeli któreś z transakcji nie mieszczą się w zakładanym przez nas czasie SLA, to w tym momencie w zależności od tego ile tych transakcji jest, o ile ten czas jest przekroczony, tak nasz APM Index będzie spadał i przyjmował coraz mniejsze wartości. Jesteśmy w stanie zobaczyć tutaj również szczegóły pojedynczej transakcji, czyli jesteśmy w stanie zejść bardzo głęboko, aż do pojedynczego połączenia/wywołania w naszej aplikacji. Zobaczymy kto i z jakiego adresu IP i ile danych przesłał, ile danych odebrał, co było w zapytaniu i wiele szczegółów o których opowiem więcej w części prezentacyjnej.

Paweł:

To co każdy z użytkowników ma do dyspozycji to dashboardy, które w jednym centralnym punkcie pokazują wszystkie skonfigurowane wcześniej wizualizacje. Możemy sobie dla każdego z modułów naszej aplikacji przygotować osobny dashboard, który będzie pokazywał nam różne parametry na których nam zależy. Możemy osobno pokazać moduł logowania, moduł koszyka zakupów, lub inne moduły które mamy w swojej aplikacji, czy opóźnienia, które wprowadzają różnią się od siebie czy są zależne od tego jak dobrze napisany jest każdy z tych modułów. Możemy dowolnie konfigurować te dashboardy, zmieniając zakresy w których występowały informacje, a także sprawdzając jak wiele z tych transakcji przekraczało SLA ustalone wcześniej w umowie z klientem. Takie SLA możemy wprowadzić w systemie i dzięki temu widzimy, która transakcja wprowadzała opóźnienie przekraczające poziom SLA np. dwukrotnie lub trzykrotnie. Dodatkowo mamy raportowanie związane z błędami, które generowała aplikacja. Mamy tutaj zarówno kody poszczególnych błędów, jak i dodatkowe informacje kiedy wystąpiły, kto wywołał ten błąd i jakie były pozostałe parametry.

Taką listę możemy sobie wygenerować i weryfikować jak często występują dane typy błędów bądź też które konkretne błędy pojawiają się dla większej liczby użytkowników, bo to nimi należy zająć się w pierwszej kolejności. Dodatkowo każdą z tych transakcji można szczegółowo zweryfikować, zobaczyć konkretne adresy IP, porty i wszelkie inne niezbędne informacje, m.in. z jakiej przeglądarki korzystał użytkownik lub identyfikatory plików cookie.

Piotr:

Takie same informacje możemy zobaczyć dla transakcji bazodanowych, gdzie zobaczymy jaki był tutaj Select. Zobaczymy pełną treść zapytania SQL-owego, czy jest generowane poprawnie, czy nie pobiera zbyt dużo informacji w stosunku do tego co później wyświetlamy w naszej aplikacji. Czy nie jest tutaj tak, że pobieramy całą tabelę, a wyświetlamy tylko pierwszych dziesięć rekordów z tabeli. Warto też tutaj zwrócić uwagę jak wygląda wydajność tej aplikacji bazodanowej. Zarówno dla pojedynczej transakcji webowej jak i bazodanowej, jesteśmy w stanie zejść bardzo nisko ze szczegółami i monitorować sobie te transakcje.

Jakie w ogóle systemy i aplikacje jesteśmy w stanie monitorować? Oczywiście po stronie webowej jesteśmy w stanie monitorować aplikacje HTTP, również te które są zaszyfrowane za pomocą SSL-a, TLS-a. Trzeba tutaj przede wszystkim zwrócić uwagę na to, jaki algorytm szyfrowania jest wykorzystywany i trzeba dostarczyć tutaj klucz deszyfrujący do systemu, żeby tę kopię ruchu można było zdeszyfrować, zajrzeć w głąb transmisji i dzięki temu znaleźć poszczególne transakcje. Jeżeli chodzi o systemy bazodanowe to mamy tutaj praktycznie te najpopularniejsze, oparte o język SQL, czyli Microsoft SQL Server, Oracle, PostgreSQL, MySQL i MariaDB w zależności od tego czy jest to rozwiązanie komercyjne czy darmowe. Jesteśmy w stanie monitorować te aplikacje i zaglądać w szczegóły transakcji. To co jest jeszcze bardzo istotne, to że mamy możliwość korelowania tych transakcji, czyli możemy zobaczyć jak wywołanie użytkownika w serwerze webowym wpływa na konsekwencje, jeżeli chodzi o transakcje w systemie bazodanowym. Zobaczymy tutaj, że kliknięcie w ten jeden element na naszej stronie, generuje kilka zapytań bazodanowych, jakie one są, co jest przesyłane w tej komunikacji.

Mamy tutaj przykład takiej korelacji, gdzie widzimy że zapytanie HTTP generuje kilka zapytań SQL-owych. Pod spodem widzimy opóźnienie części webowej, które wynika z tego, że wśród tych transakcji bazodanowych jest jedna, która trwa bardzo długo i przesyła bardzo dużo danych. Wpływa to naprawdę negatywnie na wydajność całego naszego systemu. Jeżeli chodzi o wdrożenie systemu, to jest ono bardzo proste i odbywa się dosłownie w trzech krokach. Pierwszym z nich jest konfiguracja sondy w taki sposób, żebyśmy wskazali która z sond widzi kopię tego ruchu, na którym interfejsie sieciowym. Następnie wskazujemy serwer, który chcemy monitorować. Wybieramy tutaj adres IP serwera aplikacyjnego lub bazodanowego i wskazujemy jaki to będzie protokół użyty do monitorowania tej aplikacji. Jeżeli jest to komunikacja szyfrowana, to musimy jeszcze wgrać klucz do zdeszyfrowania tego ruchu. Ostatnim krokiem jest zdefiniowanie samej aplikacji. Definiujemy sobie jak nasza aplikacja będzie się nazywała, jak będziemy rozpoznawali tę aplikację, dlatego że na jednym serwerze może działać kilka aplikacji i każda z nich będzie się czymś wyróżniała. Będzie albo jakiś host name, albo fragment adresu URL, jakiś podkatalog całej tej naszej aplikacji. Definiujemy sobie tutaj jak chcielibyśmy rozróżnić naszą aplikację, definiujemy ten nasz SLA, czyli czas po jakim spodziewamy się odpowiedzi naszego systemu i po przejściu takiego trzykrokowego kreatora, dochodzimy właśnie do aplikacji i do możliwości monitorowania tego ruchu.

Mamy również oczywiście możliwość użycia tego syntetycznego użytkownika do tego by stworzyć sobie taką wzorcową transakcję i sprawdzać jak ona się zachowuje wtedy, kiedy system jest mniej lub bardziej obciążony. Możemy sobie to korelować w długiej perspektywie czasu, dzięki czemu widzimy że np. miesiąc temu czy pół roku temu nasz system działał szybciej niż działa w tej chwili. Możemy sobie określić tutaj jaki jest dla nas ten krytyczny próg, przy którym stwierdzimy że aplikacja jest po prostu mało wydajna. To co jest bardzo istotne, to że Transaction Generator jest modułem darmowym. Symuluje on zachowanie użytkownika, czyli definiujemy po prostu jaka transakcja ma być wywołana. Jeżeli w ramach tej transakcji potrzebne jest podanie jakichś dodatkowych informacji, wypełnienie jakiegoś formularza, to oczywiście możemy to też zdefiniować i w tym momencie wszystkie te pola będą przez takiego syntetycznego użytkownika wypełnione. Dzięki temu będziemy w stanie zmierzyć również czas odpowiedzi na wypełniony formularz/kwestionariusz na naszej stronie. Taki sposób monitorowania jest najbardziej zbliżony do pracy zwykłego użytkownika. Transaction Generator jest modułem darmowym i częścią modułu APM. Działa on z wykorzystaniem przygotowanych przez nas scenariuszy testujących, które będą uruchamiane zgodnie z harmonogramem i będą nam mierzyły czas odpowiedzi i korelowały go z naszym czasem SLA, który założyliśmy jako wzorcowy czas naszej aplikacji. Wszystko oczywiście wyświetli się nam w postaci raportu pokazującego wydajność bądź spadek wydajności naszego systemu.

Paweł:

Zgodnie z obietnicą przejdziemy teraz do przykładów wziętych z życia, z opowieści naszych klientów. Jednym z takich klientów, który zastosował moduł APM jest wspomniany na slajdzie operator aplikacji VITAKARTA ONLINE. Aplikacja ta służy do obsługi pacjentów. Jak to na co dzień w życiu administratora bywa, otrzymuje on jakąś ilość skarg od użytkowników o spadku wydajności. Niektórzy użytkownicy mogą częściowo korzystać z aplikacji, a niektórzy w ogóle są z niej wyrzuceni z powodu różnych błędów. Co w tej sytuacji możemy zrobić? Przede wszystkim po wdrożeniu modułu APM, musimy przyjrzeć się informacjom związanym z opóźnieniami, które wprowadzają poszczególne elementy systemu. Takimi statystykami na których warto się tutaj skupić, jest różnica między średnim czasem transakcji, a medianą. I tutaj widać, że jest pewien problem, bo dla 5% wszystkich transakcji operacja trwa dłużej niż 7 sekund. Widzimy to właśnie w tym zestawieniu. Co w takim razie należy zrobić? Jeśli są tak duże opóźnienia, to znaczy że gdzieś musi być jakieś wąskie gardło. W momencie kiedy 5% transakcji generuje problemy, to jest kwestia którą trzeba jak najszybciej naprawić. Głęboka analiza polega właśnie na tym, że szukamy tego wąskiego gardła i sprawdzamy które błędy pojawiają się najczęściej. Możemy przeanalizować poszczególne elementy i komponenty aplikacji, którą się opiekujemy. Dokonał więc takiej analizy, że w część związanej z profilem klienta, gdzie definiowane są pewne dane, wygląda na to że na dashboardach zdecydowana większość transakcji mieściła się w zakładanym SLA. Szukamy więc dalej przyczyny problemu. Okazało się, że w module „dziennik”, co na dashboardzie widać bardzo wyraźnie, połowa transakcji ma przekroczone SLA, wykres jest czerwono-zielony, więc należy skupić się przede wszystkim na tym module. Jest to możliwe dzięki temu, że poszczególne kody błędów można przeanalizować dla każdej z transakcji. Pytanie na czym się skupić? Możemy wygenerować listę wszystkich transakcji, wraz z informacjami o tym jaki był średni czas odpowiedzi i ile tych transakcji dla danego modułu było zrealizowanych. Pozwala to skupić się najpierw na rozwiązaniu tych problemów, które są najpopularniejsze i które dotykają największej liczby użytkowników.

Piotr:

Kolejny przykład pochodzi z naszego podwórka. Mieliśmy do monitorowania aplikację do zarządzania obiegiem dokumentów. Nie jest to sytuacja, która wystąpiła u jednego z naszych klientów. Klienta referencyjnego, który od dłuższego czasu korzystał już z naszego systemu i chciał zobaczyć jak wygląda możliwość monitorowania obiegu dokumentów. Po konsultacjach, zdecydowaliśmy się na uruchomienie modułu APM u tego klienta. Tutaj to było łatwe, dlatego że mieliśmy już wdrożony system i tylko na testy rozszerzyliśmy licencję dla naszego systemu, aby sprawdzić jak aplikacja się zachowuje. Po wdrożeniu systemu, pierwsze co rzuciło nam się w oczy to niski APM index, który zaskoczył nawet samego administratora. Nie spodziewał się, że aplikacja działa aż tak słabo. Zaczęliśmy drążyć z czym to jest związane i przeglądać transakcje, które były najwolniejsze. Okazało się, że naszą aplikację trzeba nieco inaczej zdefiniować, ponieważ okazało się że aplikacja składa się z kilku części. Mieliśmy tutaj część związaną z typowym interfejsem użytkownika, gdzie użytkownik po prostu klika, wprowadza jakieś dane, pobiera dokumenty i to działa nawet całkiem dobrze. Ale jest też część związana z raportowaniem, która działa wolno. Wiadomo, że jak generujemy jakiś raport, to nastawiamy się, że ten raport będzie się chwilę generował. W związku z czym na podstawie fragmentu adresu URL, zdecydowaliśmy się na podzielenie aplikacji na dwie części, czyli na ten interfejs użytkownika i na część związaną z raportami. W części interfejsu użytkownika, zostawiliśmy nasze SLA zgodnie z wcześniejszym założeniem. W raportach zwiększyliśmy go do uznanego przez nas za akceptowalny czas na wygenerowanie raportu. Po takim podzieleniu aplikacji okazało się, że APM index nie wynosił jeszcze 100, ale był już bardzo wysoki, ponad 96 punktów, także całkiem dobry wynik. Widzieliśmy tu także wszystkie transakcje, oraz ich średni, minimalny i maksymalny czas, więc mieliśmy tutaj wszystkie statystyki. Tamte testy zakończyły się taką informacją, że do samego monitorowania aplikacji można APM używać, ale to nie jest tak kluczowe, bo sama aplikacja wydaje się działać dobrze.

Na początku tego roku okazało się, że aktualizacja tej aplikacji, spowodowała sporo problemów i że nastąpił bardzo duży spadek wydajności samej aplikacji. Wtedy firma, która aplikację tworzyła, odpowiedziała standardowo, czyli że problemem jest zbyt słaby sprzęt na którym aplikacja działa albo pojawiają się problemy z siecią i to one generują nam problem, powodując że aplikacja działa wolniej. Przystąpiliśmy wtedy jeszcze raz do krótkiego sprawdzenia jak aplikacja się zachowuje. Ponownie  wgraliśmy testową licencję na moduł APM i co się okazało? Okazało się, że mamy niezmienioną wydajność naszego systemu jeżeli chodzi o APM index. Był on cały czas taki sam, niezależnie od tego ile transakcji było w systemie generowanych. Widać to na powyższym slajdzie. Czerwony wykres to liczba transakcji, a niebieski to APM. Widać, że nawet jeżeli tych transakcji jest kilka razy więcej, to tak naprawdę APM index utrzymuje się na tym samym poziomie. Znaleźliśmy jednak kilkanaście lub kilkadziesiąt transakcji, które zawsze, niezależnie od tego czy pracował tam jeden użytkownik czy wielu użytkowników, niezależnie od tego ile transakcji w tym czasie było generowanych, one zawsze zajmowały nam bardzo dużo czasu i to jednoznacznie wskazywało na problemy z aplikacją, a konkretnie z tymi transakcjami. Do firmy, która tworzy system, zostały dostarczone także niezbite dowody na to gdzie jest problem w aplikacji. Skończyło się to tym, że firma napisała aktualizację do systemu, a klient aby uniknąć takich sytuacji w przyszłości, zakupił jednak Flowmon APM do by móc stale monitorować aplikację i wiedzieć co się w niej dzieje. Jest to nasz klient referencyjny, ale nie mamy jeszcze referencji na samego APM-a. Jeżeli tylko pojawi się taka zgoda, to będziemy mogli udzielić dokładniejszych informacji co to za klient i jak poradziliśmy sobie u niego z tą konkretną aplikacją.

Mamy jeszcze kilku klientów referencyjnych, którzy z systemu korzystają. Są to przede wszystkim firmy zagraniczne. Za chwilę pojawi się tutaj również polska firma, która korzysta z systemu. Nie wszyscy godzą się jednak na zostanie klientem referencyjnym, bo to ujawnia posiadane przez firmy rozwiązania. Nie wszyscy chcą się na to zgodzić i takich informacji udzielać.

Paweł:

To na co warto zwrócić uwagę, to że są to bardzo różnorodni klienci, posiadający różne aplikacje, zarówno do utrzymywania sklepów, jak również do systemów wewnętrznych istotnych z punktu widzenia ich działalności. Powinniśmy skupić się przede wszystkim na tych korzyściach, które daje wdrożone rozwiązanie APM do monitorowania aplikacji. Dzięki niemu mamy przede wszystkim cały czas rękę na pulsie i wiemy jakie są wrażenia użytkowników. Co więcej, możemy sprawdzić który konkretny moduł generuje pożądany poziom satysfakcji. Bazujemy na analizie kopii ruchu, więc nie wpływamy w żaden sposób na to jak działa w danym momencie infrastruktura, urządzenia sieciowe na konfigurację. Działa to również bezagentowo i jest to kolejnym plusem, bo nie musimy się martwić o to jaki konkretny system w tym momencie działa w naszej sieci. Nie musimy go zmieniać w przypadku aktualizacji lub zmiany technologii w której działają nasze aplikacje. Rozróżniamy opóźnienia sieci i aplikacji, co jest istotne w przypadku pewnych konfliktów między działami IT, a działami sieciowymi, które w przypadku problemów zawsze się pojawiają. Możemy zastosować APM w zasadzie dla każdej aplikacji webowej i bazodanowej. Ta elastyczność jest bardzo dużą zaletą.

Demo

Piotr:

Przejdźmy do prezentacji naszego systemu. Mam tutaj odpalony interfejs naszego demo. Gdyby ktoś chciał sobie tutaj zajrzeć, to demoflowmon.com, login: demo, hasło: demo. Można się zalogować i samemu zobaczyć jak ten interfejs działa. Ja tutaj mam ten najbardziej ogólny widok, czyli widzę aplikacje, które monitoruję. Mam tutaj szereg wykresów.

Powiedzmy, że chciałbym zobaczyć jak wygląda wydajność aplikacji. Mam tutaj wydajność części webowej jakiegoś sklepu internetowego, więc klikam sobie w to okno i w tym momencie mogę zobaczyć jak wyglądają statystyki. Te statystyki będę analizował z okresu ostatnich 12 godzin. Mogę sobie oczywiście ten czas zmienić. Widzę, że w tym czasie system APM index nie wynosi 100, tylko 54,7, czyli mniej więcej 50% transakcji mieści się w tym czasie SLA, ale spora część transakcji ma ten czas znacznie przekroczony. To co widać na tym wykresie, to jak liczba transakcji wpływa na wydajność naszego systemu. Widzimy tutaj statystykę ile transakcji zostało w ciągu tych 12 godzin wywołanych, ile danych było przesłanych, jaki być średni, minimalny i maksymalny czas odpowiedzi. Oczywiście widok ten można sobie rozszerzać, zaglądać do większej liczby statystyk. Mamy tutaj również informacje o tym ilu równolegle użytkowników korzysta z naszego systemu. W tym momencie jest to jeden użytkownik, bo jest to demo, ale normalnie widzimy ilu jest użytkowników, a więc też ile osób realnie korzysta z naszego systemu. Rozpoznawanie użytkownika może odbywać się po wielu parametrach. Może to być adres IP, jakiś login przekazywany w URL-u, w pliku cookie. Możliwości tutaj jest naprawdę całkiem sporo. Widzimy najwolniejsze transakcje i tutaj szybko możemy się przyjrzeć czy np. to że jakaś transakcja jest bardzo wolna, przekłada się na wydajność samej aplikacji. Bardzo często jest tak, że widzimy że jakaś liczba monitorowanych transakcji wynosiła kilkadziesiąt czy kilkaset tysięcy APM. Top 5 najwolniejszych transakcji to kilka, kilkanaście takich wywołań. Wiemy że i tak te transakcje nie będą wpływały na ogólne wrażenia użytkownika z pracy całego systemu. Niemniej możemy sobie przejrzeć poszczególne transakcje. Mamy tutaj zagregowane dane po tym, jaką transakcję chcemy monitorować, czyli widzimy tu że jakaś transakcja jest wpisana jako Credits, została wywołana 15 razy, jaki był jej średni czas odpowiedzi i jaki jest dla niej wyliczony APM index. Widzimy kiedy po raz pierwszy i kiedy po raz ostatni w tym przedziale 12 godzin widzieliśmy tę transakcję. Możemy oczywiście zejść bardziej szczegółowo i zobaczyć sobie transakcje w ujęciu poszczególnych wywołań. Tutaj mogę sobie za pomocą filtra wyświetlić te transakcje, które będą mnie interesowały i będę widział host, czyli adres IP z którego to wywołanie się pojawiło. Będę widział też adres URL jaki był za każdym razem wywoływany. User agent, czyli zobaczę jaka to była przeglądarka, czy transakcja zakończyła się sukcesem, czy pojawiły się tutaj jakieś problemy. Będę widział te wszystkie informacje. Mogę również kliknąć sobie w taką transakcję i zobaczyć więcej szczegółów. Widzę tutaj jaka metoda została użyta, jaka była ścieżka, jaki był URL. Będę widział np. zawartość pliku cookie, więc jeżeli potem chcemy sobie zrobić jakieś filtry, to jak najbardziej te parametry mogę użyć w filtrowaniu tego ruchu. Widzę, że status tej transakcji to był kod 200, czyli wszystko przebiegło tutaj poprawnie. Widzę również jakie transakcje bazodanowe były wywołane przez tę transakcję webową. Widzę także szereg informacji, których mogę dalej używać. Jeżeli kliknę sobie w taką transakcję, to znowu zobaczę szczegóły, zobaczę pełną treść tego zapytania SQL-owego, dużo szczegółów które będą dostarczane wraz z systemem do tego, by skutecznie monitorować naszą aplikację, by dostarczyć tutaj szeregu informacji do twórców aplikacji, czyli jeżeli jesteśmy twórcami aplikacji, to żeby sprawdzić sobie jak ta nasza aplikacja działa i dzięki temu dostarczyć aplikację jeszcze lepszej jakości. Oczywiście nasze widoki będą zawierały dużo więcej informacji, np. jakie błędy się pojawiały i kiedy te błędy w działaniu aplikacji pojawiały się u nas. Będziemy również w stanie zobaczyć jak w czasie przekłada się przekroczenie tego czasu SLA, czasu który sobie założyliśmy jako ten akceptowalny czas odpowiedzi naszej aplikacji. Jak widać wiele z tych informacji jest dostarczonych w formie wykresów i czytelnych tabel, które możemy sobie dalej filtrować i z których możemy sobie generować raport i np. wysyłać cyklicznie taki raport na maila czy wysyłać jakieś sprawozdania jak działała nasza aplikacja. Możliwości jest tutaj bardzo dużo. Sam system po wstępnym skonfigurowaniu, wymaga później już bardziej obsługi i przeglądania tych danych, niż jakiejś mocnej pracy. Nie wymaga więc zbyt dużych nakładów administracyjnych na utrzymanie takiego systemu.