Je spremljanje mrtvo? — Naj živi spremljanje

Od leta 2008 se naše podjetje ukvarja predvsem z upravljanjem infrastrukture in 400-urno tehnično podporo za spletne projekte: imamo več kot 15 strank, kar je približno 15% ruske elektronske trgovine. V skladu s tem je podprta zelo raznolika arhitektura. Če kaj pade, smo dolžni to popraviti v XNUMX minutah. Toda da bi razumeli, da se je zgodila nesreča, morate spremljati projekt in se odzvati na incidente. Kako to narediti?

Menim, da je problem v organizaciji ustreznega sistema spremljanja. Če ne bi bilo težav, bi bil moj govor sestavljen iz ene teze: "Prosimo, namestite Prometheus + Grafana in vtičnike 1, 2, 3." Žal tako ne gre več. In glavni problem je, da vsi še naprej verjamejo v nekaj, kar je obstajalo leta 2008, v smislu programskih komponent.

Glede organizacije sistema monitoringa bi si upal trditi, da ... projekti s kompetentnim monitoringom ne obstajajo. In razmere so tako slabe, da če nekaj pade, obstaja tveganje, da bo ostalo neopaženo - navsezadnje so vsi prepričani, da je "vse nadzorovano."
Morda se vse spremlja. Ampak kako?

Vsi smo se že srečali s takšno zgodbo: nek devops, nek admin dela, k njim pride razvojna ekipa in reče - "izpuščeni smo, zdaj spremljaj." Nadzorovati kaj? Kako deluje?

V REDU. Spremljamo na staromoden način. In že se spreminja in izkaže se, da ste spremljali storitev A, ki je postala storitev B, ki je v interakciji s storitvijo C. Toda razvojna ekipa vam reče: "Namestite programsko opremo, mora spremljati vse!"

Kaj se je torej spremenilo? - Vse se je spremenilo!

2008 Vse je vredu

Obstaja nekaj razvijalcev, en strežnik, en strežnik baze podatkov. Vse gre od tukaj. Imamo nekaj informacij, namestimo zabbix, Nagios, cacti. Nato nastavimo jasna opozorila o CPU, delovanju diska in prostoru na disku. Izvedemo tudi nekaj ročnih pregledov, da zagotovimo, da se spletno mesto odziva in da naročila prispejo v bazo podatkov. In to je to – bolj ali manj smo zaščiteni.

Če primerjamo količino dela, ki ga je skrbnik takrat opravil za zagotavljanje nadzora, je bilo 98 % tega avtomatskega: oseba, ki izvaja nadzor, mora razumeti, kako namestiti Zabbix, kako ga konfigurirati in konfigurirati opozorila. In 2% - za zunanje preglede: da se spletno mesto odzove in pošlje zahtevo v bazo podatkov, da so prispela nova naročila.

2010 Obremenitev narašča

Začenjamo širiti splet in dodajamo iskalnik. Želimo zagotoviti, da katalog izdelkov vsebuje vse izdelke. In to iskanje izdelkov deluje. Da baza podatkov deluje, da se naročajo, da se spletno mesto odziva navzven in se odziva z dveh strežnikov in uporabnik ni vržen s spletnega mesta, medtem ko se le-to rebalansira na drug strežnik itd. Obstaja več entitet.

Še več, subjekt, povezan z infrastrukturo, še vedno ostaja največji v upravljavčevi glavi. V moji glavi je še vedno ideja, da je oseba, ki izvaja nadzor, oseba, ki bo namestila zabbix in ga lahko konfigurirala.

Toda hkrati se pojavlja delo na izvajanju zunanjih preverjanj, na ustvarjanju nabora poizvedbenih skriptov za indeksiranje iskanja, nabora skriptov za preverjanje, ali se iskanje med postopkom indeksiranja spreminja, nabora skriptov, ki preverjajo, ali je blago preneseno v dostavna služba itd. in tako naprej.

Opomba: "nabor skriptov" sem napisal 3-krat. To pomeni, da oseba, odgovorna za nadzor, ni več tista, ki preprosto namesti zabbix. To je oseba, ki začne kodirati. Toda v glavah ekipe se še ni nič spremenilo.

Toda svet se spreminja, postaja vse bolj zapleten. Dodana je virtualizacijska plast in več novih sistemov. Začnejo sodelovati drug z drugim. Kdo je rekel, da "smrdi po mikrostoritvah?" Toda vsaka storitev še vedno izgleda kot spletno mesto posebej. Lahko se obrnemo nanj in razumemo, da zagotavlja potrebne informacije in deluje samostojno. In če si skrbnik, ki je nenehno vpet v projekt, ki se razvija 5-7-10 let, se to znanje kopiči: pojavi se nova raven - spoznal si jo, pojavi se druga raven - spoznal si ...

Redkokdo pa spremlja projekt 10 let.

Življenjepis nadzornika

Recimo, da ste prišli do novega startupa, ki je takoj najel 20 razvijalcev, napisal 15 mikrostoritev, vi pa ste skrbnik, ki mu rečejo: »Izgradite CI/CD. prosim." Zgradili ste CI/CD in nenadoma slišite: »Težko nam je delati s proizvodnjo v »kocki«, ne da bi razumeli, kako bo aplikacija v njej delovala. Naredite nam peskovnik v isti "kocki".
V tej kocki narediš peskovnik. Takoj vam povedo: "Želimo scensko bazo, ki se posodablja vsak dan od produkcije, da razumemo, da deluje v bazi podatkov, a hkrati ne pokvari produkcijske baze."

Živiš v vsem tem. Ostajata še 2 tedna do izdaje, vam rečejo: "Zdaj pa spremljajmo vse to ..." To je. spremljanje infrastrukture gruče, spremljanje arhitekture mikrostoritev, spremljanje dela z zunanjimi storitvami...

In moji kolegi vzamejo običajno shemo iz glave in rečejo: "No, tukaj je vse jasno! Namestite program, ki bo vse to spremljal.« Da, da: Prometheus + Grafana + vtičniki.
In dodajo: "Imate dva tedna časa, poskrbite, da bo vse varno."

V veliko projektih, ki jih vidimo, je za spremljanje dodeljena ena oseba. Predstavljajte si, da želimo zaposliti osebo, ki bo izvajala monitoring za 2 tedna, in zanjo napišemo življenjepis. Kakšne veščine bi morala imeti ta oseba, glede na vse, kar smo do sedaj povedali?

• Razumeti mora spremljanje in specifike delovanja železne infrastrukture.
• Razumeti mora posebnosti spremljanja Kubernetesa (in vsi želijo iti v "kocko", ker se lahko abstrahirate od vsega, skrijete, ker se bo skrbnik ukvarjal z ostalim) - samega sebe, njegove infrastrukture in razumeti, kako spremljati aplikacije znotraj.
• Razumeti mora, da storitve med seboj komunicirajo na posebne načine, in poznati posebnosti medsebojnega delovanja storitev. Povsem mogoče je videti projekt, kjer nekatere storitve komunicirajo sinhrono, ker drugače ne gre. Na primer, zaledje gre prek REST, prek gRPC do kataloške storitve, prejme seznam izdelkov in ga vrne nazaj. Ne moreš čakati tukaj. In z drugimi storitvami deluje asinhrono. Prenesite naročilo dostavni službi, pošljite pismo itd.
  Verjetno ste že priplavali iz vsega tega? In admin, ki mora to spremljati, je postal še bolj zmeden.
• Znati mora pravilno načrtovati in načrtovati – dela pa je vedno več.
• Iz ustvarjene storitve mora torej ustvariti strategijo, da razume, kako jo konkretno spremljati. Potrebuje razumevanje arhitekture projekta in njegovega razvoja + razumevanje tehnologij, uporabljenih pri razvoju.

Spomnimo se povsem običajnega primera: nekatere storitve so v PHP, nekatere storitve v Go, nekatere storitve v JS. Nekako delujejo drug z drugim. Od tod izvira izraz »mikrostoritev«: obstaja toliko posameznih sistemov, da razvijalci ne morejo razumeti projekta kot celote. En del ekipe piše storitve v JS, ki delajo same in ne poznajo delovanja preostalega sistema. Drugi del piše storitve v Pythonu in se ne vmešava v delovanje drugih storitev; so izolirani na svojem območju. Tretji je pisanje storitev v PHP ali kaj drugega.
Vseh teh 20 ljudi je razdeljenih na 15 služb in samo en admin mora vse to razumeti. nehaj! sistem smo samo razdelili na 15 mikroservisov, ker 20 ljudi ne more razumeti celotnega sistema.

Ampak to je treba nekako spremljat...

Kakšen je rezultat? Posledično se pojavi ena oseba, ki se domisli vsega, česar cela ekipa razvijalcev ne more razumeti, hkrati pa mora znati in znati narediti tudi to, kar smo navedli zgoraj – infrastrukturo strojne opreme, infrastrukturo Kubernetes itd.

Kaj naj rečem... Houston, imamo težave.

Spremljanje sodobnega programskega projekta je programski projekt sam po sebi

Iz lažnega prepričanja, da je spremljanje programska oprema, razvijemo vero v čudeže. Toda čudeži se, žal, ne dogajajo. Ne morete namestiti zabbixa in pričakovati, da bo vse delovalo. Nima smisla nameščati Grafana in upati, da bo vse ok. Največ časa bomo porabili za organizacijo preverjanj delovanja storitev in njihove medsebojne interakcije, preverjanje delovanja zunanjih sistemov. Pravzaprav 90 % časa ne bomo porabili za pisanje skriptov, temveč za razvoj programske opreme. In za to bi morala skrbeti ekipa, ki razume delo projekta.
Če je v tej situaciji ena oseba vržena v nadzor, se bo zgodila katastrofa. Kar se dogaja povsod.

Na primer, obstaja več storitev, ki med seboj komunicirajo preko Kafke. Naročilo je prispelo, Kafki smo poslali sporočilo o naročilu. Obstaja storitev, ki posluša informacije o naročilu in pošilja blago. Obstaja storitev, ki posluša informacije o naročilu in uporabniku pošlje pismo. In potem se pojavi kup več storitev in začnemo biti zmedeni.

In če to daste tudi skrbniku in razvijalcem na stopnji, ko je do izdaje ostalo malo časa, bo oseba morala razumeti ta celoten protokol. Tisti. Projekt takšnega obsega zahteva veliko časa, kar je treba upoštevati pri razvoju sistema.
Toda zelo pogosto, zlasti pri startupih, vidimo, kako se spremljanje odloži na pozneje. »Zdaj bomo naredili dokaz koncepta, izstrelili ga bomo in pustili, da pade – pripravljeni smo se žrtvovati. In potem bomo vse spremljali.” Ko (ali če) projekt začne služiti denar, želi podjetje dodati še več funkcij – ker je začel delovati, ga je treba še naprej uvajati! In ste na točki, ko morate najprej spremljati vse prejšnje, kar ne vzame 1% časa, ampak veliko več. In mimogrede, za spremljanje bodo potrebni razvijalci, ki jim je lažje pustiti, da delajo na novih funkcijah. Posledično se pišejo nove funkcije, vse se pokvari in ste v neskončni slepi ulici.

Kako torej spremljati projekt od začetka in kaj storiti, če dobite projekt, ki ga je treba spremljati, pa ne veste, kje začeti?

Najprej morate načrtovati.

Lirična digresija: zelo pogosto začnejo z nadzorom infrastrukture. Na primer, imamo Kubernetes. Začnimo z namestitvijo Prometheusa z Grafano, namestitvijo vtičnikov za spremljanje “kocke”. Ne samo razvijalci, tudi skrbniki imajo nesrečno prakso: "Namestili bomo ta vtičnik, vendar vtičnik verjetno ve, kako to narediti." Ljudje radi začnejo s preprostim in jasnim, ne pa s pomembnimi dejanji. In spremljanje infrastrukture je preprosto.

Najprej se odločite, kaj in kako želite spremljati, nato pa izberite orodje, saj drugi ne morejo razmišljati namesto vas. In bi morali? Drugi ljudje so razmišljali o univerzalnem sistemu - ali pa sploh niso razmišljali, ko je bil ta vtičnik napisan. In samo zato, ker ima ta vtičnik 5 tisoč uporabnikov, še ne pomeni, da je uporaben. Morda boste postali 5001. preprosto zato, ker je bilo tam že 5000 ljudi.

Če začnete spremljati infrastrukturo in se zaledje vaše aplikacije preneha odzivati, bodo vsi uporabniki izgubili povezavo z mobilno aplikacijo. Prikaže se napaka. Prišli bodo do vas in rekli: "Aplikacija ne deluje, kaj delaš tukaj?" - "Spremljamo." — “Kako nadziraš, če ne vidiš, da aplikacija ne deluje?!”

1. Menim, da morate spremljati točno od vstopne točke uporabnika. Če uporabnik ne vidi, da aplikacija deluje, je to to, gre za napako. In na to bi moral najprej opozoriti nadzorni sistem.
2. In šele nato lahko spremljamo infrastrukturo. Ali pa to storite vzporedno. Z infrastrukturo je lažje - tukaj lahko končno samo namestimo zabbix.
3. In zdaj morate iti v korenine aplikacije, da razumete, kje stvari ne delujejo.

Moja glavna ideja je, da mora spremljanje potekati vzporedno s procesom razvoja. Če ekipo za spremljanje odvrnete od drugih nalog (ustvarjanje CI/CD, peskovnik, reorganizacija infrastrukture), bo spremljanje začelo zaostajati in morda ne boste nikoli dohiteli razvoja (ali pa ga boste morali prej ali slej ustaviti).

Vse po nivojih

Tako jaz vidim organizacijo sistema spremljanja.

1) Raven uporabe:

• spremljanje poslovne logike aplikacij;
• spremljanje zdravstvenih metrik storitev;
• spremljanje integracije.

2) Raven infrastrukture:

• spremljanje stopnje orkestracije;
• spremljanje sistemske programske opreme;
• spremljanje ravni železa.

3) Spet raven aplikacije - vendar kot inženirski izdelek:

• zbiranje in spremljanje dnevnikov aplikacij;
• APM;
• sledenje.

4) Opozorilo:

• organizacija opozorilnega sistema;
• organizacija sistema dolžnosti;
• organizacija »baze znanja« in poteka dela za obdelavo incidentov.

Pomembno je,: do opozorila ne pridemo po tem, ampak takoj! Ni treba zagnati nadzora in "nekako kasneje" ugotoviti, kdo bo prejel opozorila. Konec koncev, kaj je naloga spremljanja: razumeti, kje v sistemu nekaj deluje narobe, in o tem obvestiti prave ljudi. Če to pustite do konca, bodo pravi ljudje vedeli, da gre nekaj narobe le s klicem "nič nam ne gre."

Aplikacijska plast - Nadzor poslovne logike

Tukaj govorimo o preverjanju samega dejstva, ali aplikacija deluje za uporabnika.

To raven je treba narediti v razvojni fazi. Na primer, imamo pogojni Prometheus: gre do strežnika, ki izvaja preverjanja, potegne končno točko, končna točka pa gre in preveri API.

Ko programerji pogosto zahtevajo, naj spremljajo domačo stran, da se prepričajo, ali spletno mesto deluje, ponudijo ročaj, ki ga lahko potegnejo vsakič, ko se morajo prepričati, ali API deluje. In programerji v tem trenutku še vedno vzamejo in napišejo /api/test/helloworld
Edini način, da zagotovite, da vse deluje? - Ne!

• Ustvarjanje takih pregledov je v bistvu naloga razvijalcev. Teste enot bi morali napisati programerji, ki pišejo kodo. Ker če to izdaš skrbniku, "Stari, tukaj je seznam protokolov API za vseh 25 funkcij, prosim spremljaj vse!" - nič ne bo šlo.
• Če natisnete »zdravo, svet«, nihče ne bo vedel, da bi API moral delovati in deluje. Vsaka sprememba API-ja mora povzročiti spremembo preverjanj.
• Če že imate takšno težavo, zaustavite funkcije in dodelite razvijalce, ki bodo napisali te preglede, ali sprejmite izgube, sprejmite, da se nič ne preverja in da ne bo uspelo.

Tehnični nasveti:

• Bodite prepričani, da organizirate zunanji strežnik za organizacijo pregledov - morate biti prepričani, da je vaš projekt dostopen zunanjemu svetu.
• Organizirajte preverjanja celotnega protokola API, ne le posameznih končnih točk.
• Z rezultati testa ustvarite prometejevo končno točko.

Aplikacijska plast - spremljanje zdravstvenih metrik

Zdaj govorimo o zunanji meritvi zdravja storitev.

Odločili smo se, da vse “ročaje” aplikacije spremljamo z zunanjimi preverjanji, ki jih kličemo iz zunanjega nadzornega sistema. Toda to so "ročaji", ki jih uporabnik "vidi". Želimo biti prepričani, da naše storitve same delujejo. Tu je še boljša zgodba: K8s ima zdravstvene preglede, tako da se lahko vsaj "kocka" sama prepriča, da storitev deluje. Toda polovica čekov, ki sem jih videl, je enakega napisa »zdravo, svet«. Tisti. Tako potegne enkrat po namestitvi, je odgovoril, da je vse v redu - to je vse. In storitev, če ponuja svoj API, ima ogromno vstopnih točk za ta isti API, ki ga je treba tudi spremljati, saj želimo vedeti, da deluje. In to že spremljamo znotraj.

Kako to tehnično pravilno izvesti: vsaka storitev izpostavi končno točko o svoji trenutni zmogljivosti in v grafih Grafana (ali katere koli druge aplikacije) vidimo stanje vseh storitev.

• Vsaka sprememba API-ja mora povzročiti spremembo preverjanj.
• Takoj ustvarite novo storitev z zdravstvenimi meritvami.
• Skrbnik lahko pride do razvijalcev in vpraša "dodajte mi nekaj funkcij, da bom vse razumel, in dodajte informacije o tem v svoj nadzorni sistem." Toda razvijalci običajno odgovorijo: "Dva tedna pred izdajo ne bomo ničesar dodali."
  Naj vodje razvoja vedo, da bodo takšne izgube, naj vedo tudi vodstva vodij razvoja. Ker ko bo vse padlo, bo še vedno nekdo poklical in zahteval spremljanje “konstantno padajočega servisa” (c)
• Mimogrede, dodelite razvijalcem pisanje vtičnikov za Grafana - to bo dobra pomoč za skrbnike.

Aplikacijska plast – spremljanje integracije

Spremljanje integracije se osredotoča na spremljanje komunikacij med poslovno kritičnimi sistemi.

Na primer, obstaja 15 storitev, ki komunicirajo med seboj. To nista več ločeni strani. Tisti. ne moremo zagnati storitve same, dobiti /helloworld in razumeti, da storitev deluje. Ker mora spletna storitev za naročanje poslati informacijo o naročilu v avtobus - iz avtobusa, mora skladiščna služba to sporočilo prejeti in z njim delati naprej. In storitev distribucije e-pošte mora to nekako nadalje obdelati itd.

V skladu s tem ne moremo razumeti, če zbadamo vsako posamezno storitev, da vse deluje. Ker imamo določeno vodilo, prek katerega vse komunicira in sodeluje.
Zato mora ta stopnja zaznamovati stopnjo testiranja storitev za interakcijo z drugimi storitvami. Nemogoče je organizirati nadzor komunikacije s spremljanjem posrednika sporočil. Če obstaja storitev, ki izdaja podatke, in storitev, ki jih sprejema, bomo pri spremljanju posrednika videli le podatke, ki letijo z ene strani na drugo. Tudi če bi nekako uspeli interno spremljati interakcijo teh podatkov - da določen proizvajalec objavi podatke, jih nekdo prebere, ta tok gre naprej do Kafke - nam to še vedno ne bo dalo informacij, če je ena storitev poslala sporočilo v eni različici , vendar druga storitev ni pričakovala te različice in jo je preskočila. Tega ne bomo vedeli, saj nam bodo storitve povedale, da vse deluje.

Kaj priporočam:

• Za sinhrono komunikacijo: končna točka pošilja zahteve povezanim storitvam. Tisti. vzamemo to končno točko, potegnemo skript znotraj storitve, ki gre do vseh točk in pravi "lahko potegnem tja in potegnem tja, lahko potegnem tja ..."
• Za asinhrono komunikacijo: dohodna sporočila - končna točka preveri vodilo za testna sporočila in prikaže status obdelave.
• Za asinhrono komunikacijo: odhodna sporočila - končna točka pošilja testna sporočila na vodilo.

Kot se običajno zgodi: imamo storitev, ki vrže podatke v vodilo. Obiščemo to storitev in vas prosimo, da nam poveste o njenem stanju integracije. In če mora storitev ustvariti sporočilo nekje dlje (WebApp), bo ustvarila to testno sporočilo. In če izvajamo storitev na strani OrderProcessing, najprej objavi tisto, kar lahko objavi neodvisno, in če so nekatere odvisne stvari, potem prebere nabor testnih sporočil iz vodila, razume, da jih lahko obdela, poroča in , če je treba, jih objavi naprej, o tem pa pravi - vse je ok, živ sem.

Zelo pogosto slišimo vprašanje "kako lahko to preizkusimo na bojnih podatkih?" Na primer, govorimo o isti storitvi naročanja. Naročilo pošilja sporočila v skladišče, kjer je blago odpisano: tega ne moremo preizkusiti na bojnih podatkih, ker "moje blago bo odpisano!" Rešitev: Celoten test načrtujte na začetku. Imate tudi teste enot, ki se posmehujejo. Torej, to storite na globlji ravni, kjer imate komunikacijski kanal, ki ne škodi delovanju podjetja.

Raven infrastrukture

Spremljanje infrastrukture je nekaj, kar je dolgo veljalo za samo spremljanje.

• Nadzor infrastrukture se lahko in mora zagnati kot ločen proces.
• Ne bi smeli začeti z nadzorom infrastrukture na tekočem projektu, tudi če bi to res želeli. To je bolečina za vse devope. "Najprej bom spremljal gručo, spremljal bom infrastrukturo" - tj. Najprej bo spremljal, kaj je spodaj, vendar ne bo šel v aplikacijo. Ker aplikacija je za devops nerazumljiva stvar. Pricurljalo mu je in ne razume, kako deluje. Ampak on razume infrastrukturo in začne z njo. Ampak ne - vedno morate najprej spremljati aplikacijo.
• Ne pretiravajte s številom opozoril. Glede na kompleksnost sodobnih sistemov opozorila neprestano letijo in s tem kupom opozoril je treba nekako živeti. In dežurna oseba, ki bo pogledala sto naslednjih opozoril, se bo odločila: "Nočem razmišljati o tem." Opozorila naj obveščajo le o kritičnih stvareh.

Nivo aplikacije kot poslovne enote

Ključne točke:

• ELK. To je industrijski standard. Če iz nekega razloga ne združujete dnevnikov, začnite to početi takoj.
• APM. Zunanji APM kot način za hitro zaprtje nadzora aplikacij (NewRelic, BlackFire, Datadog). To stvar lahko začasno namestite, da vsaj nekako razumete, kaj se dogaja z vami.
• Sledenje. V desetinah mikrostoritev morate izslediti vse, ker zahteva ne živi več sama od sebe. Pozneje ga je zelo težko dodati, zato je bolje, da takoj načrtujete sledenje v razvoju - to je delo in uporabnost razvijalcev. Če tega še niste implementirali, ga implementirajte! Glej Jaeger/Zipkin

Opozorilo

• Organizacija sistema obveščanja: v pogojih spremljanja kopice stvari bi moral obstajati enoten sistem za pošiljanje obvestil. Lahko v Grafani. Na Zahodu vsi uporabljajo PagerDuty. Opozorila morajo biti jasna (npr. od kod prihajajo ...). In priporočljivo je nadzorovati, ali so obvestila sploh prejeta
• Organizacija sistema dežurstva: opozorila ne smejo biti poslana vsem (bodisi bodo vsi reagirali v množici ali pa nihče). Razvijalci morajo biti tudi dežurni: obvezno določite področja odgovornosti, naredite jasna navodila in v njih napišite, koga točno poklicati v ponedeljek in sredo ter koga v torek in petek (sicer ne bodo nikogar poklicali niti v v primeru velike težave - bali se vas bodo zbuditi ali motiti: ljudje na splošno ne marajo klicati in zbujati drugih ljudi, še posebej ponoči). In pojasnite, da prošnja za pomoč ni pokazatelj nesposobnosti (»prosim za pomoč, to pomeni, da sem slab delavec«), spodbujajte prošnje za pomoč.
• Organizacija »baze znanja« in poteka dela za obdelavo incidentov: za vsak resen incident je treba načrtovati obdukcijo in kot začasen ukrep zabeležiti ukrepe, ki bodo razrešili incident. In naj postane praksa, da so ponavljajoča se opozorila greh; popraviti jih je treba v kodi ali infrastrukturnem delu.

Tehnološki sklad

Predstavljajmo si, da je naš kup naslednji:

• zbiranje podatkov - Prometej + Grafana;
• analiza dnevnika - ELK;
• za APM ali Tracing - Jaeger (Zipkin).

Izbira možnosti ni kritična. Kajti če ste na začetku razumeli, kako spremljati sistem in si napisali načrt, potem začnete izbirati orodja, ki ustrezajo vašim zahtevam. Vprašanje je, kaj ste se sploh odločili spremljati. Ker morda orodje, ki ste ga izbrali na začetku, sploh ne ustreza vašim zahtevam.

Nekaj ​​tehničnih točk, ki jih zadnje čase vidim povsod:

Prometeja rinejo v Kubernetes – kdo si je to izmislil?! Če se vaša gruča zruši, kaj boste storili? Če imate v notranjosti zapleteno gručo, mora obstajati nekakšen nadzorni sistem znotraj gruče in nekaj zunaj, ki bo zbiral podatke znotraj gruče.

Znotraj gruče zbiramo polena in vse ostalo. Toda nadzorni sistem mora biti zunaj. Zelo pogosto so v gruči, kjer je interno nameščen Promtheus, tudi sistemi, ki izvajajo zunanje preglede delovanja strani. Kaj pa, če so vaše povezave z zunanjim svetom padle in aplikacija ne deluje? Izkazalo se je, da je znotraj vse v redu, a to uporabnikom nič ne olajša stvari.

Ugotovitve

• Spremljanje razvoja ni namestitev pripomočkov, ampak razvoj programskega izdelka. 98 % današnjega spremljanja je kodiranje. Kodiranje v storitvah, kodiranje zunanjih pregledov, preverjanje zunanjih storitev in to je vse.
• Ne zapravljajte časa svojih razvijalcev za spremljanje: to lahko vzame do 30 % njihovega dela, vendar je vredno.
• Devops, ne skrbi, da nečesa ne moreš spremljati, ker so nekatere stvari čisto drugačen način razmišljanja. Niste bili programer, spremljanje dela pa je ravno njihova naloga.
• Če projekt že teče in ni nadzorovan (in ste vodja), dodelite sredstva za spremljanje.
• Če je izdelek že v proizvodnji in ste devops, ki mu je bilo rečeno, da "nastavite nadzor" - poskusite vodstvu razložiti, o čem sem vse to napisal.

To je razširjena različica poročila na konferenci Saint Highload++.

Če vas zanimajo moje ideje in razmišljanja o tem in sorodnih temah, potem lahko tukaj preberite kanal 🙂

Vir: www.habr.com