Pekný piatok všetkým! Priatelia, dnes pokračujeme v sérii publikácií venovaných kurzu , pretože vyučovanie v novej skupine pre kurz začne koncom budúceho týždňa. Takže, začnime!
Monitorovanie je proste. Toto je známy fakt. Spustite Nagios, spustite NRPE na vzdialenom systéme, nakonfigurujte Nagios na NRPE TCP port 5666 a máte monitorovanie.
Je to také ľahké, až to nie je zaujímavé. Teraz máte základné metriky pre čas CPU, diskový subsystém, RAM, ktoré sú štandardne dodávané pre Nagios a NRPE. Toto však v skutočnosti nie je „monitorovanie“ ako také. Toto je len začiatok.
(Zvyčajne si nainštalujú PNP4Nagios, RRDtool a Thruk, nastavia si notifikácie v Slacku a idú rovno na nagiosexchange, ale to teraz vynechajme).
Dobrý monitoring je v skutočnosti pomerne zložitý, skutočne potrebujete poznať interné prvky aplikácie, ktorú monitorujete.
Je sledovanie náročné?
Akýkoľvek server, či už je to Linux alebo Windows, bude podľa definície slúžiť nejakému účelu. Apache, Samba, Tomcat, úložisko súborov, LDAP – všetky tieto služby sú viac-menej jedinečné v jednom alebo viacerých ohľadoch. Každý z nich má svoju vlastnú funkciu, svoje vlastné charakteristiky. Existujú rôzne spôsoby, ako získať metriky, KPI (kľúčové ukazovatele výkonu), ktoré sú pre vás zaujímavé, keď je server zaťažený.
Autor fotografie na
(Kiežby boli moje prístrojové dosky neónovo modré - zasnene vzdychám -... hmm...)
Každý softvér, ktorý poskytuje služby, musí mať mechanizmus na zhromažďovanie metrík. Apache má modul mod-status, čím sa zobrazí stránka stavu servera. Nginx má - stub_status. Tomcat má JMX alebo vlastné webové aplikácie, ktoré zobrazujú kľúčové metriky. MySQL má príkaz „zobraziť globálny stav“ atď.
Prečo teda vývojári nezabudujú podobné mechanizmy do aplikácií, ktoré vytvárajú?
Robia to len vývojári?
Určitá miera nezáujmu o vkladanie metrík sa netýka iba vývojárov. Pracoval som v spoločnostiach, kde vyvíjali aplikácie pomocou Tomcat a neposkytovali žiadne vlastné metriky, žiadne protokoly o činnosti služby, okrem všeobecných protokolov chýb Tomcat. Niektorí vývojári generujú množstvo protokolov, ktoré pre správcu systému, ktorý má tú smolu, že ich číta o 3:15 ráno, nič neznamenajú.
Autor fotografie na
Určitú zodpovednosť za situáciu musia niesť aj systémoví inžinieri, ktorí umožňujú uvedenie takýchto produktov na trh. Len málo systémových inžinierov má čas alebo starostlivosť, aby sa pokúsili extrahovať zmysluplné metriky z protokolov bez kontextu týchto metrík a schopnosti interpretovať ich vo svetle aktivity aplikácie. Niektorí nechápu, aký z toho môžu mať úžitok okrem indikátorov „niečo je momentálne (alebo čoskoro bude) zle“.
Zmena v myslení o potrebe metrík musí nastať nielen medzi vývojármi, ale aj medzi systémovými inžiniermi.
Pre každého systémového inžiniera, ktorý potrebuje nielen reagovať na kritické udalosti, ale aj zabezpečiť, aby sa nevyskytli, je nedostatok metrík zvyčajne prekážkou, aby tak urobili.
Systémoví inžinieri sa však zvyčajne nehrabú v kóde, aby zarobili peniaze pre svoju spoločnosť. Potrebujú vedúcich vývojárov, ktorí chápu dôležitosť zodpovednosti systémového inžiniera pri identifikácii problémov, zvyšovaní povedomia o problémoch s výkonom a podobne.
Toto devops vec
Mentalita devops popisuje synergiu medzi rozvojovým (dev) a operačným (ops) myslením. Každá spoločnosť, ktorá tvrdí, že „robí devops“ musí:
- hovoria veci, ktoré pravdepodobne nie (s odkazom na meme Princezná nevesta – „Nemyslím si, že to znamená to, čo si myslíš ty!“)
- Podporujte postoj neustáleho zlepšovania produktu.
Nemôžete vylepšiť produkt a vedieť, že bol vylepšený, ak neviete, ako momentálne funguje. Nemôžete vedieť, ako produkt funguje, ak nerozumiete tomu, ako fungujú jeho komponenty, služby, na ktorých závisí, jeho hlavné bolestivé body a prekážky.
Ak nebudete sledovať potenciálne úzke miesta, nebudete môcť pri písaní Postmortem postupovať podľa techniky Five Whys. Nebudete môcť dať všetko na jednu obrazovku, aby ste videli, ako produkt funguje, alebo aby ste vedeli, ako vyzerá „normálne a šťastne“.
Shift doľava, DOĽAVA, POVEDAL SOM LEEEE-
Pre mňa je jedným z kľúčových princípov Devops „posun doľava“. Posun doľava v tomto kontexte znamená posunutie možnosti (žiadna zodpovednosť, ale iba schopnosti) robiť veci, o ktoré sa systémoví inžinieri zvyčajne starajú, ako je vytváranie metrík výkonu, efektívnejšie používanie protokolov atď., vľavo v životnom cykle dodávania softvéru.
Autor fotografie na
Vývojári softvéru musia byť schopní používať a poznať monitorovacie nástroje, ktoré spoločnosť používa, aby mohli vykonávať monitorovanie vo všetkých jeho formách, metrikách, protokolovaní, monitorovacích rozhraniach a čo je najdôležitejšie, sledovať, ako ich produkt funguje vo výrobe. Nemôžete prinútiť vývojárov, aby investovali úsilie a čas do monitorovania, kým neuvidia metriky a neovplyvnia, ako vyzerajú, ako ich produktový vlastník prezentuje CTO na najbližšom brífingu atď.
Krátko povedané
- Veďte svojho koňa k vode. Ukážte vývojárom, koľkým problémom sa môžu sami vyhnúť, pomôžte im identifikovať správne KPI a metriky pre ich aplikácie, aby produktový vlastník, na ktorého kričí CTO, menej kričal. Vyneste ich na svetlo, jemne a pokojne. Ak to nefunguje, potom ich alebo produktového vlastníka podplatte, vyhrážajte sa im a presvedčte ich, aby čo najrýchlejšie implementovali získavanie týchto metrík z aplikácií a potom nakreslite diagramy. Bude to ťažké, pretože to nebude vnímané ako priorita a plán produktu bude mať veľa projektov generujúcich príjmy. Preto budete potrebovať obchodný prípad na zdôvodnenie času a nákladov vynaložených na implementáciu monitorovania do produktu.
- Pomôžte systémovým inžinierom dobre sa vyspať. Ukážte im, že používanie kontrolného zoznamu „poďme vydať“ pre akýkoľvek produkt, ktorý sa uvádza na trh, je dobrá vec. A uistenie sa, že všetky aplikácie vo výrobe sú pokryté metrikami, vám pomôže lepšie spať v noci, pretože vývojárom umožní vidieť, čo sa deje a kde. Správny spôsob, ako podráždiť a frustrovať každého vývojára, produktového vlastníka alebo CTO, je vytrvať a odolávať. Toto správanie ovplyvní dátum vydania akéhokoľvek produktu, ak budete opäť čakať na poslednú chvíľu, takže sa znova posuňte doľava a začleňte tieto problémy do plánu projektu čo najskôr. Ak je to potrebné, urobte si cestu na produktové stretnutia. Noste falošné fúzy a plsť alebo niečo také, nikdy to nezlyhá. Komunikujte o svojich obavách, preukazujte jasné výhody a evanjelizujte.
- Zabezpečte, aby vývoj (dev) aj prevádzka (ops) rozumeli významu a dôsledkom presunu metrík produktu do červenej zóny. Nenechávajte Ops ako jediného strážcu zdravia produktu, uistite sa, že sú zapojení aj vývojári (#productsquads).
- Logy sú skvelá vec, ale aj metriky. Skombinujte ich a nedovoľte, aby sa vaše polená stali odpadom v obrovskej horiacej guli zbytočností. Vysvetlite a ukážte vývojárom, prečo nikto iný nebude rozumieť ich protokolom, ukážte im, aké to je pozerať sa na zbytočné protokoly o 3:15 ráno.
Autor fotografie na
To je všetko. Nový materiál vyjde budúci týždeň. Ak by ste sa chceli o kurze dozvedieť viac, pozývame vás , ktorá sa uskutoční v pondelok. A teraz už tradične čakáme na vaše komentáre.
Zdroj: hab.com