Ydy monitro wedi marw? — Monitro byw hir

Ers 2008, mae ein cwmni wedi bod yn ymwneud yn bennaf â rheoli seilwaith a chymorth technegol rownd y cloc ar gyfer prosiectau gwe: mae gennym fwy na 400 o gleientiaid, sef tua 15% o e-fasnach Rwsia. Yn unol â hynny, cefnogir pensaernïaeth amrywiol iawn. Os bydd rhywbeth yn disgyn, mae'n rhaid i ni ei drwsio o fewn 15 munud. Ond i ddeall bod damwain wedi digwydd, mae angen i chi fonitro'r prosiect ac ymateb i ddigwyddiadau. Sut i wneud hyn?

Credaf fod problem o ran trefnu system fonitro gywir. Pe na bai unrhyw drafferth wedi bod, yna byddai fy araith yn cynnwys un traethawd ymchwil: “Gosodwch Prometheus + Grafana ac ategion 1, 2, 3.” Yn anffodus, nid yw'n gweithio felly mwyach. A'r brif broblem yw bod pawb yn parhau i gredu mewn rhywbeth a fodolai yn 2008, o ran cydrannau meddalwedd.

O ran trefniadaeth y system fonitro, byddwn yn mentro dweud... nad oes prosiectau â monitro cymwys yn bodoli. Ac mae’r sefyllfa mor ddrwg, os bydd rhywbeth yn disgyn, mae risg y bydd yn mynd heb i neb sylwi – wedi’r cyfan, mae pawb yn siŵr bod “popeth yn cael ei fonitro.”
Efallai bod popeth yn cael ei fonitro. Ond sut?

Rydyn ni i gyd wedi dod ar draws stori fel y canlynol: rhai devops, mae gweinyddwr penodol yn gweithio, mae tîm datblygu yn dod atyn nhw ac yn dweud - "rydyn ni'n cael ein rhyddhau, nawr yn monitro." Monitro beth? Sut mae'n gweithio?

IAWN. Rydyn ni'n monitro'r ffordd hen ffasiwn. Ac mae eisoes yn newid, ac mae'n troi allan eich bod yn monitro gwasanaeth A, a ddaeth yn wasanaeth B, sy'n rhyngweithio â gwasanaeth C. Ond mae'r tîm datblygu yn dweud wrthych: "Gosodwch y feddalwedd, dylai fonitro popeth!"

Felly beth sydd wedi newid? - Mae popeth wedi newid!

2008 Mae popeth yn iawn

Mae yna un neu ddau o ddatblygwyr, un gweinydd, un gweinydd cronfa ddata. Mae'r cyfan yn mynd o fan hyn. Mae gennym rywfaint o wybodaeth, rydym yn gosod zabbix, Nagios, cacti. Ac yna rydym yn gosod rhybuddion clir ar y CPU, ar weithrediad disg, ac ar ofod disg. Rydym hefyd yn gwneud cwpl o wiriadau â llaw i sicrhau bod y wefan yn ymateb a bod archebion yn cyrraedd y gronfa ddata. A dyna ni – rydyn ni wedi ein hamddiffyn fwy neu lai.

Os byddwn yn cymharu faint o waith a wnaeth y gweinyddwr bryd hynny i ddarparu monitro, yna roedd 98% ohono'n awtomatig: rhaid i'r sawl sy'n monitro ddeall sut i osod Zabbix, sut i'w ffurfweddu a ffurfweddu rhybuddion. A 2% - ar gyfer gwiriadau allanol: bod y wefan yn ymateb ac yn gwneud cais i'r gronfa ddata, bod archebion newydd wedi cyrraedd.

2010 Mae'r llwyth yn tyfu

Rydym yn dechrau graddio'r we, gan ychwanegu peiriant chwilio. Rydym am sicrhau bod y catalog cynnyrch yn cynnwys yr holl gynhyrchion. Ac mae'r chwiliad cynnyrch hwnnw'n gweithio. Bod y gronfa ddata yn gweithio, bod archebion yn cael eu gwneud, bod y wefan yn ymateb yn allanol ac yn ymateb gan ddau weinyddwr ac nad yw'r defnyddiwr yn cael ei gicio allan o'r wefan tra ei fod yn cael ei ail-gydbwyso i weinydd arall, ac ati. Mae mwy o endidau.

Ar ben hynny, mae'r endid sy'n gysylltiedig â seilwaith yn parhau i fod yr un mwyaf ym mhen y rheolwr. Mae yna syniad o hyd yn fy mhen mai'r person sy'n gwneud y monitro yw'r person a fydd yn gosod zabbix ac yn gallu ei ffurfweddu.

Ond ar yr un pryd, mae gwaith yn ymddangos ar gynnal gwiriadau allanol, ar greu set o sgriptiau ymholiad mynegeiwr chwilio, set o sgriptiau i wirio bod y chwiliad yn newid yn ystod y broses mynegeio, set o sgriptiau sy'n gwirio bod nwyddau'n cael eu trosglwyddo i'r gwasanaeth dosbarthu, ac ati. ac yn y blaen.

Nodyn: Ysgrifennais “set o sgriptiau” 3 gwaith. Hynny yw, nid y person sy'n gyfrifol am fonitro yw'r un sy'n gosod zabbix yn unig. Dyma berson sy'n dechrau codio. Ond does dim byd wedi newid ym meddyliau’r tîm eto.

Ond mae'r byd yn newid, gan ddod yn fwyfwy cymhleth. Ychwanegir haen rhithwiroli a sawl system newydd. Maent yn dechrau rhyngweithio â'i gilydd. Pwy ddywedodd “yn arogli fel microservices?” Ond mae pob gwasanaeth yn dal i edrych fel gwefan yn unigol. Gallwn droi ato a deall ei fod yn darparu'r wybodaeth angenrheidiol ac yn gweithio ar ei ben ei hun. Ac os ydych chi'n weinyddwr sy'n ymwneud yn gyson â phrosiect sydd wedi bod yn datblygu ers 5-7-10 mlynedd, mae'r wybodaeth hon yn cronni: mae lefel newydd yn ymddangos - fe wnaethoch chi ei sylweddoli, mae lefel arall yn ymddangos - fe wnaethoch chi sylweddoli hynny ...

Ond anaml y bydd unrhyw un yn dod gyda phrosiect am 10 mlynedd.

Crynodeb y dyn monitro

Tybiwch eich bod wedi dod i gwmni cychwyn newydd a logodd 20 o ddatblygwyr ar unwaith, a ysgrifennodd 15 microwasanaeth, a'ch bod yn weinyddwr y dywedir wrtho: “Adeiladu CI/CD. Os gwelwch yn dda." Rydych chi wedi adeiladu CI/CD ac yn sydyn rydych chi'n clywed: “Mae'n anodd i ni weithio gyda chynhyrchu mewn “ciwb”, heb ddeall sut bydd y rhaglen yn gweithio ynddo. Gwnewch flwch tywod i ni yn yr un “ciwb”.
Rydych chi'n gwneud blwch tywod yn y ciwb hwn. Maen nhw'n dweud wrthych chi ar unwaith: “Rydyn ni eisiau cronfa ddata llwyfan sy'n cael ei diweddaru bob dydd o'r cynhyrchiad, fel ein bod ni'n deall ei fod yn gweithio ar y gronfa ddata, ond nid ar yr un pryd yn difetha'r gronfa ddata cynhyrchu.”

Rydych chi'n byw yn hyn i gyd. Mae 2 wythnos ar ôl cyn y datganiad, maen nhw'n dweud wrthych chi: “Nawr gadewch i ni fonitro hyn i gyd…” Hynny yw. monitro seilwaith y clwstwr, monitro pensaernïaeth y microwasanaeth, monitro gwaith gyda gwasanaethau allanol...

Ac mae fy nghydweithwyr yn cymryd y cynllun arferol allan o’u pennau ac yn dweud: “Wel, mae popeth yn glir yma! Gosodwch raglen a fydd yn monitro hyn i gyd.” Ie, ydy: Prometheus + Grafana + ategion.
Ac maen nhw'n ychwanegu: “Mae gennych chi bythefnos, gwnewch yn siŵr bod popeth yn ddiogel.”

Mewn llawer o brosiectau a welwn, neilltuir un person ar gyfer monitro. Dychmygwch ein bod am logi person i wneud monitro am 2 wythnos, ac rydym yn ysgrifennu crynodeb iddo. Pa sgiliau ddylai fod gan y person hwn, o ystyried popeth rydyn ni wedi'i ddweud hyd yn hyn?

• Rhaid iddo ddeall monitro a manylion gweithrediad y seilwaith haearn.
• Rhaid iddo ddeall manylion monitro Kubernetes (ac mae pawb eisiau mynd i'r "ciwb", oherwydd gallwch chi dynnu o bopeth, cuddio, oherwydd bydd y gweinyddwr yn delio â'r gweddill) - ei hun, ei seilwaith, a deall sut i fonitro cymwysiadau tu mewn.
• Rhaid iddo ddeall bod gwasanaethau'n cyfathrebu â'i gilydd mewn ffyrdd arbennig, a gwybod sut mae gwasanaethau'n rhyngweithio â'i gilydd. Mae’n ddigon posibl gweld prosiect lle mae rhai gwasanaethau’n cyfathrebu’n gydamserol, oherwydd nid oes unrhyw ffordd arall. Er enghraifft, mae'r backend yn mynd trwy REST, trwy gRPC i'r gwasanaeth catalog, yn derbyn rhestr o gynhyrchion ac yn ei dychwelyd yn ôl. Ni allwch aros yma. A chyda gwasanaethau eraill mae'n gweithio'n anghydamserol. Trosglwyddo'r archeb i'r gwasanaeth dosbarthu, anfon llythyr, ac ati.
  Mae'n debyg eich bod eisoes wedi nofio o hyn i gyd? A daeth y gweinyddwr, sydd angen monitro hyn, yn fwy dryslyd fyth.
• Rhaid iddo allu cynllunio a chynllunio yn gywir - wrth i'r gwaith ddod yn fwyfwy.
• Rhaid iddo felly greu strategaeth o’r gwasanaeth a grëwyd er mwyn deall sut i’w fonitro’n benodol. Mae arno angen dealltwriaeth o bensaernïaeth y prosiect a'i ddatblygiad + dealltwriaeth o'r technolegau a ddefnyddir wrth ddatblygu.

Gadewch i ni gofio achos cwbl arferol: mae rhai gwasanaethau yn PHP, mae rhai gwasanaethau yn Go, mae rhai gwasanaethau yn JS. Maen nhw rhywsut yn gweithio gyda'i gilydd. Dyma o ble mae’r term “microwasanaeth” yn dod: mae cymaint o systemau unigol na all datblygwyr ddeall y prosiect yn ei gyfanrwydd. Mae un rhan o'r tîm yn ysgrifennu gwasanaethau yn JS sy'n gweithio ar eu pen eu hunain ac nad ydynt yn gwybod sut mae gweddill y system yn gweithio. Mae'r rhan arall yn ysgrifennu gwasanaethau yn Python ac nid yw'n ymyrryd â sut mae gwasanaethau eraill yn gweithio; maent wedi'u hynysu yn eu hardal eu hunain. Y trydydd yw ysgrifennu gwasanaethau yn PHP neu rywbeth arall.
Mae'r 20 o bobl hyn i gyd wedi'u rhannu'n 15 gwasanaeth, a dim ond un gweinyddwr sy'n gorfod deall hyn i gyd. Stopiwch! Rydym yn rhannu’r system yn 15 meicrowasanaeth oherwydd ni all 20 o bobl ddeall y system gyfan.

Ond mae angen ei fonitro rywsut...

Beth yw'r canlyniad? O ganlyniad, mae yna un person sy'n cynnig popeth na all y tîm cyfan o ddatblygwyr ei ddeall, ac ar yr un pryd mae'n rhaid iddo hefyd wybod a gallu gwneud yr hyn a nodwyd gennym uchod - seilwaith caledwedd, seilwaith Kubernetes, ac ati.

Beth alla i ei ddweud... Houston, mae gennym ni broblemau.

Mae monitro prosiect meddalwedd modern yn brosiect meddalwedd ynddo'i hun

O'r gred ffug mai meddalwedd yw monitro, rydym yn datblygu cred mewn gwyrthiau. Ond nid yw gwyrthiau, gwaetha'r modd, yn digwydd. Ni allwch osod zabbix a disgwyl i bopeth weithio. Does dim pwynt gosod Grafana a gobeithio y bydd popeth yn iawn. Bydd y rhan fwyaf o'r amser yn cael ei dreulio ar drefnu gwiriadau o weithrediad gwasanaethau a'u rhyngweithio â'i gilydd, gan wirio sut mae systemau allanol yn gweithio. Yn wir, bydd 90% o'r amser yn cael ei dreulio nid ar ysgrifennu sgriptiau, ond ar ddatblygu meddalwedd. A dylai gael ei drin gan dîm sy'n deall gwaith y prosiect.
Os yn y sefyllfa hon mae un person yn cael ei daflu i fonitro, yna bydd trychineb yn digwydd. Sef beth sy'n digwydd ym mhobman.

Er enghraifft, mae yna nifer o wasanaethau sy'n cyfathrebu â'i gilydd trwy Kafka. Cyrhaeddodd y gorchymyn, anfonwyd neges am yr archeb i Kafka. Mae yna wasanaeth sy'n gwrando ar wybodaeth am yr archeb ac yn cludo'r nwyddau. Mae yna wasanaeth sy'n gwrando ar wybodaeth am yr archeb ac yn anfon llythyr at y defnyddiwr. Ac yna mae llawer mwy o wasanaethau'n ymddangos, ac rydyn ni'n dechrau drysu.

Ac os ydych chi hefyd yn rhoi hwn i'r gweinyddwr a'r datblygwyr ar y cam pan fo amser byr ar ôl cyn y rhyddhau, bydd angen i'r person ddeall y protocol cyfan hwn. Y rhai. Mae prosiect o'r maint hwn yn cymryd cryn dipyn o amser, a dylid ystyried hyn wrth ddatblygu'r system.
Ond yn aml iawn, yn enwedig mewn busnesau newydd, gwelwn sut y caiff monitro ei ohirio tan yn ddiweddarach. “Nawr byddwn yn gwneud Prawf Cysyniad, byddwn yn lansio gydag ef, yn gadael iddo ddisgyn - rydym yn barod i aberthu. Ac yna byddwn yn monitro'r cyfan. ” Pan (neu os) mae'r prosiect yn dechrau gwneud arian, mae'r busnes am ychwanegu hyd yn oed mwy o nodweddion - oherwydd ei fod wedi dechrau gweithio, felly mae angen ei gyflwyno ymhellach! Ac rydych chi ar y pwynt lle mae angen i chi fonitro popeth yn flaenorol, sy'n cymryd nid 1% o'r amser, ond llawer mwy. A chyda llaw, bydd angen datblygwyr ar gyfer monitro, ac mae'n haws gadael iddynt weithio ar nodweddion newydd. O ganlyniad, mae nodweddion newydd yn cael eu hysgrifennu, mae popeth yn cael ei chwalu, ac rydych mewn sefyllfa ddiddiwedd.

Felly sut i fonitro prosiect sy'n dechrau o'r dechrau, a beth i'w wneud os ydych chi'n cael prosiect y mae angen ei fonitro, ond nad ydych chi'n gwybod ble i ddechrau?

Yn gyntaf, mae angen i chi gynllunio.

Digression telynegol: yn aml iawn maent yn dechrau gyda monitro seilwaith. Er enghraifft, mae gennym Kubernetes. Gadewch i ni ddechrau trwy osod Prometheus gyda Grafana, gosod ategion ar gyfer monitro'r “ciwb”. Nid yn unig datblygwyr, ond hefyd gweinyddwyr sydd â'r arfer anffodus o: "Byddwn yn gosod yr ategyn hwn, ond mae'n debyg bod yr ategyn yn gwybod sut i'w wneud." Mae pobl yn hoffi dechrau gyda'r syml a'r syml, yn hytrach na'r camau gweithredu pwysig. Ac mae monitro seilwaith yn hawdd.

Yn gyntaf, penderfynwch beth a sut rydych chi am ei fonitro, ac yna dewiswch offeryn, oherwydd ni all pobl eraill feddwl i chi. Ac a ddylen nhw? Roedd pobl eraill yn meddwl iddyn nhw eu hunain, am system gyffredinol - neu ddim yn meddwl o gwbl pan ysgrifennwyd yr ategyn hwn. Ac nid yw'r ffaith bod gan yr ategyn hwn 5 mil o ddefnyddwyr yn golygu ei fod o unrhyw ddefnydd. Efallai mai chi fydd y 5001fed dim ond oherwydd bod 5000 o bobl yno o'r blaen yn barod.

Os byddwch chi'n dechrau monitro'r seilwaith a bod cefn eich cais yn peidio ag ymateb, bydd pob defnyddiwr yn colli cysylltiad â'r rhaglen symudol. Bydd gwall yn ymddangos. Byddan nhw'n dod atoch chi ac yn dweud “Nid yw'r cais yn gweithio, beth ydych chi'n ei wneud yma?” - “Rydyn ni'n monitro.” — “Sut ydych chi'n monitro os na welwch nad yw'r cais yn gweithio?!”

1. Credaf fod angen i chi ddechrau monitro yn union o bwynt mynediad y defnyddiwr. Os nad yw'r defnyddiwr yn gweld bod y rhaglen yn gweithio, dyna ni, mae'n fethiant. A dylai'r system fonitro rybuddio am hyn yn gyntaf.
2. A dim ond wedyn y gallwn fonitro'r seilwaith. Neu ei wneud ochr yn ochr. Mae'n haws gyda seilwaith - yma o'r diwedd gallwn osod zabbix.
3. Ac yn awr mae angen i chi fynd at wreiddiau'r cais i ddeall lle nad yw pethau'n gweithio.

Fy mhrif syniad yw y dylai monitro fynd ochr yn ochr â'r broses ddatblygu. Os byddwch yn tynnu sylw'r tîm monitro at dasgau eraill (creu CI/CD, bocsio tywod, ad-drefnu seilwaith), bydd monitro'n dechrau llusgo ac efallai na fyddwch byth yn dal i fyny â'r datblygiad (neu'n hwyr neu'n hwyrach bydd yn rhaid i chi ei atal).

Popeth yn ôl lefelau

Dyma sut yr wyf yn gweld trefniadaeth system fonitro.

1) Lefel cais:

• monitro rhesymeg busnes cais;
• monitro metrigau iechyd gwasanaethau;
• monitro integreiddio.

2) Lefel Isadeiledd:

• monitro lefel cerddorfaol;
• monitro meddalwedd system;
• monitro lefel haearn.

3) Eto lefel y cais - ond fel cynnyrch peirianneg:

• casglu a monitro cofnodion ceisiadau;
• APM;
• olrhain.

4) Rhybuddio:

• trefnu system rybuddio;
• trefnu system ddyletswydd;
• trefnu “sylfaen wybodaeth” a llif gwaith ar gyfer prosesu digwyddiadau.

Mae'n bwysig: rydym yn cyrraedd y rhybudd nid ar ôl, ond ar unwaith! Nid oes angen lansio monitro a “rhywsut yn ddiweddarach” darganfod pwy fydd yn derbyn rhybuddion. Wedi'r cyfan, beth yw'r dasg o fonitro: i ddeall ble yn y system mae rhywbeth yn gweithio o'i le, a rhoi gwybod i'r bobl iawn amdano. Os byddwch chi'n gadael hwn tan y diwedd, yna bydd y bobl iawn yn gwybod bod rhywbeth yn mynd o'i le dim ond trwy ffonio “does dim byd yn gweithio i ni.”

Haen Cais - Monitro Rhesymeg Busnes

Yma rydym yn sôn am wirio'r union ffaith bod y cais yn gweithio i'r defnyddiwr.

Dylid gwneud y lefel hon yn ystod y cyfnod datblygu. Er enghraifft, mae gennym Prometheus amodol: mae'n mynd i'r gweinydd sy'n gwneud y gwiriadau, yn tynnu'r diweddbwynt, ac mae'r diweddbwynt yn mynd ac yn gwirio'r API.

Pan ofynnir yn aml i fonitro'r dudalen gartref i sicrhau bod y wefan yn gweithio, mae rhaglenwyr yn rhoi handlen y gellir ei thynnu bob tro y mae angen iddynt wneud yn siŵr bod yr API yn gweithio. Ac mae rhaglenwyr ar hyn o bryd yn dal i gymryd ac ysgrifennu /api/test/helloworld
Yr unig ffordd i sicrhau bod popeth yn gweithio? - Na!

• Yn y bôn, tasg datblygwyr yw creu gwiriadau o'r fath. Dylai profion uned gael eu hysgrifennu gan y rhaglenwyr sy'n ysgrifennu'r cod. Oherwydd os byddwch chi'n ei ollwng i'r gweinyddwr, “Dude, dyma restr o brotocolau API ar gyfer pob un o'r 25 swyddogaeth, monitro popeth!” - ni fydd dim yn gweithio allan.
• Os ydych chi'n argraffu “helo world”, ni fydd neb byth yn gwybod y dylai'r API weithio ac y bydd yn gweithio. Rhaid i bob newid API arwain at newid mewn sieciau.
• Os oes gennych broblem o'r fath eisoes, stopiwch y nodweddion a neilltuwch y datblygwyr a fydd yn ysgrifennu'r gwiriadau hyn, neu'n derbyn y colledion, yn derbyn nad oes unrhyw beth yn cael ei wirio a bydd yn methu.

Cyngor Technegol:

• Gwnewch yn siŵr eich bod yn trefnu gweinydd allanol i drefnu sieciau - rhaid i chi fod yn siŵr bod eich prosiect yn hygyrch i'r byd y tu allan.
• Trefnwch wiriadau ar draws y protocol API cyfan, nid dim ond pwyntiau terfyn unigol.
• Creu diweddbwynt prometheus gyda chanlyniadau'r prawf.

Haen cais - monitro metrigau iechyd

Nawr rydym yn sôn am fetrigau iechyd allanol gwasanaethau.

Fe wnaethom benderfynu ein bod yn monitro holl “ddolenni” y rhaglen gan ddefnyddio gwiriadau allanol, yr ydym yn eu galw o system fonitro allanol. Ond dyma'r “dolenni” y mae'r defnyddiwr yn eu “gweld”. Rydym am fod yn siŵr bod ein gwasanaethau eu hunain yn gweithio. Mae stori well yma: mae gan K8s wiriadau iechyd, fel y gall y “ciwb” ei hun o leiaf fod yn argyhoeddedig bod y gwasanaeth yn gweithio. Ond mae hanner y sieciau dwi wedi gweld yr un print “helo world”. Y rhai. Felly mae'n tynnu unwaith ar ôl ei ddefnyddio, atebodd fod popeth yn iawn - dyna i gyd. Ac mae gan y gwasanaeth, os yw'n darparu ei API ei hun, nifer enfawr o bwyntiau mynediad ar gyfer yr un API hwnnw, y mae angen eu monitro hefyd, oherwydd rydym am wybod ei fod yn gweithio. Ac rydym eisoes yn ei fonitro y tu mewn.

Sut i weithredu hyn yn gywir yn dechnegol: mae pob gwasanaeth yn amlygu diweddbwynt am ei berfformiad presennol, ac yn graffiau Grafana (neu unrhyw raglen arall) gwelwn statws yr holl wasanaethau.

• Rhaid i bob newid API arwain at newid mewn sieciau.
• Creu gwasanaeth newydd ar unwaith gyda metrigau iechyd.
• Gall gweinyddwr ddod at y datblygwyr a gofyn “ychwanegwch ychydig o nodweddion ataf fel fy mod yn deall popeth ac yn ychwanegu gwybodaeth am hyn at fy system fonitro.” Ond mae datblygwyr fel arfer yn ateb, "Ni fyddwn yn ychwanegu unrhyw beth bythefnos cyn y datganiad."
  Rhowch wybod i'r rheolwyr datblygu y bydd colledion o'r fath, rhowch wybod i reolwyr y rheolwyr datblygu hefyd. Oherwydd pan fydd popeth yn cwympo, bydd rhywun yn dal i alw a mynnu monitro'r “gwasanaeth sy'n cwympo'n gyson” (c)
• Gyda llaw, neilltuwch ddatblygwyr i ysgrifennu ategion ar gyfer Grafana - bydd hyn yn help da i weinyddwyr.

Haen Cais - Monitro Integreiddio

Mae monitro integreiddio yn canolbwyntio ar fonitro cyfathrebu rhwng systemau sy'n hanfodol i fusnes.

Er enghraifft, mae 15 o wasanaethau sy'n cyfathrebu â'i gilydd. Nid yw'r rhain bellach yn safleoedd ar wahân. Y rhai. ni allwn dynnu'r gwasanaeth ar ei ben ei hun, cael /heloworld a deall bod y gwasanaeth yn rhedeg. Oherwydd bod yn rhaid i'r gwasanaeth gwe archebu anfon gwybodaeth am yr archeb i'r bws - o'r bws, rhaid i'r gwasanaeth warws dderbyn y neges hon a gweithio gydag ef ymhellach. Ac mae'n rhaid i'r gwasanaeth dosbarthu e-bost brosesu hyn rywsut ymhellach, ac ati.

Yn unol â hynny, ni allwn ddeall, gan brocio ar bob gwasanaeth unigol, fod y cyfan yn gweithio. Oherwydd bod gennym ni fws penodol lle mae popeth yn cyfathrebu ac yn rhyngweithio.
Felly, dylai'r cam hwn nodi'r cam o brofi gwasanaethau ar gyfer rhyngweithio â gwasanaethau eraill. Mae'n amhosibl trefnu monitro cyfathrebu trwy fonitro'r brocer negeseuon. Os oes gwasanaeth sy’n cyhoeddi data a gwasanaeth sy’n ei dderbyn, wrth fonitro’r brocer dim ond data sy’n hedfan o ochr i ochr y byddwn yn ei weld. Hyd yn oed pe baem ni rywsut yn llwyddo i fonitro rhyngweithio'r data hwn yn fewnol - bod cynhyrchydd penodol yn postio'r data, bod rhywun yn ei ddarllen, mae'r llif hwn yn parhau i fynd i Kafka - ni fydd hyn yn dal i roi gwybodaeth i ni pe bai un gwasanaeth yn anfon y neges mewn un fersiwn , ond nid oedd y gwasanaeth arall yn disgwyl y fersiwn hon a'i hepgor. Ni fyddwn yn gwybod am hyn, gan y bydd y gwasanaethau yn dweud wrthym fod popeth yn gweithio.

Yr hyn yr wyf yn argymell ei wneud:

• Ar gyfer cyfathrebu cydamserol: mae'r pwynt terfyn yn gwneud ceisiadau i wasanaethau cysylltiedig. Y rhai. rydyn ni'n cymryd y pwynt olaf hwn, yn tynnu sgript y tu mewn i'r gwasanaeth, sy'n mynd at yr holl bwyntiau ac yn dweud “Gallaf dynnu yno, a thynnu yno, gallaf dynnu yno...”
• Ar gyfer cyfathrebu asyncronig: negeseuon sy'n dod i mewn - mae'r pwynt terfyn yn gwirio'r bws am negeseuon prawf ac yn dangos y statws prosesu.
• Ar gyfer cyfathrebu asyncronig: negeseuon sy'n mynd allan - mae'r pwynt terfyn yn anfon negeseuon prawf i'r bws.

Fel sy'n digwydd fel arfer: mae gennym wasanaeth sy'n taflu data i'r bws. Rydym yn dod i'r gwasanaeth hwn ac yn gofyn i chi ddweud wrthym am ei iechyd integreiddio. Ac os oes angen i'r gwasanaeth gynhyrchu neges yn rhywle pellach (WebApp), yna bydd yn cynhyrchu'r neges brawf hon. Ac os ydym yn rhedeg gwasanaeth ar yr ochr OrderProcessing, yn gyntaf mae'n postio'r hyn y gall ei bostio'n annibynnol, ac os oes rhai pethau dibynnol, yna mae'n darllen set o negeseuon prawf o'r bws, yn deall y gall eu prosesu, adrodd amdanynt a , os oes angen, postiwch nhw ymhellach, ac am hyn mae'n dweud - mae popeth yn iawn, rydw i'n fyw.

Yn aml iawn rydyn ni'n clywed y cwestiwn “sut allwn ni brofi hyn ar ddata ymladd?” Er enghraifft, rydym yn sôn am yr un gwasanaeth archebu. Mae'r archeb yn anfon negeseuon i'r warws lle mae'r nwyddau'n cael eu dileu: ni allwn brofi hyn ar ddata ymladd, oherwydd "bydd fy nwyddau'n cael eu dileu!" Ateb: Cynlluniwch y prawf cyfan hwn o'r cychwyn cyntaf. Mae gennych hefyd brofion uned sy'n gwneud ffugiau. Felly, gwnewch hynny ar lefel ddyfnach lle mae gennych sianel gyfathrebu nad yw'n niweidio gweithrediad y busnes.

Lefel seilwaith

Mae monitro seilwaith yn rhywbeth yr ystyriwyd ers tro byd monitro ei hun.

• Gellir, a dylid, lansio monitro seilwaith fel proses ar wahân.
• Ni ddylech ddechrau gyda monitro seilwaith ar brosiect rhedeg, hyd yn oed os ydych chi wir eisiau. Mae hyn yn boen i bob devops. “Yn gyntaf, byddaf yn monitro'r clwstwr, byddaf yn monitro'r seilwaith” - h.y. Yn gyntaf, bydd yn monitro'r hyn sydd isod, ond ni fydd yn mynd i mewn i'r cais. Oherwydd bod y cais yn beth annealladwy ar gyfer devops. Fe'i gollyngwyd iddo, ac nid yw'n deall sut mae'n gweithio. Ac mae'n deall y seilwaith ac yn dechrau ag ef. Ond na - mae angen i chi fonitro'r cais yn gyntaf bob amser.
• Peidiwch â mynd dros ben llestri gyda nifer y rhybuddion. O ystyried cymhlethdod systemau modern, mae rhybuddion yn hedfan yn gyson, ac mae'n rhaid i chi fyw gyda'r criw hwn o rybuddion rywsut. A bydd y person ar alwad, ar ôl edrych ar gant o’r rhybuddion nesaf, yn penderfynu “Dydw i ddim eisiau meddwl amdano.” Dim ond am bethau hollbwysig y dylai rhybuddion eu hysbysu.

Lefel cais fel uned fusnes

Pwyntiau allweddol:

• ELK. Dyma safon y diwydiant. Os nad ydych yn agregu logiau am ryw reswm, dechreuwch wneud hynny ar unwaith.
• APM. APMs allanol fel ffordd o gau monitro ceisiadau yn gyflym (NewRelic, BlackFire, Datadog). Gallwch chi osod y peth hwn dros dro i o leiaf rywsut ddeall beth sy'n digwydd gyda chi.
• Olrhain. Mewn dwsinau o ficrowasanaethau, mae'n rhaid ichi olrhain popeth, oherwydd nid yw'r cais bellach yn byw ar ei ben ei hun. Mae'n anodd iawn ychwanegu yn nes ymlaen, felly mae'n well amserlennu olrhain mewn datblygiad ar unwaith - dyma waith a defnyddioldeb y datblygwyr. Os nad ydych wedi ei roi ar waith eto, rhowch ar waith! Gweler Jaeger/Zipkin

Rhybuddio

• Trefniadaeth system hysbysu: o dan amodau monitro criw o bethau, dylai fod system unedig ar gyfer anfon hysbysiadau. Gallwch chi yn Grafana. Yn y Gorllewin, mae pawb yn defnyddio PagerDuty. Dylai rhybuddion fod yn glir (ee o ble y daethant...). Ac mae'n ddoeth rheoli bod hysbysiadau yn cael eu derbyn o gwbl
• Trefniadaeth system ddyletswydd: ni ddylid anfon rhybuddion at bawb (naill ai bydd pawb yn ymateb mewn torf, neu ni fydd neb yn ymateb). Mae angen i ddatblygwyr fod ar alwad hefyd: gwnewch yn siŵr eich bod yn diffinio meysydd cyfrifoldeb, gwnewch gyfarwyddiadau clir ac ysgrifennu ynddo pwy yn union i'w ffonio ddydd Llun a dydd Mercher, a phwy i'w ffonio ddydd Mawrth a dydd Gwener (fel arall ni fyddant yn galw unrhyw un hyd yn oed yn y digwyddiad o broblem fawr - bydd arnynt ofn eich deffro neu aflonyddu : yn gyffredinol nid yw pobl yn hoffi galw a deffro pobl eraill, yn enwedig yn y nos). Ac esboniwch nad yw gofyn am help yn arwydd o anghymhwysedd ("Rwy'n gofyn am help, mae hynny'n golygu fy mod yn weithiwr gwael"), anogwch geisiadau am help.
• Trefnu “sylfaen wybodaeth” a llif gwaith ar gyfer prosesu digwyddiadau: ar gyfer pob digwyddiad difrifol, dylid cynllunio post-mortem, ac fel mesur dros dro, dylid cofnodi camau gweithredu a fydd yn datrys y digwyddiad. A gwnewch yn arfer bod rhybuddion ailadroddus yn bechod; mae angen eu gosod mewn cod neu waith seilwaith.

pentwr technoleg

Gadewch i ni ddychmygu bod ein pentwr fel a ganlyn:

• casglu data - Prometheus + Grafana;
• dadansoddiad log - ELK;
• ar gyfer APM neu Olrhain - Jaeger (Zipkin).

Nid yw'r dewis o opsiynau yn hollbwysig. Oherwydd os oeddech chi'n deall ar y dechrau sut i fonitro'r system ac wedi ysgrifennu cynllun, yna rydych chi'n dechrau dewis offer i weddu i'ch gofynion. Y cwestiwn yw beth wnaethoch chi ddewis ei fonitro yn y lle cyntaf. Oherwydd efallai nad yw'r offeryn a ddewisoch ar y dechrau yn gweddu i'ch gofynion o gwbl.

Ychydig o bwyntiau technegol a welaf ym mhobman yn ddiweddar:

Mae Prometheus yn cael ei wthio y tu mewn i Kubernetes - pwy feddyliodd am hwn?! Os bydd eich clwstwr yn chwalu, beth fyddwch chi'n ei wneud? Os oes gennych glwstwr cymhleth y tu mewn, yna dylai fod rhyw fath o system fonitro y tu mewn i'r clwstwr, a rhai y tu allan, a fydd yn casglu data o'r tu mewn i'r clwstwr.

Y tu mewn i'r clwstwr rydym yn casglu boncyffion a phopeth arall. Ond rhaid i'r system fonitro fod y tu allan. Yn aml iawn, mewn clwstwr lle mae Protheus wedi'i osod yn fewnol, mae yna hefyd systemau sy'n cynnal gwiriadau allanol o weithrediad y wefan. Beth os yw eich cysylltiadau â'r byd y tu allan wedi gostwng ac nad yw'r cais yn gweithio? Mae'n ymddangos bod popeth yn iawn y tu mewn, ond nid yw'n gwneud pethau'n haws i ddefnyddwyr.

Canfyddiadau

• Nid gosod cyfleustodau yw monitro datblygiad, ond datblygu cynnyrch meddalwedd. Mae 98% o fonitro heddiw yn codio. Codio mewn gwasanaethau, codio gwiriadau allanol, gwirio gwasanaethau allanol, a dyna i gyd.
• Peidiwch â gwastraffu amser eich datblygwyr ar fonitro: gall gymryd hyd at 30% o'u gwaith, ond mae'n werth chweil.
• Devops, peidiwch â phoeni na allwch fonitro rhywbeth, oherwydd mae rhai pethau'n ffordd hollol wahanol o feddwl. Nid oeddech yn rhaglennydd, a’u swydd hwy yn union yw gwaith monitro.
• Os yw'r prosiect eisoes yn rhedeg a heb ei fonitro (a'ch bod yn rheolwr), neilltuwch adnoddau ar gyfer monitro.
• Os yw'r cynnyrch eisoes yn cael ei gynhyrchu, a'ch bod yn ddevops y dywedwyd wrthych am “sefydlu monitro” - ceisiwch esbonio i'r rheolwyr beth ysgrifennais hyn i gyd amdano.

Dyma fersiwn estynedig o'r adroddiad yng nghynhadledd Saint Highload++.

Os oes gennych chi ddiddordeb yn fy syniadau a'm meddyliau arno a phynciau cysylltiedig, yna dyma chi'n gallu darllen y sianel 🙂

Ffynhonnell: hab.com