Jurnallar tizimning muhim qismi bo'lib, u kutilganidek ishlayotganini (yoki ishlamayotganini) tushunishga imkon beradi. Mikroservis arxitekturasida jurnallar bilan ishlash maxsus olimpiada uchun alohida intizomga aylanadi. Bir vaqtning o'zida bir nechta savollarni hal qilish kerak:
- dasturdan jurnallarni qanday yozish kerak;
- jurnallarni qayerda yozish kerak;
- saqlash va qayta ishlash uchun jurnallarni qanday etkazib berish;
- jurnallarni qanday qayta ishlash va saqlash.
Hozirgi vaqtda mashhur konteynerlash texnologiyalaridan foydalanish muammoni hal qilish variantlari maydoniga rake ustiga qum qo'shadi.
Yuriy Bushmelevning "Jurnallarni yig'ish va etkazib berish sohasidagi rakalar xaritasi" ma'ruzasining stenogrammasi aynan shu haqida.
Kimga g'amxo'rlik qiladi, iltimos, mushuk ostida.
Mening ismim Yuriy Bushmelev. Men Lazadada ishlayman. Bugun men jurnallarimizni qanday qilganimiz, ularni qanday yig'ganimiz va u erda nima yozganimiz haqida gapiraman.
Biz qayerdanmiz? Biz kimmiz? Lazada Janubi-Sharqiy Osiyodagi oltita davlatda 1-raqamli onlayn-riteyler hisoblanadi. Bu mamlakatlarning barchasi bizning ma'lumotlar markazlarimiz orasida taqsimlangan. Hozirda jami 4 ta maʼlumot markazlari mavjud. Nima uchun bu muhim? Chunki ba'zi qarorlar markazlar o'rtasida juda zaif aloqalar mavjudligi bilan bog'liq edi. Bizda mikroservis arxitekturasi mavjud. Bizda allaqachon 80 ta mikroservis borligini bilib hayron bo'ldim. Jurnallar bilan vazifani boshlaganimda, ularning atigi 20 tasi bor edi.Bundan tashqari, PHP merosining juda katta qismi bor, men ham yashashim va chidashim kerak. Bularning barchasi hozirda butun tizim uchun daqiqada 6 milliondan ortiq xabarlarni ishlab chiqaradi. Keyinchalik men bu bilan qanday yashashga harakat qilayotganimizni va nima uchun bunday ekanligini ko'rsataman.
Siz qandaydir tarzda ushbu 6 million xabar bilan yashashingiz kerak. Ular bilan nima qilishimiz kerak? Sizga kerak bo'lgan 6 million xabar:
- ilovadan yuborish
- yetkazib berish uchun qabul qilish
- tahlil qilish va saqlash uchun yetkazib berish.
- tahlil qilish
- uni qandaydir tarzda saqlang.
Uch million xabar paydo bo'lganda, men xuddi shunday qaradim. Chunki biz bir necha tiyin bilan boshladik. Ilova jurnallari u erda yozilganligi aniq. Misol uchun, men ma'lumotlar bazasiga ulana olmadim, ma'lumotlar bazasiga ulanishga muvaffaq bo'ldim, lekin hech narsa o'qiy olmadim. Ammo bundan tashqari, bizning har bir mikroservisimiz kirish jurnalini ham yozadi. Mikroservisga kelgan har bir so'rov jurnalda qayd etiladi. Nega buni qilyapmiz? Ishlab chiquvchilar kuzatish imkoniyatiga ega bo'lishni xohlashadi. Har bir kirish jurnali traceid maydonini o'z ichiga oladi, uning yordamida maxsus interfeys butun zanjirni bo'shatadi va izni chiroyli ko'rsatadi. Iz so'rov qanday o'tganligini ko'rsatadi va bu bizning ishlab chiquvchilarimizga har qanday noma'lum axlat bilan tezda kurashishga yordam beradi.
Bu bilan qanday yashash kerak? Endi men variantlar sohasini qisqacha tasvirlab beraman - bu muammo umuman qanday hal qilinadi. Jurnallarni yig'ish, uzatish va saqlash muammosini qanday hal qilish mumkin.
Ilovadan qanday yozish kerak? Turli xil yo'llar borligi aniq. Xususan, moda o'rtoqlarimiz aytganidek, eng yaxshi amaliyot mavjud. Bobolarimiz aytganidek, eski maktabning ikki turi mavjud. Boshqa yo'llar ham bor.
Jurnallarni yig'ish bilan bog'liq vaziyat taxminan bir xil. Ushbu alohida qismni hal qilish uchun ko'p variantlar mavjud emas. Ular allaqachon ko'p, lekin hali ko'p emas.
Ammo etkazib berish va keyingi tahlillar bilan o'zgarishlar soni portlashni boshlaydi. Men hozir har bir variantni tasvirlab bermayman. Menimcha, asosiy variantlar mavzuga qiziqqan har bir kishiga yaxshi ma'lum.
Men sizga Lazadada buni qanday qilganimizni va hammasi qanday boshlanganini ko'rsataman.
Bir yil oldin men Lazadaga keldim va loglar haqidagi loyihaga yuborildim. Bu shunga o'xshash narsa edi. Ilovalar jurnali stdout va stderr-ga yozilgan. Hamma narsa zamonaviy tarzda amalga oshirildi. Ammo keyin ishlab chiquvchilar uni standart oqimlardan chiqarib tashlashdi va keyin qandaydir tarzda infratuzilma mutaxassislari buni aniqlaydilar. Infratuzilma bo'yicha mutaxassislar va ishlab chiquvchilar o'rtasida: "Uh ... mayli, ularni qobiq bilan faylga o'rab qo'yaylik, tamom" degan relizlar ham bor. Va bularning barchasi konteynerda bo'lganligi sababli, ular uni to'g'ridan-to'g'ri idishning o'ziga o'rashdi, katalogni xaritaga solishdi va u erga qo'yishdi. O'ylaymanki, bu nimadan kelib chiqqani hamma uchun aniq.
Hozircha bir oz ko'proq qaraylik. Bu jurnallarni qanday yetkazib berdik? Kimdir td-agentni tanladi, u aslida ravon, lekin unchalik ravon emas. Men bu ikki loyiha o'rtasidagi munosabatlarni hali ham tushunmayapman, lekin ular bir xil narsaga o'xshaydi. Ruby-da yozilgan bu ravon, jurnal fayllarini o'qiydi va qandaydir muntazamlikdan foydalangan holda ularni JSONga ajratdi. Keyin ularni Kafkaga yubordim. Bundan tashqari, Kafkada bizda har bir API uchun 4 ta alohida mavzu bor edi. Nega 4? Chunki jonli bor, sahnalashtirish bor va stdout va stderr mavjud. Ishlab chiquvchilar ularni yaratadilar va infratuzilmani ishlab chiquvchilar ularni Kafkada yaratishlari kerak. Bundan tashqari, Kafka boshqa bo'lim tomonidan nazorat qilingan. Shuning uchun, har bir api uchun 4 ta mavzu yaratishlari uchun chipta yaratish kerak edi. Hamma buni unutdi. Umuman olganda, axlat va shovqin bor edi.
Bu bilan keyin nima qildik? Biz uni Kafkaga yubordik. Keyin Kafkadan kelgan loglarning yarmi Logstashga uchib ketdi. Jurnallarning qolgan yarmi bo'lingan. Ba'zilar bir Greylogga, ba'zilari boshqa Graylogga uchib ketishdi. Natijada, bularning barchasi bitta Elasticsearch klasteriga kirdi. Ya'ni, barcha tartibsizliklar shu erda tugadi. Buni qilmang!
Agar yuqoridan qarasangiz, shunday ko'rinadi. Buni qilmang! Bu erda muammoli joylar darhol raqamlar bilan belgilanadi. Ulardan ko'plari bor, lekin 6 tasi haqiqatan ham muammoli bo'lib, ular haqida nimadir qilish kerak. Men hozir ular haqida alohida aytib beraman.
Bu erda (1,2,3) biz fayllarni yozamiz va shunga mos ravishda bu erda bir vaqtning o'zida uchta rake mavjud.
Birinchisi (1) biz ularni biror joyga yozishimiz kerak. API ga to'g'ridan-to'g'ri faylga yozish qobiliyatini berish har doim ham istalmagan. API konteynerda ajratilgan bo'lishi yoki undan ham yaxshiroq, faqat o'qish uchun bo'lishi maqsadga muvofiqdir. Men tizim administratoriman, shuning uchun bu narsalarga biroz muqobil ko'rinishga egaman.
Ikkinchi nuqta (2,3) bizda API ga juda ko'p so'rovlar keladi. API faylga juda ko'p ma'lumotlarni yozadi. Fayllar o'sib bormoqda. Biz ularni aylantirishimiz kerak. Chunki aks holda siz u erda hech qanday diskda zaxira qila olmaysiz. Ularni aylantirish yomon, chunki ular qobiq orqali katalogga yo'naltirish orqali amalga oshiriladi. Uni qayta ko'rib chiqishning iloji yo'q. Ilovaga tutqichlarni qayta ochishni ayta olmaysiz. Chunki ishlab chiquvchilar sizga ahmoqdek qarashadi: “Qanday deskriptorlar? Biz odatda stdout-ga yozamiz. Infratuzilmani ishlab chiquvchilar logrotate uchun copytruncate qildilar, bu shunchaki faylning nusxasini yaratadi va asl nusxani transkripsiya qiladi. Shunga ko'ra, ushbu nusxalash jarayonlari orasida disk maydoni odatda tugaydi.
(4) Turli API-larda bizda turli formatlar mavjud edi. Ular biroz boshqacha edi, lekin regexp boshqacha yozilishi kerak edi. Bularning barchasi Qo'g'irchoq tomonidan nazorat qilinganligi sababli, o'zlarining hamamböceği bo'lgan katta guruh sinflari bor edi. Bundan tashqari, ko'pincha td-agent xotirani yeyishi, ahmoq bo'lishi mumkin, u o'zini ishlayotgandek ko'rsatishi va hech narsa qilmasligi mumkin. Tashqaridan uning hech narsa qilmayotganini tushunish mumkin emas edi. Eng yaxshi holatda u yiqilib tushadi va kimdir uni keyinroq olib ketadi. Aniqrog'i, ogohlantirish keladi va kimdir borib, uni qo'llari bilan ko'taradi.
(6) Va eng axlat va chiqindilar elasticsearch edi. Chunki bu eski versiya edi. Chunki o‘sha paytda bizda fidoyi ustalar yo‘q edi. Bizda maydonlari bir-birining ustiga chiqishi mumkin bo'lgan heterojen jurnallar mavjud edi. Turli xil ilovalarning turli jurnallari bir xil maydon nomlari bilan yozilishi mumkin, ammo ichida turli xil ma'lumotlar bo'lishi mumkin. Ya'ni, bitta jurnal maydonda Integer bilan birga keladi, masalan, daraja. Boshqa jurnal daraja maydonida String bilan birga keladi. Statik xaritalash bo'lmasa, bu juda ajoyib narsa. Agar elasticsearch-da indeksni aylantirgandan so'ng, birinchi navbatda satrli xabar kelsa, biz odatdagidek yashaymiz. Ammo agar birinchisi Integer'dan kelgan bo'lsa, String'dan kelgan barcha keyingi xabarlar shunchaki o'chiriladi. Chunki maydon turi mos kelmaydi.
Biz bu savollarni berishni boshladik. Biz aybdorlarni qidirmaslikka qaror qildik.
Lekin nimadir qilish kerak! Aniq narsa shundaki, biz standartlarni o'rnatishimiz kerak. Bizda allaqachon ba'zi standartlar mavjud edi. Biz biroz keyinroq boshladik. Yaxshiyamki, o'sha paytda barcha API uchun yagona jurnal formati allaqachon tasdiqlangan edi. U to'g'ridan-to'g'ri xizmatlar o'rtasidagi o'zaro aloqa standartlariga yozilgan. Shunga ko'ra, jurnallarni olishni istaganlar ularni ushbu formatda yozishlari kerak. Agar kimdir ushbu formatda jurnallarni yozmasa, biz hech narsaga kafolat bermaymiz.
Keyinchalik, jurnallarni yozish, etkazib berish va yig'ish usullari uchun yagona standart yaratmoqchiman. Aslida, ularni qaerga yozish va ularni qanday etkazish kerak. Loyihalar bir xil kutubxonadan foydalanganda ideal holat. Go uchun alohida jurnal kutubxonasi va PHP uchun alohida kutubxona mavjud. Bizda mavjud bo'lgan har bir kishi ulardan foydalanishi kerak. Ayni paytda bu borada 80 foiz muvaffaqiyatga erishganimizni aytgan bo'lardim. Ammo ba'zi odamlar kaktuslarni eyishni davom ettiradilar.
Va u erda (slaydda) "Jurnallarni etkazib berish uchun SLA" zo'rg'a paydo bo'la boshlaydi. Bu hali mavjud emas, lekin biz buning ustida ishlayapmiz. Chunki infratuzilma falon joyga falon formatda yozsangiz va sekundiga N tadan ko‘p bo‘lmagan xabarlarni yozsangiz, uni falon joyga yetkazib beramiz, deganda juda qulay. Bu juda ko'p bosh og'rig'ini engillashtiradi. Agar SLA bo'lsa, bu juda ajoyib!
Muammoni qanday hal qilishni boshladik? Asosiy muammo td-agent bilan bog'liq edi. Bizning jurnallarimiz qaerga ketganligi aniq emas edi. Ular yetkazib beriladimi? Ular ketyaptimi? Ular qayerda? Shuning uchun, birinchi nuqta td-agentni almashtirishga qaror qilindi. Men bu erda uni nima bilan almashtirish variantlarini qisqacha bayon qildim.
Fluentd. Birinchidan, men uni oldingi ish joyida uchratdim va u ham vaqti-vaqti bilan u erga tushib qoldi. Ikkinchidan, bu xuddi shunday, faqat profilda.
Filebeat. Bu biz uchun qanday qulay edi? Chunki u Go'da va bizda Go'da ko'p tajriba bor. Shunga ko'ra, agar biror narsa yuz bergan bo'lsa, biz qandaydir tarzda o'zimiz uchun qo'shishimiz mumkin edi. Shuning uchun biz uni olmadik. Shunday qilib, uni o'zingiz uchun qayta yozishni boshlash vasvasasi ham bo'lmaydi.
Tizim administratori uchun aniq yechim bu miqdordagi barcha turdagi sysloglardir (syslog-ng/rsyslog/nxlog).
Yoki o'zingizdan biror narsa yozing, lekin biz buni ham, filebeatni ham bekor qildik. Agar biror narsa yozsangiz, biznes uchun foydali narsalarni yozganingiz ma'qul. Jurnallarni etkazib berish uchun tayyor narsalarni olish yaxshiroqdir.
Shuning uchun tanlov aslida syslog-ng va rsyslog o'rtasidagi tanlovga tushdi. Men rsyslogga moyil bo'ldim, chunki bizda allaqachon Qo'g'irchoqda rsyslog uchun darslar bor edi va ular o'rtasida aniq farq topmadim. Syslog nima, syslog nima. Ha, ba'zilarida hujjatlar yomonroq, ba'zilarida esa yaxshiroq. Buni shunday qilish mumkin, ikkinchisi esa boshqacha qilish mumkin.
Va rsyslog haqida bir oz. Birinchidan, bu juda zo'r, chunki u juda ko'p modullarga ega. Unda odam o'qiy oladigan RainerScript (zamonaviy konfiguratsiya tili) mavjud. Biz standart vositalardan foydalangan holda td-agentning xatti-harakatlariga taqlid qilishimiz mumkin bo'lgan ajoyib bonus va ilovalar uchun hech narsa o'zgarmadi. Ya'ni, biz td-agentni rsyslog ga o'zgartiramiz va qolganlarini hozircha yolg'iz qoldiramiz. Va biz darhol ishchi yetkazib beramiz. Keyinchalik, mmnormalize rsyslog-da ajoyib narsadir. Bu sizga jurnallarni tahlil qilish imkonini beradi, lekin Grok va regexp dan foydalanmaydi. U mavhum sintaksis daraxtini yaratadi. U jurnallarni xuddi kompilyator manbalarni tahlil qilgandek tahlil qiladi. Bu sizga juda tez ishlashga, kam protsessorni iste'mol qilishga imkon beradi va umuman olganda, bu juda ajoyib narsa. Boshqa ko'plab bonuslar mavjud. Men ular haqida to‘xtalmayman.
rsyslog boshqa ko'plab kamchiliklarga ega. Ular bonuslar bilan deyarli bir xil. Asosiy muammolar shundaki, siz uni qanday pishirishni bilishingiz kerak va siz versiyani tanlashingiz kerak.
Biz unix soketiga jurnallar yozishga qaror qildik. Va /dev/log da emas, chunki bizda tizim jurnallari chalkashliklari bor, jurnal bu quvurda. Shunday qilib, keling, maxsus rozetkaga yozaylik. Biz uni alohida qoidalar to'plamiga biriktiramiz. Hech narsaga aralashmaylik. Hamma narsa shaffof va tushunarli bo'ladi. Biz aynan shunday qildik. Ushbu rozetkalarga ega katalog standartlashtirilgan va barcha konteynerlarga yuboriladi. Konteynerlar kerakli rozetkani ko'rishlari, ochishlari va unga yozishlari mumkin.
Nega fayl emas? Chunki hamma uni o'qiydi , faylni dockerga yuborishga harakat qildi va rsyslogni qayta ishga tushirgandan so'ng, fayl identifikatori o'zgargani va docker bu faylni yo'qotgani aniqlandi. U boshqa narsalarni ochiq tutadi, lekin ular yozayotgan rozetkani emas. Biz ushbu muammoni hal qilishga qaror qildik va shu bilan birga blokirovka muammosini hal qilishga qaror qildik.
Rsyslog slaydda ko'rsatilgan amallarni bajaradi va jurnallarni reley yoki Kafkaga yuboradi. Kafka eski yo'ldan yuradi. Relay - Men jurnallarni etkazib berish uchun sof rsyslogdan foydalanishga harakat qildim. Xabar navbatisiz, standart rsyslog vositalaridan foydalangan holda. Asosan, u ishlaydi.
Ammo ularni ushbu qismga qanday kiritish kerakligi bilan bog'liq nuanslar mavjud (Logstash/Graylog/ES). Ushbu qism (rsyslog-rsyslog) ma'lumotlar markazlari o'rtasida ishlatiladi. Mana siqilgan tcp havolasi, bu bizga o'tkazish qobiliyatini tejashga imkon beradi va shunga mos ravishda kanal tiqilib qolganda boshqa ma'lumotlar markazidan ba'zi jurnallarni olish ehtimolini oshiradi. Chunki bizda hamma narsa yomon Indoneziya bor. Bu erda doimiy muammo yotadi.
Biz ilovadan yozib olgan jurnallar oxirigacha etib borishini qanday kuzatishimiz mumkinligi haqida o'yladik? Biz ko'rsatkichlarni yaratishga qaror qildik. rsyslog o'zining statistika yig'ish moduliga ega bo'lib, u qandaydir hisoblagichlarni o'z ichiga oladi. Masalan, u sizga navbat hajmini yoki falon harakatda qancha xabar kelganligini ko'rsatishi mumkin. Siz allaqachon ulardan biror narsa olishingiz mumkin. Bundan tashqari, u sozlanishi mumkin bo'lgan maxsus hisoblagichlarga ega va u sizga, masalan, ba'zi API yozib olgan xabarlar sonini ko'rsatadi. Keyin Python-da rsyslog_exporter yozdim va biz hammasini Prometeyga yubordik va grafiklar qurdik. Biz Graylog ko'rsatkichlarini juda xohlardik, lekin ularni sozlashga hali vaqtimiz yo'q.
Qanday muammolar bor edi? Bizning Live API-larimiz sekundiga 50 ming xabar yozayotganini aniqlaganimizda (TO'satdan!) muammolar paydo bo'ldi. Bu sahnalashtirmasdan faqat Live API. Va Graylog bizga soniyada atigi 12 ming xabarni ko'rsatadi. Va oqilona savol tug'ildi: qoldiqlar qayerda? Shundan kelib chiqib, biz Graylog shunchaki bardosh bera olmaydi degan xulosaga keldik. Biz qaradik va haqiqatan ham Graylog va Elasticsearch bu oqimga bardosh bera olmadi.
Keyinchalik, biz yo'lda qilgan boshqa kashfiyotlar.
Rozetkaga yozishlar bloklangan. Bu qanday sodir bo `LDI? Men yetkazib berish uchun rsyslog dan foydalanganimda, ma'lumotlar markazlari orasidagi kanal buzilib ketdi. Bir joyda yetkazib berish to‘xtadi, boshqa joyda yetkazib berish to‘xtadi. Bularning barchasi rsyslog soketiga yozadigan API-larga ega mashinaga etib keldi. U yerda navbat bor edi. Keyin sukut bo'yicha 128 paket bo'lgan unix soketiga yozish uchun navbat to'ldi. Va ilovadagi keyingi yozish() bloklangan. Biz Go ilovalarida foydalanadigan kutubxonani ko'rib chiqqanimizda, u erda rozetkaga yozish bloklanmaydigan rejimda sodir bo'lishi yozilgan edi. Hech narsa to'sqinlik qilmaganiga amin edik. Chunki biz o'qiymiz bu haqda kim yozgan. Ammo bir daqiqa bor. Shuningdek, ushbu qo'ng'iroq atrofida cheksiz halqa bor edi, unda doimiy ravishda rozetkaga xabarni surish uchun urinish mavjud edi. Biz uni sezmadik. Men kutubxonani qayta yozishim kerak edi. O'shandan beri u bir necha bor o'zgardi, ammo endi biz barcha quyi tizimlarda blokirovkadan xalos bo'ldik. Shunday qilib, siz rsyslogni to'xtatishingiz mumkin va hech narsa buzilmaydi.
Navbatlar hajmini kuzatish kerak, bu esa bu rakega qadam qo'ymaslikka yordam beradi. Birinchidan, biz xabarlarni yo'qotishni boshlaganimizda kuzatishimiz mumkin. Ikkinchidan, biz etkazib berish bilan bog'liq muammolar mavjudligini kuzatishimiz mumkin.
Va yana bir noxush lahza - mikroservis arxitekturasida 10 marta kuchaytirish juda oson. Bizda juda ko'p kiruvchi so'rovlar yo'q, lekin bu xabarlar yanada ko'proq tarqaladigan grafik tufayli, kirish jurnallari tufayli biz log yukini taxminan o'n baravar oshiramiz. Afsuski, aniq raqamlarni hisoblash uchun vaqtim yo'q edi, lekin mikroservislar - bu. Buni yodda tutish kerak. Ma'lum bo'lishicha, hozirda jurnallarni yig'ish quyi tizimi Lazada-da eng ko'p yuklangan.
Elasticsearch muammosini qanday hal qilish mumkin? Agar siz jurnallarni bir joyda tezda olishingiz kerak bo'lsa, barcha mashinalarga yugurib ketmaslik va ularni u erda to'plash uchun fayllarni saqlashdan foydalaning. Bu ishlashi kafolatlangan. Bu har qanday serverdan amalga oshirilishi mumkin. Siz shunchaki disklarni u erga yopishtirishingiz va syslogni o'rnatishingiz kerak. Shundan so'ng, sizga barcha jurnallar bir joyda bo'lishi kafolatlanadi. Keyin asta-sekin elasticsearch, graylog va boshqa narsalarni sozlashingiz mumkin. Ammo siz allaqachon barcha jurnallarga ega bo'lasiz va bundan tashqari, siz ularni etarlicha disk massivlari mavjud bo'lganda saqlashingiz mumkin.
Mening hisobotim paytida sxema shunday ko'rinishni boshladi. Biz amalda faylga yozishni to'xtatdik. Endi, katta ehtimol bilan, qolganlarini o'chirib qo'yamiz. API bilan ishlaydigan mahalliy mashinalarda biz fayllarga yozishni to'xtatamiz. Birinchidan, faylni saqlash mavjud, bu juda yaxshi ishlaydi. Ikkinchidan, bu mashinalar doimo bo'sh joy tugaydi, uni doimiy ravishda kuzatib borish kerak.
Logstash va Graylog bilan bu qism, u haqiqatan ham o'chib ketadi. Shuning uchun biz undan qutulishimiz kerak. Siz bitta narsani tanlashingiz kerak.
Biz Logstash va Kibanani tashlashga qaror qildik. Chunki bizda xavfsizlik bo‘limi bor. Qanday aloqa? Aloqa shundaki, Kibana X-Packsiz va Shieldsiz jurnallarga kirish huquqlarini farqlashga imkon bermaydi. Shuning uchun biz Graylogni oldik. Unda hammasi bor. Menga yoqmaydi, lekin u ishlaydi. Biz yangi uskuna sotib oldik, u yerda yangi Graylog-ni o'rnatdik va qattiq formatdagi barcha jurnallarni alohida Graylog-ga o'tkazdik. Biz turli xil turdagi bir xil maydonlar bilan muammoni tashkiliy jihatdan hal qildik.
Yangi Graylogga aynan nima kiritilgan. Biz hamma narsani dockerga yozdik. Biz bir nechta serverlarni oldik, uchta Kafka nusxasini, 7 Graylog serverining 2.3 versiyasini chiqardik (chunki biz Elasticsearch 5-versiyasini xohladik). Bularning barchasi HDD reydlari paytida olingan. Biz sekundiga 100 ming xabarni indekslash tezligini ko'rdik. Biz haftasiga 140 terabayt ma'lumot olishini ko'rdik.
Va yana rake! Oldinda ikkita sotuvimiz bor. Biz 6 million xabardan oshib ketdik. Graylogning chaynashga vaqti yo'q. Qandaydir tarzda biz yana omon qolishimiz kerak.
Shunday qilib biz omon qoldik. Biz yana bir nechta serverlar va SSD'larni qo'shdik. Ayni paytda biz shunday yashayapmiz. Endi biz sekundiga 160 ming xabarni chaynayapmiz. Biz hali chegaraga yetganimiz yo'q, shuning uchun biz bundan qanchasini olishimiz mumkinligi noma'lum.
Bu bizning kelajak uchun rejalarimiz. Ulardan eng muhimi, ehtimol, yuqori darajadagi mavjudlikdir. Bizda hali yo'q. Bir nechta mashinalar xuddi shu tarzda tuzilgan, ammo hozirgacha hamma narsa bitta mashinadan o'tmoqda. Ular o'rtasida o'zgartirishni o'rnatish uchun vaqt kerak bo'ladi.
Graylog-dan ko'rsatkichlarni to'plang.
Bizning tarmoqli kengligimiz va boshqa hamma narsani o'ldirmaydigan bitta aqldan ozgan API bo'lishi uchun tarif chegarasini belgilang.
Va nihoyat, ishlab chiquvchilar bilan qandaydir SLAni imzolang, shunda biz shunchalik ko'p xizmat qila olamiz. Agar siz ko'proq yozsangiz, kechirasiz.
Va hujjatlarni yozing.
Qisqacha aytganda, biz boshdan kechirgan hamma narsaning natijalari. Birinchidan, standartlar. Ikkinchidan, syslog - bu tort. Uchinchidan, rsyslog xuddi slaydda yozilganidek ishlaydi. Va keling, savollarga o'tamiz.
Sizning savollaringiz.
Sizning savolingiz: Nega qabul qilmaslikka qaror qildingiz... (filebeat?)
Javob bering: Biz faylga yozishimiz kerak. Men haqiqatan ham xohlamadim. Sizning API sekundiga minglab xabarlarni yozganda, hatto uni soatiga bir marta aylantirsangiz ham, bu variant emas. Quvurda yozishingiz mumkin. Ishlab chiquvchilar mendan so'rashdi: "Agar biz yozayotgan jarayon buzilib qolsa nima bo'ladi?" Men ularga nima deb javob berishni topolmadim va: "Xo'sh, buni qilmaylik", dedim.
Sizning savolingiz: Nima uchun faqat HDFS-ga jurnallar yozmaysiz?
Javob bering: Bu keyingi bosqich. Biz bu haqda boshida o'ylagan edik, ammo hozirda buni amalga oshirish uchun resurslar yo'qligi sababli, bu bizning uzoq muddatli yechimimizda osilgan.
Sizning savolingiz: Ustun formati ko'proq mos keladi.
Javob bering: Men hammasini tushunaman. Biz ikkala qo'l bilan ham bunga tayyormiz.
Sizning savolingiz: Siz rsyslogga yozyapsiz. U erda siz TCP va UDP dan foydalanishingiz mumkin. Ammo agar UDP bo'lsa, etkazib berishni qanday kafolatlaysiz?
Javob bering: Ikki nuqta bor. Birinchidan, men darhol hammaga aytaman, biz loglarni yetkazib berishni kafolatlamaymiz. Chunki ishlab chiquvchilar kelib: "Keling, moliyaviy ma'lumotlarni yozishni o'sha erda boshlaylik, agar biror narsa yuz bersa, biz uchun biror joyga qo'yasiz", deyishganda, biz ularga javob beramiz: "Ajoyib! Keling, rozetkaga yozishni bloklashni boshlaylik va buni tranzaktsiyalarda bajaramiz, shunda siz uni rozetkaga qo'yishingiz va biz uni boshqa tomondan olishimizga ishonch hosil qilishingiz mumkin." Va hozirda hamma darhol unga muhtoj emas. Agar kerak bo'lmasa, qanday savollarni berishimiz kerak? Agar rozetkaga yozishni kafolatlashni istamasangiz, nega biz yetkazib berishni kafolatlashimiz kerak? Biz bor kuchimizni sarflaymiz. Biz haqiqatan ham imkon qadar ko'proq va eng yaxshi tarzda etkazib berishga harakat qilamiz, lekin biz 100% kafolat bermaymiz. Shuning uchun u erda moliyaviy ma'lumotlarni yozishning hojati yo'q. Buning uchun tranzaktsiyalar bilan ma'lumotlar bazalari mavjud.
Sizning savolingiz: API jurnalda ba'zi xabarlarni yaratganda va boshqaruvni mikroservislarga o'tkazganda, turli mikroservislardan xabarlar noto'g'ri tartibda kelishi muammosiga duch keldingizmi? Bu chalkashlikka olib keladi.
Javob bering: Ularning har xil tartibda kelishi normal holat. Siz bunga tayyor bo'lishingiz kerak. Chunki har qanday tarmoq yetkazib berish buyurtmani kafolatlamaydi yoki buning uchun maxsus resurslarni sarflash kerak bo'ladi. Agar biz fayl omborlarini olsak, har bir API jurnallarni o'z fayliga saqlaydi. To'g'rirog'i, rsyslog ularni kataloglarga ajratadi. Har bir API o'z jurnallariga ega, u erda siz borib ko'rishingiz mumkin, keyin ularni ushbu jurnaldagi vaqt tamg'asi yordamida solishtirishingiz mumkin. Agar ular Graylogga qarashsa, ular vaqt tamg'asi bo'yicha saralanadi. U erda hammasi yaxshi bo'ladi.
Sizning savolingiz: Vaqt tamg'asi millisekundlarda farq qilishi mumkin.
Javob bering: Vaqt tamg'asi APIning o'zi tomonidan yaratilgan. Bu, aslida, butun nuqta. Bizda NTP bor. API xabarning o'zida vaqt tamg'asini yaratadi. rsyslog uni qo'shmaydi.
Sizning savolingiz: Ma'lumotlar markazlari o'rtasidagi o'zaro aloqa juda aniq emas. Ma'lumotlar markazida jurnallar qanday yig'ilgani va qayta ishlangani aniq. Ma'lumotlar markazlari o'rtasidagi o'zaro ta'sir qanday amalga oshiriladi? Yoki har bir ma'lumot markazi o'z hayotini yashaydimi?
Javob bering: Deyarli. Mamlakatimizda har bir davlat bitta ma'lumot markazida joylashgan. Ayni paytda bizda bitta mamlakat turli ma'lumotlar markazlarida joylashganligi uchun tarqalish yo'q. Shuning uchun ularni birlashtirishning hojati yo'q. Har bir markazning ichida jurnal o'rni mavjud. Bu Rsyslog serveri. Aslida ikkita boshqaruv mashinasi. Ular bir xil munosabatda. Ammo hozircha trafik ulardan biri orqali o'tadi. U barcha jurnallarni birlashtiradi. Har ehtimolga qarshi uning disk navbati bor. U jurnallarni yuklab oladi va ularni markaziy ma'lumotlar markaziga (Singapur) yuboradi, u erda ular Graylogga yuboriladi. Va har bir ma'lumot markazining o'z fayl xotirasi mavjud. Agar ulanishimiz yo'qolsa, bizda barcha jurnallar mavjud. Ular u erda qoladilar. Ular u erda saqlanadi.
Sizning savolingiz: Agar g'ayritabiiy vaziyatlar bo'lsa, u erdan jurnallarni olasizmi?
Javob bering: Siz u yerga (fayl saqlash joyiga) borib, qarashingiz mumkin.
Sizning savolingiz: Jurnallarni yo'qotmasligingizni qanday nazorat qilasiz?
Javob bering: Biz aslida ularni yo'qotmoqdamiz va biz buni kuzatmoqdamiz. Monitoring bir oy oldin boshlangan. Go API ishlatadigan kutubxona ko'rsatkichlarga ega. U rozetkaga necha marta yoza olmaganini sanab bera oladi. Hozirda u erda aqlli evristik mavjud. U erda bufer mavjud. Undan rozetkaga xabar yozishga harakat qiladi. Agar bufer to'lib ketgan bo'lsa, u ularni tashlab keta boshlaydi. Va u ulardan qanchasini tashlaganini hisoblaydi. Agar hisoblagichlar u erda toshib keta boshlasa, biz bu haqda bilib olamiz. Ular endi prometeyga ham kelishmoqda va siz Grafanadagi grafiklarni ko'rishingiz mumkin. Siz ogohlantirishlarni sozlashingiz mumkin. Ammo ularni kimga jo‘natish hozircha aniq emas.
Sizning savolingiz: Elasticsearch-da siz jurnallarni ortiqcha bilan saqlaysiz. Qancha nusxangiz bor?
Javob bering: Bir qator.
Sizning savolingiz: Bu faqat bitta qatormi?
Javob bering: Bu master va replika. Ma'lumotlar ikki nusxada saqlanadi.
Sizning savolingiz: Rsyslog bufer hajmini qandaydir tarzda sozladingizmi?
Javob bering: Biz datagramlarni maxsus unix soketiga yozamiz. Bu bizga darhol 128 kilobayt chegarani qo'yadi. Biz unga ko'proq yozolmaymiz. Biz buni standartga yozdik. Xotiraga kirmoqchi bo'lganlar 128 kilobayt yozadilar. Bundan tashqari, kutubxonalar kesiladi va xabar kesilgan bayroq qo'yiladi. Bizning standartimiz xabar uchun maxsus maydonga ega bo'lib, u yozib olish paytida uzilganmi yoki yo'qligini ko'rsatadi. Demak, bizda ham bu lahzani kuzatish imkoni bor.
Savol: Buzilgan JSON yozasizmi?
Javob bering: Buzilgan JSON paket juda katta bo'lgani uchun o'tish paytida ham o'chiriladi. Yoki Graylog olib tashlanadi, chunki u JSONni tahlil qila olmaydi. Lekin tuzatilishi kerak bo'lgan nuanslar mavjud va ular asosan rsyslog bilan bog'langan. Men u erda bir nechta masalalarni to'ldirdim, ular ustida ishlash kerak.
Savol: Nega Kafka? RabbitMQ-ni sinab ko'rdingizmi? Graylog bunday yuklarda muvaffaqiyatsizlikka uchraydimi?
Javob bering: Graylog bilan biz uchun ishlamayapti. Va Graylog biz uchun shakllanmoqda. U haqiqatan ham muammoli. U o'ziga xos narsa. Va, aslida, bu kerak emas. Men rsyslog-dan to'g'ridan-to'g'ri elasticsearch-ga yozishni va keyin Kibana-ga qarashni afzal ko'raman. Ammo biz bu masalani qo'riqchilar bilan hal qilishimiz kerak. Bu bizning rivojlanishimiz uchun mumkin bo'lgan variant, biz Graylogni chiqarib tashlaganimizda va Kibana-dan foydalanamiz. Logstash-dan foydalanishning ma'nosi yo'q. Chunki rsyslog bilan ham xuddi shunday qila olaman. Unda elasticsearch ga yozish uchun modul mavjud. Biz qandaydir tarzda Graylog bilan yashashga harakat qilyapmiz. Biz hatto uni biroz sozladik. Lekin hali ham yaxshilanish uchun joy bor.
Kafka haqida. Tarixiy jihatdan shunday bo'lgan. Men kelganimda, u allaqachon bor edi va unga jurnallar allaqachon yozilayotgan edi. Biz shunchaki klasterimizni ko'tardik va unga jurnallarni joylashtirdik. Biz uning boshqaruvimiz, uning his-tuyg'ularini bilamiz. RabbitMQ-ga kelsak, RabbitMQ bilan bu biz uchun ishlamaydi. RabbitMQ esa biz uchun shakllanmoqda. Bizda ishlab chiqarishda bor va u bilan bog'liq muammolar bor edi. Endi sotuvdan oldin uni maftun qilishardi va u odatdagidek ishlay boshlaydi. Ammo bundan oldin men uni ishlab chiqarishga chiqarishga tayyor emas edim. Yana bir nuqta bor. Graylog AMQP 0.9 versiyasini o'qiy oladi va rsyslog AMQP 1.0 versiyasini yozishi mumkin. Va o'rtada ikkalasini ham qila oladigan yagona yechim yo'q. Bu yoki boshqasi. Shuning uchun, hozirda faqat Kafka. Ammo uning o'ziga xos nuanslari ham bor. Chunki biz foydalanadigan rsyslog versiyasining omkafka rsyslogdan olingan butun xabar buferini yo'qotishi mumkin. Hozircha bunga chidaymiz.
Savol: Kafka sizda allaqachon bo'lganligi uchun foydalanyapsizmi? Endi hech qanday maqsadda foydalanilmaydimi?
Javob bering: bo'lgan Kafka Data Science jamoasi tomonidan qo'llaniladi. Bu mutlaqo alohida loyiha, afsuski, men hech narsa deya olmayman. Bilmadim; bilmayman. Uni Data Science jamoasi boshqargan. Jurnallar yaratilganda, biz o'zimizni o'rnatmaslik uchun uni ishlatishga qaror qildik. Endi biz Graylog-ni yangiladik va biz moslikni yo'qotdik, chunki unda Kafkaning eski versiyasi mavjud. Biz o'zimizni boshlashimiz kerak edi. Shu bilan birga, biz har bir API uchun ushbu to'rtta mavzudan xalos bo'ldik. Biz jonli efirda hamma uchun bitta keng mavzuni, barcha sahnalashtirish uchun bitta keng mavzuni yaratdik va hamma narsani shu yerga joylashtirdik. Graylog bularning barchasini parallel ravishda qirib tashlaydi.
Savol: Bu rozetkali shamanizm bizga nima uchun kerak? Konteynerlar uchun syslog log drayveridan foydalanishga harakat qildingizmi?
Javob bering: Biz bu savolni bergan paytimizda doker bilan munosabatlarimiz keskin edi. Bu docker 1.0 yoki 0.9 edi. Dockerning o'zi g'alati edi. Ikkinchidan, agar siz unga loglarni ham kiritsangiz... Menda tekshirilmagan shubha bor, u barcha jurnallarni o'zidan, docker demoni orqali o'tkazadi. Agar bitta API aqldan ozgan bo'lsa, qolgan APIlar stdout va stderr ni yubora olmasligi bilan bog'liq. Bu qayerga olib kelishini bilmayman. Menda bu joyda Docker syslog drayverini ishlatishning hojati yo'qligini his qilish darajasida shubha bor. Funktsional test bo'limimiz jurnallar bilan o'z Graylog klasteriga ega. Ular Docker jurnali drayverlaridan foydalanadilar va u erda hamma narsa yaxshi ko'rinadi. Lekin ular darhol Graylogga GELF yozishadi. Bularning barchasini boshlaganimizda, bizga faqat ishlash kerak edi. Balki, keyinroq kimdir kelib, yuz yildan beri yaxshi ishlayapti, desa, harakat qilamiz.
Savol: Siz rsyslog yordamida ma'lumotlar markazlari o'rtasida yetkazib berishni amalga oshirasiz. Nega Kafka emas?
Javob bering: Haqiqatan ham ikkalamiz ham qilamiz. Ikki sababga ko'ra. Agar kanal butunlay o'lik bo'lsa, bizning barcha jurnallarimiz, hatto siqilgan shaklda ham, u orqali o'tmaydi. Kafka esa bu jarayonda ularni shunchaki yo'qotishga imkon beradi. Shunday qilib, biz bu jurnallarning tiqilib qolishidan xalos bo'lamiz. Biz bu holatda to'g'ridan-to'g'ri Kafkadan foydalanamiz. Agar bizda yaxshi kanal bo'lsa va uni ozod qilmoqchi bo'lsak, biz ularning rsyslogidan foydalanamiz. Ammo, aslida, siz uni o'zi mos kelmagan narsalarni tashlab ketishi uchun sozlashingiz mumkin. Ayni paytda biz rsyslog yetkazib berishdan to'g'ridan-to'g'ri bir joyda foydalanamiz va Kafka qayerdadir.
Manba: www.habr.com