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 в пика). В резултат на такова семплиране, стойностите на максимумите и минимумите изглеждат безполезни. Например, така:

Как беше

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

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

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

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

Тъй като по отношение на скалируемостта имаме запас, решихме да започнем с отказоустойчивостта. 'О! Отказоустойчивост! Това е лесно, това можем', помислихме и стартирахме 2 сървъра, създавайки на всеки копие на brubeck. За целта трябваше да копираме трафика с метриките на двата сървъра и дори да напишем за това малка утилита. Разрешихме проблема с отказоустойчивостта, но... не много добре. Първоначално всичко изглеждаше страхотно: всеки 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 практически не ни предоставяше,
• защото получихме шанс да програмираме свое собствено хайперформанс дистрибутирано приложение, което няма да повтори напълно архитектурата на друго такова хайперформанс...

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

• защото вече имаше прототип на решението,
• защото авторът на статията по това време вече знаеше Rust и искаше да напише нещо с него за продукция с възможност да го публикува в open-source,
• защото езици с GC не ни подхождат поради природата на получавания трафик (практически в реално време) и паузите на GC са практически недопустими,
• защото е необходима максимална производителност, сравнима с C
• защото Rust ни предоставя безстрашна конкурентност, а ако бяхме започнали да пишем това на 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 не е необходим. В режим на множество съобщения се постига основното: преобладаващото време мрежовият поток обработва опашката на ОС - извлича данни от сокета и ги прехвърля в user-space буфера, само от време на време превключвайки, за да предаде запълнения буфер на агрегаторите. Опашката в сокета практически не нараства, количеството на отхвърлените пакети почти не се увеличава.

Забележка

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

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

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

Отключване на една от нодовете и пренасочване на входящите метрики.

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

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

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

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

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

С това, както се казва, that’s all folks, купувайте нашите слонове!

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