Bioyino - разпределен, мащабируем агрегатор на показатели

Така че събирате показатели. Такива, каквито сме. Също така събираме показатели. Разбира се, необходими за бизнеса. Днес ще говорим за първата връзка на нашата система за мониторинг - съвместим със statsd сървър за агрегиране биойино, защо го написахме и защо изоставихме brubeck.

От предишните ни статии (1, 2) можете да разберете, че до известно време сме събирали оценки с помощта на Брубек. Написан е на C. От гледна точка на кода, той е толкова прост, колкото щепсел (това е важно, когато искате да допринесете) и най-важното е, че обработва нашите обеми от 2 милиона метрики в секунда (MPS) при пик без никакви проблеми. В документацията се посочва поддръжка за 4 милиона MPS със звездичка. Това означава, че ще получите посочената цифра, ако конфигурирате мрежата правилно на Linux. (Не знаем колко MPS можете да получите, ако оставите мрежата такава, каквато е). Въпреки тези предимства, имахме няколко сериозни оплаквания от brubeck.

Претенция 1. Github, разработчикът на проекта, спря да го поддържа: публикува пачове и корекции, приема нашия и (не само нашия) PR. През последните няколко месеца (някъде от февруари-март 2018 г.) дейността се възобнови, но преди това имаше почти 2 години пълно затишие. Освен това проектът се разработва за вътрешни нужди на Gihub, което може да се превърне в сериозна пречка за въвеждането на нови функции.

Претенция 2. Точност на изчисленията. Brubeck събира общо 65536 30 стойности за агрегиране. В нашия случай, за някои показатели, по време на периода на агрегиране (1 секунди), може да пристигнат много повече стойности (527 392 XNUMX в пика). В резултат на това вземане на проби максималните и минималните стойности изглеждат безполезни. Например така:

Както си беше

Как трябваше да бъде

По същата причина сумите обикновено се изчисляват неправилно. Добавете тук бъг с 32-битово плаващо преливане, което обикновено изпраща сървъра на segfault при получаване на привидно невинна метрика и всичко става страхотно. Грешката, между другото, не е коригирана.

И, накрая, Претенция X. Към момента на писане сме готови да го представим на всички 14 повече или по-малко работещи реализации на statsd, които успяхме да намерим. Нека си представим, че една отделна инфраструктура е нараснала толкова много, че приемането на 4 милиона MPS вече не е достатъчно. Или дори ако все още не е нараснал, но показателите вече са толкова важни за вас, че дори кратки, 2-3 минутни спадове в класациите вече могат да станат критични и да причинят пристъпи на непреодолима депресия сред мениджърите. Тъй като лечението на депресия е неблагодарна задача, необходими са технически решения.

Първо, толерантност към грешки, така че внезапен проблем на сървъра да не предизвика психиатричен зомби апокалипсис в офиса. Второ, мащабиране, за да можете да приемате повече от 4 милиона MPS, без да ровите дълбоко в мрежовия стек на Linux и спокойно да растете „на ширина“ до необходимия размер.

Тъй като имахме място за мащабиране, решихме да започнем с толерантност към грешки. "ОТНОСНО! Толерантност към грешки! Просто е, можем да го направим“, помислихме си и стартирахме 2 сървъра, като на всеки издигнахме копие на brubeck. За да направим това, трябваше да копираме трафик с показатели на двата сървъра и дори да пишем за това малка полезност. С това решихме проблема с толерантността към грешки, но... не много добре. Отначало всичко изглеждаше страхотно: всеки brubeck събира своя собствена версия на агрегация, записва данни в Graphite веднъж на всеки 30 секунди, презаписвайки стария интервал (това се прави от страна на Graphite). Ако един сървър внезапно се повреди, винаги имаме втори със собствено копие на обобщените данни. Но тук е проблемът: ако сървърът се повреди, на графиките се появява „трион“. Това се дължи на факта, че 30-секундните интервали на brubeck не са синхронизирани и в момента на срив един от тях не се презаписва. При стартиране на втория сървър се случва същото. Доста поносимо, но искам по-добро! Проблемът с мащабируемостта също не е изчезнал. Всички показатели все още „летят“ към един сървър и следователно сме ограничени до същите 2-4 милиона MPS, в зависимост от нивото на мрежата.

Ако помислите малко за проблема и в същото време копаете сняг с лопата, може да ви хрумне следната очевидна идея: имате нужда от statsd, който може да работи в разпределен режим. Тоест такъв, който реализира синхронизация между възлите във времето и показателите. „Разбира се, такова решение вероятно вече съществува“, казахме ние и отидохме в Google…. И не намериха нищо. След като прегледате документацията за различни statsd (https://github.com/etsy/statsd/wiki#server-implementations към 11.12.2017 декември XNUMX г.), не открихме абсолютно нищо. Очевидно нито разработчиците, нито потребителите на тези решения все още не са се сблъскали с ТОЛКОВА много показатели, в противен случай определено биха измислили нещо.

И тогава си спомнихме за „играчката“ statsd - bioyino, която беше написана на хакатона Just for Fun (името на проекта беше генерирано от скрипта преди началото на хакатона) и разбрахме, че спешно се нуждаем от собствена statsd. За какво?

• защото има твърде малко клонинги на statsd в света,
• тъй като е възможно да се осигури желаната или близка до желаната устойчивост на грешки и мащабируемост (включително синхронизиране на агрегирани показатели между сървъри и решаване на проблема с изпращането на конфликти),
• тъй като е възможно да се изчислят показателите по-точно, отколкото Brubeck прави,
• тъй като можете сами да съберете по-подробна статистика, която brubeck на практика не ни предостави,
• тъй като имах възможност да програмирам моя собствена хиперпроизводителна distributedscalelabplication, която няма да повтори напълно архитектурата на друга подобна хиперза... добре, това е.

На какво да пиша? Разбира се, в Rust. Защо?

• защото вече имаше прототипно решение,
• тъй като авторът на статията вече познаваше Rust по това време и нямаше търпение да напише нещо в нея за производство с възможност да го постави в отворен код,
• защото езиците с GC не са подходящи за нас поради естеството на получения трафик (почти в реално време) и GC паузите са практически неприемливи,
• защото имате нужда от максимална производителност, сравнима с C
• защото Rust ни осигурява безстрашна паралелност и ако започнем да го пишем на C/C++, щяхме да натрупаме още повече уязвимости, препълване на буфери, условия на състезание и други страшни думи от brubeck.

Имаше и аргумент срещу Rust. Компанията нямаше опит в създаването на проекти в Rust и сега също не планираме да го използваме в основния проект. Затова имаше сериозни страхове, че нищо няма да се получи, но решихме да рискуваме и опитахме.

Мина време...

Най-накрая, след няколко неуспешни опита, първата работеща версия беше готова. Какво стана? Ето какво се случи.

Всеки възел получава свой собствен набор от показатели и ги акумулира и не агрегира показатели за тези типове, където техният пълен набор е необходим за окончателното агрегиране. Възлите са свързани помежду си чрез някакъв вид протокол за разпределено заключване, който ви позволява да изберете сред тях единствения (тук плакахме), който е достоен да изпраща метрики на Великия. Този проблем в момента се разрешава от консул, но в бъдеще амбициите на автора се простират до собствен изпълнение Сал, където най-достойният, разбира се, ще бъде лидерът на консенсуса. В допълнение към консенсуса, възлите доста често (веднъж в секунда по подразбиране) изпращат на своите съседи онези части от предварително агрегирани показатели, които са успели да съберат за тази секунда. Оказва се, че мащабирането и толерантността към грешки се запазват - всеки възел все още съдържа пълен набор от показатели, но показателите се изпращат вече агрегирани, чрез TCP и кодирани в двоичен протокол, така че разходите за дублиране са значително намалени в сравнение с UDP. Въпреки доста големия брой входящи показатели, натрупването изисква много малко памет и още по-малко CPU. За нашите силно компресируеми показатели това са само няколко десетки мегабайта данни. Като допълнителен бонус не получаваме ненужни презаписи на данни в Graphite, какъвто беше случаят с Burbeck.

UDP пакетите с показатели са небалансирани между възлите на мрежовото оборудване чрез обикновен Round Robin. Разбира се, мрежовият хардуер не анализира съдържанието на пакетите и следователно може да изтегли много повече от 4 милиона пакета в секунда, да не говорим за показатели, за които не знае нищо. Ако вземем предвид, че показателите не идват един по един във всеки пакет, тогава не предвиждаме никакви проблеми с производителността на това място. Ако сървър се срине, мрежовото устройство бързо (в рамките на 1-2 секунди) открива този факт и премахва сринатия сървър от ротация. В резултат на това пасивните (т.е. нелидерни) възли могат да се включват и изключват практически без да се забелязват усвоявания на графиките. Максимумът, който губим, е част от показателите, които са влезли в последната секунда. Внезапна загуба/изключване/превключване на лидер все още ще създаде малка аномалия (интервалът от 30 секунди все още не е синхронизиран), но ако има комуникация между възлите, тези проблеми могат да бъдат сведени до минимум, например чрез изпращане на пакети за синхронизиране .

Малко за вътрешната структура. Приложението, разбира се, е многонишково, но архитектурата на нишките е различна от тази, използвана в brubeck. Нишките в brubeck са едни и същи - всяка от тях отговаря както за събирането, така и за агрегирането на информация. В bioyino работниците са разделени на две групи: тези, които отговарят за мрежата, и тези, които отговарят за агрегацията. Това разделение ви позволява по-гъвкаво да управлявате приложението в зависимост от вида на показателите: където се изисква интензивно агрегиране, можете да добавите агрегатори, където има много мрежов трафик, можете да добавите броя на мрежовите потоци. В момента на нашите сървъри работим в 8 мрежови и 4 агрегационни потока.

Броенето (отговорно за агрегацията) е доста скучно. Буферите, запълнени от мрежови потоци, се разпределят между преброяващите потоци, където впоследствие се анализират и агрегират. При поискване се дават метрики за изпращане до други възли. Всичко това, включително изпращане на данни между възли и работа с Consul, се извършва асинхронно, работейки върху рамката Токио.

Много повече проблеми по време на разработката бяха причинени от мрежовата част, отговорна за получаването на показатели. Основната цел на разделянето на мрежовите потоци на отделни обекти беше желанието да се намали времето, което потокът прекарва не за четене на данни от сокета. Опциите, използващи асинхронен UDP и обикновен recvmsg, бързо изчезнаха: първият консумира твърде много потребителско пространство на процесора за обработка на събития, вторият изисква твърде много контекстни превключватели. Затова сега се използва recvmmsg с големи буфери (а буферите, господа офицери, са нищо за вас!). Поддръжката за обикновен UDP е запазена за леки случаи, когато recvmmsg не е необходим. В режим на много съобщения е възможно да се постигне най-важното: през по-голямата част от времето мрежовата нишка изравнява опашката на ОС - чете данни от сокета и ги прехвърля в буфера на потребителското пространство, като само от време на време превключва към предоставяне на запълнения буфер на агрегатори. Опашката в гнездото практически не се натрупва, броят на изпуснатите пакети практически не расте.

Внимание

В настройките по подразбиране размерът на буфера е зададен да бъде доста голям. Ако изведнъж решите сами да опитате сървъра, може да се сблъскате с факта, че след изпращане на малък брой показатели, те няма да пристигнат в Graphite, оставайки в буфера на мрежовия поток. За да работите с малък брой показатели, трябва да зададете bufsize и task-queue-size на по-малки стойности в конфигурацията.

И накрая, няколко класации за любителите на класациите.

Статистика за броя на входящите показатели за всеки сървър: повече от 2 милиона MPS.

Деактивиране на един от възлите и преразпределяне на входящите показатели.

Статистика за изходящите показатели: само един възел винаги изпраща - шефът на нападението.

Статистика на работата на всеки възел, като се вземат предвид грешките в различни системни модули.

Детайлизиране на входящите показатели (имената на показателите са скрити).

Какво планираме да правим с всичко това? Разбира се, пишете код, по дяволите...! Първоначално проектът беше планиран да бъде с отворен код и ще остане такъв през целия си живот. Нашите непосредствени планове включват преминаване към нашата собствена версия на Raft, промяна на peer протокола към по-преносим, ​​въвеждане на допълнителна вътрешна статистика, нови типове показатели, корекции на грешки и други подобрения.

Разбира се, всеки е добре дошъл да помогне в развитието на проекта: създаване на PR, проблеми, ако е възможно, ще отговорим, подобрим и т.н.

С това казано, това е всичко, хора, купете нашите слонове!

Източник: www.habr.com