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

И така, събирате метрики. Както и ние. Ние също събираме метрики. Разбира се, важни за бизнеса. Днес ще ви разкажем за първото звено на нашата мониторинг система — сървър за агрегация, съвместим с statsd. bioyino, защо го написахме и защо се отказахме от brubeck.

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

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

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

Както беше

Как debería да бъде

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

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

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

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

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

И тогава си спомнихме за "играчката" statsd — bioyino, която писахме на хакатон просто за забавление (името на проекта бе генерирано от скрипт в началото на хакатона) и разбрахме, че спешно ни е нужен собствен statsd. Защо?

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

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

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

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

Времето минава...

Накрая, след няколко неуспешни опита, първата работеща версия беше готова. Какво постигнахме? Постижението е такова.

Всяка нода получава своя собствен набор от метрики и ги съхранява при себе си, като не агрегира метриките за типове, при които за финалната агрегация е необходим целият им набор. Нодите са свързани помежду си чрез някакъв протокол на разпределено заключване (distributed lock), който позволява да се избере измежду тях онази единствена (тук плачем), която е достойна да изпраща метриките на Великия. В момента този проблем се решава чрез Consul, но в бъдеще амбициите на автора се простират до собствена реализация Raft, където онази достойна ще бъде, разбира се, нода-лидер на консенсуса. Освен консенсуса, нодите доста често (по подразбиране веднъж в секунда) изпращат на своите съседи частите от предагрегирани метрики, които са успели да съберат за тази секунда. Получава се, че мащабирането и отказоустойчивостта се запазват — всяка от нодите все още държи при себе си пълен набор от метрики, но метриките вече се изпращат агрегирани, по TCP и с кодиране в бинарен протокол, затова разходите за дублиране в сравнение с UDP значително намаляват. Въпреки доста голямото количество входящи метрики, натрупването изисква много малко памет и още по-малко CPU. За нашите добре компресируеми метрики това е само няколко десетки мегабайта данни. Допълнителен бонус е отсъствието на ненужни презаписи на данни в Graphite, както беше в случая с burbeck.

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

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

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

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

Забележка

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

Накрая — малко графики за любителите на графиките.

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

Изключване на един от възлите и преразпределение на входящите метрики.

Статистика за изходящите метрики: винаги само един възел изпраща — рейдбосът.

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

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

Какво планираме да правим с всичко това занапред? Разбира се, ще пишем код, бл…! Проектът първоначално бе планиран като open-source и ще остане такъв през целия си живот. В близките планове — преход към собствена версия на Raft, смяна на peer-протокола с по-преносим, добавяне на допълнителна вътрешна статистика, нови типове метрики, поправяне на грешки и други подобрения.

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

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

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