Fy enw i yw Anton Baderin. Rwy'n gweithio yn y Ganolfan Technoleg Uchel ac yn gweinyddu systemau. Fis yn ôl, daeth ein cynhadledd gorfforaethol i ben, lle buom yn rhannu ein profiad cronedig gyda chymuned TG ein dinas. Soniais am fonitro cymwysiadau gwe. Roedd y deunydd wedi'i fwriadu ar gyfer lefel iau neu ganol, nad oedd yn adeiladu'r broses hon o'r dechrau.
Y conglfaen sy'n sail i unrhyw system fonitro yw datrys problemau busnes. Nid yw monitro er mwyn monitro o ddiddordeb i neb. Beth mae busnes ei eisiau? Fel bod popeth yn gweithio'n gyflym a heb wallau. Mae busnesau eisiau bod yn rhagweithiol, fel ein bod ni ein hunain yn nodi problemau yn y gwasanaeth ac yn eu trwsio cyn gynted â phosibl. Y rhain, mewn gwirionedd, yw'r problemau y gwnes i eu datrys i gyd y llynedd ar brosiect i un o'n cwsmeriaid.
Ynglŷn â'r prosiect
Mae'r prosiect yn un o'r rhaglenni teyrngarwch mwyaf yn y wlad. Rydym yn helpu cadwyni manwerthu i gynyddu amlder gwerthiannau trwy amrywiol offer marchnata megis cardiau bonws. Yn gyfan gwbl, mae'r prosiect yn cynnwys 14 o geisiadau sy'n rhedeg ar ddeg gweinydd.
Yn ystod y broses gyfweld, sylwais dro ar ôl tro nad yw gweinyddwyr bob amser yn ymdrin â monitro cymwysiadau gwe yn gywir: mae llawer yn dal i ganolbwyntio ar fetrigau system weithredu ac yn monitro gwasanaethau o bryd i'w gilydd.
Yn fy achos i, roedd system fonitro'r cwsmer yn flaenorol yn seiliedig ar Icinga. Nid oedd yn datrys y problemau uchod mewn unrhyw ffordd. Yn aml, roedd y cleient ei hun yn rhoi gwybod i ni am broblemau, ac yn amlach na pheidio, nid oedd gennym ddigon o ddata i gyrraedd gwaelod y rheswm.
Yn ogystal, roedd dealltwriaeth glir o oferedd ei ddatblygiad pellach. Rwy'n meddwl y bydd y rhai sy'n gyfarwydd ag Icinga yn fy neall. Felly, penderfynasom ailgynllunio'r system monitro cymwysiadau gwe ar gyfer y prosiect yn llwyr.
Prometheus
Fe wnaethom ddewis Prometheus yn seiliedig ar dri phrif ddangosydd:
- Nifer enfawr o fetrigau sydd ar gael. Yn ein hachos ni mae yna 60 mil ohonyn nhw. Wrth gwrs, mae'n werth nodi nad ydym yn defnyddio'r mwyafrif helaeth ohonynt (tua 95% yn ôl pob tebyg). Ar y llaw arall, maent i gyd yn gymharol rad. I ni, dyma'r pegwn arall o'i gymharu â'r Icinga a ddefnyddiwyd yn flaenorol. Ynddo, roedd ychwanegu metrigau yn boen arbennig: roedd y rhai presennol yn ddrud (edrychwch ar god ffynhonnell unrhyw ategyn). Roedd unrhyw ategyn yn sgript yn Bash neu Python, y mae ei lansiad yn ddrud o ran yr adnoddau a ddefnyddir.
- Mae'r system hon yn defnyddio swm cymharol fach o adnoddau. Mae 600 MB o RAM, 15% o un craidd a chwpl o ddwsin o IOPS yn ddigon ar gyfer ein holl fetrigau. Wrth gwrs, mae'n rhaid i chi redeg allforwyr metrigau, ond maent i gyd wedi'u hysgrifennu yn Go ac nid ydynt yn newynog iawn ar bŵer ychwaith. Dydw i ddim yn meddwl bod hyn yn broblem mewn realiti modern.
- Yn darparu'r gallu i fudo i Kubernetes. O ystyried cynlluniau'r cwsmer, mae'r dewis yn amlwg.
ELK
Yn flaenorol, ni wnaethom gasglu na phrosesu logiau. Mae'r diffygion yn amlwg i bawb. Fe wnaethon ni ddewis ELK oherwydd bod gennym ni brofiad gyda'r system hon eisoes. Dim ond logiau cais rydyn ni'n eu storio yno. Y prif feini prawf dethol oedd chwiliad testun llawn a'i gyflymder.
Сlickhouse
I ddechrau, disgynnodd y dewis ar InfluxDB. Sylweddolom yr angen i gasglu logiau Nginx, ystadegau o pg_stat_statements, a storio data hanesyddol Prometheus. Nid oeddem yn hoffi Mewnlifiad oherwydd o bryd i'w gilydd dechreuodd ddefnyddio llawer iawn o gof a chwalodd. Yn ogystal, roeddwn i eisiau grwpio ymholiadau yn ôl remote_addr, ond dim ond trwy dagiau y mae grwpio yn y DBMS hwn. Mae tagiau'n ddrud (cof), mae eu nifer yn gyfyngedig yn amodol.
Dechreuon ni ein chwiliad eto. Yr hyn oedd ei angen oedd cronfa ddata ddadansoddol gyda defnydd lleiaf o adnoddau, yn ddelfrydol gyda chywasgu data ar ddisg.
Mae Clickhouse yn bodloni'r holl feini prawf hyn, ac nid ydym erioed wedi difaru ein dewis. Nid ydym yn ysgrifennu unrhyw symiau rhyfeddol o ddata ynddo (dim ond tua phum mil y funud yw nifer y mewnosodiadau).
NewRelic
Yn hanesyddol mae NewRelic wedi bod gyda ni oherwydd dyna oedd dewis y cwsmer. Rydym yn ei ddefnyddio fel APM.
Zabbix
Rydym yn defnyddio Zabbix yn unig i fonitro Blwch Du amrywiol APIs.
Diffinio Dull Monitro
Roeddem am ddadelfennu'r dasg a thrwy hynny systemateiddio'r dull monitro.
I wneud hyn, rhannais ein system i'r lefelau canlynol:
- caledwedd a VMS;
- system weithredu;
- gwasanaethau system, pentwr meddalwedd;
- cais;
- rhesymeg busnes.
Pam fod y dull hwn yn gyfleus:
- rydym yn gwybod pwy sy'n gyfrifol am waith pob lefel ac, yn seiliedig ar hyn, gallwn anfon rhybuddion;
- gallwn ddefnyddio'r strwythur wrth atal rhybuddion - byddai'n rhyfedd anfon rhybudd am nad yw cronfa ddata ar gael pan nad yw'r peiriant rhithwir yn ei gyfanrwydd ar gael.
Gan mai ein tasg yw nodi troseddau yng ngweithrediad y system, mae'n rhaid i ni ar bob lefel dynnu sylw at set benodol o fetrigau y mae'n werth rhoi sylw iddynt wrth ysgrifennu rheolau rhybuddio. Nesaf, gadewch i ni fynd trwy'r lefelau “VMS”, “System weithredu” a “Gwasanaethau system, pentwr meddalwedd”.
Peiriannau rhithwir
Mae hosting yn dyrannu prosesydd, disg, cof a rhwydwaith i ni. A chawsom broblemau gyda'r ddau gyntaf. Felly, y metrigau:
Amser wedi'i ddwyn gan CPU - pan fyddwch chi'n prynu peiriant rhithwir ar Amazon (t2.micro, er enghraifft), dylech ddeall na ddyrennir craidd prosesydd cyfan i chi, ond dim ond cwota o'i amser. A phan fyddwch chi'n ei ddihysbyddu, bydd y prosesydd yn cael ei gymryd oddi wrthych.
Mae'r metrig hwn yn caniatáu ichi olrhain eiliadau o'r fath a gwneud penderfyniadau. Er enghraifft, a oes angen cymryd tariff tewach neu ddosbarthu prosesu tasgau cefndir a cheisiadau API i wahanol weinyddion?
Amser IOPS + CPU - am ryw reswm, mae llawer o hostings cwmwl yn pechu trwy beidio â darparu digon o IOPS. At hynny, nid yw amserlen ag IOPS isel yn ddadl drostynt. Felly, mae'n werth casglu iowait CPU. Gyda'r pâr hwn o graffiau - gydag IOPS isel ac aros I / O uchel - gallwch chi eisoes siarad â'r gwesteiwr a datrys y broblem.
System weithredu
Metrigau system weithredu:
- faint o gof sydd ar gael mewn %;
- gweithgaredd defnydd cyfnewid: vmstat swapin, swapout;
- nifer o inodau sydd ar gael a gofod rhydd ar y system ffeiliau yn %
- llwyth cyfartalog;
- nifer y cysylltiadau mewn dau gyflwr;
- cyflawnder bwrdd conntrack;
- Gellir monitro ansawdd y rhwydwaith gan ddefnyddio'r cyfleustodau ss, y pecyn iproute2 - mynnwch ddangosydd o gysylltiadau RTT o'i allbwn a'i grwpio yn ôl porthladd cyrchfan.
Hefyd ar lefel y system weithredu mae gennym endid o'r fath â phrosesau. Mae'n bwysig nodi yn y system gyfres o brosesau sy'n chwarae rhan bwysig yn ei gweithrediad. Er enghraifft, os oes gennych chi sawl pgpool, yna mae angen i chi gasglu gwybodaeth ar gyfer pob un ohonyn nhw.
Mae'r set o fetrigau fel a ganlyn:
- CPUs;
- cof yn breswyl yn bennaf;
- IO - yn IOPS yn ddelfrydol;
- FileFd - agor a chyfyngu;
- methiannau tudalen sylweddol - fel hyn gallwch ddeall pa broses sy'n cael ei chyfnewid.
Rydym yn defnyddio'r holl fonitro yn Docker, ac rydym yn defnyddio Advisor i gasglu data metrigau. Ar beiriannau eraill rydym yn defnyddio proses-allforiwr.
Gwasanaethau system, pentwr meddalwedd
Mae gan bob cais ei fanylion ei hun, ac mae'n anodd nodi set benodol o fetrigau.
Y set gyffredinol yw:
- cyfradd cais;
- nifer o gamgymeriadau;
- hwyrni;
- dirlawnder.
Ein henghreifftiau mwyaf trawiadol o fonitro ar y lefel hon yw Nginx a PostgreSQL.
Y gwasanaeth sydd wedi'i lwytho fwyaf yn ein system yw'r gronfa ddata. Yn y gorffennol, rydym yn aml yn cael trafferth darganfod beth oedd y gronfa ddata yn ei wneud.
Gwelsom lwyth uchel ar y disgiau, ond nid oedd y logiau araf yn dangos unrhyw beth mewn gwirionedd. Rydym wedi datrys y broblem hon gan ddefnyddio pg_stat_statements, golygfa sy'n casglu ystadegau ymholiad.
Dyna'r holl anghenion gweinyddol.
Rydym yn adeiladu graffiau o weithgaredd ceisiadau darllen ac ysgrifennu:
Mae popeth yn syml ac yn glir, mae gan bob cais ei liw ei hun.
Enghraifft yr un mor drawiadol yw logiau Nginx. Nid yw'n syndod mai ychydig o bobl sy'n eu dosrannu neu'n eu crybwyll yn y rhestr o bethau hanfodol. Nid yw'r fformat safonol yn addysgiadol iawn ac mae angen ei ehangu.
Yn bersonol, ychwanegais request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Rydym yn plotio amser ymateb a nifer y gwallau:
Rydym yn adeiladu graffiau o amser ymateb a nifer y gwallau. Cofiwch? Wnes i siarad am dasgau busnes? I gyflym a heb wallau? Rydym eisoes wedi ymdrin â'r materion hyn gyda dwy siart. A gallwch chi eisoes ffonio'r gweinyddwyr ar ddyletswydd gan eu defnyddio.
Ond erys un broblem arall - er mwyn sicrhau bod achosion y digwyddiad yn cael eu dileu'n gyflym.
Datrys digwyddiad
Gellir rhannu'r broses gyfan o adnabod i ddatrys problem yn nifer o gamau:
- adnabod y broblem;
- hysbysu'r gweinyddwr ar ddyletswydd;
- ymateb i ddigwyddiad;
- dileu achosion.
Mae’n bwysig inni wneud hyn cyn gynted â phosibl. Ac os ar y camau o nodi problem ac anfon hysbysiad ni allwn ennill llawer o amser - bydd dau funud yn cael ei dreulio arnynt beth bynnag, yna mae'r rhai dilynol yn syml heb ei aredig maes ar gyfer gwelliannau.
Gadewch i ni ddychmygu bod ffôn y swyddog ar ddyletswydd wedi canu. Beth fydd e'n ei wneud? Chwiliwch am atebion i gwestiynau - beth dorrodd, ble torrodd, sut i ymateb? Dyma sut rydym yn ateb y cwestiynau hyn:
Yn syml, rydym yn cynnwys yr holl wybodaeth hon yn nhestun yr hysbysiad, yn rhoi dolen iddo i dudalen wiki sy'n disgrifio sut i ymateb i'r broblem hon, sut i'w datrys a'i dwysáu.
Nid wyf wedi dweud dim o hyd am yr haen ymgeisio a rhesymeg busnes. Yn anffodus, nid yw ein ceisiadau yn gweithredu casglu metrigau eto. Yr unig ffynhonnell o unrhyw wybodaeth o'r lefelau hyn yw logiau.
Cwpl o bwyntiau.
Yn gyntaf, ysgrifennwch logiau strwythuredig. Nid oes angen cynnwys cyd-destun yn nhestun y neges. Mae hyn yn eu gwneud yn anodd eu grwpio a'u dadansoddi. Mae Logstash yn cymryd amser hir i normaleiddio hyn i gyd.
Yn ail, defnyddiwch lefelau difrifoldeb yn gywir. Mae gan bob iaith ei safon ei hun. Yn bersonol, rwy'n gwahaniaethu ar bedair lefel:
- dim gwall;
- gwall ochr cleient;
- mae'r camgymeriad ar ein hochr ni, nid ydym yn colli arian, nid ydym yn ysgwyddo risgiau;
- Mae'r camgymeriad ar ein hochr ni, rydym yn colli arian.
Gadewch i mi grynhoi. Mae angen i chi geisio adeiladu monitro yn seiliedig ar resymeg busnes. Ceisiwch fonitro'r cais ei hun a gweithredu gyda metrigau fel nifer y gwerthiannau, nifer y cofrestriadau defnyddwyr newydd, nifer y defnyddwyr gweithredol ar hyn o bryd, ac ati.
Os yw eich busnes cyfan yn un botwm yn y porwr, mae angen i chi fonitro a yw'n clicio ac yn gweithio'n iawn. Nid yw'r gweddill i gyd o bwys.
Os nad oes gennych hwn, gallwch geisio dal i fyny ag ef mewn logiau cais, logiau Nginx, ac yn y blaen, fel y gwnaethom ni. Dylech fod mor agos â phosibl at y cais.
Mae metrigau system weithredu yn bwysig wrth gwrs, ond nid oes gan fusnes ddiddordeb ynddynt, nid ydym yn cael ein talu amdanynt.
Ffynhonnell: hab.com