SRE (Site Reliability Engineering) është një qasje për të siguruar disponueshmërinë e projekteve në internet. Konsiderohet si një kornizë për DevOps dhe flet se si të arrihet sukses në aplikimin e praktikave të DevOps. Përkthimi në këtë artikull libra nga Google. Unë e përgatita vetë këtë përkthim dhe u mbështeta në përvojën time për të kuptuar proceset e monitorimit. Në kanalin e telegramit и Unë botova gjithashtu një lidhje me përkthimin e Kapitullit 4 të të njëjtit libër për qëllimet e nivelit të shërbimit.
Përkthim nga cat. Kënaquni duke lexuar!
Ekipet e SRE të Google kanë parimet bazë dhe praktikat më të mira për krijimin e sistemeve të suksesshme të monitorimit dhe njoftimit. Ky kapitull ofron udhëzime se cilat probleme mund të hasë një vizitor i faqes në internet dhe si të zgjidhen problemet që e bëjnë të vështirë shfaqjen e faqeve të internetit.
Përkufizimet
Nuk ka asnjë fjalor të vetëm të përdorur për të diskutuar tema që lidhen me monitorimin. Edhe në Google, termat e mëposhtëm nuk përdoren zakonisht, por ne do të listojmë interpretimet më të zakonshme.
Monitorimi
Mbledhja, përpunimi, grumbullimi dhe shfaqja e të dhënave sasiore në kohë reale për sistemin: numri i kërkesave dhe llojet e kërkesave, numri i gabimeve dhe llojet e gabimeve, koha e përpunimit të kërkesave dhe koha e funksionimit të serverit.
Monitorimi i kutisë së bardhë
Monitorimi i bazuar në metrikat e shfaqura nga komponentët e brendshëm të sistemit, duke përfshirë regjistrat, metrikat e profilizimit të Makinës Virtuale Java ose metrikat e mbajtësit të HTTP që gjenerojnë statistika të brendshme.
Monitorimi i kutisë së zezë
Testimi i sjelljes së aplikacionit nga këndvështrimi i përdoruesit.
Paneli
Një ndërfaqe (zakonisht ueb) që ofron një pasqyrë të treguesve kryesorë shëndetësorë të shërbimeve. Paneli mund të ketë filtra, aftësinë për të zgjedhur treguesit e shfaqur, etj. Ndërfaqja është krijuar për të identifikuar treguesit që janë më të rëndësishëm për përdoruesit. Paneli mund të shfaqë gjithashtu informacione për stafin e mbështetjes teknike: një radhë kërkesash, një listë gabimesh me prioritet të lartë dhe një inxhinier të caktuar për një fushë të caktuar përgjegjësie.
Sinjalizim (njoftim)
Njoftimet që synohen të merren nga një person me email ose mjete të tjera, të cilat mund të shkaktohen nga gabime ose një rritje në radhën e kërkesës. Njoftimet klasifikohen si: bileta, njoftime me email dhe mesazhe me mesazhe të menjëhershme.
Shkaku rrënjësor
Një defekt i softuerit ose gabim njerëzor që, pasi të korrigjohet, nuk duhet të ndodhë më. Problemi mund të ketë disa shkaqe kryesore: automatizimi i pamjaftueshëm i procesit, defekti i softuerit, shtjellimi i pamjaftueshëm i logjikës së aplikimit. Secili prej këtyre faktorëve mund të jetë shkaku kryesor dhe secili prej tyre duhet të eliminohet.
Nyja dhe makina (nyja dhe makina)
Terma të këmbyeshëm për t'iu referuar një shembulli të vetëm të një aplikacioni të ekzekutuar në një server fizik, makinë virtuale ose kontejner. Një makinë mund të presë disa shërbime. Shërbimet mund të jenë:
- të lidhur me njëri-tjetrin: për shembull, një server memorie dhe një server në internet;
- shërbime të palidhura në një pjesë të vetme të harduerit: për shembull, një depo kodi dhe një magjistar për një sistem konfigurimi, si p.sh. ose .
Shtytje
Çdo ndryshim në konfigurimin e softuerit.
Pse nevojitet monitorimi?
Ka disa arsye pse aplikimet duhet të monitorohen:
Analiza e tendencave afatgjata
Sa e madhe është baza e të dhënave dhe sa shpejt po rritet? Si ndryshon numri ditor i përdoruesve?
Krahasimi i performancës
A janë kërkesat më të shpejta në Acme Bucket of Bytes 2.72 krahasuar me Ajax DB 3.14? Sa më mirë ruhen kërkesat pas shfaqjes së një nyje shtesë? A funksionon faqja më ngadalë në krahasim me javën e kaluar?
Sinjalizime (njoftime)
Diçka është prishur dhe dikush duhet ta rregullojë atë. Ose diçka do të prishet së shpejti dhe dikush duhet ta kontrollojë së shpejti.
Krijimi i paneleve
Paneli duhet t'u përgjigjet pyetjeve themelore dhe të përfshijë diçka nga — vonesat (latenca), trafiku (trafiku), gabimet (gabimet) dhe madhësia e ngarkesës (ngopja).
Kryerja e analizave retrospektive (debugging)
Vonesa e përpunimit të kërkesave është rritur, por çfarë ndodhi tjetër në të njëjtën kohë?
Sistemet e monitorimit janë të dobishme si një burim i të dhënave për sistemet e inteligjencës së biznesit dhe për të lehtësuar analizën e incidenteve të sigurisë. Për shkak se ky libër fokusohet në fushat inxhinierike në të cilat SRE-të kanë ekspertizë, ne nuk do të diskutojmë këtu teknikat e monitorimit.
Monitorimi dhe sinjalizimet lejojnë që sistemi t'ju tregojë kur është prishur ose është gati të prishet. Kur një sistem nuk mund të riparojë automatikisht veten, ne duam që një person të analizojë alarmin, të përcaktojë nëse problemi është ende aktiv, ta zgjidhë atë dhe të përcaktojë shkakun rrënjësor. Nëse nuk i kontrolloni komponentët e sistemit, nuk do të merrni kurrë një sinjalizim thjesht sepse "diçka duket pak e çuditshme".
Të ngarkosh një person me njoftime është një përdorim mjaft i shtrenjtë i kohës së një punonjësi. Nëse punonjësi është duke punuar, alarmi ndërpret procesin e punës. Nëse punonjësi është në shtëpi, alarmi ndërpret kohën personale dhe ndoshta gjumin. Kur sinjalizimet ndodhin shumë shpesh, punonjësit i kalojnë ato, i shtyjnë ose i shpërfillin sinjalizimet hyrëse. Herë pas here ata injorojnë alarmin e vërtetë, i cili maskohet nga ngjarjet e zhurmës. Ndërprerjet e shërbimit mund të zgjasin për periudha të gjata kohore pasi ngjarjet e zhurmës parandalojnë që problemi të diagnostikohet dhe korrigjohet shpejt. Sistemet efektive të paralajmërimit kanë një raport të mirë sinjal-zhurmë.
Vendosja e pritshmërive të arsyeshme për sistemin e monitorimit
Vendosja e monitorimit për një aplikacion kompleks është një detyrë komplekse inxhinierike në vetvete. Edhe me një infrastrukturë të konsiderueshme mjetesh grumbullimi, shfaqjeje dhe alarmi, një ekip Google SRE prej 10–12 anëtarësh zakonisht përfshin një ose dy persona, qëllimi kryesor i të cilëve është të ndërtojnë dhe mirëmbajnë sisteme monitorimi. Ky numër është ulur me kalimin e kohës ndërsa ne konsolidojmë dhe centralizojmë infrastrukturën e monitorimit, por çdo ekip i SRE zakonisht ka të paktën një person të dedikuar vetëm për monitorimin. Duhet të themi se ndërsa panelet e sistemit të monitorimit janë mjaft interesante për t'u parë, ekipet e SRE shmangin me kujdes situatat që kërkojnë që dikush të shikojë një ekran për të monitoruar problemet.
Në përgjithësi, Google ka kaluar në sisteme të thjeshta dhe të shpejta monitorimi me mjete optimale të analizës pas faktit. Ne shmangim sistemet "magjike" që përpiqen të parashikojnë pragjet ose të zbulojnë automatikisht shkakun rrënjësor. Sensorët që zbulojnë përmbajtje të paqëllimshme në kërkesat e përdoruesve fundorë janë i vetmi kundërshembull; Për sa kohë që këta sensorë mbeten të thjeshtë, ata mund të zbulojnë shpejt shkaqet e anomalive serioze. Formatet e tjera për përdorimin e të dhënave të monitorimit, si planifikimi i kapacitetit ose parashikimi i trafikut, janë më komplekse. Vëzhgimi për një periudhë shumë të gjatë kohore (muaj ose vite) me një shkallë të ulët kampionimi (orë ose ditë) do të zbulojë një prirje afatgjatë.
Ekipi i Google SRE ka pasur sukses të përzier me hierarkitë komplekse të varësisë. Ne përdorim rrallë rregulla si "nëse zbuloj se baza e të dhënave është e ngadaltë, marr një sinjalizim se baza e të dhënave është e ngadaltë, përndryshe marr një alarm që faqja është e ngadaltë". Rregullat e bazuara në varësi zakonisht i referohen pjesëve të pandryshueshme të sistemit tonë, siç është sistemi për filtrimin e trafikut të përdoruesve në qendrën e të dhënave. Për shembull, "nëse filtrimi i trafikut në qendrën e të dhënave është konfiguruar, mos më lajmëroni për vonesat në përpunimin e kërkesave të përdoruesve" është një rregull i përgjithshëm për sinjalizimet nga qendra e të dhënave. Pak ekipe në Google mbështesin hierarkitë komplekse të varësisë sepse infrastruktura jonë ka një shkallë konstante rifaktorimi të vazhdueshëm.
Disa nga idetë e përshkruara në këtë kapitull janë ende relevante: ka gjithmonë një mundësi për të kaluar më shpejt nga simptoma në shkakun rrënjësor, veçanërisht në sistemet që ndryshojnë vazhdimisht. Prandaj, ndërsa ky kapitull përshkruan disa qëllime për sistemet e monitorimit dhe mënyrën e arritjes së këtyre qëllimeve, është e rëndësishme që sistemet e monitorimit të jenë të thjeshta dhe të kuptueshme për të gjithë në ekip.
Po kështu, për të mbajtur nivelet e zhurmës të ulëta dhe nivelet e sinjalit të larta, qasjet për monitorimin e aktiveve të sinjalizuara duhet të jenë shumë të thjeshta dhe të besueshme. Rregullat që gjenerojnë paralajmërime për njerëzit duhet të jenë të lehta për t'u kuptuar dhe të paraqesin një problem të qartë.
Simptomat kundrejt shkaqeve
Sistemi juaj i monitorimit duhet t'i përgjigjet dy pyetjeve: "çfarë u prish" dhe "pse u prish".
"Çfarë u prish" flet për simptomat, dhe "pse u prish" flet për shkakun. Tabela më poshtë tregon shembuj të lidhjeve të tilla.
Simptoma
Причина
Marrja e gabimit HTTP 500 ose 404
Serverët e bazës së të dhënave refuzojnë lidhjet
Përgjigjet e ngadalta të serverit
Përdorim i lartë i CPU-së ose kabllo Ethernet e dëmtuar
Përdoruesit në Antarktidë nuk po marrin GIF të maceve
CDN juaj i urren shkencëtarët dhe macet, kështu që disa adresa IP përfunduan në listën e zezë
Përmbajtja private është bërë e disponueshme nga kudo
Shfaqja e një versioni të ri të softuerit bëri që muri i zjarrit të harrojë të gjitha ACL-të dhe t'i lejojë të gjithë të hyjnë
"Çfarë" dhe "pse" janë disa nga blloqet ndërtuese më të rëndësishme për krijimin e një sistemi të mirë monitorimi me sinjal maksimal dhe zhurmë minimale.
Kutia e zezë vs kutia e bardhë
Ne kombinojmë monitorimin e gjerë të kutisë së bardhë me monitorimin modest të kutisë së zezë për metrikat kritike. Mënyra më e lehtë për të krahasuar kutinë e zezë me kutinë e bardhë është se kutia e zezë është e përqendruar te simptomat dhe është monitorim reaktiv dhe jo proaktiv: "sistemi nuk po funksionon siç duhet tani". White-box varet nga aftësitë e verifikimit të brendshëm të sistemeve: regjistrat e ngjarjeve ose serverët në internet. Kështu, White-box ju lejon të zbuloni problemet e afërta, gabimet që duket se janë një ritransmetim i një kërkese, etj.
Vini re se në një sistem me shumë shtresa, një simptomë në fushën e përgjegjësisë së një inxhinieri është një simptomë në fushën e përgjegjësisë së një inxhinieri tjetër. Për shembull, performanca e bazës së të dhënave është ulur. Leximet e ngadalta të bazës së të dhënave janë një simptomë e bazës së të dhënave SRE që i zbulon ato. Sidoqoftë, për një SRE të përparme që vëzhgon një faqe interneti të ngadaltë, shkaku i të njëjtit lexim të ngadaltë të bazës së të dhënave është një bazë e të dhënave e ngadaltë. Prandaj, monitorimi i kutisë së bardhë ndonjëherë është i fokusuar tek simptomat dhe nganjëherë i fokusuar tek shkaku, në varësi të shtrirjes së tij.
Gjatë mbledhjes së telemetrisë për korrigjimin e gabimeve, kërkohet monitorimi i White-box. Nëse serverët e uebit janë të ngadalshëm për t'iu përgjigjur pyetjeve të bazës së të dhënave, ju duhet të dini se sa shpejt komunikon serveri i uebit me bazën e të dhënave dhe sa shpejt ai përgjigjet. Përndryshe, nuk do të jeni në gjendje të bëni dallimin midis një serveri të ngadaltë të bazës së të dhënave dhe një problemi të rrjetit midis serverit të uebit dhe bazës së të dhënave.
Monitorimi i kutisë së zezë ka një avantazh kryesor kur dërgoni sinjalizime: ju aktivizoni njoftimin te marrësi kur problemi ka rezultuar tashmë në simptoma reale. Nga ana tjetër, monitorimi është i padobishëm për një problem të kutisë së zezë që nuk është shfaqur ende, por është i pashmangshëm.
Katër sinjale të arta
Katër sinjalet e arta të monitorimit janë vonesa, trafiku, gabimet dhe ngopja. Nëse mund të matni vetëm katër metrikë të sistemit të përdoruesve, përqendrohuni në ato katër.
vonesë
Koha e nevojshme për të përpunuar kërkesën. Është e rëndësishme të bëhet dallimi midis vonesës së kërkesave të suksesshme dhe të pasuksesshme. Për shembull, një gabim HTTP 500 i shkaktuar nga humbja e lidhjes me një bazë të dhënash ose një bazë tjetër mbështetëse mund të diagnostikohet shumë shpejt, megjithatë, një gabim HTTP 500 mund të tregojë një kërkesë të dështuar. Përcaktimi i ndikimit të një gabimi 500 në vonesën e përgjithshme mund të çojë në përfundime të gabuara. Nga ana tjetër, një gabim i ngadalshëm është edhe një gabim i shpejtë! Prandaj, është e rëndësishme të monitorohet vonesa e gabimit në vend që thjesht të filtrohen gabimet.
Trafiku
Numri i kërkesave për sistemin tuaj matet në metrikë të sistemit të nivelit të lartë. Për një shërbim ueb, kjo matje zakonisht përfaqëson numrin e kërkesave HTTP për sekondë, të ndarë sipas natyrës së kërkesave (për shembull, përmbajtje statike ose dinamike). Për një sistem transmetimi audio, kjo matje mund të fokusohet në shpejtësinë e hyrjes/daljes së rrjetit ose numrin e seancave të njëkohshme. Për një sistem të ruajtjes së vlerës së çelësit, kjo matje mund të jetë transaksione ose rezultate kërkimi për sekondë.
Gabimet
Kjo është shkalla e kërkesave të dështuara që janë të qarta (p.sh. HTTP 500), të nënkuptuara (p.sh. HTTP 200 por të kombinuara me përmbajtje të pavlefshme) ose politikë (p.sh. "Nëse keni marrë një përgjigje në një sekondë, çdo sekondë është një gabim"). Nëse kodet e përgjigjes HTTP nuk janë të mjaftueshme për të shprehur të gjitha kushtet e dështimit, mund të kërkohen protokolle dytësore (të brendshme) për të zbuluar dështimin e pjesshëm. Monitorimi i të gjitha kërkesave të tilla të dështuara mund të mos jetë informativ, ndërkohë që testet e sistemit nga fundi në fund do të ndihmojnë në zbulimin se po përpunoni përmbajtje të pasaktë.
Ngopja
Metrika tregon se sa intensivisht përdoret shërbimi juaj. Ky është një masë e monitorimit të sistemit që identifikon burimet që janë më të kufizuara (për shembull, në një sistem me memorie të kufizuar, tregon kujtesën, në një sistem të kufizuar nga I/O, tregon numrin e I/O-ve). Vini re se shumë sisteme degradojnë performancën përpara se të arrijnë shfrytëzimin 100%, kështu që të kesh një qëllim përdorimi është i rëndësishëm.
Në sistemet komplekse, ngopja mund të plotësohet me matje të ngarkesës në nivele më të larta: a mundet shërbimi juaj të trajtojë siç duhet trafikun e dyfishtë, të trajtojë vetëm 10% më shumë trafik ose të trajtojë edhe më pak trafik sesa aktualisht? Për shërbime të thjeshta që nuk kanë parametra që ndryshojnë kompleksitetin e kërkesës (për shembull, "Më jep asgjë" ose "Më duhet një numër i vetëm monotonik unik"), që rrallë ndryshojnë konfigurimin, një vlerë e testit të ngarkesës statike mund të jetë e përshtatshme. Megjithatë, siç u diskutua në paragrafin e mëparshëm, shumica e shërbimeve duhet të përdorin sinjale indirekte si përdorimi i CPU-së ose gjerësia e brezit të rrjetit, të cilat kanë një kufi të sipërm të njohur. Rritja e vonesës është shpesh një tregues kryesor i ngopjes. Matja e kohës së përgjigjes së përqindjes së 99-të në një dritare të vogël (p.sh., një minutë) mund të sigurojë një sinjal shumë të hershëm të ngopjes.
Së fundi, ngopja shoqërohet gjithashtu me parashikime rreth ngopjes së afërt, për shembull: "Duket sikur databaza juaj do të mbushë hard diskun tuaj në 4 orë."
Nëse matni të katër sinjalet e arta dhe kur ka një problem me një nga metrikat (ose, në rastin e ngopjes, një problem afërsisht), paralajmëroni një person, shërbimi juaj do të mbulohet pak a shumë nga monitorimi.
Shqetësimet për "bishtin" (ose instrumentet dhe performancën)
Kur krijoni një sistem monitorimi nga e para, ekziston një tundim për të zhvilluar një sistem të bazuar në vlerat mesatare: vonesa mesatare, përdorimi mesatar i CPU-së i nyjeve ose plotësia mesatare e bazës së të dhënave. Rreziku i dy shembujve të fundit është i dukshëm: procesorët dhe bazat e të dhënave asgjësohen në një mënyrë shumë të paparashikueshme. E njëjta gjë vlen edhe për vonesën. Nëse përdorni një shërbim ueb me një vonesë mesatare prej 100 ms me 1000 kërkesa në sekondë, 1% e kërkesave mund të zgjasin 5 sekonda. Nëse përdoruesit varen nga shumë shërbime të tilla në internet, përqindja e 99-të e një fundi mund të bëhet lehtësisht koha mesatare e përgjigjes së frontendit.
Mënyra më e thjeshtë për të bërë dallimin midis mesatares së ngadaltë dhe bishtit shumë të ngadaltë të kërkesave është mbledhja e matjeve të kërkesave të shprehura në statistika (një mjet i mirë për t'u shfaqur janë histogramet) në vend të vonesave aktuale: sa kërkesa shërbeu shërbimi që zgjatën midis 0 ms. dhe 10 ms, midis 10 ms dhe 30 ms, midis 30 ms dhe 100 ms, midis 100 ms dhe 300 ms, etj. Zgjerimi i kufijve të histogramit përafërsisht në mënyrë eksponenciale (me një faktor të përafërt prej 3) është shpesh një mënyrë e thjeshtë për të vizualizuar shpërndarjen të kërkesave.
Zgjedhja e nivelit të duhur të detajeve për matjet
Elementë të ndryshëm të sistemit duhet të maten në nivele të ndryshme detajesh. Për shembull:
- Monitorimi i përdorimit të CPU-së gjatë një periudhe kohore nuk do të tregojë rritje afatgjata që çojnë në vonesa të larta.
- Nga ana tjetër, për një shërbim ueb që synon jo më shumë se 9 orë ndërprerje në vit (99,9% kohëzgjatje vjetore), kontrollimi për një përgjigje HTTP 200 më shumë se një ose dy herë në minutë ka të ngjarë të jetë pa nevojë i shpeshtë.
- Po kështu, kontrollimi i hapësirës së diskut për disponueshmërinë 99,9% më shumë se një herë në 1-2 minuta ndoshta nuk është i nevojshëm.
Kini kujdes në mënyrën se si e strukturoni granularitetin e matjeve tuaja. Mbledhja e ngarkesës së CPU-së një herë në sekondë mund të sigurojë të dhëna interesante, por matje të tilla të shpeshta mund të jenë shumë të shtrenjta për t'u mbledhur, ruajtur dhe analizuar. Nëse qëllimi juaj i monitorimit kërkon shkallëzim të lartë dhe nuk kërkon reagim të lartë, mund t'i ulni këto kosto duke vendosur mbledhjen e metrikës në server dhe më pas duke vendosur një sistem të jashtëm për të mbledhur dhe grumbulluar ato metrika. a mund të:
- Matni ngarkesën e CPU-së çdo sekondë.
- Zvogëloni detajet në 5%.
- Përmbledh metrikat çdo minutë.
Kjo strategji do t'ju lejojë të mbledhni të dhëna me një shkallëzim të lartë, pa kryer analiza të larta dhe shpenzime të mëdha ruajtjeje.
Sa më e thjeshtë, por jo më e thjeshtë
Mbivendosja e kërkesave të ndryshme mbi njëra-tjetrën mund të rezultojë në një sistem monitorimi shumë kompleks. Për shembull, sistemi juaj mund të ketë elementët e mëposhtëm ndërlikues:
- Alarmet sipas pragjeve të ndryshme për vonesën e përpunimit të kërkesave, në përqindje të ndryshme, për të gjitha llojet e treguesve të ndryshëm.
- Shkrimi i kodit shtesë për të zbuluar dhe identifikuar shkaqet e mundshme.
- Krijoni panele përkatëse për secilin nga shkaqet e mundshme të problemeve.
Burimet e komplikimeve të mundshme nuk mbarojnë kurrë. Ashtu si të gjitha sistemet softuerike, monitorimi mund të bëhet aq kompleks sa të bëhet i brishtë dhe i vështirë për t'u ndryshuar dhe mirëmbajtur.
Prandaj, dizajnoni sistemin tuaj të monitorimit për ta thjeshtuar sa më shumë që të jetë e mundur. Kur zgjidhni se çfarë të gjurmoni, mbani parasysh sa vijon:
- Rregullat që më së shpeshti kapin incidente reale duhet të jenë sa më të thjeshta, të parashikueshme dhe të besueshme.
- Konfigurimi për mbledhjen e të dhënave, grumbullimin dhe sinjalizimin që kryhet rrallë (për shembull, më pak se çdo tremujor për disa ekipe SRE) duhet të hiqet.
- Metrikat që mblidhen, por që nuk shfaqen në asnjë panel kontrolli paraprak ose përdoren nga ndonjë sinjalizues, janë kandidatë për fshirje.
Në Google, mbledhja dhe grumbullimi i metrikës bazë, i kombinuar me sinjalizimet dhe panelet, funksionon mirë si një sistem relativisht i pavarur (sistemi i monitorimit të Google në fakt është i ndarë në disa nënsisteme, por njerëzit zakonisht janë të vetëdijshëm për të gjitha aspektet e këtyre nënsistemeve). Mund të jetë joshëse për të kombinuar monitorimin me teknika të tjera për ekzaminimin e sistemeve komplekse: profilizimin e detajuar të sistemit, korrigjimin e procesit, gjurmimin e detajeve rreth përjashtimeve ose dështimeve, testimin e ngarkesës, mbledhjen dhe analizën e regjistrave ose inspektimin e trafikut. Ndërsa shumica e këtyre gjërave kanë të përbashkëta me monitorimin bazë, përzierja e tyre do të rezultojë në shumë rezultate dhe do të krijojë një sistem kompleks dhe të brishtë. Ashtu si me shumë aspekte të tjera të zhvillimit të softuerit, mbështetja e sistemeve të ndryshme me pika integrimi të qarta, të thjeshta dhe të lidhura lirshëm është strategjia më e mirë (për shembull, përdorimi i një API ueb për të tërhequr të dhënat e grumbulluara në një format që mund të mbetet i qëndrueshëm për një periudhë të gjatë kohore ).
Lidhja e Parimeve së bashku
Parimet e diskutuara në këtë kapitull mund të kombinohen në një filozofi monitorimi dhe alarmimi që miratohet dhe ndiqet nga ekipet e Google SRE. Respektimi i kësaj filozofie monitorimi është i dëshirueshëm, është një pikënisje e mirë për krijimin ose rishikimin e metodologjisë suaj të sinjalizimit dhe mund t'ju ndihmojë të bëni pyetjet e duhura për funksionin tuaj të operacioneve, pavarësisht nga madhësia e organizatës suaj ose kompleksiteti i shërbimit ose sistemit.
Kur krijoni rregulla monitorimi dhe sinjalizimi, bërja e pyetjeve të mëposhtme mund t'ju ndihmojë të shmangni pozitivët e rremë dhe sinjalizimet e panevojshme:
- A zbulon ky rregull një gjendje përndryshe të pazbulueshme të sistemit që është urgjente, bën thirrje për veprim dhe në mënyrë të pashmangshme prek përdoruesin?
- A mund ta injoroj këtë paralajmërim duke e ditur se është i mirë? Kur dhe pse mund ta shpërfill këtë paralajmërim dhe si mund ta shmang këtë skenar?
- A do të thotë ky sinjalizim se përdoruesit po ndikohen negativisht? A ka situata ku përdoruesit nuk ndikohen negativisht, si p.sh. përmes filtrimit të trafikut ose kur përdoren sisteme testimi për të cilat duhet të filtrohen sinjalizimet?
- A mund të ndërmarr veprime në përgjigje të këtij sinjalizimi? A janë këto masa urgjente apo mund të presin deri në mëngjes? A mund të automatizohet një veprim në mënyrë të sigurt? A do të jetë ky veprim një zgjidhje afatgjatë apo një zgjidhje afatshkurtër?
- Disa njerëz po marrin sinjalizime të shumta për këtë çështje, kështu që a ka ndonjë mënyrë për të reduktuar numrin e sinjalizimeve?
Këto pyetje pasqyrojnë filozofinë themelore mbi sistemet e alarmeve dhe paralajmërimeve:
- Sa herë që vjen një alarm, duhet të reagoj menjëherë. Mund të reagoj urgjentisht disa herë në ditë para se të lodhem.
- Çdo alarm duhet të jetë relevant.
- Çdo përgjigje ndaj një alarmi duhet të kërkojë ndërhyrje njerëzore. Nëse njoftimi mund të përpunohet automatikisht, ai nuk duhet të arrijë.
- Alarmet duhet të jenë për një problem ose ngjarje të re që nuk ekzistonte më parë.
Kjo qasje mjegullon disa dallime: nëse sinjalizimi plotëson katër kushtet e mëparshme, nuk ka rëndësi nëse sinjalizimi dërgohet nga një sistem monitorimi White-box ose Black-Box. Kjo qasje gjithashtu përforcon disa dallime: është më mirë të shpenzoni shumë më tepër përpjekje për të identifikuar simptomat sesa për shkaqet; kur bëhet fjalë për shkaqet, duhet të shqetësoheni vetëm për shkaqet e pashmangshme.
Monitorimi afatgjatë
Në mjediset e sotme të produktivitetit, sistemet e monitorimit monitorojnë një sistem prodhimi gjithnjë në zhvillim me arkitekturë të softuerit në ndryshim, karakteristikat e ngarkesës së punës dhe objektivat e performancës. Alarmet që aktualisht janë të vështira për t'u automatizuar mund të bëhen të zakonshme, ndoshta edhe ia vlen të adresohen. Në këtë pikë, dikush duhet të gjejë dhe eliminojë shkaqet rrënjësore të problemit; nëse një zgjidhje e tillë nuk është e mundur, përgjigja ndaj alarmit kërkon automatizim të plotë.
Është e rëndësishme që vendimet e monitorimit të merren duke pasur parasysh qëllimet afatgjata. Çdo sinjalizim që ekzekutohet sot e largon një person nga përmirësimi i sistemit nesër, kështu që shpesh ka një reduktim në disponueshmërinë ose performancën e një sistemi produktiv për kohën e nevojshme për të përmirësuar sistemin e monitorimit në terma afatgjatë. Le të shohim dy shembuj për të ilustruar këtë fenomen.
Bigtable SRE: Një përrallë mbi alarmin
Infrastruktura e brendshme e Google zakonisht sigurohet dhe matet kundrejt një niveli shërbimi (SLO). Shumë vite më parë, shërbimi SLO i Bigtable bazohej në performancën mesatare të një transaksioni sintetik që simulonte një klient të drejtpërdrejtë. Për shkak të problemeve në Bigtable dhe niveleve më të ulëta të grumbullit të ruajtjes, performanca mesatare u nxit nga një bisht "i madh": 5% më e keqe e pyetjeve shpesh ishin dukshëm më të ngadalta se pjesa tjetër.
Njoftimet me email u dërguan me afrimin e pragut të SLO dhe sinjalizimet e mesazherëve u dërguan kur SLO ishte tejkaluar. Të dy llojet e sinjalizimeve dërgoheshin mjaft shpesh, duke konsumuar sasi të papranueshme të kohës inxhinierike: ekipi shpenzoi një kohë të konsiderueshme duke renditur sinjalizimet për të gjetur ato pak që ishin realisht të rëndësishme. Shpesh na mungonte një problem që prekte përdoruesit, sepse vetëm disa nga sinjalizimet ishin për atë çështje specifike. Shumë prej sinjalizimeve nuk ishin urgjente për shkak të problemeve të kuptueshme në infrastrukturë dhe u përpunuan në mënyrë standarde, ose nuk u përpunuan fare.
Për të korrigjuar situatën, ekipi mori një qasje me tre drejtime: ndërsa punonim shumë për të përmirësuar performancën e Bigtable, ne vendosëm përkohësisht objektivin tonë SLO të jetë përqindja e 75-të për vonesën e përgjigjes së pyetjeve. Ne gjithashtu i çaktivizuam sinjalizimet me email, sepse kishte aq shumë saqë ishte e pamundur të kalonim kohë për t'i diagnostikuar.
Kjo strategji na lejoi që dhoma e frymëmarrjes të fillojë të rregullojë problemet afatgjata në Bigtable dhe nivelet më të ulëta të grumbullit të ruajtjes, në vend që të rregullojmë vazhdimisht çështje taktike. Inxhinierët në fakt mund të kryenin punën pa u bombarduar me alarme gjatë gjithë kohës. Në fund të fundit, shtyrja e përkohshme e përpunimit të sinjalizimeve na lejoi të përmirësonim cilësinë e shërbimit tonë.
Gmail: Përgjigje njerëzore të parashikueshme, algoritmike
Në fillimin e tij, Gmail u ndërtua në një sistem të modifikuar të menaxhimit të procesit të Workqueue që ishte krijuar për të përpunuar pjesë të një indeksi kërkimi. Radha e punës u përshtat për proceset jetëgjata dhe më pas u aplikua në Gmail, por disa gabime në kodin e errët të planifikuesit u provuan shumë të vështira për t'u rregulluar.
Në atë kohë, monitorimi i Gmail ishte i strukturuar në mënyrë që sinjalizimet të aktivizoheshin kur detyrat individuale anuloheshin duke përdorur Workqueue. Kjo qasje nuk ishte ideale, sepse edhe në atë kohë, Gmail kryente mijëra detyra, secila prej të cilave iu ofrua një fraksioni të përqindjes së përdoruesve tanë. Ne ishim shumë të shqetësuar për t'u ofruar përdoruesve të Gmail një përvojë të mirë përdoruesi, por trajtimi i kaq shumë sinjalizimeve ishte i paarritshëm.
Për të adresuar këtë problem, Gmail SRE krijoi një mjet për të ndihmuar në korrigjimin e programit sa më mirë të jetë e mundur për të minimizuar ndikimin tek përdoruesit. Ekipi pati disa diskutime nëse thjesht do të automatizonte të gjithë ciklin nga zbulimi i problemit deri te korrigjimi derisa të gjendej një zgjidhje afatgjatë, por disa ishin të shqetësuar se një zgjidhje e tillë do të vononte në fakt ndreqjen e problemit.
Ky tension ishte i zakonshëm në ekip dhe shpesh pasqyronte mungesën e besimit në vetëdisiplinën: ndërsa disa anëtarë të ekipit duan të lënë kohë për rregullimin e duhur, të tjerë shqetësohen se rregullimi përfundimtar do të harrohet dhe rregullimi i përkohshëm do të zgjasë përgjithmonë. Kjo çështje meriton vëmendje sepse është shumë e lehtë të rregullosh përkohësisht problemet në vend që ta bësh situatën të përhershme. Menaxherët dhe stafi teknik luajnë një rol kyç në zbatimin e rregullimeve afatgjata, duke mbështetur dhe duke i dhënë përparësi zgjidhjeve potenciale afatgjata edhe pasi të ulet "dhimbja" fillestare.
Alarmet e rregullta, të përsëritura dhe përgjigjet algoritmike duhet të jenë një flamur i kuq. Ngurrimi i ekipit tuaj për të automatizuar këto sinjalizime do të thotë se ekipit i mungon besimi se mund t'u besojë algoritmeve. Ky është një problem serioz që duhet trajtuar.
Afatgjatë
Një temë e zakonshme lidh shembujt Bigtable dhe Gmail: konkurrenca midis disponueshmërisë afatshkurtër dhe afatgjatë. Shpesh, një përpjekje e fortë mund të ndihmojë një sistem të brishtë të arrijë disponueshmëri të lartë, por kjo rrugë është zakonisht jetëshkurtër, e mbushur me djegie të ekipit dhe varësi nga një numër i vogël anëtarësh të të njëjtit ekip heroik.
Reduktimi i kontrolluar dhe afatshkurtër i disponueshmërisë është shpesh i dhimbshëm, por strategjikisht i rëndësishëm për stabilitetin afatgjatë të sistemit. Është e rëndësishme të mos shikojmë secilin alarm në izolim, por të shqyrtojmë nëse niveli i përgjithshëm i volumit të alarmit çon në një sistem të shëndetshëm, të aksesueshëm siç duhet, me një ekip të zbatueshëm dhe një prognozë të favorshme. Ne analizojmë statistikat e frekuencës së alarmit (zakonisht të shprehura si incidente për ndërrim, ku një incident mund të përbëhet nga incidente të shumta të lidhura) në raportet tremujore drejtuar menaxhmentit, duke i lejuar vendimmarrësit të kenë një pamje të vazhdueshme të ngarkesës së sistemit të alarmit dhe shëndetit të përgjithshëm të ekipit.
Përfundim
Rruga drejt monitorimit dhe alarmimit të shëndetshëm është e thjeshtë dhe e qartë. Ai fokusohet në simptomat e problemit që shkaktojnë sinjalizime dhe monitorimi i shkakut shërben si një ndihmë për korrigjimin e problemeve. Monitorimi i simptomave është më i lehtë sa më lart të jeni në grupin që kontrolloni, megjithëse monitorimi i ngarkesës dhe performancës së bazës së të dhënave duhet të bëhet drejtpërdrejt në vetë bazën e të dhënave. Njoftimet me email kanë dobi shumë të kufizuar dhe priren të bëhen lehtësisht zhurmë; në vend të kësaj, duhet të përdorni një panel kontrolli që monitoron të gjitha problemet aktuale që shkaktojnë sinjalizime me email. Paneli mund të çiftohet gjithashtu me një regjistër ngjarjesh për të analizuar korrelacionet historike.
Në afat të gjatë, është e nevojshme të arrihet një rrotullim i suksesshëm i sinjalizimeve për simptomat dhe problemet reale të afërta, duke përshtatur qëllimet për të siguruar që monitorimi të mbështesë diagnozën e shpejtë.
Faleminderit që lexuat përkthimin deri në fund. Regjistrohu në kanalin tim të telegramit për monitorimin и .
Burimi: www.habr.com