O vytvoření monitorovacího systému jsme uvažovali ve fázi formování produktových týmů. Ukázalo se, že naše podnikání – vykořisťování – do těchto týmů nespadá. proč tomu tak je?
Faktem je, že všechny naše týmy jsou postaveny na jednotlivých informačních systémech, mikroslužbách a frontách, takže týmy nevidí celkový stav celého systému jako celku. Například nemusí vědět, jak nějaká malá část v hlubokém backendu ovlivňuje frontend. Jejich rozsah zájmu je omezen na systémy, se kterými je jejich systém integrován. Pokud tým a jeho služba A nemají téměř žádné spojení se službou B, pak je taková služba pro tým téměř neviditelná.
Náš tým zase pracuje se systémy, které jsou mezi sebou velmi silně integrované: existuje mezi nimi mnoho propojení, jde o velmi rozsáhlou infrastrukturu. A na všech těchto systémech (kterých máme mimochodem obrovské množství) závisí provoz internetového obchodu.
Ukazuje se tedy, že naše oddělení nepatří žádnému týmu, ale je umístěno trochu stranou. V celém tomto příběhu je naším úkolem komplexně porozumět tomu, jak informační systémy fungují, jejich funkčnost, integrace, software, síť, hardware a jak to vše spolu souvisí.
Platforma, na které naše internetové obchody fungují, vypadá takto:
- přední
- střední kancelář
- back office
Ať bychom chtěli sebevíc, nestane se, že by všechny systémy fungovaly hladce a bezchybně. Jde opět o počet systémů a integrací – u něčeho, jako je ten náš, jsou některé incidenty navzdory kvalitě testování nevyhnutelné. Navíc jak v rámci samostatného systému, tak z hlediska jejich integrace. A je potřeba hlídat stav celé platformy komplexně a ne jen tak nějaké její jednotlivé části.
V ideálním případě by mělo být monitorování stavu celé platformy automatizováno. A k monitorování jsme se dostali jako nevyhnutelná součást tohoto procesu. Zpočátku byl postaven pouze pro frontovou část, zatímco síťoví specialisté, správci softwaru a hardwaru měli a stále mají své vlastní systémy sledování vrstev. Všichni tito lidé sledovali monitoring pouze na své úrovni, ani nikdo neměl komplexní pochopení.
Pokud například dojde k havárii virtuálního stroje, ve většině případů o tom ví pouze správce zodpovědný za hardware a virtuální stroj. V takových případech frontový tým viděl samotný fakt pádu aplikace, ale neměl data o pádu virtuálního stroje. A správce může vědět, kdo je zákazník, a mít přibližnou představu o tom, co na tomto virtuálním stroji aktuálně běží, za předpokladu, že se jedná o nějaký velký projekt. S největší pravděpodobností o těch nejmenších neví. V každém případě je potřeba, aby správce zašel za majitelem a zeptal se, co na tomto stroji bylo, co je potřeba obnovit a co změnit. A pokud se něco opravdu vážného porouchalo, začali běhat v kruzích – protože nikdo neviděl systém jako celek.
V konečném důsledku takové nesourodé příběhy ovlivňují celý frontend, uživatele a naši hlavní obchodní funkci – online prodej. Protože nejsme součástí týmu, ale zabýváme se provozem všech ecommerce aplikací v rámci internetového obchodu, vzali jsme si za úkol vytvořit komplexní monitorovací systém pro ecommerce platformu.
Struktura systému a zásobník
Začali jsme identifikací několika monitorovacích vrstev pro naše systémy, v rámci kterých bychom potřebovali shromažďovat metriky. A to vše bylo potřeba skloubit, což jsme udělali v první fázi. Nyní v této fázi dokončujeme nejkvalitnější sbírku metrik napříč všemi našimi vrstvami, abychom vytvořili korelaci a pochopili, jak se systémy navzájem ovlivňují.
Absence komplexního monitoringu v počátečních fázích spouštění aplikace (od doby, kdy jsme ji začali budovat, když byla většina systémů ve výrobě), vedl k tomu, že jsme měli značný technický dluh na nastavení monitoringu celé platformy. Nemohli jsme si dovolit soustředit se na nastavení monitoringu pro jeden IS a detailně pro něj rozpracovat monitoring, protože zbytek systémů by zůstal nějakou dobu bez monitoringu. Abychom tento problém vyřešili, identifikovali jsme seznam nejnutnějších metrik pro hodnocení stavu informačního systému po vrstvách a začali jej implementovat.
Proto se rozhodli slona sníst po částech.
Náš systém se skládá z:
- Hardware;
- operační systém;
- software;
- části uživatelského rozhraní v monitorovací aplikaci;
- obchodní metriky;
- integrační aplikace;
- informační bezpečnost;
- sítě;
- vyvažovač dopravy.
V centru tohoto systému je samotné monitorování. Abyste obecně porozuměli stavu celého systému, musíte vědět, co se děje s aplikacemi na všech těchto vrstvách a napříč celou sadou aplikací.
Takže o hromadě.
Používáme open source software. V centru máme Zabbix, který používáme především jako výstražný systém. Každý ví, že je ideální pro monitorování infrastruktury. Co to znamená? Přesně ty nízkoúrovňové metriky, které má každá společnost, která spravuje vlastní datové centrum (a Sportmaster má svá datová centra) – teplota serveru, stav paměti, raid, metriky síťových zařízení.
Integrovali jsme Zabbix s telegramovým messengerem a Microsoft Teams, které jsou aktivně využívány v týmech. Zabbix pokrývá vrstvu skutečné sítě, hardwaru a některého softwaru, ale není to všelék. Tyto údaje obohacujeme o některé další služby. Například na hardwarové úrovni se přímo připojujeme přes API k našemu virtualizačnímu systému a sbíráme data.
Co jiného. Kromě Zabbixu používáme Prometheus, který nám umožňuje sledovat metriky v aplikaci dynamického prostředí. To znamená, že můžeme přijímat metriky aplikací přes koncový bod HTTP a nestarat se o to, které metriky do něj načíst a které ne. Na základě těchto dat lze vytvořit analytické dotazy.
Zdroje dat pro další vrstvy, například obchodní metriky, jsou rozděleny do tří složek.
Za prvé jsou to externí obchodní systémy, Google Analytics, metriky shromažďujeme z protokolů. Z nich získáváme data o aktivních uživatelích, konverzích a všem dalším, co s podnikáním souvisí. Za druhé, toto je monitorovací systém uživatelského rozhraní. Mělo by být popsáno podrobněji.
Kdysi jsme začínali s ručním testováním a přerostlo to v automatické testy funkčnosti a integrací. Z toho jsme udělali monitoring, ponechali jsme pouze hlavní funkcionalitu a spoléhali na markery, které jsou co nejstabilnější a v průběhu času se často nemění.
Nová týmová struktura znamená, že všechny aplikační aktivity jsou omezeny na produktové týmy, takže jsme přestali provádět čistě testování. Místo toho jsme provedli monitorování uživatelského rozhraní z testů napsaných v Javě, Selenium a Jenkins (používá se jako systém pro spouštění a generování reportů).
Měli jsme spoustu testů, ale nakonec jsme se rozhodli jít na hlavní silnici, metriku nejvyšší úrovně. A pokud budeme mít hodně specifických testů, bude těžké udržovat data aktuální. Každé další vydání výrazně naruší celý systém a jediné, co uděláme, je oprava. Zaměřili jsme se proto na velmi zásadní věci, které se málokdy mění, a pouze je sledujeme.
Konečně, za třetí, zdrojem dat je centralizovaný logovací systém. Pro protokoly používáme Elastic Stack a poté můžeme tato data stáhnout do našeho monitorovacího systému pro obchodní metriky. K tomu všemu máme vlastní službu Monitoring API napsanou v Pythonu, která se přes API dotazuje na jakékoli služby a sbírá z nich data do Zabbixu.
Dalším nepostradatelným atributem monitorování je vizualizace. Náš je založen na Grafaně. Mezi ostatními vizualizačními systémy vyniká tím, že umožňuje vizualizovat metriky z různých zdrojů dat na řídicím panelu. Můžeme shromažďovat metriky nejvyšší úrovně pro internetový obchod, například počet objednávek zadaných za poslední hodinu z DBMS, metriky výkonu pro operační systém, na kterém tento internetový obchod běží, ze Zabbix a metriky pro instance této aplikace. od Promethea. A to vše bude na jednom přístrojovém panelu. Přehledné a dostupné.
Ještě poznámka k bezpečnosti – v současné době dokončujeme systém, který později integrujeme s globálním monitorovacím systémem. Podle mého názoru hlavní problémy, kterým e-commerce v oblasti informační bezpečnosti čelí, souvisejí s roboty, parsery a hrubou silou. Na to musíme dávat pozor, protože to vše může kriticky ovlivnit jak fungování našich aplikací, tak naši pověst z obchodního hlediska. A se zvoleným stackem tyto úkoly úspěšně pokrýváme.
Dalším důležitým bodem je, že aplikační vrstva je sestavena společností Prometheus. On sám je také integrován se Zabbixem. A máme tu také sitespeed, službu, která nám umožňuje zobrazit parametry jako rychlost načítání naší stránky, úzká místa, vykreslování stránky, načítání skriptů atd., je také integrované API. Naše metriky se tedy shromažďují v Zabbixu a podle toho odtud také upozorňujeme. Všechna upozornění se aktuálně odesílají na hlavní způsoby odesílání (zatím je to e-mail a telegram, nedávno byl také připojen MS Teams). Plánuje se upgradovat upozorňování do takového stavu, aby chytré roboty fungovaly jako služba a poskytovaly monitorovací informace všem zainteresovaným produktovým týmům.
Pro nás jsou důležité metriky nejen pro jednotlivé informační systémy, ale i obecné metriky pro celou infrastrukturu, kterou aplikace využívají: clustery fyzických serverů, na kterých běží virtuální stroje, traffic balancery, Network Load Balancery, samotná síť, využití komunikačních kanálů . Plus metriky pro naše vlastní datová centra (máme jich několik a infrastruktura je poměrně rozsáhlá).
Výhodou našeho monitorovacího systému je, že s jeho pomocí vidíme zdravotní stav všech systémů a můžeme hodnotit jejich vliv na sebe navzájem i na sdílené zdroje. A v konečném důsledku nám umožňuje zapojit se do plánování zdrojů, což je také naše odpovědnost. Spravujeme serverové zdroje – fond v rámci e-commerce, zprovozňujeme a vyřazujeme z provozu nové vybavení, nakupujeme další nové vybavení, provádíme audit využití zdrojů atd. Každý rok týmy plánují nové projekty, vyvíjejí své systémy a je pro nás důležité poskytnout jim zdroje.
A pomocí metrik vidíme trend ve spotřebě zdrojů našimi informačními systémy. A na jejich základě můžeme něco plánovat. Na úrovni virtualizace shromažďujeme data a vidíme informace o dostupném množství zdrojů podle datového centra. A již uvnitř datového centra můžete vidět recyklaci, skutečnou distribuci a spotřebu zdrojů. Navíc jak se samostatnými servery, tak virtuálními stroji a clustery fyzických serverů, na kterých se všechny tyto virtuální stroje energicky točí.
Vyhlídky
Nyní máme jádro systému jako celek hotové, ale je tu ještě spousta věcí, na kterých je potřeba ještě zapracovat. Minimálně se jedná o vrstvu zabezpečení informací, ale je také důležité dosáhnout sítě, vyvinout varování a vyřešit problém korelace. Máme mnoho vrstev a systémů a na každé vrstvě je mnohem více metrik. Ukazuje se, že je to matrjoška do stupně matrjošky.
Naším úkolem je nakonec učinit správná upozornění. Pokud byl například problém s hardwarem, opět s virtuálním strojem a byla tam důležitá aplikace a služba nebyla nijak zálohována. Zjistíme, že virtuální stroj zemřel. Pak vás obchodní metriky upozorní: uživatelé někam zmizeli, není konverze, UI v rozhraní je nedostupné, software a služby také zemřely.
V této situaci budeme dostávat spam z upozornění, a to již nezapadá do formátu správného monitorovacího systému. Nabízí se otázka korelace. V ideálním případě by proto náš monitorovací systém měl říci: „Kluci, váš fyzický stroj zemřel a spolu s ním i tato aplikace a tyto metriky“ s pomocí jednoho upozornění, místo toho, aby nás zuřivě bombardoval stovkou upozornění. Mělo by hlásit to hlavní - příčinu, která pomáhá rychle odstranit problém díky jeho lokalizaci.
Náš systém oznámení a zpracování výstrah je postaven na XNUMXhodinové službě horké linky. Všechna upozornění, která jsou považována za nutnost a jsou zahrnuta v kontrolním seznamu, se odesílají tam. Každá výstraha musí mít popis: co se stalo, co to vlastně znamená, co to ovlivňuje. A také odkaz na dashboard a návod, co v tomto případě dělat.
To vše je o požadavcích na vytvoření výstrahy. Pak se situace může vyvíjet dvěma směry – buď je problém a je potřeba ho řešit, nebo došlo k poruše v monitorovacím systému. Ale v každém případě musíte jít a přijít na to.
V průměru nyní dostáváme kolem stovky upozornění denně, vezmeme-li v úvahu skutečnost, že korelace upozornění ještě není správně nakonfigurována. A pokud potřebujeme provést technické práce a něco násilně vypneme, jejich počet se výrazně zvýší.
Kromě monitorování systémů, které provozujeme, a sběru metrik, které jsou z naší strany považovány za důležité, nám monitorovací systém umožňuje shromažďovat data pro produktové týmy. Mohou ovlivnit skladbu metrik v rámci námi sledovaných informačních systémů.
Náš kolega může přijít a požádat o přidání nějaké metriky, která bude užitečná pro nás i pro tým. Nebo například tým nemusí mít dostatek základních metrik, které máme, potřebuje sledovat některé specifické. V Grafaně vytváříme prostor pro každý tým a udělujeme administrátorská práva. Také, pokud tým potřebuje dashboardy, ale sám to neumí/nevědí, jak to udělat, pomůžeme mu.
Vzhledem k tomu, že stojíme mimo tok tvorby hodnot týmu, jejich vydávání a plánování, postupně docházíme k závěru, že vydání všech systémů jsou bezproblémová a lze je denně zavádět bez koordinace s námi. A je pro nás důležité tato vydání monitorovat, protože by mohly potenciálně ovlivnit provoz aplikace a něco pokazit, a to je kritické. Ke správě releasů používáme Bamboo, odkud dostáváme data přes API a vidíme, které releasy byly vydány v jakých informačních systémech a jejich stav. A nejdůležitější je v jakém čase. Hlavní kritické metriky překrýváme značkami vydání, což je vizuálně velmi orientační v případě problémů.
Tímto způsobem můžeme vidět korelaci mezi novými verzemi a vznikajícími problémy. Hlavní myšlenkou je pochopit, jak systém funguje na všech vrstvách, rychle lokalizovat problém a stejně rychle jej opravit. Často se totiž stává, že nejvíce času nezabere řešení problému, ale hledání příčiny.
A v této oblasti se chceme v budoucnu zaměřit na proaktivitu. V ideálním případě bych o blížícím se problému rád věděl předem a ne až poté, abych mu mohl spíše předejít, než ho řešit. Někdy dochází k falešným poplachům monitorovacího systému, a to jak lidskou chybou, tak změnami v aplikaci.A na tom pracujeme, odlaďujeme to a snažíme se na to upozornit uživatele, kteří to u nás používají před jakoukoliv manipulací s monitorovacím systémem , nebo tyto činnosti provádět v technickém okně.
Takže systém byl spuštěn a od začátku jara úspěšně funguje... a vykazuje velmi reálné zisky. Toto samozřejmě není jeho finální verze, budeme zavádět mnoho dalších užitečných funkcí. Ale právě teď, s tolika integracemi a aplikacemi, je automatizace monitorování opravdu nevyhnutelná.
Pokud také sledujete velké projekty s velkým počtem integrací, napište do komentářů, co jste na to našli.
Zdroj: www.habr.com