Leo, pamoja na msimbo wa monolithic, mradi wetu unajumuisha kadhaa ya huduma ndogo. Kila mmoja wao anahitaji kufuatiliwa. Kufanya hivi kwa kiwango kama hicho kwa kutumia wahandisi wa DevOps ni shida. Tumeunda mfumo wa ufuatiliaji ambao unafanya kazi kama huduma kwa wasanidi programu. Wanaweza kuandika vipimo kwa kujitegemea kwenye mfumo wa ufuatiliaji, kuzitumia, kuunda dashibodi kulingana nazo, na kuambatisha kwao arifa ambazo zitaanzishwa wakati viwango vya juu vinafikiwa. Kwa wahandisi wa DevOps, miundombinu na hati pekee.
Chapisho hili ni nakala ya hotuba yangu na yetu kwa RIT++. Watu wengi walituuliza tutengeneze matoleo ya maandishi ya ripoti kutoka hapo. Ikiwa ulikuwa kwenye mkutano au ulitazama video, hutapata chochote kipya. Na kila mtu mwingine - kuwakaribisha kwa paka. Nitakuambia jinsi tulivyokuja kwenye mfumo kama huo, jinsi inavyofanya kazi na jinsi tunapanga kuisasisha.
Zamani: mipango na mipango
Je, tulifikaje kwenye mfumo wa sasa wa ufuatiliaji? Ili kujibu swali hili, unahitaji kwenda 2015. Hivi ndivyo ilivyokuwa wakati huo:
Tulikuwa na takriban nodi 24 ambazo zilihusika na ufuatiliaji. Kuna pakiti nzima ya taji tofauti, hati, daemoni ambazo kwa njia fulani hufuatilia kitu, kutuma ujumbe, na kutekeleza majukumu. Tulifikiri kwamba kadiri tulivyoendelea, ndivyo mfumo kama huo ungekuwa haufai. Hakuna maana katika kuikuza: ni ngumu sana.
Tuliamua kuchagua vipengele hivyo vya ufuatiliaji ambavyo tutavitunza na kuviendeleza, na vile ambavyo tutaviacha. Kulikuwa na 19. Ni grafiti tu, vijumlishi na Grafana kama dashibodi iliyosalia. Lakini mfumo mpya utakuwaje? Kama hii:
Tuna hifadhi ya vipimo: hizi ni grafiti, ambazo zitatokana na viendeshi vya haraka vya SSD, hizi ni viunganishi fulani vya vipimo. Inayofuata - Grafana ya kuonyesha dashibodi na Moira kwa arifa. Pia tulitaka kuunda mfumo wa kutafuta hitilafu.
Kawaida: Ufuatiliaji 2.0
Hivi ndivyo mipango ilivyoonekana mwaka 2015. Lakini tulipaswa kuandaa sio tu miundombinu na huduma yenyewe, lakini pia nyaraka kwa ajili yake. Tumejitengenezea kiwango cha ushirika, ambacho tunakiita ufuatiliaji 2.0. Mahitaji ya mfumo yalikuwa yapi?
- upatikanaji wa mara kwa mara;
- muda wa kuhifadhi metrics = sekunde 10;
- uhifadhi wa muundo wa metrics na dashibodi;
- SLA > 99,99%
- ukusanyaji wa vipimo vya matukio kupitia UDP (!).
Tulihitaji UDP kwa sababu tuna mtiririko mkubwa wa trafiki na matukio ambayo hutoa metriki. Ikiwa utaziandika zote kwenye grafiti mara moja, hifadhi itaanguka. Pia tulichagua viambishi vya kiwango cha kwanza kwa vipimo vyote.
Kila moja ya viambishi awali ina sifa fulani. Kuna vipimo vya seva, mitandao, vyombo, rasilimali, programu, na kadhalika. Uchujaji wa wazi, mkali na uliochapwa umetekelezwa, ambapo tunakubali vipimo vya kiwango cha kwanza na kuacha vingine. Hivi ndivyo tulivyopanga mfumo huu mnamo 2015. Kuna nini kwa sasa?
Sasa: ββmchoro wa mwingiliano wa vipengele vya ufuatiliaji
Kwanza kabisa, tunafuatilia programu: msimbo wetu wa PHP, programu na huduma ndogo - kwa ufupi, kila kitu ambacho watengenezaji wetu huandika. Programu zote hutuma vipimo kupitia UDP kwa kikokoteni cha Brubeck (statsd, iliyoandikwa upya katika C). Ilibadilika kuwa ya haraka zaidi katika vipimo vya syntetisk. Na hutuma vipimo vilivyojumlishwa kwa Graphite kupitia TCP.
Ina aina ya vipimo vinavyoitwa vipima muda. Hili ni jambo rahisi sana. Kwa mfano, kwa kila muunganisho wa mtumiaji kwenye huduma, unatuma kipimo kilicho na muda wa kujibu kwa Brubeck. Majibu milioni yalikuja, lakini kijumlishi kilirejesha vipimo 10 pekee. Una idadi ya watu waliokuja, muda wa juu zaidi, wa chini na wastani wa majibu, wastani na asilimia 4. Kisha data huhamishiwa kwa Graphite na tunaiona yote ikiishi.
Pia tuna ujumlisho wa vipimo kwenye maunzi, programu, vipimo vya mfumo na mfumo wetu wa awali wa ufuatiliaji wa Munin (ulitufanyia kazi hadi 2015). Tunakusanya haya yote kupitia daemon ya CollectD ya C (ina rundo zima la programu-jalizi tofauti zilizojengwa ndani yake, inaweza kupigia kura rasilimali zote za mfumo wa mwenyeji ambao umewekwa, taja tu katika usanidi mahali pa kuandika data) na andika data kwa Graphite kupitia hiyo. Pia inasaidia programu-jalizi za python na hati za ganda, kwa hivyo unaweza kuandika masuluhisho yako maalum: CollectD itakusanya data hii kutoka kwa mwenyeji wa ndani au wa mbali (ikizingatiwa Curl) na kuituma kwa Graphite.
Kisha tunatuma vipimo vyote ambavyo tulikusanya kwa Carbon-c-relay. Hili ni suluhisho la Relay ya Carbon kutoka Graphite, iliyorekebishwa katika C. Hiki ni kipanga njia ambacho hukusanya vipimo vyote tunachotuma kutoka kwa viunganishi vyetu na kuzielekeza kwenye nodi. Pia katika hatua ya uelekezaji, hukagua uhalali wa vipimo. Kwanza, lazima zilingane na mpango wa kiambishi awali ambao nilionyesha hapo awali na, pili, ni halali kwa grafiti. Vinginevyo wataanguka.
Carbon-c-relay kisha hutuma vipimo kwenye nguzo ya Graphite. Tunatumia akiba ya Carbon, iliyoandikwa upya katika Go, kama hifadhi kuu ya vipimo. Go-carbon, kwa sababu ya usomaji wake mwingi, hupita kache ya Carbon. Inapokea data na kuiandika kwa diski kwa kutumia kifurushi cha whisper (kiwango, kilichoandikwa kwa python). Ili kusoma data kutoka kwa hifadhi zetu, tunatumia API ya Graphite. Ni kasi zaidi kuliko kawaida Graphite WEB. Nini kitatokea kwa data inayofuata?
Wanaenda Grafana. Tunatumia nguzo zetu za grafiti kama chanzo kikuu cha data, na pia tuna Grafana kama kiolesura cha wavuti cha kuonyesha vipimo na dashibodi za ujenzi. Kwa kila huduma zao, watengenezaji huunda dashibodi yao wenyewe. Kisha huunda grafu kulingana nazo, ambazo zinaonyesha metriki wanazoandika kutoka kwa programu zao. Mbali na Grafana, pia tuna SLAM. Hii ni pepo ya chatu ambayo huhesabu SLA kulingana na data kutoka kwa grafiti. Kama nilivyosema tayari, tunayo huduma ndogo kadhaa, ambayo kila moja ina mahitaji yake. Kwa kutumia SLAM, tunaenda kwenye hati na kuilinganisha na iliyo kwenye Graphite na kulinganisha jinsi mahitaji yanavyolingana na upatikanaji wa huduma zetu.
Wacha tuende zaidi: kuonya. Inapangwa kwa kutumia mfumo madhubuti - Moira. Ni huru kwa sababu ina Graphite yake chini ya kofia. Iliyoundwa na wavulana kutoka SKB "Kontur", iliyoandikwa kwa python na Go, chanzo wazi kabisa. Moira hupokea mtiririko sawa unaoingia kwenye grafiti. Ikiwa kwa sababu fulani hifadhi yako itakufa, arifa yako bado itafanya kazi.
Tulisambaza Moira huko Kubernetes; inatumia kundi la seva za Redis kama hifadhidata kuu. Matokeo yake yalikuwa mfumo wa kustahimili makosa. Inalinganisha mtiririko wa vipimo na orodha ya vichochezi: ikiwa hakuna kutajwa ndani yake, basi huacha kipimo. Kwa hivyo ina uwezo wa kuchimba gigabytes ya metriki kwa dakika.
Pia tuliambatisha LDAP ya shirika kwake, kwa usaidizi ambao kila mtumiaji wa mfumo wa shirika anaweza kujiundia arifa kulingana na vichochezi vilivyopo (au vilivyoundwa hivi karibuni). Kwa kuwa Moira ina Graphite, inasaidia vipengele vyake vyote. Kwa hivyo kwanza unachukua mstari na unakili kwenye Grafana. Tazama jinsi data inavyoonyeshwa kwenye grafu. Na kisha unachukua mstari huo huo na unakili kwenye Moira. Unaipachika na mipaka na kupata arifa kwenye pato. Ili kufanya haya yote, hauitaji maarifa maalum. Moira inaweza kutoa arifa kupitia SMS, barua pepe, Jira, Slack... Pia inasaidia utekelezaji wa hati maalum. Kichochezi kinapomtokea, na anajisajili kwa hati maalum au mfumo wa jozi, yeye huiendesha na kutuma JSON kwa stdin kwa mfumo huu wa jozi. Ipasavyo, programu yako lazima ichanganue. Utafanya nini na JSON hii ni juu yako. Ikiwa unataka, itume kwa Telegramu, ikiwa unataka, fungua kazi huko Jira, fanya chochote.
Pia tunatumia maendeleo yetu wenyewe kwa arifa - Imagotag. Tulirekebisha paneli, ambayo kwa kawaida hutumiwa kwa vitambulisho vya bei ya kielektroniki katika maduka, ili kukidhi mahitaji yetu. Tulileta vichochezi kutoka Moira kwake. Inaonyesha ni katika hali gani na wakati ilitokea. Baadhi ya watengenezaji waliacha arifa katika Slack na barua pepe ili kupendelea kidirisha hiki.
Naam, kwa kuwa sisi ni kampuni inayoendelea, tulifuatilia pia Kubernetes katika mfumo huu. Tuliijumuisha kwenye mfumo kwa kutumia Heapster, ambayo tuliisakinisha kwenye kundi, inakusanya data na kuituma kwa Graphite. Kama matokeo, mchoro unaonekana kama hii:
Vipengele vya Ufuatiliaji
Hapa kuna orodha ya viungo kwa vipengele tulivyotumia kwa kazi hii. Wote ni chanzo wazi.
Grafiti:
- go-carbon:
- kunong'ona:
- grafiti-api:
Carbon-c-relay:
Brubeck:
Imekusanywa:
Moira:
Grafana:
Heapster:
takwimu
Na hapa kuna nambari kadhaa kuhusu jinsi mfumo unavyofanya kazi kwa ajili yetu.
Aggregator (brubeck)
Idadi ya vipimo: ~300/sekunde
Muda wa kutuma vipimo kwa Graphite: 30 sek
Matumizi ya rasilimali ya seva: ~ 6% CPU (tunazungumza kuhusu seva kamili); ~ 1Gb RAM; ~3 Mbps LAN
Grafiti (go-carbon)
Idadi ya vipimo: ~ 1 / min
Muda wa kusasisha vipimo: sekunde 30
Mpango wa kuhifadhi vipimo: 30sec 35d, 5min 90d, 10min 365d (hukupa ufahamu wa kile kinachotendeka kwa huduma kwa muda mrefu)
Matumizi ya rasilimali ya seva: ~10% CPU; ~ 20Gb RAM; ~30 Mbps LAN
Utulivu
Sisi katika Avito tunathamini sana kubadilika katika huduma yetu ya ufuatiliaji. Kwa nini kweli aliibuka hivi? Kwanza, vipengele vyake vinaweza kubadilishana: vipengele vyote vyenyewe na matoleo yao. Pili, usaidizi. Kwa kuwa mradi mzima ni chanzo wazi, unaweza kuhariri msimbo mwenyewe, kufanya mabadiliko, na kutekeleza vitendaji ambavyo havipatikani nje ya kisanduku. Nguzo za kawaida hutumiwa, haswa Go na Python, kwa hivyo hii inafanywa kwa urahisi kabisa.
Hapa kuna mfano wa shida halisi. Kipimo katika Graphite ni faili. Ina jina. Jina la faili = jina la kipimo. Na kuna njia ya kufika huko. Majina ya faili katika Linux yana vibambo 255 tu. Na tuna (kama "wateja wa ndani") watu kutoka idara ya hifadhidata. Wanatuambia: "Tunataka kufuatilia maswali yetu ya SQL. Na sio herufi 255, lakini 8 MB kila moja. Tunataka kuzionyesha katika Grafana, angalia vigezo vya ombi hili, na bora zaidi, tunataka kuona sehemu ya juu ya maombi kama haya. Itakuwa nzuri ikiwa itaonyeshwa kwa wakati halisi. Ingekuwa vyema sana kuwaweka katika tahadhari.β
Swali la SQL la mfano linachukuliwa kama mfano kutoka
Tunasanidi seva ya Redis na kutumia programu-jalizi zetu zilizokusanywa, ambazo huenda kwa Postgres na kuchukua data yote kutoka hapo, na kutuma vipimo kwa Graphite. Lakini tunabadilisha jina la kipimo na heshi. Wakati huo huo tunatuma heshi sawa kwa Redis kama ufunguo, na hoja nzima ya SQL kama thamani. Tunachopaswa kufanya ni kuhakikisha kwamba Grafana anaweza kwenda Redis na kuchukua taarifa hii. Tunafungua API ya Graphite kwa sababu... huu ndio kiunganishi kikuu cha mwingiliano wa vifaa vyote vya ufuatiliaji na grafiti, na tunaingiza kazi mpya hapo inayoitwa aliasByHash() - kutoka Grafana tunapata jina la metric, na kuitumia kwa ombi kwa Redis kama ufunguo, katika jibu tunapata thamani ya ufunguo, ambayo ni "swala letu la SQL" " Kwa hivyo, tulionyesha katika Grafana onyesho la swali la SQL, ambalo kwa nadharia haikuwezekana kuonyesha hapo, pamoja na takwimu juu yake (simu, safu, jumla_saa, ...).
Matokeo ya
Upatikanaji Huduma yetu ya ufuatiliaji inapatikana 24/7 kutoka kwa programu yoyote na msimbo wowote. Ikiwa una upatikanaji wa vifaa vya kuhifadhi, unaweza kuandika data kwa huduma. Lugha sio muhimu, maamuzi sio muhimu. Unahitaji tu kujua jinsi ya kufungua tundu, kuweka metric hapo na kufunga tundu.
Kuegemea Vipengele vyote vinastahimili makosa na hushughulikia mizigo yetu vizuri.
Kizuizi cha chini cha kuingia. Ili kutumia mfumo huu, hauitaji kujifunza lugha za programu na maswali huko Grafana. Fungua tu programu yako, weka soketi ndani yake ambayo itatuma vipimo kwa Graphite, kuifunga, fungua Grafana, unda dashibodi hapo na uangalie tabia ya vipimo vyako, kupokea arifa kupitia Moira.
Uhuru. Unaweza kufanya haya yote mwenyewe, bila msaada wa wahandisi wa DevOps. Na hii ni faida, kwa sababu unaweza kufuatilia mradi wako hivi sasa, sio lazima uulize mtu yeyote - ama kuanza kazi au kufanya mabadiliko.
Je, tunalenga nini?
Kila kitu kilichoorodheshwa hapa chini sio tu mawazo ya kufikirika, lakini kitu ambacho angalau hatua za kwanza zimechukuliwa.
- Kigunduzi kisicho cha kawaida. Tunataka kuunda huduma ambayo itaenda kwenye hifadhi zetu za Graphite na kuangalia kila kipimo kwa kutumia algoriti mbalimbali. Tayari kuna algorithms ambayo tunataka kutazama, kuna data, tunajua jinsi ya kufanya kazi nayo.
- Metadata. Tuna huduma nyingi, zinabadilika kwa wakati, kama watu wanaofanya kazi nazo. Kutunza nyaraka kwa mikono sio chaguo. Ndiyo maana sasa tunapachika metadata kwenye huduma zetu ndogo. Inasema ni nani aliyeitengeneza, lugha zinazoingiliana nazo, mahitaji ya SLA, ni wapi na kwa nani arifa zinapaswa kutumwa. Wakati wa kusambaza huduma, data yote ya huluki huundwa kwa kujitegemea. Kama matokeo, unapata viungo viwili - kimoja cha vichochezi, kingine kwa dashibodi huko Grafana.
- Ufuatiliaji katika kila nyumba. Tunaamini kuwa wasanidi programu wote wanapaswa kutumia mfumo kama huo. Katika kesi hii, daima unaelewa ambapo trafiki yako iko, nini kinatokea kwake, wapi huanguka, ambapo udhaifu wake ni. Ikiwa, kwa mfano, kitu kinakuja na kuharibu huduma yako, basi utajifunza kuhusu hilo si wakati wa simu kutoka kwa meneja, lakini kutoka kwa tahadhari, na unaweza kufungua mara moja magogo ya hivi karibuni na kuona kilichotokea huko.
- Utendaji wa juu. Mradi wetu unakua kila wakati, na leo unachakata takriban viwango vya metri 2 kwa dakika. Mwaka mmoja uliopita, takwimu hii ilikuwa 000. Na ukuaji unaendelea, na hii ina maana kwamba baada ya muda fulani Graphite (whisper) itaanza kupakia sana mfumo mdogo wa disk. Kama nilivyosema tayari, mfumo huu wa ufuatiliaji ni wa ulimwengu wote kwa sababu ya kubadilishana kwa vipengele. Mtu hudumisha na kupanua kila mara miundombinu yake mahususi kwa Graphite, lakini tuliamua kwenda njia tofauti: tumia kama ghala la vipimo vyetu. Mpito huu unakaribia kukamilika, na hivi karibuni nitakuambia kwa undani zaidi jinsi hii ilifanyika: ni shida gani na jinsi zilivyoshindwa, jinsi mchakato wa uhamiaji ulivyoenda, nitaelezea vipengele vilivyochaguliwa kama vifungo na usanidi wao.
Asante kwa umakini wako! Uliza maswali yako juu ya mada, nitajaribu kujibu hapa au katika machapisho yafuatayo. Labda mtu ana uzoefu wa kujenga mfumo sawa wa ufuatiliaji au kubadili Clickhouse katika hali sawa - shiriki kwenye maoni.
Chanzo: mapenzi.com