Тиймээс та хэмжүүр цуглуулдаг. Бидний байгаагаар. Бид бас хэмжүүр цуглуулдаг. Мэдээжийн хэрэг, бизнест хэрэгтэй. Өнөөдөр бид хяналтын системийн хамгийн эхний холбоос болох statsd-тэй нийцтэй нэгтгэх серверийн талаар ярих болно. , бид яагаад үүнийг бичсэн, яагаад бид брубекийг орхисон юм.
Бидний өмнөх нийтлэлүүдээс (, ) Хэсэг хугацаанд бид тэмдэглэгээг ашиглан цуглуулж байсныг та мэдэж болно . Энэ нь C хэл дээр бичигдсэн байдаг. Кодын үүднээс авч үзвэл энэ нь залгуур шиг энгийн (та хувь нэмрээ оруулахыг хүсч байгаа үед энэ нь чухал юм) бөгөөд хамгийн чухал нь секундэд 2 сая хэмжигдэхүүнийг (MPS) дээд цэгтээ хүргэдэг. ямар ч асуудалгүй. Баримт бичигт одоор тэмдэглэсэн 4 сая MPS-ийг дэмжсэн байна. Энэ нь та Линукс дээр сүлжээгээ зөв тохируулсан тохиолдолд заасан тоог авна гэсэн үг. (Хэрэв та сүлжээг байгаагаар нь орхивол хэдэн MPS авах боломжтойг бид мэдэхгүй). Эдгээр давуу талуудыг үл харгалзан бид брубекийн талаар хэд хэдэн ноцтой гомдол гаргасан.
Нэхэмжлэл 1. Төслийн хөгжүүлэгч Github үүнийг дэмжихээ больсон: засварууд болон засваруудыг нийтлэх, бидний болон (зөвхөн бидний биш) PR-ийг хүлээн авах. Сүүлийн хэдэн сард (2018 оны 2-р сараас XNUMX-р сар хүртэл хаа нэгтээ) үйл ажиллагаа сэргэсэн боловч үүнээс өмнө бараг XNUMX жил бүрэн тайван байсан. Үүнээс гадна төслийг боловсруулж байна , энэ нь шинэ функцуудыг нэвтрүүлэхэд ноцтой саад болж болзошгүй юм.
Нэхэмжлэл 2. Тооцооллын нарийвчлал. Брубек нэгтгэхийн тулд нийт 65536 утгыг цуглуулдаг. Манай тохиолдолд, зарим хэмжүүрүүдийн хувьд нэгтгэх хугацаанд (30 секунд) илүү их утгууд (оргил үедээ 1) ирж магадгүй юм. Энэхүү түүврийн үр дүнд хамгийн их ба хамгийн бага утга нь ашиггүй мэт харагдаж байна. Жишээлбэл, иймэрхүү:
Байсан шиг
Яаж байх ёстой байсан юм
Үүнтэй ижил шалтгаанаар дүнг ерөнхийдөө буруу тооцдог. Энд 32 битийн хөвөгч халилттай алдааг нэмж оруулаарай, энэ нь гэмгүй мэт санагдах хэмжигдэхүүнийг хүлээн авах үед серверийг segfault руу илгээдэг бөгөөд бүх зүйл сайхан болдог. Дашрамд хэлэхэд алдаа засаагүй байна.
Эцэст нь хэлэхэд, Нэхэмжлэлийн X. Бичиж байх үед бид үүнийг олж чадсан бүх 14 статистикийн хэрэгжүүлэлтэд танилцуулахад бэлэн байна. Зарим нэг дэд бүтэц маш их өссөн тул 4 сая MPS хүлээн авах нь хангалтгүй болсон гэж төсөөлөөд үз дээ. Эсвэл хараахан өсөөгүй байсан ч хэмжигдэхүүнүүд нь танд маш чухал тул график дахь 2-3 минутын богино бууралтууд аль хэдийн чухал болж, менежерүүдийн дунд даван туулах аргагүй сэтгэлийн хямралд хүргэж болзошгүй юм. Сэтгэлийн хямралыг эмчлэх нь талархалгүй ажил тул техникийн шийдэл хэрэгтэй.
Нэгдүгээрт, алдааг тэсвэрлэх чадвар, ингэснээр сервер дээрх гэнэтийн асуудал нь оффис дахь сэтгэцийн зомби апокалипсис үүсгэхгүй. Хоёрдугаарт, Линукс сүлжээний стекийг гүнзгийрүүлэхгүйгээр 4 сая гаруй MPS-ийг хүлээн авах боломжтой болгож, шаардлагатай хэмжээнд хүртэл "өргөн" тайвнаар өсөх болно.
Бидэнд томруулах зай байгаа тул алдааг тэсвэрлэх чадвараас эхлэхээр шийдсэн. "ТУХАЙ! Алдааг тэсвэрлэх чадвар! Энэ бол маш энгийн, бид үүнийг хийж чадна" гэж бид бодож, 2 сервер ажиллуулж, тус бүр дээр brubeck-ийн хуулбарыг суулгав. Үүнийг хийхийн тулд бид хоёр серверт хэмжигдэхүүн бүхий урсгалыг хуулж, тэр ч байтугай бичих шаардлагатай болсон . Бид үүгээр алдааг тэсвэрлэх асуудлыг шийдсэн, гэхдээ ... тийм ч сайн биш. Эхэндээ бүх зүйл сайхан санагдаж байв: брубек бүр өөрийн нэгтгэх хувилбарыг цуглуулж, 30 секунд тутамд нэг удаа Graphite руу өгөгдөл бичиж, хуучин интервалыг дарж бичдэг (энэ нь Графит тал дээр хийгддэг). Хэрэв нэг сервер гэнэт бүтэлгүйтвэл бид үргэлж нэгтгэсэн өгөгдлийн хуулбартай хоёр дахь сервертэй байдаг. Гэхдээ энд асуудал байна: хэрэв сервер амжилтгүй болвол график дээр "хөрөө" гарч ирнэ. Энэ нь Брюбекийн 30 секундын интервалууд синхрончлогдоогүй, осол гарах үед тэдгээрийн аль нэгийг нь дарж бичдэггүйтэй холбоотой юм. Хоёр дахь сервер эхлэхэд ижил зүйл тохиолддог. Тэвчих боломжтой, гэхдээ би илүү сайн байхыг хүсч байна! Өргөтгөх чадварын асуудал бас арилаагүй байна. Бүх хэмжүүрүүд нэг сервер рүү "нисдэг" хэвээр байгаа тул бид сүлжээний түвшнээс хамааран 2-4 сая MPS-ээр хязгаарлагддаг.
Хэрэв та асуудлын талаар бага зэрэг бодож, цасыг хүрзээр ухаж авбал дараахь тодорхой санаа гарч ирж магадгүй юм: танд хуваарилагдсан горимд ажиллах боломжтой статистик хэрэгтэй. Энэ нь зангилаа хоорондын синхрончлолыг цаг хугацаа болон хэмжүүрээр гүйцэтгэдэг. "Мэдээжийн хэрэг, ийм шийдэл аль хэдийн байгаа байх" гэж бид хэлээд Google рүү очив.... Тэгээд тэд юу ч олсонгүй. Өөр өөр статистикийн баримт бичгүүдийг шалгасны дараа ( 11.12.2017 оны XNUMX-р сарын XNUMX-ний байдлаар) бид юу ч олсонгүй. Эдгээр шийдлүүдийг хөгжүүлэгчид ч, хэрэглэгчид ч ийм олон хэмжүүртэй тулгараагүй байгаа бололтой, эс тэгвээс тэд ямар нэгэн зүйл гаргаж ирэх нь гарцаагүй.
Тэгээд бид зүгээр л хөгжилтэй хакатон дээр бичигдсэн "тоглоом" статсд - bioyino-ийн тухай санаж (төслийн нэрийг хакатон эхлэхээс өмнө скриптээр үүсгэсэн) бидэнд өөрийн гэсэн статистик яаралтай хэрэгтэй байгааг ойлгов. Юуны төлөө?
- Учир нь дэлхий дээр хэт цөөхөн статистик клон байдаг.
- Учир нь энэ нь хүссэн эсвэл хүссэн хэмжээндээ ойрхон алдааны хүлцэл, өргөтгөх чадварыг хангах боломжтой (үүнд серверүүдийн хооронд нэгтгэсэн хэмжигдэхүүнийг синхрончлох, зөрчил илгээх асуудлыг шийдвэрлэх)
- Учир нь хэмжигдэхүүнийг Брюбекээс илүү нарийвчлалтай тооцоолох боломжтой.
- Учир нь та Брюбек бидэнд бараг өгөөгүй илүү нарийвчилсан статистикийг өөрөө цуглуулж болно.
- Учир нь би өөр нэг ижил төстэй гиперфорын архитектурыг бүрэн давтахгүй өөрийн hyperperformance-ийн тархсан масштабын лабораторийн программыг програмчлах боломж олдсон юм.
Юун дээр бичих вэ? Мэдээжийн хэрэг, Rust-д. Яагаад?
- учир нь аль хэдийн прототип шийдэл байсан.
- Учир нь тухайн нийтлэлийн зохиогч Зэвийг тэр үед таньдаг байсан бөгөөд түүн дээр ямар нэгэн зүйл бичихийг эрмэлзэж, нээлттэй эх сурвалжид оруулах боломжтой байсан.
- Учир нь хүлээн авсан траффикийн шинж чанараас (бараг бодит цагийн) GC-тэй хэл нь бидэнд тохиромжгүй бөгөөд GC-ийн түр зогсолт нь бараг хүлээн зөвшөөрөгдөхгүй,
- Учир нь танд C-тэй харьцуулахад хамгийн их гүйцэтгэл хэрэгтэй
- Учир нь Rust нь бидэнд айдасгүй зэрэгцэн ажиллах боломжийг олгодог бөгөөд хэрэв бид үүнийг C/C++ хэл дээр бичиж эхэлбэл brubeck-ээс ч илүү эмзэг байдал, буферийн хэт ачаалал, уралдааны нөхцөл байдал болон бусад аймшигтай үгсийг арилгах байсан.
Мөн Зэвийн эсрэг маргаан гарсан. Тус компани нь Rust-д төсөл хэрэгжүүлэх туршлагагүй байсан бөгөөд одоо бид үүнийг үндсэн төсөлдөө ашиглахаар төлөвлөөгүй байна. Тиймээс юу ч бүтэхгүй гэсэн ноцтой айдас байсан ч бид азаа үзэхээр шийдэж, оролдсон.
Цаг хугацаа өнгөрсөн...
Эцэст нь хэд хэдэн амжилтгүй оролдлого хийсний дараа эхний ажлын хувилбар бэлэн болсон. Юу болсон бэ? Ийм зүйл болсон.
Зангилаа бүр өөрийн хэмжүүрийг хүлээн авч, тэдгээрийг хуримтлуулдаг бөгөөд эцсийн нэгтгэхэд бүрэн багц шаардлагатай эдгээр төрлүүдийн хэмжүүрүүдийг нэгтгэдэггүй. Зангилаанууд нь өөр хоорондоо ямар нэгэн хуваарилагдсан түгжээний протоколоор холбогддог бөгөөд энэ нь тэдгээрийн дотроос Агуу Нэгэнд хэмжигдэхүүн илгээх зохистой цорын ганцыг (бид уйлсан) сонгох боломжийг олгодог. Одоогоор энэ асуудлыг шийдэж байна , гэхдээ ирээдүйд зохиолчийн хүсэл тэмүүлэл хүрээгээ тэлж байна Хамгийн зохистой нь мэдээж зөвшилцлийн удирдагч зангилаа байх болно Сал. Зөвшилцөлөөс гадна зангилаанууд ихэвчлэн (анхдагчаар секундэд нэг удаа) тухайн секундэд цуглуулж чадсан урьдчилан нэгтгэсэн хэмжүүрийн хэсгүүдийг хөршүүд рүүгээ илгээдэг. Хуваарилалт болон алдааны хүлцэл хадгалагдсаар байна - зангилаа бүр хэмжүүрийн бүрэн багцыг агуулж байгаа боловч хэмжигдэхүүнүүдийг аль хэдийн нэгтгэн TCP-ээр илгээж, хоёртын протокол болгон кодлодог тул давхардлын зардал UDP-тэй харьцуулахад мэдэгдэхүйц багасдаг. Хэдий нэлээд олон тооны ирж буй хэмжигдэхүүнийг үл харгалзан хуримтлал нь маш бага санах ой, бүр бага CPU шаарддаг. Манай өндөр нягтаршлын хувьд энэ нь хэдхэн арван мегабайт өгөгдөл юм. Нэмэлт урамшууллын хувьд бид Бурбектэй адил Graphite дээр шаардлагагүй өгөгдлийг дахин бичихгүй.
Хэмжигдэхүүн бүхий UDP пакетууд нь энгийн Round Robin-ээр дамжуулан сүлжээний төхөөрөмж дээрх зангилааны хооронд тэнцвэргүй байдаг. Мэдээжийн хэрэг, сүлжээний техник хангамж нь пакетуудын агуулгыг задалдаггүй тул секундэд 4 сая гаруй пакет татах боломжтой бөгөөд энэ нь юу ч мэдэхгүй хэмжигдэхүүнийг дурдахгүй. Хэрэв бид багц бүрт хэмжигдэхүүнүүд нэг нэгээр ирдэггүй гэдгийг харгалзан үзвэл энэ газарт гүйцэтгэлийн асуудал гарахгүй. Хэрэв сервер эвдэрсэн бол сүлжээний төхөөрөмж хурдан (1-2 секундын дотор) энэ баримтыг илрүүлж, эвдэрсэн серверийг эргүүлэхээс зайлуулдаг. Үүний үр дүнд идэвхгүй (жишээ нь, удирдагч бус) зангилаануудыг диаграмм дахь бууралтыг анзааралгүйгээр бараг асааж, унтрааж болно. Бидний алдах дээд хэмжээ нь сүүлийн секундэд орж ирсэн хэмжүүрүүдийн нэг хэсэг юм. Удирдагчийг гэнэт алдах/унтраах/шилжүүлэх нь бага зэргийн гажиг үүсгэсэн хэвээр байх болно (30 секундын интервал нь синхрончлолгүй хэвээр байна), гэхдээ хэрэв зангилаа хоорондын харилцаа холбоо байгаа бол жишээлбэл, синхрончлолын пакетуудыг илгээх замаар эдгээр асуудлыг багасгаж болно. .
Дотоод бүтцийн талаар бага зэрэг. Уг програм нь мэдээжийн хэрэг олон урсгалтай боловч threading архитектур нь brubeck-д хэрэглэгддэгээс өөр юм. Brubeck-ийн утаснууд нь адилхан - тус бүр нь мэдээлэл цуглуулах, нэгтгэх үүрэгтэй. Bioyino-д ажилчдыг сүлжээг хариуцах, нэгтгэх үүрэгтэй гэсэн хоёр бүлэгт хуваадаг. Энэ хэлтэс нь хэмжүүрийн төрлөөс хамааран програмыг илүү уян хатан удирдах боломжийг олгодог: эрчимтэй нэгтгэх шаардлагатай бол нэгтгэгчийг нэмж, сүлжээний ачаалал ихтэй бол сүлжээний урсгалын тоог нэмж болно. Одоогоор манай серверүүд дээр бид 8 сүлжээ, 4 нэгтгэх урсгалаар ажиллаж байна.
Тоолох (нэгтгэх үүрэгтэй) хэсэг нь нэлээд уйтгартай. Сүлжээний урсгалаар дүүргэсэн буферууд нь тоолох урсгалуудын дунд хуваарилагдаж, дараа нь задлан шинжилж, нэгтгэгддэг. Хүсэлтийн дагуу бусад зангилаа руу илгээх хэмжүүрүүдийг өгдөг. Зангилааны хооронд өгөгдөл илгээх, консултай ажиллах зэрэг энэ бүхэн асинхрон байдлаар, хүрээ дээр ажилладаг. .
Хөгжүүлэлтийн явцад илүү олон асуудал нь хэмжигдэхүүнийг хүлээн авах үүрэгтэй сүлжээний хэсгээс үүдэлтэй байв. Сүлжээний урсгалыг салангид нэгж болгон хуваах гол зорилго нь урсгалын зарцуулдаг цагийг багасгах хүсэл байв. үгүй залгуураас өгөгдлийг унших. Асинхрон UDP болон ердийн recvmsg ашигладаг сонголтууд хурдан алга болсон: эхнийх нь үйл явдлыг боловсруулахад хэт их хэрэглэгчийн орон зайн CPU зарцуулдаг, хоёр дахь нь хэт олон контекст шилжүүлэгч шаарддаг. Тиймээс үүнийг одоо ашиглаж байна том буфертэй (мөн буферууд, эрхэм офицерууд, танд юу ч биш!). Тогтмол UDP-ийн дэмжлэг нь recvmmsg шаардлагагүй хөнгөн тохиолдлуудад зориулагдсан. Мультимессежийн горимд та гол зүйлд хүрэх боломжтой: ихэнх тохиолдолд сүлжээний утас нь үйлдлийн системийн дарааллыг татдаг - залгуураас өгөгдлийг уншиж, хэрэглэгчийн зайны буфер руу шилжүүлдэг, зөвхөн хааяа дүүргэсэн буфер руу шилждэг. агрегаторууд. Сокет дахь дараалал бараг хуримтлагддаггүй, унасан пакетуудын тоо бараг өсдөггүй.
тайлбар
Анхдагч тохиргоонд буферийн хэмжээг нэлээд том байхаар тохируулсан. Хэрэв та гэнэт серверээ өөрөө туршиж үзэхээр шийдсэн бол цөөн тооны хэмжүүр илгээсний дараа тэдгээр нь сүлжээний урсгалын буферт үлдэх Graphite-д ирэхгүй гэсэн баримттай тулгарч магадгүй юм. Цөөн тооны хэмжигдэхүүнтэй ажиллахын тулд тохиргоонд bufsize болон task-queue-size-ийг бага утгаар тохируулах хэрэгтэй.
Эцэст нь, график сонирхогчдод зориулсан зарим графикууд.
Сервер бүрийн ирж буй хэмжүүрүүдийн тоон статистик: 2 сая гаруй MPS.
Зангилааны аль нэгийг идэвхгүй болгож, ирж буй хэмжигдэхүүнийг дахин хуваарилах.
Гарч буй хэмжүүрүүдийн статистик: зөвхөн нэг зангилаа үргэлж илгээдэг - raid boss.
Төрөл бүрийн системийн модулиудын алдааг харгалзан зангилаа бүрийн үйл ажиллагааны статистик.
Ирж буй хэмжүүрүүдийн дэлгэрэнгүй мэдээлэл (хэмжийн нэрийг нуусан).
Энэ бүхнийг бид цаашид юу хийхээр төлөвлөж байна вэ? Мэдээж код бичээрэй, хараал ид...! Төслийг анх нээлттэй эх сурвалжтай байхаар төлөвлөж байсан бөгөөд амьдралынхаа туршид хэвээр байх болно. Бидний ойрын төлөвлөгөөнд Raft-ын өөрийн хувилбарт шилжих, үе тэнгийн протоколыг илүү зөөврийн протокол болгон өөрчлөх, нэмэлт дотоод статистик, шинэ төрлийн хэмжигдэхүүн, алдаа засах болон бусад сайжруулалтууд багтана.
Мэдээжийн хэрэг, хүн бүр төслийг боловсруулахад туслахыг урьж байна: PR бий болгох, Асуудал гаргах, боломжтой бол бид хариу өгөх, сайжруулах гэх мэт.
Үүнийг хэлэхэд бүх хүмүүс, манай заануудыг худалдаж аваарай!
Эх сурвалж: www.habr.com