Flopsar Suite

Po co to czytać? Z oczywistych powodów, ci co są zainteresowani, chcą wiedzieć jak najwięcej o tym za co będą płacić - bo będą i to sporo (choć czy dużo, to względne). Jest teraz taki zwyczaj, że najwięcej to się pisze o tym co jest złe. Mówię teraz o pisaniu opinii o jakimś produkcie. Ci co się przejechali chcą w ten sposób odreagować (tak sobie myślę). Robią przez to taką kampanie negatywną, jako zemstę. Jak już się dobrze pisze, to tak dużo w tym marketingu, że nie wiadomo czy to jest prawdą. Ci którym coś się sprawdziło to dają sobie spokój. Szkoda czasu. Trudno w takich warunkach o decyzję, bo aby ją podjąć trzeba mieć czym się kierować. Zaufanie nam tu pewnie nie wystarczy.

Ja opowiem historię, bo lubię opowiadać takie historie ... z happy endem. Nie Flopsar jest tu głównym aktorem - a nasz system. Nie napiszę bezpośrednio opinii o samym Flopsar Suite. Czemu? Nikt mi za to nie zapłacił. Czy warto o nim pisać? A może nawet - czy mogę pisać na ten temat! Tak zastanawiałem się bo to w końcu mój czas. Jednak napiszę bo pewien incydent związany z Flopsar był przyczyną sporej ilości zmian w moim wypadku. Czy sam Flopsar dał mi jakieś korzyści? Czy załatwił mój problem? I czy w ogóle ja miałem jakiś problem? To są pytania pomocnicze.
Tak naprawdę to piszę to, bo chcę pokazać że dałem radę.
Piszę też dlatego że irytuje mnie ta forma marketingu której doświadczam.
Zabiegi instytucji odpowiedzialnych za marketing dziś są tak nachalne, że bardziej przypominają wojnę, niż ofertę - propozycję. To moja subiektywna opinia. Może nie wszyscy tak postrzegają...

Zobacz sam http://flopsar.com/
Na dziś to raczej nie jest duża firma, ale to nie ma dużego znaczenia.

Jednak trochę krytycznie

Samemu nie musiałem szukać. Sami mnie znaleźli. Gdy już się skontaktowali obejrzałem ich stronkę. Taka reklamówka całkiem kolorowa - jak dla mnie - taka amerykańska (byłem to wiem), mało szczegółów - ładne opakowanie (choć to względne), na tle innych takich systemów do monitorowania. Ale czy to złe? Nie dowiesz się za wiele dopóki nie zgłosisz się do producenta. Sam osobiście się tam nie zgłosiłem, to mnie znaleźli, mnie nie zależało na tym aby to kupić. Dziwnie może się potoczyć koło fortuny. Potem okazało się że miałem okazję tego użyć. I przyznaje pomysł dobry systemu jest dobry. Nie jest innowacyjny. Podobne rozwiązania już były. Ważne to że wykonanie jest wystarczające do tego co ma zrobić. Napiszę, bardziej od siebie niż na życzenie, bo niestety mam takie wrażenie gdy o tym gdzieś czytam, a nie ma tego za wiele oprócz satysfakcji odkrycia czegoś.
Nasuwa mi się jedna opinia. To nie jest świat open source. To nie jest dla wszystkich. To komercja. Nawet nie ma też wzmianki o cenie. Bo to zależy od klienta. W moim mniemaniu to bardziej usługa niż soft. Ale pewnie czasem warto, aby ktoś za nas coś zrobił. Gdyby popatrzeć na przemysł od tuningu też jest taka nisza w miejscu gdzie standard nie wystarczy, gdzie są Ci którzy wiedzą (lub im się wydaje że wiedzą) więcej.

Jeżeli mam coś powiedzieć na temat marketingu, bo tu musiałem się z nim zderzyć - na pewno niezbyt przyjemna sprawa to fakt, że w biznesie nie ma że się kogoś lubi. I w tym miejscu gdzie nam się powinie noga, ktoś inny może zrobić kasę. My niestety wylądujemy w gorszym miejscu, gdzie poniekąd zostaniemy ze świadomością że się nie udało.
Ja mam tą nadzieję, że nie wszyscy tak robią i zdarzają się dwustronne korzyści.

O mnie i o innych trochę.

Było na początku tak: zrobiliśmy fajny system. Był pomysł - w sumie nie mój, ale to nie szkodzi. Nawet na początku wszystkie te graty ruszyły, przeszły testy i się cieszymy. Działa!! - prawie zawsze... Wszystko fajnie tylko... że mamy umowę. Dość wredną umowę. Dlatego nie można nad tym przejść obok, tyko trzeba się zmierzyć z tym dlaczego czasami nie działa. Przez tą umowę, gdy coś padnie liczy się czas, kiedy uda się naprawić. Mnie osobiście wydaje się, że jest jeszcze gorzej, gdy pada a potem samo się naprawia, zanim my zdążymy to naprawić. Wtedy robimy dochodzenie co było przyczyną. I teraz już wiem, że to męczące i żmudne. Na początku każda hipoteza jest cenna. Są pomysły. Są próby. Nie jedziemy w ciemno. Jest trochę co szukać, co zbierać i jak. Jednak gdy już kolejna diagnoza nie całkiem się sprawdza, pojawia się znużenie i ogólny brak zaufania.
Regularnie wraca pytanie co tam się dzieje? A potem, może nawet pytanie kto za to beknie. System jest duży, wydaje się skomplikowany i tylko czasami nawala. To właściwie powinno wystarczyć, ale nie wystarcza. Właściwie już zrobiłem co się dało.
Niestety to raport z autopsji.

I wtedy niestety ten ktoś, kto właściwy jest zadowolony jakimś cudem trafia na magika, który ci wszystko załatwi - łącznie z Tobą. Tylko czy aby to nie jest prawdziwy magik? - taki od sztuczek a nie od rozwiązywania problemów!

Gdyby jednak tego nie robił magik a ja. Zatem umówmy się, że ja mam ten system naprawić. Przynajmniej tak bym chciał. Taka moja ambicja. Ja po części też go pisałem. Wiem sporo co i jak działa. Nie wiem niestety wszystkiego (przynajmniej ja tak zakładam), bo gdybym wiedział to pewnie bez mojej wiedzy by nie padał. Czy to moja wina że tak się dzieje? Nie, raczej szukam kogoś winnego, bo to też mogę być niestety ja. Chcę to rozwiązać.

Jak się zabrać do takiej roboty?
Na pierwszy rzut oka wydaje się że już wszystko sprawdziłem - ale na pewno nie. Co mam?

* Logi
System jest rozproszony. Badanie logów to ciężka praca. Owszem mamy teraz już fajne wynalazki jak logstash (za free) itp. Na początek opędziłem to tak, że skorzystałem z logowania do Cassandry - ale nie od razu. Rzeczywista wymagana wydajność tego co pracuje dość duża. 400 komunikatów webservice na sekundę (w tybie ciągłym). I tak działa. Ogólnie Dużo maszyn wirtualnych. Dużo serwerów. Dużo logów.
Gdy je przeglądam widzę gdzie staje, ale nie wiem czy to wina sieci, czy bazy, czy szyny. Jednym słowem pat.

* Monitoring
Skoro znam się na Zabbix to czemu mam coś kombinować. Monitorowany Linux, Java, Poole do bazy, Baza, Operacje na bazie, Szyna ESB, Endpointy na szynie. Ale to za mało :[
Nie tylko ja to monitoruje. Nie tylko Zabbix. Wszyscy widzimy kiedy pada. Przesłanki które pozwalają wróżyć kiedy to się stanie pojawiają się za krótko przed zanim to się dzieje. W sumie na reakcję jest minuta - może? I to się nam pięknie zapisuje. Możemy to sobie po fakcie pooglądać. Ale gdzie jest przyczyna? Patowa sytuacja ogólnie.

Pewnie potrzeba czegoś na poparcie tych historyjek. Ale tu niestety nie wszystko można pokazać.
Tu muszę podkreślić że pomysł który wykorzystali we Flopsar Suite jest dobry, a to jako developer sobie cenię.

Dostaniesz agenta do javy. Każda maszyna wirtualna będzie ładować klasy przez wrapper który opakuje wywołanie wskazanych metod

Jak już przez to przebrnę to będę musiał zadać odpowiedzieć na kilka pytań, które się pojawiły:
- Na co uważać?

• na opłaty
• na to co rejestrują (do ich bazy idą jawne parametry które występują w metodach kodu), może to oznaczać, że znajdą się tam dane niepożądane takie jak hasła i piny które są wrażliwe. Normalnie te dane nie są dostępne bo są tylko na czas przetwarzania requesta aplikacji - tu mogą one zostać zapisane w bazie flopsar

- Co zobaczysz?

• agenta do javy
• "czarną skrzynkę" z autorską bazą
• klienta do bazy w jsf, który jest dość intuicyjny

- Czy da radę?

• zbierać potrafi dużo (spowolnienie kilka ms na request przy 400 requestów / sekundę - akceptowalne)   

- Czy warto?

Przykłady

Nie mogę pokazać na tyle dużo na ile bym chciał...

Myślę że mogę pokazać parę screenów które nie zdradzają szczegółów systemu.

Jednym z testów które przeprowadziłem był test impulsowej odpowiedzi.

"Osławiona" galaktyka punktów

Najbardziej wychwalanym elementem, który jest reklamowany przez flopsar to galaktyka punktów.

Na badany system składa się wiele workerów (serwerów aplikacyjnych) pełniących różną role.

Punkty które się pojawiają na wykresie galaktyka to czasy dla poszczególnych elementów stacka (dla requestów w moim wypadku) - atomowych elementów występujących w ścieżce przejścia.

W tym wypadku jest to request HTTP, na który składa się po stronie serwera wywołanie wielu metod z różnych klas.

To jakie klasy rejestrować, jakie metody z tych klas, oraz jakie atrybuty w metodach jest konfigurowalne w każdym z agentów dla javy na której pracuje serwer aplikacyjny. 

Jako serwer aplikacyjny można potraktować tomcat-a, ESB czy cokolwiek,

Pozycja pionowo na osi to czas przetwarzania konkretnej metody w ramach requesta. 

Na jeden request może być wiele takich punktów - po prostu stack wywołania.

Kolory punktów wynikają z przynależności do serwera aplikacyjnego - agenta dla flopsara który zostanie dograny do javy na której pracuje serwer aplikacyjny.

Przykładowy test impulsowy aplikacji.

Co widać na takim wykresie?

• niektóre workery (np ten czerwony, niebieskim i zielony) przetwarzają żądania dłużej przy teście impulsowym znacznie dłużej.
• po zaznaczeniu fragmentu obszaru z punktami, który znajduje się wyżej na osi Y będzie można obejrzeć requesty które zawierają punkty powyżej - to jest właśnie siła. Tu da się przejrzeć który punkt (czas przetwarzania jakiegoś kawałka - metody) trwał najdłużej i za co odpowiada. Tu będzie można np zobaczyć sql (jak jest ustawione rejestrowanie w agencie) lub parametry

Czego nie widać na tym wykresie?

• Ile jest faktycznie żądań - czy jest ich dużo czy mało, Na podstawie ilości punktów można powiedzieć tylko że jest dużo punktów (metod) zarejestrowanych. Pośrednio jak żądań jest więcej to punktów też jest więcej, ale nie daje to możliwości bezpośredniej organoleptycznej oceny ilości żądań
• Gdy request się nie zakończy (zawiśnie) to go nie zobaczymy
• Co jest przyczyną trzeba samemu wyciągnąć wnioski, a one nie koniecznie zawszę są na tacy

Można przy pomocy takiego narzędzia dobrać konfigurację systemu przy modyfikacji parametrów.
Wykonujemy te same testy dla różnych konfiguracji, a potem badamy to co możemy - czyli to co się zarejestrowało.

Poniżej zachowanie impulsowe systemu przy zmianach wielkości pooli dla datasource do bazy.

W zastawieniu zarejestrowanych requestów po wybraniu obszaru który nas interesuje wygląda to tak... (oczywiście nie pokazuje tego co nie trzeba)

Stack wywołania dla jednego ze wskazanych requestów

Na pewno takie przejrzenie historycznej odpowiedzi daje ciekawe pole do popisu do analizy. Co do tego na pewno nie mam wątpliwości.

Czy oglądanie tego na bieżąco jest potrzebne? Raczej nie.

Czy warto to ciągle rejestrować? Jak są zasoby to czemu nie. Wtedy można się "cofnąć w czasie".

Na podstawie zarejestrowanych danych będzie ciężko jednak wysnuć wnioski jeżeli przechodzą przez wiele workerów. 

Diagnostyka jest skuteczna w ramach jednego workera - a w złożonych systemach rzadko kiedy tak jest. Nie zawsze długi czas to dobre kryterium do alarmu.