Ég heiti Anton Baderin. Ég vinn á Hátæknisetrinu og stunda kerfisstjórnun. Fyrir mánuði síðan lauk fyrirtækjaráðstefnu okkar, þar sem við deildum uppsafnaðri reynslu okkar með upplýsingatæknisamfélaginu í borginni okkar. Ég talaði um að fylgjast með vefforritum. Efnið var ætlað yngri eða miðstigi, sem byggðu þetta ferli ekki upp frá grunni.
Hornsteinninn að baki hverju eftirlitskerfi er að leysa viðskiptavandamál. Vöktun í þágu eftirlits kemur engum til greina. Hvað vill fyrirtæki? Svo að allt virki hratt og villulaust. Fyrirtæki vilja vera fyrirbyggjandi þannig að við sjálf greinum vandamál í þjónustunni og lagum þau eins fljótt og auðið er. Þetta eru í raun vandamálin sem ég leysti allt síðasta ár í verkefni fyrir einn af viðskiptavinum okkar.
Um verkefnið
Verkefnið er eitt stærsta tryggðarkerfi landsins. Við hjálpum verslunarkeðjum að auka sölutíðni með ýmsum markaðstækjum eins og bónuskortum. Alls inniheldur verkefnið 14 forrit sem keyra á tíu netþjónum.
Í viðtalsferlinu tók ég ítrekað eftir því að stjórnendur nálgast eftirlit með vefforritum ekki alltaf rétt: margir einblína enn á mælikvarða stýrikerfisins og fylgjast stundum með þjónustu.
Í mínu tilviki var eftirlitskerfi viðskiptavinarins áður byggt á Icinga. Það leysti ekki ofangreind vandamál á nokkurn hátt. Oft upplýsti viðskiptavinurinn okkur sjálfur um vandamál og oftar en ekki höfðum við einfaldlega ekki næg gögn til að komast til botns í ástæðunni.
Auk þess var skýr skilningur á tilgangsleysi frekari þróunar þess. Ég held að þeir sem þekkja til Icinga skilji mig. Þannig að við ákváðum að endurhanna eftirlitskerfi vefforrita fyrir verkefnið algjörlega.
Prometheus
Við völdum Prometheus út frá þremur meginvísum:
- Mikill fjöldi tiltækra mælikvarða. Í okkar tilviki eru þeir 60 þúsund. Auðvitað er rétt að taka fram að við notum ekki langflest þeirra (líklega um 95%). Aftur á móti eru þeir allir tiltölulega ódýrir. Fyrir okkur er þetta hin öfga miðað við áður notaða Icinga. Í því var það sérstakt verk að bæta við mælingum: þær sem fyrir voru voru dýrar (sjáðu bara frumkóðann hvers konar viðbóta). Hvaða tappi sem er var handrit í Bash eða Python, opnun þess er dýr með tilliti til auðlinda sem neytt er.
- Þetta kerfi eyðir tiltölulega litlu magni af auðlindum. 600 MB af vinnsluminni, 15% af einum kjarna og nokkrir tugir IOPS eru nóg fyrir alla mælikvarða okkar. Auðvitað þarf að reka mælikvarðaútflytjendur, en þeir eru allir skrifaðir í Go og eru heldur ekki mjög orkusvangir. Ég held að í nútíma veruleika sé þetta ekki vandamál.
- Veitir möguleika á að flytja til Kubernetes. Miðað við áætlanir viðskiptavinarins er valið augljóst.
ELK
Áður söfnuðum við hvorki né unnum annálum. Gallarnir eru öllum ljósir. Við völdum ELK vegna þess að við höfðum þegar reynslu af þessu kerfi. Við geymum aðeins forritaskrár þar. Helstu valforsendur voru fulltextaleit og hraði hennar.
Slickhouse
Upphaflega féll valið á InfluxDB. Við gerðum okkur grein fyrir þörfinni á að safna Nginx annálum, tölfræði úr pg_stat_statements og geyma Prometheus söguleg gögn. Okkur líkaði ekki Influx vegna þess að það byrjaði reglulega að eyða miklu minni og hrundi. Að auki vildi ég flokka fyrirspurnir eftir remote_addr, en flokkun í þessu DBMS er aðeins með tögum. Merki eru dýr (minni), fjöldi þeirra er takmarkaður með skilyrðum.
Við hófum leitina aftur. Það sem þurfti var greiningargagnagrunnur með lágmarks auðlindanotkun, helst með gagnaþjöppun á diski.
Clickhouse uppfyllir öll þessi skilyrði og við höfum aldrei séð eftir vali okkar. Við skrifum ekkert óvenjulegt magn af gögnum inn í það (fjöldi innsetninga er aðeins um fimm þúsund á mínútu).
NewRelic
NewRelic hefur í gegnum tíðina verið með okkur vegna þess að það var val viðskiptavinarins. Við notum það sem APM.
Zabbix
Við notum Zabbix eingöngu til að fylgjast með Black Box ýmissa API.
Að skilgreina eftirlitsaðferð
Við vildum sundurliða verkefnið og kerfisbinda þar með nálgunina við eftirlitið.
Til að gera þetta skipti ég kerfinu okkar í eftirfarandi stig:
- vélbúnaður og VMS;
- stýrikerfi;
- kerfisþjónusta, hugbúnaðarstafla;
- umsókn;
- viðskiptarökfræði.
Af hverju þessi aðferð er þægileg:
- við vitum hver ber ábyrgð á starfi hvers stigs og út frá þessu getum við sent áminningar;
- við getum notað uppbygginguna þegar við bælum viðvaranir - það væri skrítið að senda viðvörun um óaðgengi gagnagrunns þegar sýndarvélin í heild er ekki tiltæk.
Þar sem verkefni okkar er að bera kennsl á brot í rekstri kerfisins, verðum við á hverju stigi að draga fram ákveðinn mælikvarða sem vert er að gefa gaum þegar viðvörunarreglur eru skrifaðar. Næst skulum við fara í gegnum stigin „VMS“, „Stýrikerfi“ og „Kerfisþjónusta, hugbúnaðarstafla“.
Sýndarvélar
Hýsing úthlutar okkur örgjörva, disk, minni og neti. Og við áttum í vandræðum með fyrstu tvo. Svo, mælikvarðar:
CPU stolinn tími - þegar þú kaupir sýndarvél á Amazon (t.d. t2.micro) ættirðu að skilja að þér er ekki úthlutað heilum örgjörvakjarna, heldur aðeins kvóta af sínum tíma. Og þegar þú klárar hann verður örgjörvinn tekinn frá þér.
Þessi mælikvarði gerir þér kleift að fylgjast með slíkum augnablikum og taka ákvarðanir. Er til dæmis nauðsynlegt að taka feitari gjaldskrá eða dreifa vinnslu bakgrunnsverkefna og API beiðna á mismunandi netþjóna?
IOPS + CPU biðtími - af einhverjum ástæðum syndga margar skýhýsingar með því að veita ekki nóg IOPS. Þar að auki er áætlun með lágum IOPS ekki rök fyrir þeim. Þess vegna er það þess virði að safna CPU iowait. Með þessu grafi - með lágum IOPS og mikilli I/O bið - geturðu nú þegar talað við hýsingaraðilann og leyst vandamálið.
Stýrikerfi
Stýrikerfismælingar:
- magn af tiltæku minni í %;
- skipta um notkun: vmstat skipta, skipta út;
- fjöldi tiltækra inóta og laust pláss á skráarkerfinu í %
- meðalálag;
- fjöldi tenginga í tw ástandi;
- conntrack borð fylling;
- Hægt er að fylgjast með gæðum netsins með því að nota ss tólið, iproute2 pakkann - fáðu vísbendingu um RTT tengingar frá framleiðslu þess og flokkaðu það eftir dest porti.
Einnig á stýrikerfisstigi höfum við slíka einingu eins og ferli. Mikilvægt er að greina í kerfinu safn ferla sem gegna mikilvægu hlutverki í rekstri þess. Ef þú ert til dæmis með nokkra pgpools, þá þarftu að safna upplýsingum fyrir hvern þeirra.
Mælasamstæðan er sem hér segir:
- ÖRGJÖRVI;
- minnið er fyrst og fremst búsett;
- IO - helst í IOPS;
- FileFd - opna og takmarka;
- verulegar síðubilanir - þannig geturðu skilið hvaða ferli er verið að skipta um.
Við setjum upp allt eftirlit í Docker og við notum Advisor til að safna mæligögnum. Á öðrum vélum notum við process-exporter.
Kerfisþjónusta, hugbúnaðarstafla
Hvert forrit hefur sína sérstöðu og það er erfitt að útskýra tiltekið sett af mæligildum.
Alhliða settið er:
- beiðni hlutfall;
- fjöldi mistaka;
- leynd;
- mettun.
Mest sláandi dæmi okkar um eftirlit á þessu stigi eru Nginx og PostgreSQL.
Mest hlaðna þjónustan í kerfinu okkar er gagnagrunnurinn. Áður fyrr áttum við oft í vandræðum með að átta okkur á hvað gagnagrunnurinn var að gera.
Við sáum mikið álag á diskunum, en hægu skrárnar sýndu í raun ekki neitt. Við leystum þetta vandamál með því að nota pg_stat_statements, útsýni sem safnar tölfræði fyrirspurna.
Það er allt sem admin þarf.
Við smíðum línurit af virkni lestrar- og skrifabeiðna:
Allt er einfalt og skýrt, hver beiðni hefur sinn lit.
Jafn sláandi dæmi er Nginx logs. Það kemur ekki á óvart að fáir flokka þau eða nefna þau á listanum yfir nauðsynleg atriði. Staðlað snið er ekki mjög upplýsandi og þarf að stækka það.
Sjálfur bætti ég við request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Við teiknum upp svartíma og fjölda villna:
Við smíðum línurit yfir viðbragðstíma og fjölda villna. Manstu? Talaði ég um viðskiptamarkmið? Til fljótt og án villna? Við höfum þegar fjallað um þessi mál með tveimur töflum. Og þú getur nú þegar hringt í stjórnendur á vakt með því að nota þá.
En enn er enn eitt vandamálið - að tryggja skjóta útrýmingu á orsökum atviksins.
Úrlausn atviks
Skipta má öllu ferlinu frá því að greina til að leysa vandamál í nokkur skref:
- að bera kennsl á vandamálið;
- tilkynning til vaktstjóra;
- viðbrögð við atviki;
- útrýming á orsökum.
Það er mikilvægt að við verðum að gera þetta eins fljótt og auðið er. Og ef við getum ekki unnið mikinn tíma á þeim stigum að bera kennsl á vandamál og senda tilkynningu - tveimur mínútum verður varið í þau í öllum tilvikum, þá eru þær síðari einfaldlega óplægðar til úrbóta.
Ímyndum okkur að síminn hjá vaktstjóranum hafi hringt. Hvað mun hann gera? Leitaðu að svörum við spurningum - hvað bilaði, hvar brotnaði það, hvernig á að bregðast við? Svona svörum við þessum spurningum:
Við tökum einfaldlega allar þessar upplýsingar inn í texta tilkynningarinnar, gefum þeim hlekk á wiki-síðu sem lýsir hvernig eigi að bregðast við þessu vandamáli, hvernig eigi að leysa það og auka það.
Ég hef enn ekki sagt neitt um umsóknarlagið og viðskiptarökfræði. Því miður innleiða forritin okkar ekki enn mælingasöfnun. Eina uppspretta allra upplýsinga frá þessum stigum er logs.
Nokkrir punktar.
Fyrst skaltu skrifa skipulagða annála. Það er engin þörf á að setja samhengi í texta skilaboðanna. Þetta gerir þá erfitt að flokka og greina. Logstash tekur langan tíma að staðla þetta allt.
Í öðru lagi, notaðu alvarleikastig rétt. Hvert tungumál hefur sinn staðal. Persónulega greini ég á fjórum stigum:
- engin villa;
- villa við viðskiptavini;
- mistökin eru okkar megin, við töpum ekki peningum, við berum enga áhættu;
- Mistökin eru okkar megin, við töpum peningum.
Leyfðu mér að draga saman. Þú þarft að reyna að byggja upp vöktun byggt á viðskiptarökfræði. Reyndu að fylgjast með forritinu sjálfu og vinna með mælikvarða eins og fjölda sölu, fjölda nýrra notendaskráninga, fjölda virkra notenda og svo framvegis.
Ef allt fyrirtækið þitt er einn hnappur í vafranum þarftu að fylgjast með því hvort hann smelli og virki rétt. Allt hitt skiptir ekki máli.
Ef þú ert ekki með þetta geturðu reynt að ná því í forritaskrám, Nginx logs og svo framvegis, eins og við gerðum. Þú ættir að vera eins nálægt umsókninni og mögulegt er.
Stýrikerfismælingar eru auðvitað mikilvægar, en fyrirtæki hafa ekki áhuga á þeim, við fáum ekki borgað fyrir þær.
Heimild: www.habr.com