Kumbukumbu ni sehemu muhimu ya mfumo, hukuruhusu kuelewa kuwa inafanya kazi (au haifanyi kazi) kama inavyotarajiwa. Katika usanifu wa microservice, kufanya kazi na magogo inakuwa nidhamu tofauti kwa Olympiad maalum. Kundi la maswali yanahitaji kutatuliwa mara moja:
- jinsi ya kuandika kumbukumbu kutoka kwa programu;
- wapi kuandika kumbukumbu;
- jinsi ya kutoa magogo kwa ajili ya kuhifadhi na usindikaji;
- jinsi ya kuchakata na kuhifadhi kumbukumbu.
Utumiaji wa teknolojia maarufu za uwekaji vyombo huongeza mchanga juu ya safu kwenye uwanja wa chaguzi za kutatua shida.
Hivi ndivyo nakala ya ripoti ya Yuri Bushmelev "Ramani ya reki katika uwanja wa kukusanya na kutoa magogo" inahusu.
Nani anajali, tafadhali chini ya paka.
Jina langu ni Yuri Bushmelev. Ninafanya kazi Lazada Leo nitazungumzia jinsi tulivyotengeneza magogo yetu, jinsi tulivyokusanya, na kile tunachoandika hapo.
Tunatoka wapi? Sisi ni akina nani? Lazada ni muuzaji nambari 1 mtandaoni katika nchi sita za Kusini-mashariki mwa Asia. Nchi hizi zote zinasambazwa kati ya vituo vyetu vya data. Kwa sasa kuna vituo 4 vya data kwa jumla. Kwa nini hili ni muhimu? Kwa sababu baadhi ya maamuzi yalitokana na ukweli kwamba kuna uhusiano dhaifu sana kati ya vituo. Tuna usanifu wa huduma ndogo. Nilishangaa kupata kwamba tayari tunayo huduma ndogo 80. Nilipoanza kazi na magogo, kulikuwa na 20 tu. Zaidi ya hayo kuna sehemu kubwa ya urithi wa PHP, ambayo pia lazima niishi nayo na kuvumilia. Haya yote kwa sasa yanazalisha zaidi ya ujumbe milioni 6 kwa dakika kwa mfumo mzima. Ifuatayo nitaonyesha jinsi tunavyojaribu kuishi na hii, na kwa nini hii ni hivyo.
Inabidi uishi kwa njia fulani na jumbe hizi milioni 6. Tufanye nini nao? Ujumbe milioni 6 unahitaji:
- tuma kutoka kwa programu
- kukubali kwa utoaji
- toa kwa uchambuzi na uhifadhi.
- kuchambua
- ihifadhi kwa namna fulani.
Wakati ujumbe milioni tatu ulipotokea, nilitazama sawa. Kwa sababu tulianza na senti chache tu. Ni wazi kwamba kumbukumbu za maombi zimeandikwa hapo. Kwa mfano, sikuweza kuunganisha kwenye hifadhidata, niliweza kuunganisha kwenye hifadhidata lakini sikuweza kusoma chochote. Lakini kando na hii, kila moja ya huduma zetu ndogo pia huandika logi ya ufikiaji. Kila ombi linalofika kwenye huduma ndogo hurekodiwa kwenye kumbukumbu. Kwa nini tunafanya hivi? Wasanidi wanataka kuweza kufuatilia. Kila kumbukumbu ya ufikiaji ina uga wa traceid, kwa kutumia kiolesura maalum kisha kufungua mnyororo mzima na kuonyesha ufuatiliaji kwa uzuri. Ufuatiliaji unaonyesha jinsi ombi lilivyoenda, na hii huwasaidia wasanidi programu wetu kukabiliana haraka na uchafu wowote ambao haujatambuliwa.
Jinsi ya kuishi na hii? Sasa nitaelezea kwa ufupi uwanja wa chaguzi - jinsi tatizo hili linatatuliwa kwa ujumla. Jinsi ya kutatua tatizo la kukusanya, kusambaza na kuhifadhi magogo.
Jinsi ya kuandika kutoka kwa programu? Ni wazi kwamba kuna njia tofauti. Hasa, kuna mazoezi bora, kama wandugu wetu wa mtindo wanatuambia. Kuna aina mbili za shule ya zamani, kama babu zetu walituambia. Kuna njia nyingine.
Hali na magogo ya kukusanya ni takriban sawa. Hakuna chaguo nyingi za kutatua sehemu hii mahususi. Tayari kuna zaidi yao, lakini sio wengi bado.
Lakini kwa utoaji na uchambuzi unaofuata, idadi ya tofauti huanza kulipuka. Sitaelezea kila chaguo sasa. Nadhani chaguzi kuu zinajulikana kwa kila mtu anayevutiwa na mada.
Nitakuonyesha jinsi tulivyofanya huko Lazada, na jinsi yote yalivyoanza.
Mwaka mmoja uliopita nilikuja Lazada na nilitumwa kwa mradi kuhusu magogo. Ilikuwa kitu kama hiki. Rekodi ya programu iliandikwa kwa stdout na stderr. Kila kitu kilifanyika kwa njia ya mtindo. Lakini basi watengenezaji waliitupa nje ya mtiririko wa kawaida, na kisha kwa namna fulani wataalamu wa miundombinu wataihesabu. Kati ya wataalamu wa miundombinu na watengenezaji, pia kuna watoaji ambao walisema: "uh ... vizuri, wacha tuwafunge kwenye faili iliyo na ganda, na ndivyo hivyo." Na kwa kuwa haya yote yalikuwa kwenye kontena, waliifunga moja kwa moja kwenye chombo chenyewe, wakapanga orodha ya ndani na kuiweka hapo. Nadhani ni dhahiri kwa kila mtu kilichotokea.
Hebu tuangalie zaidi kwa sasa. Je, tuliwasilishaje kumbukumbu hizi? Mtu alichagua td-agent, ambayo kwa kweli ni fasaha, lakini si fasaha kabisa. Bado sielewi uhusiano kati ya miradi hii miwili, lakini inaonekana kuwa juu ya kitu kimoja. Na hii fasaha, iliyoandikwa kwa Ruby, ilisoma faili za kumbukumbu, ilizichanganua kuwa JSON kwa kutumia aina fulani ya utaratibu. Kisha nikawapeleka Kafka. Kwa kuongezea, huko Kafka tulikuwa na mada 4 tofauti kwa kila API. Kwa nini 4? Kwa sababu kuna moja kwa moja, kuna maonyesho, na kwa sababu kuna stdout na stderr. Watengenezaji wanaziunda, na watengenezaji wa miundombinu lazima waziunde huko Kafka. Aidha, Kafka ilidhibitiwa na idara nyingine. Kwa hivyo, ilikuwa ni lazima kuunda tikiti ili waweze kuunda mada 4 kwa kila api. Kila mtu alisahau kuhusu hilo. Kwa ujumla, kulikuwa na takataka na fujo.
Tulifanya nini baadaye na hii? Tuliipeleka Kafka. Kisha nusu ya magogo kutoka Kafka yaliruka hadi Logstash. Nusu nyingine ya magogo iligawanywa. Wengine waliruka kwa Graylog moja, wengine hadi Graylog nyingine. Kama matokeo, haya yote yaliingia kwenye nguzo moja ya Elasticsearch. Yaani fujo zote hizi ziliishia hapo. Usifanye hivyo!
Hivi ndivyo inavyoonekana ukiitazama kutoka juu. Usifanye hivyo! Hapa maeneo ya shida yana alama mara moja na nambari. Kwa kweli kuna zaidi yao, lakini 6 ni shida sana ambazo zinahitaji kufanywa kitu. Nitakuambia juu yao tofauti sasa.
Hapa (1,2,3) tunaandika faili na, ipasavyo, kuna reki tatu hapa mara moja.
Ya kwanza (1) ni kwamba tunahitaji kuziandika mahali fulani. Haitahitajika kila wakati kuipa API uwezo wa kuandika moja kwa moja kwa faili. Inastahili kuwa API itengwe kwenye kontena, au bora zaidi, kwamba isomwe tu. Mimi ni msimamizi wa mfumo, kwa hivyo nina maoni mbadala kidogo ya vitu hivi.
Jambo la pili (2,3) ni kwamba tunayo maombi mengi yanayokuja kwa API. API huandika data nyingi kwa faili. Faili zinaongezeka. Tunahitaji kuzizungusha. Kwa sababu vinginevyo hutaweza kuhifadhi kwenye diski yoyote huko. Kuzizungusha ni mbaya kwa sababu zinatengenezwa kwa kuelekeza kupitia ganda kwenye saraka. Hakuna njia tunaweza kuirekebisha. Huwezi kusema programu ifungue tena vishikizo. Kwa sababu watengenezaji watakuangalia kama wewe ni mpumbavu: "Ni maelezo gani? Kwa ujumla tunawaandikia stdout." Wasanidi wa miundombinu walifanya copytruncate kwa logrotate, ambayo hufanya nakala ya faili na kunukuu ya asili. Ipasavyo, kati ya michakato hii ya kunakili nafasi ya diski kawaida huisha.
(4) Tulikuwa na umbizo tofauti katika API tofauti. Zilikuwa tofauti kidogo, lakini regexp ilibidi iandikwe tofauti. Kwa kuwa haya yote yalidhibitiwa na Puppet, kulikuwa na kundi kubwa la madarasa na mende wao wenyewe. Zaidi ya hayo, mara nyingi td-agent inaweza kula kumbukumbu, kuwa mjinga, inaweza tu kujifanya kuwa inafanya kazi na kufanya chochote. Kutoka nje haikuwezekana kuelewa kwamba alikuwa akifanya chochote. Kwa bora, ataanguka na mtu atamchukua baadaye. Kwa usahihi, tahadhari itafika, na mtu ataenda na kuinua kwa mikono yao.
(6) Na takataka zaidi na taka ilikuwa elasticsearch. Kwa sababu ilikuwa toleo la zamani. Kwa sababu hatukuwa na mabwana waliojitolea wakati huo. Tulikuwa na magogo mengi ambayo sehemu zake zinaweza kupishana. Kumbukumbu tofauti kutoka kwa programu tofauti zinaweza kuandikwa kwa majina ya sehemu sawa, lakini kunaweza kuwa na data tofauti ndani. Hiyo ni, logi moja inakuja na Integer kwenye shamba, kwa mfano, ngazi. Logi nyingine inakuja na Kamba kwenye uwanja wa kiwango. Kwa kutokuwepo kwa ramani tuli, hili ni jambo la ajabu sana. Ikiwa, baada ya kuzunguka index katika elasticsearch, ujumbe wenye kamba huja kwanza, basi tunaishi kawaida. Lakini ikiwa ya kwanza ilifika kutoka kwa Integer, basi ujumbe wote unaofuata uliofika kutoka kwa String hutupwa tu. Kwa sababu aina ya uwanja hailingani.
Tulianza kuuliza maswali haya. Tuliamua kutowatafuta wa kuwalaumu.
Lakini kitu kinahitaji kufanywa! Jambo lililo wazi ni kwamba tunahitaji kuweka viwango. Tayari tulikuwa na viwango fulani. Tulianza baadhi baadaye kidogo. Kwa bahati nzuri, muundo mmoja wa kumbukumbu wa API zote ulikuwa tayari umeidhinishwa wakati huo. Imeandikwa moja kwa moja katika viwango vya mwingiliano kati ya huduma. Ipasavyo, wale ambao wanataka kupokea kumbukumbu lazima waandike katika muundo huu. Ikiwa mtu hajaandika kumbukumbu katika muundo huu, basi hatuhakikishi chochote.
Ifuatayo, ningependa kuunda kiwango cha umoja cha njia za kurekodi, kutoa na kukusanya kumbukumbu. Kweli, wapi kuziandika, na jinsi ya kuziwasilisha. Hali nzuri ni wakati miradi hutumia maktaba sawa. Kuna maktaba tofauti ya ukataji miti ya Go, na maktaba tofauti ya PHP. Kila tuliye naye anapaswa kuzitumia. Kwa sasa, ningesema kwamba tumefanikiwa kwa asilimia 80 katika hili. Lakini watu wengine wanaendelea kula cacti.
Na huko (kwenye slaidi) "SLA ya utoaji wa magogo" huanza kuonekana. Bado haipo, lakini tunaifanyia kazi. Kwa sababu ni rahisi sana wakati miundombinu inasema kwamba ikiwa utaandika kwa njia kama hiyo na vile kwa mahali fulani na si zaidi ya ujumbe wa N kwa sekunde, basi uwezekano mkubwa tutawasilisha mahali fulani na vile. Hii huondoa maumivu ya kichwa mengi. Ikiwa kuna SLA, basi hii ni ya ajabu kabisa!
Je, tulianzaje kutatua tatizo? Shida kuu ilikuwa na wakala wa td. Haikuwa wazi magogo yetu yalikwenda wapi. Je, zinatolewa? Je, wanaenda? Wako wapi hata hivyo? Kwa hivyo, hatua ya kwanza iliamuliwa kuchukua nafasi ya wakala wa td. Nimeelezea kwa ufupi chaguzi za nini cha kubadilisha hapa.
Mwenye ufasaha. Kwanza, nilikutana naye kwenye kazi ya hapo awali, na pia mara kwa mara alianguka hapo. Pili, hii ni kitu kimoja, tu katika wasifu.
Mdundo wa faili. Jinsi gani ilikuwa rahisi kwa ajili yetu? Kwa sababu iko katika Go, na tuna utaalamu mwingi katika Go. Ipasavyo, ikiwa chochote kitatokea, tunaweza kwa njia fulani kujiongezea sisi wenyewe. Ndiyo maana hatukuichukua. Ili kusiwe na jaribu lolote la kuanza kujiandikia tena.
Suluhisho la wazi kwa msimamizi wa mfumo ni kila aina ya syslogs katika idadi hii (syslog-ng/rsyslog/nxlog).
Au andika kitu chako mwenyewe, lakini tulitupilia mbali hii, pamoja na mpigo wa faili. Ikiwa unaandika kitu, ni bora kuandika kitu muhimu kwa biashara. Ili kutoa magogo, ni bora kuchukua kitu kilichopangwa tayari.
Kwa hivyo, chaguo kweli lilikuja kwa chaguo kati ya syslog-ng na rsyslog. Niliegemea rsyslog kwa sababu tayari tulikuwa na madarasa ya rsyslog kwenye Puppet, na sikupata tofauti dhahiri kati yao. syslog ni nini, syslog ni nini. Ndio, zingine zina hati mbaya zaidi, zingine zina bora zaidi. Huyu anaweza kuifanya kwa njia hii, na mwingine anaweza kuifanya kwa njia tofauti.
Na kidogo kuhusu rsyslog. Kwanza kabisa, ni nzuri kwa sababu ina moduli nyingi. Ina RainerScript inayoweza kusomeka na binadamu (lugha ya usanidi ya kisasa). Ni bonasi nzuri sana ambayo tunaweza kuiga tabia ya td-agent kwa kutumia zana za kawaida, na hakuna kilichobadilika kwa programu. Hiyo ni, tunabadilisha wakala wa td kuwa rsyslog, na kuacha kila kitu kingine peke yake kwa sasa. Na mara moja tunapokea utoaji wa kazi. Ifuatayo, mmnormalize ni jambo la kushangaza katika rsyslog. Inakuruhusu kuchanganua magogo, lakini bila kutumia Grok na regexp. Inafanya mti wa sintaksia wa kufikirika. Huchanganua magogo kwa njia sawa na mkusanyaji huchanganua vyanzo. Hii hukuruhusu kufanya kazi haraka sana, hutumia CPU kidogo, na, kwa ujumla, ni jambo la kupendeza sana. Kuna rundo la mafao mengine. Sitakaa juu yao.
rsyslog ina shida zingine nyingi. Wao ni sawa na bonuses. Shida kuu ni kwamba unahitaji kujua jinsi ya kupika, na unahitaji kuchagua toleo.
Tuliamua kwamba tutaandika magogo kwenye tundu la unix. Na sio ndani /dev/log, kwa sababu huko tunayo fujo ya kumbukumbu za mfumo, zilizoandikwa ziko kwenye bomba hili. Kwa hivyo wacha tuandike kwa tundu maalum. Tutaiambatanisha kwa mpangilio tofauti wa kanuni. Tusiingilie chochote. Kila kitu kitakuwa wazi na kinachoeleweka. Ndivyo tulivyofanya. Saraka iliyo na soketi hizi imesawazishwa na kutumwa kwa vyombo vyote. Vyombo vinaweza kuona tundu wanalohitaji, fungua na uandike.
Kwa nini isiwe faili? Kwa sababu kila mtu aliisoma , ambayo ilijaribu kusambaza faili kwa docker, na ikagundulika kuwa baada ya kuanza tena rsyslog, maelezo ya faili yalibadilika, na docker ilipoteza faili hii. Inaweka kitu kingine wazi, lakini sio tundu ambapo wanaandika. Tuliamua kwamba tutashughulikia tatizo hili, na wakati huo huo, tungeshughulikia tatizo la kuzuia.
Rsyslog hufanya vitendo vilivyoonyeshwa kwenye slaidi na kutuma kumbukumbu kwa relay au Kafka. Kafka inafuata njia ya zamani. Relay - Nilijaribu kutumia rsyslog safi kutoa magogo. Bila Foleni ya Ujumbe, kwa kutumia zana za kawaida za rsyslog. Kimsingi, inafanya kazi.
Lakini kuna nuances na jinsi ya kuzisukuma kwenye sehemu hii (Logstash/Graylog/ES). Sehemu hii (rsyslog-rsyslog) inatumika kati ya vituo vya data. Hapa kuna kiunga cha tcp kilichoshinikwa, ambacho huturuhusu kuokoa kipimo data na, ipasavyo, kwa njia fulani kuongeza uwezekano kwamba tutapokea kumbukumbu kutoka kwa kituo kingine cha data wakati chaneli imefungwa. Kwa sababu tuna Indonesia, ambapo kila kitu ni mbaya. Hapa ndipo penye tatizo la kudumu.
Tulifikiria jinsi tunavyoweza kufuatilia kwa hakika jinsi uwezekano wa kumbukumbu tulizorekodi kutoka kwa programu kufikia mwisho? Tuliamua kuunda vipimo. rsyslog ina moduli yake ya ukusanyaji wa takwimu, ambayo ina aina fulani za vihesabio. Kwa mfano, inaweza kukuonyesha ukubwa wa foleni, au ni ujumbe ngapi umefika katika kitendo kama hicho. Unaweza tayari kuchukua kitu kutoka kwao. Zaidi, ina vihesabio maalum ambavyo vinaweza kusanidiwa, na itakuonyesha, kwa mfano, idadi ya ujumbe ambao baadhi ya API ilirekodi. Ifuatayo, niliandika rsyslog_exporter huko Python, na tukatuma yote kwa Prometheus na kujengwa grafu. Tulitaka sana vipimo vya Graylog, lakini bado hatujapata muda wa kuviweka.
Matatizo yalikuwa nini? Matatizo yalitokea tulipogundua (GHAFLA!) kwamba API zetu za Moja kwa Moja zilikuwa zikiandika ujumbe wa 50k kwa sekunde. Hii ni API ya Moja kwa Moja tu bila kuonyeshwa. Na Graylog inatuonyesha ujumbe elfu 12 tu kwa sekunde. Na swali la busara likaibuka: mabaki yako wapi? Ambayo tulihitimisha kuwa Graylog haiwezi kustahimili. Tuliangalia, na, kwa kweli, Graylog na Elasticsearch hawakuweza kushughulikia mtiririko huu.
Kisha, uvumbuzi mwingine tuliofanya njiani.
Maandishi kwenye tundu yamezuiwa. Ilifanyikaje? Nilipokuwa nikitumia rsyslog kwa utoaji, wakati fulani kituo kati ya vituo vya data kiliharibika. Uwasilishaji ulisimamishwa katika sehemu moja, uwasilishaji ulisimamishwa mahali pengine. Haya yote yamefikia mashine iliyo na API zinazoandika kwa tundu la rsyslog. Kulikuwa na foleni pale. Kisha foleni ya kuandika kwa tundu unix, ambayo kwa default ni 128 pakiti, kujazwa juu. Na write() inayofuata kwenye programu imezuiwa. Tulipoangalia maktaba tunayotumia katika programu za Go, iliandikwa hapo kwamba kuandika kwenye tundu hutokea katika hali isiyo ya kuzuia. Tulikuwa na hakika kwamba hakuna kitu kilichozuiwa. Kwa sababu tunasoma ambaye aliandika juu yake. Lakini kuna wakati. Pia kulikuwa na kitanzi kisicho na kikomo karibu na simu hii, ambayo kulikuwa na jaribio la mara kwa mara la kusukuma ujumbe kwenye tundu. Hatukumwona. Ilinibidi kuandika upya maktaba. Tangu wakati huo imebadilika mara kadhaa, lakini sasa tumeondoa kuzuia katika mifumo yote ndogo. Kwa hivyo, unaweza kusimamisha rsyslog, na hakuna kitu kitaanguka.
Inahitajika kufuatilia saizi ya foleni, ambayo husaidia kuzuia kukanyaga kwenye tafuta hii. Kwanza, tunaweza kufuatilia tunapoanza kupoteza ujumbe. Pili, tunaweza kufuatilia kwamba tuna matatizo ya kujifungua.
Na wakati mwingine usio na furaha - amplification kwa mara 10 katika usanifu wa microservice ni rahisi sana. Hatuna maombi mengi yanayoingia, lakini kwa sababu ya grafu ambayo ujumbe huu husafiri zaidi, kwa sababu ya kumbukumbu za kufikia, kwa kweli tunaongeza mzigo wa logi kwa karibu mara kumi. Kwa bahati mbaya, sikuwa na wakati wa kuhesabu nambari halisi, lakini huduma ndogo ni nini. Hili lazima likumbukwe. Inabadilika kuwa kwa sasa mfumo mdogo wa mkusanyiko wa logi ndio uliopakiwa zaidi katika Lazada.
Jinsi ya kutatua shida ya elasticsearch? Ikiwa unahitaji haraka kupata magogo katika sehemu moja, ili usikimbie karibu na mashine zote na kuzikusanya huko, tumia hifadhi ya faili. Hii imehakikishiwa kufanya kazi. Inaweza kufanywa kutoka kwa seva yoyote. Unahitaji tu kubandika diski hapo na usakinishe syslog. Baada ya hayo, umehakikishiwa kuwa na magogo yote katika sehemu moja. Kisha unaweza kusanidi polepole elasticsearch, graylog, na kitu kingine. Lakini tayari utakuwa na kumbukumbu zote, na, zaidi ya hayo, unaweza kuzihifadhi hadi kuna safu za kutosha za disk.
Wakati wa ripoti yangu, mpango ulianza kuonekana kama hii. Kwa kweli tuliacha kuiandikia faili. Sasa, uwezekano mkubwa, tutazima wengine. Kwenye mashine za ndani zinazoendesha API, tutaacha kuandika kwa faili. Kwanza, kuna hifadhi ya faili, ambayo inafanya kazi vizuri sana. Pili, mashine hizi zinaishiwa na nafasi kila wakati; inahitaji kufuatiliwa kila wakati.
Sehemu hii iliyo na Logstash na Graylog, inaondoka. Kwa hiyo, tunahitaji kuiondoa. Unapaswa kuchagua kitu kimoja.
Tuliamua kuwatupa nje Logstash na Kibana. Kwa sababu tuna idara ya usalama. Uhusiano gani? Uunganisho ni kwamba Kibana bila X-Pack na bila Shield haikuruhusu kutofautisha haki za upatikanaji wa kumbukumbu. Ndiyo sababu tulichukua Graylog. Ina yote. Siipendi, lakini inafanya kazi. Tulinunua maunzi mapya, tukasakinisha Graylog mpya hapo na tukahamisha kumbukumbu zote zilizo na umbizo kali kwa Graylog tofauti. Tulitatua tatizo na aina tofauti za nyanja zinazofanana kwa utaratibu.
Nini hasa ni pamoja na katika Graylog mpya. Tuliandika tu kila kitu kwenye docker. Tulichukua rundo la seva, tukazindua matukio matatu ya Kafka, seva 7 za Graylog toleo la 2.3 (kwa sababu tulitaka toleo la 5 la Elasticsearch). Yote hii ilichukuliwa wakati wa uvamizi kutoka kwa HDD. Tuliona kiwango cha kuorodhesha cha hadi ujumbe elfu 100 kwa sekunde. Tuliona takwimu kwamba terabytes 140 za data kwa wiki.
Na tena rafu! Tuna mauzo mawili yanakuja. Tulihamisha zaidi ya ujumbe milioni 6. Graylog hana wakati wa kutafuna. Kwa namna fulani tunapaswa kuishi tena.
Hivi ndivyo tulivyonusurika. Tuliongeza seva chache zaidi na SSD. Kwa sasa tunaishi hivi. Sasa tayari tunatafuna jumbe 160k kwa sekunde. Bado hatujafikia kikomo, kwa hivyo haijulikani ni kiasi gani tunaweza kupata kutoka kwa hili.
Hii ndio mipango yetu ya siku zijazo. Kati ya hizi, muhimu zaidi labda ni upatikanaji wa juu. Bado hatuna. Magari kadhaa yameundwa kwa njia ile ile, lakini hadi sasa kila kitu kinapitia gari moja. Inachukua muda kuanzisha kushindwa kati yao.
Kusanya vipimo kutoka kwa Graylog.
Weka kikomo cha bei ili tuwe na API moja ya kichaa ambayo haiua kipimo data chetu na kila kitu kingine.
Na hatimaye, saini aina fulani ya SLA na watengenezaji ili tuweze kutumikia kiasi hiki. Ikiwa utaandika zaidi, basi samahani.
Na kuandika nyaraka.
Kwa kifupi, matokeo ya kila kitu tulichopata. Kwanza, viwango. Pili, syslog ni keki. Tatu, rsyslog hufanya kazi kama ilivyoandikwa kwenye slaidi. Na tuendelee kwenye maswali.
maswali.
Swali: Kwa nini uliamua kutochukua... (filebeat?)
Kujibu: Tunahitaji kuandika kwa faili. Kwa kweli sikutaka. Wakati API yako inapoandika maelfu ya ujumbe kwa sekunde, hata kama utaizungusha mara moja kwa saa, hii bado si chaguo. Unaweza kuandika kwenye bomba. Ambayo watengenezaji waliniuliza: "Ni nini kitatokea ikiwa mchakato tunaoandika utaacha kufanya kazi?" Sikupata tu la kuwajibu, na nikasema: “Sawa, sawa, tusifanye hivyo.”
Swali: Kwa nini usiandike tu kumbukumbu kwa HDFS?
Kujibu: Hii ni hatua inayofuata. Tulifikiria juu yake mwanzoni, lakini kwa kuwa kwa sasa hakuna rasilimali za kufanya hivi, inategemea suluhisho letu la muda mrefu.
Swali: Umbizo la safu wima lingefaa zaidi.
Kujibu: Naelewa. Sisi ni kwa ajili yake kwa mikono miwili.
Swali: Unaandika kwa rsyslog. Huko unaweza kutumia TCP na UDP. Lakini ikiwa UDP, basi unahakikishaje utoaji?
Kujibu: Kuna pointi mbili. Kwanza, ninawaambia kila mtu mara moja kwamba hatuhakikishi utoaji wa magogo. Kwa sababu wakati watengenezaji wanakuja na kusema: "Hebu tuanze kuandika data ya kifedha huko, na utatuweka mahali fulani ikiwa kitu kitatokea," tunawajibu, "Kubwa! Wacha tuanze kuzuia kuandika kwa soketi, na tufanye hivi katika shughuli, ili uwe na uhakika wa kuiweka kwenye soketi kwa ajili yetu na kuhakikisha kwamba tunaipokea kutoka upande mwingine. Na kwa wakati huu, kila mtu mara moja haitaji tena. Ikiwa sio lazima, basi ni maswali gani tunapaswa kuuliza? Ikiwa hutaki kuhakikisha uandishi kwa soketi, basi kwa nini tunahitaji kuhakikisha uwasilishaji? Tunafanya juhudi zetu zote. Kwa kweli tunajaribu kutoa kadiri iwezekanavyo na kwa njia bora zaidi, lakini hatutoi dhamana ya 100%. Kwa hiyo, hakuna haja ya kuandika data ya kifedha huko. Kuna hifadhidata zilizo na shughuli za hii.
Swali: Wakati API inazalisha baadhi ya ujumbe kwenye logi na kuhamisha udhibiti kwa huduma ndogo, je, umekumbana na tatizo kwamba ujumbe kutoka kwa huduma ndogo tofauti hufika kwa mpangilio usio sahihi? Hii husababisha kuchanganyikiwa.
Kujibu: Ni kawaida kwamba wanakuja kwa mpangilio tofauti. Unahitaji kuwa tayari kwa hili. Kwa sababu utoaji wowote wa mtandao hauhakikishi utaratibu, au unapaswa kutumia rasilimali maalum juu ya hili. Ikiwa tutachukua hifadhi za faili, basi kila API huhifadhi kumbukumbu kwenye faili yake. Au tuseme, kuna rsyslog huzipanga katika saraka. Kila API ina kumbukumbu zake, ambapo unaweza kwenda na kuangalia, na kisha unaweza kuzilinganisha kwa kutumia muhuri wa muda katika logi hii. Ikiwa wataangalia katika Graylog, basi hupangwa hapo kwa muhuri wa wakati. Kila kitu kitakuwa sawa huko.
Swali: Muhuri wa muda unaweza kutofautiana kwa milisekunde.
Kujibu: Muhuri wa wakati unatolewa na API yenyewe. Hii ni, kwa kweli, hatua nzima. Tuna NTP. API hutoa muhuri wa muda katika ujumbe wenyewe. rsyslog haiongezi.
Swali: Mwingiliano kati ya vituo vya data sio wazi sana. Ndani ya kituo cha data, ni wazi jinsi kumbukumbu zilivyokusanywa na kuchakatwa. Je, mwingiliano kati ya vituo vya data hufanyikaje? Au je, kila kituo cha data kinaishi maisha yake?
Kujibu: Karibu. Katika nchi yetu, kila nchi iko katika kituo kimoja cha data. Kwa sasa, hatuna kuenea ili nchi moja iko katika vituo tofauti vya data. Kwa hiyo, hakuna haja ya kuchanganya yao. Kila kituo kina Relay ya Kumbukumbu ndani. Hii ni seva ya Rsyslog. Kwa kweli, mashine mbili za usimamizi. Wana mtazamo sawa. Lakini kwa sasa, trafiki hupitia moja wapo. Inakusanya magogo yote. Ana foleni ya diski endapo tu. Inapakua kumbukumbu na kuzituma kwa kituo kikuu cha data (Singapore), ambapo zinatumwa kwa Graylog. Na kila kituo cha data kina hifadhi yake ya faili. Ikiwa muunganisho wetu utapotea, tuna kumbukumbu zote hapo. Watabaki huko. Zitahifadhiwa hapo.
Swali: Katika hali isiyo ya kawaida, je, unapokea kumbukumbu kutoka huko?
Kujibu: Unaweza kwenda huko (kwenye hifadhi ya faili) na uangalie.
Swali: Unafuatiliaje kuwa haupotezi magogo?
Kujibu: Kwa kweli tunawapoteza, na tunafuatilia. Ufuatiliaji ulizinduliwa mwezi mmoja uliopita. Maktaba ambayo API za Go hutumia ina vipimo. Anaweza kuhesabu ni mara ngapi hakuweza kuandika kwenye soketi. Kwa sasa kuna heuristic wajanja huko. Kuna buffer hapo. Inajaribu kuandika ujumbe kutoka kwake hadi kwenye tundu. Ikiwa buffer itafurika, inaanza kuwaangusha. Na anahesabu ngapi alidondosha. Ikiwa mita zinaanza kufurika huko, tutajua kuhusu hilo. Sasa wanakuja pia kwa prometheus, na unaweza kuona grafu huko Grafana. Unaweza kusanidi arifa. Lakini bado haijabainika wampeleke nani.
Swali: Katika utaftaji wa elastic unahifadhi magogo na upungufu. Una nakala ngapi?
Kujibu: Mstari mmoja.
Swali: Je, huu ni mstari mmoja tu?
Kujibu: Hii ni bwana na nakala. Data imehifadhiwa katika nakala mbili.
Swali: Je, ulirekebisha saizi ya bafa ya rsyslog kwa namna fulani?
Kujibu: Tunaandika datagramu kwa soketi maalum ya unix. Hii mara moja inaweka kikomo cha kilobytes 128 juu yetu. Hatuwezi kuiandikia zaidi. Tumeandika hii katika kiwango. Wale ambao wanataka kuingia kwenye hifadhi wanaandika kilobytes 128. Maktaba, zaidi ya hayo, hukatwa, na bendera imewekwa kwamba ujumbe umekatwa. Kiwango chetu cha ujumbe wenyewe kina sehemu maalum inayoonyesha ikiwa ilikatwa wakati wa kurekodi au la. Kwa hivyo tunayo fursa ya kufuatilia wakati huu pia.
Swali: Unaandika JSON iliyovunjika?
Kujibu: JSON iliyovunjika itatupwa aidha wakati wa usambazaji kwa sababu pakiti ni kubwa mno. Au Graylog itatupwa kwa sababu haiwezi kuchanganua JSON. Lakini kuna nuances ambazo zinahitaji kusasishwa, na zimefungwa kwa rsyslog. Tayari nimejaza masuala kadhaa huko, ambayo bado yanahitaji kufanyiwa kazi.
Swali: Kwa nini Kafka? Je, umejaribu RabbitMQ? Je, Graylog inashindwa chini ya mizigo kama hiyo?
Kujibu: Haifanyi kazi kwetu na Graylog. Na Graylog inakua kwa ajili yetu. Ana matatizo kweli. Yeye ni jambo la kipekee. Na, kwa kweli, haihitajiki. Ningependelea kuandika kutoka rsyslog moja kwa moja hadi elasticsearch kisha nimtazame Kibana. Lakini tunahitaji kusuluhisha suala hilo na walinzi. Hili ni chaguo linalowezekana kwa maendeleo yetu, tunapotupa Graylog na kutumia Kibana. Hakuna maana katika kutumia Logstash. Kwa sababu naweza kufanya kitu kimoja na rsyslog. Na ina moduli ya kuandika kwa elasticsearch. Tunajaribu kuishi kwa njia fulani na Graylog. Hata tuliirekebisha kidogo. Lakini bado kuna nafasi ya kuboresha.
Kuhusu Kafka. Hivi ndivyo ilivyotokea kihistoria. Nilipofika, tayari ilikuwa iko, na magogo yalikuwa yameandikwa kwake. Tuliinua tu nguzo yetu na kuhamisha kumbukumbu ndani yake. Sisi ni usimamizi wake, tunajua jinsi anavyojisikia. Kuhusu RabbitMQ... haifanyi kazi kwetu na RabbitMQ. Na RabbitMQ inachukua sura kwa ajili yetu. Tunayo katika uzalishaji, na kulikuwa na matatizo nayo. Sasa, kabla ya kuuza, wangemvutia, na angeanza kufanya kazi kawaida. Lakini kabla ya hapo sikuwa tayari kuitoa katika uzalishaji. Kuna jambo moja zaidi. Graylog inaweza kusoma toleo la AMQP 0.9, na rsyslog inaweza kuandika toleo la AMQP 1.0. Na hakuna suluhisho moja katikati ambayo inaweza kufanya zote mbili. Ni ama moja au nyingine. Kwa hivyo, kwa sasa ni Kafka tu. Lakini pia ina nuances yake mwenyewe. Kwa sababu omkafka ya toleo la rsyslog tunalotumia linaweza kupoteza bafa nzima ya ujumbe ambayo ilitoka kwa rsyslog. Kwa sasa tunavumilia.
Swali: Je, unatumia Kafka kwa sababu tayari unayo? Haitumiki tena kwa madhumuni yoyote?
Kujibu: Kafka, ambayo ilikuwa, inatumiwa na timu ya Sayansi ya Data. Huu ni mradi tofauti kabisa, ambao, kwa bahati mbaya, siwezi kusema chochote. Sijui. Iliendeshwa na timu ya Sayansi ya Data. Wakati magogo yalipoundwa, tuliamua kuitumia ili tusiweke yetu wenyewe. Sasa tumesasisha Graylog, na tumepoteza uoanifu kwa sababu ina toleo la zamani la Kafka. Ilibidi tuanzishe yetu. Wakati huo huo, tuliondoa mada hizi nne kwa kila API. Tulitengeneza mada moja pana kwa wote moja kwa moja, mada moja pana kwa maonyesho yote na kuweka kila kitu hapo. Graylog inafuta haya yote kwa sambamba.
Swali: Kwa nini tunahitaji shamanism hii na soketi? Umejaribu kutumia kiendesha logi cha syslog kwa vyombo?
Kujibu: Wakati tunauliza swali hili, uhusiano wetu na docker ulikuwa wa wasiwasi. Ilikuwa docker 1.0 au 0.9. Docker yenyewe ilikuwa ya kushangaza. Pili, ikiwa pia unasukuma kumbukumbu ndani yake... Nina shaka ambayo haijathibitishwa kwamba inapitisha magogo yote kupitia yenyewe, kupitia daemon ya docker. Ikiwa API moja itaenda wazimu, basi API zingine zimekwama katika ukweli kwamba haziwezi kutuma stdout na stderr. Sijui hii itapelekea wapi. Nina mashaka katika kiwango cha kuhisi kuwa hakuna haja ya kutumia kiendesha syslog cha Docker mahali hapa. Idara yetu ya upimaji kazi ina nguzo yake ya Graylog yenye kumbukumbu. Wanatumia madereva ya logi ya Docker na kila kitu kinaonekana kuwa sawa hapo. Lakini mara moja wanaandika GELF kwa Graylog. Wakati tulipoanza haya yote, tulihitaji tu kufanya kazi. Labda baadaye, wakati mtu anakuja na kusema kwamba imekuwa ikifanya kazi vizuri kwa miaka mia moja, tutajaribu.
Swali: Unawasilisha kati ya vituo vya data kwa kutumia rsyslog. Kwa nini sio Kafka?
Kujibu: Tunafanya zote mbili kwa kweli. Kwa sababu mbili. Ikiwa chaneli imekufa kabisa, basi magogo yetu yote, hata katika fomu iliyoshinikizwa, haitatambaa kupitia hiyo. Na Kafka hukuruhusu kuwapoteza tu katika mchakato. Hivi ndivyo tunavyoondoa magogo haya kukwama. Tunatumia Kafka moja kwa moja katika kesi hii. Ikiwa tuna chaneli nzuri na tunataka kuikomboa, basi tunatumia rsyslog yao. Lakini kwa kweli, unaweza kuisanidi ili yenyewe ianguke kile ambacho hakikuingia. Kwa sasa, tunatumia utoaji wa rsyslog moja kwa moja mahali fulani, na Kafka mahali fulani.
Chanzo: mapenzi.com