Šťastný pátek všem! Přátelé, dnes pokračujeme v sérii publikací věnovaných kurzu , protože výuka v nové skupině pro kurz začne koncem příštího týdne. Takže, začněme!
Monitorování je jenom. To je známý fakt. Vyvolejte Nagios, spusťte NRPE na vzdáleném systému, nakonfigurujte Nagios na NRPE TCP portu 5666 a máte monitorování.
Je to tak snadné, že to není zajímavé. Nyní máte základní metriky pro čas CPU, diskový subsystém, RAM, které jsou standardně dodávány Nagios a NRPE. To ale ve skutečnosti není „monitorování“ jako takové. To je jen začátek.
(Obvykle nainstalují PNP4Nagios, RRDtool a Thruk, nastaví upozornění ve Slacku a jdou rovnou na nagiosexchange, ale to teď nechme stranou).
Dobré sledování je ve skutečnosti poměrně složitý, opravdu potřebujete znát vnitřnosti aplikace, kterou sledujete.
Je sledování obtížné?
Jakýkoli server, ať už je to Linux nebo Windows, bude z definice sloužit nějakému účelu. Apache, Samba, Tomcat, úložiště souborů, LDAP – všechny tyto služby jsou víceméně jedinečné v jednom či více ohledech. Každý má svou vlastní funkci, své vlastní vlastnosti. Existují různé způsoby, jak získat metriky, KPI (klíčové ukazatele výkonu), které jsou pro vás zajímavé, když je server pod zatížením.
fotka od na
(Přál bych si, aby moje palubní desky byly neonově modré - zasněně vzdychám -... hmm...)
Jakýkoli software, který poskytuje služby, musí mít mechanismus pro shromažďování metrik. Apache má modul mod-status, zobrazí se stránka stavu serveru. Nginx má - stub_status. Tomcat má JMX nebo vlastní webové aplikace, které zobrazují klíčové metriky. MySQL má příkaz „ukázat globální stav“ atd.
Proč tedy vývojáři podobné mechanismy nezabudují do aplikací, které vytvářejí?
Dělají to jen vývojáři?
Určitá míra lhostejnosti k vkládání metrik se netýká pouze vývojářů. Pracoval jsem ve společnostech, kde vyvíjeli aplikace pomocí Tomcatu a neposkytovali žádné vlastní metriky, žádné protokoly o činnosti služby, kromě obecných protokolů chyb Tomcat. Někteří vývojáři generují spoustu logů, které pro správce systému, který má tu smůlu, že je čte ve 3:15 ráno, nic neznamenají.
fotka od na
Určitou odpovědnost za situaci musí nést i systémoví inženýři, kteří umožňují uvedení takových produktů na trh. Jen málo systémových inženýrů má čas nebo péči pokusit se extrahovat smysluplné metriky z protokolů bez kontextu těchto metrik a schopnosti interpretovat je ve světle aktivity aplikace. Někteří nechápou, jak z toho mohou těžit, kromě ukazatelů „něco je aktuálně (nebo brzy bude) špatně“.
Změna v uvažování o potřebě metrik musí nastat nejen mezi vývojáři, ale také mezi systémovými inženýry.
Pro každého systémového inženýra, který potřebuje nejen reagovat na kritické události, ale také zajistit, aby k nim nedocházelo, je nedostatek metrik obvykle překážkou.
Systémoví inženýři si však obvykle nelámou hlavu s kódem, aby pro svou společnost vydělali peníze. Potřebují vedoucí vývojáře, kteří chápou důležitost odpovědnosti systémového inženýra při identifikaci problémů, zvyšování povědomí o problémech s výkonem a podobně.
Tohle devops věc
Mentalita devops popisuje synergii mezi vývojovým (dev) a operačním (ops) myšlením. Každá společnost, která tvrdí, že „dělá devops“ musí:
- říkat věci, které pravděpodobně ne (s odkazem na mem Princezna nevěsta – „Nemyslím si, že to znamená to, co si myslíš ty!“)
- Podporujte postoj neustálého zlepšování produktu.
Nemůžete vylepšit produkt a vědět, že byl vylepšen, pokud nevíte, jak aktuálně funguje. Nemůžete vědět, jak produkt funguje, pokud nerozumíte tomu, jak fungují jeho součásti, služby, na kterých závisí, jeho hlavní bolesti a překážky.
Pokud nebudete sledovat potenciální úzká hrdla, nebudete moci při psaní Postmortem postupovat podle techniky Five Whys. Nebudete moci dát vše na jednu obrazovku, abyste viděli, jak produkt funguje, nebo abyste věděli, jak vypadá „normálně a šťastně“.
Řaďte doleva, doleva, řekl jsem LEEEE-
Pro mě je jedním z klíčových principů Devops „shift left“. Posun doleva v tomto kontextu znamená posunutí možnosti (žádnou zodpovědnost, ale pouze schopnosti) k provádění věcí, o které se systémoví inženýři obvykle starají, jako je vytváření metrik výkonu, efektivnější používání protokolů atd., vlevo v životním cyklu dodávky softwaru.
fotka od na
Softwaroví vývojáři musí být schopni používat a znát monitorovací nástroje, které společnost používá, aby mohli provádět monitorování ve všech jeho formách, metrikách, protokolování, monitorovacích rozhraních a hlavně, sledovat, jak jejich produkt funguje ve výrobě. Nemůžete přimět vývojáře, aby investovali úsilí a čas do monitorování, dokud neuvidí metriky a neovlivní, jak vypadají, jak je produktový vlastník prezentuje CTO na příštím briefingu atd.
Krátce řečeno
- Veďte svého koně k vodě. Ukažte vývojářům, jak velkým problémům se mohou sami vyhnout, pomozte jim identifikovat správné KPI a metriky pro jejich aplikace, aby bylo méně křiku ze strany produktového vlastníka, na kterého CTO křičí. Vyveďte je na světlo, jemně a klidně. Pokud to nefunguje, pak je uplácejte, vyhrožujte a přemlouvejte buď je, nebo produktového vlastníka, aby co nejrychleji implementovali získávání těchto metrik z aplikací, a pak nakreslete diagramy. To bude obtížné, protože to nebude považováno za prioritu a plán produktu bude mít mnoho nevyřízených projektů generujících příjmy. Proto budete potřebovat obchodní případ, abyste odůvodnili čas a náklady vynaložené na implementaci monitorování do produktu.
- Pomozte systémovým inženýrům dobře se vyspat. Ukažte jim, že používání kontrolního seznamu „pojďme vydat“ pro jakýkoli produkt, který je uvolňován, je dobrá věc. A zajistit, aby byly všechny aplikace v produkci pokryty metrikami, vám pomůže v noci lépe spát, protože vývojářům umožníte vidět, co se děje a kde. Nicméně správným způsobem, jak rozčílit a frustrovat každého vývojáře, produktového vlastníka nebo CTO, je vytrvat a vzdorovat. Pokud budete znovu čekat na poslední chvíli, toto chování ovlivní datum vydání libovolného produktu, takže se znovu posuňte doleva a zařaďte tyto problémy do plánu projektu co nejdříve. V případě potřeby se vydejte na produktové schůzky. Noste falešný knír a plsť nebo tak něco, nikdy to nezklame. Sdělujte své obavy, demonstrujte jasné výhody a evangelizujte.
- Zajistěte, aby vývoj (dev) i operace (ops) chápaly význam a důsledky přesunu metrik produktu do červené zóny. Nenechávejte Ops jako jediného strážce zdraví produktu, ujistěte se, že jsou zapojeni i vývojáři (#productsquads).
- Logy jsou skvělá věc, ale také metriky. Kombinujte je a nenechte, aby se vaše polena stala odpadkem v obrovské planoucí kouli zbytečnosti. Vysvětlete a ukažte vývojářům, proč nikdo jiný nebude rozumět jejich logům, ukažte jim, jaké to je dívat se na zbytečné logy ve 3:15 ráno.
fotka od na
To je vše. Nový materiál vyjde příští týden. Pokud byste se chtěli o kurzu dozvědět více, zveme vás , která se uskuteční v pondělí. A nyní již tradičně čekáme na vaše komentáře.
Zdroj: www.habr.com