Hävitav jälgimine? — Elagu jälgimine

Meie ettevõte on alates 2008. aastast peamiselt infrastruktuuri haldamise ja veebiprojektide ööpäevaringsse tehnilise toe pakkumisega. Meil on üle 400 kliendi, mis moodustab umbes 15% Venemaa e-kaubandusest. Seega on meie toetuses väga mitmekesine arhitektuur. Kui midagi läheb katki, peame selle 15 minuti jooksul parandama. Kuid avarii toimumise mõistmiseks tuleb projekti jälgida ja sündmustele reageerida. Kuidas seda teha?

Arvan, et korraliku monitooringusüsteemi loomisel tekib probleem. Kui probleemi ei oleks, koosneks mu ettekanne ühest väitest: "Palun installige Prometheus + Grafana ja pistikprogrammid 1, 2, 3." Kahjuks ei toimi see enam nii. Peamine probleem on see, et kõik usuvad endiselt millessegi, mis eksisteeris 2008. aastal, tarkvarakomponentide osas.

Monitooringusüsteemi korraldamise osas julgen öelda, et... õigesti monitooritud projekte ei eksisteeri. Ja olukord on nii halb, et kui midagi kukub, on oht, et see jääb märkamata — kõik usuvad ju, et "kõike monitooritakse".
Võib-olla monitooritakse kõike. Aga kuidas?

Me kõik oleme kokku puutunud järgmise looga: töötab üks devops, üks admin, ja neile tuleb arendajate meeskond ja ütleb — "me oleme välja andnud, nüüd monitoorige." Mida monitoorida? Kuidas see töötab?

Okei. Monitoorime vanaviisi. Ja see juba muutub ning selgub, et olete monitoorinud teenust A, mis on muutunud teenuseks B, mis suhtleb teenusega C. Aga arendajate meeskond ütleb: "Pane tarkvara paigaldama, see peaks ju kõik monitoorima!"

Mis siis muutus? — Kõik muutus!

2008. aasta. Kõik on suurepärane.

On paar arendajat, üks server, üks andmebaasi server. Sealt see kõik algab. Meil on mingid andmed, paigaldame zabbixi, Nagios’e, cacti. Ja siis seadistame arusaadavad häired CPU, ketaste töö ja ketaste kohta. Teeme veel paar käsitsi kontrolli, et veebisaidi vastus oleks olemas, et tellimused jõuavad andmebaasi. Ja kõik – oleme enam-vähem kaitstud.

Kui võrrelda töömahu ulatust, mida toona tegi admin, et tagada jälgimise toimimine, siis 98% sellest oli automaatne: inimene, kes tegeleb jälgimisega, peab mõistma, kuidas Zabbix paigaldada, kuidas seda seadistada ja seadistada teatised. Ja 2% - need on välised kontrollid: kas sait vastab ja teeb päringu andmebaasi, kas uued tellimused on saabunud.

2010. aasta. Koormus kasvab

Alustame veebide skaleerimist, lisame otsimootori. Me tahame olla kindlad, et toote kataloog sisaldab kõiki tooteid. Ja et toodete otsimine töötab. Et andmebaas töötab, et tellimused tehakse, et sait vastab väljastpoolt ja vastab kahest serverid ja kasutaja ei visata veebisaidilt välja, kuni ta on teisele serverile ümber tasakaalustatud, jne. Oluliste elementide arv kasvab.

Samas seondub infrastruktuuriga seotud element endiselt enim juhataja peas. Ikka on peas idee, et inimene, kes tegeleb jälgimisega, on see, kes paneb Zabbixi paigaldama ja suudab seda seadistada.

Aga samas tekivad tööülesanded väliste kontrollide läbiviimiseks, otsimootori indekseerimise päringute skriptide komplekti loomine, skriptide komplekti loomiseks, et kontrollida, et otsing muutub indekseerimise käigus, skriptide komplekti, mis kontrollivad, et tarneteenusele edastatakse tooted jne.

Pane tähele: ma olen kolm korda kirjutanud «skriptide komplekt». Seega on vastutav jälgimise eest enam mitte see, kes lihtsalt paigaldab Zabbixi. See on inimene, kes hakkab kodeerima. Kuid meeskonna peas ei muutu veel midagi.

Küll aga maailm muutub, keerukamaks minnes. Lisandub virtualiseerimistasand, mitu uut süsteemi. Need hakkavad omavahel suhtlema. Kes ütles, et «mikroteenuste lõhn hakkab olema?» Kuid iga teenus näeb ikkagi eraldiseisvana välja nagu veebisait. Me saame sellele pöörduda ja mõista, et see annab vajalikku teavet ja töötab ning kui oled admin, kes pidevalt tegeleb projektiga, mis on arenenud 5-7-10 aastat, siis need teadmised kogunevad: ilmub uus tase - sa oled selle tunnetanud, ilmub veel üks tase - sa oled selle tunnetanud...

Aga harva, kui keegi toetab projekti 10 aastat.

Jälgimise spetsialisti kokkuvõte

Oletame, et olete tulnud uude idufirmasse, kus on kohe 20 arendajat ja 15 mikrosüsteemi, ning teie roll on administraator, kellele öeldakse: "Ehita CI/CD. Paluuuuun." Te ehitasite CI/CD ja äkki kuulete: "Meil on keeruline töötada tootmises 'konteineris', teadmata, kuidas seal rakendus töötab. Tee meile liivakast samasse 'konteinerisse'."
Te loote selle liivakasti selle konteineri sees. Teile öeldakse kohe: "Me tahame etappidatabelit, mis iga päev uuendatakse tootmisest, et mõista, et see töötab andmebaasis, kuid et samal ajal mitte rikkuda tootmisandmebaasi."

Te elate selle kõik. Rilis on jäänud 2 nädalat, teile öeldakse: "Nüüd peaksime selle kõik jälgima…" St. jälgida klastrite infrastruktuuri, jälgida mikrosüsteemide arhitektuuri, jälgida koostööd väliste teenustega…

Kolleegid toovad välja harjumuspärase skeemi ja ütlevad: "Siin on ju kõik selge! Installi programm, mis seda kõike jälgib." Jah, jah: Prometheus + Grafana + pluginad.
Ja lisavad samal ajal: "Sul on kaks nädalat, tee nii, et kõik oleks usaldusväärne."

Paljude projektide puhul, mida me näeme, on jälgimiseks määratud üks inimene. Kujutage ette, et me tahame kaheks nädalaks palgata inimese, kes tegeleks jälgimisega, ja koostame talle CV. Milliseid oskusi peaks sellel inimesel olema, kui arvestada kõike, mida me varem ütlesime?

• Ta peab mõistma jälgimist ja želee infrastruktuuri tööd.
• Ta peab mõistma Kubernetes'i jälgimise spetsiifikat (kõik tahavad 'konteinerisse', sest seal on võimalik kõigest eristuda, peituda, et ülejäänud lahendab administraator) — selle iseenesest, selle infrastruktuuri ning mõistma, kuidas rakendusi seal sees jälgida.
• Ta peab mõistma, et teenused suhtlevad spetsiaalsete viisidega ja teadma teenuste omavahelise suhtluse spetsiifikat. On täiesti realistlik näha projekti, kus osa teenustest suhtleb sünkroonselt, sest teisiti ei saa. Näiteks backend läheb REST-i kaudu, gRPC kaudu katalooge teenusele, saab toote nimekirja ja toob tagasi. Siin ei saa oodata. Ja teiste teenustega töötab ta asünkroonselt. Edastada tellimus kullerteenusele, saata kiri jne.
  Te olete kindlasti juba kõigest sellest segaduses? Aga administraator, kellel on vaja seda jälgida, on veel rohkem segaduses.
• Ta peab oskama õigesti planeerida, kuna tööd on üha rohkem.
• Seetõttu peab ta looma strateegia loodud teenuse jaoks, et mõista, kuidas seda konkreetselt monitoorida. Tal peab olema arusaam projekti arhitektuurist ja selle arengust ning tehnoloogiatest, mida arenduses kasutatakse.

Kujutame ette täiesti tavalist juhtumit: osa teenuseid on php-s, osa teenuseid on Go-s, osa teenuseid on JS-is. Need toimivad omavahel mingil moel. Sealt tuleneb ka termin "mikroteenus": eraldi süsteeme on nii palju, et arendajad ei suuda projekti tervikuna mõista. Üks meeskonna osa kirjutab JS teenuseid, mis töötavad iseseisvalt ja ei tea, kuidas ülejäänud süsteem töötab. Teine osa kirjutab teenuseid Pythonis ja ei sekku teiste teenuste toimimisse, nad on isoleeritud oma valdkonnas. Kolmas kirjutab teenuseid php-s või mõnes muus keeles.
Kõik need 20 inimest on jagatud 15 teenuse vahel ja ainult üks admin, kes peab kogu seda mõistma. Peatus! Me just jagasime süsteemi 15 mikroteenuseks, kuna 20 inimest ei suuda kogu süsteemi mõista.

Kuid seda tuleb kuidagi monitoorida...

Mis on tulemus? Tulemus on see, et on üks inimene, kelle pähe mahub kõik see, mida terve arendajate tiim ei suuda mõista, ja samas peab ta teadma ja oskama ka seda, mida me ülal oleme maininud — riistvara infrastruktuuri, Kubernetes'e infrastruktuuri jne.

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

Kaasaegse tarkvaraprojekti monitoorimine on iseenesest tarkvaraprojekt.

Valeusku, et monitoorimine on tarkvara, tekitab meis usu imelistesse asjadesse. Kahjuks imesid ei juhtu. Ei saa lihtsalt paigaldada zabbixi ja loota, et kõik töötab. Pole mõtet paigaldada Grafanat ja loota, et kõik läheb hästi. Suur osa ajast läheb teenuste töö ja nende omavahelise tegevuse kontrollimise korraldamisele ning väliste süsteemide töö kontrollimisele. Tegelikult kulub 90% ajast mitte skriptide kirjutamisele, vaid tarkvaraarendusele. Sellega peaks tegelema meeskond, kes mõistab projekti toimimist.
Kui selle olukorra juures panna üks inimene monitooringule, siis juhtub katastroof. Just see toimubki laialdaselt.

Näiteks on mitmeid teenuseid, mis suhtlevad omavahel läbi Kafka. Tuli tellimus, saatsime tellimusteate Kafka'sse. On teenus, mis kuulab tellimusteavet ja korraldab kauba kohaletoimetamise. On teenus, mis kuulab tellimusteavet ja saadab kasutajale kirja. Siis ilmub palju teisi teenuseid ja me hakkame segadusse minema.

Ent kui annate selle administraatorile ja arendajatele etapis, kui avaldamiseni on jäänud vähe aega, peab inimene kogu selle protokolli mõistma. See tähendab, et sellise ulatusega projekti jaoks kulub märkimisväärselt aega ning süsteemi arendamisel peab see olema ette nähtud.
Kuid väga sageli, eriti tulekahjude korral, näeme idufirmade puhul, et jälgimine lükatakse edasi. "Praegu teeme Proof of Concept'i, käivitame selle, lasta tal kukkuda - me oleme valmis ohverdama. Aja jooksul teeme kõik selle jälgimise." Kui (või kui) projekt hakkab raha teenima, soovib äri rakendada veel rohkem funktsioone — sest see on hakanud toimima, seega tuleks edasi arendada! Ja olete hetkes, kus alguses tuleb jälgida kogu eelnevat, mis ei võta 1% ajast, vaid märkimisväärselt rohkem. Ja muide, jälgimiseks on vaja arendajaid, kuid neid on lihtsam suunata uutele funktsioonidele. Lõpuks kirjutatakse uued funktsioonid, kõik arendatakse ja olete lõputus ummikus.

Kuidas jälgida projekti alates algusest ja mida teha, kui teile on antud projekt, mida tuleb jälgida, ja te ei tea, kust alustada?

Esiteks tuleb planeerida.

Lühiülevaade: väga sageli alustatakse infrastruktuuri jälgimisest. Näiteks on meil Kubernetes. Alustame sellega, et paigaldame Prometheuse koos Grafanaga, paigaldame "kubiku" jälgimise pluginaid. Mitte ainult arendajatel, vaid ka administraatoritel on kurb praktika: "Me paigaldame selle plugina, ja plugin tegelikult teab, kuidas seda teha." Inimesed armastavad alustada lihtsatest ja arusaadavatest asjadest, mitte olulistest tegevustest. Ja infrastruktuuri jälgimine on lihtsalt.

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

Kui olete hakanud jälgima oma rakenduse infrastruktuuri ja backend enam ei tööta, kaotavad kõik kasutajad ühenduse mobiilirakendusega. Tuleb viga. Teie juurde tullakse ja öeldakse: „Rakendus ei tööta, mille kallal te töötate?” — „Me jälgime.” — „Kuidas te jälgite, kui ei näe, et rakendus ei tööta?!“

1. Minu arvates tuleks jälgimisega alustada kasutaja sisenemispunktist. Kui kasutaja ei näe, et rakendus töötab — on kõik, see on ebaõnnestumine. Ja jälgimissüsteem peaks sellest esimesena hoiatama.
2. Ja alles siis saame infrastruktuuri jälgida. Või teha seda paralleelselt. Infrastruktuuriga on lihtsam — siin saame lõpuks lihtsalt paigaldada Zabbixi.
3. Ja nüüd tuleb minna rakenduse juurtel, et mõista, kus miski ei toimi.

Minu peamine mõte on, et jälgimine peab käima paralleelselt arendusprotsessiga. Kui eemaldate jälgimismeeskonna teistesse ülesannetesse (CI/CD loomine, liivakasti loomine, infrastruktuuri ümberkorraldamine), hakkab jälgimine maha jääma ja võib-olla ei jõua te enam kunagi arendustele järgi (või peate kas varakult arenduse peatama).

Kõik tasemete kaupa

Nii näen ma jälgimissüsteemi korraldamist.

1) Rakenduse tase:

• jälgimine rakenduse äriloo puhul;
• teenuste tervise meetrikate jälgimine;
• integratsioonijälgimine.

2) Infrastruktuuri tase:

• orkestreerimise taseme jälgimine;
• süsteemi tarkvara jälgimine;
• doonori taseme jälgimine.

3) Jälle rakenduse tase — aga juba inseneritootena:

• rakenduse logide kogumine ja jälgimine;
• APM;
• tracing.

4) Alerteerimine:

• hoiatamissüsteemi korraldamine;
• vahtkonna korraldamine;
• „teadmistebaasi” ja intsidendi töötlemise töövoo korraldamine.

Oluline: me jõuame jälgimise juurde mitte pärast, vaid kohe! Ei ole vaja käivitada jälgimist ja «kuidas iganes hiljem» välja mõelda, kellele häiret teated saadetakse. Sest jälgimise ülesanne on aru saada, kus süsteemis midagi ei toimi, ja teavitada sellest õigeid inimesi. Kui see jätta viimasele hetkele, saavad õiged inimesed teada, et midagi on valesti, alles siis, kui telefon heliseb: «meil ei tööta mitte miski».

Rakenduse tase — äriloogika jälgimine

Siin on jutt selle kohta, et kontrollitakse, kas rakendus töötab kasutaja jaoks.

See tase peaks olema loodud arendamise etapis. Näiteks, meil on harilik Prometheus: ta läheb serverisse, mis tegeleb kontrollidega, kutsub endpoint’i, ja endpoint läheb ja kontrollib API-d.

Kui sageli palutakse jälgida avalehte, et veenduda, et sait töötab, siis programmeerijad annavad nuppu, mida saab kutsuda igal korral, kui on vaja veenduda, et API töötab. Samal ajal kirjutavad programmeerijad ka /api/test/helloworld.
Kas ainus viis veenduda, et kõik töötab? — Ei!

• Selliste kontrollide loomine on põhimõtteliselt arendajate ülesanne. Üksuskatseid peaksid kirjutama programmeerijad, kes kirjutavad koodi. Sest kui sa anname selle administraatorile: «Kutt, siin on sulle kõigi 25 funktsiooni API protokollide nimekiri, palun jälgi kõike!» — siis ei juhtu mitte midagi.
• Kui teete print “hello world”, ei saa keegi kunagi teada, et API peaks ja tõesti töötab. Iga API muutus peaks endaga kaasa tooma muutuse kontrollides.
• Kui teil on juba selline probleem – peatage funktsioonid ja eraldage arendajad, kes need kontrollid kirjutavad, või leppige kaotustega, leppige, et mitte midagi ei kontrollita ja see hakkab alla kukkuma.

Tehnilised nõuanded:

• Kohustuslik on korraldada väline server kontrollide korraldamiseks — peate olema kindel, et teie projekt on välismaailmale ligipääsetav.
• Korraldage kontroll kogu API protokolli ulatuses, mitte ainult üksikute endpoint'e osas.
• Looge prometheus-endpoint kontrollide tulemustega.

Rakenduse tase — tervise meetrikate jälgimine

Nüüd on jutt väliste teenuste tervise meetrikatest.

Me otsustasime, et igasuguseid rakenduse „nuppe” jälgime väliste kontrollide abil, mida kutsume esile välisest jälgimisse süsteemist. Kuid need on just need „nupud”, mida kasutaja näeb. Me soovime olla kindlad, et meie teenused töötavad. Siin on lugu parem: K8s sisaldab tervisekontrolle, et vähemalt „kuubik” veenduks, et teenus töötab. Kuid pooltest kontrollidest, mida olen näinud, on sama print „hello world”. See tähendab, et ta kutsub seda pärast juurutamist kord, vastus on, et kõik on korras – ja ongi kõik. Kui teenus väljastab oma API-d REST-i kaudu, on tal tohutult sisenemiskohti selle API juurde, mida samuti tuleb jälgida, sest me tahame teada, et see töötab. Ja me jälgime seda juba seespidiselt.

Kuidas seda õigesti tehniliselt rakendada: iga teenus esitleb oma tööolekut endpointina ning Grafana (või mõne muu rakenduse) graafikutes näeme kõikide teenuste staatust.

• Iga API muudatus peaks kaasa tooma kontrollide muutmise.
• Uuendage uusi teenuseid kohe tervise mõõdikute lisamisega.
• Administraator võib minna arendajate juurde ja paluda "lisage paar funktsiooni, et ma saaksin kõik aru ja oma jälgimisse süsteemi selle info lisada." Kuid arendajad vastavad tavaliselt: "Kaks nädalat enne väljundit me midagi lisama ei hakka."
  Las arendajate juhid teavad, et selliseid kaotusi tuleb, las arendajate juhtkond samuti teab. Sest kui kõik kokku kukub, helistab keegi kindlasti ja nõuab, et „ pidevalt kokku kukkuvat teenust” jälgitaks (c)
• Muide, eraldage arendajad Grafana pluginate kirjutamiseks - see on administreerijatele hea abi.

Rakenduse tase - Integreerimise jälgimine

Integreerimise jälgimine keskendub kriitiliste ärisüsteemide vahelise suhtluse jälgimisele.

Näiteks on 15 teenust, mis suhtlevad omavahel. Need ei ole enam eraldiseisvad veebisaidid. St me ei saa kummagi teenuse juurde minna, saada /helloworld ja aru saada, et teenus töötab. Sest tellimuse vormistamise veebiteenus peab saatma tellimuste info bussile - bussist peab lao teenus saama selle sõnumi ja seda edaspidiselt töötlema. E-kirjade saatmise teenus peab seda kuidagi edasi töötlema jne.

Seega me ei saa aru, klõpsates iga eraldi teenuse peale, et see kõik töötab. Sest meil on mingi bussi, mille kaudu kõik suhtleb ja interakteerub.
Seetõttu peab see etapp tähistama teenuste testimise etappi teiste teenustega suhtlemisel. Ei saa lihtsalt jälgida sõnumite vahendajat ja korraldada suhtluse jälgimist. Kui on teenus, mis edastab andmeid, ja teenus, mis neid vastu võtab, siis jälgides vahendajat näeme vaid andmeid, mis liiguvad edasi-tagasi. Isegi kui me kuidagi suudame jälgida nende andmete interaktsiooni, — et mingi tootja postitab andmed, keegi loeb need, see voog jätkab liiklemist Kafka'sse — ei anna see meile ikkagi teavet, kui üks teenus edastas sõnumi ühes versioonis, aga teine teenus ei oodanud seda versiooni ja jättis selle vahele. Me ei saa sellest teada, kuna teenused ütlevad meile, et kõik töötab.

Kuidas ma soovitan tegutseda:

• Sünkroonses suhtluses: lõpp-punkt esitab päringud seotud teenustele. Ehk võtame selle lõpp-punkti, käivitame skripti teenuses, mis läbib kõik punktid ja ütleb: „ma saan seal tõmmata ja seal tõmmata, saan seal tõmmata...“
• Asünkroonses suhtluses: sissetulevad sõnumid — lõpp-punkt kontrollib bussi, et leida test-sõnumeid ja annab töötlemise staatuse.
• Asünkroonses suhtluses: väljaminevad sõnumid — lõpp-punkt saadab bussile test-sõnumid.

Kuidas tavaliselt toimub: meil on teenus, mis viskab andmeid bussi. Me tuleme sellesse teenusesse ja palume rääkida tema integratsioonilisest tervisest. Ja kui teenus peab edastama mingi sõnum edasi (WebApp), siis ta edastab selle test-sõnumi. Ja kui me tõmbame teenust tellimuste töötlemise poole, siis ta kõigepealt postitab seda, mida ta saab postitada sõltumatult, ja kui on mingeid sõltuvaid asju — siis ta loeb bussist komplekti test-sõnumeid, mõistab, mida ta saab töödelda, teatab sellest ja kui vaja, postitab neid edasi ning ütleb selle kohta — kõik on korras, ma olen elus.

Sageli kuuleme küsimust "kuidas me saame seda testida tootmisandmetega?" Näiteks räägime samast tellimuste teenusest. Tellimus saadab sõnumeid laosse, kus tooted kirjutatakse maha: me ei saa seda testida tootmisandmetega, sest „mul hakkavad tooted maha kandma!" Lahendus: planeerige see test algfaasis. Teil on ju olemas 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 asi, mis on juba ammu määratletud kui tõeline jälgimine.

• Infrastruktuuri jälgimist saab ja tuleb alustada kui eraldi protsessi.
• Ärge alustage infrastruktuuri jälgimist töötaval projektil, isegi kui see on väga soovitud. See on probleem, millega kõik DevOps'i spetsialistid silmitsi seisavad. "Esiteks jälgin klastrit, jälgin infrastruktuuri" – see tähendab, et ta jälgib kõige madalamat taset, aga rakendusse ei tungi. Sest rakendus on DevOps'ile arusaamatu asi. Selle on talle edastatud, ja ta ei mõista, kuidas see töötab. Kuid ta mõistab infrastruktuuri ja alustab sealt. Aga ei — alati tuleks kõigepealt jälgida rakendust.
• Ärge liialdage teavituste arvuga. Arvestades kaasaegsete süsteemide keerukust, lendavad teavitused pidevalt ja selle hulga teavitustega tuleb kuidagi elada. Ja inimene, kes on valmis reageerima, vaatab sada järgmist teavitust ja otsustab, et "ma ei taha selle üle mõelda". Teavitused peaksid teavitama ainult kriitilistest asjadest.

Rakenduse tase kui äriüksus

Olulised punktid:

• ELK. See on tööstusstandardi määratlemine. Kui mingil põhjusel te ei kogu logisid, alustage selle tegemist kohe.
• APM. Välimised APM-id kiireks rakenduse jälgimise katmiseks (NewRelic, BlackFire, Datadog). Saate selle asja ajutiselt paigaldada, et natuke aru saada, mis teil toimub.
• Jälgimine. Kümnetes mikroteenustes peate jälgima kõike, sest päring ei ela enam iseseisvalt. Hiljem juurde lisamine on väga keeruline, seega on parem kavandada jälgimine arenduses kohe — see on arendajate töö ja tööriist. Kui pole veel rakendanud - rakendage! Vaadake Jaeger/Zipkin

Teavitamine

• Teavitussüsteemi loomine: jälgimise tingimustes peab olema ühtne teavitussüsteem. Grafanas on see võimalik. Läänes kasutatakse kõikjal PagerDuty'd. Teated peavad olema arusaadavad (näiteks, kust nad tulid…). Ja on soovitatav kontrollida, et teated tõepoolest kohale jõuavad.
• Vahetuste süsteemi loomine: häired ei tohiks tulla kõigile (muud moodi reageerivad kõik koos või ei reageeri keegi). Vahetuse ajal peavad olema ka arendajad: määrake kindlasti vastutusalad, koostage selged juhised ja kirjutage sellesse, kellele täpselt esmaspäeval ja kolmapäeval helistada ning kellele teisipäeval ja reedel (muud moodi ei helistata aga suurte hädade korral — kartuses, et võetakse üles, segatakse: inimesed ei armasta helistada ja äratada teisi, eriti öösel). Ja selgitage, et abi küsimine ei ole ebakompetentsuse näitaja ("ma küsin abi — tähendab, et ma olen halb töötaja"), julgustage abitootmisi.
• Teadmiste baasi ja juhtumite töötlemise töövoo loomine: iga tõsise juhtumi korral peab olema kavandatud postmortem; ajutise abinõuna peavad olema fikseeritud toimingud, mis lahendavad juhtumi. Ja looge praktika, et korduvad häired on patt; need tuleb fikseerida koodis või infrastruktuuri töödes.

Tehnoloogiakogum

Kujutage ette, et meie tehnoloogia on järgmine:

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

Valikuvõimalused ei ole kriitilised. Sest kui olete alguses aru saanud, kuidas süsteemi jälgida, ja koostanud plaani, hakkate hiljem valima tööriistu vastavalt oma nõudmistele. Küsimus on, mida te alguses jälgida valisite. Sest võib-olla ei sobi tööriist, mille valisite alguses, teie nõudmistele üldse.

Mõned tehnilised aspektid, mida ma viimasel ajal igal pool näen:

Prometheust surutakse Kubernetesesse — kes selle välja mõtles?! Kui teie klaster kokku kukub, mida teete? Kui teil on keeruline klaster sees, peab töötama mingi jälgimissüsteem sees ja mingi — väljas, mis kogub andmeid klastrist.

Klastri sees kogume logisid ja kõike muud. Kuid jälgimissüsteem peab olema väljas. Väga sageli, kui klastris on Prometheus, mis on paigaldatud sisse, on seal ka süsteeme, mis teevad väliseid kontrollimisi veebisaidi töö kohta. Ja kui teie ühendus välismaailmaga katkeb ja rakendus ei tööta? Tundub, et teie sees on kõik korras, kuid kasutajatele ei ole sellest kasu.

Järeldused

• Jälgimise arendamine ei tähenda lihtsalt utiliitide installimist, vaid tarkvaratoote arendamist. 98% tänapäevastest jälgimistest on koodimine. Koodimine teenustes, koodimine väliste kontrollide jaoks, väliste teenuste testimine ja nii edasi.
• Ärge kahetsege arendajate aega jälgimiseks: 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 on üldse teistsugune mõtteviis. Te ei olnud programmeerija, aga jälgimise töö on just nende vastutus.
• Kui projekt juba töötab ja pole jälgitud (ja te olete juht), eraldage ressursid jälgimiseks.
• Kui toode on juba tootmises ja te olete DevOps, kellele öeldi «seadistada jälgimist», proovige selgitada juhtkonnale seda, millest ma rääkisin.

See on laiendatud versioon ettekandest konverentsil Saint Highload++.

Kui teid huvitavad minu ideed ja mõtted IT-st ja selle ümber, siis siin on võimalus lugeda kanalit 🙂

Allikas: habr.com