A teraz túto,… o monitoringu.
Ahoj programátor. Ako sa máš? Asi si dávaš svoju rannú kávu a čakáš kedy ti zbehnú testy? A čo dobrého si spravil minulý týždeň pre slovenské IT? Určite si zmastil pre kravaťáka tú novú feature, ktorou chce ovládnuť všetky trhy a svet. Alebo si dnes pokoril nový framework, čo robí presne to isté, čo ten starý, len tento je cool funkcionálny? A čo si spravil pre operations? Pýtaš sa kto to je? To je ten nový chalan, čo vyzerá akosi nevyspatý. Voláte ho že Admin. Strčili ho k vám, lebo váš šéf sa rozhodol, že budete robiť nejaký DevOps. Vraj to tak robí Spotify a sú to vraj šťastní zamestnanci. On však nevyzerá vôbec šťastne. Ty tiež nie si z toho 3x nadšený. Chápem. Nieje to programátor, tak čo by si pre neho mal robiť. Hlavne že on pre teba už 2 týždne grepuje logy z produkcie na požiadanie. Mohol by si na oplátku spraviť ty niečo pre neho. Nech má chalan trochu svetla v tej tme. Ver mi, že budete z toho profitovať obaja.
Má tvoja aplikácia už vyriešený monitoring? Nemyslím logy, a už vôbec nie ELK. Myslím skôr nejaké metriky, merania. Nie? Akoto? Vraj ti to bude špatiť kód? Ja ti teda poviem načo je to dobré.
Takže, na to aby tvoj nový kamoš vedel spravovať aplikácie čo tam plodíte, tak má už nejaký Nagios. Ono je fajn že ho má. ale podľa mňa tam aj tak nič rozumné nemonitoruje. Totižto ty si mu do svojej aplikácie nezakomponoval žiadne metriky. Maximálne pinguje nejaký endpoint, či je tvoja aplikácia vôbec živá. Ešte samozrejme nejaké CPU, pamäť. To, čo mu Linux poskytuje lebo Linux vývojári berú monitoring ako samozrejmosť. Tvoja aplikácia je pre neho však akási čierna skrinka, do ktorej nevidí. Inač povedané, má to chalan s tebou ťažké. Stále rieši tvoju aplikáciu keď už je neskoro, keď už to je totálne v ….
Predstav si takúto situáciu. Nedávno si pracoval na novej požiadavke od kravaťáka, o ktorej si bol už vtedy presvedčený, že je to blbosť. Samozrejme kravaťák prišiel už aj s riešením. Táto nová feature sa vypustila a všetko vyzeralo fajn. Kravaťák je šťastný, ty si rád že to máš s krku a tvoj nový kamoš admin má pocit že všetko je úplne v poriadku. Lenže v tom riešení je logická chyba, kedy po 20000 requestoch aplikácia odmietne asi 50% requestov štýlom 401 Unauthorized asi cca na pol minúty. Samozrejme aplikácia má zatiaľ 50 používateľov a toto chovanie sa prejavuje len sporadicky. AJ samotný používateľ, keď natrafí na tento problém, povie si: ach asi blbé heslo a skúsi opäť znova. Prejde určitý čas a tvoju aplikáciu začne používať viac ľudí. Nedajbože sa tvoje API dostane do nejakej mobilnej aplikácie. Zrazu na produkcii máš 10000 requestov za minútu a výsledok je, že každé 2 minúty je tvoja aplikácia pre 50% používateľov nedostupná. Tvoj nový kamoš na tom strávil celkom nepríjemné 2 dni, pretože ani za nič nevedel prísť na to, čo sa presne deje. V monitoringu mal len to, že aplikácia žije. Tak mu nič iné neostalo, len sa hrabať v logoch, čo na produkcii pri tomto množstve nie je sranda. Bola to feature, ktorá je tam už 4 mesiace a tento problém tam ležal a čakal na svoj big-bang. Tebe teda nič iné neostáva, len narýchlo zmastiť nejaký škaredý fix. Celá tvoja čistá DDD architektúra je ti teraz aj tak nanič. Koho je to chyba? Nikoho. Produkcia je totižto mrcha. Takéto veci sa dejú, a dejú často. Ťažko im predísť. Na takéto situácie treba vedieť včas reagovať. Čím skôr, tým lepšie. Tvoj nový kamoš to dokáže, lenže potrebuje vidieť do tvojej aplikácie.
Monitoringom aplikácie nezíska len on lepší prehľad, čo sa deje, ale aj ty získaš tvrdé čísla. Čísla, ktoré potom môžeš použiť, ako argumenty napríklad na mítingoch s kravaťákom, že to nie je dobré riešenie. Samozrejme bez týchto čísel sa tvoje mítingy menia na boj: tvrdenie proti tvrdeniu, kde vyhráva ten, kto je vo firme vyššie postavený. Určite to poznáš. Nedávno si zažil tiež taký míting s architektom. To je ten človek, čo prečítal o 3 knihy viac ako ty, na Twitteri sleduje Fowlera a na každom mítingu je považovaný za technického guru, čo vie všetko. Bol tam, lebo idete robiť novú integráciu. Samozrejme príde s tým, že treba použiť technológiu XYZ, ktorá je dnes v móde. Vraj to bude super-duper distribuované a to riešenie čo si chcel ty, je “pomalé”. Obaja varíte z vody. Ty preto, že nemáš/nepoznáš skutočné čísla svojej aplikácie, on preto, že to niekde čítal. Ak by si mal metriky vo svojej aplikácii, vedel by si, že posledné čo ťa trápi, je latencia, ktorá je teraz relatívne dobrá. Že problém je skôr napríklad so stabilitou releasov. Posledné čo potrebuješ, je teda ďalšia technológia.
Snáď si už správne namotivovaný, aby si šiel do monitoringu. Ono to nie je nič komplikované. Nebudem tu písať o tom, či Prometheus, Nagios, Graphite. Toto nie je mojim cieľom. Mimochodom Mike Julian v knihe Practical Monitoring začína antipatternami. Antipattern #1 — Tool Obsession. Podstatné je si uvedomiť, že monitoring je kompozitná záležitosť. Nieje to len o grafoch. Dá sa to teda rozdeliť na:
· Data Collection
· Data Storage
· Visualisation
· Alerting
· Reporting and analysis
Teba sa najviac bude týkať ‘Data Collection’. Je to bod, ktorým to celé začína. Aby bolo možné robiť data collection, musíš do svojej aplikácie zakomponovať možnosť zbierania metrík. Je to jednoduchá vec. Máš na výber 2 možné spôsoby: Pull a Push. Push znamená, že tvoja aplikácia odosiela stav metrík do nejakého systému. Pull je opačný spôsob. Vystavíš nejaký endpoint, a systém si cez tento endpoint vytiahne stav metrík. Kedysi sa preferoval push, dnes je v móde pull. Samozrejme je okolo toho kopec hašterenia, ktoré je lepšie. Ja si myslím že pravda je niekde v strede. Osobne preferujem pull pre web aplikácie, pretože sa veľmi jednoducho implementuje. Push naopak je fajn pri ETL, batch atď. Ideálne je, ak systém podporuje oba spôsoby (bod pre Prometheus). Povieš si čo mi to tu hovoríš. Zoberiem Spring Boot a toto čo tu píšeš mam spravené jednou závislosťou. Pravda. Problém s takýmito metrikami je, že zrazu namiesto žiadnych metrík ich máš 1000 ktorým vôbec nerozumieš. Vlastne si si nijak nepomohol. Možno je to ešte horšie. Ak tvoj kamoš admin zavesí alerting na takéto metriky hlava nehlava a začne mu mobil zvoniť o 2:30 ráno, a ty mu ani nebudeš vedieť vysvetliť čo to vlastne znamená, asi ho tým nepotešíš. Maj každú metriku pod kontrolou. Je dôležité rozumieť každému číslu. A tiež nemať 1000 metrík.
Prvé čim začneš, je, že si do svojej aplikácie dorafáš nejakú knižnicu ako dropwizard-metrics, alebo prometheus-client. Ono možno budeš sklamaný, že tieto knižnice poznajú dokopy 3 alebo 4 veľmi jednoduché typy meraní. Napríklad Counter. Veď to sa len zvyšuje nejaké číslo, Alebo Gauge. To číslo sa dokonca ani len nezvyšuje. Vtipné je, že to je všetko čo potrebuješ. Pri data collection nie je úlohou robiť konečné štatistiky, alebo nejaké zložité metriky. Data collection je taká hipsterina v znamení raw, bio, eko. Čiže zbierať treba čo najviac RAW dát. Tým sa človek nepripraví o kopec možnosti. Je dobré, aby knižnica, ktorú zvolíš, neprodukovala len nejaký názov a číslo. Dôležité je aby knižnica vedela metriku labelovať, tagovať. Ku každej metrike tak vieš doplniť nejaké metadáta. Toto je mega-super-cool vec. Ak si sa stretol s OLAP, tak na to môžeš pozerať ako na dimenzie. Každá metrika má teda hodnotu a dimenzie. To umožňuje kadejaké zaujímavé štatistické srandy.
Dobre. Takže máš už nejakú knižnicu, napr. prometheus-client ako závislosť v tvojej aplikácii. Máš vystavený nejaký endpoint, ktorý Prometheus pulluje, čo nastavil tvoj nový kamoš admin. On si už pripravil aj Grafanu ako vizualizáciu. Hurá. Poďme teraz k tomu, čo má a nemá zmysel monitorovať a ako sa vysporiadať s hodnotami.
Na úvod 3 skratky: SLI, SLO a SLA. Tieto 3 magické skratky prichádzajú z Google. Ak chceš o nich vedieť viac, odporúčam knihu Site Reliability Engineering — Chapter 4: Service Level Objectives. SLA (Service Level Agreement) asi poznáš. To necháme kravaťákovi. Každopádne, je dobré s nim hodiť reč, aké SLA on vidí zo svojho pohľadu, alebo aké má KPI. Tu je dôležitá zodpovednosť. Čo sa teda stane, ak sa SLA nenaplní. Teba a tvojho nového kamoša bude viac zaujímať SLI (Service Level Indicator) a SLO (Service Level Objective).
SLI je indikátor. Vlastne, to čo meriaš. Aká hodnota ťa bude zaujímať. Napríklad RPS (Requests per seconds), alebo latencia requestu. SLO je akýsi treshold. Napríklad že latencia endpointu by mala byť pod 100ms. Alebo akceptovaný počet ‘HTTP 500’ chýb z celkového počtu requestov je 0.05%. Taktiež je to fajn základ na argumentáciu pre kravaťáka, prečo nemôžete robiť na novej feature. Ak začínate prekračovať/porušovať SLO, asi by si mal zapracovať na stabilite systému, a nechrliť nové features. Nieje zlé si stanoviť aj zelené/pozitívne SLO. Napríklad máme menej ako 0.02% errorov, to je zelená pre nejakú šialenosť. Hurá pre vášho architekta, Môže sa vyblázniť na technológii, ktorej nikto z vás aj tak nerozumie. SLO je teda celkom dôležitá záležitosť.
Naspäť k SLI. Aké indikátory stanoviť našej aplikácii? Predstavme si, že máme klasickú web aplikáciu, ktorá ma nejaké REST API a dáta v nejakej DB. Na začiatok ťa budú zaujímať endpointy APIčka a volania/queries nad DB. Toto sú také najčastejšie miesta v kóde, kde by sme nejaké metriky mali zaviesť. Volajme to blackbox monitoring. O blackbox/whitebox monitoringu je taktiež kopec hádok. No a teraz čo za metriky? Dobre je začať tzv. golden signals. To tvoj nový kamoš admin veľmi ocení. SRE pozná 4: Latency, Traffic, Errors a Saturation. Okrem toho sú populárne ešte USE method (Utilization, Saturation, Errors) a RED method (Rate, Errors Duration). Najľahšie je asi začať RED, ale proti vkusu žiaden dišputát. Saturácia (čiže ako je plný/preťažený systém a rozloženie záťaže) je trošku komplikovanejšia téma, hoci dosť zaujímavá. Tam uvidíš aká ilúzia je napríklad round-robin balancing. Rate je napr. requests per second — RPS, alebo queries per second — QPS a iné per second. Errors je snáď jasná vec. Všetko čo nie je HTTP 2xx. Tu prídeš na to, aký dobrý koncept je label. Keď si dáš HTTP Status kód ako label, tak môžeš neskôr reportovať nielen koľko chýb nastalo, ale či išlo o validačné chyby, neautorizované prístupy atď. Nieje chyba ako chyba. Neskôr ťa to dotlačí aj do rozumného používania status kódov. S labelmi však opatrne, netreba to zase preháňať. No a duration je koľko “priemerne” trvá jeden request. Či je to 10msec alebo 3sec.
Naschvál som dal priemer do úvodzoviek. Priemer je veľmi zradná štatistická funkcia. Zoberme si časový rámec jednej sekundy. Stačí jeden request na začiatku ktorý potrvá 3 sekundy (lebo caching).Aj keď ďalšie requesty už budú pod 100ms, tak priemerná hodnota vyletí do výšok, ktoré ti môžu naraziť na SLO. Tvojmu kamošovi adminovy to potom odpáli alerting. Preto je lepšie používať napr. histogram a nejaký quantille alebo percentille. Nespriemeruješ všetky hodnoty, ale napr. 99 percentille, čiže 1% krajných hodnôt odfiltruješ a budeš sa tváriť, že je to OK. Knižnice ako prometheus-client a dropwizard-metrics ti s tým pomôžu. Prometheus client napríklad pekne vytvorí tzv. buckety pre histogram. Dropwizard metrics zase pre danú metriku bude vyrábať rôzne percentille. Stačí to už len zobrať, porozumieť a používať. Samozrejme zmieniš to aj pri SLO, že nie 100% requestov by malo byť do 100ms ale 99% je do 100ms. Histogram ti dá aj lepší prehľad o tom, kde a ako sa tá tvoja latencia vyvíja. To môže poukazovať na to, či caching funguje dobre, alebo ho treba jemne prekonfigurovať.
Teraz, keď už približne vieš, čo a ako, s kamošom adminom môžete začať zbierať hodnoty do nejakej time-series databázy (TSDB). Napríklad opäť môj obľúbený Prometheus. Pretože si ma počúval a zbieraš RAW dáta, tak kamoš admin si vie nastaviť alerting ako potrebuje aby ho nebudil pri každej hlúposti. Dokonca si tvoj kamoš na niektoré alerty zavesí skripty a možno už nebude vyzerať tak nevyspatý. Alebo môžete s architektom robiť A/B testing. Pomocou feature toggle môžete skúšať, či daný algoritmus je lepší, alebo horší, ako ten predchádzajúci. Takto spoznáte čoho vaša aplikácia je schopná. Môžete tieto RAW dáta poskytnúť tej novej mat-fyzáčke vo vedľajšom teame. Robí DataScience a môže nájsť kadečo, možno začne predikovať výpadky. Vlastne tie ani netreba predikovať, tie sa dejú neustále. Hlavne budete môcť vidieť dopad rozhodnutí a naopak, na základe čísiel sa vedieť rozhodnúť.
Ja som tu len škrtol náznak toho, o čom monitoring je. Vlastne ten sa dnes už vo svete ani nerobí. Vo svete dnes fičí observability, ale najprv sprav tento prvý krôčik. O observability možno niekedy inokedy. Chcel som ti ukázať, prečo je monitoring dôležitý, namotivovať ťa aby si sa do neho pustil. Nastal totižto čas zmeny, kedy programátor bude musieť ovládať niečo z operations.
Mimochodom, testy ti už dávno dobehli. Takže už tu nestrácaj čas a bež. Vieš čo máš robiť….
