🥇Monitorimi i vdekur? — Rroftë monitorimi

Kompania jonë merret kryesisht me menaxhimin e infrastrukturës dhe mbështetje teknike 24/7 për projektet web që nga viti 2008: kemi më shumë se 400 klientë, duke përfaqësuar rreth 15% të tregtisë elektronike në Rusi. Prandaj, mbështetja ka një arkitekturë shumë të larmishme. Nëse diçka ndalon së funksionuari, ne jemi të detyruar ta riparojmë brenda 15 minutash. Por për të kuptuar se ndodhi një aksident, ne duhet të monitorojmë projektin dhe të reagojmë ndaj incidenteve. Si ta bëjmë këtë?

Mendoj se në organizimin e një sistemi të duhur monitorimi ndodhin probleme. Nëse nuk do të kishte probleme, fjalimi im do të ishte i përbërë nga një thënie: "Ju lutemi, instaloni Prometheus + Grafana dhe shtojcat 1, 2, 3". Fatkeqësisht, tani nuk funksionon kështu. Problemi kryesor është se të gjithë vazhdojnë të besojnë në diçka që ekzistonte në vitin 2008, sa i përket komponenteve të softuerit.

Sa i përket organizimit të sistemit të monitorimit, guxoj të them se... nuk ekzistojnë projekte me një monitorim të duhur. Situata është aq e keqe, saqë nëse diçka ndalet, ka rrezik që kjo të mbetet e papërshkruar — të gjithë besojnë se "këto gjëra monitorohen".
Ndoshta, gjithçka monitorohet. Por si?

Të gjithë ne kemi hasur në ndodhi si kjo: punon një devops, një administrator, dhe ekipin e zhvilluesve vjen dhe thotë — "ne u publikuan, tani monitoro". Çfarë të monitorohet? Si funksionon kjo?

Mirë. Po monitorojmë në mënyrën e vjetër. Por gjërat tashmë po ndryshojnë, dhe zbulohet se ju keni monitoruar shërbimin A, i cili u bë shërbimi B, i cili ndërvepron me shërbimin C. Por ekipi i zhvilluesve ju thotë: "Instalo software-in, ai duhet ta monitorojë gjithçka!"

Pra, çfarë ka ndryshuar? — Gjithçka ka ndryshuar!

Viti 2008. Gjithçka ishte në rregull.

Ka disa zhvillues, një server, një server DB. Këtu fillon gjithçka. Kemi disa informacione, instalojmë zabbix, Nagios, cacti. Pastaj vendosim alarme të qarta për CPU, për punën e hard-disqeve, për hapësirën në disqe. Bëjmë edhe disa kontrolle manuale, që faqja e internetit përgjigjet, që porositë po kalojnë në bazën e të dhënave. Dhe kjo është – jemi më shumë se të mbrojtur.

Nëse e krahasojmë vëllimin e punës që administratorët bënin për të siguruar monitorimin atëherë, 98% e saj ishte automatike: personi që merrej me monitorimin kishte për detyrë të kuptonte si ta instalonte Zabbix, si ta konfigurationonte dhe si të vendoste alarme. Dhe 2% – për kontrollet e jashtme: që faqja e internetit përgjigjet dhe bën kërkesë në bazë, që porositë e reja arrijnë.

Viti 2010. Rritet ngarkesa.

Nisim të shkallëzojmë web-in, shtojmë një motor kërkimor. Duam të jemi të sigurt se katalogu i produkteve përmban të gjitha produktet. Dhe se kërkimi i produkteve funksionon. Që baza funksionon, që porositë po bëhen, që faqja e internetit përgjigjet jashtë dhe e përgjigjet pa e nxjerrë përdoruesin nga faqja, derisa të ri-balancohet në server tjetër, etj. Entitetet po bëhen më të shumta. servera Për më tepër, entiteti që lidhet me infrastrukturën vazhdon të mbetet më i madhi në mendjen e menaxherit. Ideja se personi që merret me monitorimin është ai që do të vendosë zabbix dhe do ta konfiguronte, ende ekziston.

Por në të njëjtën kohë, shfaqen punët për të kryer kontrolle të jashtme, për të krijuar një grup skriptesh për kërkuesin e indeksonit, një grup skriptesh për të kontrolluar se diçka ndryshon gjatë procesit të indeksonit, një grup skriptesh që kontrollojnë se produket i dërgohen shërbimit të dorëzimit, etj.

Vini re: kam shkruar 3 herë "grup skriptesh". Pra, personi përgjegjës për monitorimin — nuk është më ai që thjesht instalon zabbix. Ky është një person që fillon të kodojë. Por në mendjet e ekipit, ende nuk ka ndryshime.

Por bota po ndryshon, duke u komplikuar gjithnjë e më shumë. Shtrohen shtresa virtualizimi, disa sisteme të reja. Ato fillojnë të ndërveprojnë me njëra-tjetrën. Kush tha "ka një pamje të mikroshërbimeve?" Por çdo shërbim duket ende si një faqe interneti e veçantë. Mund të qasemi ndaj tij dhe të kuptojmë se ai jep informacionin e nevojshëm dhe funksionon përvetë. Dhe nëse je administrator që merret vazhdimisht me një projekt që po zhvillohet për 5-7-10 vjet, këto njohuri grumbullohen: shfaqet një nivel i ri — e kupton këtë, shfaqet një tjetër nivel — e kupton këtë...

Por rrallë ndokush mbështet një projekt për 10 vjet.

Përmbledhje e monitorimit.

Supozoni se keni shkuar në një startup të ri, që menjëherë u rrit në 20 zhvillues, shkruajti 15 mikroshërbime, dhe ju — jeni një administrator, që ju thonë: "Ndërto CI/CD. Të lutem." Ju ndërtoni CI/CD dhe papritmas dëgjoni: "Na është e vështirë të punojmë me prodhimin në kub, duke mos kuptuar se si do të funksionojë aplikacioni atje. Na bëni një sandbox në të njëjtën kub."

Supozoni se erdhët në një startup të ri që menjëherë mori 20 zhvillues, shkroi 15 mikroshërbime, dhe ju — administratori, e cila ju thonë: "Ndihmona të ndërtojmë CI/CD. Të falënderojmë shumë." E ndërtuat CI/CD dhe papritmas dëgjoni: "Na duket e vështirë të punojmë me prodhimin në 'kub', pa e kuptuar se si do të funksionojë aplikacioni atje. Na bëj një sand Box në këtë 'kub' po ashtu."
Po krijoni një sandbox në këtë kub. Menjëherë ju thonë: «Duam një bazë të dhënash stage që përditësohet nga prodhimi, që të kuptojmë nëse funksionon me bazën e të dhënave, por pa prishur bazën e prodhimit».

Ju e jetoni të gjithë këtë. Kanë mbetur 2 javë deri në lançim, ju thonë: «Tani do të ishte mirë ta monitoronim këtë…» Domethënë, të monitoroni infrastrukturën klasterike, të monitoroni arkitekturën mikrosërvices, të monitoroni integrimin me shërbimet e jashtme…

Dhe kolegët e nxjerrin nga kokat e tyre një skemë të njohur dhe thonë: «Ktu është gjithçka e qartë! Vendos një program që ta monitorojë të gjithë këtë». Po po: Prometheus + Grafana + plugins.
Dhe shtojnë: «Ke dy javë, bëje që gjithçka të jetë e sigurt».

Në shumë projekte që shohim, monitorimi i besohet vetëm një personi. Imagjinoni se duam të punësojmë një person për 2 javë që do merret me monitorimin, dhe ne po i përgatitim një CV. Çfarë aftësish duhet të ketë ky person — nëse marrim parasysh gjithçka që kemi thënë më parë?

Ai duhet të kuptojë monitorimin dhe specifikat e punës së infrastrukturës harduerike.
Ai duhet të kuptojë specifikat e monitorimit të Kubernetes (të gjithë duan të kalojnë në «kubik», sepse mund të abstrahohen nga gjithçka, të fshihen, sepse administratori do t'i gjejë zgjidhjet për pjesët e tjera) — në vetvete, infrastrukturën e saj, dhe të kuptojë se si të monitorojë aplikacionet brenda saj.
Ai duhet të kuptojë se shërbimet komunikojnë me njëra-tjetrën në mënyra të veçanta dhe të dijë specifikat e ndërveprimit mes shërbimeve. Në fakt është e mundur të shohësh një projekt ku disa shërbime komunikojnë në mënyrë sinkrone, sepse nuk ka asnjë mundësi tjetër. Për shembull, backend-i përdor REST, autorizohet me gRPC për shërbimin e katalogut, merr listën e produkteve dhe e kthen mbrapsht. Këtu nuk mund të presësh. Ndërsa me shërbime të tjera punon asinkronisht. Dërgon një porosi te shërbimi i shpërndarjes, dërgon një email dhe tjerë.
Ndoshta keni humbur në të gjithë këtë? Dhe administratori, të cilit i nevojitet monitorimi, është edhe më i humbur.
Ai duhet të jetë i aftë të planifikojë dhe të planifikojë saktë — pasi puna po shtohet gjithnjë e më shumë.
Ai duhet, pra, të krijojë një strategji nga shërbimi i krijuar për të kuptuar se si të monitorojë konkretisht. I nevojitet një kuptim i arkitekturës së projektit dhe zhvillimit të tij + një kuptim i teknologjive që përdoren në zhvillim.

Le të kujtojmë një rast krejt normal: disa shërbime janë në PHP, disa shërbime në Go, disa shërbime në JS. Ato punohet disi mes tyre. Këtu ka lindur termi «mikrosërvic»: sistemet e veçanta janë bërë aq shumë sa që zhvilluesit nuk mund ta kuptojnë projektin në tërësinë e tij. Një pjesë e ekipit shkruan shërbime në JS, që funksionojnë vetë dhe nuk dinë si funkcionihet pjesa tjetër e sistemit. Një tjetër pjesë shkruan shërbime në Python dhe nuk përzihet me atë se si punojnë shërbimet e tjera, ato janë të izoluara në fushën e tyre. Një e treta — shkruan shërbime në PHP ose diçka tjetër.
Të gjithë këta 20 persona janë të ndarë në 15 shërbime, dhe ka vetëm një administrator, i cili duhet ta kuptojë të gjithë këtë. Ndalo! sapo e kemi ndarë sistemin në 15 mikrosërvica, sepse 20 njerëz nuk mund ta kuptojnë sistemin në tërësi.

Por ndonjëherë duhet ta monitorosh atë…

Çfarë rezultati ka? Rezultati është një njeri, që në mendje ka gjithçka që një ekip i tërë zhvilluesish nuk mund ta kuptojë, dhe për më tepër ai duhet të dijë dhe të jetë në gjendje të bëjë atë që e kemi përmendur më sipër — infrastrukturën harduerike, infrastrukturën Kubernetes etj.

Çfarë të themi… Hjuston, kemi probleme.

Monitorimi i një projekti modern softuerik — është vetë një projekt softuerik.

Nga besimi i gabuar se monitorimi është softuer, na lind besimi në mrekulli. Dhe mrekullitë, fatkeqësisht, nuk ndodhin. Nuk ka kuptim të vendosësh zabbix dhe të presësh që gjithçka të funksionojë. Nuk ka kuptim të vendosësh Grafana dhe të shpresosh që gjithçka do të jetë në rregull. Një pjesë e madhe e kohës do të shkojë për organizimin e kontrolleve të punës së shërbimeve dhe ndërveprimit të tyre, kontrollimi i si funksionojnë sistemet e jashtme. Faktikisht, 90% e kohës do të shkojë jo në shkruhen skriptet, por në zhvillimin e softuerit. Dhe këtë duhet ta bëjë ekipi që kupton funksionimin e projektit.
Nëse në këtë situatë një njeri hidhet në monitorim, atëherë do të ndodhi një katastrofë. Çfarë ndodh gjithandej.

Për shembull, ka disa shërbime që komunikojnë mes tyre përmes Kafka. Ka ardhur një porosi, ne e dërguam atë në Kafka. Ka një shërbim që dëgjon informacionin mbi porosinë dhe bën dërgesën e produktit. Ka një shërbim që dëgjon informacionin mbi porosinë dhe i dërgon një email përdoruesit. Pastaj shfaqen shumë shërbime të tjera, dhe ne fillojmë të habitemi.

Nëse i jepni këtë administratorëve dhe zhvilluesve në fazën kur mbetet pak kohë deri në lançim, dikush duhet të kuptojë të gjithë këtë protokoll. Projekti i këtij shtrirje kërkon kohë të konsiderueshme, dhe kjo duhet të jetë parashikuar në zhvillimin e sistemit.
Por shumë shpesh, veçanërisht në start-up, ne shohim se monitorimi shtyhet për më vonë. "Tani do të bëjmë Proof of Concept, do të fillojmë me të, le të bjerë – ne jemi të gatshëm të sakrifikojmë. Më pas, do ta monitorojmë gjithçka." Kur (ose nëse) projekti fillon të sjellë para, biznesi dëshiron të shtojë më shumë funksionalitete — sepse tani po funksionon, do të thotë se duhet të avancojmë më tej! Por ndodheni në një pikë ku fillimisht duhet të monitoroni gjithçka që ka ndodhur më parë, e cila nuk kërkon 1% kohë, por shumë më tepër. Dhe për monitorimin e nevojiten zhvillues, ndërsa është më e lehtë t'i drejtojmë për funksionalitete të reja. Në fund, shkruhen funksionalitete të reja, gjithçka avancon dhe ju jeni në një deadlock të pafund.

Si mund të monitoroni një projekt duke filluar nga e para, dhe çfarë duhet të bëni nëse keni marrë një projekt që duhet të monitoroni, por nuk e dini nga të filloni?

Së pari, duhet të planifikoni.

Për një moment lirsh: shpesh fillohet me monitorimin e infrastrukturës. Për shembull, kemi Kubernetes. Do të fillojmë duke instaluar Prometheus me Grafana, do të vendosim plugins për monitorimin e "kubikëve". Jo vetëm zhvilluesit, por edhe administratorët kanë një praktikë të hidhur: "Do të vendosim këtë plugin, ndoshta ai e di se si ta bëjë këtë." Njerëzit duan të fillojnë me diçka të thjeshtë dhe të kuptueshme, jo me veprime të rëndësishme. Dhe monitorimi i infrastrukturës është i thjeshtë.

Fillimisht vendosni se çfarë dhe si doni të monitoroni, pastaj zgjidhni mjetin, sepse të tjerët nuk mund të mendojnë për ju. A duhet? Të tjerët kanë menduar për veten e tyre, për një sistem universale — ose madje nuk kanë menduar fare kur e shkruan këtë plugin. Dhe ajo që ky plugin ka 5000 përdorues nuk do të thotë se ai ofron ndihmë. Ndoshta do të jeni 5001-i thjesht sepse deri tani kanë pasur 5000 njerëz.

Nëse keni filluar të monitoroni infrastrukturën dhe backend-i i aplikacionit tuaj ka ndalur përgjigjen, të gjithë përdoruesit do të humbin lidhjen me aplikacionin mobil. Një gabim do të shfaqet. Ata do t'ju vijnë dhe do të thonë: "Aplikacioni nuk funksionon, çfarë po bëni këtu?" — "Ne po monitorojmë." — "Si po monitoroni, nëse nuk e shihni se aplikacioni nuk funksionon?!"

Mendoj se duhet të filloni të monitoroni pikërisht nga pika e hyrjes së përdoruesit. Nëse përdoruesi nuk sheh se aplikacioni funksionon — është një dështim. Dhe sistemi i monitorimit duhet të japë alarmin për këtë në radhë të parë.
Dhe vetëm më pas mund të fillojmë të monitorojmë infrastrukturën. Ose ta bëjmë këtë paralelisht. Me infrastrukturën është më e lehtë — këtu përfundimisht mund të vendosim vetëm zabbix.
Dhe tani duhet të shkojmë në thelbin e aplikacionit për të kuptuar se ku gjërat nuk funksionojnë.

Idenë time kryesore është se monitorimi duhet të shkojë paralelisht me procesin e zhvillimit. Nëse e shkëputni ekipin e monitorimit për detyra të tjera (krijimi i CI/CD, sandbox, organizimi i infrastrukturës), monitorimi do të fillojë të vonohet dhe ndoshta kurrë nuk do e arrini zhvillimin (ose më herët ose më vonë do të duhet ta ndaloni atë).

Të gjitha në nivele

Ja si e shoh organizimin e sistemit të monitorimit.

1) Niveli i aplikacionit:

monitorimi i logjikës biznesore të aplikacionit;
monitorimi i metrikave shëndetësore të shërbimeve;
monitorimi i integrimit.

2) Niveli i infrastrukturës:

monitorimi i nivelit të orkestrimit;
monitorimi i sistemeve operativ;
monitorimi i nivelit "hardueri".

3) Prapë niveli i aplikacionit — por tashmë si produkt inxhinierik:

marrja dhe vëzhgimi i regjistrave të aplikacionit;
APM;
tracing.

4) Alarmin:

organizimi i sistemit të njoftimeve;
organizimi i sistemit të turneve;
organizimi i "bazës së njohurive" dhe flukset e punës për trajtimin e incidenteve.

E rëndësishme: arrijmë te alarmin jo pasi, por menjëherë! Nuk ka nevojë të nisni monitorimin dhe "si të jetë më vonë" të mendoni se kujt do t'i shkojnë alarmin. Sepse cila është detyra e monitorimit: të kuptoni se ku diçka nuk funksionon në sistem dhe t'i njoftoni njerëzit e nevojshëm. Nëse e lini për në fund, njerëzit e nevojshëm do të mësojnë që diçka nuk shkon mirë vetëm nëpërmjet telefonatës "nuk funksionon asgjë".

Niveli i aplikacionit — monitorimi i logjikës biznesore

Këtu flitet për kontrollet e vetë faktit që aplikacioni funksionon për përdoruesin.

Ky nivel duhet të bëhet në fazën e zhvillimit. Për shembull, kemi një Prometheus të kushtëzuar: ai shkon te serveri që merret me kontrollet, godet endpoint-in, dhe endpoint-i shkon dhe kontrollon API.

Kur kërkohet shpesh të monitorohet faqja kryesore për të siguruar që faqja e internetit po funksionon, programuesit japin një buton që mund të tërhiqet çdo herë që është e nevojshme të siguroheni që API po funksionon. Ndërkohë, programuesit gjithashtu e shkruajnë /api/test/helloworld
Një mënyrë e vetme për të siguruar që çdo gjë funksionon? — Jo!

Krijimi i kontrolleve të tilla është në thelb një detyrë për zhvilluesit. Testet e njësive duhet t'i shkruajnë programuesit që shkruajnë kod. Sepse, nëse ia jepni këtë një administratori "O burra, këtu ke një listë protokollesh të API-së për të gjitha 25 funksionet, të lutem monitoro të gjitha!" — nuk do të dalë asgjë.
Nëse bëni print "hello world", askush nuk do ta dijë kurrë që API duhet dhe në të vërtetë funksionon. Çdo ndryshim në API duhet të tërheqë pas vetes një ndryshim në kontrollet.
Nëse keni një problem të tillë - ndaloni funksionalitetet dhe caktoni zhvilluesit që të shkruajnë këto kontrole, ose pranojeni humbjen, pranoni që asgjë nuk kontrollohet dhe do të bjerë.

Këshilla teknike:

Sigurohuni që të organizoni një server të jashtëm për të kryer kontrollet — duhet të jeni të sigurt që projekti juaj është i aksesueshëm për botën e jashtme.
Organizoni kontrollet për të gjithë protokollin e API-së dhe jo vetëm për endpoint-et e veçanta.
Krijoni një endpoint prometheus me rezultatet e kontrolleve.

Niveli i aplikacionit — monitorimi i metrikave shëndetësore

Tani bëhet fjalë për metrike shëndetësore të jashtme të shërbimeve.

Ne vendosëm që të monitorojmë të gjitha “butonat” e aplikacionit përmes kontrolleve të jashtme që i thërrasim nga një sistem monitorimi të jashtëm. Por këto janë pikërisht “butonat” që i sheh përdoruesi. Ne dëshirojmë të jemi të sigurt që shërbimet tona funksionojnë. Këtu gjërat janë më të mira: në K8s ka kontrolla shëndetësore, që të paktën vetë “kubiku” të sigurohet që shërbimi funksionon. Por gjysma e kontrollave që kam parë janë po ai print “hello world”. Domethënë, ai e thërret një herë pas implementimit, ai iu përgjigj se gjithçka është mirë — dhe ka mbaruar. Ndërsa një shërbim, nëse ai jep API-në e tij me rest, ka një numër të madh pikash hyrjeje të atij API, që gjithashtu duhet të monitorohet, sepse dëshirojmë të dimë që ai funksionon. Dhe ne e monitorojmë atë brenda.

Si ta implementoni këtë teknikisht: çdo shërbim ekspozon një endpoint në lidhje me funksionimin e tij aktual, dhe në grafikët e Grafana (apo ndonjë aplikacion tjetër) ne shohim statusin e të gjithë shërbimeve.

Çdo ndryshim në API duhet të tërheqë një ndryshim në kontrollet.
Krijoni shërbime të reja menjëherë me metrikat shëndetësore.
Administratori mund të shkojë te zhvilluesit dhe të kërkojë "shtoni disa funksionalitete, që ta kuptoj dhe ta shtoj informacionin në sistemin tim të monitorimit." Por zhvilluesit zakonisht përgjigjen "Ne nuk do të shtojmë asgjë dy javë para lansimit."
Lëreni menaxherët e zhvillimit të dinë që do të ketë humbje të tilla, lëreni edhe menaxhmentin e menaxherëve të zhvillimit të dijë. Sepse, kur gjithçka të bjerë, dikush do të telefonojë dhe do të kërkojë të monitorojë "shërbimin që vazhdon të bjerë" (c)
Tani, caktoni zhvilluesit për të shkruar plugina për Grafana — kjo do të jetë një ndihmë e mirë për administratorët.

Niveli i aplikacionit — Monitorimi i integrimit

Monitorimi i integrimit përqendrohet në monitorimin e komunikimit midis sistemeve kritik për biznesin.

Për shembull, ka 15 shërbime që komunikojnë midis tyre. Këto nuk janë më faqe të veçanta. Domethënë, ne nuk mund të thërrasim shërbimin vetë, të marrim /helloworld dhe të kuptojmë se shërbimi funksionon. Sepse shërbimi i çdo porosie duhet të dërgojë informacionin për porosinë në një autobus — nga autobusi shërbimi i magazinës duhet të marrë këtë mesazh dhe të punojë me të më tej. Dhe shërbimi i dërgimit të email-eve duhet ta përpunojë këtë ndonjë mënyrë tjetër, etj.

Prandaj, ne nuk mund të kuptojmë, duke u goditur në çdo shërbim të veçantë, se gjithçka funksionon. Sepse ne kemi një autobus, përmes të cilit të gjitha komunikojnë dhe bashkëveprojnë.
Kështu, ky hap duhet të shënojë fazën e testimit të shërbimeve për ndërveprimin me shërbime të tjerë. Nuk mund të monitorojmë komunikimin vetëm nga monitorimi i brokerit të mesazheve. Nëse ka një shërbim që jep të dhëna, dhe një shërbim që i merr ato, gjatë monitorimit të brokerit do të shohim vetëm të dhënat që fluturojnë nga njëra anë në tjetrën. Nëse ndonjëherë arritëm të monitorojmë ndërveprimin e këtyre të dhënave brenda — që një prodhues poston të dhëna, dikush i lexon ato, ky rrjedhë vazhdon në Kafka — kjo gjithsesi nuk do të na japë informacion nëse një shërbim dërgoi një mesazh në një version, ndërsa shërbimi tjetër nuk e priste atë version dhe e kaloi atë. Ne nuk do ta mësojmë këtë, pasi shërbimet do të na thonë se gjithçka funksionon.

Kështu rekomandoj ta bëni:

Për komunikim sinkron: endpoint-i bën kërkesa ndaj shërbimeve të lidhura. Pra, ne marrim këtë endpoint dhe aktivizojmë një skript brenda shërbimit, i cili kalon nëpër të gjitha pikat dhe thotë ‘mund të veproj këtu, dhe këtu gjithashtu, mund të veproj aty...’
Për komunikim asinkron: mesazhet e ardhshme — endpoint-i kontrollon autobusin për mesazhe provuese dhe jep statusin e përpunimit.
Për komunikim asinkron: mesazhet e dalshme — endpoint-i dërgon mesazhe provuese në autobus.

Si zakonisht ndodh: ne kemi një shërbim që dërgon të dhëna në autobus. Ne shkojmë në këtë shërbim dhe kërkojmë që të flasë rreth shëndetit të tij integrues. Dhe nëse shërbimi duhet të dërgojë ndonjë mesazh diku tjetër (WebApp), atëherë ai e prodhon atë mesazh provues. Nëse ne tërheqim shërbimin nga ana e OrderProcessing, ai fillimisht poston atë që mund të postojë të pavarur, dhe nëse ka ndonjë gjë të varur — ai lexon nga autobusi një grup mesazhesh provuese, kupton se çfarë mund të përpunojë, e njofton këtë dhe, nëse është e nevojshme, poston ato më tej, dhe për këtë thotë — gjithçka është ok, jam në jetë.

Shumë shpesh ne dëgjojmë pyetjen “si mund ta testojmë këtë me të dhënat reale?” Për shembull, është fjala për shërbimin e porosive. Porosia dërgon mesazhe në magazinë, ku produktet hiqen: ne nuk mund ta testojmë këtë me të dhëna reale, sepse ‘prodhat do të hiqen!’ Çelja: në fazën fillestare planifikoni të gjithë këtë test. Ju keni teste unitare, të cilat bëjnë mock-e. Pra, bëni këtë në një nivel më të thellë, ku do të kalojë kanali i komunikimit, i cili nuk do të dëmtojë funksionimin e biznesit.

Niveli i infrastruktures

Monitorimi i infrastrukturës është diçka që prej kohësh konsiderohet si vetë monitorim.

Monitorimi i infrastrukturës mund dhe duhet të nisë si një proces i veçantë.
Nuk duhet të filloni me monitorimin e infrastrukturës në një projekt në funksionim, edhe nëse dëshira është e madhe. Kjo është një problematikë për të gjithë devops-at. ‘Fillimisht do të monitoroj klasterin, do t’i monitoroj infrastrukturën’ – pra, fillimisht do të monitoroj atë që është në fund, dhe nuk do të merret me aplikacionin. Sepse aplikacioni është një gjë e paqartë për devops-in. Atij iu dha dhe ai nuk kupton se si funksionon. Por infrastruktura e kupton dhe fillon me të. Por jo — gjithmonë duhet të monitoroni aplikacionin në fillim.
Mos e teproni me numrin e njoftimeve. Duke pasur parasysh kompleksitetin e sistemeve moderne, alertrat arrijnë vazhdimisht, dhe kësaj grumbull të alertrave duhet t’i bëni ballë ndryshe. Dhe personi on-call, duke parë njëqind alertra të tjera, do të vendosë ‘nuk dua të mendoj për këtë’. Alertrat duhet të paralajmërojnë vetëm për gjëra kritike.

Niveli i aplikacionit si një njësi biznesi

Pikat kyçe:

ELK. Ky është standardi industrial. Nëse për shkak të ndonjë arsyeje nuk po agregoni loge, filloni menjëherë të bëni këtë.
APM. APM-të e jashtme si një mënyrë për të mbyllur shpejt monitorimin e aplikacionit (NewRelic, BlackFire, Datadog). Mund të vendosni përkohësisht këtë gjë, për të kuptuar se çfarë ndodh.
Tracing. Në dhjetëra mikroshërbime duhet të bëni tracing gjithçka, sepse kërkesa nuk jeton më vetvetiu. Të shkruani më vonë është shumë e komplikuar, prandaj është më mirë të planifikoni tracing-in gjatë zhvillimit — kjo është punë dhe një utilitar për zhvilluesit. Nëse nuk e keni implementuar akoma – implementoni! Shihni Jaeger/Zipkin

Alerte

Organizimi i sistemit të njoftimeve: në kushtet e monitorimit të shumë gjërave, duhet të ketë një sistem të vetëm për shpërndarjen e njoftimeve. Mund të jetë në Grafana. Në Perëndim, të gjithë përdorin PagerDuty. Njoftimet duhet të jenë të kuptueshme (për shembull, nga e kuptuan…). Dhe është e dëshirueshme të kontrolloni që njoftimet të arrijnë fare.
Organizimi i sistemit të kujdestarive: alertrat nuk duhet t’i vijnë të gjithëve (ose do të reagojnë të gjithë njëkohësisht, ose askush nuk do të reagojë). Personat on-call duhet të jenë edhe zhvillues: duhet patjetër të përcaktoni zonat e përgjegjësisë, të bëni një udhëzim të qartë dhe ta përcaktoni se kujt konkretisht t’i telefononi të hënën dhe të mërkurën, dhe kujt — të martën dhe të premten (ndryshe nuk do t’i telefonojnë askujt madje në rast të një fatkeqësie të madhe — do të kenë frikë të zgjojnë, të shqetësojnë: njerëzit në përgjithësi nuk e duan që t’i telefonosh dhe t’i zgjojsh të tjerët, veçanërisht natën). Dhe shpjegoni se kërkimi për ndihmë nuk është tregues i paaftësisë (‘po kërkoj ndihmë — dmth jam punonjës i keq’), inkurajoni kërkesat për ndihmë.
Organizimi i ‘bazës së njohurive’ dhe rrjedhës së përpunimit të incidenteve: për çdo incident serioz duhet planifikuar një postmortem, si një masë përkohësore duhet regjistruar veprimet që do të zgjidhnin incidentin. Dhe vendosni praktikën që alertrat e përsëritura janë mëkat; ato duhet të rregullohen në kodin ose në punët infrastrukturor.

Stoku teknologjik

Le të imagjinojmë se staku ynë është si më poshtë:

mbledhja e të dhënave — Prometheus + Grafana;
analiza e logeve — ELK;
për APM ose Tracing — Jaeger (Zipkin).

Zgjedhja e opsioneve nuk është kritike. Sepse, nëse në fillim keni kuptuar si ta monitoroni sistemin dhe keni përgatitur një plan, atëherë filloni të zgjidhni mjetet sipas kërkesave tuaja. Pyetja është se çfarë vendosni të monitoroni fillimisht. Sepse ndoshta, mjeti që keni zgjedhur në fillim — nuk i përshtatet aspak kërkesave tuaja.

Disa çështje teknike që i shoh në çdo vend së fundmi:

Prometheus po futet brenda Kubernetes — kush e shpiku këtë?! Nëse klasteri juaj bie, çfarë do bëni? Nëse keni një klaster të komplikuar brenda, duhet të ketë një sistem monitorimi brenda klasterit, dhe një — jashtë, i cili do të mbledhë të dhëna nga brenda klasterit.

Brenda klasterit ne mbledhim loge dhe gjithçka tjetër. Por sistemi i monitorimit duhet të jetë jashtë. Shumë shpesh në klasterat, ku ka Prometheus të instaluar brenda, ka gjithashtu sisteme që bëjnë kontrolle të jashtme të funksionimit të faqes. Po çfarë ndodh nëse lidhjet me botën jasht kanë rënë dhe aplikacioni nuk funksionon? Pra, brenda gjithçka është mirë, por për përdoruesit nuk është më e lehtë.

Përfundimet

Zhvillimi i monitorimit — nuk është instalimi i utilitareve, por zhvillimi i një produkti programor. 98% e monitorimit sot — është kodim. Kodim në shërbime, kodim kontrollesh të jashtme, kontrolli i shërbimeve të jashtme, dhe gjithçka tjetër.
Mos e kurseni kohën e zhvilluesve për monitorimin: kjo mund të marrë deri në 30% të punës së tyre, por ia vlen.
DevOps, mos u shqetësoni nëse nuk arrini të monitoroni diçka, sepse disa gjëra — janë një mendësi krejt tjetër. Ju nuk keni qenë programues, dhe puna e monitorimit — është pikërisht puna e tyre.
Nëse projekti tashmë funksionon dhe nuk është monitoruar (dhe ju jeni menaxher) — sigurohuni që të keni burime për monitorimin.
Nëse produkti është tashmë në prodhim dhe ju jeni devops-i që iu tha ‘të konfiguroni monitorimin’ — përpiquni të shpjegoni drejtuesve atë që kam shkruar të gjithë këtë.

Kjo është një version i zgjeruar i një referati në konferencën Saint Highload++.

Nëse jeni të interesuar për idetë dhe reflektimet e mia në temat IT dhe përafër tyre, atëherë mund të lexoni kanalin 🙂

Burimi: habr.com