Stebėjimas miręs? — Tegyvuoja stebėjimas

Nuo 2008 m. mūsų įmonė daugiausia užsiima infrastruktūros valdymu ir visą parą teikiamu techniniu interneto projektų palaikymu: turime daugiau nei 400 klientų, o tai sudaro apie 15% Rusijos elektroninės komercijos. Atitinkamai palaikoma labai įvairi architektūra. Jeigu kažkas nukrenta, privalome tai sutvarkyti per 15 minučių. Tačiau norint suprasti, kad įvyko avarija, reikia stebėti projektą ir reaguoti į incidentus. Kaip tai padaryti?

Manau, kad yra problema organizuojant tinkamą stebėjimo sistemą. Jei nebūtų buvę problemų, mano kalba būtų sudaryta iš vienos tezės: „Įdiekite Prometheus + Grafana ir papildinius 1, 2, 3“. Deja, taip jau nebeveikia. Ir pagrindinė problema yra ta, kad visi ir toliau tiki tuo, kas egzistavo 2008 m., kalbant apie programinės įrangos komponentus.

Dėl stebėsenos sistemos organizavimo drįsčiau teigti, kad... projektų su kompetentinga stebėsena nėra. O situacija tokia prasta, kad jei kažkas nukris, kyla pavojus, kad tai liks nepastebėta – juk visi įsitikinę, kad „viskas stebima“.
Galbūt viskas stebima. Bet kaip?

Visi esame susidūrę su tokia istorija: tam tikras devopas, tam tikras administratorius dirba, prie jų ateina kūrimo komanda ir sako – „mes paleistas, dabar stebėkite“. Stebėti ką? Kaip tai veikia?

GERAI. Stebime senamadišką būdą. Ir jau keičiasi, ir pasirodo, kad jūs stebėjote paslaugą A, kuri tapo paslauga B, kuri sąveikauja su paslauga C. Tačiau kūrėjų komanda jums sako: „Įdiekite programinę įrangą, ji turėtų viską stebėti!

Taigi, kas pasikeitė? - Viskas pasikeitė!

2008 m Viskas gerai

Yra pora kūrėjų, vienas serveris, vienas duomenų bazių serveris. Viskas eina iš čia. Turime šiek tiek informacijos, montuojame zabbix, Nagios, kaktusus. Tada nustatome aiškius įspėjimus apie centrinį procesorių, disko veikimą ir vietos diske. Taip pat atliekame keletą rankinių patikrinimų, kad įsitikintume, ar svetainė reaguoja ir ar užsakymai patenka į duomenų bazę. Ir viskas – esame daugiau ar mažiau apsaugoti.

Jei lygintume administratoriaus atliktą darbą, kad būtų užtikrintas stebėjimas, tai 98% jo buvo automatinis: asmuo, kuris atlieka stebėjimą, turi suprasti, kaip įdiegti Zabbix, kaip jį konfigūruoti ir sukonfigūruoti įspėjimus. Ir 2% – už išorinius patikrinimus: ar svetainė atsiliepia ir pateikia užklausą duomenų bazei, ar atėjo nauji užsakymai.

2010 m Krūvis auga

Pradedame didinti žiniatinklio mastelį, įtraukdami paieškos variklį. Norime įsitikinti, kad prekių kataloge yra visos prekės. Ir ta produktų paieška veikia. Kad duomenų bazė veiktų, kad būtų daromi užsakymai, kad svetainė reaguotų iš išorės ir atsakytų iš dviejų serverių, o vartotojas nebūtų išmestas iš svetainės, kol ji perbalansuojama į kitą serverį ir pan. Yra ir daugiau subjektų.

Be to, su infrastruktūra susijęs subjektas vis dar išlieka didžiausias valdytojo galvoje. Mano galvoje vis dar sukasi mintis, kad monitoringą atlieka tas žmogus, kuris įdiegs zabbix ir galės jį sukonfigūruoti.

Tačiau tuo pat metu atsiranda darbas atliekant išorinius patikrinimus, kuriant paieškos indeksatoriaus užklausų scenarijų rinkinį, scenarijų rinkinį, skirtą patikrinti, ar paieška keičiasi indeksavimo proceso metu, scenarijų rinkinį, kuris tikrina, ar prekės yra perkeltos į pristatymo paslauga ir kt. ir taip toliau.

Pastaba: aš parašiau „scenarijų rinkinį“ 3 kartus. Tai reiškia, kad už stebėjimą atsakingas asmuo nebėra tas, kuris tiesiog įdiegia „zabbix“. Tai žmogus, kuris pradeda koduoti. Tačiau komandos galvose dar niekas nepasikeitė.

Tačiau pasaulis keičiasi, darosi vis sudėtingesnis. Pridedamas virtualizacijos sluoksnis ir kelios naujos sistemos. Jie pradeda bendrauti vienas su kitu. Kas pasakė: „kvepia mikropaslaugomis? Tačiau kiekviena paslauga atskirai atrodo kaip svetainė. Galime į ją kreiptis ir suprasti, kad ji suteikia reikiamą informaciją ir veikia savaime. O jei esi administratorius, nuolat dalyvaujantis 5-7-10 metų kuriamame projekte, šios žinios kaupiasi: atsiranda naujas lygis - supratai, atsiranda kitas lygis - supratai...

Tačiau retai kas 10 metų lydi projektą.

Stebėtojo gyvenimo aprašymas

Tarkime, atėjote į naują startuolį, kuris iškart pasamdė 20 kūrėjų, parašė 15 mikro paslaugų ir esate administratorius, kuriam sakoma: „Sukurkite CI/CD. Prašau." Sukūrėte CI/CD ir staiga išgirstate: „Mums sunku dirbti su gamyba „kube“, nesuvokiant, kaip joje veiks programa. Padarykite mums smėlio dėžę tame pačiame „kube“.
Šiame kube sukuriate smėlio dėžę. Jie iš karto jums sako: „Norime etapo duomenų bazės, kuri būtų atnaujinama kiekvieną dieną nuo gamybos pradžios, kad suprastume, kad ji veikia duomenų bazėje, bet tuo pačiu nesugadintų gamybos duomenų bazės“.

Tu gyveni visame tame. Iki išleidimo liko 2 savaitės, jums sako: „Dabar stebėkime visa tai...“ Tai yra. stebėti klasterio infrastruktūrą, stebėti mikropaslaugų architektūrą, stebėti darbą su išorinėmis paslaugomis...

O kolegos ima iš galvos įprastą schemą ir sako: „Na, čia viskas aišku! Įdiekite programą, kuri visa tai stebės“. Taip, taip: Prometėjas + Grafana + papildiniai.
Ir jie priduria: „Turite dvi savaites, įsitikinkite, kad viskas yra saugu“.

Daugelyje projektų, kuriuos matome, stebėjimui skiriamas vienas žmogus. Įsivaizduokite, kad norime pasamdyti žmogų, kuris atliktų stebėjimą 2 savaitėms, ir parašome jam gyvenimo aprašymą. Kokius įgūdžius šis asmuo turėtų turėti, atsižvelgiant į viską, ką iki šiol sakėme?

• Jis turi suprasti geležies infrastruktūros stebėjimą ir veikimo specifiką.
• Jis turi suprasti „Kubernetes“ stebėjimo specifiką (ir visi nori eiti į „kubą“, nes galite nuo visko abstrahuotis, pasislėpti, nes su visa kita susitvarkys administratorius) - save, savo infrastruktūrą ir suprasti, kaip stebėti programas. viduje.
• Jis turi suprasti, kad tarnybos tarpusavyje bendrauja ypatingais būdais, ir žinoti paslaugų tarpusavio sąveikos specifiką. Visai galima pamatyti projektą, kur kai kurios paslaugos bendrauja sinchroniškai, nes kitaip nėra. Pavyzdžiui, backend eina per REST, per gRPC į katalogo paslaugą, gauna produktų sąrašą ir grąžina jį atgal. Jūs negalite laukti čia. O su kitomis paslaugomis veikia asinchroniškai. Perduokite užsakymą pristatymo tarnybai, išsiųskite laišką ir pan.
  Tikriausiai jau plaukėte nuo viso šito? O administratorė, kuriai reikia tai stebėti, dar labiau sutriko.
• Jis turi mokėti planuoti ir planuoti teisingai – nes darbų darosi vis daugiau.
• Todėl jis turi sukurti strategiją iš sukurtos paslaugos, kad suprastų, kaip konkrečiai ją stebėti. Jam reikia supratimo apie projekto architektūrą ir jo vystymą + supratimą apie kuriant naudojamas technologijas.

Prisiminkime visiškai įprastą atvejį: kai kurios paslaugos yra PHP, kai kurios paslaugos yra Go, kai kurios paslaugos yra JS. Jie kažkaip dirba vienas su kitu. Iš čia kilęs terminas „mikroservisas“: yra tiek daug atskirų sistemų, kad kūrėjai negali suprasti viso projekto. Viena dalis komandos rašo paslaugas JS, kurios veikia savarankiškai ir nežino, kaip veikia kita sistemos dalis. Kita dalis rašo paslaugas Python ir netrukdo kitų paslaugų veikimui, jos yra izoliuotos savo srityje. Trečia – paslaugų rašymas PHP ar kažkuo kitu.
Visi šie 20 žmonių yra suskirstyti į 15 tarnybų, ir yra tik vienas administratorius, kuris turi visa tai suprasti. Sustabdyti! mes tiesiog padalinome sistemą į 15 mikro paslaugų, nes 20 žmonių negali suprasti visos sistemos.

Bet tai reikia kažkaip stebėti...

Koks rezultatas? Dėl to yra vienas žmogus, kuris sugalvoja viską, ko negali suprasti visa kūrėjų komanda, o tuo pačiu jis taip pat turi žinoti ir mokėti daryti tai, ką nurodėme aukščiau - techninės įrangos infrastruktūrą, Kubernetes infrastruktūrą ir t.t.

Ką aš galiu pasakyti... Hiustonas, mes turime problemų.

Šiuolaikinės programinės įrangos projekto stebėjimas yra pats programinės įrangos projektas

Iš klaidingo įsitikinimo, kad stebėjimas yra programinė įranga, mes ugdome tikėjimą stebuklais. Bet stebuklų, deja, nebūna. Negalite įdiegti „zabbix“ ir tikėtis, kad viskas veiks. Nėra prasmės diegti Grafana ir tikėtis, kad viskas bus gerai. Didžioji dalis laiko bus skirta paslaugų veikimo ir tarpusavio sąveikos patikrų organizavimui, išorinių sistemų veikimo patikrinimui. Tiesą sakant, 90% laiko bus skirta ne scenarijų rašymui, o programinės įrangos kūrimui. Ir tai turėtų tvarkyti komanda, kuri supranta projekto darbą.
Jei šioje situacijoje vienas asmuo bus įtrauktas į stebėjimą, įvyks nelaimė. Kas vyksta visur.

Pavyzdžiui, yra keletas tarnybų, kurios tarpusavyje bendrauja per Kafka. Užsakymas atkeliavo, išsiuntėme Kafkai žinutę apie užsakymą. Yra paslauga, kuri išklauso informaciją apie užsakymą ir išsiunčia prekes. Yra paslauga, kuri išklauso informaciją apie užsakymą ir išsiunčia vartotojui laišką. Ir tada atsiranda dar krūva paslaugų, ir mes pradedame sutrikti.

Ir jei tai taip pat pateiksite administratoriui ir kūrėjams tame etape, kai iki išleidimo liko šiek tiek laiko, asmuo turės suprasti visą šį protokolą. Tie. Tokio masto projektas užima daug laiko ir į tai turėtų būti atsižvelgta kuriant sistemą.
Tačiau labai dažnai, ypač startuoliuose, matome, kaip stebėjimas atidedamas vėlesniam laikui. „Dabar mes padarysime koncepcijos įrodymą, paleisime su juo, tegul nukrenta – esame pasirengę aukotis. Ir tada mes visa tai stebėsime“. Kai (arba jei) projektas pradeda uždirbti, verslas nori pridėti dar daugiau funkcijų, nes jis pradėjo veikti, todėl jį reikia plėtoti toliau! Ir jūs esate toje vietoje, kur pirmiausia turite stebėti viską, kas buvo ankstesnė, o tai užima ne 1% laiko, o daug daugiau. Ir, beje, kūrėjai bus reikalingi stebėjimui, ir lengviau leisti jiems dirbti su naujomis funkcijomis. Dėl to rašomos naujos funkcijos, viskas sutrinka ir atsiduriate begalinėje aklavietėje.

Taigi, kaip stebėti projektą pradedant nuo pradžių ir ką daryti, jei gavote projektą, kurį reikia stebėti, bet nežinote, nuo ko pradėti?

Pirma, reikia planuoti.

Lyrinis nukrypimas: labai dažnai jie prasideda nuo infrastruktūros stebėjimo. Pavyzdžiui, turime Kubernetes. Pradėkime nuo „Prometheus“ įdiegimo su „Grafana“, įdiegdami „kubo“ stebėjimo papildinius. Ne tik kūrėjai, bet ir administratoriai turi apgailėtiną praktiką: „Įdiegsime šį papildinį, bet įskiepis tikriausiai žino, kaip tai padaryti“. Žmonės mėgsta pradėti nuo paprastų ir nesudėtingų dalykų, o ne nuo svarbių veiksmų. Ir infrastruktūros stebėjimas yra paprastas.

Pirmiausia nuspręskite, ką ir kaip norite stebėti, o tada pasirinkite įrankį, nes kiti žmonės negali galvoti už jus. Ir ar jie turėtų? Kiti žmonės galvojo apie universalią sistemą – arba visai negalvojo, kai buvo parašytas šis papildinys. Ir tai, kad šis papildinys turi 5 tūkstančius vartotojų, nereiškia, kad jis yra naudingas. Galbūt jūs tapsite 5001-uoju vien todėl, kad anksčiau ten jau buvo 5000 žmonių.

Jei pradėsite stebėti infrastruktūrą ir jūsų programos užpakalinė dalis nustos reaguoti, visi vartotojai praras ryšį su mobiliąja programa. Atsiras klaida. Jie ateis pas jus ir pasakys: „Programa neveikia, ką tu čia veiki? – „Mes stebime“. — "Kaip stebėti, jei nematote, kad programa neveikia?!"

1. Manau, kad reikia pradėti stebėti tiksliai nuo vartotojo įėjimo taško. Jei vartotojas nemato, kad programa veikia, tai viskas, tai yra gedimas. Ir stebėjimo sistema pirmiausia turėtų įspėti apie tai.
2. Ir tik tada galime stebėti infrastruktūrą. Arba darykite tai lygiagrečiai. Su infrastruktūra lengviau – čia pagaliau galime tiesiog įdiegti „zabbix“.
3. Ir dabar reikia pereiti prie programos šaknų, kad suprastumėte, kur viskas neveikia.

Mano pagrindinė mintis yra ta, kad stebėjimas turėtų vykti lygiagrečiai su kūrimo procesu. Jei atitrauksite stebėjimo komandos dėmesį kitoms užduotims (CI/CD kūrimas, smėlio dėžė, infrastruktūros pertvarkymas), stebėjimas pradės vėluoti ir galbūt niekada nepasivysite plėtros (arba anksčiau ar vėliau turėsite jį sustabdyti).

Viskas pagal lygius

Štai kaip aš matau stebėjimo sistemos organizavimą.

1) Taikymo lygis:

• programų verslo logikos stebėjimas;
• paslaugų sveikatos rodiklių stebėjimas;
• integracijos stebėjimas.

2) Infrastruktūros lygis:

• orkestravimo lygio stebėjimas;
• Sistemos programinės įrangos stebėjimas;
• geležies lygio stebėjimas.

3) Vėlgi taikymo lygis – bet kaip inžinerinis produktas:

• programų žurnalų rinkimas ir stebėjimas;
• APM;
• sekimas.

4) Įspėjimas:

• perspėjimo sistemos organizavimas;
• pareigų sistemos organizavimas;
• „žinių bazės“ ir incidentų apdorojimo darbo eigos organizavimas.

Svarbu,: į perspėjimą gauname ne po, o iš karto! Nereikia pradėti stebėjimo ir „kažkaip vėliau“ išsiaiškinti, kas gaus įspėjimus. Galų gale, kokia yra stebėjimo užduotis: suprasti, kurioje sistemoje kažkas neveikia, ir pranešti apie tai tinkamiems žmonėms. Jei paliksite tai iki galo, tinkami žmonės sužinos, kad kažkas negerai, tik paskambinę „niekas mums neveikia“.

Taikymo sluoksnis – verslo logikos stebėjimas

Čia kalbame apie paties fakto, kad programa veikia vartotojui, patikrinimą.

Šis lygis turėtų būti atliktas kūrimo etape. Pavyzdžiui, turime sąlyginį „Prometheus“: jis eina į serverį, kuris atlieka patikrinimus, ištraukia galinį tašką, o galutinis taškas eina ir patikrina API.

Kai dažnai prašoma stebėti pagrindinį puslapį, kad įsitikintų, jog svetainė veikia, programuotojai suteikia rankenėlę, kurią galima patraukti kiekvieną kartą, kai reikia įsitikinti, kad API veikia. Ir šiuo metu programuotojai vis dar ima ir rašo /api/test/helloworld
Vienintelis būdas įsitikinti, kad viskas veikia? - Ne!

• Sukurti tokius patikrinimus iš esmės yra kūrėjų užduotis. Vienetų testus turėtų parašyti programuotojai, kurie rašo kodą. Nes jei nutekėsite jį administratoriui: „Drauge, čia yra API protokolų sąrašas visoms 25 funkcijoms, stebėkite viską! - nieko neišeis.
• Jei išspausdinsite „hello world“, niekas niekada nesužinos, kad API turėtų veikti ir veikia. Dėl kiekvieno API pakeitimo turi pasikeisti patikrinimai.
• Jei jau turite tokią problemą, sustabdykite funkcijas ir paskirkite kūrėjus, kurie išrašys šiuos čekius, arba priims nuostolius, sutikite, kad niekas nėra patikrinta ir nepavyks.

Techniniai patarimai:

• Patikrinimams organizuoti būtinai organizuokite išorinį serverį – turite būti tikri, kad jūsų projektas yra prieinamas išoriniam pasauliui.
• Tvarkykite patikrinimus visame API protokole, o ne tik atskiruose galutiniuose taškuose.
• Su bandymo rezultatais sukurkite „Prometheus“ galinį tašką.

Taikymo lygis – sveikatos metrikų stebėjimas

Dabar kalbame apie išorinius paslaugų sveikatos rodiklius.

Nusprendėme, kad visas programos „rankenas“ stebime naudodami išorinius patikrinimus, kuriuos iškviečiame iš išorinės stebėjimo sistemos. Bet tai yra „rankenos“, kurias vartotojas „mato“. Norime būti tikri, kad pačios mūsų paslaugos veikia. Čia yra geresnė istorija: K8s turi sveikatos patikrinimus, kad bent pats "kubas" galėtų įsitikinti, kad paslauga veikia. Tačiau pusė mano matytų čekių yra tas pats spausdintas „labas pasaulis“. Tie. Taigi jis traukia vieną kartą po dislokavimo, jis atsakė, kad viskas gerai - viskas. Ir paslauga, jei ji teikia savo API, turi daugybę įėjimo taškų į tą pačią API, kurią taip pat reikia stebėti, nes norime žinoti, kad ji veikia. Ir mes jau stebime tai viduje.

Kaip tai teisingai įgyvendinti techniškai: kiekviena paslauga atskleidžia galinį tašką apie dabartinį jos veikimą, o Grafana (ar bet kurios kitos programos) diagramose matome visų paslaugų būseną.

• Dėl kiekvieno API pakeitimo turi pasikeisti patikrinimai.
• Nedelsdami sukurkite naują paslaugą su sveikatos rodikliais.
• Administratorius gali ateiti pas kūrėjus ir paprašyti „pridėkite man keletą funkcijų, kad viską suprasčiau ir įtraukčiau informaciją apie tai į savo stebėjimo sistemą“. Tačiau kūrėjai paprastai atsako: „Dvi savaites iki išleidimo nieko nepridėsime“.
  Praneškite plėtros vadovams, kad tokių nuostolių bus, praneškite ir plėtros vadovams. Nes kai viskas krenta, kažkas vis tiek paskambins ir reikalaus stebėti „nuolat krentančią paslaugą“ (c)
• Beje, paskirkite kūrėjams Grafana įskiepių rašymą – tai bus gera pagalba administratoriams.

Programos sluoksnis – integracijos stebėjimas

Integracijos stebėjimas skirtas ryšių tarp verslui svarbių sistemų stebėjimui.

Pavyzdžiui, yra 15 tarnybų, kurios bendrauja tarpusavyje. Tai nebėra atskiros svetainės. Tie. Mes negalime patys ištraukti paslaugos, gauti /helloworld ir suprasti, kad paslauga veikia. Kadangi užsakymo žiniatinklio tarnyba turi siųsti informaciją apie užsakymą į autobusą – iš autobuso, sandėlio tarnyba turi gauti šį pranešimą ir dirbti su juo toliau. Ir el. pašto platinimo tarnyba turi tai kažkaip toliau apdoroti ir pan.

Atitinkamai, mes negalime suprasti, kai kalbame apie kiekvieną atskirą paslaugą, kad visa tai veikia. Nes mes turime tam tikrą autobusą, per kurį viskas bendrauja ir sąveikauja.
Todėl šis etapas turėtų pažymėti paslaugų sąveikos su kitomis paslaugomis testavimo etapą. Neįmanoma organizuoti komunikacijos stebėjimo stebint pranešimų tarpininką. Jei yra paslauga, kuri išduoda duomenis, ir paslauga, kuri juos gauna, stebėdami brokerį matysime tik iš vienos pusės į kitą skrendančius duomenis. Net jei mums kažkaip pavyktų stebėti šių duomenų sąveiką viduje - kad tam tikras gamintojas paskelbia duomenis, kažkas juos perskaito, šis srautas ir toliau eina į Kafką - tai vis tiek neduos mums informacijos, jei viena tarnyba išsiuntė pranešimą viena versija. , tačiau kita tarnyba šios versijos nesitikėjo ir ją praleido. Mes apie tai nesužinosime, nes tarnybos pasakys, kad viskas veikia.

Ką aš rekomenduoju daryti:

• Sinchroniniam ryšiui: galutinis taškas pateikia užklausas susijusioms paslaugoms. Tie. Mes paimame šį galinį tašką, ištraukiame scenarijų paslaugos viduje, kuris eina į visus taškus ir sako: „Aš galiu traukti ten, ir traukti ten, aš galiu patraukti ten...“
• Asinchroniniam ryšiui: gaunami pranešimai – galutinis taškas tikrina, ar magistrale nėra bandomųjų pranešimų, ir parodo apdorojimo būseną.
• Asinchroniniam ryšiui: siunčiami pranešimai – galutinis taškas siunčia bandomuosius pranešimus į magistralę.

Kaip dažniausiai atsitinka: turime paslaugą, kuri meta duomenis į autobusą. Mes ateiname į šią paslaugą ir prašome papasakoti apie jos integracijos būklę. Ir jei paslaugai reikia sukurti pranešimą kažkur toliau (WebApp), tada ji pateiks šį bandomąjį pranešimą. Ir jei mes vykdome paslaugą OrderProcessing pusėje, ji pirmiausia paskelbia, ką gali paskelbti nepriklausomai, o jei yra kokių nors priklausomų dalykų, tada nuskaito bandomuosius pranešimus iš magistralės, supranta, kad gali juos apdoroti, pranešti ir , jei reikia, patalpink juos toliau, o apie tai jis sako - viskas ok, as gyvas.

Labai dažnai girdime klausimą „kaip mes galime tai patikrinti kovos duomenimis? Pavyzdžiui, kalbame apie tą pačią užsakymo paslaugą. Užsakymas siunčia žinutes į sandėlį, kuriame prekės nurašomos: negalime to patikrinti kovos duomenimis, nes „mano prekės bus nurašytos! Sprendimas: suplanuokite visą šį testą iš pradžių. Taip pat turite vienetų testus, kurie tyčiojasi. Taigi darykite tai gilesniame lygmenyje, kur turite komunikacijos kanalą, kuris nekenkia verslo veiklai.

Infrastruktūros lygis

Infrastruktūros stebėjimas jau seniai buvo laikomas stebėjimu.

• Infrastruktūros stebėjimas gali ir turėtų būti pradėtas kaip atskiras procesas.
• Neturėtumėte pradėti nuo vykdomo projekto infrastruktūros stebėjimo, net jei to tikrai norite. Tai yra skausmas visiems devoms. „Pirmiausia stebėsiu klasterį, stebėsiu infrastruktūrą“ – t.y. Pirma, ji stebės, kas yra žemiau, bet nepateks į programą. Nes programa yra nesuprantamas dalykas devopsui. Jis jam buvo nutekėjęs, ir jis nesupranta, kaip tai veikia. Bet jis supranta infrastruktūrą ir nuo jos pradeda. Bet ne – visada pirmiausia reikia stebėti programą.
• Nepersistenkite su įspėjimų skaičiumi. Atsižvelgiant į šiuolaikinių sistemų sudėtingumą, įspėjimai nuolat sklinda, ir jūs turite kažkaip gyventi su šia įspėjimų krūva. Ir budintis asmuo, peržiūrėjęs šimtą kitų įspėjimų, nuspręs: „Nenoriu apie tai galvoti“. Įspėjimai turėtų pranešti tik apie svarbius dalykus.

Taikymo lygis kaip verslo vienetas

Pagrindiniai klausimai:

• ELK. Tai yra pramonės standartas. Jei dėl kokių nors priežasčių nejungiate žurnalų, pradėkite tai daryti nedelsdami.
• APM. Išoriniai APM kaip būdas greitai uždaryti programų stebėjimą (NewRelic, BlackFire, Datadog). Galite laikinai įdiegti šį dalyką, kad bent kažkaip suprastumėte, kas su jumis vyksta.
• Atsekimas. Dešimtyse mikropaslaugų turite viską atsekti, nes užklausa nebegyvena savaime. Tai labai sunku pridėti vėliau, todėl geriau nedelsiant suplanuoti sekimą kuriant - tai kūrėjų darbas ir naudingumas. Jei dar neįgyvendinote, įgyvendinkite! Žr. Jaeger/Zipkin

Įspėjimas

• Pranešimų sistemos organizavimas: stebint daugybę dalykų, turėtų būti vieninga pranešimų siuntimo sistema. Galite Grafana. Vakaruose visi naudoja PagerDuty. Perspėjimai turi būti aiškūs (pvz., iš kur jie atkeliavo...). Ir patartina kontroliuoti, kad pranešimai iš viso būtų gaunami
• Budėjimo sistemos organizavimas: perspėjimai neturėtų būti siunčiami visiems (arba visi reaguos minioje, arba niekas nereaguos). Kūrėjai taip pat turi būti budintys: būtinai apibrėžti atsakomybės sritis, pateikti aiškias instrukcijas ir įrašyti, kam tiksliai skambinti pirmadienį ir trečiadienį, o kam skambinti antradienį ir penktadienį (kitaip niekam neskambins net didelės problemos atveju – jie bijo jus pažadinti arba trukdyti: žmonės paprastai nemėgsta skambinti ir žadinti kitų žmonių, ypač naktį). Ir paaiškinkite, kad pagalbos prašymas nėra nekompetencijos rodiklis („prašau pagalbos, vadinasi, esu blogas darbuotojas“), skatinkite pagalbos prašymus.
• „Žinių bazės“ ir incidentų apdorojimo darbo eigos organizavimas: kiekvienam rimtam incidentui turėtų būti suplanuotas pomirtinis tyrimas, o kaip laikina priemonė – veiksmai, padėsiantys išspręsti incidentą. Ir paverskite tai praktika, kad pakartotiniai įspėjimai yra nuodėmė; juos reikia pataisyti kode arba infrastruktūros darbuose.

Technologijų krūva

Įsivaizduokime, kad mūsų krūva yra tokia:

• duomenų rinkimas - Prometėjas + Grafana;
• log analizė - ELK;
• APM arba Tracing - Jaeger (Zipkin).

Parinkčių pasirinkimas nėra kritinis. Nes jei iš pradžių supratote, kaip stebėti sistemą ir susirašėte planą, tada pradedate rinktis įrankius, atitinkančius jūsų poreikius. Kyla klausimas, ką pirmiausia pasirinkote stebėti. Nes galbūt iš pradžių pasirinktas įrankis visiškai neatitinka jūsų reikalavimų.

Keletas techninių dalykų, kuriuos pastaruoju metu matau visur:

Prometėjas stumiamas Kubernetes viduje – kas tai sugalvojo?! Jei jūsų klasteris sugenda, ką darysite? Jei viduje yra sudėtingas klasteris, tada klasterio viduje ir išorėje turėtų būti tam tikra stebėjimo sistema, kuri rinks duomenis iš klasterio vidaus.

Klasterio viduje renkame rąstus ir visa kita. Tačiau stebėjimo sistema turi būti išorėje. Labai dažnai klasteryje, kuriame yra viduje įdiegtas Promtheus, yra ir sistemos, kurios atlieka išorinius svetainės veikimo patikrinimus. Ką daryti, jei jūsų ryšiai su išoriniu pasauliu nutrūko ir programa neveikia? Pasirodo, viduje viskas gerai, bet vartotojams tai nepalengvina.

išvados

• Kūrimo stebėjimas yra ne paslaugų diegimas, o programinės įrangos produkto kūrimas. 98% šiandienos stebėjimo yra kodavimas. Kodavimas paslaugose, išorinių patikrinimų kodavimas, išorinių paslaugų tikrinimas ir viskas.
• Negaiškite savo kūrėjų laiko stebėjimui: tai gali užtrukti iki 30 % jų darbo, bet verta.
• Devops, nesijaudink, kad negali kažko stebėti, nes kai kurie dalykai yra visiškai kitoks mąstymas. Jūs nebuvote programuotojas, o stebėjimo darbas yra būtent jų darbas.
• Jei projektas jau vykdomas ir nėra stebimas (o jūs esate vadovas), paskirkite išteklių stebėjimui.
• Jei produktas jau gaminamas, o jūs esate devops, kuriam buvo liepta „nustatyti stebėjimą“ – pabandykite vadovybei paaiškinti, apie ką aš visa tai rašiau.

Tai išplėstinė Saint Highload++ konferencijos pranešimo versija.

Jei jus domina mano idėjos ir mintys apie tai ir susijusiomis temomis, tai galite padaryti čia skaityti kanalą ????

Šaltinis: www.habr.com