Všetkým prajem šťastný piatok! Priatelia, dnes pokračujeme v sérii publikácií venovaných kurzu , pretože hodiny v novej skupine kurzu začínajú už na konci budúceho týždňa. Takže, poďme na to!
Monitorovanie — to je jednoduchý. To je známy fakt. Spustite Nagios, nastavte NRPE na vzdialenom systéme, nakonfigurujte Nagios na porte NRPE TCP 5666 a máte monitorovanie.
Je to také jednoduché, že to ani nie je zaujímavé. Teraz máte základné metriky CPU času, diskového subsystému a operačnej pamäte, ktoré sa dostanú do Nagios a NRPE ako predvolené. Ale v skutočnosti to nie je "monitorovanie" v pravom slova zmysle. To je len začiatok.
(Obvykle sa inštaluje PNP4Nagios, RRDtool a Thruk, nastavujú sa upozornenia v Slacker a idú priamo na nagiosexchange, ale zatiaľ to vynechajme).
Dobrý monitoring je v skutočnosti dosť zložitý, naozaj potrebujete poznať vnútro aplikácie, ktorú sledujete.
Je monitoring zložitý?
Každý server, nech už je to Linux alebo Windows, bude mať nejaký účel. 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ý má svoju funkciu, svoje špecifiká. Existujú rôzne spôsoby získavania metrík, KPI (kľúčových ukazovateľov výkonnosti), ktoré vás zaujímajú, keď je server pod záťažou.
Autor fotografie na
(rád by som, aby moje panely boli natreté v neonovo modrých farbách — snívajúc —… hm…)
Akýkoľvek softvér, ktorý poskytuje služby, by mal mať mechanizmus na zbieranie metrík. Apache má modul mod-status, ktorý zobrazuje stavovú stránku servera. Nginx má stub_status. Tomcat má JMX alebo špeciálne webové aplikácie, ktoré ukazujú kľúčové metriky. V MySQL je príkaz "show global status" atď.
Tak prečo vývojári nevkladajú takéto mechanizmy do aplikácií, ktoré vytvárajú?
Robia to len vývojári?
Určitá úroveň ľahostajnosti voči vkladaniu metrík nie je obmedzená len na vývojárov. Pracoval som v spoločnostiach, kde vyvíjali aplikácie pomocou Tomcat a nevydávali žiadne svoje metriky, žiadne denníky aktivity služby, okrem všeobecných chýb Tomcat. Niektorí vývojári generujú množstvo denníkov, ktoré pre sysadmina, ktorému sa smolu čítať o 3:15 ráno, nemajú žiadny význam.
Autor fotografie na
Systémoví inžinieri, ktorí umožňujú týmto produktom vyjsť na trh, by mali niesť určitú zodpovednosť za situáciu. Iba máloktorí systémoví inžinieri majú čas a zaujímajú sa o to, aby sa pokúsili získať významné metriky z logov, bez kontextu týchto metrík a možnosti ich interpretácie v súvislosti s aktivitou aplikácie. Niektorí nechápu, akú hodnotu môžu z toho získať, okrem indikátorov typu „niečo momentálne (alebo čoskoro) nie je v poriadku“.
Zmena myslenia o potrebe metrík by sa mala uskutočniť nielen medzi vývojármi, ale aj medzi systémovými inžiniermi.
Pre každého systémového inžiniera, ktorý musí nielen reagovať na kritické udalosti, ale aj zabezpečiť ich absenciu, je absencia metrík zvyčajne prekážkou.
Systémoví inžinieri zvyčajne nedokopávajú do kódu, 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.
Táto devops záležitosť
Myslenie devops opisuje synergické zmýšľanie vývojárov (dev) a prevádzky (ops). Akákoľvek spoločnosť, ktorá tvrdí, že robí devops, by mala:
- hovoriť to, čo pravdepodobne nerobia (narážka na meme z filmu ‚Princezná nevesty‘ — ‚Nemyslím si, že to znamená to, čo si myslíš, že to znamená!‘)
- podporovať postoj neustáleho zlepšovania produktu.
Nemôžete zlepšiť produkt a vedieť, že bol zlepšený, ak neviete, ako v súčasnosti funguje. Nebudete môcť zistiť, ako produkt funguje, ak nerozumiete, ako fungujú jeho komponenty, služby, na ktorých závisí, jeho hlavné problémy a úzke miesta.
Ak nesledujete potenciálne úzke miesta, nebudete môcť použiť techniku „Päť prečo“ pri písaní postmortem správy. Nebudete môcť zhromaždiť všetko na jednom displeji, aby ste videli, ako produkt funguje alebo aby ste zistili, ako vyzerá „normálne a šťastne“.
Posun doľava, DOĽAVA, POVEDAL SOM, DOĽAVA—
Pre mňa je jedným z kľúčových princípov Devops „Posun doľava“ (shift left). Posun doľava v tomto kontexte znamená posunutie schopnosti (nie zodpovednosti, a len možnosti) robiť to, o čo sa obvykle zaujímajú systémoví inžinieri, napríklad vytvárať metriky výkonu, efektívnejšie využívať logy atď. v rámci životného cyklu dodávky softvéru (Software Delivery Life Cycle).
Autor fotografie na
Vývojári softvéru by mali mať možnosť používať a poznať nástroje monitorovania, ktoré firma využíva na monitorovanie vo všetkých jeho formách, metrikách, logovaní, monitorovacích rozhraniach a, čo je najdôležitejšie, sledovať, ako ich produkt funguje v produkcii.. Nemôžete donútiť vývojárov venovať čas a úsilie monitorovaniu, pokiaľ nebudú môcť vidieť metriky a ovplyvniť to, ako vyzerajú, ako im ich produktový majiteľ predstaví CTO na nasledujúcom brífingu atď.
Inými slovami
- Dostaňte koňa k vode. Ukážte vývojárom, akým problémom sa môžu vyhnúť, pomôžte im určiť správne KPI a metriky pre ich aplikácie, aby bol menší krik od produktového vlastníka, na ktorého kričí technický riaditeľ (CTO). Vyveďte ich na svetlo, jemne a pokojne. Ak sa to nepodarí, podplácajte, vyhrážajte sa a presviedčajte buď ich, alebo produktového vlastníka, aby čo najskôr realizovali získanie týchto metrík z aplikácií a potom nakreslite diagramy. Bude to ťažké, pretože to nebude považované za prioritu a v produktovom pláne bude veľa čakajúcich projektov na realizáciu, ktoré generujú príjmy. Preto budete potrebovať hospodárske odôvodnenie, aby ste ospravedlnili čas a prostriedky vynaložené na implementáciu monitorovania do produktu.
- Pomôžte systémovým inžinierom vyspať sa. Ukážte im, že používanie kontrolného zoznamu "vydávame vydanie" pre akýkoľvek vydávaný produkt je dobré. A kontrola toho, či všetky aplikácie v produkte sú pokryté metrikami, pomôže dosiahnuť zdravý spánok v noci, čo umožní vývojárom vidieť, čo a kde nefunguje. Napriek tomu je správny spôsob, ako rozčúliť a rozrušiť každého vývojára, majiteľa produktu a technického riaditeľa, dôrazne vkladať klacky pod nohy a odporovať. Toto správanie ovplyvní dátum vydania akéhokoľvek produktu, ak opäť čakáte do poslednej minúty, takže znovu vykonajte posun vľavo a čo najskôr zahrňte tieto otázky do plánu projektu. Ak je to potrebné, preniknite na stretnutia týkajúce sa produktu. Noste falošné fúzy a filcovú čiapku alebo niečo podobné, to nikdy nesklame. Oznámte svoje problémy, ukážte zjavné výhody a evanjelizujte.
- Uistite sa, že ako vývojári (dev), tak aj operácie (ops) rozumejú významu a dôsledkom prechodu metrík produktu do "červenej zóny". Nenechávajte operácie ako jediného strážcu funkčnosti produktu, uistite sa, že vývojári sú tiež zapojení do tohto procesu (#productsquads).
- Logy sú skvelá vec, ale aj metriky. Spojte ich a nenechajte, aby sa vaše logy stali odpadom v obrovskom horiacej guľôčke bezcennosti. Vysvetlite a ukážte vývojárom, prečo nikto okrem nich nepochopí ich logy, ukážte im, aké to je pozerať sa na bezcenné logy o 3:15 ráno.
Autor fotografie na
Na tomto je všetko. Nový materiál vyjde budúci týždeň. Ak sa chcete dozvedieť viac o kurze, pozývame vás na , ktorý sa uskutoční už v pondelok. A teraz tradične čakáme na vaše komentáre.
Zdroj: habr.com
