A ka vdekur monitorimi? — Rroftë monitorimi

Që nga viti 2008, kompania jonë ka qenë e angazhuar kryesisht në menaxhimin e infrastrukturës dhe mbështetje teknike gjatë gjithë orarit për projektet në internet: ne kemi më shumë se 400 klientë, që është rreth 15% e tregtisë elektronike ruse. Prandaj, mbështetet një arkitekturë shumë e larmishme. Nëse diçka bie, jemi të detyruar ta rregullojmë brenda 15 minutash. Por për të kuptuar se ka ndodhur një aksident, duhet të monitoroni projektin dhe t'i përgjigjeni incidenteve. Si ta bëni këtë?

Besoj se ka një problem në organizimin e një sistemi të mirëfilltë monitorimi. Nëse nuk do të kishte pasur probleme, atëherë fjalimi im do të përbëhej nga një tezë: "Ju lutemi instaloni Prometheus + Grafana dhe shtojcat 1, 2, 3." Fatkeqësisht, nuk funksionon më në këtë mënyrë. Dhe problemi kryesor është se të gjithë vazhdojnë të besojnë në diçka që ekzistonte në vitin 2008, sa i përket komponentëve të softuerit.

Sa i përket organizimit të sistemit të monitorimit, do të guxoja të them se... projekte me monitorim kompetent nuk ekzistojnë. Dhe situata është aq e keqe sa nëse diçka bie, ekziston rreziku që ajo të kalojë pa u vënë re - në fund të fundit, të gjithë janë të sigurt se "gjithçka monitorohet".
Ndoshta gjithçka po monitorohet. Por si?

Të gjithë kemi hasur në një histori si më poshtë: një zhvillues i caktuar, një administrator i caktuar po punon, një ekip zhvillimi vjen tek ata dhe thotë - "Ne jemi liruar, tani monitorojmë". Monitoroni çfarë? Si punon?

NE RREGULL. Ne monitorojmë mënyrën e vjetër. Dhe tashmë po ndryshon, dhe rezulton se keni monitoruar shërbimin A, i cili u bë shërbimi B, i cili ndërvepron me shërbimin C. Por ekipi i zhvillimit ju thotë: "Instaloni softuerin, ai duhet të monitorojë gjithçka!"

Pra, çfarë ka ndryshuar? - Gjithcka ka ndryshuar!

2008 Cdo gje eshte ne rregull

Ka disa zhvillues, një server, një server të bazës së të dhënave. Gjithçka shkon nga këtu. Kemi disa informacione, instalojmë zabbix, Nagios, kaktus. Dhe më pas vendosim sinjalizime të qarta në CPU, në funksionimin e diskut dhe në hapësirën e diskut. Ne gjithashtu bëjmë disa kontrolle manuale për të siguruar që faqja përgjigjet dhe se porositë po mbërrijnë në bazën e të dhënave. Dhe kjo është ajo - ne jemi pak a shumë të mbrojtur.

Nëse krahasojmë sasinë e punës që administratori bëri atëherë për të ofruar monitorim, atëherë 98% e saj ishte automatike: personi që bën monitorimin duhet të kuptojë se si të instalojë Zabbix, si ta konfigurojë atë dhe të konfigurojë sinjalizimet. Dhe 2% - për kontrolle të jashtme: që faqja të përgjigjet dhe të bëjë një kërkesë në bazën e të dhënave, që porositë e reja kanë ardhur.

2010 Ngarkesa po rritet

Ne po fillojmë të zgjerojmë ueb-in, duke shtuar një motor kërkimi. Ne duam të sigurohemi që katalogu i produkteve të përmbajë të gjitha produktet. Dhe kërkimi i produktit funksionon. Që baza e të dhënave po funksionon, se po bëhen porosi, që faqja përgjigjet nga jashtë dhe përgjigjet nga dy serverë dhe përdoruesi nuk dëbohet nga faqja ndërsa ribalancohet në një server tjetër, etj. Ka më shumë subjekte.

Për më tepër, subjekti i lidhur me infrastrukturën mbetet ende më i madhi në kokën e menaxherit. Ende kam një ide në kokën time që personi që bën monitorimin është personi që do të instalojë zabbix dhe do të jetë në gjendje ta konfigurojë atë.

Por në të njëjtën kohë, shfaqet puna për kryerjen e kontrolleve të jashtme, për krijimin e një grupi skriptesh pyetjesh të indeksuesit të kërkimit, një grup skriptesh për të kontrolluar nëse kërkimi ndryshon gjatë procesit të indeksimit, një grup skriptesh që kontrollojnë që mallrat janë transferuar në shërbimi i dërgesës etj. e kështu me radhë.

Shënim: Kam shkruar "një grup skenarësh" 3 herë. Domethënë, personi përgjegjës për monitorimin nuk është më ai që thjesht instalon zabbix. Ky është një person që fillon të kodojë. Por asgjë nuk ka ndryshuar ende në mendjet e ekipit.

Por bota po ndryshon, po bëhet gjithnjë e më komplekse. Shtohet një shtresë virtualizimi dhe disa sisteme të reja. Ata fillojnë të ndërveprojnë me njëri-tjetrin. Kush tha se "ka erë si mikroshërbime?" Por çdo shërbim ende duket si një faqe interneti individualisht. Ne mund t'i drejtohemi asaj dhe të kuptojmë se ai siguron informacionin e nevojshëm dhe funksionon vetë. Dhe nëse jeni një administrator i përfshirë vazhdimisht në një projekt që po zhvillohet për 5-7-10 vjet, kjo njohuri grumbullohet: shfaqet një nivel i ri - e kuptove, shfaqet një nivel tjetër - e kuptove ...

Por rrallëherë dikush shoqëron një projekt për 10 vjet.

CV e Monitoringman

Supozoni se keni ardhur në një startup të ri që punësoi menjëherë 20 zhvillues, shkroi 15 mikroshërbime dhe ju jeni një administrator që ju thuhet: “Ndërtoni CI/CD. Ju lutem." Keni ndërtuar CI/CD dhe befas dëgjoni: “Është e vështirë për ne të punojmë me prodhimin në një “kub”, pa kuptuar se si do të funksionojë aplikacioni në të. Na bëni një kuti rëre në të njëjtin "kub".
Ju bëni një kuti rëre në këtë kub. Ata ju thonë menjëherë: "Ne duam një bazë të dhënash të skenës që përditësohet çdo ditë nga prodhimi, në mënyrë që të kuptojmë se funksionon në bazën e të dhënave, por në të njëjtën kohë të mos prishë bazën e të dhënave të prodhimit."

Ju jetoni në të gjitha këto. Kanë mbetur edhe 2 javë para daljes, ju thonë: “Tani le të monitorojmë të gjitha këto...” Dmth. monitoroni infrastrukturën e grupimeve, monitoroni arkitekturën e mikroservisit, monitoroni punën me shërbimet e jashtme...

Dhe kolegët e mi nxjerrin nga koka skemën e zakonshme dhe thonë: "Epo, gjithçka është e qartë këtu! Instaloni një program që do të monitorojë të gjitha këto.” Po, po: Prometheus + Grafana + shtojca.
Dhe ata shtojnë: "Ju keni dy javë, sigurohuni që gjithçka të jetë e sigurt."

Në shumë projekte që shohim, një person është caktuar për monitorim. Imagjinoni që ne duam të punësojmë një person për të bërë monitorim për 2 javë dhe ne i shkruajmë një rezyme. Çfarë aftësish duhet të ketë ky person, duke pasur parasysh gjithçka që kemi thënë deri më tani?

• Ai duhet të kuptojë monitorimin dhe specifikat e funksionimit të infrastrukturës së hekurit.
• Ai duhet të kuptojë specifikat e monitorimit të Kubernetes (dhe të gjithë duan të shkojnë në "kub", sepse ju mund të abstraktoni nga gjithçka, të fshiheni, sepse administratori do të merret me pjesën tjetër) - vetë, infrastrukturën e tij dhe të kuptojë se si të monitoroni aplikacionet brenda.
• Ai duhet të kuptojë se shërbimet komunikojnë me njëri-tjetrin në mënyra të veçanta dhe të dijë specifikat se si shërbimet ndërveprojnë me njëra-tjetrën. Është mjaft e mundur të shihet një projekt ku disa shërbime komunikojnë në mënyrë sinkrone, sepse nuk ka rrugë tjetër. Për shembull, backend shkon nëpërmjet REST, nëpërmjet gRPC në shërbimin e katalogut, merr një listë të produkteve dhe e kthen atë. Nuk mund të presësh këtu. Dhe me shërbime të tjera funksionon në mënyrë asinkrone. Transferoni porosinë në shërbimin e dërgesës, dërgoni një letër, etj.
  Ju ndoshta keni notuar tashmë nga e gjithë kjo? Dhe administratori, i cili duhet ta monitorojë këtë, u hutua edhe më shumë.
• Ai duhet të jetë në gjendje të planifikojë dhe planifikojë saktë - ndërsa puna bëhet gjithnjë e më shumë.
• Prandaj ai duhet të krijojë një strategji nga shërbimi i krijuar në mënyrë që të kuptojë se si ta monitorojë atë në mënyrë specifike. Ai ka nevojë për një kuptim të arkitekturës së projektit dhe zhvillimit të tij + një kuptim të teknologjive të përdorura në zhvillim.

Le të kujtojmë një rast absolutisht normal: disa shërbime janë në PHP, disa shërbime janë në Go, disa shërbime janë në JS. Ata disi punojnë me njëri-tjetrin. Nga këtu vjen termi "mikroshërbim": ka kaq shumë sisteme individuale që zhvilluesit nuk mund ta kuptojnë projektin në tërësi. Një pjesë e ekipit shkruan shërbime në JS që funksionojnë vetë dhe nuk e dinë se si funksionon pjesa tjetër e sistemit. Pjesa tjetër shkruan shërbimet në Python dhe nuk ndërhyn në mënyrën se si funksionojnë shërbimet e tjera; ato janë të izoluara në zonën e tyre. E treta është shkrimi i shërbimeve 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 që duhet t'i kuptojë të gjitha këto. Ndalo! ne thjesht e ndajmë sistemin në 15 mikroshërbime sepse 20 persona nuk mund ta kuptojnë të gjithë sistemin.

Por duhet monitoruar disi...

Cili është rezultati? Si rezultat, ekziston një person që del me gjithçka që i gjithë ekipi i zhvilluesve nuk mund ta kuptojë, dhe në të njëjtën kohë ai gjithashtu duhet të dijë dhe të jetë në gjendje të bëjë atë që treguam më lart - infrastrukturën e harduerit, infrastrukturën Kubernetes, etj.

Çfarë mund të them... Houston, ne kemi probleme.

Monitorimi i një projekti softuerik modern është një projekt softuer në vetvete

Nga besimi i rremë se monitorimi është softuer, ne zhvillojmë një besim te mrekullitë. Por mrekullitë, mjerisht, nuk ndodhin. Ju nuk mund të instaloni zabbix dhe të prisni që gjithçka të funksionojë. Nuk ka kuptim të instaloni Grafana dhe të shpresoni se gjithçka do të jetë në rregull. Pjesa më e madhe e kohës do të shpenzohet për organizimin e kontrolleve të funksionimit të shërbimeve dhe ndërveprimin e tyre me njëri-tjetrin, duke kontrolluar se si funksionojnë sistemet e jashtme. Në fakt, 90% e kohës nuk do të shpenzohet në shkrimin e skripteve, por në zhvillimin e softuerit. Dhe duhet të trajtohet nga një ekip që e kupton punën e projektit.
Nëse në këtë situatë një person hidhet në monitorim, atëherë do të ndodhë fatkeqësi. Kjo është ajo që ndodh kudo.

Për shembull, ka disa shërbime që komunikojnë me njëri-tjetrin nëpërmjet Kafkës. Erdhi porosia, i dërguam mesazh për porosinë Kafkës. Ekziston një shërbim që dëgjon informacionin rreth porosisë dhe dërgon mallrat. Ekziston një shërbim që dëgjon informacionin rreth porosisë dhe i dërgon një letër përdoruesit. Dhe pastaj shfaqen një mori shërbimesh të tjera dhe ne fillojmë të ngatërrohemi.

Dhe nëse ia jepni këtë edhe administratorit dhe zhvilluesve në fazën kur ka mbetur pak kohë para lëshimit, personi do të duhet të kuptojë të gjithë këtë protokoll. Ato. Një projekt i kësaj shkalle kërkon një kohë të konsiderueshme, dhe kjo duhet të përfshihet në zhvillimin e sistemit.
Por shumë shpesh, sidomos në startup-et, shohim sesi monitorimi shtyhet për më vonë. “Tani do të bëjmë një provë koncepti, do të nisim me të, le të bjerë - jemi gati të sakrifikojmë. Dhe pastaj ne do t'i monitorojmë të gjitha." Kur (ose nëse) projekti fillon të fitojë para, biznesi dëshiron të shtojë edhe më shumë veçori - sepse ka filluar të funksionojë, kështu që duhet të shtrihet më tej! Dhe ju jeni në pikën ku së pari duhet të monitoroni gjithçka të mëparshme, gjë që nuk merr 1% të kohës, por shumë më tepër. Dhe nga rruga, zhvilluesit do të nevojiten për monitorim dhe është më e lehtë t'i lini ata të punojnë në veçori të reja. Si rezultat, shkruhen veçori të reja, gjithçka prishet dhe ju jeni në një bllokim të pafund.

Pra, si të monitoroni një projekt duke filluar nga fillimi, dhe çfarë të bëni nëse merrni një projekt që duhet të monitorohet, por nuk dini ku të filloni?

Së pari, ju duhet të planifikoni.

Digresioni lirik: shumë shpesh fillojnë me monitorimin e infrastrukturës. Për shembull, ne kemi Kubernetes. Le të fillojmë duke instaluar Prometheus me Grafana, duke instaluar shtojca për monitorimin e "kubit". Jo vetëm zhvilluesit, por edhe administratorët kanë praktikën fatkeqe të: "Ne do ta instalojmë këtë shtojcë, por shtojca ndoshta e di se si ta bëjë atë." Njerëzve u pëlqen të fillojnë me veprimet e thjeshta dhe të drejtpërdrejta, sesa me veprimet e rëndësishme. Dhe monitorimi i infrastrukturës është i lehtë.

Së pari, vendosni se çfarë dhe si dëshironi të monitoroni, dhe më pas zgjidhni një mjet, sepse njerëzit e tjerë nuk mund të mendojnë për ju. Dhe a duhet ata? Njerëz të tjerë menduan me vete, për një sistem universal - ose nuk menduan fare kur u shkrua kjo shtojcë. Dhe vetëm për shkak se ky plugin ka 5 mijë përdorues nuk do të thotë se është i dobishëm. Ndoshta do të bëhesh i 5001-ti thjesht sepse aty më parë kishte 5000 njerëz.

Nëse filloni të monitoroni infrastrukturën dhe pjesa e pasme e aplikacionit tuaj nuk përgjigjet, të gjithë përdoruesit do të humbasin lidhjen me aplikacionin celular. Do të shfaqet një gabim. Ata do të vijnë tek ju dhe do të thonë "Aplikacioni nuk po funksionon, çfarë po bëni këtu?" - "Ne jemi duke monitoruar." — “Si monitoroni nëse nuk shihni që aplikacioni nuk funksionon?!”

1. Unë besoj se duhet të filloni monitorimin pikërisht nga pika e hyrjes së përdoruesit. Nëse përdoruesi nuk sheh që aplikacioni po funksionon, kjo është ajo, është një dështim. Dhe për këtë fillimisht duhet të paralajmërojë sistemi i monitorimit.
2. Dhe vetëm atëherë mund të monitorojmë infrastrukturën. Ose bëjeni paralelisht. Është më e lehtë me infrastrukturën - këtu më në fund thjesht mund të instalojmë zabbix.
3. Dhe tani ju duhet të shkoni te rrënjët e aplikacionit për të kuptuar se ku gjërat nuk funksionojnë.

Ideja ime kryesore është që monitorimi të shkojë paralelisht me procesin e zhvillimit. Nëse e shpërqendroni ekipin e monitorimit për detyra të tjera (krijimi i CI/CD, vendosja e sandboxit, riorganizimi i infrastrukturës), monitorimi do të fillojë të vonojë dhe mund të mos e arrini kurrë hapin e zhvillimit (ose herët a vonë do t'ju duhet ta ndaloni atë).

Gjithçka sipas niveleve

Kështu e shoh unë organizimin e një sistemi monitorimi.

1) Niveli i aplikimit:

• monitorimi i logjikës së biznesit të aplikacionit;
• monitorimi i matjeve shëndetësore të shërbimeve;
• monitorimi i integrimit.

2) Niveli i infrastrukturës:

• monitorimi i nivelit të orkestrimit;
• monitorimi i softuerit të sistemit;
• monitorimi i nivelit të hekurit.

3) Përsëri niveli i aplikimit - por si produkt inxhinierik:

• mbledhjen dhe monitorimin e regjistrave të aplikacioneve;
• APM;
• gjurmimi.

4) Paralajmërim:

• organizimi i një sistemi paralajmërimi;
• organizimi i një sistemi detyre;
• organizimi i një "baze të njohurive" dhe rrjedhës së punës për përpunimin e incidenteve.

Është e rëndësishme: arrijmë në alarm jo më pas, por menjëherë! Nuk ka nevojë të filloni monitorimin dhe "disi më vonë" të kuptoni se kush do të marrë alarme. Në fund të fundit, cila është detyra e monitorimit: të kuptosh se ku në sistem diçka nuk funksionon dhe të njoftosh njerëzit e duhur për këtë. Nëse e lini këtë deri në fund, atëherë njerëzit e duhur do ta dinë se diçka po shkon keq vetëm duke thirrur "asgjë nuk po funksionon për ne".

Shtresa e Aplikimit - Monitorimi i Logjikës së Biznesit

Këtu po flasim për të kontrolluar vetë faktin që aplikacioni funksionon për përdoruesin.

Ky nivel duhet të bëhet gjatë fazës së zhvillimit. Për shembull, ne kemi një Prometheus të kushtëzuar: ai shkon te serveri që bën kontrollet, tërheq pikën përfundimtare dhe pika e fundit shkon dhe kontrollon API-në.

Kur u kërkohet shpesh të monitorojnë faqen kryesore për t'u siguruar që faqja po funksionon, programuesit japin një dorezë që mund të tërhiqet sa herë që u nevojitet për t'u siguruar që API po funksionon. Dhe programuesit në këtë moment ende marrin dhe shkruajnë /api/test/helloworld
Mënyra e vetme për t'u siguruar që gjithçka funksionon? - Jo!

• Krijimi i kontrolleve të tilla është në thelb detyrë e zhvilluesve. Testet e njësisë duhet të shkruhen nga programuesit që shkruajnë kodin. Sepse nëse ia tregon administratorit, "Duke, këtu është një listë e protokolleve API për të gjitha 25 funksionet, ju lutemi monitoroni gjithçka!" - asgjë nuk do të funksionojë.
• Nëse printoni "hello world", askush nuk do ta dijë kurrë se API duhet dhe funksionon. Çdo ndryshim API duhet të çojë në një ndryshim në kontrolle.
• Nëse tashmë keni një problem të tillë, ndaloni veçoritë dhe caktoni zhvilluesit që do t'i shkruajnë këto kontrolle, ose pranoni humbjet, pranoni që asgjë nuk është kontrolluar dhe nuk do të dështojë.

Këshilla teknike:

• Sigurohuni që të organizoni një server të jashtëm për të organizuar kontrolle - duhet të jeni të sigurt që projekti juaj është i aksesueshëm për botën e jashtme.
• Organizoni kontrolle në të gjithë protokollin API, jo vetëm në pikat përfundimtare individuale.
• Krijo një pikë fundore prometheus me rezultatet e testit.

Shtresa e aplikimit - monitorimi i metrikës së shëndetit

Tani po flasim për matjet e jashtme shëndetësore të shërbimeve.

Ne vendosëm që të monitorojmë të gjitha "dorezat" e aplikacionit duke përdorur kontrolle të jashtme, të cilat i quajmë nga një sistem monitorimi i jashtëm. Por këto janë "dorezat" që përdoruesi "sheh". Ne duam të jemi të sigurt që vetë shërbimet tona funksionojnë. Këtu historia është më e mirë: K8s ka kontrolle shëndetësore, në mënyrë që të paktën vetë "kubi" të bindet se shërbimi po funksionon. Por gjysma e çeqeve që kam parë janë të njëjtat printime "hello world". Ato. Kështu që ai tërhiqet një herë pas vendosjes, ai u përgjigj se gjithçka është në rregull - kjo është e gjitha. Dhe shërbimi, nëse ofron API-në e vet, ka një numër të madh pikash hyrëse për të njëjtin API, i cili gjithashtu duhet të monitorohet, sepse duam të dimë se funksionon. Dhe ne tashmë po e monitorojmë brenda.

Si ta zbatoni këtë saktë teknikisht: çdo shërbim ekspozon një pikë përfundimtare në lidhje me performancën e tij aktuale, dhe në grafikët e Grafana (ose çdo aplikacioni tjetër) shohim statusin e të gjitha shërbimeve.

• Çdo ndryshim API duhet të çojë në një ndryshim në kontrolle.
• Krijo një shërbim të ri menjëherë me metrikat shëndetësore.
• Një administrator mund të vijë te zhvilluesit dhe të kërkojë "më shtoni disa veçori në mënyrë që të kuptoj gjithçka dhe të shtoj informacion në lidhje me këtë në sistemin tim të monitorimit". Por zhvilluesit zakonisht përgjigjen: "Ne nuk do të shtojmë asgjë dy javë para publikimit."
  Le ta dinë menaxherët e zhvillimit se do të ketë humbje të tilla, le ta dinë edhe menaxhmenti i menaxherëve të zhvillimit. Sepse kur gjithçka bie, dikush do të telefonojë dhe do të kërkojë të monitorojë "shërbimin vazhdimisht në rënie" (c)
• Nga rruga, caktoni zhvilluesit për të shkruar shtojca për Grafana - kjo do të jetë një ndihmë e mirë për administratorët.

Shtresa e Aplikimit - Monitorimi i Integrimit

Monitorimi i integrimit fokusohet në monitorimin e komunikimeve ndërmjet sistemeve kritike për biznesin.

Për shembull, janë 15 shërbime që komunikojnë me njëri-tjetrin. Këto nuk janë më sajte të veçanta. Ato. ne nuk mund ta tërheqim vetë shërbimin, të marrim /helloworld dhe të kuptojmë që shërbimi po funksionon. Për shkak se shërbimi i uebit i porositjes duhet të dërgojë informacion në lidhje me porosinë në autobus - nga autobusi, shërbimi i magazinës duhet ta marrë këtë mesazh dhe të punojë me të më tej. Dhe shërbimi i shpërndarjes së postës elektronike duhet ta përpunojë këtë disi më tej, etj.

Rrjedhimisht, ne nuk mund të kuptojmë, duke i prekur çdo shërbim individual, se gjithçka funksionon. Sepse ne kemi një autobus të caktuar përmes të cilit gjithçka komunikon dhe ndërvepron.
Prandaj, kjo fazë duhet të shënojë fazën e testimit të shërbimeve për ndërveprim me shërbimet e tjera. Është e pamundur të organizohet monitorimi i komunikimit duke monitoruar ndërmjetësin e mesazheve. Nëse ka një shërbim që lëshon të dhëna dhe një shërbim që i merr ato, gjatë monitorimit të ndërmjetësit do të shohim vetëm të dhëna që fluturojnë nga njëra anë në tjetrën. Edhe nëse kemi arritur disi të monitorojmë ndërveprimin e këtyre të dhënave nga brenda - që një prodhues i caktuar poston të dhënat, dikush i lexon, kjo rrjedhë vazhdon të shkojë te Kafka - kjo përsëri nuk do të na japë informacion nëse një shërbim dërgoi mesazhin në një version. , por shërbimi tjetër nuk e priste këtë version dhe e anashkaloi atë. Ne nuk do të dimë për këtë, pasi shërbimet do të na tregojnë se gjithçka po funksionon.

Çfarë rekomandoj të bëni:

• Për komunikim sinkron: pika përfundimtare bën kërkesa për shërbimet e lidhura. Ato. marrim këtë pikë përfundimtare, tërheqim një skript brenda shërbimit, i cili shkon në të gjitha pikat dhe thotë "Unë mund të tërheq atje, dhe tërhiqe atje, mund të tërhiq atje..."
• Për komunikim asinkron: mesazhet hyrëse - pika e fundit kontrollon autobusin për mesazhe testuese dhe shfaq statusin e përpunimit.
• Për komunikim asinkron: mesazhet dalëse - pika përfundimtare dërgon mesazhe testimi në autobus.

Siç ndodh zakonisht: ne kemi një shërbim që hedh të dhëna në autobus. Ne vijmë te ky shërbim dhe ju kërkojmë të na tregoni për shëndetin e integrimit të tij. Dhe nëse shërbimi duhet të prodhojë një mesazh diku më tej (WebApp), atëherë ai do të prodhojë këtë mesazh testimi. Dhe nëse ekzekutojmë një shërbim në anën e Përpunimit të Porosisë, ai së pari poston atë që mund të postojë i pavarur, dhe nëse ka disa gjëra të varura, atëherë lexon një grup mesazhesh testimi nga autobusi, kupton se mund t'i përpunojë, raportojë dhe , nëse është e nevojshme, postojini më tej, dhe për këtë ai thotë - gjithçka është në rregull, unë jam gjallë.

Shumë shpesh dëgjojmë pyetjen "si mund ta testojmë këtë në të dhënat luftarake?" Për shembull, ne po flasim për të njëjtin shërbim porositjeje. Urdhri dërgon mesazhe në magazinë ku janë shlyer mallrat: ne nuk mund ta testojmë këtë në të dhënat luftarake, sepse "mallrat e mia do të fshihen!" Zgjidhja: Planifikoni të gjithë këtë test që në fillim. Ju gjithashtu keni teste për njësi që bëjnë tallje. Pra, bëjeni në një nivel më të thellë ku të keni një kanal komunikimi që nuk dëmton funksionimin e biznesit.

Niveli i infrastrukturës

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

• Monitorimi i infrastrukturës mund dhe duhet të nisë si një proces i veçantë.
• Ju nuk duhet të filloni me monitorimin e infrastrukturës në një projekt në zhvillim, edhe nëse vërtet dëshironi. Kjo është një dhimbje për të gjithë devopët. "Së pari do të monitoroj grupin, do të monitoroj infrastrukturën" - d.m.th. Së pari, do të monitorojë atë që qëndron më poshtë, por nuk do të hyjë në aplikacion. Sepse aplikacioni është një gjë e pakuptueshme për devops. Iu zbulua atij dhe ai nuk e kupton se si funksionon. Por ai e kupton infrastrukturën dhe fillon me të. Por jo - gjithmonë duhet të monitoroni aplikacionin së pari.
• Mos e teproni me numrin e sinjalizimeve. Duke marrë parasysh kompleksitetin e sistemeve moderne, sinjalizimet po fluturojnë vazhdimisht, dhe ju duhet të jetoni disi me këtë grup sinjalizimesh. Dhe personi në thirrje, pasi ka parë njëqind nga sinjalizimet e radhës, do të vendosë "Nuk dua të mendoj për këtë". Alarmet duhet të njoftojnë vetëm për gjëra kritike.

Niveli i aplikimit si njësi biznesi

Pikat kryesore:

• ELK. Ky është standardi i industrisë. Nëse për ndonjë arsye nuk po grumbulloni regjistrat, filloni ta bëni këtë menjëherë.
• APM. APM-të e jashtme si një mënyrë për të mbyllur shpejt monitorimin e aplikacioneve (NewRelic, BlackFire, Datadog). Ju mund ta instaloni këtë gjë përkohësisht që të paktën të kuptoni disi se çfarë po ndodh me ju.
• Gjurmimi. Në dhjetëra mikroshërbime, duhet të gjurmosh gjithçka, sepse kërkesa nuk jeton më vetë. Është shumë e vështirë të shtohet më vonë, kështu që është më mirë të planifikoni menjëherë gjurmimin në zhvillim - kjo është puna dhe dobia e zhvilluesve. Nëse nuk e keni zbatuar akoma, zbatojeni! Shih Jaeger/Zipkin

Paralajmëruese

• Organizimi i një sistemi njoftimi: në kushtet e monitorimit të një morie gjërash, duhet të ketë një sistem të unifikuar për dërgimin e njoftimeve. Mundeni në Grafana. Në Perëndim, të gjithë përdorin PagerDuty. Alarmet duhet të jenë të qarta (p.sh. nga kanë ardhur...). Dhe këshillohet të kontrolloni që njoftimet të merren fare
• Organizimi i një sistemi shërbimi: alarmet nuk duhet t'u dërgohen të gjithëve (ose të gjithë do të reagojnë në një turmë, ose askush nuk do të reagojë). Zhvilluesit gjithashtu duhet të jenë në gatishmëri: sigurohuni që të përcaktojnë fushat e përgjegjësisë, të bëjnë udhëzime të qarta dhe të shkruajnë në të kë të telefonojnë saktësisht të hënën dhe të mërkurën dhe kë të telefonojnë të martën dhe të premten (përndryshe ata nuk do të telefonojnë askënd edhe në ngjarje e një problemi të madh - do të kenë frikë t'ju zgjojnë ose t'ju shqetësojnë: njerëzve në përgjithësi nuk u pëlqen të telefonojnë dhe zgjojnë njerëz të tjerë, veçanërisht gjatë natës). Dhe shpjegoni se kërkimi për ndihmë nuk është një tregues i paaftësisë ("Kërkoj ndihmë, kjo do të thotë se jam një punëtor i keq"), inkurajoni kërkesat për ndihmë.
• Organizimi i një “baze njohurish” dhe fluksi i punës për përpunimin e incidentit: për çdo incident serioz, duhet të planifikohet një post-mortem dhe si masë e përkohshme, duhet të regjistrohen veprimet që do të zgjidhin incidentin. Dhe bëjeni praktikë që alarmet e përsëritura janë mëkat; ato duhet të rregullohen në kod ose në punë infrastrukturore.

Rafte teknologjike

Le të imagjinojmë se pirgja jonë është si më poshtë:

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

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

Disa pika teknike që i shoh kudo kohët e fundit:

Prometeu po shtyhet brenda Kubernetes - kush e ka menduar këtë?! Nëse grupi juaj rrëzohet, çfarë do të bëni? Nëse keni një grup kompleks brenda, atëherë duhet të ketë një lloj sistemi monitorimi brenda grupit dhe disa jashtë, i cili do të mbledhë të dhëna nga brenda grupit.

Brenda grupit ne mbledhim trungje dhe gjithçka tjetër. Por sistemi i monitorimit duhet të jetë jashtë. Shumë shpesh, në një grup ku ka Promtheus të instaluar brenda, ka edhe sisteme që kryejnë kontrolle të jashtme të funksionimit të faqes. Po sikur lidhjet tuaja me botën e jashtme të kenë rënë dhe aplikacioni të mos funksionojë? Rezulton se gjithçka është në rregull brenda, por nuk i lehtëson gjërat për përdoruesit.

Gjetjet

• Monitorimi i zhvillimit nuk është instalimi i shërbimeve, por zhvillimi i një produkti softuer. 98% e monitorimit të sotëm është kodim. Kodimi në shërbime, kodimi i kontrolleve të jashtme, kontrollimi i shërbimeve të jashtme dhe kjo është e gjitha.
• Mos e humbni kohën e zhvilluesve tuaj në monitorim: mund të marrë deri në 30% të punës së tyre, por ia vlen.
• Devops, mos u shqetësoni se nuk mund të monitoroni diçka, sepse disa gjëra janë një mënyrë krejtësisht e ndryshme të të menduarit. Ju nuk keni qenë programues dhe monitorimi i punës është pikërisht puna e tyre.
• Nëse projekti tashmë po funksionon dhe nuk monitorohet (dhe ju jeni menaxher), ndani burime për monitorim.
• Nëse produkti është tashmë në prodhim, dhe ju jeni një devops të cilit ju është thënë të "konfiguroni monitorimin" - përpiquni t'i shpjegoni menaxhmentit se për çfarë kam shkruar gjithë këtë.

Ky është një version i zgjeruar i raportit në konferencën Saint Highload++.

Nëse jeni të interesuar për idetë dhe mendimet e mia për të dhe tema të ngjashme, atëherë këtu mundeni lexoni kanalin 🙂

Burimi: www.habr.com