Mae SRE (Peirianneg Dibynadwyedd Safle) yn ddull o sicrhau bod prosiectau gwe ar gael. Fe'i hystyrir yn fframwaith ar gyfer DevOps ac mae'n sôn am sut i sicrhau llwyddiant wrth gymhwyso arferion DevOps. Cyfieithiad yn yr erthygl hon llyfrau oddi wrth Google. Paratoais y cyfieithiad hwn fy hun a dibynnais ar fy mhrofiad fy hun o ddeall prosesau monitro. Yn y sianel telegram и Cyhoeddais hefyd ddolen i’r cyfieithiad o Bennod 4 o’r un llyfr am nodau lefel gwasanaeth.
Cyfieithiad gan gath. Mwynhewch ddarllen!
Mae gan dimau SRE Google egwyddorion sylfaenol ac arferion gorau ar gyfer creu systemau monitro a hysbysu llwyddiannus. Mae'r bennod hon yn rhoi arweiniad ar ba broblemau y gallai ymwelydd â thudalennau gwe ddod ar eu traws a sut i ddatrys problemau sy'n gwneud tudalennau gwe yn anodd eu harddangos.
Diffiniadau
Ni ddefnyddir geirfa unigol i drafod testunau sy'n ymwneud â monitro. Hyd yn oed ar Google, nid yw'r termau isod yn cael eu defnyddio'n gyffredin, ond byddwn yn rhestru'r dehongliadau mwyaf cyffredin.
Monitro
Casglu, prosesu, agregu ac arddangos data meintiol am y system mewn amser real: nifer y ceisiadau a'r mathau o geisiadau, nifer y gwallau a'r mathau o wallau, amser prosesu ceisiadau a uptime gweinyddwr.
Monitro blwch gwyn
Monitro yn seiliedig ar fetrigau a ddangosir gan gydrannau system fewnol, gan gynnwys logiau, metrigau proffilio Java Virtual Machine, neu fetrigau triniwr HTTP sy'n cynhyrchu ystadegau mewnol.
Monitro blwch du
Profi ymddygiad cymhwysiad o safbwynt y defnyddiwr.
Dangosfwrdd
Rhyngwyneb (gwe fel arfer) sy'n rhoi trosolwg o ddangosyddion iechyd allweddol gwasanaethau. Efallai y bydd gan y dangosfwrdd hidlwyr, y gallu i ddewis y dangosyddion a ddangosir, ac ati Mae'r rhyngwyneb wedi'i gynllunio i nodi'r dangosyddion sydd bwysicaf i ddefnyddwyr. Gall y dangosfwrdd hefyd arddangos gwybodaeth ar gyfer staff cymorth technegol: ciw o geisiadau, rhestr o wallau blaenoriaeth uchel, a pheiriannydd penodedig ar gyfer maes cyfrifoldeb penodol.
Rhybudd (hysbysiad)
Hysbysiadau y bwriedir eu derbyn gan berson trwy e-bost neu ddulliau eraill, a allai gael eu hysgogi gan wallau neu gynnydd yn y ciw cais. Mae hysbysiadau yn cael eu dosbarthu fel: tocynnau, rhybuddion e-bost a negeseuon negesydd gwib.
Achos gwraidd
Nam meddalwedd neu wall dynol na ddylai, unwaith y caiff ei gywiro, ddigwydd eto. Efallai bod gan y broblem sawl prif achos: awtomeiddio prosesau annigonol, diffyg meddalwedd, ymhelaethu'n annigonol ar resymeg y cais. Efallai mai pob un o'r ffactorau hyn yw'r achos sylfaenol, a rhaid dileu pob un ohonynt.
Nod a pheiriant (nôd a pheiriant)
Termau ymgyfnewidiol i gyfeirio at un enghraifft o raglen redeg ar weinydd ffisegol, peiriant rhithwir, neu gynhwysydd. Gall un peiriant gynnal nifer o wasanaethau. Gall gwasanaethau fod yn:
- yn gysylltiedig â'i gilydd: er enghraifft, gweinydd caching a gweinydd gwe;
- gwasanaethau anghysylltiedig ar un darn o galedwedd: er enghraifft, ystorfa god a dewin ar gyfer system ffurfweddu, megis neu .
Gwthiwch
Unrhyw newid mewn cyfluniad meddalwedd.
Pam fod angen monitro?
Mae sawl rheswm pam mae angen monitro ceisiadau:
Dadansoddiad o dueddiadau hirdymor
Pa mor fawr yw'r gronfa ddata a pha mor gyflym y mae'n tyfu? Sut mae nifer dyddiol y defnyddwyr yn newid?
Cymhariaeth perfformiad
A yw ceisiadau yn gyflymach ar Acme Bucket of Bytes 2.72 o'i gymharu ag Ajax DB 3.14? Faint yn well y caiff ceisiadau eu storio ar ôl ymddangosiad nod ychwanegol? A yw'r safle'n rhedeg yn arafach o'i gymharu â'r wythnos ddiwethaf?
Rhybuddio
Mae rhywbeth wedi torri ac mae angen i rywun ei drwsio. Neu bydd rhywbeth yn torri'n fuan ac mae angen i rywun ei wirio'n fuan.
Creu dangosfyrddau
Dylai dangosfyrddau ateb cwestiynau sylfaenol a chynnwys rhywbeth o — oedi (latency), traffig (traffig), gwallau (gwallau) a maint llwyth (dirlawnder).
Cynnal dadansoddiad ôl-weithredol (difa chwilod)
Mae'r oedi wrth brosesu ceisiadau wedi cynyddu, ond beth arall ddigwyddodd tua'r un pryd?
Mae systemau monitro yn ddefnyddiol fel ffynhonnell data ar gyfer systemau gwybodaeth busnes ac i hwyluso dadansoddi digwyddiadau diogelwch. Gan fod y llyfr hwn yn canolbwyntio ar feysydd peirianneg y mae gan SREs arbenigedd ynddynt, ni fyddwn yn trafod technegau monitro yma.
Mae monitro a rhybuddion yn caniatáu i'r system ddweud wrthych pan fydd wedi torri i lawr neu ar fin chwalu. Pan na all system atgyweirio ei hun yn awtomatig, rydym am i ddyn ddadansoddi'r rhybudd, penderfynu a yw'r broblem yn dal i fod yn weithredol, ei datrys, a phenderfynu ar yr achos sylfaenol. Os na fyddwch yn archwilio cydrannau system, ni fyddwch byth yn derbyn rhybudd yn syml oherwydd bod "rhywbeth yn ymddangos ychydig yn rhyfedd."
Mae rhoi baich ar berson gyda hysbysiadau yn ddefnydd gweddol ddrud o amser gweithiwr. Os yw'r gweithiwr yn gweithio, mae'r rhybudd yn torri ar draws y broses waith. Os yw'r gweithiwr gartref, mae'r rhybudd yn torri ar draws amser personol ac o bosibl yn cysgu. Pan fydd rhybuddion yn digwydd yn rhy aml, mae gweithwyr yn sgimio trwyddynt, yn eu hatal, neu'n anwybyddu rhybuddion sy'n dod i mewn. O bryd i'w gilydd maent yn anwybyddu'r rhybudd go iawn, sy'n cael ei guddio gan ddigwyddiadau sŵn. Gall ymyriadau i wasanaethau bara am gyfnodau hir o amser gan fod digwyddiadau sŵn yn atal y broblem rhag cael ei diagnosio a’i chywiro’n gyflym. Mae gan systemau rhybuddio effeithiol gymhareb signal-i-sŵn dda.
Gosod disgwyliadau rhesymol ar gyfer y system fonitro
Mae sefydlu monitro ar gyfer cymhwysiad cymhleth yn dasg beirianneg gymhleth ynddo'i hun. Hyd yn oed gyda seilwaith sylweddol o offer casglu, arddangos a rhybuddio, mae tîm SRE Google o 10-12 aelod fel arfer yn cynnwys un neu ddau o bobl a'u prif ddiben yw adeiladu a chynnal systemau monitro. Mae'r nifer hwn wedi gostwng dros amser wrth i ni gyfuno a chanoli'r seilwaith monitro, ond fel arfer mae gan bob tîm ARhPh o leiaf un person sy'n ymroddedig i fonitro yn unig. Mae'n rhaid i ni ddweud, er bod dangosfyrddau systemau monitro yn eithaf diddorol i'w gwylio, mae timau ARhPh yn ofalus i osgoi sefyllfaoedd sy'n gofyn i rywun edrych ar sgrin i fonitro problemau.
Ar y cyfan, mae Google wedi symud i systemau monitro syml a chyflym gyda'r offer dadansoddi ôl-y-ffaith gorau posibl. Rydym yn osgoi systemau "hud" sy'n ceisio rhagweld trothwyon neu ganfod yr achos sylfaenol yn awtomatig. Synwyryddion sy'n canfod cynnwys anfwriadol mewn ceisiadau defnyddiwr terfynol yw'r unig wrthenghraifft; Cyn belled â bod y synwyryddion hyn yn parhau i fod yn syml, gallant ganfod yn gyflym achosion anomaleddau difrifol. Mae fformatau eraill ar gyfer defnyddio data monitro, megis cynllunio capasiti neu ragweld traffig, yn fwy cymhleth. Bydd arsylwi dros gyfnod hir iawn (misoedd neu flynyddoedd) ar gyfradd samplu isel (oriau neu ddyddiau) yn datgelu tuedd hirdymor.
Mae tîm SRE Google wedi cael llwyddiant cymysg gyda hierarchaethau dibyniaeth gymhleth. Anaml y byddwn yn defnyddio rheolau fel “os byddaf yn darganfod bod y gronfa ddata yn araf, byddaf yn cael rhybudd bod y gronfa ddata yn araf, fel arall byddaf yn cael rhybudd bod y wefan yn araf.” Mae rheolau sy'n seiliedig ar ddibyniaeth fel arfer yn cyfeirio at rannau digyfnewid o'n system, megis y system ar gyfer hidlo traffig defnyddwyr i'r ganolfan ddata. Er enghraifft, “os yw hidlo traffig i'r ganolfan ddata wedi'i ffurfweddu, peidiwch â'm rhybuddio am oedi wrth brosesu ceisiadau defnyddwyr” yn un rheol gyffredinol ar gyfer rhybuddion gan y ganolfan ddata. Ychydig iawn o dimau yn Google sy'n cefnogi hierarchaethau dibyniaeth gymhleth oherwydd bod gan ein seilwaith gyfradd gyson o ailffactorio parhaus.
Mae rhai o'r syniadau a ddisgrifir yn y bennod hon yn dal yn berthnasol: mae cyfle bob amser i symud yn gyflymach o'r symptom i'r achos gwraidd, yn enwedig mewn systemau sy'n newid yn gyson. Felly, er bod y bennod hon yn amlinellu rhai nodau ar gyfer systemau monitro a sut i gyflawni'r nodau hynny, mae'n bwysig bod systemau monitro yn syml ac yn ddealladwy i bawb ar y tîm.
Yn yr un modd, er mwyn cadw lefelau sŵn yn isel a lefelau signal yn uchel, rhaid i ddulliau monitro asedau hysbysedig fod yn syml ac yn ddibynadwy iawn. Dylai rheolau sy'n cynhyrchu rhybuddion i bobl fod yn hawdd eu deall a dylent fod yn broblem glir.
Symptomau yn erbyn achosion
Dylai eich system fonitro ateb dau gwestiwn: “beth dorrodd” a “pham y torrodd.”
Mae “Beth dorrodd” yn sôn am y symptom, a “pam y torrodd” yn sôn am yr achos. Mae'r tabl isod yn dangos enghreifftiau o gysylltiadau o'r fath.
Symptom
Achos
Cael Gwall HTTP 500 neu 404
Mae gweinyddwyr cronfa ddata yn gwrthod cysylltiadau
Ymatebion gweinydd araf
Defnydd CPU uchel neu gebl Ethernet wedi'i ddifrodi
Nid yw defnyddwyr yn Antarctica yn derbyn GIFs cath
Mae eich CDN yn casáu gwyddonwyr a chathod, felly roedd rhai cyfeiriadau IP ar y rhestr ddu yn y diwedd
Mae cynnwys preifat wedi dod ar gael o bob man
Fe wnaeth cyflwyno datganiad meddalwedd newydd wneud i'r wal dân anghofio pob ACL a gadael i bawb ddod i mewn
“Beth” a “pam” yw rhai o'r blociau adeiladu pwysicaf ar gyfer creu system fonitro dda gyda'r signal mwyaf a'r sŵn lleiaf.
Blwch du yn erbyn blwch gwyn
Rydym yn cyfuno monitro Blwch Gwyn helaeth â monitro Blwch Du cymedrol ar gyfer metrigau critigol. Y ffordd hawsaf o gymharu Black-box â White-box yw bod Black-box yn canolbwyntio ar symptomau ac yn adweithiol yn hytrach na monitro rhagweithiol: “nid yw’r system yn gweithio’n gywir ar hyn o bryd.” Mae blwch gwyn yn dibynnu ar alluoedd gwirio mewnol systemau: logiau digwyddiadau neu weinyddion gwe. Felly, mae Blwch Gwyn yn caniatáu ichi ganfod problemau sydd ar ddod, namau sy'n ymddangos fel pe baent yn ailddarllediad o gais, ac ati.
Sylwch, mewn system aml-haen, fod symptom ym maes cyfrifoldeb un peiriannydd yn symptom ym maes cyfrifoldeb peiriannydd arall. Er enghraifft, mae perfformiad cronfa ddata wedi gostwng. Mae darlleniadau cronfa ddata yn araf yn symptom o ARhPh y gronfa ddata sy'n eu canfod. Fodd bynnag, ar gyfer ARhPh pen blaen sy'n arsylwi gwefan araf, cronfa ddata araf yw achos yr un gronfa ddata araf a ddarllenir. Felly, mae monitro blwch gwyn weithiau'n canolbwyntio ar symptomau ac weithiau'n canolbwyntio ar achosion, yn dibynnu ar ba mor helaeth ydyw.
Wrth gasglu telemetreg ar gyfer dadfygio, mae angen monitro blwch gwyn. Os yw gweinyddwyr gwe yn araf i ymateb i ymholiadau cronfa ddata, mae angen i chi wybod pa mor gyflym y mae'r gweinydd gwe yn cyfathrebu â'r gronfa ddata a pha mor gyflym y mae'n ymateb. Fel arall, ni fyddwch yn gallu gwahaniaethu rhwng gweinydd cronfa ddata araf a phroblem rhwydwaith rhwng y gweinydd gwe a'r gronfa ddata.
Mae gan fonitro blwch du fantais allweddol wrth anfon rhybuddion: rydych chi'n sbarduno'r hysbysiad i'r derbynnydd pan fydd y broblem eisoes wedi arwain at symptomau go iawn. Ar y llaw arall, mae monitro yn ddiwerth ar gyfer problem Black-box nad yw wedi codi eto ond sydd ar fin digwydd.
Pedwar arwydd euraidd
Y pedwar signal monitro euraidd yw hwyrni, traffig, gwallau a dirlawnder. Os mai dim ond pedwar metrig system defnyddiwr y gallwch chi eu mesur, canolbwyntiwch ar y pedwar hynny.
Oedi
Yr amser sydd ei angen i brosesu'r cais. Mae'n bwysig gwahaniaethu rhwng hwyrni ceisiadau llwyddiannus ac aflwyddiannus. Er enghraifft, gellir canfod gwall HTTP 500 a achosir gan golli cysylltiad â chronfa ddata neu gefn arall yn gyflym iawn, fodd bynnag, gall gwall HTTP 500 nodi cais a fethodd. Gall pennu effaith gwall 500 ar hwyrni cyffredinol arwain at gasgliadau gwallus. Ar y llaw arall, mae gwall araf hyd yn oed yn gamgymeriad cyflym! Felly, mae'n bwysig monitro cuddni gwallau yn hytrach na dim ond hidlo gwallau allan.
traffig
Mae nifer y ceisiadau i'ch system yn cael ei fesur mewn metrigau system lefel uchel. Ar gyfer gwasanaeth gwe, mae'r mesuriad hwn fel arfer yn cynrychioli nifer y ceisiadau HTTP yr eiliad, wedi'u rhannu â natur y ceisiadau (er enghraifft, cynnwys statig neu ddeinamig). Ar gyfer system ffrydio sain, gall y mesuriad hwn ganolbwyntio ar gyflymder I/O rhwydwaith neu nifer y sesiynau cydamserol. Ar gyfer system storio gwerth allweddol, gallai'r mesuriad hwn fod yn drafodion neu'n ganlyniadau chwilio yr eiliad.
Gwallau
Dyma'r gyfradd o geisiadau a fethwyd sy'n eglur (ee HTTP 500), ymhlyg (ee HTTP 200 ond wedi'i gyfuno â chynnwys annilys) neu bolisi (ee "Os daliasoch ymateb mewn un eiliad, mae unrhyw eiliad yn wall"). Os nad yw codau ymateb HTTP yn ddigonol i fynegi'r holl amodau methiant, efallai y bydd angen protocolau eilaidd (mewnol) i ganfod methiant rhannol. Efallai na fydd monitro pob cais gwallus o'r fath yn addysgiadol, tra bydd profion system o'r dechrau i'r diwedd yn helpu i ganfod eich bod yn prosesu cynnwys anghywir.
Dirlawnder
Mae'r metrig yn dangos pa mor ddwys y defnyddir eich gwasanaeth. Mae hwn yn fesur monitro system sy'n nodi'r adnoddau sydd wedi'u cyfyngu fwyaf (er enghraifft, ar system â chyfyngiad cof, yn dangos cof, ar system â chyfyngiad I/O, yn dangos nifer yr I/O). Sylwch fod llawer o systemau yn diraddio perfformiad cyn iddynt gyrraedd 100% o ddefnydd, felly mae cael nod defnydd yn bwysig.
Mewn systemau cymhleth, gall dirlawnder gael ei ategu gan fesuriadau llwyth lefel uwch: a all eich gwasanaeth drin traffig dwbl yn iawn, trin dim ond 10% yn fwy o draffig, neu drin hyd yn oed llai o draffig nag y mae ar hyn o bryd? Ar gyfer gwasanaethau syml nad oes ganddynt baramedrau sy'n newid cymhlethdod y cais (er enghraifft, "Rhowch ddim i mi" neu "mae angen cyfanrif monotonig sengl unigryw arnaf"), sy'n anaml yn newid cyfluniad, gall gwerth prawf llwyth statig fod yn ddigonol. Fodd bynnag, fel y trafodwyd yn y paragraff blaenorol, rhaid i'r rhan fwyaf o wasanaethau ddefnyddio signalau anuniongyrchol, megis defnyddio CPU neu led band rhwydwaith, sydd â therfyn uchaf hysbys. Mae hwyrni cynyddol yn aml yn ddangosydd blaenllaw o dirlawnder. Gall mesur yr amser ymateb 99ain canradd mewn ffenestr fach (e.e., un funud) roi arwydd cynnar iawn o dirlawnder.
Yn olaf, mae dirlawnder hefyd yn gysylltiedig â rhagfynegiadau ynghylch dirlawnder sydd ar ddod, er enghraifft: “Mae'n edrych yn debyg y bydd eich cronfa ddata yn llenwi'ch gyriant caled mewn 4 awr.”
Os ydych chi'n mesur pob un o'r pedwar signal euraidd a phan fydd problem gydag un o'r metrigau (neu, yn achos dirlawnder, problem agos), rydych chi'n rhybuddio person, bydd eich gwasanaeth yn cael ei gwmpasu fwy neu lai gan fonitro.
Poeni am y "gynffon" (neu offeryniaeth a pherfformiad)
Wrth greu system fonitro o'r dechrau, mae yna demtasiwn i ddatblygu system yn seiliedig ar werthoedd cyfartalog: hwyrni cyfartalog, defnydd CPU cyfartalog o nodau, neu gyflawnder cronfa ddata ar gyfartaledd. Mae perygl y ddwy enghraifft olaf yn amlwg: mae proseswyr a chronfeydd data yn cael eu gwaredu mewn ffordd anrhagweladwy iawn. Mae'r un peth yn wir am oedi. Os ydych yn rhedeg gwasanaeth gwe gyda 100m yn hwyr ar gyfartaledd gyda 1000 o geisiadau yr eiliad, gallai 1% o geisiadau gymryd 5 eiliad. Os yw defnyddwyr yn dibynnu ar wasanaethau gwe lluosog o'r fath, gall y 99fed canradd o un ôl-wyneb ddod yn amser ymateb canolrifol y pen blaen yn hawdd.
Y ffordd symlaf o wahaniaethu rhwng y cyfartaledd araf a chynffon araf iawn y ceisiadau yw casglu mesuriadau o geisiadau a fynegir mewn ystadegau (offeryn da i'w arddangos yw histogramau) yn hytrach na hwyrni gwirioneddol: faint o geisiadau a wasanaethwyd gan y gwasanaeth a gymerodd rhwng 0 ms a 10 ms, rhwng 10 ms a 30 ms, rhwng 30 ms a 100 ms, rhwng 100 ms a 300 ms, ac ati. Yn aml, mae ehangu ffiniau'r histogram yn esbonyddol (gan ffactor bras o 3) yn ffordd syml o geisiadau.
Dewis y lefel briodol o fanylder ar gyfer mesuriadau
Rhaid mesur gwahanol elfennau o'r system ar wahanol lefelau o fanylder. Er enghraifft:
- Ni fydd monitro defnydd CPU dros gyfnod o amser yn dangos pigau hirdymor sy'n arwain at guddfannau uchel.
- Ar y llaw arall, ar gyfer gwasanaeth gwe sy'n targedu dim mwy na 9 awr o amser segur y flwyddyn (99,9% uptime blynyddol), mae gwirio am ymateb HTTP 200 fwy nag unwaith neu ddwywaith y funud yn debygol o fod yn ddiangen o aml.
- Yn yr un modd, mae'n debyg nad oes angen gwirio lle ar y gyriant caled am 99,9% o argaeledd fwy nag unwaith bob 1-2 funud.
Byddwch yn ofalus sut rydych chi'n strwythuro gronynnedd eich mesuriadau. Gall casglu llwyth CPU unwaith yr eiliad ddarparu data diddorol, ond gall mesuriadau aml o'r fath fod yn ddrud iawn i'w casglu, eu storio a'u dadansoddi. Os yw eich nod monitro yn gofyn am ronynnedd uchel ac nad oes angen ymatebolrwydd uchel, gallwch leihau'r costau hyn trwy sefydlu casgliad metrigau ar y gweinydd ac yna sefydlu system allanol i gasglu a chyfuno'r metrigau hynny. Allech chi:
- Mesur llwyth CPU bob eiliad.
- Lleihau manylion i 5%.
- Metrigau cyfanredol bob munud.
Bydd y strategaeth hon yn eich galluogi i gasglu data ar ronynnedd uchel heb fynd i ddadansoddiad uchel a storio uwchben.
Mor syml â phosibl, ond nid yn symlach
Gall troshaenu gwahanol ofynion ar ben ei gilydd arwain at system fonitro gymhleth iawn. Er enghraifft, efallai y bydd gan eich system yr elfennau cymhlethu canlynol:
- Rhybuddion yn ôl gwahanol drothwyon ar gyfer hwyrni prosesu ceisiadau, mewn gwahanol ganraddau, ar gyfer pob math o wahanol ddangosyddion.
- Ysgrifennu cod ychwanegol i ganfod a nodi achosion posibl.
- Creu dangosfyrddau cysylltiedig ar gyfer pob un o achosion posibl problemau.
Nid yw ffynonellau cymhlethdodau posibl byth yn dod i ben. Fel pob system feddalwedd, gall monitro fod mor gymhleth fel ei fod yn dod yn fregus ac yn anodd ei newid a'i gynnal.
Felly, dyluniwch eich system fonitro i'w symleiddio cymaint â phosibl. Wrth ddewis beth i'w olrhain, cadwch y canlynol mewn cof:
- Dylai'r rheolau sy'n dal digwyddiadau go iawn amlaf fod mor syml, rhagweladwy a dibynadwy â phosibl.
- Dylid dileu ffurfweddiad ar gyfer casglu data, agregu, a rhybuddio sy'n cael ei berfformio'n anaml (er enghraifft, llai na chwarterol ar gyfer rhai timau ARhPh).
- Mae metrigau a gesglir ond nas dangosir mewn unrhyw ddangosfwrdd rhagolwg neu a ddefnyddir gan unrhyw rybudd yn ymgeiswyr i'w dileu.
Yn Google, mae casglu a chyfuno metrigau sylfaenol, ynghyd â rhybuddion a dangosfyrddau, yn gweithio'n dda fel system gymharol annibynnol (mewn gwirionedd mae system fonitro Google wedi'i rhannu'n sawl is-system, ond mae pobl fel arfer yn ymwybodol o bob agwedd ar yr is-systemau hyn). Gall fod yn demtasiwn cyfuno monitro â thechnegau eraill ar gyfer archwilio systemau cymhleth: proffilio system manwl, dadfygio prosesau, olrhain manylion am eithriadau neu fethiannau, profi llwythi, casglu a dadansoddi logiau, neu archwilio traffig. Er bod y rhan fwyaf o'r pethau hyn yn gyffredin â monitro sylfaenol, bydd eu cymysgu â'i gilydd yn arwain at ormod o ganlyniadau ac yn creu system gymhleth a bregus. Fel gyda llawer o agweddau eraill ar ddatblygu meddalwedd, cefnogi systemau gwahanol gyda phwyntiau integreiddio clir, syml, llac yw'r strategaeth orau (er enghraifft, defnyddio API gwe i adalw data cyfanredol mewn fformat a all aros yn gyson dros gyfnod hir o amser ).
Clymu'r Egwyddorion Ynghyd
Gellir cyfuno'r egwyddorion a drafodir yn y bennod hon yn athroniaeth monitro a rhybuddio sy'n cael ei chymeradwyo a'i dilyn gan dimau SRE Google. Mae cadw at yr athroniaeth fonitro hon yn ddymunol, mae'n fan cychwyn da ar gyfer creu neu adolygu eich methodoleg rhybuddio, a gall eich helpu i ofyn y cwestiynau cywir am eich swyddogaeth gweithrediadau, waeth beth fo maint eich sefydliad neu gymhlethdod y gwasanaeth neu'r system.
Wrth greu rheolau monitro a rhybuddio, gall gofyn y cwestiynau canlynol eich helpu i osgoi pethau cadarnhaol ffug a rhybuddion diangen:
- A yw'r rheol hon yn canfod cyflwr y system na ellir ei ganfod fel arall sy'n frys, galwadau i weithredu, ac sy'n effeithio'n anochel ar y defnyddiwr?
- A gaf i anwybyddu'r rhybudd hwn gan wybod ei fod yn ddiniwed? Pryd a pham y gallaf anwybyddu'r rhybudd hwn a sut y gallaf osgoi'r senario hwn?
- A yw'r rhybudd hwn yn golygu bod defnyddwyr yn cael eu heffeithio'n negyddol? A oes sefyllfaoedd lle nad yw defnyddwyr yn cael eu heffeithio'n negyddol, megis hidlo traffig trwodd neu wrth ddefnyddio systemau prawf y dylid hidlo rhybuddion ar eu cyfer?
- A gaf i weithredu mewn ymateb i'r rhybudd hwn? A yw'r mesurau hyn yn rhai brys neu a allant aros tan y bore? A ellir awtomeiddio'r weithred yn ddiogel? A fydd y cam hwn yn ateb hirdymor neu'n ateb tymor byr?
- Mae rhai pobl yn cael rhybuddion lluosog ar gyfer y mater hwn, felly a oes ffordd i leihau nifer y rhybuddion?
Mae'r cwestiynau hyn yn adlewyrchu'r athroniaeth sylfaenol ar systemau rhybuddio:
- Bob tro y daw rhybudd i mewn, mae'n rhaid i mi ymateb ar unwaith. Gallaf ymateb ar frys sawl gwaith y dydd cyn i mi flino.
- Rhaid i bob rhybudd fod yn berthnasol.
- Rhaid i bob ymateb i rybudd fod angen ymyrraeth ddynol. Os gellir prosesu'r hysbysiad yn awtomatig, ni ddylai gyrraedd.
- Dylai rhybuddion fod yn ymwneud â phroblem neu ddigwyddiad newydd nad oedd yn bodoli o'r blaen.
Mae'r dull hwn yn cymylu rhai gwahaniaethau: os yw'r rhybudd yn bodloni'r pedwar amod blaenorol, nid oes ots a yw'r rhybudd yn cael ei anfon o system fonitro Blwch Gwyn neu Black-Box. Mae'r dull hwn hefyd yn atgyfnerthu rhai gwahaniaethau: mae'n well gwario llawer mwy o ymdrech ar adnabod symptomau nag ar achosion; o ran achosion, dim ond am yr achosion anochel y mae angen i chi boeni.
Monitro tymor hir
Yn amgylcheddau cynhyrchiant heddiw, mae systemau monitro yn monitro system gynhyrchu sy'n esblygu'n barhaus gyda phensaernïaeth meddalwedd newidiol, nodweddion llwyth gwaith, a thargedau perfformiad. Gall rhybuddion sy'n anodd eu hawtomeiddio ar hyn o bryd ddod yn gyffredin, efallai hyd yn oed yn werth mynd i'r afael â nhw. Ar y pwynt hwn, rhaid i rywun ddarganfod a dileu achosion sylfaenol y broblem; os nad yw datrysiad o'r fath yn bosibl, mae angen awtomeiddio llawn ar yr ymateb i'r rhybudd.
Mae'n bwysig bod penderfyniadau monitro yn cael eu gwneud gyda nodau hirdymor mewn golwg. Mae pob rhybudd sy'n rhedeg heddiw yn tynnu sylw person oddi wrth wella'r system yfory, felly yn aml mae gostyngiad yn argaeledd neu berfformiad system gynhyrchiol am yr amser sydd ei angen i wella'r system fonitro yn y tymor hir. Edrychwn ar ddwy enghraifft i ddangos y ffenomen hon.
ARhPh Bigtable: Hanes Gor-Effro
Mae seilwaith mewnol Google fel arfer yn cael ei ddarparu a'i fesur yn erbyn lefel gwasanaeth (SLO). Flynyddoedd lawer yn ôl, roedd SLO gwasanaeth Bigtable yn seiliedig ar berfformiad cyfartalog trafodiad synthetig yn efelychu cleient byw. Oherwydd problemau yn Bigtable a lefelau is o'r pentwr storio, roedd perfformiad cyfartalog yn cael ei yrru gan gynffon "fawr": roedd y 5% gwaethaf o ymholiadau yn aml yn sylweddol arafach na'r gweddill.
Anfonwyd hysbysiadau e-bost wrth agosáu at y trothwy SLO, ac anfonwyd rhybuddion negesydd pan eid y tu hwnt i'r SLO. Anfonwyd y ddau fath o rybuddion yn weddol aml, gan gymryd symiau annerbyniol o amser peirianneg: treuliodd y tîm gryn dipyn o amser yn didoli'r rhybuddion i ddod o hyd i'r ychydig oedd yn berthnasol mewn gwirionedd. Roeddem yn aml yn methu mater a oedd yn effeithio ar ddefnyddwyr mewn gwirionedd oherwydd dim ond rhai o'r rhybuddion oedd ar gyfer y mater penodol hwnnw. Nid oedd llawer o'r rhybuddion yn rhai brys oherwydd problemau dealladwy yn y seilwaith ac fe'u proseswyd mewn ffordd safonol, neu ni chawsant eu prosesu o gwbl.
I unioni'r sefyllfa, cymerodd y tîm ymagwedd driphlyg: Wrth weithio'n galed i wella perfformiad Bigtable, fe wnaethom osod ein nod SLO dros dro i fod y 75ain canradd ar gyfer hwyrni ymateb i ymholiad. Fe wnaethom hefyd ddiffodd rhybuddion e-bost oherwydd bod cymaint ohonynt fel ei bod yn amhosibl treulio amser yn gwneud diagnosis ohonynt.
Roedd y strategaeth hon yn caniatáu'r ystafell anadlu i ni ddechrau trwsio materion hirdymor yn Bigtable a haenau isaf y pentwr storio, yn hytrach na thrwsio materion tactegol yn gyson. Gallai peirianwyr gael gwaith wedi'i wneud heb gael eu peledu â rhybuddion drwy'r amser. Yn y pen draw, fe wnaeth gohirio prosesu rhybuddion dros dro ein galluogi i wella ansawdd ein gwasanaeth.
Gmail: Ymatebion Dynol Algorithmig Rhagweladwy
Ar y dechrau, roedd Gmail wedi'i adeiladu ar system rheoli prosesau Workqueue wedi'i haddasu a ddyluniwyd i grynhoi darnau proses o fynegai chwilio. Addaswyd Workqueue i brosesau hirhoedlog a'i gymhwyso wedyn i Gmail, ond bu'n anodd iawn trwsio rhai bygiau yn y cod amserlennu afloyw.
Ar y pryd, roedd monitro Gmail wedi'i strwythuro fel y byddai rhybuddion yn cael eu sbarduno pan fyddai tasgau unigol yn cael eu canslo gan ddefnyddio Workqueue. Nid oedd y dull hwn yn ddelfrydol, oherwydd hyd yn oed bryd hynny, cyflawnodd Gmail filoedd lawer o dasgau, a darparwyd pob un ohonynt i ffracsiwn o ganran o'n defnyddwyr. Roeddem yn bryderus iawn am ddarparu profiad defnyddiwr da i ddefnyddwyr Gmail, ond roedd trin cymaint o rybuddion allan o gyrraedd.
Er mwyn mynd i'r afael â'r mater hwn, creodd Gmail SRE offeryn i helpu i ddadfygio'r rhaglennydd orau â phosibl i leihau'r effaith ar ddefnyddwyr. Cafodd y tîm rai trafodaethau ynghylch a ddylid awtomeiddio'r cylch cyfan o ddarganfod problemau i adferiad hyd nes y canfyddir ateb hirdymor, ond roedd rhai yn pryderu y byddai datrysiad o'r fath yn gohirio datrys y broblem mewn gwirionedd.
Roedd y tensiwn hwn yn gyffredin yn y tîm ac yn aml yn adlewyrchu diffyg ymddiriedaeth mewn hunanddisgyblaeth: er bod rhai aelodau tîm eisiau caniatáu amser ar gyfer yr atgyweiriad cywir, mae eraill yn poeni y bydd yr atgyweiriad terfynol yn cael ei anghofio ac y bydd yr atgyweiriad dros dro yn cymryd am byth. Mae'r mater hwn yn haeddu sylw oherwydd mae'n rhy hawdd trwsio problemau dros dro yn hytrach na gwneud y sefyllfa'n barhaol. Mae rheolwyr a staff technegol yn chwarae rhan allweddol wrth roi atebion hirdymor ar waith, gan gefnogi a blaenoriaethu atebion hirdymor posibl hyd yn oed ar ôl i'r “boen” gychwynnol gilio.
Dylai rhybuddion rheolaidd, ailadroddus ac ymatebion algorithmig fod yn faner goch. Mae amharodrwydd eich tîm i awtomeiddio'r rhybuddion hyn yn golygu nad oes gan y tîm hyder y gallant ymddiried yn yr algorithmau. Mae hon yn broblem ddifrifol y mae angen mynd i’r afael â hi.
Tymor hir
Mae thema gyffredin yn cysylltu enghreifftiau Bigtable a Gmail: y gystadleuaeth rhwng argaeledd tymor byr a thymor hir. Yn aml, gall ymdrech gref helpu system fregus i sicrhau argaeledd uchel, ond mae'r llwybr hwn fel arfer yn fyrhoedlog, yn llawn bwrlwm tîm a dibyniaeth ar nifer fach o aelodau o'r un tîm arwrol hwnnw.
Mae gostyngiad rheoledig, tymor byr mewn argaeledd yn aml yn boenus, ond yn strategol bwysig ar gyfer sefydlogrwydd hirdymor y system. Mae'n bwysig peidio ag edrych ar bob rhybudd ar ei ben ei hun, ond ystyried a yw lefel gyffredinol y nifer o rybuddion yn arwain at system iach, hygyrch iawn gyda thîm hyfyw a phrognosis ffafriol. Rydym yn dadansoddi ystadegau amlder rhybuddion (a fynegir fel arfer fel digwyddiadau fesul sifft, lle gall digwyddiad gynnwys digwyddiadau cysylltiedig lluosog) mewn adroddiadau chwarterol i reolwyr, gan ganiatáu i benderfynwyr gael golwg barhaus ar lwyth y system rybuddio ac iechyd cyffredinol y tîm.
Casgliad
Mae'r llwybr i fonitro a rhybuddio iach yn syml ac yn glir. Mae'n canolbwyntio ar symptomau'r broblem sy'n sbarduno rhybuddion, ac mae monitro'r achos yn gymorth i broblemau dadfygio. Mae monitro symptomau yn haws po uchaf yr ydych yn y pentwr rydych yn ei reoli, er y dylid monitro llwyth a pherfformiad y gronfa ddata yn uniongyrchol ar y gronfa ddata ei hun. Mae defnyddioldeb hysbysiadau e-bost yn gyfyngedig iawn ac yn dueddol o ddod yn sŵn yn hawdd; yn lle hynny, dylech ddefnyddio dangosfwrdd sy'n monitro'r holl faterion cyfredol sy'n sbarduno rhybuddion e-bost. Gellir paru'r dangosfwrdd hefyd â log digwyddiad i ddadansoddi cydberthnasau hanesyddol.
Yn y tymor hir, mae angen cyflawni cylchdro llwyddiannus o rybuddion am symptomau a phroblemau gwirioneddol sydd ar ddod, gan addasu nodau i sicrhau bod monitro yn cefnogi diagnosis cyflym.
Diolch am ddarllen y cyfieithiad hyd y diwedd. Tanysgrifiwch i'm sianel telegram am fonitro и .
Ffynhonnell: hab.com