Heddiw, yn ychwanegol at y cod monolithig, mae dwsinau o ficrowasanaethau yn gweithredu ar ein prosiect. Mae angen monitro pob un ohonynt. Mae'n anodd gwneud hyn mewn niferoedd o'r fath gan beirianwyr DevOps. Rydym wedi datblygu system fonitro sy'n gweithio fel gwasanaeth i ddatblygwyr. Gallant ysgrifennu metrigau yn annibynnol i'r system fonitro, eu defnyddio, adeiladu dangosfyrddau yn seiliedig arnynt, atodi rhybuddion iddynt a fydd yn cael eu sbarduno pan gyrhaeddir gwerthoedd trothwy. Gyda pheirianwyr DevOps - dim ond seilwaith a dogfennaeth.
Mae'r post hwn yn drawsgrifiad o fy araith o'n ar RIT++. Gofynnodd llawer i ni wneud fersiynau testun o adroddiadau oddi yno. Os ydych chi wedi bod i gynhadledd neu wedi gwylio fideo, ni fyddwch chi'n dod o hyd i unrhyw beth newydd. Ac i bawb arall - croeso dan gath. Dywedaf wrthych sut y daethom at system o'r fath, sut y mae'n gweithio a sut yr ydym yn bwriadu ei diweddaru.
Gorffennol: cynlluniau a chynlluniau
Sut daethom ni at y system fonitro bresennol? Er mwyn ateb y cwestiwn hwn, mae angen i chi fynd i 2015. Dyma sut olwg oedd arno bryd hynny:
Roedd gennym tua 24 o nodau a oedd yn gyfrifol am fonitro. Mae yna griw cyfan o wahanol crons, sgriptiau, daemons sy'n monitro rhywbeth yn rhywle, yn anfon negeseuon, yn cyflawni swyddogaethau. Roeddem yn meddwl po bellaf, y lleiaf y byddai system o’r fath yn ymarferol. Nid yw'n gwneud unrhyw synnwyr i'w ddatblygu: mae'n rhy feichus.
Penderfynasom ddewis yr elfennau hynny o fonitro y byddwn yn eu gadael ac yn eu datblygu, a’r rhai y byddwn yn cefnu arnynt. Roedd 19 ohonynt, a dim ond graffitau, agregwyr a Grafana fel dangosfwrdd oedd ar ôl. Ond sut olwg fydd ar y system newydd? Fel hyn:
Mae gennym ystorfa o fetrigau: mae'r rhain yn graffitau a fydd yn seiliedig ar yriannau SSD cyflym, mae'r rhain yn rhai cydgrynwyr ar gyfer metrigau. Nesaf - Grafana ar gyfer arddangos dangosfyrddau a Moira fel rhybudd. Roeddem hefyd am ddatblygu system ar gyfer dod o hyd i anomaleddau.
Safon: Monitro 2.0
Dyma sut olwg oedd ar y cynlluniau yn 2015. Ond bu’n rhaid inni baratoi nid yn unig y seilwaith a’r gwasanaeth ei hun, ond hefyd y ddogfennaeth ar ei gyfer. Rydym wedi datblygu safon gorfforaethol i ni ein hunain, sef monitro 2.0. Beth oedd y gofynion ar gyfer y system?
- argaeledd cyson;
- cyfwng storio metrig = 10 eiliad;
- storfa strwythuredig o fetrigau a dangosfyrddau;
- CLG > 99,99%
- casglu metrigau digwyddiadau trwy CDU (!).
Roedd angen CDU arnom oherwydd mae gennym lawer o draffig a digwyddiadau sy'n cynhyrchu metrigau. Os ydynt i gyd wedi'u hysgrifennu mewn graffit ar unwaith, bydd yr ystorfa'n cwympo. Fe wnaethom hefyd ddewis rhagddodiaid lefel gyntaf ar gyfer pob metrig.
Mae gan bob un o'r rhagddodiaid rywfaint o eiddo. Mae yna fetrigau ar gyfer gweinyddwyr, rhwydweithiau, cynwysyddion, adnoddau, cymwysiadau, ac ati. Mae hidlo clir, llym, wedi'i deipio wedi'i weithredu, lle rydym yn derbyn y metrigau lefel gyntaf, ac yn syml yn gollwng y gweddill. Dyma sut y cynlluniwyd y system hon gennym yn 2015. Beth sydd yn y presennol?
Presennol: cynllun rhyngweithio cydrannau monitro
Yn gyntaf oll, rydym yn monitro ceisiadau: ein cod PHP, ceisiadau a microservices - mewn gair, popeth y mae ein datblygwyr yn ei ysgrifennu. Mae pob cais yn anfon metrigau trwy'r CDU i gydgrynwr Brubeck (stats, wedi'i ailysgrifennu yn C). Trodd allan i fod y cyflymaf yn ôl canlyniadau profion synthetig. Ac mae'n anfon y metrigau sydd eisoes wedi'u hagregu i Graphite trwy TCP.
Mae ganddo fath o fetrigau ag amseryddion. Mae hyn yn beth handi iawn. Er enghraifft, ar gyfer pob cysylltiad defnyddiwr â'r gwasanaeth, rydych chi'n anfon metrig amser ymateb i Brubeck. Daeth miliwn o atebion, a dim ond 10 metrig a roddodd y cyfanredwr. Mae gennych nifer y bobl a ddaeth, yr amseroedd ymateb mwyaf, lleiafswm a chyfartaledd, y canolrif a 4 canradd. Yna trosglwyddir y data i Graphite a gwelwn nhw i gyd yn fyw.
Mae gennym hefyd agregiad ar gyfer caledwedd, meddalwedd, metrigau system a'n hen system fonitro Munin (bu'n gweithio gyda ni tan 2015). Rydyn ni'n casglu hyn i gyd trwy'r daemon C'ish CollectD (mae criw cyfan o ategion amrywiol wedi'u gwnïo ynddo, gall gwestiynu holl adnoddau'r system gwesteiwr y mae wedi'i osod arno, dim ond nodi yn y ffurfweddiad ble i ysgrifennu data ) ac ysgrifennu data trwyddo mewn Graffit. Mae hefyd yn cefnogi ategion python a sgriptiau cregyn, felly gallwch chi ysgrifennu eich datrysiadau personol eich hun: bydd CollectD yn casglu'r data hwn gan westeiwr lleol neu o bell (gan dybio bod Curl) a'i anfon at Graphite.
Ymhellach, mae'r holl fetrigau rydyn ni wedi'u casglu yn cael eu hanfon i Carbon-c-relay. Dyma ddatrysiad Carbon Relay Graphite, wedi'i addasu yn C. Mae hwn yn llwybrydd sy'n casglu'r holl fetrigau rydyn ni'n eu hanfon o'n cydgrynwyr ac yn eu llwybro trwy'r nodau. Hefyd ar y cam llwybro, mae'n gwirio dilysrwydd y metrigau. Yn gyntaf, rhaid iddynt gyd-fynd â'r cynllun rhagddodiad a ddangosais yn gynharach ac, yn ail, rhaid iddynt fod yn ddilys ar gyfer graffit. Fel arall, maent yn gollwng.
Yna mae Carbon-c-relay yn anfon y metrigau i'r clwstwr Graffit. Rydym yn defnyddio Carbon-cache wedi'i ailysgrifennu yn Go fel y brif storfa ar gyfer metrigau. Mae go-carbon, oherwydd ei edafu aml, yn llawer gwell o ran perfformiad na Carbon-cache. Mae'n cymryd data i mewn iddo'i hun ac yn ei ysgrifennu i ddisg gan ddefnyddio'r pecyn sibrwd (safonol, wedi'i ysgrifennu mewn python). Er mwyn darllen data o'n storfeydd, rydym yn defnyddio'r API Graffit. Mae'n gweithio'n llawer cyflymach na'r WEB Graffit safonol. Beth fydd yn digwydd i'r data nesaf?
Maen nhw'n mynd i Grafana. Rydym yn defnyddio ein clystyrau graffit fel y brif ffynhonnell ddata, ac mae gennym Grafana fel rhyngwyneb gwe ar gyfer arddangos metrigau, adeiladu dangosfyrddau. Ar gyfer pob un o'u gwasanaethau, mae datblygwyr yn creu eu dangosfwrdd eu hunain. Yna maen nhw'n adeiladu graffiau yn seiliedig arnyn nhw, sy'n dangos y metrigau maen nhw'n eu hysgrifennu o'u cymwysiadau. Yn ogystal â Grafana, mae gennym ni hefyd SLAM. Mae hwn yn gythraul pythonic sy'n cyfrifo CLG yn seiliedig ar ddata o graffit. Fel y dywedais, mae gennym sawl dwsin o ficrowasanaethau, ac mae gan bob un ohonynt ei ofynion ei hun. Gyda chymorth SLAM, rydym yn mynd i'r ddogfennaeth ac yn ei gymharu â'r hyn sydd yn Graphite ac yn cymharu sut mae'r gofynion yn cyfateb i argaeledd ein gwasanaethau.
Mynd ymhellach: rhybuddio. Mae'n cael ei drefnu gyda system gref - Moira. Mae hi'n annibynnol oherwydd bod ganddi ei Graffit ei hun o dan y cwfl. Wedi'i ddatblygu gan y bechgyn o SKB Kontur, wedi'i ysgrifennu yn python a Go, ffynhonnell gwbl agored. Mae Moira yn derbyn yr un llif sy'n mynd i mewn i graffitau. Os bydd eich storfa yn marw am ryw reswm, yna bydd eich rhybuddion yn gweithio.
Fe wnaethom ddefnyddio Moira yn Kubernetes, mae'n defnyddio clwstwr o weinyddion Redis fel y brif gronfa ddata. Y canlyniad yw system sy'n goddef diffygion. Mae'n cymharu llif metrigau â'r rhestr o sbardunau: os nad oes unrhyw gyfeiriadau ynddo, yna mae'n gollwng y metrig. Felly mae hi'n gallu treulio gigabeit o fetrigau y funud.
Fe wnaethom hefyd ychwanegu LDAP corfforaethol ato, gyda chymorth y gall pob defnyddiwr o'r system gorfforaethol greu hysbysiadau iddo'i hun ar sbardunau presennol (neu rai newydd eu creu). Gan fod Moira yn cynnwys Graffit, mae'n cefnogi ei holl nodweddion. Felly rydych chi'n cymryd y llinell yn gyntaf ac yn ei chopïo i Grafana. Gweld sut mae'r data'n cael ei arddangos ar y siartiau. Ac yna rydych chi'n cymryd yr un llinell a'i chopïo i Moira. Hongian gyda therfynau a chael rhybudd ar yr allbwn. I wneud hyn i gyd, nid oes angen unrhyw wybodaeth benodol. Gall Moira rybuddio trwy SMS, e-bost, Jira, Slack ... Mae hefyd yn cefnogi sgriptiau arfer. Pan fydd ganddi sbardun, ac mae hi wedi'i thanysgrifio i sgript arfer neu ddeuaidd, mae'n ei lansio ac yn anfon y deuaidd JSON hwn i stdin. Yn unol â hynny, dylai eich rhaglen dosrannu ei. Chi sydd i benderfynu beth fyddwch chi'n ei wneud gyda'r JSON hwn. Os ydych chi eisiau, anfonwch ef i Telegram, os ydych chi eisiau, agorwch dasgau yn Jira, gwnewch beth bynnag rydych chi ei eisiau.
Rydym hefyd yn defnyddio ein datblygiad ein hunain ar gyfer rhybuddio - Imagotag. Fe wnaethom addasu'r panel, a ddefnyddir fel arfer ar gyfer tagiau pris electronig mewn siopau, i'n hanghenion. Daethom â sbardunau o Moira iddo. Mae'n nodi ym mha gyflwr y maent, pan ddigwyddodd. Mae rhai o'r dynion o'r datblygiad wedi gadael hysbysiadau yn Slack ac yn y post o blaid y panel hwn.
Wel, gan ein bod yn gwmni blaengar, rydym hefyd yn monitro Kubernetes yn y system hon. Wedi'i gynnwys yn y system gan ddefnyddio Heapster, yr ydym wedi'i osod yn y clwstwr, mae'n casglu data ac yn ei anfon i Graphite. O ganlyniad, mae’r cynllun yn edrych fel hyn:
Cydrannau Monitro
Dyma restr o ddolenni i'r cydrannau a ddefnyddiwyd gennym ar gyfer y dasg hon. Mae pob un ohonynt yn ffynhonnell agored.
Graffit:
- go-garbon:
- sibrwd:
- graffit-api:
Cyfnewid carbon-c:
Brubeck:
Wedi'i gasglu:
Moira:
Grafana:
pentyrrau:
Ystadegau
A dyma rai niferoedd am sut mae'r system yn gweithio i ni.
Aggregator (brubeck)
Nifer y metrigau: ~ 300 / eiliad
Cyfwng Anfon Metrigau Graffit: 30 eiliad
Defnyddio adnoddau gweinydd: ~ 6% CPU (rydym yn sôn am weinyddion llawn); ~ 1Gb RAM; ~ 3 Mbps LAN
Graffit (go-carbon)
Nifer y metrigau: ~ 1 / min
Cyfnod diweddaru metrig: 30 eiliad
Cynllun storio metrigau: 30sec 35d, 5min 90d, 10min 365d (yn rhoi dealltwriaeth o'r hyn sy'n digwydd i'r gwasanaeth dros gyfnod hir o amser)
Defnydd o adnoddau gweinydd: ~10% CPU; ~ 20Gb RAM; ~ 30 Mbps LAN
Hyblygrwydd
Rydym ni yn Avito wir yn gwerthfawrogi'r hyblygrwydd yn ein gwasanaeth monitro. Pam y trodd e allan fel hyn mewn gwirionedd? Yn gyntaf, mae ei rannau cyfansoddol yn gyfnewidiol: y cydrannau eu hunain a'u fersiynau. Yn ail, cynaladwyedd. Gan fod y prosiect cyfan wedi'i adeiladu ar ffynhonnell agored, gallwch olygu'r cod eich hun, gwneud newidiadau, a gweithredu swyddogaethau nad ydynt ar gael allan o'r blwch. Defnyddir staciau eithaf cyffredin, Go a Python yn bennaf, felly gwneir hyn yn eithaf syml.
Dyma enghraifft o broblem wirioneddol. Mae metrig mewn Graffit yn ffeil. Mae ganddo enw. Enw ffeil = enw metrig. Ac mae ffordd i gyrraedd yno. Mae enwau ffeiliau yn Linux wedi'u cyfyngu i 255 nod. Ac mae gennym ni (fel “cwsmeriaid mewnol”) ddynion o'r adran gronfa ddata. Maent yn dweud wrthym: “Rydym am fonitro ein hymholiadau SQL. Ac nid ydynt yn 255 o nodau, ond 8 MB yr un. Rydym am eu harddangos yn Grafana, gweler y paramedrau ar gyfer y cais hwn, a hyd yn oed yn well, rydym am weld brig ceisiadau o'r fath. Bydd yn wych os caiff ei arddangos mewn amser real. A byddai’n cŵl iawn eu gwthio i’r rhybudd.”
Cymerir yr enghraifft ymholiad SQL fel enghraifft o
Rydym yn codi'r gweinydd Redis a'n ategion Collected sy'n mynd i Postgres ac yn cymryd yr holl ddata oddi yno, yn anfon metrigau i Graphite. Ond rydym yn disodli enw'r metrig gyda hashes. Mae'r un hash yn cael ei anfon ar yr un pryd i Redis fel allwedd, a'r ymholiad SQL cyfan fel gwerth. Mater i ni o hyd yw gwneud Grafana yn gallu mynd i Redis a chymryd y wybodaeth hon. Rydym yn agor yr API Graffit oherwydd dyma'r prif ryngwyneb ar gyfer rhyngweithio'r holl gydrannau monitro â graffit, ac rydym yn mynd i mewn i swyddogaeth newydd yno o'r enw aliasByHash () - rydym yn cael enw'r metrig o Grafana, ac yn ei ddefnyddio mewn cais i Redis fel allwedd, yn ymateb rydym yn cael gwerth yr allwedd, sef ein “ymholiad SQL”. Felly, daethom ag arddangosfa ymholiad SQL i Grafana, na ellid, mewn egwyddor, ei arddangos yno, ynghyd ag ystadegau arno (galwadau, rhesi, cyfanswm_amser, ...).
Canlyniadau
Argaeledd Mae ein gwasanaeth monitro ar gael 24/7 o unrhyw gais ac unrhyw god. Os oes gennych chi fynediad i'r storfa, gallwch chi ysgrifennu data i'r gwasanaeth. Nid yw iaith yn bwysig, nid yw penderfyniadau yn bwysig. Nid oes ond angen i chi wybod sut i agor soced, taflu metrig yno, a chau'r soced.
Dibynadwyedd Mae'r holl gydrannau'n oddefgar o fai ac yn trin ein llwythi gwaith yn dda.
Trothwy mynediad isel. Er mwyn defnyddio'r system hon, nid oes angen i chi ddysgu ieithoedd rhaglennu ac ymholiadau yn Grafana. Agorwch eich cais, ychwanegwch soced ato a fydd yn anfon metrigau i Graphite, ei gau, agor Grafana, creu dangosfyrddau yno ac edrych ar ymddygiad eich metrigau, gan dderbyn hysbysiadau trwy Moira.
Annibyniaeth. Gallwch chi wneud hyn i gyd eich hun, heb gymorth peirianwyr DevOps. Ac mae hwn yn ornodwedd, oherwydd gallwch chi fonitro'ch prosiect ar hyn o bryd, nid oes rhaid i chi ofyn i unrhyw un - na dechrau gweithio, na gwneud newidiadau.
Am beth rydyn ni'n ymdrechu?
Nid yw popeth a restrir isod yn feddyliau haniaethol yn unig, ond yn rhywbeth y mae o leiaf y camau cyntaf wedi'u cymryd tuag ato.
- canfodydd anomaleddau. Rydym am greu gwasanaeth a fydd yn mynd i'n storfa Graffit a gwirio pob metrig gan ddefnyddio algorithmau amrywiol. Mae yna eisoes algorithmau yr ydym am eu gweld, mae data, rydym yn gwybod sut i weithio gydag ef.
- metadata. Mae gennym lawer o wasanaethau, maent yn newid dros amser, yn ogystal â'r bobl sy'n gweithio gyda nhw. Nid yw cadw cofnodion â llaw yn opsiwn. Felly, mae metadata bellach wedi’i wreiddio yn ein microwasanaethau. Mae'n nodi pwy a'i datblygodd, yr ieithoedd y mae'n rhyngweithio â nhw, gofynion CLG, ble ac at bwy i anfon hysbysiadau. Wrth ddefnyddio gwasanaeth, caiff yr holl ddata endid ei greu'n annibynnol. O ganlyniad, cewch ddau ddolen - un ar gyfer sbardunau, a'r llall ar gyfer dangosfyrddau yn Grafana.
- Monitro ym mhob cartref. Credwn y dylai pob datblygwr ddefnyddio system o'r fath. Yn yr achos hwn, rydych chi bob amser yn deall ble mae'ch traffig, beth sy'n digwydd iddo, lle mae'n disgyn, lle mae ganddo bwyntiau gwan. Er enghraifft, os daw rhywbeth i ddamwain eich gwasanaeth, yna byddwch yn dod i wybod amdano nid yn ystod galwad gan y rheolwr, ond o rybudd, a gallwch agor logiau newydd ar unwaith a gweld beth ddigwyddodd yno.
- Perfformiad uchel. Mae ein prosiect yn tyfu'n gyson, a heddiw mae'n prosesu tua 2 o werthoedd metrig y funud. Flwyddyn yn ôl, roedd y ffigur hwn yn 000. Ac mae'r twf yn parhau, ac mae hyn yn golygu y bydd Graffit (sibrwd) yn dechrau llwytho'r is-system ddisg yn drwm iawn ar ôl peth amser. Fel y dywedais, mae'r system fonitro hon yn eithaf amlbwrpas oherwydd cyfnewidioldeb cydrannau. Mae rhywun yn benodol ar gyfer Graffit yn cynnal ac yn ehangu eu seilwaith yn gyson, ond fe wnaethom benderfynu mynd i'r ffordd arall: defnyddio fel ystorfa ar gyfer ein metrigau. Mae'r cyfnod pontio hwn bron wedi'i gwblhau, ac yn fuan iawn dywedaf wrthych yn fanylach sut y'i gwnaed: beth oedd yr anawsterau a sut y cawsant eu goresgyn, sut aeth y broses fudo, byddaf yn disgrifio'r cydrannau a ddewiswyd fel rhai rhwymol a'u ffurfweddiadau.
Diolch am eich sylw! Gofynnwch eich cwestiynau ar y pwnc, byddaf yn ceisio ateb yma neu yn y swyddi canlynol. Efallai bod gan rywun brofiad o adeiladu system fonitro debyg neu newid i Clickhouse mewn sefyllfa debyg - rhannwch ef yn y sylwadau.
Ffynhonnell: hab.com