Meghalt a monitorozás? — Éljen a megfigyelés

Cégünk 2008 óta elsősorban infrastruktúra-menedzsmenttel és webes projektek éjjel-nappali technikai támogatásával foglalkozik: több mint 400 ügyfelünk van, ami az orosz e-kereskedelem mintegy 15%-a. Ennek megfelelően egy nagyon változatos architektúra támogatott. Ha valami leesik, kötelesek vagyunk 15 percen belül megjavítani. De annak megértéséhez, hogy baleset történt, figyelemmel kell kísérnie a projektet, és reagálnia kell az eseményekre. Hogy kell ezt csinálni?

Úgy gondolom, hogy probléma van a megfelelő monitoring rendszer megszervezésével. Ha nem lett volna baj, akkor a beszédem egy tézisből állna: „Kérjük, telepítse a Prometheus + Grafana és az 1., 2., 3. bővítményeket.” Sajnos ez már nem így működik. A fő probléma pedig az, hogy mindenki továbbra is hisz valamiben, ami 2008-ban is létezett, ami a szoftverkomponenseket illeti.

A monitoring rendszer megszervezésével kapcsolatban megkockáztatom, hogy... kompetens monitoringgal rendelkező projektek nem léteznek. És a helyzet annyira rossz, hogy ha valami leesik, fennáll a veszélye annak, hogy észrevétlen marad - elvégre mindenki biztos abban, hogy „mindent figyelnek”.
Talán mindent figyelnek. De hogyan?

Mindannyian találkoztunk már a következőhöz hasonló történettel: egy bizonyos devops, egy bizonyos adminisztrátor dolgozik, odajön hozzájuk egy fejlesztőcsapat, és azt mondja: "Kiengedtük, most figyelj." Mit figyelni? Hogyan működik?

RENDBEN. A régi módon figyelünk. És ez már változik, és kiderült, hogy figyelte az A szolgáltatást, amiből B szolgáltatás lett, amely kölcsönhatásba lép a C szolgáltatással. De a fejlesztőcsapat azt mondja: „Telepítse a szoftvert, annak mindent figyelnie kell!”

Szóval mi változott? - Minden megváltozott!

2008 Minden rendben

Van pár fejlesztő, egy szerver, egy adatbázis szerver. Innen megy minden. Van némi információnk, telepítünk zabbixot, Nagiot, kaktuszt. Ezután egyértelmű riasztásokat állítunk be a CPU-ra, a lemez működésére és a lemezterületre. Néhány kézi ellenőrzést is végzünk, hogy megbizonyosodjunk arról, hogy a webhely válaszol, és megérkeznek-e a megrendelések az adatbázisba. És ennyi – többé-kevésbé védettek vagyunk.

Ha összehasonlítjuk az adminisztrátor által akkor végzett munka mennyiségét a felügyelet biztosítása érdekében, akkor ennek 98%-a automatikus volt: a felügyeletet végző személynek értenie kell a Zabbix telepítését, konfigurálását és a riasztások beállítását. És 2% - külső ellenőrzésekre: hogy az oldal válaszol-e és kérelmet küld-e az adatbázisnak, érkeztek-e új megrendelések.

2010 A terhelés nő

Megkezdjük az internet méretezését, hozzáadunk egy keresőt. Biztosítani szeretnénk, hogy a termékkatalógus minden terméket tartalmazzon. És ez a termékkeresés működik. Hogy az adatbázis működik, rendelések készülnek-e, hogy az oldal külsőleg válaszol és két szerverről válaszol, és a felhasználót ne rúgják ki az oldalról, amíg az egy másik szerverre egyensúlyoz, stb. Több entitás is van.

Ráadásul az infrastruktúrához kapcsolódó entitás továbbra is a legnagyobb a vezető fejében. Még mindig ott van a fejemben az a gondolat, hogy a monitorozást az végzi, aki telepíti a zabbix-ot és be tudja állítani.

Ugyanakkor megjelenik a munka a külső ellenőrzések végrehajtásán, a keresési indexelő lekérdezési szkriptek készletének létrehozásán, egy olyan szkriptkészlet létrehozásán, amely ellenőrzi, hogy a keresés megváltozik-e az indexelési folyamat során, olyan szkriptek készletén, amelyek ellenőrzik, hogy az áruk átkerülnek-e a házhozszállítás stb. stb.

Megjegyzés: Háromszor írtam „a szkriptek sorozatát”. Vagyis a monitorozásért már nem az a felelős, aki egyszerűen telepíti a zabbixet. Ez az a személy, aki elkezdi a kódolást. De még semmi sem változott a csapat fejében.

De a világ változik, egyre bonyolultabbá válik. Egy virtualizációs réteg és számos új rendszer került hozzáadásra. Elkezdenek kölcsönhatásba lépni egymással. Ki mondta, hogy „mikroszolgáltatások szaga van?” De minden szolgáltatás külön-külön is webhelynek tűnik. Hozzá fordulhatunk és megérthetjük, hogy megadja a szükséges információkat, és önmagában is működik. És ha állandóan egy 5-7-10 éve fejlődő projektben vesz részt adminisztrátor, akkor ez a tudás felhalmozódik: megjelenik egy új szint - rájöttél, megjelenik egy másik szint - rájöttél...

De ritkán kísér valaki egy projektet 10 évig.

Felügyelő önéletrajza

Tegyük fel, hogy egy új startuphoz érkezett, amely azonnal felvett 20 fejlesztőt, 15 mikroszolgáltatást írt, és Ön egy adminisztrátor, akinek azt mondják: „Build CI/CD. Kérem." Ön elkészítette a CI/CD-t, és hirtelen ezt hallja: „Nehéz a termeléssel „kockában” dolgozni anélkül, hogy megértenénk, hogyan fog működni benne az alkalmazás. Csinálj nekünk homokozót ugyanabban a „kockában”.
Ebben a kockában homokozót készítesz. Rögtön azt mondják: "Olyan színpadi adatbázist akarunk, amely minden nap frissül a gyártástól kezdve, hogy megértsük, működik az adatbázison, ugyanakkor ne rontsa el a gyártási adatbázist."

Te ebben az egészben élsz. 2 hét van hátra a megjelenésig, azt mondják: „Most figyeljük mindezt...” Azaz. figyeli a klaszter infrastruktúráját, figyeli a mikroszolgáltatási architektúrát, figyeli a külső szolgáltatásokkal végzett munkát...

A kollégáim pedig kiveszik a fejükből a szokásos sémát, és azt mondják: „Nos, itt minden világos! Telepítsen egy programot, amely mindezt felügyeli." Igen, igen: Prometheus + Grafana + bővítmények.
És hozzáteszik: "Két heted van, győződjön meg róla, hogy minden biztonságban van."

Sok olyan projektben, amit látunk, egy személyt jelölnek ki a megfigyelésre. Képzeljük el, hogy fel akarunk venni egy személyt, aki 2 hétre monitorozást végez, és írunk neki önéletrajzot. Milyen képességekkel kell rendelkeznie ennek az embernek, mindazt figyelembe véve, amit eddig mondtunk?

• Meg kell értenie a vasi infrastruktúra felügyeletét és működésének sajátosságait.
• Meg kell értenie a Kubernetes figyelésének sajátosságait (és mindenki a „kockába” akar menni, mert mindentől elvonatkoztathat, elrejthet, mert a többivel az adminisztrátor foglalkozik) - önmagával, az infrastruktúrájával, és meg kell értenie, hogyan kell figyelni az alkalmazásokat. belül.
• Meg kell értenie, hogy a szolgáltatások különleges módon kommunikálnak egymással, és ismernie kell a szolgáltatások egymás közötti interakciójának sajátosságait. Nagyon is lehet látni olyan projektet, ahol egyes szolgáltatások szinkronban kommunikálnak, mert nincs más mód. Például a háttérrendszer a REST-en keresztül a gRPC-n keresztül a katalógusszolgáltatáshoz megy, megkapja a termékek listáját, és visszaküldi azt. Alig várhatsz itt. Más szolgáltatásokkal pedig aszinkron módon működik. Vigye át a rendelést a futárszolgálathoz, küldjön levelet stb.
  Valószínűleg már megúsztad ezt az egészet? És az admin, akinek ezt figyelnie kell, még jobban összezavarodott.
• Tudnia kell helyesen tervezni és tervezni – ahogy a munka egyre több lesz.
• Ezért stratégiát kell alkotnia a létrehozott szolgáltatásból, hogy megértse, hogyan kell azt konkrétan figyelemmel kísérni. Szüksége van a projekt architektúrájának és fejlesztésének megértésére + a fejlesztés során használt technológiák megértésére.

Emlékezzünk egy teljesen normális esetre: néhány szolgáltatás PHP-ben van, néhány szolgáltatás Go-ban, néhány szolgáltatás JS-ben van. Valahogy együttműködnek egymással. Innen származik a „mikroszolgáltatás” kifejezés: annyi egyedi rendszer létezik, hogy a fejlesztők nem értik a projekt egészét. A csapat egy része olyan szolgáltatásokat ír JS-ben, amelyek önállóan működnek, és nem tudják, hogyan működik a rendszer többi része. A másik rész Pythonban ír szolgáltatásokat, és nem zavarja a többi szolgáltatás működését, el vannak különítve a saját területükön. A harmadik a szolgáltatások írása PHP-ben vagy valami másban.
Mind ezt a 20 embert 15 szolgáltatásra osztják, és csak egy adminisztrátornak kell megértenie mindezt. Állj meg! csak 15 mikroszolgáltatásra osztottuk a rendszert, mert 20 ember nem érti az egész rendszert.

De ezt valahogy figyelni kell...

mi az eredmény? Ebből kifolyólag van egy ember, aki mindennel előjön, amit az egész fejlesztőcsapat nem ért, ugyanakkor tudnia kell és meg is kell tudnia csinálni, amit fentebb jeleztünk - hardver infrastruktúra, Kubernetes infrastruktúra stb.

Mit mondjak... Houston, problémáink vannak.

Egy modern szoftverprojekt monitorozása önmagában is szoftverprojekt

Abból a tévhitből, hogy a monitorozás szoftver, kialakul a csodákba vetett hit. De csodák, sajnos, nem történnek. Nem telepítheti a zabbixot, és elvárhatja, hogy minden működjön. Nincs értelme telepíteni a Grafanát és remélni, hogy minden rendben lesz. Az idő nagy részét a szolgáltatások működésének és egymás közötti interakciójának ellenőrzésére, a külső rendszerek működésének ellenőrzésére fordítjuk. Valójában az idő 90%-át nem szkriptek írására, hanem szoftverfejlesztésre fordítják. És ezt egy olyan csapatnak kell kezelnie, amely érti a projekt munkáját.
Ha ebben a helyzetben egy embert megfigyelés alá vetnek, akkor katasztrófa történik. Ami mindenhol megtörténik.

Például több szolgáltatás is kommunikál egymással a Kafkán keresztül. Megérkezett a rendelés, üzenetet küldtünk a rendelésről Kafkának. Van egy szolgáltatás, amely meghallgatja a rendeléssel kapcsolatos információkat, és kiszállítja az árut. Van egy szolgáltatás, amely meghallgatja a megrendeléssel kapcsolatos információkat, és levelet küld a felhasználónak. Aztán megjelenik még egy csomó szolgáltatás, és kezdünk összezavarodni.

És ha ezt is megadja az adminisztrátornak és a fejlesztőknek abban a szakaszban, amikor már egy kis idő van hátra a kiadásig, akkor a személynek meg kell értenie ezt a teljes protokollt. Azok. Egy ilyen léptékű projekt jelentős időt vesz igénybe, és ezt figyelembe kell venni a rendszerfejlesztésben.
De nagyon gyakran, különösen az induló vállalkozásoknál, azt látjuk, hogy a monitorozást későbbre halasztják. „Most elkészítjük a Proof of Concept-et, azzal indulunk, hagyjuk, hogy leessen – készek vagyunk az áldozatra. És akkor mindent figyelemmel kísérünk.” Amikor (vagy ha) a projekt elkezd pénzt keresni, a vállalkozás még több funkciót szeretne hozzáadni – mivel elkezdett működni, ezért tovább kell fejleszteni! És ott van a pont, ahol először minden korábbit figyelnie kell, ami nem az idő 1%-át, hanem sokkal többet vesz igénybe. És mellesleg a monitorozáshoz fejlesztőkre lesz szükség, és könnyebb őket hagyni, hogy új funkciókon dolgozzanak. Ennek eredményeként új funkciókat írnak fel, minden elromlik, és Ön végtelenül patthelyzetbe került.

Tehát hogyan lehet egy projektet az elejétől kezdve figyelemmel kísérni, és mit kell tenni, ha olyan projektet kap, amelyet monitorozni kell, de nem tudja, hol kezdje?

Először is meg kell tervezni.

Lírai kitérő: nagyon gyakran az infrastruktúra megfigyelésével kezdik. Például van Kubernetes. Kezdjük a Prometheus és a Grafana telepítésével, a „kocka” megfigyelésére szolgáló bővítmények telepítésével. Nemcsak a fejlesztők, hanem az adminisztrátorok is alkalmazzák a következő szerencsétlen gyakorlatot: „Telepítjük ezt a bővítményt, de a bővítmény valószínűleg tudja, hogyan kell csinálni.” Az emberek szeretnek az egyszerű és egyértelmű dolgokkal kezdeni, nem pedig a fontos cselekedetekkel. Az infrastruktúra felügyelete pedig egyszerű.

Először döntse el, mit és hogyan szeretne felügyelni, majd válasszon eszközt, mert mások nem tudnak helyette gondolkodni. És kellene? Mások egy univerzális rendszerre gondoltak – vagy egyáltalán nem gondolkodtak, amikor ezt a bővítményt írták. És attól, hogy ennek a bővítménynek 5 ezer felhasználója van, még nem jelenti azt, hogy bármi haszna van. Talán te leszel az 5001. egyszerűen azért, mert korábban már 5000 ember volt ott.

Ha elkezdi figyelni az infrastruktúrát, és az alkalmazás háttérrendszere nem válaszol, minden felhasználó elveszíti kapcsolatát a mobilalkalmazással. Hiba jelenik meg. Odajönnek hozzád, és azt mondják: „Nem működik az alkalmazás, mit keresel itt?” – Figyeljük. — "Hogyan figyeli, ha nem látja, hogy az alkalmazás nem működik?!"

1. Úgy gondolom, hogy a megfigyelést pontosan a felhasználó belépési pontjától kell elkezdeni. Ha a felhasználó nem látja, hogy az alkalmazás működik, akkor ez az, ez meghibásodás. A megfigyelőrendszernek pedig először erre kell figyelmeztetnie.
2. És csak ezután tudjuk felügyelni az infrastruktúrát. Vagy csináld párhuzamosan. Az infrastruktúrával egyszerűbb – itt végre telepíthetjük a zabbix-ot.
3. És most el kell mennie az alkalmazás gyökereihez, hogy megértse, hol nem működnek a dolgok.

A fő elképzelésem az, hogy a monitoring a fejlesztési folyamattal párhuzamosan menjen. Ha más feladatokra (CI/CD létrehozása, sandboxolás, infrastruktúra átszervezése) vonja el a felügyeleti csapat figyelmét, a monitorozás késni kezd, és lehet, hogy soha nem éri utol a fejlesztést (vagy előbb-utóbb le kell állítania).

Mindent szintek szerint

Én így látom egy monitoring rendszer megszervezését.

1) Alkalmazási szint:

• alkalmazások üzleti logikájának figyelése;
• szolgáltatások egészségügyi mutatóinak nyomon követése;
• integráció figyelése.

2) Infrastruktúra szintje:

• hangszerelési szint figyelése;
• rendszerszoftver-felügyelet;
• vasszint monitorozás.

3) Ismét az alkalmazási szint – de mérnöki termékként:

• alkalmazásnaplók gyűjtése és figyelése;
• APM;
• nyomon követése.

4) Figyelmeztetés:

• figyelmeztető rendszer szervezése;
• ügyeleti rendszer szervezése;
• „tudásbázis” és munkafolyamat szervezése az incidensek feldolgozásához.

Fontos: nem utána, hanem azonnal riasztásra jutunk! Nem kell elindítani a megfigyelést, és „valahogy később” kitalálni, hogy kik kapnak figyelmeztetést. Végül is mi a feladata a monitorozásnak: megérteni, hogy a rendszer hol működik rosszul, és erről a megfelelő embereket értesíteni. Ha ezt a végére hagyod, akkor a megfelelő emberek csak a „nekünk semmi sem megy” felhívásból tudják meg, hogy valami rosszul sül el.

Alkalmazási réteg – Üzleti logikai figyelés

Itt arról van szó, hogy ellenőrizzük, hogy az alkalmazás működik-e a felhasználó számára.

Ezt a szintet a fejlesztési szakaszban kell elvégezni. Például van egy feltételes Prometheusunk: elmegy a szerverhez, amelyik elvégzi az ellenőrzéseket, lekéri a végpontot, a végpont pedig ellenőrzi az API-t.

Amikor gyakran kérik, hogy figyeljék a kezdőlapot, hogy megbizonyosodjanak arról, hogy a webhely működik, a programozók olyan fogantyút adnak, amelyet minden alkalommal meg lehet húzni, hogy megbizonyosodjanak arról, hogy az API működik. És a programozók ebben a pillanatban még mindig veszik és írják az /api/test/helloworld fájlt
Az egyetlen módja annak, hogy minden működjön? - Nem!

• Az ilyen ellenőrzések elkészítése alapvetően a fejlesztők feladata. Az egységteszteket a kódot író programozóknak kell megírniuk. Mert ha kiszivárogtatja az adminisztrátornak: "Haver, itt van az API protokollok listája mind a 25 funkcióhoz, kérlek, figyelj mindent!" - semmi sem fog sikerülni.
• Ha kinyomtatja a „hello world”, senki sem fogja tudni, hogy az API-nak működnie kell, és működik. Minden API-módosításnak az ellenőrzések változásához kell vezetnie.
• Ha már van ilyen probléma, állítsa le a funkciókat, és jelölje ki azokat a fejlesztőket, akik megírják ezeket az ellenőrzéseket, vagy elfogadják a veszteségeket, fogadják el, hogy semmi sem kerül ellenőrzésre és meghiúsul.

Technikai tippek:

• Ügyeljen arra, hogy külső szervert szervezzen az ellenőrzések megszervezéséhez – biztosnak kell lennie abban, hogy projektje elérhető a külvilág számára.
• Az ellenőrzéseket a teljes API-protokollra kiterjedően megszervezheti, nem csak az egyes végpontokon.
• Hozzon létre egy prometheus-végpontot a teszteredményekkel.

Alkalmazási réteg – állapotmérők figyelése

Most a szolgáltatások külső egészségügyi mutatóiról beszélünk.

Úgy döntöttünk, hogy az alkalmazás összes „fogóját” külső ellenőrzésekkel figyeljük, amelyeket külső felügyeleti rendszerből hívunk meg. De ezek azok a „fogantyúk”, amelyeket a felhasználó „lát”. Biztosak akarunk lenni abban, hogy szolgáltatásaink maguk is működnek. Van itt egy jobb sztori: a K8s-ban van állapotfelmérés, így legalább maga a „kocka” meggyőződhet arról, hogy a szolgáltatás működik. De az általam látott csekk fele ugyanaz a nyomtatott „hello world”. Azok. Tehát a bevetés után egyszer meghúz, azt válaszolta, hogy minden rendben - ennyi. És a szolgáltatásnak, ha saját API-t biztosít, hatalmas számú belépési pontja van ugyanannak az API-nak, amit szintén figyelni kell, mert tudni akarjuk, hogy működik. És már odabent is figyeljük.

Hogyan kell ezt helyesen megvalósítani technikailag: minden szolgáltatás egy végpontot tesz közzé aktuális teljesítményéről, és a Grafana (vagy bármely más alkalmazás) grafikonjain láthatjuk az összes szolgáltatás állapotát.

• Minden API-módosításnak az ellenőrzések változásához kell vezetnie.
• Azonnal hozzon létre új szolgáltatást egészségügyi mutatók segítségével.
• Egy adminisztrátor eljöhet a fejlesztőkhöz, és megkérdezheti, hogy "adjon hozzá néhány funkciót, hogy mindent megértsek, és adjak hozzá információkat a felügyeleti rendszeremhez." De a fejlesztők általában azt válaszolják: "Két héttel a megjelenés előtt nem adunk hozzá semmit."
  Tudassák a fejlesztési vezetőkkel, hogy lesznek ilyen veszteségek, tudassa a fejlesztési vezetők vezetőivel is. Mert ha minden esik, valaki akkor is felhív, és követeli a „folyamatosan zuhanó szolgáltatás” figyelését (c)
• Mellesleg, rendelje meg a fejlesztőket, hogy bővítményeket írjanak a Grafana számára - ez jó segítség lesz az adminoknak.

Alkalmazási réteg – Integráció figyelése

Az integrációfigyelés az üzleti szempontból kritikus rendszerek közötti kommunikáció figyelésére összpontosít.

Például 15 szolgáltatás kommunikál egymással. Ezek már nem különálló oldalak. Azok. nem tudjuk lehúzni a szolgáltatást önmagában, kapjuk meg a /helloworld-t, és megértsük, hogy a szolgáltatás fut. Mivel a megrendelő webszolgáltatásnak információt kell küldenie a rendelésről a busznak - a buszról, a raktári szolgáltatásnak meg kell kapnia ezt az üzenetet, és tovább kell dolgoznia vele. És az e-mail terjesztési szolgáltatásnak ezt valahogy tovább kell feldolgoznia stb.

Ennek megfelelően nem érthetjük meg az egyes szolgáltatásokra piszkálva, hogy mindez működik. Mert van egy bizonyos buszunk, amelyen keresztül minden kommunikál és kölcsönhatásba lép.
Ezért ennek a szakasznak a szolgáltatások tesztelésének szakaszát kell kijelölnie más szolgáltatásokkal való interakcióhoz. Lehetetlen megszervezni a kommunikáció figyelését az üzenetközvetítő figyelésével. Ha van adatot kiadó és fogadó szolgáltatás, akkor a bróker figyelésekor csak az egyik oldalról a másikra repülõ adatokat látunk. Még ha valahogyan sikerült is belsőleg figyelnünk ezeknek az adatoknak a kölcsönhatását – hogy egy bizonyos gyártó feladja az adatokat, valaki elolvassa, ez az áramlás továbbra is a Kafkához megy –, ez akkor sem ad információt, ha egy szolgáltatás egy verzióban küldte el az üzenetet. , de a másik szolgáltatás nem erre a verzióra számított, és kihagyta. Erről nem fogunk tudni, mert a szolgálatok közölni fogják, hogy minden működik.

Amit ajánlok:

• Szinkron kommunikációhoz: a végpont kéréseket küld a kapcsolódó szolgáltatásokhoz. Azok. vesszük ezt a végpontot, húzunk egy szkriptet a szolgáltatáson belül, ami az összes pontra megy, és azt mondja: „Oda húzhatok, és oda húzhatok, oda húzhatok...”
• Aszinkron kommunikációhoz: bejövő üzenetek - a végpont ellenőrzi a buszt, hogy vannak-e tesztüzenetek, és megjeleníti a feldolgozás állapotát.
• Aszinkron kommunikációhoz: kimenő üzenetek – a végpont tesztüzeneteket küld a busznak.

Ahogy az lenni szokott: van egy szolgáltatásunk, amely adatokat dob ​​a buszba. Eljövünk ehhez a szolgáltatáshoz, és megkérjük, hogy meséljen az integrációs állapotáról. És ha a szolgáltatásnak valahol tovább kell üzenetet készítenie (WebApp), akkor ezt a tesztüzenetet fogja előállítani. És ha az OrderProcessing oldalon futtatunk egy szolgáltatást, akkor először kiír valamit, amit önállóan tud feladni, és ha vannak függő dolgok, akkor kiolvas egy sor tesztüzenetet a buszról, megérti, hogy képes feldolgozni, jelenteni. és ha kell, tedd tovább, és erre azt mondja: minden rendben, élek.

Nagyon gyakran halljuk a kérdést: „Hogyan tesztelhetjük ezt a harci adatokon?” Például ugyanarról a rendelési szolgáltatásról beszélünk. A megrendelés üzenetet küld annak a raktárnak, ahol az árut leírják: ezt nem tudjuk harci adatokon tesztelni, mert „leírják az árumat!” Megoldás: Tervezze meg az egész tesztet az elején. Vannak olyan egységtesztjei is, amelyek gúnyt űznek. Tehát tedd ezt egy mélyebb szinten, ahol olyan kommunikációs csatornád van, amely nem károsítja a vállalkozás működését.

Infrastruktúra réteg

Az infrastruktúra-monitoring olyan dolog, amit régóta magának a felügyeletnek tekintenek.

• Az infrastruktúra-felügyeletet külön folyamatként lehet és kell elindítani.
• Nem szabad infrastruktúra-felügyelettel kezdeni egy futó projektet, még akkor sem, ha nagyon szeretné. Ez fájdalom minden devop számára. „Először a klasztert, az infrastruktúrát figyelem” – azaz. Először is figyelni fogja az alábbiakat, de nem megy bele az alkalmazásba. Mert az alkalmazás a devops számára érthetetlen dolog. Kiszivárogtatta neki, és nem érti, hogyan működik. De érti az infrastruktúrát, és azzal kezdi. De nem – először mindig figyelnie kell az alkalmazást.
• Ne ess túlzásba a riasztások számával. Tekintettel a modern rendszerek bonyolultságára, a riasztások folyamatosan repülnek, és valahogy együtt kell élni ezzel a riasztáshalmazzal. És az ügyeletes személy, miután megnézett száz következő riasztást, úgy dönt: „Nem akarok rá gondolni”. A riasztásoknak csak kritikus dolgokról kell értesíteniük.

Alkalmazási szint, mint üzleti egység

Főbb pontok:

• JÁVORSZARVAS. Ez az ipari szabvány. Ha valamilyen okból nem összesíti a naplókat, azonnal kezdje el.
• APM. Külső APM-ek az alkalmazások figyelésének gyors lezárására (NewRelic, BlackFire, Datadog). Ideiglenesen telepítheti ezt a dolgot, hogy legalább valahogy megértse, mi történik veled.
• Nyomkövetés. A mikroszolgáltatások tucatjaiban mindent nyomon kell követni, mert a kérés már nem él magától. Nagyon nehéz később hozzáadni, ezért jobb, ha azonnal ütemezi a nyomkövetést a fejlesztés során - ez a fejlesztők munkája és hasznossága. Ha még nem valósítottad meg, valósítsd meg! Lásd Jaeger/Zipkin

Figyelmeztetés

• Értesítési rendszer felépítése: egy csomó dolog figyelésének feltételei között egységes rendszer kell az értesítések küldésére. Grafanában megteheti. Nyugaton mindenki a PagerDuty-t használja. A figyelmeztetéseknek egyértelműnek kell lenniük (pl. honnan érkeztek...). És célszerű ellenőrizni, hogy egyáltalán érkezzenek-e értesítések
• Ügyeleti rendszer szervezése: nem szabad mindenkinek riasztást küldeni (vagy tömegben mindenki reagál, vagy senki sem). A fejlesztőknek is készenlétben kell lenniük: feltétlenül határozzák meg a felelősségi köröket, adják meg az egyértelmű utasításokat, és írják bele, kit kell pontosan hívni hétfőn és szerdán, illetve kedden és pénteken (egyébként nem hívnak senkit sem nagy probléma esetén – félnek felébreszteni vagy zavarni: az emberek általában nem szeretnek felhívni és felébreszteni másokat, különösen éjszaka). És magyarázza el, hogy a segítségkérés nem a hozzá nem értés jelzője ("Segítséget kérek, ez azt jelenti, hogy rossz dolgozó vagyok"), bátorítsa a segítségkéréseket.
• „Tudásbázis” és munkafolyamat szervezése az incidensek feldolgozásához: minden súlyos incidenshez post mortem-et kell tervezni, és ideiglenes intézkedésként rögzíteni kell az incidenst megoldó intézkedéseket. És tegye gyakorlattá, hogy az ismételt figyelmeztetések bűnnek számítanak; kódban vagy infrastrukturális munkában rögzíteni kell őket.

Technológiai verem

Képzeljük el, hogy a stackünk a következő:

• adatgyűjtés - Prometheus + Grafana;
• log elemzés - ELK;
• APM-hez vagy Tracinghez - Jaeger (Zipkin).

Az opciók kiválasztása nem kritikus. Mert ha az elején megértette, hogyan kell felügyelni a rendszert, és felírt egy tervet, akkor elkezdi kiválasztani az igényeinek megfelelő eszközöket. A kérdés az, hogy mit választottál először a monitorozás mellett. Mert lehet, hogy az elején kiválasztott eszköz egyáltalán nem felel meg az Ön igényeinek.

Néhány technikai szempont, amit mostanában mindenhol látok:

Prométheuszt lökdösik Kubernetes belsejébe – ki találta ki ezt?! Ha a klaszter összeomlik, mit fog tenni? Ha van egy komplex fürt a belsejében, akkor a fürtön belül kell lennie valamilyen megfigyelő rendszernek, és kívülről is, amely adatokat gyűjt a fürtön belülről.

A klaszteren belül naplókat és minden mást gyűjtünk. De a megfigyelőrendszernek kívül kell lennie. Nagyon gyakran egy olyan klaszterben, ahol a Promtheus belül van telepítve, vannak olyan rendszerek is, amelyek külső ellenőrzéseket végeznek a webhely működésében. Mi van, ha megszakadt a kapcsolata a külvilággal, és az alkalmazás nem működik? Kiderült, hogy belül minden rendben van, de ez nem könnyíti meg a felhasználók dolgát.

Álláspontja

• A fejlesztés monitorozása nem segédprogramok telepítése, hanem egy szoftvertermék fejlesztése. A mai megfigyelés 98%-a kódolás. Kódolás szolgáltatásokban, külső ellenőrzések kódolása, külső szolgáltatások ellenőrzése, és ez minden.
• Ne pazarolja a fejlesztők idejét a monitorozásra: ez akár a munkájuk 30%-át is igénybe veheti, de megéri.
• Devops, ne aggódj, hogy valamit nem tudsz figyelni, mert néhány dolog teljesen más gondolkodásmódot jelent. Nem voltál programozó, és az ellenőrzési munka pontosan az ő feladatuk.
• Ha a projekt már fut, és nincs felügyelve (és Ön menedzser), rendeljen erőforrásokat a megfigyeléshez.
• Ha a termék már gyártásban van, és Ön egy devops, akinek azt mondták, hogy „beállítsa a monitoringot”, próbálja meg elmagyarázni a vezetőségnek, hogy miről írtam mindezt.

Ez a Saint Highload++ konferencián készült jelentés kiterjesztett változata.

Ha érdekelnek az ötleteim, gondolataim ezzel kapcsolatban és a kapcsolódó témákról, akkor itt megteheti olvassa el a csatornát ????

Forrás: will.com