O vytvorení monitorovacieho systému sme uvažovali vo fáze formovania produktových tímov. Ukázalo sa, že náš biznis – vykorisťovanie – do týchto tímov nespadá. prečo je to tak?
Faktom je, že všetky naše tímy sú postavené na jednotlivých informačných systémoch, mikroslužbách a frontoch, takže tímy nevidia celkový stav celého systému ako celku. Napríklad nemusia vedieť, ako nejaká malá časť v hlbokom backende ovplyvňuje frontend. Ich rozsah záujmu je obmedzený na systémy, s ktorými je ich systém integrovaný. Ak tím a jeho služba A nemajú takmer žiadne spojenie so službou B, potom je takáto služba pre tím takmer neviditeľná.
Náš tím zase pracuje so systémami, ktoré sú navzájom veľmi silne integrované: existuje medzi nimi veľa spojení, ide o veľmi veľkú infraštruktúru. A od všetkých týchto systémov (ktorých máme mimochodom obrovské množstvo) závisí fungovanie internetového obchodu.
Ukazuje sa teda, že naše oddelenie nepatrí do žiadneho tímu, ale nachádza sa trochu bokom. V celom tomto príbehu je našou úlohou komplexne pochopiť, ako informačné systémy fungujú, ich funkcionalitu, integrácie, softvér, sieť, hardvér a ako to všetko navzájom súvisí.
Platforma, na ktorej fungujú naše internetové obchody, vyzerá takto:
- predné
- stredná kancelária
- back office
Akokoľvek by sme chceli, nestane sa, že by všetky systémy fungovali hladko a bezchybne. Pointa je opäť v počte systémov a integrácií – pri niečom, ako je ten náš, sú niektoré incidenty nevyhnutné, a to aj napriek kvalite testovania. Navyše ako v rámci samostatného systému, tak aj z hľadiska ich integrácie. A treba sledovať stav celej platformy komplexne a nie len jej jednotlivých častí.
V ideálnom prípade by monitorovanie zdravotného stavu na celej platforme malo byť automatizované. A k monitorovaniu sme dospeli ako k nevyhnutnej súčasti tohto procesu. Spočiatku bol postavený len pre frontovú časť, zatiaľ čo sieťoví špecialisti, správcovia softvéru a hardvéru mali a majú svoje vlastné monitorovacie systémy po vrstvách. Všetci títo ľudia sledovali monitoring len na svojej úrovni, nikto nemal ani komplexné pochopenie.
Ak sa napríklad zrúti virtuálny stroj, vo väčšine prípadov o tom vie iba správca zodpovedný za hardvér a virtuálny stroj. V takýchto prípadoch frontový tím videl samotný fakt pádu aplikácie, no nemal údaje o páde virtuálneho stroja. A správca môže vedieť, kto je zákazník a mať približnú predstavu o tom, čo momentálne beží na tomto virtuálnom stroji, za predpokladu, že ide o nejaký veľký projekt. S najväčšou pravdepodobnosťou nevie o malých. V každom prípade musí správca ísť za majiteľom a opýtať sa, čo bolo na tomto stroji, čo treba obnoviť a čo treba zmeniť. A ak sa niečo naozaj vážne pokazilo, začali behať v kruhu – pretože nikto nevidel systém ako celok.
V konečnom dôsledku takéto nesúrodé príbehy ovplyvňujú celý frontend, používateľov a našu hlavnú obchodnú funkciu – online predaj. Keďže nie sme súčasťou tímu, ale venujeme sa prevádzke všetkých ecommerce aplikácií v rámci internetového obchodu, dali sme si za úlohu vytvoriť komplexný monitorovací systém pre ecommerce platformu.
Štruktúra systému a zásobník
Začali sme identifikáciou niekoľkých monitorovacích vrstiev pre naše systémy, v rámci ktorých by sme potrebovali zbierať metriky. A toto všetko bolo potrebné skombinovať, čo sme urobili v prvej fáze. Teraz v tejto fáze dokončujeme kolekciu metrík najvyššej kvality vo všetkých našich vrstvách, aby sme vytvorili koreláciu a pochopili, ako sa systémy navzájom ovplyvňujú.
Nedostatočný komplexný monitoring v počiatočných fázach spúšťania aplikácie (keďže sme ju začali budovať, keď bola väčšina systémov vo výrobe) viedol k tomu, že sme mali značný technický dlh na nastavení monitoringu celej platformy. Nemohli sme si dovoliť zamerať sa na nastavenie monitoringu pre jeden IS a detailne preň rozpracovať monitoring, keďže zvyšok systémov by zostal nejaký čas bez monitoringu. Na vyriešenie tohto problému sme identifikovali zoznam najpotrebnejších metrík na hodnotenie stavu informačného systému podľa vrstiev a začali ho implementovať.
Preto sa rozhodli zjesť slona po častiach.
Náš systém pozostáva z:
- hardvér;
- operačný systém;
- softvér;
- časti používateľského rozhrania v monitorovacej aplikácii;
- obchodné metriky;
- integračné aplikácie;
- informačná bezpečnosť;
- siete;
- vyrovnávač dopravy.
V centre tohto systému je samotné monitorovanie. Na všeobecné pochopenie stavu celého systému potrebujete vedieť, čo sa deje s aplikáciami na všetkých týchto vrstvách a v celej množine aplikácií.
Takže o stohu.
Používame open source softvér. V centre máme Zabbix, ktorý využívame predovšetkým ako výstražný systém. Každý vie, že je ideálny na monitorovanie infraštruktúry. Čo to znamená? Presne tie nízkoúrovňové metriky, ktoré má každá spoločnosť, ktorá si spravuje vlastné dátové centrum (a Sportmaster má svoje dátové centrá) – teplota servera, stav pamäte, nájazd, metriky sieťových zariadení.
Zabbix sme integrovali s telegramovým messengerom a Microsoft Teams, ktoré sa aktívne využívajú v tímoch. Zabbix pokrýva vrstvu skutočnej siete, hardvéru a niektorého softvéru, ale nie je všeliekom. Tieto údaje obohacujeme o niektoré ďalšie služby. Napríklad na hardvérovej úrovni sa priamo pripájame cez API k nášmu virtualizačnému systému a zbierame dáta.
Čo ešte. Okrem Zabbixu používame Prometheus, ktorý nám umožňuje sledovať metriky v aplikácii dynamického prostredia. To znamená, že môžeme prijímať metriky aplikácie cez koncový bod HTTP a nestarať sa o to, ktoré metriky doň načítať a ktoré nie. Na základe týchto údajov je možné vytvoriť analytické dopyty.
Zdroje údajov pre ďalšie vrstvy, napríklad obchodné metriky, sú rozdelené do troch komponentov.
Po prvé, ide o externé obchodné systémy, Google Analytics, metriky zhromažďujeme z protokolov. Z nich získavame dáta o aktívnych užívateľoch, konverziách a všetkom ostatnom, čo súvisí s biznisom. Po druhé, toto je monitorovací systém používateľského rozhrania. Malo by to byť podrobnejšie opísané.
Kedysi sme začínali s manuálnym testovaním a prerástlo to do automatických testov funkčnosti a integrácií. Z toho sme spravili monitoring, pričom sme ponechali len hlavnú funkcionalitu, a spoliehali sme sa na čo najstabilnejšie markery, ktoré sa v priebehu času často nemenia.
Nová tímová štruktúra znamená, že všetky aplikačné aktivity sú obmedzené na produktové tímy, takže sme prestali robiť čisté testovanie. Namiesto toho sme urobili monitorovanie používateľského rozhrania z testov napísaných v jazyku Java, Selenium a Jenkins (používaný ako systém na spúšťanie a generovanie správ).
Mali sme veľa testov, ale nakoniec sme sa rozhodli ísť na hlavnú cestu, metriku najvyššej úrovne. A ak máme veľa špecifických testov, bude ťažké udržiavať dáta aktuálne. Každé ďalšie vydanie výrazne naruší celý systém a jediné, čo urobíme, je oprava. Zamerali sme sa preto na veľmi zásadné veci, ktoré sa málokedy menia a iba ich sledujeme.
Nakoniec, po tretie, zdrojom údajov je centralizovaný systém protokolovania. Pre protokoly používame Elastic Stack a potom môžeme tieto údaje stiahnuť do nášho monitorovacieho systému pre obchodné metriky. K tomu všetkému máme vlastnú službu Monitoring API napísanú v Pythone, ktorá cez API dopytuje akékoľvek služby a zbiera z nich dáta do Zabbixu.
Ďalším nevyhnutným atribútom monitorovania je vizualizácia. Naša je založená na Grafane. Medzi ostatnými vizualizačnými systémami vyniká tým, že umožňuje vizualizovať metriky z rôznych zdrojov údajov na dashboarde. Môžeme zhromažďovať metriky najvyššej úrovne pre internetový obchod, napríklad počet objednávok zadaných za poslednú hodinu z DBMS, metriky výkonu pre operačný systém, na ktorom je tento internetový obchod spustený, zo Zabbix a metriky pre inštancie tejto aplikácie. od Promethea. A to všetko bude na jednej palubnej doske. Prehľadné a dostupné.
Dovoľte mi poznamenať k bezpečnosti – v súčasnosti dokončujeme systém, ktorý neskôr integrujeme s globálnym monitorovacím systémom. Podľa môjho názoru hlavné problémy, ktorým e-commerce čelí v oblasti informačnej bezpečnosti, súvisia s botmi, parsermi a hrubou silou. Musíme na to dávať pozor, pretože toto všetko môže z obchodného hľadiska kriticky ovplyvniť fungovanie našich aplikácií aj našu reputáciu. A so zvoleným zásobníkom tieto úlohy úspešne pokrývame.
Ďalším dôležitým bodom je, že aplikačnú vrstvu zostavuje Prometheus. On sám je tiež integrovaný so Zabbixom. A máme tu aj sitespeed, službu, ktorá nám umožňuje zobraziť parametre ako rýchlosť načítania našej stránky, úzke miesta, vykresľovanie stránky, načítavanie skriptov atď., taktiež je integrované API. Naše metriky sa teda zhromažďujú v Zabbixe a podľa toho odtiaľ tiež upozorňujeme. Všetky upozornenia sa momentálne odosielajú na hlavné spôsoby odosielania (zatiaľ je to e-mail a telegram, nedávno bol pripojený aj MS Teams). Plánuje sa upgradovať upozorňovanie do takého stavu, aby inteligentné roboty fungovali ako služba a poskytovali monitorovacie informácie všetkým zainteresovaným produktovým tímom.
Metriky sú pre nás dôležité nielen pre jednotlivé informačné systémy, ale aj všeobecné metriky pre celú infraštruktúru, ktorú aplikácie využívajú: klastre fyzických serverov, na ktorých bežia virtuálne stroje, balancéry prevádzky, Network Load Balancery, samotná sieť, využitie komunikačných kanálov. . Plus metriky pre vlastné dátové centrá (máme ich niekoľko a infraštruktúra je dosť veľká).
Výhody nášho monitorovacieho systému spočívajú v tom, že s jeho pomocou vidíme zdravotný stav všetkých systémov a vieme posúdiť ich vplyv na seba a na zdieľané zdroje. A v konečnom dôsledku nám to umožňuje zapojiť sa do plánovania zdrojov, čo je tiež naša zodpovednosť. Spravujeme serverové zdroje – fond v rámci elektronického obchodu, uvádzame do prevádzky a vyraďujeme nové zariadenia, nakupujeme ďalšie nové zariadenia, vykonávame audit využívania zdrojov atď. Každý rok tímy plánujú nové projekty, vyvíjajú svoje systémy a je pre nás dôležité poskytnúť im zdroje.
A pomocou metrík vidíme trend spotreby zdrojov našimi informačnými systémami. A na základe nich môžeme niečo plánovať. Na úrovni virtualizácie zbierame údaje a vidíme informácie o dostupnom množstve zdrojov podľa dátového centra. A už vo vnútri dátového centra môžete vidieť recykláciu, skutočnú distribúciu a spotrebu zdrojov. Navyše so samostatnými servermi aj virtuálnymi strojmi a klastrami fyzických serverov, na ktorých sa všetky tieto virtuálne stroje energicky otáčajú.
Vyhliadky
Teraz máme jadro systému ako celok hotové, no je tu ešte veľa vecí, na ktorých treba ešte popracovať. Prinajmenšom ide o vrstvu informačnej bezpečnosti, ale je tiež dôležité dostať sa do siete, rozvinúť výstrahy a vyriešiť problém korelácie. Máme veľa vrstiev a systémov a na každej vrstve je oveľa viac metrík. Ukazuje sa, že je to matrioška na stupeň matriošky.
Našou úlohou je v konečnom dôsledku urobiť správne upozornenia. Napríklad, ak sa vyskytol problém s hardvérom, opäť s virtuálnym strojom a bola tam dôležitá aplikácia a služba nebola žiadnym spôsobom zálohovaná. Zistili sme, že virtuálny stroj zomrel. Potom vás obchodné metriky upozornia: používatelia niekam zmizli, neexistuje konverzia, UI v rozhraní je nedostupné, zomrel aj softvér a služby.
V tejto situácii budeme dostávať spam z upozornení, a to už nezapadá do formátu správneho monitorovacieho systému. Vynára sa otázka korelácie. Preto by v ideálnom prípade mal náš monitorovací systém povedať: „Chlapci, váš fyzický stroj zomrel a spolu s ním aj táto aplikácia a tieto metriky“ pomocou jedného upozornenia, namiesto toho, aby nás zúrivo bombardoval stovkou upozornení. Mal by hlásiť hlavnú vec - príčinu, ktorá pomáha rýchlo odstrániť problém kvôli jeho lokalizácii.
Náš systém upozornení a spracovanie upozornení je postavené na XNUMX-hodinovej horúcej linke. Všetky upozornenia, ktoré sa považujú za nevyhnutné a sú zahrnuté v kontrolnom zozname, sa odosielajú tam. Každé upozornenie musí mať popis: čo sa stalo, čo to vlastne znamená, čo to ovplyvňuje. A tiež odkaz na palubnú dosku a pokyny, čo robiť v tomto prípade.
Toto je všetko o požiadavkách na vytvorenie výstrahy. Potom sa situácia môže vyvíjať dvoma smermi – buď je problém a treba ho riešiť, alebo došlo k poruche v monitorovacom systéme. Ale v každom prípade musíte ísť a prísť na to.
V súčasnosti dostávame v priemere asi sto upozornení denne, berúc do úvahy skutočnosť, že korelácia upozornení ešte nebola správne nakonfigurovaná. A ak potrebujeme vykonať technické práce a niečo násilne vypneme, ich počet sa výrazne zvýši.
Okrem monitorovania systémov, ktoré prevádzkujeme, a zberu metrík, ktoré sú z našej strany považované za dôležité, nám monitorovací systém umožňuje zbierať dáta pre produktové tímy. Môžu ovplyvniť skladbu metrík v rámci informačných systémov, ktoré sledujeme.
Náš kolega môže prísť a požiadať o pridanie metriky, ktorá bude užitočná pre nás aj pre tím. Alebo napríklad tím nemusí mať dostatok základných metrík, ktoré máme, musí sledovať niektoré špecifické. V Grafane vytvárame priestor pre každý tím a udeľujeme administrátorské práva. Tiež, ak tím potrebuje dashboardy, ale sám to nevie/nevie, ako to urobiť, pomôžeme mu.
Keďže stojíme mimo toku tvorby hodnôt tímu, ich vydávania a plánovania, postupne prichádzame k záveru, že vydania všetkých systémov sú bezproblémové a možno ich zavádzať denne bez koordinácie s nami. A je dôležité, aby sme tieto vydania monitorovali, pretože by mohli potenciálne ovplyvniť fungovanie aplikácie a niečo pokaziť, a to je kritické. Na správu vydaní používame Bamboo, odkiaľ dostávame dáta cez API a vidíme, ktoré vydania boli vydané v ktorých informačných systémoch a ich stav. A najdôležitejšie je, v akom čase. Na hlavné kritické metriky prekrývame značky vydania, čo je v prípade problémov vizuálne veľmi orientačné.
Takto môžeme vidieť koreláciu medzi novými vydaniami a vznikajúcimi problémami. Hlavnou myšlienkou je pochopiť, ako systém funguje vo všetkých vrstvách, rýchlo lokalizovať problém a rovnako rýchlo ho opraviť. Často sa totiž stáva, že najviac času zaberá nie riešenie problému, ale hľadanie príčiny.
A v tejto oblasti sa chceme v budúcnosti zamerať na proaktivitu. V ideálnom prípade by som chcel vedieť o blížiacom sa probléme vopred a nie dodatočne, aby som mu mohol skôr predchádzať ako ho riešiť. Niekedy sa vyskytnú falošné poplachy monitorovacieho systému, či už kvôli ľudskej chybe, alebo kvôli zmenám v aplikácii.A na tom pracujeme, odlaďujeme to a snažíme sa na to upozorniť používateľov, ktorí to u nás používajú pred akoukoľvek manipuláciou s monitorovacím systémom , alebo vykonávať tieto činnosti v technickom okienku.
Takže systém bol spustený a úspešne funguje od začiatku jari... a vykazuje veľmi reálne zisky. Samozrejme, toto nie je jeho finálna verzia, predstavíme mnoho ďalších užitočných funkcií. Ale práve teraz, s toľkými integráciami a aplikáciami, je automatizácia monitorovania skutočne nevyhnutná.
Ak sledujete aj veľké projekty so značným počtom integrácií, napíšte do komentárov, akú striebornú guľku ste na to našli.
Zdroj: hab.com