Tech Life

Ilustrační obrázek

Monitoring a dohled nad provozem

23. 03. 2010 13:15    kategorie: Tech Life    autor: JHr    komentářů: 1

Sledování přednášky na akci InstallFest 2010, která byla na téma monitoringu, mi připomnělo, že o monitoringu krom adminů nikdo moc neví. Že zde existuje jako i v jiných technických bodech určité informační vakuum. Především jsou málo známá specifika chování monitoringu a základy jeho fungování. A to je dobré napravit, informační vakuum minimalizovat. Probereme si tedy, co čím sledujeme, a více či méně rozvedu jednotlivé body.
 

Obecně má monitoring za úkol zavčas upozorňovat na vzniklé problémy, aby jejich reaktivní řešení bylo zajištěno co možná nejdříve. Ideálně než si problému všimnou návštěvníci či klient. Důležitá je i minimalizace případných škod. Problematiku monitoringu lze chápat i trošku šířeji a zahrnout do něj i proaktivní sledovaní a upozorňování na stavy, které ještě neznamenají problém, ale neřešení může k problému vést (krásným příkladem budiž docházející místo na disku). Další, co lze do monitoringu zahrnout, jsou statistiky provozu, přístupů a sledování těchto metrik v čase. Problémem zde pak může být i to, že určitá metrika se dostává mimo svůj běžný průběh. Jedním trochu opomíjeným bodem, který je nutno monitorovat, jsou i logy aplikace, které nás mohou velmi rychle upozornit na problém, na který by ostatní kontroly zareagovaly až později, pokud by ho vůbec zaregistrovaly.

Podívejme se nyní, jak je implementováno u nás, a zmiňme si nějaké důležité poznámky, které možná mnohým ozřejmí někdy pozdější zareagování admina než uživatele, který se systémem v době vzniku problému pracuje. Ano. Pokud se systémem někdo pracuje, reakce monitoringu na výpadek včetně reakce admina nebude nikdy rychlejší. Vždy je zde nějaká prodleva zajišťující minimalizaci false-positive notifikací a její doba může mnohdy záviset na kvalitě infrastruktury vedoucí k monitorovanému systému/aplikaci případně stabilita a běžné provozní charakteristiky monitorovaného subjektu.

Monitoring dostupnosti/běhu - Nagios

Aktuálně nám k tomuto účelu slouží systém Nagios. Tento systém v pravidelných intervalech posílá dotazy na agenty nainstalované na serverech odkud dostává odpověď, nebo sám provádí příslušnou kontrolu.

Důležitou součástí je to, že nagios provádí notifikace a posílá adminům na 24/7 telefon SMS, že něco není v pořádku. Způsob jak se k notifikaci dobere, uvedu později.

Nagios jako takový má více stavů, ale lze ho považovat zjednodušeně za dvojstavový - něco je nebo není OK (existuje mezistav warning, jehož sledování je však v reálu poněkud málo aktivně řešeno). Podívejme se ještě na zmiňovanou prodlevu v reakci admina. Nagios provádí zmíněné kontroly. Pokud narazí na problém, je služba označena že stav CRITICAL je jen SOFT a podle konfigurace dojde k aktivnější kontrole stavu. Po definovaném zopakování negativního výsledku kontroly je teprve stav CRITICAL označen za HARD, Nagios ho až nyní vidí jako problematický a začíná se počítat prodleva, po které začínají být posílány notifikace. Velmi snadno se pak lze dobrat třeba toho, že pro konkrétní službu trvá třeba i 10 minut, než je admin poprvé upozorněn. Toto si vyžaduje velmi citlivou konfiguraci a definování důležitosti služeb. Nedostatečný HW monitorovacího systému spolu s přemrštěnými požadavky na četnost kontrol, mohou mít přesně opačný efekt - další opoždění odhalení problému.

Krom mnoha dalších funkcí řeší nagios také závislost jednotlivých systémů na sobě (funkčně i síťově) stejně tak jako plánování servisních výpadků, uchovávání historie. Námi nevyužívanou funkcí je i automatická reakce na chybový stav.

Sledování metrik - munin

K tomuto účelu používáme aktuálně munin. Jde o grafovací systém, který se v pravidelných intervalech dotazuje na určité hodnoty. Důkazem, že toto lze použít nejen pro sledování metrik systému, ale i pro sledování parametrů uvnitř aplikace, je architektura Annonce. Jsou takto grafovány krom charakteristik systému také počty inzerátů i podle jejich zdroje, počty posílaných SMS na jednotlivé operátory apod.

Jedna z funkcí, která současnému stavu chybí, je možnost definování určité charakteristiky, z které když se hodnoty dostanou, tak by měly být pushnuty do nagiosu, aby na to byl admin upozorněn. Takto by šlo například odhalit výrazný nárůst vkládaných inzerátů, prudší nárůst potřeby diskové kapacity apod., příkladů lze nalézt velmi mnoho a toto je právě jeden ze způsobů, jak proaktivně odhalovat problémy před jejich vznikem.

Statistiky přístupů - AWStats

Ty nám zajišťují obecně centrální AWStats. Tyto statistiky, jejich přesná adresa, bývají často uvedeny ve smlouvě s klientem.

V poslední době se čím dál častěji rozšiřuje použití googleovských statistik. Ty však nelze považovat za plnou náhradu statistik námi generovaných z logů webserverů. Jeden z důvodů je například možnost zpětného dogenerování a reálné zpracování všech požadavků a ne jen těch, které vedly na stránky obsahující speciální úpravu pro využití Google Analytics (Google krabičku nyní nepočítám).

Stejně jako v případě muninu by i zde nebylo na škodu, aby došlo k automatickému upozornění na stav, kdy se výrazně začínají přístupy odchylovat od běžných hodnot. To nás může upozornit nejen na to, že vzrostl počet návštěvníků, ale třeba i na nárůst chybových stavů. Zde již ale jsme trošku na hraně s monitoringem logů.

Monitoring logů jNP

Na některých architekturách, jejichž množina se postupně rozšiřuje, se nasazuje alespoň základní sledování logů. Nelze ho ještě považovat za plnohodnotný monitoring. Ten se řeší poněkud speciálněji. To co máme, zajišťuje alespoň v pravidelných intervalech zasílaní všech chyb v logách aplikace.

Pokud někoho zajímá něco konkrétního, pak lze pátrat po klíčových termínech “log management“ případně “SIEM” nebo “SEM” (ty vycházejí ze sledování bezpečnosti). Ve stručnosti jde o nadstavbu logovacího serveru, na který je živě logováno a on zajistí případnou téměř okamžitou reakci třeba skrze notifikační monitoring.

Zde si dovolím upozornit na super článek na téma, kdy aplikace sice loguje, ale je to k ničemu: OReilly Community - Top Log FAIL. Logování jsem již nakousl dříve, když jsem řešil přítomnost logovacího serveru, obsahy logů jsou mnohdy samostatná kapitola a i jNP má co zlepšovat.

Monitoring logů systému

Zde nám může být pomocníkem logwatch a podobné nástroje. které provádějí souhrny z logů. Jak jsem zmínil v předchozím bodě, tak intervalové zasílaní neřeší včasnou reakci a SIEM platí i zde.

Napojení QA testů na monitoring

Toto je něco, co u nás nemáme, a chybí to. Mnoho problémů takto mohlo být odhaleno. Principem je využití jednotkových nebo end-user testcase scénářů, které by byly prováděny na produkčním prostředí a negativní výsledek by byl pushován do notifikačního monitoringu. Odhalit by se daly pak problémy, kdy například selže objednávkový proces. Navázání na prováděné udpaty je samozřejmost, ale i opakované průběhy mimo updaty tak mohou odhalit nečekané problémy.

Závěrem

Závěrem vždy rád zmiňuji nějaké ponaučení, protože pokud nad něčím přemýšlím, na něco reaguji, něco publikuji, mělo by to mít nějaké důsledky. Tedy k věci…

Krom přehledu, co máme u nás k dispozici a je zmíněno ve článku, by si měl každý uvědomit důležitost monitoringu, ale i jeho “nedostatky” s dobou reakce apod.

Jedna z podstatných myšlenek je, že téměř vše co je provozováno, má být sledováno v čase a monitorováno, stejně jako by každá funkcionalita měla mít příslušný testcase. Minulý týden se ke mně dostal problém se špatnou pozicí jednoho z portálů ve vyhledávání na Google - toto vše lze sledovat a monitorovat (i pro toto existuje plugin do Nagiosu). Podobně víme, že pokud se některé složce v jNP vyskytne příliš mnoho záznamů (sekce/složka v CMS), výkon je silně degradován - lze monitorovat, eventlog jNP (kam jsou zaznamenávány chyby při renderování stránek) pokud vygeneruje příliš záznamů, zpomalí výrazně jNP - lze monitorovat (a na O2 to tak je).

Monitoring není jen pro adminy, může existovat monitoring, který poběží nezávisle na centrálním monitoringu a bude řešit kontroly stavu jen na denních intervalech apod. Stejně tak integrace sledování metrik s notikacemi by mohla přinést další zlepšení ve stavu dohledu nad aplikacemi a aplikačním prostředím.

Jak jsem v jiném svém příspěvku psal o proaktivním řešení, z tohoto pohledu lze také upozornit na potřebu nově doplněné monitorování efektivně propagovat z pilotního projektu kde bylo poprvé nasazeno na ostatní.

Sdílet odkaz:
tisk

Diskuze k článku

Anonym, 13.3.2012 14:27

QA testy umi elegantne resit Zabbix

Přidat příspěvek

 

Kontakt pro média


Máte zájem o další informace, odborný článek či přednášku na konferenci? Kontaktujte nás prosím na pr@etnetera.cz.

RSS - Tech life


RSS kanál Tech Life Blogu

Offlineblog

Offlineblog

Ljama


Komix z prostředí imaginární firmy.

ljama

Ještě jste ho nečetli? Tak tudy ...

 
Doporučujeme: Nabídka práce, volná pracovní místa - pracovní portál SPRÁVNÝKROK.CZ