Kas monitooring on surnud? — Elagu jälgimine

Alates 2008. aastast on meie ettevõte tegelenud eelkõige infrastruktuuri haldamise ja veebiprojektide ööpäevaringse tehnilise toega: meil on üle 400 kliendi, mis moodustab umbes 15% Venemaa e-kaubandusest. Sellest lähtuvalt toetatakse väga mitmekesist arhitektuuri. Kui midagi kukub, oleme kohustatud selle parandama 15 minuti jooksul. Kuid selleks, et mõista, et õnnetus on juhtunud, peate projekti jälgima ja juhtumitele reageerima. Kuidas seda teha?

Usun, et korraliku seiresüsteemi korraldamisel on probleem. Kui probleeme poleks olnud, koosneks minu kõne ühest teesist: "Palun installige Prometheus + Grafana ja pluginad 1, 2, 3." Kahjuks see enam nii ei tööta. Ja peamine probleem on see, et kõik usuvad tarkvarakomponentide osas jätkuvalt millessegi, mis oli olemas 2008. aastal.

Seiresüsteemi korralduse kohta julgeksin väita, et... pädeva järelevalvega projekte ei eksisteeri. Ja olukord on nii hull, et kui midagi kukub, on oht, et see jääb märkamatuks - kõik on ju kindlad, et "kõike jälgitakse".
Võib-olla jälgitakse kõike. Aga kuidas?

Oleme kõik kokku puutunud sellise looga: teatud devops, teatud administraator töötab, arendusmeeskond tuleb nende juurde ja ütleb - "me oleme vabastatud, nüüd jälgige." Jälgida mida? Kuidas see töötab?

OKEI. Jälgime vanaviisi. Ja see juba muutub ja selgub, et jälgisite teenust A, millest sai teenus B, mis suhtleb teenusega C. Kuid arendusmeeskond ütleb teile: "Installi tarkvara, see peaks kõike jälgima!"

Mis siis muutunud on? - Kõik on muutunud!

2008 Kõik on korras

Seal on paar arendajat, üks server, üks andmebaasiserver. Kõik läheb siit edasi. Meil on infot, paigaldame zabbixit, Nagiost, kaktusi. Ja siis seadsime selged hoiatused protsessorile, ketta töö ja kettaruumi kohta. Teeme ka paar käsitsi kontrolli, et tagada saidi reageerimine ja tellimuste saabumine andmebaasi. Ja ongi kõik – oleme enam-vähem kaitstud.

Kui võrrelda töömahtu, mida administraator toona jälgimise pakkumiseks tegi, siis 98% sellest oli automaatne: jälgija peab aru saama, kuidas Zabbixit installida, kuidas seda seadistada ja märguandeid seadistada. Ja 2% - väliste kontrollide jaoks: kas sait vastab ja teeb päringu andmebaasi, et uued tellimused on saabunud.

2010. aasta Koormus kasvab

Alustame veebi skaleerimist, lisades otsingumootori. Soovime veenduda, et tootekataloog sisaldab kõiki tooteid. Ja see tooteotsing töötab. Et andmebaas töötab, et tellimusi tehakse, et sait reageeriks väliselt ja vastaks kahest serverist ning kasutajat ei visata saidilt välja, kui see teise serveriga ümber balansseeritakse jne. Üksusi on rohkem.

Veelgi enam, infrastruktuuriga seotud üksus jääb haldaja peas endiselt suurimaks. Endiselt on peas mõte, et monitooringut teeb inimene, kes installib zabbixi ja oskab seda seadistada.

Kuid samal ajal ilmub töö väliste kontrollide läbiviimisel, otsingu indekseerija päringuskriptide komplekti loomisel, skriptide komplekti loomisel, et kontrollida, kas otsing indekseerimisprotsessi ajal muutub, skriptide komplekti loomiseks, mis kontrollivad kaupade ülekandmist kohaletoimetamise teenus jne. ja nii edasi.

Märkus. Kirjutasin "skriptide komplekti" 3 korda. See tähendab, et jälgimise eest vastutav isik ei ole enam see, kes lihtsalt zabbixi installib. See on inimene, kes hakkab kodeerima. Kuid meeskonna meelest pole veel midagi muutunud.

Kuid maailm muutub, muutub üha keerulisemaks. Lisatakse virtualiseerimiskiht ja mitu uut süsteemi. Nad hakkavad üksteisega suhtlema. Kes ütles: "lõhnab mikroteenuste järele?" Kuid iga teenus näeb eraldi välja nagu veebisait. Saame selle poole pöörduda ja mõistame, et see annab vajalikku teavet ja töötab iseenesest. Ja kui olete administraator, kes on pidevalt seotud projektiga, mis on arenenud 5-7-10 aastat, siis need teadmised kogunevad: ilmub uus tase - te mõistsite seda, ilmneb teine ​​​​tase - te mõistsite seda ...

Kuid harva saadab keegi projekti 10 aastat.

Järelevalvemehe CV

Oletame, et tulite uude idufirmasse, mis palkas kohe 20 arendajat, kirjutas 15 mikroteenust ja olete administraator, kellele öeldakse: „Ehitage CI/CD. Palun." Olete ehitanud CI/CD ja järsku kuulete: "Meil on raske töötada "kuubis" tootmisega, ilma et mõistaksime, kuidas rakendus selles töötab. Tee meile samasse “kuubikusse” liivakast.
Sellest kuubikust teete liivakasti. Nad ütlevad teile kohe: "Tahame etapi andmebaasi, mida uuendatakse iga päev tootmisest, et saaksime aru, et see töötab andmebaasis, kuid samal ajal ei rikuks tootmisandmebaasi."

Sa elad selle kõige sees. Väljaandmiseni on jäänud 2 nädalat, nad ütlevad teile: "Nüüd jälgime seda kõike ..." See tähendab. jälgida klastri infrastruktuuri, jälgida mikroteenuste arhitektuuri, jälgida tööd välisteenustega...

Ja mu kolleegid võtavad tavapärase skeemi peast välja ja ütlevad: “No siin on kõik selge! Installige programm, mis seda kõike jälgib. Jah, jah: Prometheus + Grafana + pistikprogrammid.
Ja nad lisavad: "Teil on kaks nädalat aega, veenduge, et kõik on turvaline."

Paljudes projektides, mida näeme, on jälgimiseks eraldatud üks inimene. Kujutage ette, et tahame palgata inimest 2 nädalaks jälgima ja kirjutame talle CV. Millised oskused peaksid sellel inimesel olema, arvestades kõike, mida me seni oleme öelnud?

• Ta peab mõistma raua infrastruktuuri jälgimist ja toimimise spetsiifikat.
• Ta peab mõistma Kubernetese jälgimise eripära (ja kõik tahavad minna "kuubikusse", sest saate kõigest abstraktsiooni võtta, peita, sest ülejäänuga tegeleb administraator) - ennast, selle infrastruktuuri ja mõistma, kuidas rakendusi jälgida. sees.
• Ta peab mõistma, et teenused suhtlevad üksteisega erilisel viisil, ja teadma teenuste omavahelise suhtlemise eripära. Täiesti võimalik on näha projekti, kus mõned teenused suhtlevad sünkroonselt, sest muud võimalust ei saa. Näiteks läheb taustaprogramm RESTi kaudu gRPC kaudu kataloogiteenusesse, võtab vastu toodete loendi ja tagastab selle tagasi. Sa ei jõua siin ära oodata. Ja teiste teenustega töötab see asünkroonselt. Vii tellimus kohaletoimetajale, saada kiri vms.
  Tõenäoliselt olete sellest kõigest juba ujunud? Ja admin, kes peab seda jälgima, läks veelgi segadusse.
• Ta peab oskama õigesti planeerida ja planeerida – sedamööda, kuidas tööd läheb aina rohkem.
• Seetõttu peab ta looma loodud teenusest strateegia, et mõista, kuidas seda konkreetselt jälgida. Ta vajab arusaamist projekti arhitektuurist ja selle arengust + arusaamist arenduses kasutatavatest tehnoloogiatest.

Meenutagem täiesti tavalist juhtumit: mõned teenused on PHP-s, mõned Go-s, mõned JS-is. Nad töötavad kuidagi üksteisega. Siit pärineb termin "mikroteenus": üksikuid süsteeme on nii palju, et arendajad ei saa projektist tervikuna aru. Üks osa meeskonnast kirjutab JS-is teenuseid, mis töötavad iseseisvalt ega tea, kuidas ülejäänud süsteem töötab. Teine osa kirjutab teenuseid Pythonis ja ei sega teiste teenuste tööd, need on oma piirkonnas isoleeritud. Kolmas on teenuste kirjutamine PHP-s või milleski muus.
Kõik need 20 inimest on jagatud 15 teenuseks ja ainult üks administraator peab sellest kõigest aru saama. Lõpeta! jagasime süsteemi lihtsalt 15 mikroteenuseks, sest 20 inimest ei saa kogu süsteemist aru.

Aga seda tuleb kuidagi jälgida...

Mis on tulemus? Sellest tulenevalt on üks inimene, kes tuleb välja kõigega, millest terve arendajate tiim aru ei saa ja samas peab ta teadma ja oskama ka seda, mida eelpool osutasime - riistvarataristu, Kubernetese infrastruktuur jne.

Mida ma võin öelda... Houston, meil on probleeme.

Kaasaegse tarkvaraprojekti jälgimine on omaette tarkvaraprojekt

Valest veendumusest, et monitooring on tarkvara, areneb meil usk imedesse. Kuid imet paraku ei juhtu. Te ei saa zabbixi installida ja eeldada, et kõik töötab. Pole mõtet Grafanat installida ja loota, et kõik saab korda. Suurem osa ajast kulub teenuste toimimise ja nende omavahelise suhtluse kontrolli korraldamisele, välissüsteemide toimimise kontrollimisele. Tegelikult ei kuluta 90% ajast mitte skriptide kirjutamisele, vaid tarkvara arendamisele. Ja sellega peaks tegelema meeskond, kes mõistab projekti tööd.
Kui selles olukorras visatakse üks inimene jälgimisse, siis juhtub katastroof. Mis juhtub igal pool.

Näiteks on mitu teenust, mis suhtlevad omavahel Kafka kaudu. Tellimus saabus, saatsime Kafkale teate tellimuse kohta. Seal on teenus, mis kuulab teavet tellimuse kohta ja saadab kauba teele. Seal on teenus, mis kuulab tellimuse kohta infot ja saadab kasutajale kirja. Ja siis ilmub veel hulk teenuseid ja me hakkame segadusse minema.

Ja kui annate selle ka administraatorile ja arendajatele selles etapis, kui vabastamiseni on jäänud veidi aega, peab inimene kogu sellest protokollist aru saama. Need. Sellise mastaabiga projekt võtab palju aega ja seda tuleks süsteemi arendamisel arvesse võtta.
Aga väga sageli, eriti startup’ides, näeme, kuidas jälgimine lükkub hilisemaks. “Nüüd teeme Proof of Concepti, käivitame sellega, laseme kukkuda – oleme valmis ohverdama. Ja siis me jälgime seda kõike." Kui (või kui) projekt hakkab raha teenima, soovib ettevõte lisada veelgi rohkem funktsioone – kuna see on tööle hakanud, tuleb seda edasi arendada! Ja olete punktis, kus peate esmalt jälgima kõike eelnevat, mis ei võta 1% ajast, vaid palju rohkem. Ja muide, jälgimiseks on vaja arendajaid ja lihtsam on lasta neil uute funktsioonide kallal töötada. Selle tulemusena kirjutatakse uusi funktsioone, kõik läheb sassi ja olete lõputus ummikseisus.

Niisiis, kuidas jälgida projekti algusest peale ja mida teha, kui saad projekti, mida tuleb jälgida, aga sa ei tea, kust alustada?

Esiteks peate planeerima.

Lüüriline kõrvalepõige: väga sageli alustatakse infrastruktuuri jälgimisest. Meil on näiteks Kubernetes. Alustuseks installime Prometheuse koos Grafanaga, installime "kuubi" jälgimiseks pistikprogrammid. Mitte ainult arendajatel, vaid ka administraatoritel on kahetsusväärne tava: "Me installime selle pistikprogrammi, kuid tõenäoliselt teab pistikprogramm, kuidas seda teha." Inimestele meeldib alustada lihtsast ja otsekohesest, mitte olulistest tegudest. Ja infrastruktuuri jälgimine on lihtne.

Esmalt otsustage, mida ja kuidas soovite jälgida, ning seejärel valige tööriist, sest teised inimesed ei saa teie eest mõelda. Ja kas nad peaksid? Teised inimesed mõtlesid endamisi universaalse süsteemi üle – või ei mõelnud seda pistikprogrammi kirjutades üldse. Ja see, et sellel pistikprogrammil on 5 tuhat kasutajat, ei tähenda, et sellest kasu oleks. Võib-olla saab teist 5001. lihtsalt seetõttu, et seal oli juba varem 5000 inimest.

Kui hakkate infrastruktuuri jälgima ja teie rakenduse taustaprogramm ei reageeri, kaotavad kõik kasutajad ühenduse mobiilirakendusega. Ilmub viga. Nad tulevad teie juurde ja ütlevad: "Rakendus ei tööta, mida sa siin teed?" - "Me jälgime." — "Kuidas jälgida, kui te ei näe, et rakendus ei tööta?!"

1. Usun, et jälgimist tuleb alustada täpselt kasutaja sisenemispunktist. Kui kasutaja ei näe, et rakendus töötab, on see kõik, see on tõrge. Ja seiresüsteem peaks selle eest kõigepealt hoiatama.
2. Ja alles siis saame infrastruktuuri jälgida. Või tehke seda paralleelselt. Infrastruktuuriga on see lihtsam – siin saame lõpuks lihtsalt zabbixi installida.
3. Ja nüüd peate minema rakenduse juurte juurde, et mõista, kus asjad ei tööta.

Minu põhiidee on, et seire peaks käima paralleelselt arendusprotsessiga. Kui segate jälgimismeeskonna tähelepanu muude ülesannete täitmiseks (CI/CD loomine, liivakasti loomine, infrastruktuuri ümberkorraldamine), hakkab jälgimine maha jääma ja te ei pruugi arendusele kunagi järele jõuda (või varem või hiljem peate selle peatama).

Kõik tasemete järgi

Nii näen ma seiresüsteemi korraldust.

1) Rakenduse tase:

• rakenduste äriloogika jälgimine;
• teenuste tervisenäitajate jälgimine;
• integratsiooni jälgimine.

2) Infrastruktuuri tase:

• orkestratsioonitaseme jälgimine;
• süsteemitarkvara jälgimine;
• raua taseme jälgimine.

3) Jällegi rakendustase – aga inseneritootena:

• rakenduste logide kogumine ja jälgimine;
• APM;
• jälgimine.

4) Hoiatus:

• hoiatussüsteemi korraldamine;
• tööülesannete süsteemi korraldamine;
• "teadmistebaasi" ja töövoo korraldamine juhtumite töötlemiseks.

Oluline: hoiatuseni jõuame mitte pärast, vaid kohe! Pole vaja käivitada monitooringut ja “kuidagi hiljem” välja mõelda, kes hoiatusi saavad. Lõppude lõpuks, mis on jälgimise ülesanne: aru saada, kus süsteemis midagi valesti töötab, ja anda sellest teada õigetele inimestele. Kui jätate selle lõpuni, saavad õiged inimesed teada, et midagi läheb valesti, vaid helistades "meie jaoks ei tööta miski".

Rakenduskiht – äriloogika jälgimine

Siin räägime sellest, et kontrollida, kas rakendus töötab kasutaja jaoks.

Seda taset tuleks teha arendusfaasis. Näiteks on meil tingimuslik Prometheus: see läheb serverisse, mis kontrollib, tõmbab lõpp-punkti ja lõpp-punkt kontrollib API-d.

Kui sageli palutakse kodulehte jälgida, et veenduda saidi töös, annavad programmeerijad käepideme, mida saab tõmmata iga kord, kui neil on vaja API töös veenduda. Ja programmeerijad võtavad ja kirjutavad praegu veel /api/test/helloworld
Ainus viis veenduda, et kõik töötab? - Ei!

• Selliste kontrollide loomine on sisuliselt arendajate ülesanne. Ühiktestid peaksid kirjutama koodi kirjutavad programmeerijad. Sest kui lekitate selle administraatorile: "Kutt, siin on kõigi 25 funktsiooni API-protokollide loend, palun jälgige kõike!" - miski ei õnnestu.
• Kui prindite "tere maailm", ei saa keegi kunagi teada, et API peaks töötama ja töötab. Iga API muudatus peab kaasa tooma muudatuse kontrollides.
• Kui teil on juba selline probleem, peatage funktsioonid ja määrake arendajad, kes neid tšekke kirjutavad, või nõustuge kahjudega, nõustuge sellega, et midagi pole kontrollitud ja see ebaõnnestub.

Tehnilised nõuanded:

• Kontrollide korraldamiseks korraldage kindlasti väline server – peate olema kindel, et teie projekt on välismaailmale juurdepääsetav.
• Korraldage kontrolle kogu API protokolli, mitte ainult üksikute lõpp-punktide lõikes.
• Looge testitulemustega prometheuse lõpp-punkt.

Rakenduskiht – tervisemõõdikute jälgimine

Nüüd räägime teenuste välistest tervisenäitajatest.

Otsustasime, et jälgime kõiki rakenduse “käepidemeid”, kasutades väliseid kontrolle, mida kutsume välja välisest seiresüsteemist. Kuid need on "käepidemed", mida kasutaja "näeb". Tahame olla kindlad, et meie teenused ise toimivad. Siin on parem lugu: K8s on tervisekontroll, et vähemalt "kuubik" ise saaks veenduda, et teenus töötab. Kuid pooled tšekkidest, mida olen näinud, on samad trükised "tere maailm". Need. Nii et ta tõmbab pärast kasutuselevõttu korra, vastas ta, et kõik on korras - see on kõik. Ja teenusel, kui see pakub oma API-d, on selle sama API jaoks tohutult palju sisenemispunkte, mida tuleb samuti jälgida, sest me tahame teada, et see töötab. Ja me juba jälgime seda sees.

Kuidas seda õigesti tehniliselt rakendada: iga teenus näitab oma praeguse jõudluse lõpp-punkti ja Grafana (või mõne muu rakenduse) graafikutel näeme kõigi teenuste olekut.

• Iga API muudatus peab kaasa tooma muudatuse kontrollides.
• Looge kohe uus teenus tervisemõõdikutega.
• Administraator võib tulla arendajate juurde ja küsida "lisage mulle paar funktsiooni, et ma kõigest aru saaksin ja lisage selle kohta teave oma jälgimissüsteemi." Kuid arendajad vastavad tavaliselt: "Me ei lisa midagi kaks nädalat enne avaldamist."
  Andke arendusjuhtidele teada, et selliseid kahjusid tuleb, andke teada ka arendusjuhtide juhtkonnale. Sest kui kõik kukub, helistab keegi ikkagi ja nõuab "pidevalt langeva teenuse" jälgimist (c)
• Muide, määrake arendajad Grafana jaoks pistikprogrammide kirjutamiseks - see on administraatoritele hea abi.

Rakenduse kiht – integratsiooni jälgimine

Integratsiooni monitooring keskendub ärikriitiliste süsteemide vahelise suhtluse jälgimisele.

Näiteks on 15 teenust, mis omavahel suhtlevad. Need ei ole enam eraldi saidid. Need. me ei saa teenust iseseisvalt tõmmata, hankida /helloworld ja mõista, et teenus töötab. Kuna tellimise veebiteenus peab saatma bussile info tellimuse kohta - bussist peab laoteenus selle teate kätte saama ja sellega edasi töötama. Ja meilide levitamise teenus peab seda kuidagi edasi töötlema jne.

Seetõttu ei saa me iga üksiku teenuse kallal torkides aru, et see kõik töötab. Sest meil on kindel buss, mille kaudu kõik suhtleb ja suhtleb.
Seetõttu peaks see etapp tähistama teenuste testimise etappi teiste teenustega suhtlemiseks. Kommunikatsiooni jälgimist on võimatu korraldada sõnumivahendajat jälgides. Kui on teenus, mis väljastab andmeid ja teenus, mis neid vastu võtab, siis maaklerit jälgides näeme ainult andmeid, mis lendavad küljelt küljele. Isegi kui meil õnnestus kuidagi nende andmete interaktsiooni sisemiselt jälgida - et teatud tootja postitab andmed, keegi loeb neid, see voog läheb edasi Kafkasse -, ei anna see meile ikkagi teavet, kui üks teenus saatis sõnumi ühes versioonis , kuid teine ​​teenus ei oodanud seda versiooni ja jättis selle vahele. Me ei saa sellest teada, sest teenused ütlevad meile, et kõik töötab.

Mida soovitan teha:

• Sünkroonse suhtluse jaoks: lõpp-punkt teeb päringuid seotud teenustele. Need. võtame selle lõpp-punkti, tõmbame teenuse sees skripti, mis läheb kõikidesse punktidesse ja ütleb "Ma võin tõmmata sinna, ja tõmba sinna, ma saan tõmmata sinna..."
• Asünkroonse suhtluse jaoks: sissetulevad sõnumid – lõpp-punkt kontrollib siini testsõnumite olemasolu ja kuvab töötlemise oleku.
• Asünkroonse suhtluse jaoks: väljuvad sõnumid – lõpp-punkt saadab testsõnumid siinile.

Nagu tavaliselt: meil on teenus, mis viskab andmed bussi. Tuleme selle teenuse juurde ja palume teil rääkida meile selle integratsiooni seisundist. Ja kui teenus peab tootma sõnumi kusagil kaugemal (WebApp), siis toodab ta selle testsõnumi. Ja kui me käivitame teenust OrderProcessingi poolel, postitab see esmalt midagi, mida saab postitada iseseisvalt ja kui on mõned sõltuvad asjad, siis loeb see siinist testsõnumite komplekti, saab aru, et suudab neid töödelda, teatab sellest ja vajadusel postitage need edasi ja selle kohta ütleb ta - kõik on ok, ma olen elus.

Väga sageli kuuleme küsimust "kuidas saame seda lahinguandmetega testida?" Näiteks räägime samast tellimisteenusest. Tellimus saadab teated lattu, kus kaup maha kantakse: me ei saa seda lahinguandmetel testida, sest “minu kaup kantakse maha!” Lahendus: planeerige kogu see test juba eos. Teil on ka ühikutestid, mis teevad mõnitamist. Seega tehke seda sügavamal tasemel, kus teil on suhtluskanal, mis ei kahjusta ettevõtte toimimist.

Infrastruktuuri tase

Infrastruktuuri monitooring on midagi, mida on pikka aega peetud seireks.

• Infrastruktuuri monitooringu saab ja tuleks käivitada eraldi protsessina.
• Te ei tohiks alustada käimasoleva projekti infrastruktuuri jälgimisega, isegi kui soovite. See on valu kõigile devoppidele. “Kõigepealt jälgin klastrit, jälgin infrastruktuuri” – st. Esiteks jälgib see allpool olevat, kuid ei lähe rakendusse. Sest rakendus on devopsi jaoks arusaamatu asi. See lekitati talle ja ta ei saa aru, kuidas see töötab. Aga ta mõistab infrastruktuuri ja alustab sellest. Aga ei – alati tuleb esmalt rakendust jälgida.
• Ärge laske hoiatuste arvuga liiale minna. Arvestades tänapäevaste süsteemide keerukust, lendavad hoiatused pidevalt ja selle märguannete hunnikuga tuleb kuidagi elada. Ja valveisik, olles vaadanud sada järgmist hoiatust, otsustab: "Ma ei taha sellele mõelda." Hoiatused peaksid teavitama ainult kriitilistest asjadest.

Rakenduse tase äriüksusena

Põhipunktid:

• ELK. See on tööstusharu standard. Kui te mingil põhjusel logisid ei koonda, alustage seda kohe.
• APM. Välised APM-id kui viis rakenduste jälgimise kiireks sulgemiseks (NewRelic, BlackFire, Datadog). Saate selle asja ajutiselt installida, et vähemalt kuidagi mõista, mis teiega toimub.
• Jälgimine. Kümnetes mikroteenustes tuleb kõike jälgida, sest taotlus ei ela enam iseenesest. Seda on hiljem väga raske lisada, seega on parem jälgimine kohe arenduses ajastada - see on arendajate töö ja kasulikkus. Kui te pole seda veel rakendanud, viige see ellu! Vaata Jaeger/Zipkin

Hoiatus

• Teavitussüsteemi korraldus: hunniku asjade jälgimise tingimustes peaks teadete saatmiseks olema ühtne süsteem. Grafanas saate. Läänes kasutavad kõik PagerDuty't. Hoiatused peaksid olema selged (nt kust need tulid...). Ja soovitav on kontrollida, et teateid üldse laekuks
• Valvesüsteemi korraldus: hoiatusi ei tohiks saata kõigile (kas reageerivad kõik rahvamassis või ei reageeri keegi). Samuti peavad arendajad olema valvel: määratlege kindlasti vastutusvaldkonnad, tehke selged juhised ja kirjutage sinna, kellele täpselt helistada esmaspäeval ja kolmapäeval ning kellele helistada teisipäeval ja reedel (muidu ei helistata kellelegi isegi suure probleemi korral - nad kardavad teid äratada või häirida: üldiselt ei meeldi inimestele helistada ja teisi inimesi äratada, eriti öösel). Ja selgitage, et abi küsimine ei ole ebakompetentsuse näitaja ("Ma küsin abi, see tähendab, et ma olen halb töötaja"), julgustage abi paluma.
• „Teadmistebaasi” ja intsidentide töötlemise töövoo korraldamine: iga tõsise intsidendi jaoks tuleks kavandada surmajärgne uuring ja ajutise meetmena tuleks registreerida toimingud, mis intsidendi lahendavad. Ja muutke tavaks, et korduvad hoiatused on patt; need tuleb koodi või infrastruktuuri töös fikseerida.

Tehnoloogia virn

Kujutame ette, et meie virn on järgmine:

• andmete kogumine - Prometheus + Grafana;
• logianalüüs - ELK;
• APM või Tracing jaoks – Jaeger (Zipkin).

Valikute valik ei ole kriitiline. Sest kui alguses saite aru, kuidas süsteemi jälgida ja plaanite kirja panna, siis hakkate valima oma vajadustele vastavaid tööriistu. Küsimus on selles, mille valisite kõigepealt jälgida. Sest võib-olla ei vasta alguses valitud tööriist üldse teie vajadustele.

Mõned tehnilised punktid, mida viimasel ajal kõikjal näen:

Prometheust surutakse Kubernetese sisse – kes selle välja mõtles?! Kui teie klaster jookseb kokku, mida te teete? Kui teil on keeruline klaster sees, siis peaks klastri sees olema mingisugune seiresüsteem ja mõni väljas, mis kogub andmeid klastri seest.

Klastris kogume palke ja kõike muud. Kuid seiresüsteem peab olema väljas. Väga sageli on klastris, kus Promtheus on sisemiselt paigaldatud, ka süsteeme, mis kontrollivad saidi toimimist väliselt. Mis siis, kui teie side välismaailmaga on katkenud ja rakendus ei tööta? Selgub, et sees on kõik korras, kuid see ei tee asja kasutajate jaoks lihtsamaks.

Järeldused

• Arengu jälgimine ei ole utiliitide paigaldamine, vaid tarkvaratoote arendamine. 98% tänasest monitooringust on kodeerimine. Teenustes kodeerimine, väliste kontrollide kodeerimine, välisteenuste kontrollimine ja see on kõik.
• Ärge raisake oma arendajate aega jälgimisele: see võib võtta kuni 30% nende tööst, kuid see on seda väärt.
• Devops, ärge muretsege, et te ei saa midagi jälgida, sest mõned asjad on täiesti teistsugused. Sa ei olnud programmeerija ja jälgimistöö on täpselt nende töö.
• Kui projekt juba töötab ja seda ei jälgita (ja olete juht), eraldage jälgimiseks ressursse.
• Kui toode on juba tootmises ja olete devops, kellel kästi "seadistada monitooring" - proovige juhtkonnale selgitada, millest ma seda kõike kirjutasin.

See on Saint Highload++ konverentsi raporti laiendatud versioon.

Kui olete huvitatud minu ideedest ja mõtetest selle ja sellega seotud teemade kohta, siis siin saate seda teha loe kanalit 🙂

Allikas: www.habr.com