Í dag, auk einhæfs kóða, inniheldur verkefnið okkar heilmikið af örþjónustum. Hver þeirra þarf að vera undir eftirliti. Að gera þetta á slíkum mælikvarða með DevOps verkfræðingum er vandamál. Við höfum þróað eftirlitskerfi sem virkar sem þjónusta fyrir þróunaraðila. Þeir geta sjálfstætt skrifað mælikvarða inn í vöktunarkerfið, notað þær, byggt mælaborð út frá þeim og tengt viðvörun við þær sem verða ræstar þegar viðmiðunarmörkum er náð. Fyrir DevOps verkfræðinga, aðeins innviði og skjöl.
Þessi færsla er afrit af ræðu minni við okkar hjá RIT++. Margir báðu okkur að gera textaútgáfur af skýrslum þaðan. Ef þú varst á ráðstefnunni eða horfðir á myndbandið finnurðu ekkert nýtt. Og allir aðrir - velkomnir í köttinn. Ég skal segja þér hvernig við komum að slíku kerfi, hvernig það virkar og hvernig við ætlum að uppfæra það.
Fortíðin: áætlanir og áætlanir
Hvernig komumst við að núverandi eftirlitskerfi? Til að svara þessari spurningu þarftu að fara til 2015. Svona leit þetta út þá:
Við vorum með um 24 hnúta sem voru ábyrgir fyrir eftirliti. Það er heill pakki af mismunandi krónum, skriftum, púkum sem einhvern veginn fylgjast með einhverju, senda skilaboð og framkvæma aðgerðir. Við töldum að því lengra sem við gengum þeim mun minna hagkvæmt væri slíkt kerfi. Það þýðir ekkert að þróa það: það er of fyrirferðarmikið.
Við ákváðum að velja þá vöktunarþætti sem við munum halda og þróa og þá sem við munum yfirgefa. Þeir voru 19. Eftir stóðu aðeins grafít, safntæki og Grafana sem mælaborð. En hvernig mun nýja kerfið líta út? Svona:
Við erum með mælingargeymslu: þetta eru grafít sem munu byggjast á hröðum SSD drifum, þetta eru ákveðnir einingar fyrir mælikvarða. Næst - Grafana til að sýna mælaborð og Moira til að gera viðvörun. Við vildum líka þróa kerfi til að leita að frávikum.
Staðall: Vöktun 2.0
Svona litu áætlanirnar út árið 2015. En við þurftum ekki bara að undirbúa innviðina og þjónustuna sjálfa heldur líka skjölin fyrir hana. Við höfum þróað fyrirtækjastaðal fyrir okkur, sem við köllum vöktun 2.0. Hvaða kröfur voru gerðar til kerfisins?
- stöðugt framboð;
- geymslubil mæligilda = 10 sekúndur;
- skipulögð geymsla á mæligildum og mælaborðum;
- SLA > 99,99%
- söfnun atburðamælinga í gegnum UDP (!).
Okkur vantaði UDP vegna þess að við höfum mikið flæði umferðar og atburða sem búa til mælikvarða. Ef þú skrifar þær allar í grafít í einu mun geymslan hrynja. Við völdum líka fyrsta stigs forskeyti fyrir allar mælingar.
Hvert forskeyti hefur einhverja eiginleika. Það eru mælikvarðar fyrir netþjóna, net, gáma, auðlindir, forrit og svo framvegis. Skýr, ströng, slegin síun hefur verið innleidd, þar sem við samþykkjum fyrsta stigs mæligildi og sleppum einfaldlega restinni. Þannig skipulögðum við þetta kerfi árið 2015. Hvað er í nútímanum?
Til staðar: skýringarmynd af samspili vöktunarþátta
Í fyrsta lagi fylgjumst við með forritum: PHP kóðanum okkar, forritum og örþjónustu - í stuttu máli, allt sem verktaki okkar skrifa. Öll forrit senda mælikvarða í gegnum UDP til Brubeck safnara (statsd, endurskrifað í C). Hann reyndist fljótastur í gerviprófunum. Og það sendir þegar samansafnaðar mæligildi til Graphite í gegnum TCP.
Það hefur tegund mæligilda sem kallast tímamælir. Þetta er mjög þægilegur hlutur. Til dæmis, fyrir hverja notendatengingu við þjónustuna, sendir þú mæligildi með viðbragðstíma til Brubeck. Milljón svör bárust, en safnarinn skilaði aðeins 10 mælingum. Þú hefur fjölda fólks sem kom, hámarks-, lágmarks- og meðalviðbragðstíma, miðgildi og 4 hundraðshlutar. Síðan eru gögnin flutt yfir á Graphite og við sjáum þetta allt í beinni.
Við erum líka með samansafn fyrir mælikvarða á vélbúnaði, hugbúnaði, kerfismælingum og gamla Munin eftirlitskerfinu okkar (það virkaði fyrir okkur til 2015). Við söfnum þessu öllu í gegnum C púkann CollectD (hann er með fullt af mismunandi viðbótum innbyggt í það, það getur kannað allar auðlindir gestgjafakerfisins sem það er sett upp á, bara tilgreinið í stillingunum hvar á að skrifa gögnin) og skrifaðu gögnin í Graphite í gegnum það. Það styður einnig python viðbætur og skeljaforskriftir, svo þú getur skrifað þínar eigin sérsniðnar lausnir: CollectD mun safna þessum gögnum frá staðbundnum eða fjarlægum gestgjafa (miðað við Curl) og senda þau til Graphite.
Síðan sendum við allar mælingar sem við söfnuðum til Carbon-c-relay. Þetta er Carbon Relay lausnin frá Graphite, breytt í C. Þetta er beini sem safnar öllum mæligildum sem við sendum frá aggregatorum okkar og beinir þeim til hnúta. Einnig á leiðarstigi athugar það gildi mælikvarða. Í fyrsta lagi verða þau að samsvara forskeytikerfinu sem ég sýndi áðan og í öðru lagi gilda þau fyrir grafít. Annars munu þeir falla.
Carbon-c-relay sendir síðan mælikvarðana til grafítklasans. Við notum Carbon-skyndiminni, endurskrifað í Go, sem aðal geymsla mæligilda. Go-carbon, vegna fjölþráða, er miklu betri en Carbon-skyndiminni. Það tekur á móti gögnum og skrifar þau á diska með því að nota whisper pakkann (venjulegur, skrifaður í python). Til að lesa gögn úr geymslum okkar notum við Graphite API. Það er miklu hraðari en venjulegur Graphite WEB. Hvað verður um gögnin næst?
Þau fara til Grafana. Við notum grafítklasa okkar sem aðaluppsprettu gagna, auk þess sem við höfum Grafana sem vefviðmót til að sýna mælikvarða og byggja upp mælaborð. Fyrir hverja þjónustu þeirra búa verktaki til sitt eigið mælaborð. Síðan byggja þeir línurit út frá þeim, sem sýna mælikvarðana sem þeir skrifa úr forritunum sínum. Auk Grafana erum við líka með SLAM. Þetta er python púki sem reiknar SLA út frá gögnum frá grafít. Eins og ég sagði þegar, höfum við nokkra tugi örþjónustu, sem hver um sig hefur sínar kröfur. Með því að nota SLAM förum við í skjölin og berum þau saman við það sem er í Graphite og berum saman hversu vel kröfurnar passa við framboð þjónustu okkar.
Við skulum ganga lengra: viðvörun. Það er skipulagt með því að nota sterkt kerfi - Moira. Hann er sjálfstæður vegna þess að hann hefur sitt eigið grafít undir hettunni. Hannað af strákunum frá SKB "Kontur", skrifað í python og Go, algjörlega opinn uppspretta. Moira fær sama flæði og fer í grafít. Ef geymslan þín deyr af einhverjum ástæðum mun viðvörun þín samt virka.
Við sendum Moira í Kubernetes; það notar þyrping af Redis netþjónum sem aðalgagnagrunninn. Niðurstaðan var bilunarþolið kerfi. Það ber saman mæligildisstrauminn við listann yfir kveikjur: ef það er ekkert minnst á það, þá sleppir það mæligildinu. Þannig að það er fær um að melta gígabæta af mælingum á mínútu.
Við tengdum einnig fyrirtækja-LDAP við það, með hjálp þess getur hver notandi fyrirtækjakerfisins búið til tilkynningar fyrir sig út frá núverandi (eða nýstofnum) kveikjum. Þar sem Moira inniheldur grafít styður það alla eiginleika þess. Svo þú tekur fyrst línuna og afritar hana inn í Grafana. Sjáðu hvernig gögnin birtast á línuritunum. Og svo tekur þú sömu línu og afritar hana inn í Moira. Þú hangir það með takmörkunum og færð viðvörun við úttakið. Til að gera allt þetta þarftu enga sérstaka þekkingu. Moira getur látið vita með SMS, tölvupósti, Jira, Slack... Það styður einnig framkvæmd sérsniðinna forskrifta. Þegar kveikja kemur fyrir hana, og hún er áskrifandi að sérsniðnu handriti eða tvíundarskrá, keyrir hún það og sendir JSON til stdin fyrir þetta tvíliða. Í samræmi við það verður forritið þitt að flokka það. Hvað þú munt gera með þessum JSON er undir þér komið. Ef þú vilt, sendu það til Telegram, ef þú vilt, opnaðu verkefni í Jira, gerðu hvað sem er.
Við notum líka okkar eigin þróun til að gera viðvörun - Imagotag. Við aðlöguðum spjaldið, sem venjulega er notað fyrir rafræna verðmiða í verslunum, að okkar þörfum. Við komum með kveikjur frá Moira til þess. Það gefur til kynna í hvaða ástandi þeir eru og hvenær þeir áttu sér stað. Sumir af þróunarstrákunum yfirgáfu tilkynningar í Slack og tölvupósti í þágu þessa spjalds.
Jæja, þar sem við erum framsækið fyrirtæki, fylgdumst við líka með Kubernetes í þessu kerfi. Við settum það inn í kerfið með því að nota Heapster, sem við settum upp í klasanum, það safnar gögnum og sendir það til Graphite. Fyrir vikið lítur skýringarmyndin svona út:
Vöktunaríhlutir
Hér er listi yfir tengla á íhlutina sem við notuðum fyrir þetta verkefni. Öll eru þau opinn uppspretta.
Grafít:
- go-carbon:
- hvísla:
- grafít-api:
Kolefni-c-gengi:
Brubeck:
Safnað:
Moira:
Grafana:
Hrúga:
Tölfræði
Og hér eru nokkrar tölur um hvernig kerfið virkar fyrir okkur.
Aggregator (brubeck)
Fjöldi mælikvarða: ~300/sek
Tímabil til að senda mælikvarða til grafít: 30 sek
Aðfanganotkun netþjóns: ~ 6% CPU (við erum að tala um fullgilda netþjóna); ~ 1Gb vinnsluminni; ~3 Mbps staðarnet
Grafít (go-carbon)
Fjöldi mælikvarða: ~ 1 / mín
Tímabil uppfærslu mælinga: 30 sek
Geymslukerfi mælikvarða: 30sek 35d, 5min 90d, 10min 365d (veitir þér skilning á því hvað verður um þjónustuna yfir langan tíma)
Aðfanganotkun netþjóns: ~10% CPU; ~ 20Gb vinnsluminni; ~30 Mbps staðarnet
Sveigjanleiki
Við hjá Avito metum virkilega sveigjanleika í eftirlitsþjónustu okkar. Af hverju varð hann eiginlega svona? Í fyrsta lagi eru íhlutir þess skiptanlegir: bæði íhlutirnir sjálfir og útgáfur þeirra. Í öðru lagi, stuðningshæfni. Þar sem allt verkefnið er opinn uppspretta geturðu breytt kóðanum sjálfur, gert breytingar og innleitt aðgerðir sem eru ekki tiltækar strax. Nokkuð algengir staflar eru notaðir, aðallega Go og Python, svo þetta er einfaldlega gert.
Hér er dæmi um raunverulegt vandamál. Mæling í grafíti er skrá. Það hefur nafn. Skráarnafn = mæligildisheiti. Og það er leið til að komast þangað. Skráarnöfn í Linux eru takmörkuð við 255 stafi. Og við höfum (sem „innri viðskiptavinir“) krakkar úr gagnagrunnsdeildinni. Þeir segja okkur: „Við viljum fylgjast með SQL fyrirspurnum okkar. Og þeir eru ekki 255 stafir, heldur 8 MB hver. Við viljum sýna þær í Grafana, sjá breytur fyrir þessa beiðni og enn betra, við viljum sjá toppinn á slíkum beiðnum. Það verður frábært ef það er sýnt í rauntíma. Það væri mjög flott að setja þá í viðvörun.“
Dæmi um SQL fyrirspurn er tekin sem dæmi frá
Við setjum upp Redis netþjón og notum Collectd viðbætur okkar, sem fara í Postgres og taka öll gögn þaðan og senda mælikvarða til Graphite. En við skiptum út metraheitinu fyrir kjötkássa. Við sendum samtímis sama kjötkássa til Redis sem lykil og alla SQL fyrirspurnina sem gildi. Það eina sem við þurfum að gera er að tryggja að Grafana geti farið til Redis og tekið þessar upplýsingar. Við erum að opna Graphite API vegna þess að... þetta er aðalviðmótið fyrir samspil allra vöktunarþátta við grafít, og þar sláum við inn nýja aðgerð sem heitir aliasByHash() - frá Grafana fáum við nafn mæligildisins, og notum það í beiðni til Redis sem lykil, í svar fáum við gildi lykilsins, sem er „SQL fyrirspurn“ okkar. Þannig sýndum við í Grafana skjá á SQL fyrirspurn, sem fræðilega séð var ómögulegt að birta þar, ásamt tölfræði um hana (símtöl, raðir, heildartími, ...).
Niðurstöður
Framboð. Eftirlitsþjónusta okkar er í boði allan sólarhringinn frá hvaða forriti sem er og hvaða kóða sem er. Ef þú hefur aðgang að geymsluaðstöðu geturðu skrifað gögn í þjónustuna. Tungumálið skiptir ekki máli, ákvarðanirnar eru ekki mikilvægar. Þú þarft aðeins að vita hvernig á að opna fals, setja mælistiku þar og loka innstungunni.
Надежность. Allir íhlutir eru bilunarþolnir og fara vel með farminn okkar.
Lítil aðgangshindrun. Til þess að nota þetta kerfi þarftu ekki að læra forritunarmál og fyrirspurnir í Grafana. Opnaðu bara forritið þitt, sláðu inn fals í það sem mun senda mælikvarða til Graphite, loka því, opna Grafana, búa til mælaborð þar og skoða hegðun mæligildanna þinna, fá tilkynningar í gegnum Moira.
Sjálfstæði. Þú getur gert allt þetta sjálfur, án aðstoðar DevOps verkfræðinga. Og þetta er kostur, vegna þess að þú getur fylgst með verkefninu þínu núna, þú þarft ekki að spyrja neinn - annað hvort að hefja vinnu eða gera breytingar.
Að hverju erum við að stefna?
Allt sem talið er upp hér að neðan er ekki bara abstrakt hugsanir, heldur eitthvað sem að minnsta kosti fyrstu skrefin hafa verið tekin í átt að.
- Fráviksskynjari. Við viljum búa til þjónustu sem mun fara í grafítgeymslurnar okkar og athuga hverja mælingu með ýmsum reikniritum. Það eru nú þegar til reiknirit sem við viljum skoða, það eru gögn, við vitum hvernig á að vinna með þau.
- Lýsigögn. Við höfum marga þjónustu, hún breytist með tímanum, alveg eins og fólkið sem vinnur með henni. Það er ekki valkostur að viðhalda skjölum stöðugt handvirkt. Þess vegna erum við nú að fella lýsigögn inn í örþjónustur okkar. Þar kemur fram hver þróaði það, tungumálin sem það hefur samskipti við, SLA kröfur, hvert og til hvers tilkynningar eigi að senda. Þegar þjónustu er innleitt eru öll einingagögn búin til sjálfstætt. Fyrir vikið færðu tvo tengla - annan á kveikjur, hinn á mælaborð í Grafana.
- Eftirlit á hverju heimili. Við teljum að allir verktaki ættu að nota slíkt kerfi. Í þessu tilviki skilurðu alltaf hvar umferðin þín er, hvað verður um hana, hvar hún fellur, hvar veikleikar hennar eru. Ef, til dæmis, eitthvað kemur og hrynur þjónustu þína, þá muntu læra um það ekki í símtali frá stjórnanda, heldur frá viðvörun, og þú getur strax opnað nýjustu skrárnar og séð hvað gerðist þar.
- Mikil afköst. Verkefnið okkar er stöðugt að stækka og í dag vinnur það um 2 metragildi á mínútu. Fyrir ári síðan var þessi tala 000. Og vöxturinn heldur áfram, og þetta þýðir að eftir nokkurn tíma mun Grafít (hvísl) byrja að hlaða mikið undirkerfi disksins. Eins og ég sagði þegar er þetta eftirlitskerfi alveg alhliða vegna skiptanlegs íhluta. Einhver heldur við og stækkar stöðugt innviði sína sérstaklega fyrir Graphite, en við ákváðum að fara aðra leið: nota sem geymsla fyrir mælikvarða okkar. Þessum umskiptum er nánast lokið, og mjög fljótlega mun ég segja þér nánar hvernig þetta var gert: hvaða erfiðleikar voru og hvernig þeir voru yfirstignir, hvernig flutningsferlið gekk, ég mun lýsa íhlutunum sem voru valdir sem bindandi og stillingar þeirra.
Takk fyrir athyglina! Spyrðu spurninga þinna um efnið, ég mun reyna að svara hér eða í eftirfarandi færslum. Kannski hefur einhver reynslu af því að byggja svipað eftirlitskerfi eða skipta yfir í Clickhouse í svipaðri stöðu - deildu því í athugasemdunum.
Heimild: www.habr.com