Je monitorovanie mŕtve? — Nech žije monitorovanie

Od roku 2008 sa naša spoločnosť zaoberá predovšetkým správou infraštruktúry a nepretržitou technickou podporou webových projektov: máme viac ako 400 klientov, čo je asi 15 % ruského elektronického obchodu. V súlade s tým je podporovaná veľmi rôznorodá architektúra. Ak niečo spadne, sme povinní to do 15 minút opraviť. Aby ste však pochopili, že došlo k nehode, musíte projekt monitorovať a reagovať na incidenty. Ako na to?

Domnievam sa, že existuje problém zorganizovať správny monitorovací systém. Ak by neboli žiadne problémy, moja reč by pozostávala z jednej tézy: „Nainštalujte si Prometheus + Grafana a zásuvné moduly 1, 2, 3.“ Žiaľ, takto to už nefunguje. A hlavným problémom je, že všetci naďalej veria v niečo, čo existovalo v roku 2008, pokiaľ ide o softvérové ​​komponenty.

K organizácii monitorovacieho systému by som si dovolil povedať, že... projekty s kompetentným monitorovaním neexistujú. A situácia je taká zlá, že ak niečo spadne, existuje riziko, že to zostane nepovšimnuté - koniec koncov, každý si je istý, že „všetko je monitorované“.
Možno je všetko monitorované. Ale ako?

Všetci sme sa stretli s podobným príbehom: istý devops, istý admin pracuje, príde k nim vývojový tím a povie – „sme uvoľnení, teraz monitorujte.“ Monitorovať čo? Ako to funguje?

OK. Sledujeme staromódny spôsob. A už sa to mení a ukázalo sa, že ste monitorovali službu A, ktorá sa stala službou B, ktorá interaguje so službou C. Vývojový tím vám však povie: „Nainštalujte softvér, mala by monitorovať všetko!“

Čo sa teda zmenilo? - Všetko sa zmenilo!

2008 Všetko je v poriadku

Existuje niekoľko vývojárov, jeden server, jeden databázový server. Všetko ide odtiaľto. Máme nejaké informácie, inštalujeme zabbix, Nagios, kaktusy. A potom nastavíme jasné upozornenia na CPU, na prevádzku disku a na miesto na disku. Vykonávame aj niekoľko manuálnych kontrol, aby sme sa uistili, že stránka reaguje a objednávky prichádzajú do databázy. A to je všetko – sme viac-menej chránení.

Ak porovnáme množstvo práce, ktorú správca vykonal pri poskytovaní monitorovania, potom 98% z toho bolo automatických: osoba, ktorá vykonáva monitorovanie, musí pochopiť, ako nainštalovať Zabbix, ako ho nakonfigurovať a nakonfigurovať upozornenia. A 2% - na externé kontroly: že stránka odpovie a odošle požiadavku do databázy, že prišli nové objednávky.

2010 Záťaž rastie

Začíname škálovať web, pridávame vyhľadávač. Chceme sa uistiť, že katalóg produktov obsahuje všetky produkty. A to vyhľadávanie produktov funguje. Že databáza funguje, že sa robia objednávky, že stránka odpovedá externe a odpovedá z dvoch serverov a že používateľ nie je vyhodený zo stránky, kým je rebalancovaný na iný server atď. Subjektov je viac.

Okrem toho subjekt spojený s infraštruktúrou stále zostáva najväčším v hlave manažéra. Stále mám v hlave myšlienku, že osoba, ktorá vykonáva monitorovanie, je osoba, ktorá nainštaluje zabbix a bude ho môcť nakonfigurovať.

Zároveň sa však objavuje práca na vykonávaní externých kontrol, na vytváraní súboru vyhľadávacích indexovacích skriptov, súboru skriptov na kontrolu, či sa vyhľadávanie mení počas procesu indexovania, súboru skriptov, ktoré kontrolujú, či sa tovar prenáša do donášková služba a pod. a tak ďalej.

Poznámka: „Súbor skriptov“ som napísal 3-krát. To znamená, že osoba zodpovedná za monitorovanie už nie je tá, ktorá si zabbix jednoducho nainštaluje. Toto je osoba, ktorá začína kódovať. V mysliach tímu sa však zatiaľ nič nezmenilo.

Svet sa však mení, je čoraz zložitejší. Pridaná je virtualizačná vrstva a niekoľko nových systémov. Začnú sa vzájomne ovplyvňovať. Kto povedal „vonia ako mikroslužby?“ Každá služba však stále vyzerá ako webová stránka samostatne. Môžeme sa na ňu obrátiť a pochopiť, že poskytuje potrebné informácie a funguje sama. A ak ste správcom neustále zapojeným do projektu, ktorý sa vyvíja 5-7-10 rokov, tieto znalosti sa hromadia: objaví sa nová úroveň - uvedomili ste si to, objaví sa ďalšia úroveň - uvedomili ste si to...

Málokedy však niekto sprevádza projekt 10 rokov.

Životopis monitorujúceho

Predpokladajme, že ste prišli do nového startupu, ktorý okamžite zamestnal 20 vývojárov, napísal 15 mikroslužieb a ste admin, ktorému bolo povedané: „Build CI/CD. Prosím." Postavili ste CI/CD a zrazu počujete: „Je pre nás ťažké pracovať s produkciou v „kocke“, bez toho, aby sme pochopili, ako v nej bude aplikácia fungovať. Urobte nám pieskovisko v rovnakej „kocke“.
V tejto kocke vytvoríte pieskovisko. Okamžite vám povedia: „Chceme scénickú databázu, ktorá sa aktualizuje každý deň z produkcie, aby sme pochopili, že funguje s databázou, ale zároveň nekazí databázu produkcie.“

V tomto všetkom žijete. Do vydania zostávajú 2 týždne, povedia vám: „Teraz to všetko monitorujme...“ To znamená. monitorovať infraštruktúru klastrov, monitorovať architektúru mikroslužieb, monitorovať prácu s externými službami...

A moji kolegovia berú z hlavy obvyklú schému a hovoria: „No, tu je všetko jasné! Nainštalujte si program, ktorý toto všetko bude monitorovať.“ Áno, áno: Prometheus + Grafana + pluginy.
A dodávajú: "Máte dva týždne, uistite sa, že je všetko v bezpečí."

V mnohých projektoch, ktoré vidíme, je na monitorovanie pridelená jedna osoba. Predstavte si, že chceme zamestnať človeka na monitoring na 2 týždne a napíšeme mu životopis. Aké schopnosti by mal mať tento človek vzhľadom na všetko, čo sme doteraz povedali?

• Musí rozumieť monitorovaniu a špecifikám prevádzky železiarskej infraštruktúry.
• Musí rozumieť špecifikám monitorovania Kubernetes (a každý chce ísť do „kocky“, pretože od všetkého môžete abstrahovať, skrývať sa, pretože so zvyškom sa už postará správca) – samotného, ​​jeho infraštruktúry a rozumieť tomu, ako monitorovať aplikácie. vnútri.
• Musí chápať, že služby medzi sebou komunikujú špeciálnymi spôsobmi, a poznať špecifiká vzájomného pôsobenia služieb. Je celkom možné vidieť projekt, kde niektoré služby komunikujú synchrónne, pretože iná cesta neexistuje. Napríklad backend ide cez REST, cez gRPC do katalógovej služby, dostane zoznam produktov a vráti ho späť. Tu sa už nevieš dočkať. A s ostatnými službami to funguje asynchrónne. Preneste objednávku doručovacej službe, pošlite list atď.
  Pravdepodobne ste už z toho všetkého odplávali? A admin, ktorý to potrebuje sledovať, bol ešte zmätenejší.
• Musí vedieť správne plánovať a plánovať – keďže práce je čoraz viac.
• Z vytvorenej služby si teda musí vytvoriť stratégiu, aby pochopil, ako ju konkrétne monitorovať. Potrebuje porozumieť architektúre projektu a jeho vývoju + rozumieť technológiám používaným pri vývoji.

Spomeňme si na úplne normálny prípad: niektoré služby sú v PHP, niektoré služby sú v Go, niektoré služby sú v JS. Nejako navzájom spolupracujú. Odtiaľ pochádza pojem „mikroservis“: existuje toľko individuálnych systémov, že vývojári nedokážu pochopiť projekt ako celok. Jedna časť tímu píše služby v JS, ktoré fungujú samé od seba a nevedia, ako funguje zvyšok systému. Druhá časť píše služby v Pythone a nezasahuje do fungovania iných služieb; sú izolované vo svojej vlastnej oblasti. Tretím je písanie služieb v PHP alebo niečo iné.
Všetkých týchto 20 ľudí je rozdelených do 15 služieb a je tu len jeden admin, ktorý tomu všetkému musí rozumieť. Stop! práve sme rozdelili systém na 15 mikroslužieb, pretože 20 ľudí nedokáže pochopiť celý systém.

Ale treba to nejako sledovať...

Aký je výsledok? Výsledkom je, že je tu jeden človek, ktorý príde na všetko, čo celý tím vývojárov nedokáže pochopiť a zároveň musí vedieť a vedieť aj to, čo sme naznačili vyššie – hardvérová infraštruktúra, Kubernetes infraštruktúra atď.

Čo môžem povedať... Houston, máme problémy.

Monitorovanie moderného softvérového projektu je samo o sebe softvérovým projektom

Z falošného presvedčenia, že monitorovanie je softvér, rozvíjame vieru v zázraky. Ale zázraky sa, bohužiaľ, nedejú. Nemôžete nainštalovať zabbix a očakávať, že všetko bude fungovať. Nemá zmysel inštalovať Grafana a dúfať, že bude všetko ok. Väčšinu času zaberie organizovanie kontrol fungovania služieb a ich vzájomnej interakcie, kontrola fungovania externých systémov. V skutočnosti 90% času nestrávite písaním skriptov, ale vývojom softvéru. A mal by to riešiť tím, ktorý rozumie práci na projekte.
Ak sa v tejto situácii dostane do monitorovania jedna osoba, dôjde ku katastrofe. Čo sa deje všade.

Existuje napríklad viacero služieb, ktoré medzi sebou komunikujú cez Kafku. Objednávka prišla, Kafkovi sme poslali správu o objednávke. Existuje služba, ktorá si vypočuje informácie o objednávke a odošle tovar. Existuje služba, ktorá si vypočuje informácie o objednávke a pošle používateľovi list. A potom sa objaví veľa ďalších služieb a začneme byť zmätení.

A ak to dáte aj adminovi a vývojárom vo fáze, keď do vydania zostáva krátky čas, človek bude musieť pochopiť celý tento protokol. Tie. Projekt takéhoto rozsahu si vyžaduje značné množstvo času, čo by malo byť zohľadnené pri vývoji systému.
No veľmi často, najmä v startupoch, vidíme, ako sa monitoring odkladá na neskôr. „Teraz urobíme Proof of Concept, spustíme s ním, necháme ho padnúť – sme pripravení obetovať. A potom to všetko budeme monitorovať." Keď (alebo ak) projekt začne zarábať peniaze, podnik chce pridať ešte viac funkcií – pretože už začal fungovať, a preto je potrebné ho rozšíriť! A ste v bode, kde musíte najskôr sledovať všetko predchádzajúce, čo nezaberie 1% času, ale oveľa viac. A mimochodom, vývojári budú potrební na monitorovanie a je jednoduchšie nechať ich pracovať na nových funkciách. Výsledkom je, že sa píšu nové funkcie, všetko sa pokazí a vy ste v nekonečnej patovej situácii.

Ako teda monitorovať projekt od začiatku a čo robiť, ak dostanete projekt, ktorý je potrebné monitorovať, ale neviete, kde začať?

Najprv musíte plánovať.

Lyrická odbočka: veľmi často začínajú monitorovaním infraštruktúry. Napríklad máme Kubernetes. Začnime inštaláciou Prometheus s Grafanou, inštaláciou doplnkov na monitorovanie „kocky“. Nielen vývojári, ale aj správcovia majú nešťastnú prax: „Nainštalujeme tento doplnok, ale doplnok pravdepodobne vie, ako na to.“ Ľudia radšej začínajú jednoduchými a priamočiarymi než dôležitými činmi. A monitorovanie infraštruktúry je jednoduché.

Najprv sa rozhodnite, čo a ako chcete monitorovať, a potom vyberte nástroj, pretože iní ľudia nemôžu myslieť za vás. A mali by? Iní ľudia si mysleli o univerzálnom systéme - alebo vôbec nerozmýšľali, keď bol tento plugin napísaný. A to, že má tento plugin 5 tisíc používateľov, ešte neznamená, že je užitočný. Možno sa stanete 5001. jednoducho preto, že tam už predtým bolo 5000 ľudí.

Ak začnete monitorovať infraštruktúru a backend vašej aplikácie prestane reagovať, všetci používatelia stratia spojenie s mobilnou aplikáciou. Objaví sa chyba. Prídu za vami a povedia: "Aplikácia nefunguje, čo tu robíš?" - "Monitorujeme." - "Ako monitorujete, ak nevidíte, že aplikácia nefunguje?"

1. Domnievam sa, že musíte začať sledovať presne od vstupného bodu používateľa. Ak používateľ nevidí, že aplikácia funguje, je to tak, je to zlyhanie. A monitorovací systém by mal na to upozorniť ako prvý.
2. A až potom môžeme monitorovať infraštruktúru. Alebo to urobte paralelne. S infraštruktúrou je to jednoduchšie – tu môžeme konečne nainštalovať zabbix.
3. A teraz musíte ísť ku koreňom aplikácie, aby ste pochopili, kde veci nefungujú.

Mojou hlavnou myšlienkou je, že monitorovanie by malo prebiehať súbežne s procesom vývoja. Ak odpútate pozornosť monitorovacieho tímu na iné úlohy (tvorba CI/CD, sandboxing, reorganizácia infraštruktúry), monitorovanie začne meškať a vývoj už možno nikdy nedobehnete (alebo ho skôr či neskôr budete musieť zastaviť).

Všetko podľa úrovní

Takto vidím organizáciu monitorovacieho systému.

1) Úroveň aplikácie:

• Monitorovanie obchodnej logiky aplikácií;
• Monitorovanie zdravotných metrík služieb;
• monitorovanie integrácie.

2) Úroveň infraštruktúry:

• monitorovanie úrovne orchestrácie;
• Monitorovanie systémového softvéru;
• monitorovanie hladiny železa.

3) Opäť úroveň aplikácie - ale ako inžiniersky produkt:

• zhromažďovanie a monitorovanie aplikačných protokolov;
• APM;
• sledovanie.

4) Upozornenie:

• organizácia varovného systému;
• organizácia systému povinností;
• organizácia „vedomostnej základne“ a pracovného toku na spracovanie incidentov.

Je to dôležité,: do varovania sa dostaneme nie potom, ale hneď! Nie je potrebné spustiť monitorovanie a „nejako neskôr“ zistiť, kto bude dostávať upozornenia. Koniec koncov, čo je úlohou monitorovania: pochopiť, kde v systéme niečo nefunguje správne, a dať o tom vedieť správnym ľuďom. Ak to necháte až na koniec, potom tí správni ľudia budú vedieť, že niečo nie je v poriadku, iba ak zavolajú „nič nám nefunguje“.

Aplikačná vrstva – monitorovanie obchodnej logiky

Tu hovoríme o kontrole samotnej skutočnosti, že aplikácia funguje pre používateľa.

Táto úroveň by sa mala vykonať vo fáze vývoja. Napríklad máme podmienený Prometheus: ide na server, ktorý robí kontroly, stiahne koncový bod a koncový bod ide a kontroluje API.

Keď sa programátori často pýtajú na monitorovanie domovskej stránky, aby sa ubezpečili, že stránka funguje, dajú kliku, ktorú možno stiahnuť zakaždým, keď sa potrebujú uistiť, že rozhranie API funguje. A programátori v tejto chvíli stále berú a píšu /api/test/helloworld
Jediný spôsob, ako sa uistiť, že všetko funguje? - Nie!

• Vytváranie takýchto kontrol je v podstate úlohou vývojárov. Unit testy by mali písať programátori, ktorí píšu kód. Pretože ak to prezradíte správcovi, "Kámo, tu je zoznam protokolov API pre všetkých 25 funkcií, prosím, sledujte všetko!" - nič nevyjde.
• Ak vytlačíte „hello world“, nikto sa nikdy nedozvie, že API by malo a funguje. Každá zmena API musí viesť k zmene kontrol.
• Ak už máte takýto problém, zastavte funkcie a prideľte vývojárov, ktorí budú písať tieto kontroly, alebo akceptujte straty, akceptujte, že sa nič nekontroluje a zlyhá.

Technické tipy:

• Nezabudnite zorganizovať externý server na organizovanie kontrol – musíte si byť istí, že váš projekt je prístupný vonkajšiemu svetu.
• Organizujte kontroly v rámci celého protokolu API, nielen jednotlivých koncových bodov.
• Vytvorte koncový bod prometheus s výsledkami testu.

Aplikačná vrstva – monitorovanie zdravotných metrík

Teraz hovoríme o externých zdravotných metrikách služieb.

Rozhodli sme sa, že všetky „handle“ aplikácie budeme monitorovať pomocou externých kontrol, ktoré voláme z externého monitorovacieho systému. Ale toto sú „rúčky“, ktoré používateľ „vidí“. Chceme si byť istí, že naše služby samotné fungujú. Tu je lepší príbeh: K8s má zdravotné kontroly, takže aspoň samotná „kocka“ môže byť presvedčená, že služba funguje. Ale polovica šekov, ktoré som videl, je rovnaký nápis „ahoj svet“. Tie. Takže po nasadení raz potiahne, odpovedal, že všetko je v poriadku - to je všetko. A služba, ak poskytuje svoje vlastné API, má obrovské množstvo vstupných bodov pre to isté API, ktoré je tiež potrebné monitorovať, pretože chceme vedieť, že funguje. A už to sledujeme vo vnútri.

Ako to správne technicky implementovať: každá služba odhaľuje koncový bod o jej aktuálnom výkone a v grafoch Grafany (alebo akejkoľvek inej aplikácie) vidíme stav všetkých služieb.

• Každá zmena API musí viesť k zmene kontrol.
• Okamžite vytvorte novú službu s metrikami zdravia.
• Správca môže prísť za vývojármi a opýtať sa „pridajte mi pár funkcií, aby som všetkému porozumel a pridajte o tom informácie do svojho monitorovacieho systému“. Ale vývojári zvyčajne odpovedajú: "Dva týždne pred vydaním nič nepridáme."
  Dajte vedieť vývojovým manažérom, že dôjde k takýmto stratám, dajte vedieť aj manažmentu vývojových manažérov. Pretože keď všetko padne, stále bude niekto volať a požadovať monitorovanie „neustále klesajúcej služby“ (c)
• Mimochodom, prideľte vývojárom písanie pluginov pre Grafana - to bude dobrá pomoc pre správcov.

Aplikačná vrstva – Monitorovanie integrácie

Monitorovanie integrácie sa zameriava na monitorovanie komunikácie medzi kritickými podnikovými systémami.

Ide napríklad o 15 služieb, ktoré medzi sebou komunikujú. Toto už nie sú samostatné stránky. Tie. nemôžeme stiahnuť službu samostatne, získať /helloworld a pochopiť, že služba beží. Pretože objednávacia webová služba musí odoslať informáciu o objednávke do autobusu – z autobusu, musí túto správu dostať skladová služba a ďalej s ňou pracovať. A to musí služba distribúcie emailov nejako ďalej spracovať atď.

V súlade s tým nemôžeme pochopiť, štukajúc do každej jednotlivej služby, že to všetko funguje. Pretože máme určitú zbernicu, cez ktorú všetko komunikuje a interaguje.
Preto by táto etapa mala označovať etapu testovania služieb pre interakciu s inými službami. Nie je možné organizovať monitorovanie komunikácie monitorovaním sprostredkovateľa správ. Ak existuje služba, ktorá dáta vydáva a služba, ktorá ich prijíma, pri sledovaní brokera uvidíme len dáta, ktoré lietajú zo strany na stranu. Aj keď sa nám nejakým spôsobom podarilo interne monitorovať interakciu týchto údajov – že určitý výrobca zverejní údaje, niekto si ich prečíta, tento tok ide ďalej Kafkovi – stále nám to neposkytne informáciu, ak jedna služba poslala správu v jednej verzii , no druhá služba túto verziu nečakala a preskočila ju. Nedozvieme sa o tom, pretože služby nám povedia, že všetko funguje.

Čo odporúčam urobiť:

• Pre synchrónnu komunikáciu: koncový bod odosiela požiadavky na súvisiace služby. Tie. vezmeme tento koncový bod, natiahneme skript do služby, ktorý prejde ku všetkým bodom a povie: „Môžem tam ťahať a ťahať tam, môžem ťahať tam...“
• Pre asynchrónnu komunikáciu: prichádzajúce správy – koncový bod kontroluje zbernicu pre testovacie správy a zobrazuje stav spracovania.
• Pre asynchrónnu komunikáciu: odchádzajúce správy - koncový bod posiela testovacie správy na zbernicu.

Ako sa zvyčajne stáva: máme službu, ktorá hádže dáta do zbernice. Prichádzame do tejto služby a žiadame vás, aby ste nám povedali o jej stave integrácie. A ak služba potrebuje vytvoriť správu niekde ďalej (WebApp), potom vytvorí túto testovaciu správu. A ak spustíme službu na strane OrderProcessing, tá najskôr zverejní to, čo môže uverejniť nezávisle, a ak sú tam nejaké závislé veci, potom prečíta súbor testovacích správ zo zbernice, pochopí, že ich môže spracovať, nahlásiť a , ak je to potrebné, uverejnite ich ďalej a o tom hovorí - všetko je v poriadku, žijem.

Veľmi často počujeme otázku „ako to môžeme otestovať na bojových údajoch?“ Hovoríme napríklad o rovnakej objednávkovej službe. Objednávka posiela správy do skladu, kde je tovar odpísaný: nemôžeme to otestovať na bojových údajoch, pretože „môj tovar bude odpísaný!“ Riešenie: Naplánujte si celý tento test na začiatku. Máte tiež testy jednotiek, ktoré robia zosmiešňovanie. Urobte to teda na hlbšej úrovni, kde máte komunikačný kanál, ktorý nepoškodí fungovanie podniku.

Úroveň infraštruktúry

Monitorovanie infraštruktúry je niečo, čo sa už dlho považuje za samotné monitorovanie.

• Monitorovanie infraštruktúry môže a malo by sa spustiť ako samostatný proces.
• Nemali by ste začať s monitorovaním infraštruktúry na spustenom projekte, aj keď naozaj chcete. Toto je bolesť pre všetkých devopov. “Najskôr budem monitorovať klaster, budem monitorovať infraštruktúru” – t.j. Po prvé, bude sledovať, čo leží nižšie, ale neprejde do aplikácie. Pretože aplikácia je pre devops nepochopiteľná vec. Bolo mu to prezradené a on nechápe, ako to funguje. Ale rozumie infraštruktúre a začína s ňou. Ale nie - vždy musíte najprv sledovať aplikáciu.
• Nepreháňajte to s počtom upozornení. Vzhľadom na zložitosť moderných systémov výstrahy neustále lietajú a s touto kopou výstrah sa musíte nejako zžiť. A privolaná osoba, ktorá sa pozrie na sto ďalších upozornení, rozhodne: „Nechcem na to myslieť. Upozornenia by mali upozorňovať iba na kritické veci.

Aplikačná úroveň ako obchodná jednotka

Kľúčové body:

• ELK. Toto je priemyselný štandard. Ak z nejakého dôvodu nezhromažďujete protokoly, začnite s tým okamžite.
• APM. Externé APM ako spôsob rýchleho ukončenia monitorovania aplikácií (NewRelic, BlackFire, Datadog). Túto vec si môžete dočasne nainštalovať, aby ste aspoň nejako pochopili, čo sa s vami deje.
• Sledovanie. V desiatkach mikroslužieb musíte všetko dohľadať, pretože požiadavka už nežije sama. Je veľmi ťažké pridať neskôr, takže je lepšie okamžite naplánovať sledovanie vo vývoji - to je práca a užitočnosť vývojárov. Ak ste to ešte neimplementovali, implementujte to! Viď Jaeger/Zipkin

Upozornenie

• Organizácia notifikačného systému: v podmienkach monitorovania množstva vecí by mal existovať jednotný systém zasielania notifikácií. Môžete v Grafane. Na Západe každý používa PagerDuty. Upozornenia by mali byť jasné (napr. odkiaľ prišli...). A je vhodné kontrolovať, či vôbec prichádzajú notifikácie
• Organizácia systému povinností: upozornenia by sa nemali posielať každému (buď budú všetci reagovať v dave, alebo nikto nebude reagovať). Aj vývojári musia byť na pohotovosti: určite si definujte oblasti zodpovednosti, urobte jasné pokyny a napíšte do nich, komu presne volať v pondelok a stredu a komu volať v utorok a piatok (inak nikomu nezavolajú ani v v prípade veľkého problému – budú sa vás báť zobudiť alebo vyrušiť: ľudia vo všeobecnosti neradi volajú a zobudia iných ľudí, najmä v noci). A vysvetlite, že žiadosť o pomoc nie je indikátorom neschopnosti („Žiadam o pomoc, to znamená, že som zlý pracovník“), povzbudzujte žiadosti o pomoc.
• Organizácia „znalostnej základne“ a pracovného postupu na spracovanie incidentu: pre každý vážny incident by sa mala naplánovať pitva a ako dočasné opatrenie by sa mali zaznamenať činnosti, ktoré incident vyriešia. A urobte si z praxe, že opakované upozornenia sú hriechom; musia byť opravené v kóde alebo infraštruktúre.

Zásobník technológií

Predstavme si, že náš zásobník je takýto:

• zber dát - Prometheus + Grafana;
• log analýza - ELK;
• pre APM alebo sledovanie - Jaeger (Zipkin).

Výber možností nie je kritický. Pretože ak ste na začiatku pochopili, ako monitorovať systém a zapísali ste si plán, potom si začnete vyberať nástroje podľa svojich požiadaviek. Otázkou je, čo ste sa rozhodli sledovať ako prvé. Pretože možno nástroj, ktorý ste si vybrali na začiatku, vôbec nevyhovuje vašim požiadavkám.

Niekoľko technických bodov, ktoré v poslednej dobe vidím všade:

Do Kubernetesa sa tlačí Prometheus – kto to vymyslel?! Ak váš klaster zlyhá, čo urobíte? Ak máte vo vnútri komplexný klaster, potom by mal existovať nejaký druh monitorovacieho systému vo vnútri klastra a nejaký vonku, ktorý bude zbierať údaje z vnútra klastra.

Vo vnútri klastra zbierame polená a všetko ostatné. Ale monitorovací systém musí byť vonku. Veľmi často sa v klastri, kde je interne nainštalovaný Promtheus, nachádzajú aj systémy, ktoré vykonávajú externé kontroly fungovania stránky. Čo ak vaše spojenie s vonkajším svetom kleslo a aplikácia nefunguje? Ukazuje sa, že vo vnútri je všetko v poriadku, ale používateľom to nijako neuľahčuje.

Závery

• Monitorovanie vývoja nie je inštalácia pomocných programov, ale vývoj softvérového produktu. 98% dnešného monitorovania je kódovanie. Kódovanie v službách, kódovanie externých kontrol, kontrola externých služieb a to je všetko.
• Nestrácajte čas vývojárov monitorovaním: môže im to zabrať až 30 % práce, ale stojí to za to.
• Devops, nebojte sa, že nemôžete niečo sledovať, pretože niektoré veci sú úplne iným spôsobom myslenia. Neboli ste programátor a monitorovanie práce je presne ich úlohou.
• Ak projekt už beží a nie je monitorovaný (a vy ste manažér), prideľte zdroje na monitorovanie.
• Ak je produkt už vo výrobe a ste devops, ktorému bolo povedané, aby ste „nastavili monitorovanie“ - skúste manažmentu vysvetliť, o čom som to všetko napísal.

Toto je rozšírená verzia správy na konferencii Saint Highload++.

Ak vás zaujímajú moje nápady a myšlienky na to a súvisiace témy, tak tu môžete čítať kanál ????

Zdroj: hab.com