Navê min Anton Baderin e. Ez li Navenda Teknolojiya Bilind dixebitim û rêveberiya pergalê dikim. Berî mehekê, konferansa me ya pargîdanî bi dawî bû, ku me ezmûna xwe ya berhevkirî bi civaka IT ya bajarê xwe re parve kir. Min li ser çavdêriya sepanên webê peyivî. Materyal ji bo asta ciwan an navîn, yê ku ev pêvajo ji sifrê ava nekir, hate armanc kirin.
Kevirê bingehîn yê her pergala çavdêriyê çareserkirina pirsgirêkên karsaziyê ye. Şopandina ji bo şopandinê tu eleqeya tu kesî nîne. Karsaz çi dixwaze? Ji ber ku her tişt zû û bê xeletî dixebite. Karsaz dixwazin çalak bin, da ku em bixwe pirsgirêkên di karûbarê de nas bikin û bi lez û bez wan çareser bikin. Ev, bi rastî, pirsgirêkên ku min tevahiya sala borî li ser projeyek ji bo yek ji xerîdarên me çareser kir.
Li ser projeyê
Proje yek ji mezintirîn bernameyên dilsoziyê li welêt e. Em arîkariya zincîreyên firotanê dikin ku bi navgîniya amûrên kirrûbirrê yên cihêreng ên wekî qertên bonus ve frekansa firotanê zêde bikin. Bi tevahî, proje 14 serîlêdanên ku li ser deh serveran têne xebitandin vedihewîne.
Di pêvajoya hevpeyivînê de, min gelek caran dît ku rêvebir her gav rast nêzikî çavdêriya serîlêdanên malperê nabin: gelek hîn jî li ser metrîkên pergala xebitandinê disekinin û carinan karûbaran dişopînin.
Di doza min de, pergala çavdêriya xerîdar berê li ser bingeha Icinga bû. Pirsgirêkên jorîn bi tu awayî çareser nekir. Pir caran xerîdar bixwe me di derheqê pirsgirêkan de agahdar kir, û pir caran jî, me bi tenê daneya têr nebû ku em bigihîjin binê sedemê.
Bi ser de, têgihiştinek zelal a bêwatebûna wê ya pêşdeçûna wê hebû. Ez difikirim ku yên ku bi Icinga re dizanin dê min fêm bikin. Ji ber vê yekê, me biryar da ku ji bo projeyê pergala çavdêriya serîlêdana webê bi tevahî ji nû ve dîzayn bikin.
Prometheus
Me Prometheus li ser sê nîşaneyên sereke hilbijart:
- Hejmarek mezin a metrîkên berdest. Li cem me 60 hezar kes hene. Bê guman, hêjayî gotinê ye ku em pirraniya wan bikar naynin (dibe ku ji sedî 95). Ji hêla din ve, ew hemî bi erzan in. Ji bo me, ev li gorî Icinga-ya ku berê hatî bikar anîn, ev giraniya din e. Di wê de, lêzêdekirina metrîkan êşek taybetî bû: yên heyî biha bûn (tenê li koda çavkaniyê ya her pêvekê binêre). Her pêvek di Bash an Python de skrîptek bû, ku destpêkirina wê di warê çavkaniyên ku tê xerckirin de biha ye.
- Ev pergal rêjeyek kêm çavkaniyan dixwe. 600 MB RAM, 15% ji yek core û çend deh IOPS ji bo hemî pîvanên me bes in. Bê guman, hûn neçar in ku hinardekarên metrîkan bimeşînin, lê ew hemî di Go-yê de têne nivîsandin û di heman demê de ne pir birçî ne. Ez nafikirim ku di rastiyên nûjen de ev pirsgirêk e.
- Hêza koçkirina Kubernetes peyda dike. Li gorî plansaziyên xerîdar, bijartî diyar e.
ELK
Berê, me têketin berhev nedikir û pêvajo nedikir. Kêmasî ji her kesî re diyar in. Me ELK hilbijart, ji ber ku jixwe ezmûna me ya vê pergalê hebû. Em tenê têketinên serîlêdanê li wir hilînin. Pîvanên sereke yên hilbijartinê lêgerîna tev-nivîsê û leza wê bûn.
Сlickhouse
Di destpêkê de, bijare li ser InfluxDB ket. Me pêdiviya berhevkirina têketinên Nginx, statîstîkên ji pg_stat_statements, û hilanîna daneyên dîrokî yên Prometheus fêm kir. Me ji Influx hez nekir ji ber ku ew dem bi dem dest pê kir ku hejmareke mezin ji bîranînê dixwe û têk çû. Wekî din, min xwest ku pirsan ji hêla remote_addr ve kom bikim, lê komkirina di vê DBMS-ê de tenê bi nîşanan e. Etîket biha ne (bîr), hejmara wan bi şertî sînorkirî ye.
Me dîsa dest bi lêgerîna xwe kir. Tiştê ku hewce bû databasek analîtîk bi xerckirina çavkaniyê hindik bû, bi tercîhî bi berhevkirina daneyê li ser dîskê.
Clickhouse van hemî pîvanan pêk tîne, û em çu carî ji hilbijartina xwe poşman nebûne. Em ti mîqdarek daneya awarte tê de nanivîsin (hejmara têketinê di hûrdemê de tenê pênc hezar e).
NewRelic
NewRelic di dîrokê de bi me re ye ji ber ku ew bijartina xerîdar bû. Em wê wekî APM bikar tînin.
Zabbix
Em Zabbix-ê bi taybetî bikar tînin da ku Qutiya Reş a API-yên cihêreng bişopînin.
Diyarkirina Nêzîkatiya Şopandinê
Me xwest ku peywirê ji hev derxînin û bi vî awayî nêzîkatiya şopandinê bi pergal bikin.
Ji bo vê yekê, min pergala me di astên jêrîn de dabeş kir:
- hardware û VMS;
- pergala xebatê;
- xizmetên pergalê, stoka nermalavê;
- bikaranînî;
- mantiqa bazirganî.
Çima ev nêzîkatî hêsan e:
- em dizanin ku berpirsiyarê xebata her astê kî ye û li ser vê yekê em dikarin hişyariyan bişînin;
- Em dikarin avahîsaziyê bikar bînin dema ku hişyariyan bitepisînin - dê ecêb be ku meriv hişyariyek li ser tunebûna databasê bişîne dema ku makîneya virtual bi tevahî peyda nebe.
Ji ber ku peywira me tespîtkirina binpêkirinên di xebata pergalê de ye, divê em di her astê de komek metrîkan ronî bikin ku dema nivîsandina qaîdeyên hişyariyê hêja ye ku bala xwe bidinê. Dûv re, em di astên "VMS", "Pergala xebitandinê" û "Xizmetên pergalê, stoka nermalavê" re derbas bibin.
makîneyên virtual
Mêvandar ji me re pêvajoyek, dîsk, bîranîn û torê veqetîne. Û pirsgirêkên me bi her du yên pêşîn re hebûn. Ji ber vê yekê, metrics:
Wextê dizî yê CPU - gava ku hûn makîneyek virtual li ser Amazon bikirin (mînak, t2.micro), divê hûn fêhm bikin ku ji we re ne bingehek tevahî pêvajoyê, lê tenê kotayek dema wê tê veqetandin. Û gava ku hûn wê westînin, dê pêvajoyê ji we were girtin.
Ev metric dihêle hûn demên weha bişopînin û biryaran bidin. Mînakî, gelo pêdivî ye ku meriv tarîfek qelewtir bigire an hilberandina peywirên paşîn û daxwazên API-yê li serverên cihêreng belav bike?
IOPS + CPU dema iowaitê - ji ber hin sedeman, gelek mêvandarên ewr guneh dikin ku bi têra xwe IOPS peyda nakin. Wekî din, bernameyek bi IOPS kêm ji bo wan ne argumanek e. Ji ber vê yekê, hêja ye ku CPU iowait berhev bike. Bi vê cotê grafîkan - bi IOPS kêm û li benda I/O ya bilind - hûn dikarin jixwe bi mêvandar re biaxivin û pirsgirêkê çareser bikin.
pergala xebatê ya
Metrîkên pergala xebitandinê:
- mîqdara bîra berdest li %;
- Çalakiya karanîna swap: vmstat swapin, swapout;
- hejmara inodên berdest û cîhê belaş li ser pergala pelan bi %
- barkirina navîn;
- hejmara girêdanên di tw dewletê de;
- tambûna tabloya contrack;
- Qalîteya torê dikare bi karanîna ss-ê, pakêta iproute2 were şopandin - nîşanek girêdanên RTT ji derana wê bistînin û wê li gorî porta dest bi kom bikin.
Di heman demê de di asta pergala xebitandinê de me saziyek weha wekî pêvajoyên me heye. Girîng e ku di pergalê de komek pêvajoyên ku di xebata wê de rolek girîng dilîzin nas bikin. Heke, wek nimûne, we çend pgpool hene, wê hingê hûn hewce ne ku ji bo her yek ji wan agahdarî berhev bikin.
Koma metrîkan wiha ye:
- CPUs;
- bîr di serî de niştecîh e;
- IO - bi tercîh di IOPS de;
- FileFd - vekin û sînor bikin;
- têkçûnên girîng ên rûpelê - bi vî rengî hûn dikarin fêm bikin ka çi pêvajo tê guheztin.
Em hemî çavdêriyê li Docker bicîh dikin, û em Şêwirmend bikar tînin da ku daneyên metrîkan berhev bikin. Li ser makîneyên din em pêvajo-exporter bikar tînin.
Karûbarên pergalê, stoka nermalavê
Her serîlêdan taybetmendiyên xwe hene, û dijwar e ku meriv komek taybetî ya metrîkan yekalî bike.
Koma gerdûnî ev e:
- rêjeya daxwazê;
- hejmara xeletiyan;
- latency;
- têrbûn.
Mînakên me yên herî berbiçav ên çavdêriya di vê astê de Nginx û PostgreSQL ne.
Di pergala me de karûbarê herî barkirî databas e. Di paşerojê de, me pir caran tengav bû ku em zanibin ka databas çi dike.
Me li ser dîskan barek bilind dît, lê têketinên hêdî bi rastî tiştek nîşan nedan. Me ev pirsgirêk bi karanîna pg_stat_statements, nêrînek ku statîstîkên pirsê berhev dike, çareser kir.
Ew hemî hewcedariyên admin e.
Em grafikên çalakiya daxwazên xwendin û nivîsandinê ava dikin:
Her tişt hêsan û zelal e, her daxwazek rengê xwe heye.
Mînakek bi heman rengî têketinên Nginx e. Ne ecêb e ku hindik kes wan parsek dikin an wan di navnîşa hewcedariyên xwe de binav dikin. Forma standard ne pir agahdar e û pêdivî ye ku were berfireh kirin.
Bi kesane, min request_time, upstream_response_time, body_bytes_sent, request_length, request_id lê zêde kir. Em dema bersivê û hejmara xeletiyan xêz dikin:
Em grafikên dema bersivê û hejmara xeletiyan ava dikin. Bîrveanîn? Ma min li ser armancên karsaziyê axivî? Bi lez û bê xeletî? Me berê van mijaran bi du tabloyan vegirtibû. Û hûn dikarin berê xwe bidin rêveberên ku peywira wan bikar tînin.
Lê pirsgirêkek din jî dimîne - ji bo tasfiyekirina bilez a sedemên bûyerê.
Çareserkirina bûyerê
Tevahiya pêvajoyê ji tespîtkirina pirsgirêkê heya çareserkirina pirsgirêkê dikare li çend gavan were dabeş kirin:
- tespîtkirina pirsgirêkê;
- agahdarî ji rêveberê peywirê re;
- bersiva bûyerek;
- rakirina sedeman.
Girîng e ku em bi lez û bez vê yekê bikin. Û heke di qonaxên tespîtkirina pirsgirêkê û şandina agahiyekê de em nikaribin pir dem bi dest bixin - di her rewşê de dê du hûrdeman li ser wan were xerc kirin, wê hingê yên paşîn ji bo çêtirkirinan tenê zeviyên nehfkirî ne.
Em bifikirin ku telefona efserê wezîfedar lêxist. Ew ê çi bike? Li bersiva pirsan bigerin - çi şikest, li ku şikest, meriv çawa bertek nîşan dide? Li vir em çawa bersiva van pirsan didin:
Em bi tenê van hemî agahdarî di nav nivîsa ragihandinê de vedihewînin, lînka rûpelek wiki didin ku meriv çawa bersivê dide vê pirsgirêkê, meriv çawa çareser dike û mezin dike.
Min hîn jî di derbarê qata serîlêdanê û mantiqa karsaziyê de tiştek negot. Mixabin, serîlêdanên me hîn berhevkirina metrîkan pêk naynin. Çavkaniya yekane ya agahdariya van astan têketin in.
Çend xal.
Pêşîn, têketinên sazkirî binivîsin. Ne hewce ye ku di metna peyamê de çarçoveyek were danîn. Ev yek komkirin û analîzkirina wan zehmet dike. Logstash ji bo normalîzekirina van hemî demek dirêj digire.
Ya duyemîn, astên giraniyê rast bikar bînin. Her zimanek standardek xwe heye. Bi kesane, ez çar astan cuda dikim:
- bê xeletî;
- xeletiya aliyê muwekîlê;
- xeletî li ser milê me ye, em pereyan winda nakin, em rîskan nagirin;
- Xeletî di aliyê me de ye, em pereyan winda dikin.
Ez bi kurtî bibêjim. Pêdivî ye ku hûn hewl bidin ku çavdêriya li ser bingeha mantiqa karsaziyê ava bikin. Biceribînin ku serîlêdanê bixwe bişopînin û bi pîvanên wekî hejmara firotanê, hejmara qeydên bikarhênerên nû, hejmara bikarhênerên heyî yên çalak, û hwd.
Ger tevahiya karsaziya we di gerokê de yek bişkok e, hûn hewce ne ku çavdêriyê bikin ka ew bitikîne û bi rêkûpêk dixebite. Hemî yên din ne girîng in.
Heke we ev tune, hûn dikarin hewl bidin ku wê di têketinên serîlêdanê, têketinên Nginx, û hwd de, wekî ku me kir, bi dest bixin. Divê hûn bi qasî ku gengaz nêzikî serîlêdanê bin.
Metrîkên pergala xebitandinê bê guman girîng in, lê karsaz bi wan re eleqedar nabe, em ji bo wan nayên dayîn.
Source: www.habr.com