Surnud jälgimine? — Tere tulemast jälgimise maailma

Meie ettevõte tegeleb alates 2008. aastast peamiselt infrastruktuuride haldamise ja ööpäevaringse tehnilise toe pakkumisega veebiprojektidele: meil on üle 400 kliendi, mis moodustab umbes 15% Venemaa e-kaubandusest. Seetõttu on meie toena pakutav arhitektuur väga mitmekesine. Kui midagi läheb katki, oleme kohustatud seda 15 minuti jooksul parandama. Kuid et mõista, et avarii on toimunud, tuleb projekti jälgida ja reageerida intsidentidele. Kuidas seda aga teha?

Ma arvan, et korraliku jälgimissüsteemi puudumine toob kaasa hädasid. Kui hädasid ei oleks, siis seisneks mu kõne ühes lauses: "Palun installige Prometheus + Grafana ja pluginad 1, 2, 3." Kahjuks ei toimi see enam niimoodi. Peamine probleem on selles, et kõik usuvad endiselt millegisse, mis eksisteeris 2008. aastal, arvestades tarkvarakomponente.

Seoses jälgimissüsteemi korraldamisega julgen öelda, et... hästi korraldatud jälgimise projekte ei eksisteeri. Ja olukord on nii halb, 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?

Me kõik oleme kokku puutunud järgnevate lugudega: töötab üks devops, üks admin, kelle poole tuleb arendajate meeskond ja ütleb — "me oleme välja andnud, nüüd jälgi". Mida jälgida? Kuidas see töötab?

Okei. Jälgime vanamoodsalt. Aga see on juba muutunud ja selgub, et sa jälgisid teenust A, mis muutus teenuseks B, mis suhtleb teenusega C. Kuid arendajate meeskond ütleb sulle: "Pane tarkvara paika, see peab ju kõik jälgima!"

Nii et mis on muutunud? — Kõik on muutunud!

2008. aasta. Kõik on suurepärane

On paar Entwickler, üks server, üks andmebaasi server. Sealt see kõik algab. Meil on teatud info, seadistame Zabbixi, Nagios'e, Cacti. Ja seejärel seadistame arusaadavad alertid CPU, kõvakettade töö, kettaruumi kohta. Teeme ka paar käsitsi kontrolli, et veenduda, et veebileht vastab ja tellimused jõuavad andmebaasi. Ja kõik – oleme enam-vähem kaitstud.

Kui võrrelda tol ajal administratori tehtud töömahu, mis oli seotud jälgimise tagamisega, siis 98% sellest oli automaatne: inimene, kes tegeleb jälgimisega, peab mõistma, kuidas Zabbixi seadistada, kuidas teda konfigureerida ja seadistada alertid. Ainult 2% – välised kontrollid: et veebileht vastab ja teeb päringuid andmebaasi, et uued tellimused on saabunud.

2010. aasta. Koormus kasvab.

Me hakkame veebiteenuseid skaleerima, lisame otsingumootori. Tahame olla kindlad, et tootekataloog sisaldab kõiki tooteid. Ja et tooteotsing töötab. Et andmebaas töötab, et tellimused tehakse, et veebileht reageerib väljastpoolt ja vastab kahel pool. serverite ja kasutaja ei visata veebilehelt välja, kuni ta ümber jaotatakse teisele serverile jne. Entiteetide arv suureneb.

Kestus, mis on seotud infrastruktuuriga, jääb endiselt juhataja peas kõige olulisemaks. Õhus on endiselt idee, et inimene, kes tegeleb jälgimisega, on see, kes installib Zabbixi ja suudab seda konfigureerida.

Kuid samal ajal ilmuvad tööd väliste auditite läbiviimiseks, otsingumootori indekseerija päringute skriptide komplekti loomiseks, skriptide komplekti, et kontrollida, kas indekseerimisel toimub muudatusi, ning skriptide komplekti, mis kontrollivad, et teenusele edastatakse kaupu jne.

Pange tähele: ma kirjutasin kolm korda "skriptide komplekt". See tähendab, et jälgimise eest vastutav ei ole enam lihtsalt see, kes installib Zabbixi. See on inimene, kes hakkab kodeerima. Kuid meeskonna peas ei muutu siiani midagi.

Aga maailm muutub ja keerulisemaks. Lisanduvad virtualiseerimise kihid, mitu uut süsteemi. Need hakkavad omavahel suhtlema. Kes ütles „käib mikroteenuste õhk?” Kuid iga teenus näeb endiselt välja nagu eraldi sait. Me saame sellele ligi ja mõista, et see pakub vajalikku teavet ning töötab iseseisvalt. Ja kui oled administraator, kes pidevalt tegeleb projektiga, mis on kestnud 5-7-10 aastat, siis need teadmised kogunevad: ilmub uus tase — sa oled selle teadvustanud, tuleb veel üks tase — sa oled selle teadvustanud…

Aga harva keegi toetab projekti 10 aastat.

Monitooringumehe CV

Oletame, et sa said uude idufirmasse, kus kohe oli 20 arendajat, kirjutati 15 mikroteenust, ja sina oled administraator, kellele öeldakse: "Ehita CI/CD. Paluuuuun." Sa ehitasid CI/CD ja äkki kuuled: "Meil on keeruline töötada tootmises 'kubikus', aru saamata, kuidas seal rakendus töötab. Tee meile see 'kubik' sama 'liivakasti' sisse."
Te loob sandkasten selle kuubiku sees. Teile öeldakse kohe: „Me tahame andmebaasi, mis uuendatakse iga päev tootmisest, et mõista, kas see töötab andmebaasil, kuid samas mitte rikuda tootmisandmebaasi.”

Te elate selles kõiges. Kaks nädalat on jäänud väljaandmiseni, teile öeldakse: „Nüüd peaksime seda kõike jälgima...” See tähendab jälgida klastristruktuuri, jälgida mikroteenuste arhitektuuri, jälgida koostööd väliste teenustega...

Ja kolleegid tuletavad meelde lihtsat schaemat ja ütlevad: „Siin on ju kõik selge! Pane paika programm, mis seda kõike jälgib.” Jah, jah: Prometheus + Grafana + lisamoodulid.
Ja nad lisavad: „Sul on kaks nädalat, tee nii, et kõik oleks usaldusväärne.”

Paljudes projektides, mida me näeme, on jälgimise jaoks määratud üks inimene. Kujutage ette, et soovime kaheks nädalaks palgata inimesi, kes tegeleb jälgimisega, ja koostame talle CV. Milliste oskustega peaks see inimene olema, arvestades kõike, mida oleme varem öelnud?

• Ta peab mõistma jälgimist ja riistvara infrastruktuuri spetsiifikat.
• Ta peab mõistma Kubernetes'e jälgimise eripära (ja kõik tahavad „kuubikut”, sest see võimaldab kõigest eemaldunde, ning adminn haldab kõike muud) — tema enda, selle infrastruktuuri ja kujundama, kuidas jälgida rakendusi selle sees.
• Ta peab mõistma, et teenused suhtlevad omavahel eriviisidel ning teadma teenustevahelise suhtluse spetsiifikat. On täiesti reaalsed projektid, kus osa teenuseid suhtleb sünhroonselt, sest teisiti ei saa. Näiteks, backend töötab REST'i ja gRPC kaudu, et suhelda katalooge teenusega, saada tooteid nimekiri ja tagasi tuua. Siin ei saa oodata. Teiste teenustega töötab ta asünkroonselt. Edastada tellimus kullerteenusele, saata kiri jne.
  Te juba ilmselt tunnete end kogu selle pärast segaduses? Ent adminn, kellel on seda jälgida, on veel rohkem segaduses.
• Ta peab olema suuteline õigesti planeerima ja planeerima — kuna tööd on aina rohkem ja rohkem.
• Seetõttu peab ta looma strateegia loodud teenusest, et aru saada, kuidas seda konkreetselt jälgida. Tal on vaja arusaamist projekti arhitektuurist ja selle arengust, samuti tehnoloogiatest, mida arenduses kasutatakse.

Tuletame meelde täiesti normaalset olukorda: osa teenustest on php-s, osa teenustest Go-s, osa teenustest JS-is. Nad töötavad omavahel mingil moel koos. Sealt tuli termin 'mikroteenus': eraldi süsteeme on nii palju, et arendajad ei suuda projekti tervikuna mõista. Üks meeskonna osa kirjutab JS-is teenuseid, mis töötavad iseenesest ja ei tea, kuidas ülejäänud süsteem töötab. Teine osa kirjutab teenuseid Pythonis ja ei puuduta, kuidas teised teenused töötavad, nad on oma valdkonnas isoleeritud. Kolmas kirjutab teenuseid php-s või millegagi muuga.
Need 20 inimest on jagatud 15 teenusele ning olemas on vaid üks admin, kes peab kõik selle läbi mõistma. Peatu! Me just jagasime süsteemi 15 mikroteenuseks, sest 20 inimest ei saa kogu süsteemi aru.

Kuid seda tuleb kuidagi jälgida...

Kokkuvõttes on üks inimene, kelle pea mahub kõik, mida terve arendajate meeskond ei suuda mõista, ja ta peab siiski teadma ning oskama kõike, mida me eespool näitasime — raudne infrastruktuur, Kubernetes infrastruktuur jne.

Mida siin öelda... Houston, meil on probleemid.

Kaasaegse tarkvaraprojekti seire on iseenesest tarkvaraprojekt.

Valeusku, et seire on tarkvara, loob meile usu imedesse. Kahjuks imesid ei ole. Ei tohi paigaldada Zabbixi ja loota, et kõik töötab. Pole mõtet paigaldada Grafanat ja loota, et kõik on hästi. Suurem osa ajast kulub teenuste töö kontrollimiseks ja nendevaheliseks suhtluseks, samuti väliste süsteemide töö kontrollimiseks. Tegelikult kulub 90% ajast mitte skriptide kirjutamisele, vaid tarkvara arendamisele. Sellega peaks tegelema meeskond, kes mõistab projekti tööd.
Kui selles olukorras panna üks inimene seirele, siis juhtub katastroof. Ja see juhtub igal pool.

Näiteks on mitmeid teenuseid, mis räägivad omavahel läbi Kafka. Kui tellimus saabub, saadame tellimuse sõnumi Kafkasse. On teenus, mis kuulab tellimuse teavet ja teostab kaupade saatmise. On teenus, mis kuulab tellimuse teavet ja saadab kasutajale e-kirja. Ja siis ilmub veel hulk teenuseid ja me hakkame segadusse minema.

Aga kui te anate selle administraatorile ja arendajatele hetkel, kui enne väljalaskmist on jäänud vähe aega, peab inimesel olema aega selle koosoleku protokolliga tutvuda. See tähendab, et sellise ulatusega projekt võtab märkimisväärselt aega ja süsteemi väljatöötamisse peab see olema sisse arvestatud.
Kuid tihti, eriti algajates ettevõtetes, näeme, et jälgimine lükatakse edasi. "Praegu teeme Proof of Concept'i, käivitame sellega, las see kukub – oleme valmis ohverdama. Ja siis jälgime kõike seda." Kui (või juhul, kui) projekt hakkab kasumit tooma, soovib äri veel rohkem funktsioone arendada – sest see on ju hakanud töötama, seega on vaja veel rohkem tekitada! Ja olete punktis, kus kõigepealt tuleb jälgida kõike eelnevat, mis ei võta 1% ajast, vaid palju rohkem. Ja muide, jälgimiseks on vaja arendajaid, keda on lihtsam suunata uusi funktsioone looma. Lõpuks kirjutatakse uusi funktsioone, kõik kuhjub, ja te olete lõputus ummikus.

Kuidas siis jälgida projekti alates algusest ning mida teha, kui teil on projekt, mida on vaja jälgida, ja te ei tea, kust alustada?

Esiteks, tuleb planeerida.

Lüüriline kõrvalekalle: sageli alustatakse infrastruktuuri jälgimisest. Näiteks meie Kubernetesega. Alustame sellest, et paigaldame Prometheuse koos Grafanaga, installime pluginid 'kuubiku' jälgimiseks. Mitte ainult arendajatel, vaid ka administraatoritel on kurb praktika: 'Paigaldame selle plugina, eks see plugin teab, kuidas seda teha.' Inimesed armastavad alustada lihtsate ja arusaadavate asjadega, mitte oluliste tegevustega. Ja infrastruktuuri jälgimine on just selline lihtne tegevus.

Esialgu otsustage, mida ja kuidas soovite jälgida, seejärel valige sobiv tööriist, kuna teised inimesed ei saa teie eest mõelda. Ja kas nad peaksidki? Teised inimesed mõtlesid enda, universaalsete süsteemide peale — või ei mõelnud üldse, kui seda plugina kirjutati. Ja see, et sellel pluginil on 5000 kasutajat, ei tähenda, et see toob mingit kasu. Võib-olla saate 5001-ks lihtsalt seetõttu, et seal oli juba 5000 inimest.

Kui olete alustanud oma rakenduse infrastruktuuri ja tagasilise jälgimise järelevalvet ning see on lõpetanud vastamise, kaotavad kõik kasutajad ühenduse mobiilirakendusega. Tõuseb veateade. Teie juurde tullakse ja küsitakse: „Rakendus ei tööta, millega te siin tegelete?“ — „Me jälgime.“ — „Kuidas te jälgite, kui ei näe, et rakendus ei tööta?!”

1. Arvan, et jälgimist tuleks alustada eelkõige kasutaja sisenemispunktist. Kui kasutaja ei näe, et rakendus töötab — on see ebaõnnestumine. Ja jälgimissüsteem peab sellest eelkõige teavitama.
2. Ja alles siis saame jälgida infrastruktuuri. Või teha seda paralleelselt. Infrastruktuuriga on lihtsam — siin saame lõpuks lihtsalt paigaldada zabbixi.
3. Ja nüüd tuleb minna rakenduse juurte juurde, et mõista, kus miski ei tööta.

Minu peamine mõte on see, et jälgimine peaks käima paralleelselt arendamise protsessiga. Kui te hajutate jälgimismeeskonna teistele ülesannetele (CI/CD loomine, liivakast, infrastruktuuri ümberkorraldamine), hakkab jälgimine maha jääma ja te ei pruugi kunagi arendust taas püüdma hakata (või varem või hiljem peate selle peatama).

Kõik tasemetel

Nii näen ma monitooringusüsteemi ülesehitust.

1) Rakenduse tase:

• rakenduse äri-logi jälgimine;
• teenuste health-metrika jälgimine;
• integratsioonimonitooring.

2) Infrastruktuuri tase:

• orkestreerimistase jälgimine;
• süsteemilise tarkvara jälgimine;
• riistvara taseme jälgimine.

3) Taas rakenduse tase — kuid inseneritootena:

• rakenduse logide kogumine ja vaatamine;
• APM;
• tracing.

4) Alerteerimine:

• teavitussüsteemi korraldamine;
• valve süsteemi korraldamine;
• teadmistebaasi ja sündmuste töötlemise töövoo korraldamine.

Oluline: jõuame alerteerimise juurde kohe, mitte hiljem! Ei tohi käivitada monitooringut ja mõelda, kellele alerdid minema hakkavad, hiljem. Sest monitooringu ülesanne on mõista, kus süsteemis midagi ei tööta, ja anda sellest vajalikule rahvale teada. Kui see jätab viimasele, siis vajalikud inimesed saavad teada, et midagi on valesti, ainult kõne tõttu: "meil ei tööta miski."

Rakenduse tase — äri-loogika jälgimine

Siin on jutt rakenduse töötamise fakti kontrollimisest kasutaja jaoks.

See tase tuleb teha arenduse etapis. Näiteks, meil on hüpoteetiline Prometheus: ta pääseb serverisse, mis tegeleb kontrollidega, kutsub endpointi, ja endpoint läheb ja kontrollib API-d.

Kui sageli küsitakse, et monitorida ajaloolist lehte, et veenduda, et sait töötab, annavad programmeerijad käsiraamat, mida saab iga kord tõmmata, kui tuleb veenduda, et API töötab. Ja programmeerijad kirjutavad samal ajal /api/test/helloworld.
Kuidas olla kindel, et kõik töötab? — Ei!

• Selliste kontrollide loomine on põhimõtteliselt arendajate ülesanne. Üksuste testid peaksid kirjutama need programmeerijad, kes kirjutavad koodi. Sest kui sa annad adminile 'Küsimus, siin on API protokollide nimekiri kõigist 25 funktsioonist, palun kontrolli kõik!' — ei saa midagi, ei tule sellest midagi.
• Kui teete print 'hello world', ei saa keegi kunagi teada, et API peaks ja tõesti töötab. Iga API muutmine peab endaga kaasa tooma kontrollide muutmise.
• Kui teil on juba see probleem – peatage funktsioonid ja määrake arendajad, kes need kontrollid kirjutavad, või leppige kaotustega, leppige sellega, et mitte midagi ei kontrollita ja see hakkab kukkuma.

Tehnilised nõuanded:

• Korrigeerige kindlasti välist serverit kontrollide korraldamiseks — peate kindel olema, et teie projekt on välismaailmale ligipääsetav.
• Organiseerige kontroll kõigi API protokollide jaoks, mitte ainult eraldi lõpp-punktide jaoks.
• Looge prometheus-lõpppunkt kontrollide tulemuste jaoks.

Rakendustasand — tervisemõõdikute jälgimine

Nüüd räägime teenuste välistest tervisemõõdikutest.

Oleme otsustanud, et jälgime kõiki rakenduse "käepidemeid" välistest kontrollidest, mida kutsume välja välisest jälgimissüsteemist. Kuid need on just need "käepidemed", mida kasutaja "näeb". Soovime olla kindlad, et meie teenused töötavad. Siin on asi parem: K8s-l on tervise kontrollid, et vähemalt "kuubik" saaks veenduda, et teenus töötab. Kuid pool testidest, mida olen näinud, on see sama print “hello world”. Ehk siis, ta küsib ühe korra pärast juurutamist, tal vastati, et kõik on korras — ja kõik. Teenusel, kui ta REST-is oma API-d väljastab, on tohutult palju sissepääsupunkte sellel API-l, mida samuti tuleb jälgida, sest soovime teada, et see töötab. Jälgime seda juba seestpoolt.

Kuidas seda tehniliselt õigesti ellu viia: iga teenus esitab endpoint'i oma praeguse töökindluse kohta, ja Grafana (või mõne muu rakenduse) graafikutel näeme kõigi teenuste staatust.

• Iga API muudatus peaks endaga kaasa tooma kontrollide muudatused.
• Uue teenuse loomisel lisage kohe ka health-mõõdikud.
• Administraator võib minna arendajate juurde ja paluda: "lisage mulle paar funktsiooni, et ma kõik saaksin aru ja saaksin selle oma jälgimissüsteemi lisada." Kuid arendajad vastavad tavaliselt: "Kaks nädalat enne väljaandmist me midagi lisama ei hakka."
  Olgu arendajate juhid teadlikud, et sellised kaotused on võimalikud, ja ka arendajate juhtkond peaks seda teadma. Sest kui kõik kokku kukub, siis keegi helistab ja nõuab jälgida "alati kokku kukkuvat teenust" (c)
• Muide, suunake arendajad Grafana plugin'ite kirjutamisele - see oleks administratiividele suureks abiks.

Rakenduse tase - Integreerimisjälgimine

Integreerimisjälgimine keskendub ärikriitiliste süsteemide vahelise suhtluse jälgimisele.

Näiteks on olemas 15 teenust, mis omavahel suhtlevad. Need ei ole enam eraldi veebisaidid. See tähendab, et me ei saa teenust lihtsalt kokku tõmmata, saada /helloworld ja mõista, et teenus töötab. Sest tellimuste töötlemise veebiteenus peab saatma tellimuste info bussile — bussilt peab laohaldusteenus selle sõnumi kätte saama ja sellega edasi töötama. Ja e-kirjade saatmise teenus peab seda kuidagi edasi töötama jne.

Seega ei saa me aru, klõpsates igas erinevas teenuses, et kõik see töötab. Sest meil on mingi buss, mille kaudu kõik suhtleb ja koordineerib oma tegevust.
Seetõttu peaks see etapp tähistama teenuste testimise etappi, mis suhtlevad teiste teenustega. Ei saa nõuda, et jälgitud sõnumite vahendaja korraldaks suhtluse jälgimise. Kui on teenus, mis edastab andmeid, ja teenus, mis need andmed vastu võtab, näeme vahendaja jälgimisel ainult andmeid, mis liiguvad edasi-tagasi. Isegi kui me õnnestuks mingil viisil jälgida nende andmete vahelist interaktsiooni – et mingi tootja postitab andmeid, keegi neid loeb, ja see voog jätkub Kafka's – ei anna see meile ikkagi teavet, kui üks teenus saatis sõnumi ühes versioonis ja teine teenus ei oodanud seda versiooni ning jättis selle vahele. Me ei saa sellest teada, sest teenused ütlevad meile, et kõik töötab.

Kuidas soovitan teha:

• Sünkroonse suhtluse puhul: lõpp-punkt teeb päringud seotud teenustele. See tähendab, et me võtame selle lõpp-punkti, käivitame skripti teenuses, mis läheb läbi kõikide punktide ja ütleb: „ma saan sealt käivitada, ja sealt käivitada, saan sealt käivitada...“
• Asünkroonses suhtluses: sissetulevad sõnumid — lõpp-punkt kontrollib bussilt test-sõnumite olemasolu ja annab töötlemise staatuse.
• Asünkroonses suhtluses: väljaminevad sõnumid — lõpp-punkt saadab bussile test-sõnumid.

Nagu tavaliselt: meil on teenus, mis saadab andmeid bussi. Me tuleme selle teenuse juurde ja palume rääkida selle integratsiooni tervisest. Ja kui teenus peab edasi saatma mingi sõnumi kuhugi (WebApp), siis ta saadab selle test-sõnumi edasi. Ja kui me tõukame teenust OrderProcessing poole, postitab ta esmalt, mida ta saab iseseisvalt postitada, ja kui on mingeid sõltuvaid asju, siis ta loeb bussilt reas test-sõnumeid, mõistab, mida ta saab töödelda, teatab sellest ja kui vaja, postitab need edasi ning ütleb selle kohta — kõik okei, ma olen elus.

Väga sageli kuuleme küsimust "kuidas saame seda testida tootmisandmetel?" Näiteks räägime tellimuste teenusest. Tellimus saadab sõnumeid laos, kus tooted arvestatakse maha: me ei saa testida seda tootmisandmetel, sest "mul arvestatakse tooted maha!" Lahendus: planeerige kogu see test algfaasis. Teil on ju unit-testid, mis teevad mock-e. Seega, tehke seda sügavamal tasemel, kus teil on suhtluskanal, mis ei kahjusta äri toimimist.

Infrastruktuuri tase

Infrastruktuuri jälgimine on juba ammu tuntud kui tõeline jälgimine.

• Infrastruktuuri jälgimist saab ja tuleb käivitada kui eraldi protsess.
• Ära alusta infrastruktuuri jälgimisega töötavas projektis, isegi kui see on väga soovitav. See on vaev kõikide DevOps'i spetsialistide jaoks. "Esiteks jälgin klastrit, jälgin infrastruktuuri" – tähendab, et kõigepealt jälgitakse seda, mis on allpool, ja rakendusse ei minda. Sest rakendus on DevOps'ile arusaamatu asi. Tal on see antud ja ta ei saa aru, kuidas see töötab. Infrastruktuur on aga talle tuttav ja ta alustab selle jälgimisega. Kuid ei – alati tuleb kõigepealt jälgida rakendust.
• Ärge liialdage häiretega. Arvestades kaasaegsete süsteemide keerukust, lendavad häired pidevalt ning sellest kuhjast tuleb kuidagi elada. Ja häiriv inimene vaadates sajat häiret otsustab: "ei taha selle üle mõelda". Häired peaksid teavitama ainult kriitilistest asjadest.

Rakenduse taseme kui ärielemendi

Peamised punktid:

• ELK. See on tööstusstandard. Kui mingil põhjusel te ei koonda logisid, alustage kiiresti selle tegemist.
• APM. Välimised APM-id kui kiire viis rakenduse jälgimise sulgemiseks (NewRelic, BlackFire, Datadog). Saate ajutiselt selle asja paigaldada, et kuidagi aru saada, mis teiega toimub.
• Jälgimine. Kümnetes mikroteenustes peate jälgima kõike, kuna päring ei ela enam eraldi. Hiljem lisamine on väga keeruline, seega on parem kohe arenduses jälgimine ette planeerida — see on töö ja arendajate tööriist. Kui ei ole veel rakendatud – rakendage kindlasti! Vaata Jaeger/Ziipkin.

Häired

• Teavitussüsteemi korraldamine: monitoring'i tingimustes peab olema ühtne teavituste saatmise süsteem, näiteks Grafanas. Lääne riikides kasutatakse kõikjal PagerDuty'd. Teavitused peavad olema arusaadavad (nt kust nad tulid…). Samuti on soovitatav jälgida, et teavitused tõesti kohale jõuavad.
• Kohustuste süsteemi korraldamine: teated ei tohi tulla kõigile (muidu reageerivad kõik või ei reageeri keegi). On-call olema peab ka arendajatel: määrake kindlasti vastutusalad, koostage selge juhend ja kirja pange, kellele täpselt esmaspäeval ja kolmapäeval helistada ning kellele teisipäeval ja reedel (vastasel juhul ei helistata kellelegi isegi suure häda korral — kardetakse kedagi äratada, häirida: inimesed üldiselt ei meeldi helistada ja teisi, eriti öösel, äratada). Ja selgitage, et abi küsimine ei ole ebakompetentsuse näitaja („ma küsin abi — seega olen halb töötaja“), julgustage abi palumist.
• Teadmistebaasi ja sündmuste töötlemise töövoo korraldamine: iga tõsise sündmuse puhul peab olema planeeritud tagasivaade, ajutise meetmena peavad olema fikseeritud tegevused, mis lahendavad sündmuse. Ja looge praktika, et korduvad teated on patt; neid tuleb fikseerida koodis või infrastruktuuri töödes.

Tehnoloogiline stack

Kujutame ette, et meie tehnoloogia on järgmine:

• andmete kogumine — Prometheus + Grafana;
• logifailide analüüs — ELK;
• APM või jälgimise jaoks — Jaeger (Zipkin).

Valikuvõimalused ei ole kriitilised. Kui olete alguses aru saanud, kuidas süsteemi jälgida, ja koostanud plaani, hakkate seejärel valima tööriistu vastavalt oma nõudmistele. Küsimus on selles, mida otsustasite alguses jälgida. Sest võib-olla valitud tööriist ei sobi teie vajadustega üldse.

Mõned tehnilised punktid, mida olen viimasel ajal igal pool näinud:

Prometheus on pandud Kubernetesesse — kes selle välja mõtles?! Kui teie klaster kokku kukub, mida teete? Kui teil on keeruline klaster sees, peaks seal töötama mingi jälgimissüsteem, ja mingi — väljaspool, mis kogub andmeid klastri seest.

Klastri sees kogume logisid ja kõike muud. Aga jälgimissüsteem peaks olema väljaspool. Sageli on klastris, kus on sisseehitatud Prometheus, ka süsteemid, mis teevad väliseid kontrollimisi. Ent kui teie ühendused välismaailmaga katkevad ja rakendus ei tööta? Tundub, et sees on kõik korras, kuid kasutajatele ei ole see lihtsam.

Järeldused

• Jälgimise arendamine ei seisne utiliitide paigaldamises, vaid tarkvaratoote väljatöötamises. 98% tänapäeva jälgimisest on koodimine. Koodimine teenustes, koodimine välistes kontrollides, välistes teenustes kontrollimine ja kõikvõimalik muu.
• Ärge raisake arendajate aega jälgimise peale: see võib võtta kuni 30% nende tööst, kuid on seda väärt.
• DevOps'id, ärge muretsege, kui te ei saa midagi jälgida, sest mõned asjad vajavad hoopis teistsugust mõtteviisi. Te ei olnud programmeerija ja jälgimise töö on just nende töö.
• Kui projekt juba töötab ja ei ole jälgitud (ja teie olete juhataja) — eraldage ressursid jälgimiseks.
• Kui toode on juba tootmises ja te olete devops, kellele öeldi "seadistage jälgimine" — proovige juhtkonnale selgitada, mida ma siinkohal kirjutasin.

See on pikendatud versioon ettekandest konverentsil Saint Highload++.

Kui teid huvitavad minu ideed ja mõtisklused IT- ja selleteemal, siis siin on võimalus lugeda kanalit 🙂

Allikas: habr.com