Gaur egun, kode monolitikoaz gain, dozenaka mikrozerbitzuk funtzionatzen dute gure proiektuan. Horietako bakoitzak jarraipena egin behar du. Arazoa da DevOps ingeniariek halako bolumenetan egitea. Garatzaileentzako zerbitzu gisa funtzionatzen duen monitorizazio sistema bat garatu dugu. Monitorizazio sisteman neurriak idatz ditzakete independentean, erabili, haietan oinarritutako aginte-panelak eraiki, atalase-balioak lortzen direnean abiaraziko diren alertak erantsi. DevOps ingeniariekin - azpiegitura eta dokumentazioa soilik.
Post hau gure hitzaldiaren transkripzioa da RIT++-n. Txostenen testu bertsioak egiteko eskatu ziguten askok hortik. Konferentzia batean egon bazara edo bideo bat ikusi baduzu, ez duzu ezer berririk aurkituko. Eta beste guztiei - ongi etorria katu azpian. Esango dizut nola iritsi garen halako sistema batera, nola funtzionatzen duen eta nola eguneratzeko asmoa dugun.
Iragana: eskemak eta planak
Nola iritsi ginen indarrean dagoen monitorizazio sistemara? Galdera honi erantzuteko, 2015era joan behar duzu. Hona hemen nolakoa zen orduan:
Monitorizazioaz arduratzen ziren 24 nodo inguru genituen. Nonbait zerbait kontrolatzen dutenak, mezuak bidaltzen dituztenak, funtzioak betetzen dituzten crons, scripts, deabru ugari daude. Pentsatu genuen zenbat eta urrunago, orduan eta gutxiago bideragarria izango zela halako sistema bat. Ez du zentzurik hura garatzeak: astuna da.
Utzi eta garatuko ditugun jarraipen elementuak eta bertan behera utziko ditugunak aukeratzea erabaki dugu. 19 ziren. Grafitoak, agregatzaileak eta Grafana aginte-panel gisa bakarrik geratu ziren. Baina nolakoa izango da sistema berria? Horrela:
Metrikoen biltegi bat dugu: SSD disko bizkorretan oinarrituko diren grafitoak dira, metriketarako agregatzaile jakin batzuk dira. Hurrengoa - Grafana aginte-panelak eta Moira alerta gisa erakusteko. Anomaliak aurkitzeko sistema bat ere garatu nahi izan dugu.
Estandarra: Jarraipena 2.0
Horrelakoak ziren 2015ean planak. Baina azpiegiturak eta zerbitzua bera ez ezik, horretarako dokumentazioa ere prestatu behar izan genuen. Guretzat estandar korporatiboa garatu dugu, monitorizazioa 2.0 deitu geniona. Zeintzuk ziren sistemaren baldintzak?
- etengabeko erabilgarritasuna;
- biltegiratze-tarte metrikoa = 10 segundo;
- metrika eta aginte-panelen biltegiratze egituratua;
- SLA > % 99,99
- gertaeren neurketen bilketa UDP bidez (!).
UDP behar genuen neurriak sortzen dituzten trafiko eta gertaera asko ditugulako. Guztiak grafitoz idazten badira aldi berean, biltegia kolapsatu egingo da. Lehen mailako aurrizkiak ere aukeratu ditugu metrika guztientzat.
Aurrizki bakoitzak propietate batzuk ditu. Zerbitzarien, sareen, edukiontzien, baliabideen, aplikazioen eta abarrentzako neurketak daude. Iragazki argia, zorrotza eta idatzitakoa ezarri da, non lehen mailako neurketak onartzen ditugun, eta gainerakoak besterik gabe utzi. Horrela planifikatu genuen sistema hau 2015ean. Zer dago orainaldian?
Oraina: monitorizazio-osagaien elkarrekintzaren eskema
Lehenik eta behin, aplikazioak kontrolatzen ditugu: gure PHP kodea, aplikazioak eta mikrozerbitzuak - hitz batean, gure garatzaileek idazten duten guztia. Aplikazio guztiek neurketak UDP bidez bidaltzen dituzte Brubeck agregatzailera (statsd, C-n berridatzita). Azkarrena izan da proba sintetikoen emaitzen arabera. Eta dagoeneko gehitutako neurketak Graphite-ra bidaltzen ditu TCP bidez.
Tenporizadoreak bezalako neurriak ditu. Hau oso gauza erabilgarria da. Esaterako, zerbitzura erabiltzailearen konexio bakoitzeko, erantzun-denboraren neurketa bat bidaltzen diozu Brubeck-i. Milioi bat erantzun iritsi ziren, eta agregatzaileak 10 metrika baino ez zituen eman. Etorri den jende kopurua, erantzun denbora maximoa, minimoa eta batez bestekoa, mediana eta 4 pertzentilak dituzu. Ondoren, datuak Graphite-ra transferitzen dira eta denak zuzenean ikusten ditugu.
Hardwarea, softwarea, sistemaren metrikak eta gure Munin monitorizazio sistema zaharrak ere baditugu (gurekin 2015era arte funtzionatu zuen). Hau guztia C'ish daemon CollectD-ren bidez biltzen dugu (plugin mordo bat josita dago bertan, instalatuta dagoen sistema ostalariaren baliabide guztiak kontsulta ditzake, konfigurazioan zehaztu datuak non idatzi ) eta idatzi haren bidez datuak Grafitoz. Python pluginak eta shell script-ak ere onartzen ditu, zure soluzio pertsonalizatuak idatzi ahal izateko: CollectD-k datu hauek tokiko edo urruneko ostalari batetik bilduko ditu (demagun Curl dagoela) eta Graphite-ra bidaliko ditu.
Gainera, bildu ditugun metrika guztiak Carbon-c-relay-ra bidaltzen dira. Hau Graphite-ren Carbon Relay irtenbidea da, C-n aldatua. Gure agregatzaileetatik bidaltzen ditugun metrika guztiak biltzen dituen eta nodoetatik bideratzen dituen bideratzailea da. Bideratze fasean ere, metriken baliozkotasuna egiaztatzen du. Lehenik eta behin, lehen erakutsi dudan aurrizki-eskemarekin bat etorri behar dute eta, bigarrenik, grafitorako balio izan behar dute. Bestela, jaitsi egiten dira.
Ondoren, Carbon-c-relay-ek neurketak bidaltzen ditu Grafito klusterera. Go-n berridatzitako Carbon-cachea erabiltzen dugu metriketarako biltegiratze nagusi gisa. Go-carbon, bere multi-threading dela eta, errendimendua askoz handiagoa da Carbon-cache-ren aldean. Datuak bere baitan hartzen ditu eta diskoan idazten ditu whisper paketea erabiliz (estandarra, python-en idatzia). Gure biltegietako datuak irakurtzeko, Graphite APIa erabiltzen dugu. Graphite WEB estandarra baino askoz azkarrago funtzionatzen du. Zer gertatzen da hurrengo datuekin?
Grafanara joaten dira. Gure grafito-klusterrak erabiltzen ditugu datu-iturri nagusi gisa, eta Grafana dugu metrikak bistaratzeko, aginte-panelak eraikitzeko web interfaze gisa. Beren zerbitzu bakoitzeko, garatzaileek beren aginte-panela sortzen dute. Ondoren, haietan oinarritutako grafikoak eraikitzen dituzte, eta haien aplikazioetatik idazten dituzten neurketak erakusten dituzte. Grafanaz gain, SLAM ere badugu. Hau grafitoaren datuetan oinarrituta SLA kalkulatzen duen deabru pitonikoa da. Esan bezala, dozena bat mikrozerbitzu ditugu, eta bakoitzak bere eskakizunak ditu. SLAM-en laguntzaz, dokumentaziora joan eta Graphite-n dagoenarekin alderatzen dugu eta eskakizunak gure zerbitzuen erabilgarritasunarekin nola bat datozen konparatzen dugu.
Aurrera: abisua. Sistema sendo batekin antolatuta dago - Moira. Independentea da, bere grafitoa duelako kanpaiaren azpian. SKB Kontur-eko mutilek garatua, python eta Go-n idatzia, guztiz irekia. Moirak grafitoetan sartzen den fluxu bera jasotzen du. Arrazoiren batengatik biltegia hiltzen bada, alertak funtzionatuko du.
Moira Kubernetesen zabaldu genuen, Redis zerbitzarien multzo bat erabiltzen du datu-base nagusi gisa. Emaitza hutsegite-tolerantzia sistema bat da. Neurrien fluxua abiarazleen zerrendarekin alderatzen du: bertan aipamenik ez badago, metrika kentzen du. Beraz, minutuko gigabyte metrika digeritzeko gai da.
LDAP korporatiboa ere gehitu genion, eta horren laguntzaz sistema korporatiboaren erabiltzaile bakoitzak bere jakinarazpenak sor ditzake lehendik dauden (edo sortu berri diren) abiarazleetan. Moirak Grafitoa daukanez, bere ezaugarri guztiak onartzen ditu. Beraz, lehenik lerroa hartu eta Grafanan kopiatu. Ikusi nola bistaratzen diren datuak diagrametan. Eta gero lerro bera hartu eta Moira-n kopiatu. Zintzilikatu mugekin eta jaso alerta irteeran. Hori guztia egiteko, ez duzu ezagutza zehatzik behar. Moirak SMS, posta elektroniko bidez, Jira, Slack bidez abisatu dezake... Script pertsonalizatuak ere onartzen ditu. Abiarazle bat duenean eta script edo bitar pertsonalizatu batera harpidetuta dagoenean, abiarazten du eta JSON bitar hau stdin-era bidaltzen du. Horren arabera, zure programak analizatu beharko luke. JSON honekin egingo duzuna zure esku dago. Nahi baduzu, bidali Telegramera, nahi baduzu, ireki zereginak Jiran, egin nahi duzuna.
Alertarako ere gure garapena erabiltzen dugu - Imagotag. Dendak prezioen etiketa elektronikoetarako erabili ohi den panela gure beharretara egokitu dugu. Moiratik abiarazleak ekarri genituen bertara. Zein egoeratan dauden adierazten du, noiz gertatu diren. Garapeneko mutil batzuek Slack-en eta posta bidezko jakinarazpenak utzi zituzten panel honen alde.
Bada, enpresa aurrerakoia garenez, Kubernetes ere monitorizatu dugu sistema honetan. Klusterean instalatu dugun Heapster erabiliz sisteman sartuta, datuak bildu eta Graphite-ra bidaltzen ditu. Ondorioz, eskemak itxura hau du:
Jarraipen-osagaiak
Hona hemen zeregin honetarako erabili ditugun osagaietarako esteken zerrenda. Horiek guztiak kode irekikoak dira.
Grafitoa:
- go-karbonoa:
- xuxurla:
- grafito-api:
Karbono-c-errelea:
Brubeck:
Bilduta:
Moira:
Grafana:
heapster:
estatistikak
Eta hona hemen sistemak guretzat funtzionatzen duenari buruzko zenbait zenbaki.
Agregatzailea (brubeck)
Neurri kopurua: ~ 300 / seg
Grafitoaren neurketak bidaltzeko tartea: 30 seg
Zerbitzariaren baliabideen erabilera: ~ %6 CPU (zerbitzari osoei buruz ari gara); ~ 1 Gb RAM; ~ 3 Mbps LAN
Grafitoa (go-karbonoa)
Neurri kopurua: ~ 1 / min
Metrikoen eguneratze-tartea: 30 segundo
Metrikoen biltegiratze-eskema: 30seg 35d, 5min 90d, 10min 365d (zerbitzuarekin denbora luzean zer gertatzen den ulertzen du)
Zerbitzariaren baliabideen erabilera: ~% 10 CPU; ~ 20 Gb RAM; ~ 30 Mbps LAN
malgutasuna
Avito-n benetan eskertzen dugu gure monitorizazio-zerbitzuaren malgutasuna. Zergatik atera zen benetan horrela? Lehenik eta behin, bere osagaiak trukagarriak dira: bai osagaiak, bai haien bertsioak. Bigarrena, mantentzea. Proiektu osoa kode irekian eraikita dagoenez, zuk zeuk edita dezakezu kodea, aldaketak egin eta erabilgarri ez dauden funtzioak ezar ditzakezu. Nahiko pila arruntak erabiltzen dira, batez ere Go eta Python, beraz, nahiko erraz egiten da.
Hona hemen benetako arazo baten adibide bat. Grafitoko metrika bat fitxategi bat da. Izen bat du. Fitxategiaren izena = metrikoaren izena. Eta horra iristeko modu bat dago. Linux-en fitxategi-izenak 255 karaktere ditu. Eta datu baseen saileko mutilak ditugu (Β«barneko bezeroΒ» gisa). Esaten digute: βGure SQL kontsultak kontrolatu nahi ditugu. Eta ez dira 255 karaktere, bakoitza 8 MB baizik. Grafanan bistaratu nahi ditugu, eskaera honen parametroak ikusi eta, are hobeto, horrelako eskaeren goiko aldea ikusi nahi dugu. Handia izango da denbora errealean bistaratzen bada. Eta oso polita izango litzateke haiek alertan sartzeaΒ».
SQL kontsultaren adibidea adibide gisa hartu da
Postgres-era doazen Redis zerbitzaria eta Collectd pluginak igotzen ditugu eta hortik datu guztiak hartzen ditugu, neurketak Graphite-ra bidaltzen ditugu. Baina metrikaren izena hashekin ordezkatzen dugu. Hash bera aldi berean bidaltzen da Redis-era gako gisa, eta SQL kontsulta osoa balio gisa. Guri geratzen zaigu Grafana Redisera joan eta informazio hori hartzeko gai izatea. Graphite APIa irekitzen ari gara hau da monitorizazioko osagai guztiek grafitoarekin elkarreragiteko interfaze nagusia, eta aliasByHash () izeneko funtzio berri bat sartzen dugu bertan - Grafana-ren metrikaren izena lortzen dugu, eta Redis-i egindako eskaera batean erabiltzen dugu gako gisa, erantzuna gakoaren balioa lortzen dugu, hau da, gure "SQL kontsulta". Horrela, SQL kontsulta baten bistaratzea ekarri dugu Grafanara, eta, teorian, bertan bistaratu ezin zena, hari buruzko estatistikekin batera (deiak, errenkadak, denbora_totala,...).
Emaitzak
Erabilgarritasuna. Gure jarraipen zerbitzua 24/7 eskuragarri dago edozein aplikazio eta edozein kodetatik. Biltegietarako sarbidea baduzu, datuak idatz ditzakezu zerbitzuan. Hizkuntza ez da garrantzitsua, erabakiak ez dira garrantzitsuak. Socket bat ireki, hor metrika bat bota eta socketa ixten jakin behar duzu.
Fidagarritasuna. Osagai guztiak akatsak jasaten dituzte eta gure lan-karga ondo kudeatzen dute.
Sarrera atalase baxua. Sistema hau erabiltzeko, ez duzu programazio-lengoaiak eta kontsultak ikasi behar Grafanan. Ireki zure aplikazioa, gehitu neurketak Graphite-ra bidaliko dituen socket bat, itxi, ireki Grafana, sortu hor aginte-panelak eta begiratu zure neurketen portaera, Moira bidez jakinarazpenak jasoz.
Independentzia. Hori guztia zuk zeuk egin dezakezu, DevOps ingeniarien laguntzarik gabe. Eta hori gehiegizko ezaugarria da, oraintxe bertan zure proiektua kontrolatu dezakezulako, ez diozu inori eskatu beharrik - ez lanean hasteko, ez aldaketak egiteko.
Zertan ari gara ahalegintzen?
Jarraian agertzen dena ez dira pentsamendu abstraktuak soilik, lehen urratsak behintzat eman diren zerbait baizik.
- anomalien detektagailua. Gure Graphite biltegietara joango den zerbitzu bat sortu nahi dugu eta metrika bakoitza hainbat algoritmo erabiliz egiaztatu nahi dugu. Dagoeneko badaude algoritmoak ikusi nahi ditugunak, badaude datuak, badakigu nola lan egiten dugun.
- metadatuak. Zerbitzu asko ditugu, denborarekin aldatzen dira, baita haiekin lan egiten duten pertsonak ere. Erregistroak eskuz gordetzea ez da aukera bat. Beraz, metadatuak gure mikrozerbitzuetan txertatuta daude orain. Nork garatu zuen, zer hizkuntzatan jarduten duen, SLA eskakizunak, jakinarazpenak nori eta nori bidali behar dituen adierazten du. Zerbitzu bat zabaltzean, entitatearen datu guztiak modu independentean sortzen dira. Ondorioz, bi esteka lortzen dituzu: bata abiarazleetarako, bestea Grafanako aginte-paneletarako.
- Jarraipena etxe guztietan. Garatzaile guztiek sistema hori erabili beharko luketela uste dugu. Kasu honetan, beti ulertzen duzu non dagoen zure trafikoa, zer gertatzen zaion, non erortzen den, non dituen puntu ahulak. Adibidez, zerbait etorri eta zure zerbitzua huts egiten badu, orduan jakingo duzu ez kudeatzailearen dei batean, alerta baten bidez baizik, eta berehala ireki dezakezu erregistro berriak eta ikusi zer gertatu den bertan.
- Errendimendu handiko. Gure proiektua etengabe hazten ari da, eta gaur egun minutuko 2 balio metriko inguru prozesatzen ditu. Duela urtebete, zifra hori 000 000. Eta hazkundeak jarraitzen du, eta horrek esan nahi du denbora pixka bat igaro ondoren Grafitoa (xuxurla) diskoaren azpisistema oso kargatzen hasiko dela. Esan bezala, monitorizazio sistema hau nahiko polifazetikoa da osagaien trukagarritasuna dela eta. Graphiterako bereziki norbaitek bere azpiegitura mantentzen eta zabaltzen du etengabe, baina beste bide batetik joatea erabaki genuen: erabili gure metriketarako biltegi gisa. Trantsizio hau ia amaitu da, eta oso laster azalduko dizuet zehatzago nola egin zen: zein izan ziren zailtasunak eta nola gainditu ziren, nola joan zen migrazio prozesua, hautatutako osagaiak lotesle gisa deskribatuko ditut eta haien konfigurazioak.
Eskerrik asko zure arretagatik! Galdetu gaiari buruzko galderak, hemen edo ondorengo mezuetan erantzuten saiatuko naiz. Agian norbaitek esperientzia du antzeko monitorizazio sistema bat eraikitzen edo Clickhousera aldatzeko antzeko egoera batean - partekatu iruzkinetan.
Iturria: www.habr.com