čtvrtek 17. března 2011

Monitorování Java aplikací v cloudu

Jedna z lekcí, kterou vám dá cloud a hostování vlastních služeb, je v tom že přestávají platit staré přístupy, které vám léta fungovaly a nad kterými nebylo třeba nutno přemýšlet. V GoodData vycházíme z DevOps modelu to znamená, že vývojář jde se svým vývojem až do produkce. Nemáme tedy partu chlapíků, kteří sedí někde v servrovně a nemají na práci nic jiného než koukat kde se co děje. V produkčním clusteru nám běží N instancí JVM, které navíc můžeme dynamicky zapínat a vypínat podle očekávaného/známého zatížení. K tomu máme další desítky instancí, které běží vývojových a testovacích serverech a vývojářských instancích. Potřebujeme tedy monitoring, který nám umožní všechny tyto běžící JVM a aplikace v nich monitorovat.

Vždycky jsem byl nadšený z toho, kolik nástrojů je v ekosystému Javy k dispozici, bohužel jsem si neuvědomil, že můj pohled je značně omezený na potřeby řadového vývojáře. Máme sice jednoduché profilery a monitorovací nástroje typu VisualVM a nebo plnohodnotné profilery, ale s jejich použitím se počítá právě v rámci vývoje.

V GoodData Máme dva typy deployment prostředí z pohledu Java artefaktů/komponent, které hostujeme. Jeden typ komponenty běhá uvnitř servletového kontejneru a druhý ten stěžejní je standalone proces. Zkoumali jsme možnosti, které nabízejí nástroje NewRelic, JavaMelody a Hyperic a výsledek pro mě byl velkým zklamáním.

Požadavky

Z hlediska správy chci mít na jedné adrese jedno plátno (dashboard), na kterém si najdu instanci, která mě zajímá a podívám se na její detaily. Chci mít možnost přidávat si statistiky, které mě zajímají. Tedy kromě toho, že je sledují, tak musím mít možnost je nějak definovat. Příklad zajímá mě počet nějakých API požadavků, objem dat, které mi protečou skrze části systému a nebo čas zde strávený. Jinými slovy potřebuji customizovatelnost.

Ze základních charakteristik JVM nás zajíma:

  • maximalání velikost heapu a jeho obsazeni v čase
  • využití CPU v čase
  • uvolňování paměti Garbage Collectorem a četnost jeho pouštění v čase
  • počet tříd v čase
  • stav vláken v čase

Když vezmu ty nástroje popořadě. NewRelic i JavaMelody jsou výrazně orientované na monitoring webových aplikací a poskytují velkou část monitoringu, kterou vůbec nevyužiji. NewRelic sice umožňuje monitoring background procesů, ale jeho pricing není moc přívětivý vzhledem k objemu instancí, které tím potřebujeme monitorovat. Hyperic vypadá více genericky a umožňuje vytvářet vlastní metriky nad JMX beanami. Na druhou stranu není moc přehledný a Java v něm vypadá, že je jenom tak mimoděk.

Závěr

Jsem rozhodnuty, že pokud se neobjeví zázrakem nástroj, který se mým očím až doteď vyhýbal, tak si ten monitoring napíšeme prostě sami. Ne nechytejte se za hlavu, to opravdu myslím vážně. Už teď používáme Splunk, který nám umožňuje na všech instancích sbírat informace z logu, dělat nad tím dotazy a z výsledků stavět tabulkové reporty včetně grafů. Tedy tu správu, po které volám. Ve Scale/Jave si napíšeme jednoduchého agenta, který bude přisátý na JVM, bude olizovat její údaje a bude je dávat do logu ve formátu, nad kterým se nám budou dobře dolovat ve Splunku. Tím získáme online monitoring. Navíc si budeme moci jednoduše psát vlastní minitorovací sondy. Pro sledování dlouhodobějších trendů si uděláme konektor, kterým budeme dávat data k nám do GoodData.

Poznámka: Na dalším CZJUG setkání, které proběhne 28.3.2011 budu mluvit o tom jak vývoj v cloudu a produktu, který je prodáván jako hostovaná služba, takzvaný SAAS (Software As A Service) změnil můj pohled a zažité stereotypy z enterprise Javy.