Sot dita, në projektin tonë, përveç kodit monolitik, funksionojnë dhjetëra mikrosherbime. Çdo njëri prej tyre kërkon vëmendje për monitorim. Të bësh këtë me forcat e inxhinierëve DevOps është problematike në këtë shkallë. Ne zhvilluam një sistem monitorimi, i cili funcion si shërbim për zhvilluesit. Ata mund të shkruajnë metrikat në sistemin e monitorimit, t'i përdorin ato, të ndërtojnë tablo mbi bazën e tyre dhe t'i lidhin me alarmin e cila aktivizohet kur arrihen vlerat kufizuese. Me inxhinierët DevOps — vetëm infrastruktura dhe dokumentacioni.
Ky post është një transkript i fjalimit tim në në RIT++. Shumë kërkuan që të bëjmë versione tekstuale të referatëve të atjeshëm. Nëse ishit në konferencë ose e shikoni videon, nuk do të gjeni asgjë të re. Të gjithë të tjerët — mirë se vini poshtë. Do të flas për mënyrën se si arritëm në këtë sistem, si funksionon dhe si planifikojmë ta azhurnojmë atë.
E kaluara: skemat dhe planet
Si arritëm në sistemin ekzistues të monitorimit? Për të përgjigjur në këtë pyetje, duhet të kthehemi në vitin 2015. Këtu është si dukej atëherë:
Nuk kishim rreth 24 nodë që merreshin me monitorimin. Këtu kishte një grup të tërë me cron-e të ndryshme, skripta, demonë, që monitoronin diçka diku në ndonjë mënyrë, dërgonin mesazhe, kryenin funksione. Menduam se sa më shumë të shkonim përpara, aq më pak kjo sistem do të ishte e qëndrueshme. Nuk kishte kuptim ta zhvillonim më tej: ishte shumë e rëndë.
Vendosëm të zgjedhim elementët e monitorimit që do t'i mbajmë dhe do t'i zhvillojmë, dhe ata nga të cilët do të hiqnim dorë. Ajo rezultoi të ishin 19. Mbeten vetëm grafitet, agregatorët dhe Grafana si tabllo. Por si do të dukej sistemi i ri? Kështu:
Kemi një depo të metrikave: këto janë grafite që do të bazohen në SSD të shpejtë, janë disa agregatorë për metrika. Pastaj — Grafana për daljen e tablave dhe Moira si alarm. Gjithashtu, do të dëshironim të zhvillonim një sistem për kërkimin e anomalive.
Standarti: Monitorimi 2.0
Kështu dukeshin planet në 2015. Por na duhej të përgatisnim jo vetëm infrastrukturën dhe shërbimin vetë, por edhe dokumentacionin për të. Ne zhvilluam një standard korporativ, të cilin e quajtëm monitorimi 2.0. Çfarë kërkesash kishim për sistemin?
- disponueshmëri të vazhdueshme;
- intervali i ruajtjes së metrikave = 10 sekonda;
- ruajtje e strukturuar e metrikave dhe tablave;
- SLA > 99,99%
- mblidhni metrika eventesh përmes UDP (!).
Na duhej UDP, pasi kishim një fluks të madh trafiku dhe ngjarjesh që gjeneronin metrika. Nëse do t'i shkruanim të gjitha në grafit menjëherë, depoja do të dështonte. Po ashtu, zgjodhëm prefikset e parë për të gjitha metrikat.
Çdo prefiks ka një pronësi të caktuar. Ka metrika për servera, rrjeta, kontejnerë, burime, aplikacione dhe kështu me radhë. U realizua një filtrimi i qartë, rigoroz dhe i tipizuar, ku pranojmë metrikat e nivelit të parë, ndërsa të tjerat i ndajmë thjesht. Kështu planifikuam të këtë sistem në 2015. Si duket tani?
E tashmja: skema e bashkëpunimit të komponentëve të monitorimit
Në radhë të parë monitorojmë aplikacionet: kodin tonë PHP, aplikacionet dhe mikrosherbimet — me fjalë të tjera, gjithçka që shkruajnë zhvilluesit tanë. Të gjitha aplikacionet dërgojnë metrikat në agregatorin Brubeck (statsd, e rishkruar në C) përmes UDP. Ai doli të ishte më i shpejtë sipas testeve sintetike. Dhe ai dërgon metrikat e agreguara në Graphite përmes TCP.
Ai ka një lloj metrikash si timerët. Kjo është një gjë shumë e dobishme. Për shembull, për çdo lidhje të përdoruesit me shërbimin dërgoni në Brubeck një metrikë me kohën e përgjigjes. Ka ardhur një milion përgjigje, dhe agregatori ka nxjerrë vetëm 10 metrika. Keni numrin e përdoruesve, maksimumin, minimun dhe mesataren e kohës së përgjigjes, median dhe 4 percentilat. Më pas të dhënat kalojnë në Graphite dhe i shohim ato në kohë reale.
Gjithashtu kemi agregim për metrikat lidhur me harduerin, softuerin, metrikat sistemore dhe sistemin tonë të vjetër të monitorimit Munin (ai ka funksionuar deri në vitin 2015). Të gjitha këto i mbledhim përmes demonit CollectD të C (në të është e integruar një grup i tërë me plugins të ndryshme, ai di të kontrollojë të gjitha burimet e sistemit host në të cilin është instaluar, thjesht tregoni në konfigurim ku të shkruani të dhënat) dhe i shkruajmë përmes tij të dhënat në Graphite. Gjithashtu mbështet plugins python dhe shell scripts, kështu që mund të shkruani zgjidhje të personalizuara: CollectD do të mbledhë këto të dhëna nga një host lokal ose të largët (supozoni, ka Curl) dhe do t'i dërgojë ato në Graphite.
Më pas, të gjitha metrikat që kemi mbledhur i dërgojmë në Carbon-c-relay. Ky është një zgjidhje Carbon Relay nga Graphite, e zhvilluar në C. Është një ruter që mbledh të gjitha metrikat që dërgojmë nga agregatorët tanë dhe i rrufton ato në node. Gjithashtu, gjatë fazës së rrujtjes kontrollon vlefshmërinë e metrikave. Së pari, ato duhet të përputhen me modelin e prefikseve që e tregova më parë dhe, së dyti, të jenë të vlefshme për Graphite. Në të kundërt, ato hidhen.
Pastaj, Carbon-c-relay dërgon metrikat në klasterin Graphite. Ne përdorim si ruajtje kryesore të metrikave Carbon-cache, të shkruara në Go. Go-carbon, për shkak të shumëthësisë së tij, është shumë më tërheqës nga pikëpamja e performancës se Carbon-cache. Ai pranon të dhënat dhe i regjistron ato në disqe duke përdorur paketën whisper (standard, e shkruar në python). Për të lexuar të dhënat nga ruajtjet tona, ne përdorim Graphite API. Ai punon shumë më shpejt se Graphite WEB standarde. Çfarë ndodh me të dhënat më pas?
Ato shkojnë në Grafana. Ne përdorim klasteret tona Graphite si burimin kryesor të të dhënave, dhe gjithashtu kemi Grafana si ndërfaqen web për shfaqjen e metrikave dhe ndërtimin e dashboard-eve. Çdo shërbim ka dashboard-in e vet të krijuar nga zhvilluesit. Më pas ata ndërtuan grafikët mbi të cilët shfaqen metrikat që ata dërgojnë nga aplikacionet e tyre. Përveç Grafana, ne kemi edhe SLAM. Ky është një demon në Python, i cili llogarit SLA-në në bazë të të dhënave nga Graphite. Siç kam përmendur më parë, ne kemi disa dhjetëra mikroshërbimesh, secila me kërkesat e saj. Me SLAM ne shkojmë në dokumentacion dhe e krahasojmë me atë që kemi në Graphite, duke krahasuar nëse kërkesat përputhen me disponueshmërinë e shërbimeve tona.
Të vazhdojmë: alertimi. Ai është organizuar me një sistem të fuqishëm — Moira. Ajo është e pavarur, sepse nën kapak ka Graphite të saj. E zhvilluar nga ekipi i SKB “Kontur”, e shkruar në python dhe Go, është plotësisht open-source. Moira merr të njëjtin fluks si ai që shkon në Graphite. Nëse për një arsye ndodhi që ruajtja të dështojë, atëherë alertimi juaj do të punojë.
Moira ne e kemi vendosur në Kubernetes, dhe përdor si bazë kryesore të dhënash klasterin e serverëve Redis. Rezultati është një sistem që e duron dështimin. Ajo krahasohet me fluksin e metrikave sipas listës së trigerëve: nëse nuk ka përmendje në të, ajo hidhet. Në këtë mënyrë, ajo mund të procesojë gigabajt metrikash në minutë.
Po ashtu, ne i kemi lidhur një LDAP korporative, me ndihmën e të cilit çdo përdorues i sistemit korporativ mund të krijojë njoftime për trigerët ekzistues (ose të rinj). Siç Moira përmban Graphite, ajo mbështet të gjitha funksionet e tij. Prandaj, ju së pari merrni një rresht dhe e kopjoni atë në Grafana. Shikoni si shfaqen të dhënat në grafikët. Më pas, merrni të njëjtin rresht dhe e kopjoni në Moira. E veshni atë me kufij dhe merrni në fund alertimin. Për të bërë të gjitha këto, nuk ju nevojiten njohuri specifike. Moira di të dërgojë njoftime për SMS, email, në Jira, Slack… Ajo gjithashtu mbështet ekzekutimin e skripteve të zakonshme. Kur ndodh një triger dhe ajo është e abonuar për një skript të zakonshem ose binar, ajo e ekzekuton atë dhe i jep JSON në stdin. Prandaj, programma juaj duhet ta analizojë atë. Çfarë do të bëni me këtë JSON, vendosni vetë. Nëse dëshironi, dërgoni në Telegram, nëse dëshironi, hapni detyrat në Jira, bëni çfarëdo që dëshironi.
Për alertimin, ne gjithashtu përdorim një zhvillim tonë të brendshëm — Imagotag. Ne e kemi përshtatur panelin që përdoret zakonisht për çmimet elektronike në dyqane për nevojat tona. Ne i kemi dalë për trigerat nga Moira. Aty është treguar se në cilin gjendje janë ato, kur ndodhi. Disa zhvillues e braktisën njoftimin në Slack dhe email në favor të këtij paneli.
Dhe pasi jemi një kompani progresive, ne gjithashtu monitorojmë Kubernetes në këtë sistem. E kemi përfshirë atë në sistem me ndihmën e Heapster, të cilin e kemi instaluar në klaster, ai mbledh të dhënat dhe i dërgon ato në Graphite. Si rezultat, skema duket kështu:
Komponentët e monitorimit
Ja një listë lidhjesh për komponentët që kemi përdorur për këtë detyrë. Të gjitha ato janë open-source.
Graphite:
- go-carbon:
- whisper:
- graphite-api:
Carbon-c-relay:
Brubeck:
Collectd:
Moira:
Grafana:
Heapster:
Statistika
Dhe këtu janë disa numra për mënyrën se si funksionon sistemi te ne.
Aggregator (brubeck)
Numri i metrikave: ~ 300 000 / sec
Intervali i dërgimit të metrikave në Graphite: 30 sec
Përdorimi i burimeve të serverit: ~ 6% CPU (bëhet fjalë për serverë të plotë); ~ 1Gb RAM; ~ 3 Mbps LAN
Graphite (go-carbon)
Numri i metrikave: ~ 1 600 000 / min
Intervali i përditësimit të metricave: 30 sek
Skema e ruajtjes së metricave: 30 sek 35 d, 5 min 90 d, 10 min 365 d (ofron kuptim për atë që po ndodh me shërbimin në një periudhë të gjatë kohore)
Përdorimi i burimeve të serverit: ~ 10% CPU; ~ 20Gb RAM; ~ 30 Mbps LAN
Fleksibiliteti
Ne në Avito e vlerësojmë shumë fleksibiliteten në shërbimin tonë të monitorimit. Pse, pra, ai është kështu? Së pari, komponentët e tij janë të ndërrueshëm: si komponentët vetë, ashtu edhe versionet e tyre. Së dyti — mbështetje. Duke qenë se e gjithë projekti është ndërtuar në opensoftware, ju mund të ndryshoni kodin vetë, të bëni ndryshime, mund të implementoni funksione që nuk janë të disponueshme nga kutia. Përdoren steka të njohura, kryesisht Go dhe Python, prandaj kjo bëhet mjaft lehtë.
Ja një shembull i një problemi real që është shfaqur. Metrika në Graphite — është një skedar. Ajo ka një emër. Emri i skedarit = emri i metricës. Dhe ka një rrugë deri te ajo. Emrat e skedarëve në Linux janë të kufizuar në 255 karaktere. Dhe ne kemi (si "këshilltarë të brendshëm") djemtë nga departamenti i bazës së të dhënave. Ata na thonë: "Dua të monitorojmë kërkesat tona SQL. Dhe ato — nuk janë 255 karaktere, por 8 MB çdo një. Duam të shohim parametrat e kësaj kërkese në Grafana, dhe akoma më mirë, duam të shohim topin e këtyre kërkesave. Do të ishte e mrekullueshme nëse do të shfaqej në kohë reale. Dhe do të ishte akoma më fantastike ta integronim atë në alarmin".
Shembulli i kërkesës SQL është marrë si shembull nga
Ne ngremë serverin Redis dhe me ndihmën e pluginëve tanë Collectd, që shkojnë në Postgres dhe marrin të dhënat nga aty, dërgojmë metricat në Graphite. Por zëvendësojmë emrin e metricës me hash. Ky hash dërgohet gjithashtu në Redis si çelës, dhe e gjithë kërkesa SQL si vlerë. Na mbetet të bëjmë që Grafana të dijë të shkojë në Redis dhe të marrë këtë informacion. Ne hapim Graphite API, sepse ky është ndërfaqja kryesore e ndërveprimit të të gjitha componenteve të monitorimit me graphite, dhe vendosim një funksion të ri, i quajtur aliasByHash() — nga Grafana marrim emrin e metricës, dhe e përdorim atë në kërkesën ndaj Redis si çelës, në përgjigje marrim vlerën e çelësit, e cila është "kërkesa jonë SQL". Kështu, ne mundëm të shfaqim në Grafana kërkesën SQL, e cila teorikisht nuk mund të shfaqej atje, së bashku me statistikën për të (calls, rows, total_time, ...).
Përfundimet
Disponueshmëria. Shërbimi ynë i monitorimit është i disponueshëm 24/7 nga çdo aplikacion dhe çdo kod. Nëse keni qasje në depo, mund të dërgoni të dhëna në shërbim. Gjuha nuk ka rëndësi, zgjidhjet nuk kanë rëndësi. Ju duhet vetëm të dini si të hapni një socket, të dërgoni atje metrikën dhe të mbyllni socket-in.
Besueshmëria. Të gjithë komponentët janë të qëndrueshëm ndaj dështimeve dhe e përballojnë ngarkesën tonë mirë.
Një prag i ulët hyrjeje. Për të përdorur këtë sistem, ju nuk keni nevojë të mësoni gjuhët e programimit dhe kërkesat në Grafana. Thjesht hapni aplikacionin tuaj, shkruani atje socket-in që do të dërgojë metricat në Graphite, e mbyllni atë, hapni Grafana, krijoni atje dashboard-e dhe shikoni sjelljen e metricave tuaja, duke marrë njoftime përmes Moira.
Vetëfunksionaliteti. Të gjitha këto mund të bëhen vetë, pa ndihmën e inxhinierëve DevOps. Dhe kjo është një veçori e tepruar, sepse ju mund të monitoroni projektin tuaj tani, pa kërkuar ndihmë nga askush — as për fillimin e punës, as për ndryshime.
Çka synojmë?
Të gjitha të listuara më poshtë — nuk janë thjesht mendime abstrakte, por ato për të cilat janë bërë të paktën hapat e parë.
- Detektori i anomalisë. Duam të krijojmë një shërbim, i cili do të shkojë në depozitat tona Graphite dhe do të kontrollojë çdo metrikë sipas algoritmeve të ndryshme. Tani kemi algoritme që duam t'i shqyrtojmë, kemi të dhëna, dimë si të punojmë me to.
- Metadata. Kemi shumë shërbime, me kalimin e kohës ato ndryshojnë, ashtu siç ndryshojnë njerëzit që punojnë me to. Të mbash dokumentacionin manualisht vazhdimisht — nuk është zgjidhje. Prandaj tani në mikroshërbimet tona integrohen metadatat. Aty është shkruar, kush e zhvilloi, gjuhët me të cilat ai bashkëvepron, kërkesat për SLA, ku dhe kujt t'i dërgosh njoftimet. Gjatë publikimit të shërbimit, të gjitha të dhënat e entiteteve krijohen vetë. Në fund, merrni dy lidhje — një për trigger-at, një tjetër — për dashboard-et në Grafana.
- Monitorimi në çdo shtëpi. Ne besojmë se një sistem të tillë duhet ta përdorin të gjithë zhvilluesit. Në këtë mënyrë, gjithmonë e kuptoni se ku është trafiku juaj, çfarë po ndodh me të, ku po bie, ku ka pika të dobëta. Nëse, për shembull, ndodh diçka dhe dëmton shërbimin tuaj, do ta merrni vesh për këtë jo nëpërmjet një telefonate nga menaxheri, por nga një alarm, dhe menjëherë do të mund të hapni log-et e fundit dhe të shikoni se çfarë ndodhi.
- Performancë e lartë. Projekti ynë po rritet vazhdimisht, dhe sot përpunon rreth 2,000,000 vlerash metrike në minutë. Një vit më parë, ky tregues ishte 500,000. Rritja vazhdon, dhe kjo do të thotë se pas një kohe Graphite (whisper) do të fillojë të ngarkojë shumë ndjeshëm sistemin e diskut. Siç e kam thënë, ky sistem monitorimi është mjaft universale për shkak të ndërkëmbueshmërisë së komponentëve. Disa njerëz e mbajnë me qëllim Graphite dhe vazhdojnë ta zgjeronin infrastrukturën e tyre, por ne vendosëm të ndjekim një rrugë tjetër: të përdorim si depo për metrikat tona. Ky kalim është pothuajse i përfunduar, dhe shumë shpejt do të tregoj më shumë se si është bërë: cilat ishin vështirësitë dhe si i kemi tejkaluar ato, si ka kaluar procesi i migrimit, do të përshkruaj komponentët e zgjedhur si dhe konfigurimet e tyre.
Faleminderit për vëmendjen! Beni pyetjet tuaja mbi këtë temë, do të përpiqem të përgjigjem këtu ose në postimet e ardhshme. Ndoshta ndokush ka përvojë në ndërtimin e një sistemi të tillë monitorimi ose migrimin në Clickhouse në një situatë të ngjashme — ndani atë në komentet.
Burimi: habr.com
