SRE (Site Reliability Engineering) estas aliro por fari retprojektojn alireblaj. Ĝi estas konsiderata kadro por DevOps kaj rakontas kiel sukcesi en la apliko de DevOps-praktikoj. Ĉi tiu artikolo tradukiĝas libroj de Guglo. Mi mem preparis ĉi tiun tradukon kaj fidis je mia propra sperto pri komprenado de kontrolaj procezoj. En la telegrama kanalo и Mi ankaŭ afiŝis ligilon al traduko de Ĉapitro 4 de la sama libro pri Servonivelaj Celoj.
Traduko de kato. Ĝuu legadon!
La teamoj de Google SRE havas bazajn principojn kaj plej bonajn praktikojn por konstrui sukcesajn monitorajn kaj sciigajn sistemojn. Ĉi tiu ĉapitro donas rekomendojn pri kiaj problemoj povas renkonti retpaĝan vizitonton kaj kiel solvi problemojn, kiuj malfaciligas la montradon de retpaĝoj.
Difinoj
Ne ekzistas ununura vortprovizo uzata por diskuti temojn ligitajn al monitorado. Eĉ ĉe Guglo, la ĉi-subaj terminoj ne estas ofta uzataj, sed ni listigos la plej oftajn interpretojn.
Monitorado
Kolekto, prilaborado, agregado kaj montrado de realtempaj kvantaj datenoj pri la sistemo: nombro da petoj kaj specoj de petoj, nombro da eraroj kaj specoj de eraroj, petopretiga tempo kaj servila funkciado.
Monitorado de blanka skatolo
Monitorado surbaze de metrikoj montrataj de sisteminternoj, inkluzive de protokoloj, JVM aŭ HTTP-traktilo profilaj metrikoj kiuj generas internajn statistikojn.
Monitorado de nigra skatolo
Testante la konduton de la aplikaĵo el la vidpunkto de la uzanto.
Instrumentpanelo (instrumentpaneloj)
Interfaco (kutime interreta interfaco) kiu disponigas superrigardon de la ŝlosilaj sanindikiloj de la servoj. La panelo povas havi filtrilojn, la eblon elekti kiajn metrikojn montri, ktp. La interfaco estas desegnita por identigi la plej gravajn metrikojn por uzantoj. La panelo ankaŭ povas montri informojn por teknika helppersonaro: petovico, listo de altprioritataj eraroj, asignita inĝeniero por difinita areo de respondeco.
Atentigo (sciigo)
Sciigoj intencitaj esti ricevitaj de persono per retpoŝto aŭ alie, kiuj povas esti ekigitaj kiel rezulto de eraroj aŭ pliiĝo de la petovico. Sciigoj estas klasifikitaj kiel: biletoj, retpoŝtaj atentigoj kaj mesaĝaj mesaĝoj.
Radika kaŭzo (radika kaŭzo)
Programara difekto aŭ homa eraro kiu, kiam korektite, ne devus okazi denove. La problemo povas havi plurajn ĉefajn kialojn: nesufiĉa proceza aŭtomatigo, programaro-difekto, nesufiĉa studo de la aplika logiko. Ĉiu el ĉi tiuj faktoroj povas esti la radika kaŭzo, kaj ĉiu el ili devas esti forigita.
Nodo kaj maŝino (nodo kaj maŝino)
Interŝanĝeblaj terminoj por rilati al ununura okazo de funkcianta aplikaĵo sur fizika servilo, virtuala maŝino aŭ ujo. Povas ekzisti pluraj servoj sur unu maŝino. Servoj povas esti:
- rilataj unu al la alia: ekzemple kaŝservilo kaj retservilo;
- nerilataj servoj sur la sama aparataro: ekzemple, koddeponejo kaj sorĉisto por agorda sistemo, kiel ekzemple aŭ .
puŝo
Ajna ŝanĝo al la programara agordo.
Kial monitorado estas necesa
Estas pluraj kialoj kial aplikoj devus esti monitoritaj:
Analizo de longtempaj tendencoj
Kiom granda estas la datumbazo kaj kiom rapide ĝi kreskas? Kiel ŝanĝiĝas la ĉiutaga nombro da uzantoj?
Komparo de rendimento
Ĉu demandoj estas pli rapidaj ĉe Acme Bucket of Bytes 2.72 ol Ajax DB 3.14? Kiom pli bone estas petoj konservitaj post la apero de plia nodo? Ĉu la retejo fariĝis pli malrapida ol la pasinta semajno?
Atentigo (scioj)
Io estas rompita kaj iu devas ripari ĝin. Aŭ io baldaŭ rompiĝos kaj iu devas baldaŭ kontroli ĝin.
Kreante panelojn
Paneloj devus respondi bazajn demandojn kaj inkluzivi ion de - malfruoj (latenteco), trafiko (trafiko), eraroj (eraroj) kaj ŝarĝvaloro (saturiĝo).
Farante retrospektivan analizon (sencimigado)
La latenteco de la procesado de petoj pliiĝis, kio alia okazis ĉirkaŭ la sama tempo?
Monitoraj sistemoj estas utilaj kiel datenfonto por komercaj spionsistemoj kaj faciligi la analizon de sekurecaj okazaĵoj. Ĉar ĉi tiu libro temigas inĝenierajn areojn en kiuj SRE-oj havas kompetentecon, ni ne diskutos pri monitoraj teknikoj ĉi tie.
Monitorado kaj atentigoj permesas al la sistemo scii kiam ĝi rompiĝis aŭ estas rompiĝos. Kiam sistemo ne povas aŭtomate ripari sin, ni volas, ke homo analizu la atentigon, determini ĉu la problemo ankoraŭ ĉeestas, ripari ĝin kaj determini ĝian radikan kaŭzon. Se vi ne kontrolas sistemajn komponantojn, vi neniam ricevos atentigon nur ĉar "io ŝajnas iom stranga."
Ŝarĝi homajn atentigojn estas sufiĉe multekosta uzo de la tempo de dungito. Se la dungito laboras, la atentigo interrompas la laborfluon. Se la dungito estas hejme, la atentigo interrompas personan tempon kaj eble dormon. Kiam atentigoj okazas tro ofte, dungitoj preterpasas, prokrastas aŭ ignoras alvenantajn atentigojn. De tempo al tempo ili ignoras la veran alarmon, kiu estas maskita de bruaj eventoj. Servointerrompoj povas daŭri longan tempon, ĉar bruaj eventoj malhelpas rapidan problemo-diagnozon kaj solvon. Efikaj alparolsistemoj havas bonan signal-bruo-proporcion.
Determinante raciajn atendojn de la monitora sistemo
Agordi monitoradon por kompleksa aplikaĵo estas kompleksa inĝenieristiko en si mem. Eĉ kun signifa infrastrukturo de kolekto, montrado kaj atentiga iloj, Google SRE-teamo de 10-12 membroj kutime inkluzivas unu aŭ du homojn, kies ĉefa celo estas konstrui kaj konservi monitorajn sistemojn. Ĉi tiu nombro malpliiĝis laŭlonge de la tempo dum ni ĝeneraligas kaj centralizas la monitoran infrastrukturon, sed ĉiu SRE-teamo kutime havas almenaŭ unu monitoran nuran personaron. Oni devas diri, ke kvankam estas sufiĉe interese rigardi monitorajn sistempanelojn, SRE-teamoj zorge evitas situaciojn, kiuj postulas iun rigardi la ekranon por monitori problemojn.
Ĝenerale, Google moviĝis al simplaj kaj rapidaj monitoraj sistemoj kun optimumaj post-faktaj analiziloj. Ni evitas "magiajn" sistemojn, kiuj provas antaŭdiri sojlojn aŭ aŭtomate malkovras la radikan kaŭzon. Sensiloj kiuj detektas neintencitan enhavon en finuzantpetoj estas la nura kontraŭekzemplo; kondiĉe ke ĉi tiuj sensiloj restas simplaj, ili povas rapide detekti la kaŭzojn de gravaj anomalioj. Aliaj formatoj por uzi monitorajn datumojn, kiel kapacitplanado aŭ trafikprognozo, estas pli malfacilaj. Observado dum tre longa tempo (monatoj aŭ jaroj) kun malalta specimena indico (horoj aŭ tagoj) malkaŝos longperspektivan tendencon.
La teamo de Google SRE laboris kun diversaj gradoj de sukceso kun kompleksaj dependecaj hierarkioj. Ni malofte uzas regulojn kiel "se mi ekscias, ke la datumbazo malrapidiĝis, mi ricevas alarmon pri malrapidiĝo de la datumbazo, alie mi ricevas malrapidan retejan alarmon." Reguloj bazitaj pri dependeco kutime rilatas al la senŝanĝaj partoj de nia sistemo, kiel la sistemo por filtri uzanttrafikon al la datumcentro. Ekzemple, "se datumcentra trafika filtrado estas agordita, ne atentigu min pri prokrastoj en prilaborado de uzantpetoj" estas unu ofta regulo por datumcentraj alarmoj. Malmultaj teamoj ĉe Guglo subtenas kompleksajn dependecaj hierarkioj ĉar nia infrastrukturo havas konstantan rapidecon de kontinua refaktorado.
Kelkaj el la ideoj skizitaj en ĉi tiu ĉapitro ankoraŭ validas: ĉiam estas maniero movi pli rapide de simptomo al radika kaŭzo, precipe en ĉiam ŝanĝiĝantaj sistemoj. Tial, dum ĉi tiu ĉapitro skizas kelkajn celojn por monitoraj sistemoj kaj kiel atingi tiujn celojn, estas grave ke monitoraj sistemoj estas simplaj kaj kompreneblaj por ĉiuj en la teamo.
Same, por konservi la brunivelon malalta kaj la signalnivelon alta, aliroj al monitorado de objektoj kiuj estas atentigitaj devas esti tre simplaj kaj fidindaj. Reguloj kiuj generas avertojn por homoj devus esti facile kompreneblaj kaj prezenti klaran problemon.
Simptomoj kontraŭ kaŭzoj
Via monitora sistemo devus respondi du demandojn: "kio estas rompita" kaj "kial ĝi estas rompita".
"Kio rompis" rilatas al la simptomo, kaj "kial rompis" rilatas al la kaŭzo. La suba tabelo montras ekzemplojn de tiaj ligiloj.
Simptomo
Kialo
Ricevante HTTP-Eraron 500 aŭ 404
Datumbazaj serviloj rifuzas konektojn
Malrapidaj servilaj respondoj
Alta CPU-Uzo aŭ Difektita Ethernet-Kablo
Uzantoj en Antarkto ne ricevas katajn GIF-ojn
Via CDN malamas sciencistojn kaj katojn, do iuj IP-oj estas nigralistigitaj
Privata enhavo disponeblas ĉie
La ruliĝo de nova programaro igis la fajroŝirmilon forgesi ĉiujn ACL-ojn kaj lasi ĉiujn eniri
"Kio" kaj "kial" estas unu el la plej gravaj konstrubriketoj por krei bonan monitoran sistemon kun maksimuma signalo kaj minimuma bruo.
Nigra-skatolo kontraŭ Blanka-skatolo
Ni kombinas ampleksan monitoradon de blanka skatolo kun modesta monitorado de nigra skatolo por kritikaj mezuroj. La plej facila maniero kompari Black-box al White-box estas, ke Black-box estas simptom-fokusita kaj estas reaktiva prefere ol iniciatema monitorado: "la sistemo ne funkcias ĝuste nun." Blanka skatolo dependas de la internaj kontrolaj kapabloj de sistemoj: okazaĵaj protokoloj aŭ retserviloj. Tiel, White-box permesas vin detekti venontajn problemojn, misfunkciojn, kiuj aspektas kiel retranssendo de peto, ktp.
Notu, ke en plurtavola sistemo, simptomo en la areo de respondeco de unu inĝeniero estas simptomo en la areo de respondeco de alia inĝeniero. Ekzemple, datumbaza rendimento malpliiĝis. Malrapidaj datumbazoj legas estas simptomo de la datumbazo SRE kiu detektas ilin. Tamen, por front-end SRE rigardanta malrapidan retejon, la kialo de la sama malrapida datumbazo legado estas ke la datumbazo estas malrapida. Sekve, blank-skatola monitorado foje estas koncentrita sur simptomoj kaj foje sur kaŭzoj, depende de kiom ampleksa ĝi estas.
Kiam oni kolektas telemetrion por senararigado, necesas monitorado de Blanka skatolo. Se retserviloj malrapidas respondi al datumbazaj demandoj, vi devas scii kiom rapide la retservilo komunikas kun la datumbazo kaj kiom rapide ĝi respondas. Alie, vi ne povos distingi inter malrapida datumbaza servilo kaj reta problemo inter la retservilo kaj la datumbazo.
Nigra-skatola monitorado havas ŝlosilan avantaĝon dum sendado de atentigoj: vi ekigas sciigon al la ricevanto kiam la problemo jam kaŭzis realajn simptomojn. Aliflanke, por la problemo de Black-box kiu ankoraŭ ne aperis, sed la estonta, monitorado estas senutila.
Kvar oraj signaloj
La kvar oraj monitoraj signaloj estas latenteco, trafiko, eraroj kaj saturiĝo. Se vi povas mezuri nur kvar uzantsistemajn metrikojn, koncentriĝu sur tiuj kvar.
Prokrasto
La tempo necesa por procesi la peton. Gravas distingi inter la latencia de sukcesaj kaj malsukcesaj petoj. Ekzemple, HTTP 500-eraro kaŭzita de perdita konekto al datumbazo aŭ alia backend povas esti diagnozita tre rapide, tamen, HTTP 500-eraro povas indiki malsukcesan peton. Trovi la efikon de 500-eraro sur ĝenerala latenco povas konduki al eraraj konkludoj. Aliflanke, malrapida eraro estas eĉ rapida eraro! Sekve, gravas spuri erarajn latentecon prefere ol nur filtri erarojn.
trafiko
La nombro da petoj al via sistemo, mezurita en altnivelaj sistemaj metrikoj. Por retservo, ĉi tiu mezurado tipe reprezentas la nombron da HTTP-petoj je sekundo dividita per la naturo de la petoj (ekzemple, senmova aŭ dinamika enhavo). Por audioflua sistemo, ĉi tiu mezurado povas esti centrita sur la reto I/O-indico aŭ la nombro da samtempaj sesioj. Por ŝlosilvalora stokadsistemo, ĉi tiu mezurado povus esti transakcioj aŭ serĉoj je sekundo.
Eraroj
Ĉi tiu estas la indico de malsukcesaj petoj, aŭ eksplicite (ekzemple, HTTP 500), implicite (ekzemple, HTTP 200 sed kombinita kun malbona enhavo), aŭ laŭ politiko (ekzemple, "Se vi kaptas respondon en unu sekundo, ajna unu sekundo estas eraro"). Se ne ekzistas sufiĉe da HTTP-respondkodoj por esprimi ĉiujn fiaskokondiĉojn, sekundaraj (internaj) protokoloj povas esti postulataj por detekti partan fiaskon. Monitori ĉiujn tiajn erarajn petojn povas esti neinforma, dum fin-al-finaj sistemaj testoj povas helpi vin malkovri, ke vi prilaboras malĝustan enhavon.
Saturiĝo
La metriko montras kiom forte via servo estas uzata. Ĉi tio estas sistema monitora mezuro, kiu identigas rimedojn, kiuj estas plej limigitaj (ekzemple, en sistemo kun limigita memoro, montras memoron, en sistemo kun limigita I/O, montras la nombron da I/O). Notu, ke multaj sistemoj degradas antaŭ ol ili atingas 100%-uzadon, do havi uzcelon estas esenca.
En kompleksaj sistemoj, saturiĝo povas esti kompletigita per pli alta nivela ŝarĝmezurado: ĉu via servo povas ĝuste trakti duoblan trafikon, nur pritrakti 10% pli da trafiko, aŭ trakti eĉ malpli da trafiko ol ĝi povas nuntempe? Por simplaj servoj kiuj ne havas parametrojn kiuj ŝanĝas la kompleksecon de la peto (ekz. "Donu al mi nenion" aŭ "mi bezonas unikan monotonan entjeron") kiuj malofte ŝanĝas agordon, statika ŝarĝa testvaloro povas esti adekvata. Tamen, kiel diskutite en la antaŭa paragrafo, la plej multaj servoj devus uzi nerektajn signalojn kiel CPU-utiligo aŭ retan bendolarĝon kiuj havas konatan supran limon. Altiĝanta latenteco ofte estas la ĉefa indikilo de saturiĝo. Mezuri la 99-an procentan respondtempon en malgranda fenestro (ekz. unu minuto) povas doni tre fruan saturigan signalon.
Fine, saturiĝo ankaŭ rilatas al antaŭdiroj de baldaŭa saturiĝo, kiel ekzemple: "Ŝajnas, ke via datumbazo plenigos vian malmolan diskon en 4 horoj."
Se vi mezuras ĉiujn kvar orajn signalojn kaj kiam estas problemo kun unu el la metrikoj (aŭ, en kazo de saturiĝo, preskaŭ problemo), vi sciigas la personon, via servo estos pli-malpli kovrita de monitorado.
Zorgu pri la vosto (aŭ instrumentado kaj rendimento)
Kiam oni kreas monitoran sistemon de nulo, estas tento evoluigi sistemon bazitan sur averaĝaj valoroj: averaĝa latencia, averaĝa CPU-uzado de nodoj aŭ averaĝa datumbaza pleneco. La danĝero de la lastaj du ekzemploj estas evidenta: procesoroj kaj datumbazoj estas forigitaj en tre neantaŭvidebla maniero. La sama validas por prokrasto. Se vi prizorgas TTT-servon kun averaĝa latenteco de 100ms kun 1000 petoj sekundo, 1% de petoj povus daŭri 5 sekundojn. Se uzantoj dependas de pluraj tiaj retservoj, la 99-a percentilo de unu backend povas facile fariĝi la meza respondtempo de la fasado.
La plej simpla maniero distingi inter malrapida mezumo kaj tre malrapida vosto de petoj estas kolekti mezuradojn de petoj esprimitaj en statistiko (histogramoj estas taŭga ilo por montri), prefere ol realaj prokrastoj: kiom da petoj estis servitaj de la servo kiu prenis. inter 0 ms kaj 10ms, inter 10ms kaj 30ms, inter 30ms kaj 100ms, inter 100ms kaj 300ms, ktp. Pligrandigi la histogram-limojn proksimume eksponente (per faktoro de ĉirkaŭ 3) estas ofte facila maniero por bildigi la distribuadon de petoj.
Elektante la ĝustan granularecon por mezuradoj
Malsamaj elementoj de la sistemo devus esti mezuritaj kun malsamaj niveloj de detalo. Ekzemple:
- Rigardi uzadon de CPU dum tempodaŭro ne montros longajn pikilojn, kiuj rezultigas altajn latentecojn.
- Aliflanke, por retservo celanta ne pli ol 9 horojn da malfunkcio jare (99,9% jara funkciado), kontroli por HTTP 200 respondon pli ol unu aŭ dufoje por minuto verŝajne estus nenecese ofta.
- Simile, kontroli pri libera spaco sur la malmola disko por 99,9% havebleco pli ol unufoje ĉiun 1-2 minutojn verŝajne estas nenecesa.
Zorgu kiel vi strukturas la granularecon de la dimensioj. CPU-uzoprocento de 1 je sekundo povas provizi interesajn datumojn, sed tiaj oftaj mezuradoj povas esti tre multekostaj kolekti, stoki kaj analizi. Se via monitora celo postulas altan granularecon kaj ne postulas altan respondecon, vi povas redukti ĉi tiujn kostojn starigante metrikkolekton sur la servilo kaj poste agordante eksteran sistemon por kolekti kaj kunigi tiujn metrikojn. Ĉu vi povus:
- Mezuru CPU-uzadon ĉiun sekundon.
- Redukti detalon al 5%.
- Entutaj metrikoj ĉiuminute.
Ĉi tiu strategio permesos al vi kolekti tre grajnecajn datumojn sen sperti altajn kostojn por analizo kaj stokado.
Kiel eble plej simpla, sed ne pli facila
Stakigi malsamajn postulojn unu sur la alian povas konduki al tre kompleksa monitora sistemo. Ekzemple, via sistemo povas havi la jenajn komplikajn elementojn:
- Atentigoj laŭ malsamaj sojloj por peta latenco, en malsamaj percentiloj, tra ĉiaj malsamaj metrikoj.
- Skribante plian kodon por detekti kaj identigi eblajn kaŭzojn.
- Kreu rilatajn panelojn por ĉiu el la eblaj kaŭzoj de problemoj.
La fontoj de ebla komplikaĵo neniam finiĝas. Kiel ĉiuj softvarsistemoj, monitorado povas iĝi tiel kompleksa ke ĝi iĝas delikata, malfacile ŝanĝi kaj konservi.
Tial, desegnu vian monitoran sistemon por simpligi ĝin kiel eble plej multe. Kiam vi elektas kion spuri, memoru la jenajn:
- La reguloj, kiuj plej ofte kaptas realajn okazaĵojn, devus esti kiel eble plej simplaj, antaŭvideblaj kaj fidindaj.
- La agordo por datumkolektado, agregado kaj atentigo, kiu estas farata malofte (ekzemple, malpli ol kvaronjare por kelkaj SRE-teamoj) devus esti forigita.
- Metrikoj kiuj estas kolektitaj sed ne montritaj en iu antaŭrigarda panelo aŭ uzataj de iu atentigo estas kandidatoj por forigo.
Ĉe Guglo, baza kolekto kaj agregado de metrikoj, kombinitaj kun atentigoj kaj paneloj, funkcias bone kiel relative memstara sistemo (la monitora sistemo de Guglo estas fakte dividita en plurajn subsistemojn, sed kutime homoj konscias pri ĉiuj aspektoj de tiuj subsistemoj). Povas esti tente kombini monitoradon kun aliaj metodoj de testado de kompleksaj sistemoj: detala sistemprofilado, proceza elpurigado, spurado de escepto aŭ fiaskodetaloj, ŝarĝtestado, ŝtipkolekto kaj analizo, aŭ trafika inspektado. Dum la plej multaj el ĉi tiuj aferoj kunhavas komunajn kun baza monitorado, miksi ilin rezultigos tro multajn rezultojn kaj kreos kompleksan kaj fragilan sistemon. Kiel kun multaj aliaj aspektoj de programaro, subteni malsamajn sistemojn kun klaraj, simplaj, loze kunligitaj integriĝaj punktoj estas la plej bona strategio (ekzemple, uzante TTT-API por preni resumajn datumojn en formato kiu povas resti konstanta dum longa tempodaŭro). ).
Kunligi principojn
La principoj diskutitaj en ĉi tiu ĉapitro povas esti kombinitaj en monitorado kaj atentiga filozofio kiu estas aprobita kaj sekvata de Google SRE-teamoj. Aliĝi al ĉi tiu monitora filozofio estas dezirinda, ĝi estas bona deirpunkto por krei aŭ revizii atentan metodaron, kaj povas helpi vin demandi la ĝustajn demandojn al operacioj sendepende de la grandeco de via organizo aŭ la komplekseco de la servo aŭ sistemo.
Kiam vi kreas regulojn pri monitorado kaj atentigo, demandi la jenajn demandojn povas helpi vin eviti falsajn pozitivojn kaj nenecesajn atentigojn:
- Ĉu ĉi tiu regulo detektas alie nerimarkeblan sisteman staton, kiu urĝas, vokas al ago kaj neeviteble influas la uzanton?
- Ĉu mi povas ignori ĉi tiun averton sciante, ke ĝi estas benigna? Kiam kaj kial mi povas ignori ĉi tiun averton kaj kiel mi povas eviti ĉi tiun scenaron?
- Ĉu ĉi tiu atentigo signifas, ke uzantoj estas malfavore tuŝitaj? Ĉu ekzistas situacioj kie uzantoj ne estas negative trafitaj, ekzemple, pro trafika filtrado aŭ kiam uzado de testsistemoj, atentigoj pri kiuj devus esti filtritaj?
- Ĉu mi povas agi responde al ĉi tiu atentigo? Ĉu ĉi tiuj mezuroj estas urĝaj aŭ ĉu ili povas atendi ĝis la mateno? Ĉu estas sekure aŭtomatigi la agon? Ĉu ĉi tiu ago estos longtempa solvo aŭ mallongdaŭra solvo?
- Iuj homoj ricevas plurajn atentigojn pri ĉi tiu afero, ĉu do eblas redukti la nombron?
Ĉi tiuj demandoj reflektas la fundamentan filozofion pri atentigoj kaj alarmsistemoj:
- Ĉiufoje kiam envenas alarmo, mi devas urĝe reagi. Mi povas rapidi plurfoje tage antaŭ ol mi laciĝos.
- Ĉiu atentigo devas esti ĝisdatigita.
- Ĉiu respondo al atentigo devas postuli homan intervenon. Se la sciigo povas esti procesita aŭtomate, ĝi ne devus veni.
- Atentigoj devus temi pri nova afero aŭ evento kiu ne okazis antaŭe.
Ĉi tiu aliro malklarigas certajn distingojn: se atentigo kontentigas la antaŭajn kvar kondiĉojn, ne gravas ĉu la atentigo estas sendita de Blank-kesto-monitorsistemo aŭ Black-Box. Ĉi tiu aliro ankaŭ plifortigas certajn diferencojn: estas pli bone elspezi multe pli da peno por identigi simptomojn ol por kaŭzoj; kiam temas pri kaŭzoj, vi nur bezonas zorgi pri la neeviteblaj kaŭzoj.
Longtempa monitorado
En la hodiaŭaj produktadmedioj, monitoraj sistemoj monitoras ĉiam-evoluantan produktadsistemon kun ŝanĝiĝanta softvararkitekturo, ŝarĝaj trajtoj kaj agado-celoj. Atentigoj, kiuj estas nuntempe malfacile aŭtomatigeblaj, povas fariĝi oftaj, eble eĉ meritantaj esti traktitaj. Je ĉi tiu punkto, iu devas trovi kaj ripari la radikajn kaŭzojn de la problemo; se tia rezolucio ne eblas, la reago al la atentigo postulas plenan aŭtomatigon.
Gravas, ke kontrolaj decidoj estas faritaj kun longdaŭraj celoj en menso. Ĉiu atentigo, kiu funkcias hodiaŭ, forprenas personon de plibonigado de la sistemo morgaŭ, do ofte estas malpliigo de la havebleco aŭ agado de produktiva sistemo por la tempo necesa por plibonigi la monitoran sistemon longtempe. Ni rigardu du ekzemplojn, kiuj ilustras ĉi tiun fenomenon.
Bigtable SRE: Rakonto pri tro-atentigo
La interna infrastrukturo de Google estas kutime provizita kaj mezurita laŭ Serva Nivelo (SLO). Antaŭ jaroj, la SLO de la Bigtable-servo baziĝis sur la averaĝa rendimento de sinteza transakcio simulanta kurantan klienton. Pro problemoj en Bigtable kaj pli malaltaj niveloj de la stokado, averaĝa rendimento estis pelita de "granda" vosto: la plej malbonaj 5% de demandoj ofte estis signife pli malrapidaj ol la resto.
Retpoŝtaj sciigoj estis senditaj kiam la SLO-sojlo estis alproksimiĝita, kaj mesaĝistaj alarmoj estis senditaj kiam la SLO estis superita. Ambaŭ specoj de atentigoj estis senditaj sufiĉe ofte, konsumante neakcepteblajn kvantojn da inĝenieristiktempo: la teamo pasigis signifan tempon analizante la atentigojn por trovi kelkajn kiuj estis efektive trafaj. Ni ofte maltrafis problemon, kiu efektive influis uzantojn, ĉar nur kelkaj el la atentigoj estis por tiu aparta afero. Multaj el la atentigoj estis ne-urĝaj pro kompreneblaj infrastrukturaj problemoj kaj estis pritraktitaj laŭ norma maniero, aŭ tute ne pritraktitaj.
Por solvi la situacion, la teamo uzis tribranĉan aliron: laborante forte por plibonigi la agadon de Bigtable, ni provizore starigis la 75-an procenton por prokrasto pri demanda respondo kiel nian SLO-celon. Ni ankaŭ malŝaltis retpoŝtajn alarmojn, ĉar estis tiom da ili, ke estis neeble perdi tempon por diagnozi ilin.
Ĉi tiu strategio permesis al ni spiradon komenci ripari longperspektivajn problemojn en Bigtable kaj la pli malaltaj tavoloj de la stoka stako, anstataŭ konstante ripari taktikajn problemojn. Inĝenieroj povus efektive plenumi la laboron kiam ili ne estis bombarditaj per atentigoj la tutan tempon. Finfine, la provizora prokrasto en prilaborado de atentigoj permesis al ni plibonigi la kvaliton de servo.
Gmail: Antaŭvideblaj, Algoritmaj Homaj Respondoj
Ĉe la komenco, Gmail estis konstruita sur modifita Workqueue-proceza kontrolsistemo, kiu estis kreita por grupprocezserĉaj indekspartoj. Workqueue estis adaptita al longdaŭraj procezoj kaj poste aplikita al Gmail, sed kelkaj eraroj en la maldiafana planilo-kodo montriĝis tre malfacile ripareblaj.
Tiutempe, Gmail-monitorado estis strukturita tiel ke alarmoj ekfunkcius kiam individuaj taskoj estis nuligitaj uzante Workqueue. Ĉi tiu aliro ne estis ideala, ĉar eĉ en tiu tempo Gmail plenumis multajn milojn da taskoj, ĉiu el kiuj estis donita al frakcioj de procento de niaj uzantoj. Ni tre zorgis por certigi, ke Gmail-uzantoj havu bonan sperton de uzanto, sed pritrakti tiujn multajn atentigojn estis neeble.
Por solvi ĉi tiun problemon, Gmail SRE kreis ilon por helpi sencimigi la planilon kiel eble plej bone por minimumigi la efikon al uzantoj. La teamo havis plurajn diskutojn pri ĉu simple aŭtomatigi la tutan ciklon de trovado de la problemo ĝis ripari ĝin ĝis longtempa solvo estis trovita, sed kelkaj estis maltrankvilaj ke tia solvo prokrastus la faktan fiksadon de la problemo.
Tia streĉiteco estis ofta ene de la teamo kaj ofte reflektis malfidon je memdisciplino: dum kelkaj grupanoj volas doni tempon por bonorda solvo, aliaj maltrankvilas ke la fina solvo estos forgesita kaj la provizora solvo daŭros eterne. Ĉi tiu problemo meritas atenton, ĉar estas tro facile ripari problemojn provizore, anstataŭ fari konstantan solvon. Manaĝeroj kaj teknika personaro ludas ŝlosilan rolon en la efektivigo de longtempaj korektoj subtenante kaj prioritatante eble longdaŭrajn longtempajn korektojn eĉ kiam la komenca doloro malpliiĝas.
Regulaj revenantaj atentigoj kaj algoritmaj reagoj devus esti ruĝa flago. La malemo de via teamo aŭtomatigi ĉi tiujn atentigojn signifas, ke la teamo ne fidas, ke ili povas fidi la algoritmojn. Ĉi tio estas grava problemo, kiun oni devas trakti.
Longtempe
Ofta temo ligas la ekzemplojn de Bigtable kaj Gmail: la konkurado inter baldaŭa kaj longtempa havebleco. Ofte forta fortostreĉo povas helpi delikatan sistemon atingi altan haveblecon, sed ĉi tiu vojo estas kutime mallongdaŭra, plena de teamelĉerpiĝo kaj dependeco de malgranda nombro da membroj de ĉi tiu sama heroa teamo.
Kontrolita, mallongperspektiva malkresko en havebleco ofte estas dolora, sed strategie grava por la longperspektiva stabileco de la sistemo. Gravas ne konsideri ĉiun atentigon izolite, sed konsideri ĉu la ĝenerala indico de alarmoj kondukas al sana, taŭge alirebla sistemo kun realigebla teamo kaj favora prognozo. Ni analizas atentajn indicojn (kutime esprimitajn kiel okazaĵoj per deĵoro, kie okazaĵo povas konsisti el multoblaj rilataj okazaĵoj) en kvaronjaraj raportoj kun administrado, permesante al decidantoj kontinue prezenti alarmsistemon-ŝarĝon kaj ĝeneralan teaman sanon.
konkludo
La vojo al sana monitorado kaj atentigoj estas simpla kaj simpla. Ĝi fokusiĝas al la simptomoj de la problemo por kiuj atentigoj estas generitaj, kaj monitorado de la kaŭzo servas kiel helpo por sencimigaj problemoj. Simptoma monitorado estas pli facila ju pli alta vi estas en la stako, kiun vi kontrolas, kvankam datumbaza ŝarĝo kaj agado-monitorado devas esti faritaj rekte sur la datumbazo mem. Retpoŝtaj sciigoj estas de tre limigita uzo kaj tendencas eskaladi en bruon facile; anstataŭe, vi devus uzi panelon, kiu kontrolas ĉiujn aktualajn problemojn, kiuj estas atentigitaj retpoŝte. La panelo ankaŭ povas esti parigita kun okazaĵa protokolo por analizi historiajn korelaciojn.
Longtempe, sukcesa alterno inter simptomatentigoj kaj baldaŭaj realaj problemoj devas esti atingita, kaj celoj adaptitaj por certigi ke monitorado subtenas rapidan diagnozon.
Dankon pro legi la tradukon ĝis la fino. Abonu mian telegraman kanalon pri monitorado и .
fonto: www.habr.com