Shunday qilib, siz ko'rsatkichlarni yig'asiz. Biz ham shunday qilamiz. Biz ko'rsatkichlarni ham yig'amiz. Albatta, biznesga tegishli bo'lganlar. Bugun biz sizga monitoring tizimimizning birinchi havolasi - statsd-mos keladigan yig'ish serveri haqida gapirib beramiz. , nega biz uni yozdik va nega biz brubekni tark etdik.
Oldingi maqolalarimizdan (, ) bir muncha vaqt oldin biz teglar yordamida to'planganimizni bilib olishingiz mumkin Bu C tilida yozilgan. Bu sichqoncha kabi oddiy (bu siz hissa qo'shmoqchi bo'lganingizda muhim) va eng muhimi, bizning sekundiga 2 million metrika (MPS) eng yuqori hajmini hech qanday muammosiz boshqaradi. Hujjatlarda yulduzcha bilan belgilangan 4 million MPS qo'llab-quvvatlanishi da'vo qilinadi. Bu shuni anglatadiki, agar siz tarmoqni to'g'ri sozlasangiz, ko'rsatilgan raqamni olasiz. Linux(Agar tarmoqni hozirgi holatida tark etsangiz, qancha MPS olishingiz mumkinligini bilmaymiz.) Ushbu afzalliklarga qaramay, bizda brubeck haqida bir nechta jiddiy shikoyatlar bo'ldi.
Da'vo 1. Loyihani ishlab chiquvchisi Github uni qoʻllab-quvvatlashni toʻxtatdi: yamoqlar va tuzatishlarni nashr etish, PRlarimizni (va boshqalarning) qabul qilish. Faoliyat so'nggi bir necha oy ichida qayta tiklandi (taxminan 2018 yil fevral-mart oylarida), ammo bundan oldin deyarli ikki yil to'liq sukunat hukm surgan edi. Bundan tashqari, loyiha ishlab chiqilmoqda. , bu yangi xususiyatlarni amalga oshirishda jiddiy to'siq bo'lishi mumkin.
Da'vo 2. Hisoblashning aniqligi. Brubek yig'ish uchun atigi 65 536 qiymatni to'playdi. Bizning holatda, ba'zi ko'rsatkichlar uchun yig'ish davri (30 soniya) sezilarli darajada ko'proq qiymatlarni olishi mumkin (cho'qqisida 1,527,392). Ushbu namuna olish natijasida maksimal va minimal qiymatlar foydasiz ko'rinadi. Masalan, bu kabi:
Bo'lganidek
Qanday bo'lishi kerak edi
Xuddi shu sababga ko'ra, summalar noto'g'ri hisoblangan. Bunga 32-bitli float to'lib-toshgan xatoni qo'shing, bu esa begunoh ko'rinadigan ko'rsatkichni qabul qilganda serverni segfaultga yuboradi va hamma narsa mukammal bo'ladi. Aytgancha, bu xato hech qachon tuzatilgan emas.
Va nihoyat, X da'voYozish vaqtida biz uni biz topgan barcha 14 yoki kamroq ishlaydigan statsd ilovalariga nisbatan sinab ko'rishga tayyormiz. Tasavvur qilaylik, ma'lum bir infratuzilma shunchalik o'sdiki, 4 million MPSni olish endi etarli emas. Yoki, agar u hali o'smagan bo'lsa ham, ko'rsatkichlar siz uchun shunchalik muhimki, hatto grafiklardagi qisqa, 2-3 daqiqalik pasayish ham tanqidiy bo'lib, menejerlarda yengib bo'lmaydigan depressiya hujumlarini keltirib chiqarishi mumkin. Depressiyani davolash nomaqbul ish bo'lganligi sababli, texnik echimlar kerak.
Birinchidan, xatolarga chidamlilik, to'satdan server muammosi ofisda ruhiy zombi apokalipsisini keltirib chiqarmasligi uchun. Ikkinchidan, masshtablash imkoniyati, shunda u tarmoq stekini chuqur o'rganmasdan 4 milliondan ortiq MPSni qayta ishlay oladi. Linux va xotirjamlik bilan kerakli o'lchamgacha "kenglikda" o'sadi.
Bizda bir oz o'lchamga ega bo'lganligi sababli, biz xatolarga chidamlilikdan boshlashga qaror qildik. "Oh! Xatolarga chidamlilik! Bu oddiy, biz buni qila olamiz", deb o'yladik va har birida brubeck nusxasini ishga tushirgan ikkita serverni ishga tushirdik. Buning uchun biz ikkala serverga o'lchovlar bilan trafikni nusxalashimiz va hatto buning uchun kod parchasini yozishimiz kerak edi. Biz xatolarga chidamlilik muammosini shu tarzda hal qildik, lekin... unchalik yaxshi emas. Avvaliga hamma narsa yaxshi bo'lib tuyuldi: har bir brubek o'zining yig'ish versiyasini to'playdi, har 30 soniyada Graphite-ga ma'lumotlarni yozadi, eski intervalni qayta yozadi (bu Grafit tomonida amalga oshiriladi). Agar bitta server ishlamay qolsa, bizda har doim yig'ilgan ma'lumotlarning o'ziga xos nusxasi bo'lgan ikkinchi server mavjud. Ammo bu erda muammo bor: agar server muvaffaqiyatsiz bo'lsa, grafiklarda "arralash uchun" naqsh paydo bo'ladi. Buning sababi, Brubekning 30 soniyali intervallari sinxronlashtirilmaydi va ulardan biri ishlamay qolganda, u qayta yozilmaydi. Xuddi shu narsa ikkinchi server ishga tushganda sodir bo'ladi. Bunga chidash mumkin, lekin biz yaxshiroq bo'lishni xohlaymiz! Kengaytirish muammosi ham saqlanib qolmoqda. Barcha ko'rsatkichlar hali ham bitta serverga o'tadi va shuning uchun biz tarmoq ishlashiga qarab bir xil 2-4 million MPS bilan cheklanamiz.
Agar siz qorni tozalash paytida muammo haqida bir oz o'ylab ko'rsangiz, sizning boshingizga aniq fikr paydo bo'lishi mumkin: sizga taqsimlangan rejimda ishlay oladigan statsd kerak. Ya'ni, vaqt va ko'rsatkichlar bo'yicha tugunlar o'rtasida sinxronizatsiyani amalga oshiradigan. “Albatta, bunday yechim allaqachon mavjuddir”, dedik va qidiruvga tushdik... Va hech narsa topmadik. Turli statsd uchun hujjatlarni ko'rib chiqqandan so'ng ( 2017 yil 11 dekabr holatiga ko'ra biz mutlaqo hech narsa topmadik. Ko'rinishidan, ushbu echimlarni ishlab chiquvchilar ham, foydalanuvchilari ham ko'p ko'rsatkichlarga duch kelishmagan, aks holda ular aniq nimadir o'ylab topishgan bo'lar edi.
Va keyin biz “Just for Fun” xakatonida yozgan “o‘yinchoq” statistikasini esladik (loyiha nomi hackathon oldidan skript tomonidan yaratilgan) va bizga zudlik bilan o‘z statistikamiz kerakligini angladik. Nega?
- chunki dunyoda statsd klonlari juda kam,
- chunki kerakli yoki kerakli xatoga chidamlilik va miqyosga yaqinlikni ta'minlash mumkin (jumladan, serverlar o'rtasida yig'ilgan o'lchovlarni sinxronlashtirish va jo'natish paytida nizolar muammosini hal qilish),
- chunki siz ko'rsatkichlarni Brubekka qaraganda aniqroq hisoblashingiz mumkin,
- chunki biz Brubek bizga deyarli hech qachon taqdim etmagan batafsilroq statistik ma'lumotlarni o'zimiz to'plashimiz mumkin,
- chunki men o'zimning giper-samaradorlikdagi taqsimlangan miqyosdagi ilovamni dasturlash imkoniyatiga ega bo'ldim, bu boshqa giper-samaradorlikning arxitekturasini to'liq takrorlamaydi ... yaxshi, tushunasiz.
Nima yozish kerak? Rust, albatta. Nega?
- chunki yechimning prototipi allaqachon mavjud edi,
- chunki maqola muallifi o'sha paytda Rustni allaqachon bilar edi va uni ochiq manba sifatida chiqarish imkoniyati bilan ishlab chiqarish uchun biror narsa yozishni xohlardi,
- chunki GCga ega tillar qabul qilingan trafikning tabiati (deyarli real vaqtda) va GC pauzalari tufayli biz uchun mos emas,
- chunki biz C bilan taqqoslanadigan maksimal ishlashga muhtojmiz
- Chunki Rust bizga qo'rqmas bir vaqtda kelishini beradi va agar biz uni C/C++ da yozishni boshlasak, biz brubek, zaifliklar, buferning to'lib ketishi, poyga sharoitlari va boshqa qo'rqinchli so'zlardan ham ko'proq narsani olamiz.
Rustga qarshi bahs ham bor edi. Kompaniya Rustda loyihalar yaratish tajribasiga ega emas edi va biz undan asosiy loyihamizda foydalanishni rejalashtirmagan edik. Xullas, bu ish bermasligidan jiddiy xavotirlar bor edi, lekin biz imkoniyatdan foydalanib, sinab ko'rishga qaror qildik.
Vaqt o'tdi…
Nihoyat, bir nechta muvaffaqiyatsiz urinishlardan so'ng, birinchi ishchi versiya tayyor bo'ldi. Nima bo'ldi? Bu shunday ko'rinardi.
Har bir tugun o'ziga xos ko'rsatkichlar to'plamini oladi va ularni to'playdi, lekin yakuniy yig'ish uchun to'liq to'plam talab qilinadigan ko'rsatkichlarni jamlamaydi. Tugunlar taqsimlangan blokirovka protokoli orqali ulanadi, bu ularga Buyukga o'lchovlarni yuborishga loyiq birini tanlash imkonini beradi (biz bu erda yig'ladik). Bu muammo hozirda tomonidan hal qilinmoqda , ammo kelajakda muallifning ambitsiyalari kengayadi Raft, bu erda konsensus rahbari tugun, albatta, eng munosib. Konsensusga qo'shimcha ravishda, tugunlar tez-tez (sukut bo'yicha, soniyada bir marta) o'z qo'shnilariga o'sha soniya davomida yig'ishga muvaffaq bo'lgan oldindan yig'ilgan ko'rsatkichlarni yuboradilar. Bu masshtablilik va nosozliklarga chidamlilikni saqlaydi — har bir tugun hali ham koʻrsatkichlarning toʻliq toʻplamini saqlab qoladi, lekin koʻrsatkichlar TCP orqali jamlangan holda yuboriladi va ikkilik protokolda kodlanadi, bu UDP bilan solishtirganda takrorlash xarajatlarini sezilarli darajada kamaytiradi. Kirish ko'rsatkichlarining nisbatan ko'pligiga qaramay, to'plash juda kam xotira va hatto kamroq CPU talab qiladi. Bizning yaxshi siqilgan ko'rsatkichlarimiz uchun bu bir necha o'nlab megabayt ma'lumotlarni tashkil qiladi. Qo'shimcha bonus - burbekda bo'lgani kabi, Graphite-da keraksiz ma'lumotlarni qayta yozishdan qochishdir.
Ko'rsatkichlarga ega UDP paketlari oddiy dumaloq robin yordamida tarmoq uskunasidagi tugunlar o'rtasida muvozanatlashtirilmaydi. Tabiiyki, tarmoq uskunasi paketlar tarkibini tahlil qilmaydi va shuning uchun u hech narsa bilmaydigan ko'rsatkichlarni hisobga olmaganda, soniyada 4 million paketdan ko'proq narsani bajara oladi. Ko'rsatkichlar har bir paketda alohida qabul qilinmasligini hisobga olsak, biz bu erda ishlash bilan bog'liq muammolarga duch kelmaymiz. Agar server ishlamay qolsa, tarmoq qurilmasi tezda (1-2 soniya ichida) buni aniqlaydi va tushirilgan serverni aylanishdan olib tashlaydi. Natijada, passiv (ya'ni, etakchi bo'lmagan) tugunlarni grafiklarda deyarli sezilarli pasayishsiz yoqish va o'chirish mumkin. Biz eng ko'p yo'qotadigan narsa - bu oxirgi soniyada kelgan ba'zi ko'rsatkichlar. Rahbarning to'satdan yo'qolishi/o'zgarishi hali ham kichik anomaliyani keltirib chiqaradi (30 soniyalik interval hali ham sinxronlashtirilmagan), ammo tugunlar o'rtasida aloqa mavjud bo'lsa, bu muammolarni, masalan, sinxronizatsiya paketlarini yuborish orqali minimallashtirish mumkin.
Ichki narsalar haqida bir oz. Ilova, albatta, ko'p tarmoqli, lekin ip arxitekturasi brubeckda qo'llaniladiganidan farq qiladi. Brubekdagi mavzular bir xil - ularning har biri ma'lumotlarni yig'ish va yig'ish uchun javobgardir. Bioyinoda ishchi iplar ikki guruhga bo'linadi: tarmoqni qayta ishlash uchun mas'ul bo'lganlar va yig'ish uchun mas'ul bo'lganlar. Ushbu bo'linish ko'rsatkichlar turiga qarab ilovalarni yanada moslashuvchan boshqarish imkonini beradi: intensiv yig'ish talab qilinadigan joylarda agregatorlarni qo'shish mumkin, tarmoq trafigining ko'p bo'lgan joyda esa ko'proq tarmoq iplarini qo'shish mumkin. Hozirda biz serverlarimizda sakkizta tarmoq iplari va to'rtta yig'ish iplari bilan ishlaymiz.
Hisoblash (jamlash) qismi ancha zerikarli. Tarmoq oqimlari bilan to'ldirilgan buferlar hisoblash oqimlari o'rtasida taqsimlanadi, bu erda ular keyinchalik tahlil qilinadi va yig'iladi. So'rov bo'yicha ko'rsatkichlar boshqa tugunlarga yuboriladi. Bularning barchasi, shu jumladan tugunlar o'rtasida ma'lumotlarni uzatish va konsul bilan o'zaro aloqa, asinxron tarzda amalga oshiriladi va ramkada ishlaydi. .
Ko'rsatkichlarni qabul qilish uchun mas'ul bo'lgan tarmoq komponenti rivojlanishda ko'proq muammolarni keltirib chiqardi. Tarmoq oqimlarini alohida ob'ektlarga ajratishning asosiy maqsadi har bir oqim sarflangan vaqtni qisqartirish edi. yo'q rozetkadan ma'lumotlarni o'qish uchun. Asinxron UDP va oddiy recvmsg dan foydalanish variantlari tezda ishlatilmaydigan bo'lib qoldi: birinchisi voqeani qayta ishlash uchun juda ko'p foydalanuvchi maydoni protsessorini sarflaydi, ikkinchisi esa juda ko'p kontekstli kalitlarni iste'mol qiladi. Shuning uchun hozirgi yondashuv Katta tamponlar bilan (va buferlar, janoblar, shunchaki hech narsa emas!). Oddiy UDP-ni qo'llab-quvvatlash recvmmsg kerak bo'lmaganda kam yuklangan holatlar uchun ajratilgan. Multimessage rejimi asosiy maqsadga erishadi: tarmoq tarmog'i o'z vaqtining katta qismini OS navbatini tozalashga sarflaydi - rozetkadan ma'lumotlarni o'qish va uni foydalanuvchilar maydoni buferiga o'tkazish, faqat vaqti-vaqti bilan to'liq buferni agregatorlarga topshirishga o'tadi. Soket navbati deyarli hech qachon to'planmaydi va tushgan paketlar soni deyarli ko'paymaydi.
nota
Odatiy bo'lib, bufer hajmi juda katta o'rnatiladi. Agar siz serverni o'zingiz sinab ko'rishga qaror qilsangiz, oz sonli o'lchovlarni yuborganingizdan so'ng, ular Graphite-ga etib bormay, tarmoq oqimi buferida qolishi mumkin. Kichik miqdordagi ko'rsatkichlarni boshqarish uchun siz bufsize va vazifa navbati o'lchamidagi konfiguratsiya fayllarida kichikroq qiymatlarni o'rnatishingiz kerak.
Nihoyat, grafiklarni sevuvchilar uchun ba'zi jadvallar.
Har bir server uchun kiruvchi ko'rsatkichlar soni bo'yicha statistika: 2 million MPS dan ortiq.
Tugunlardan birini o'chirish va kiruvchi ko'rsatkichlarni qayta taqsimlash.
Chiqish ko'rsatkichlari bo'yicha statistika: faqat bitta tugun yuboradi - reyd boshlig'i.
Turli xil tizim modullaridagi xatolarni hisobga olgan holda har bir tugunning ishlashi statistikasi.
Kiruvchi ko'rsatkichlar tafsilotlari (metrik nomlari yashirin).
Bularning barchasi bilan kelgusida nima qilishni rejalashtirmoqdamiz? Albatta kodni yozing! Loyiha dastlab ochiq manba sifatida rejalashtirilgan edi va butun umri davomida shunday bo'lib qoladi. Bizning yaqin rejalarimiz orasida Raft-ning o'z versiyamizga o'tish, tengdosh protokolini ko'proq portativga o'zgartirish, qo'shimcha ichki statistika qo'shish, yangi ko'rsatkich turlari, xatolarni tuzatish va boshqa yaxshilanishlar kiradi.
Albatta, loyihani ishlab chiqishda yordam berishni istagan har bir kishi qabul qilinadi: PR, muammolarni yarating va biz imkon qadar ularga javob beramiz, ularni yaxshilaymiz va hokazo.
Hamma odamlar, ular aytganidek, bizning fillarimizni sotib oling!
Manba: www.habr.com
