Биоиино - дистрибуирани, скалабилни агрегатор метрика

Дакле, прикупљате метрику. Као што јесмо. Такође прикупљамо метрику. Наравно, неопходно за пословање. Данас ћемо говорити о првој вези нашег система за праћење - серверу за агрегацију који је компатибилан са статсд биоиино, зашто смо то написали и зашто смо напустили Брубецк.

Из наших претходних чланака (1, 2) можете сазнати да смо до неког времена прикупљали оцене користећи брубецк. Написан је у Ц. Са тачке гледишта кода, једноставан је као прикључак (ово је важно када желите да допринесете) и, што је најважније, обрађује наше количине од 2 милиона метрика у секунди (МПС) на врхунцу без икаквих проблема. У документацији је наведена подршка за 4 милиона МПС са звездицом. То значи да ћете добити наведену цифру ако исправно конфигуришете мрежу на Линук-у. (Не знамо колико МПС-а можете добити ако оставите мрежу каква јесте). Упркос овим предностима, имали смо неколико озбиљних притужби на Брубецк.

Тврдња 1. Гитхуб, програмер пројекта, престао је да га подржава: објављује закрпе и исправке, прихватајући наш и (не само наш) ПР. Последњих неколико месеци (негде од фебруара-марта 2018.) активност је настављена, али је пре тога било скоро 2 године потпуног затишја. Поред тога, пројекат се развија за унутрашње Гихубове потребе, што може постати озбиљна препрека за увођење нових функција.

Тврдња 2. Тачност прорачуна. Брубецк прикупља укупно 65536 вредности за агрегацију. У нашем случају, за неке метрике, током периода агрегације (30 секунди), може доћи много више вредности (1 на врхунцу). Као резултат овог узорковања, максималне и минималне вредности су бескорисне. На пример, овако:

Као што је био

Како је требало да буде

Из истог разлога, износи се углавном погрешно израчунавају. Додајте овде грешку са 32-битним флоат оверфловом, који генерално шаље сервер на сегфаулт када прими наизглед невину метрику, и све постаје одлично. Грешка, иначе, није отклоњена.

И, коначно, Захтев Кс. У време писања, спремни смо да га представимо за свих 14 више или мање радних статсд имплементација које смо успели да пронађемо. Замислимо да је нека појединачна инфраструктура толико нарасла да прихватање 4 милиона МПС више није довољно. Или чак и ако још није порастао, али су вам метрике већ толико важне да чак и кратки, 2-3 минута падови на графиконима већ могу постати критични и изазвати нападе непремостиве депресије међу менаџерима. Пошто је лечење депресије незахвалан задатак, потребна су техничка решења.

Прво, толеранција грешака, тако да изненадни проблем на серверу не изазове психијатријску зомби апокалипсу у канцеларији. Друго, скалирање да бисте могли да прихватите више од 4 милиона МПС, без копања дубоко у Линук мрежни стог и мирног раста „у ширину“ до потребне величине.

Пошто смо имали простора за скалирање, одлучили смо да почнемо са толеранцијом грешака. "О ТОМЕ! Толеранција грешака! Једноставно је, можемо то да урадимо“, помислили смо и покренули 2 сервера, подижући копију брубецк-а на сваком. Да бисмо то урадили, морали смо да копирамо саобраћај са метриком на оба сервера, па чак и да пишемо за ово мала корисност. Решили смо проблем толеранције грешака са овим, али... не баш добро. У почетку је све изгледало сјајно: сваки брубек прикупља своју верзију агрегације, уписује податке у Грапхите сваких 30 секунди, замењујући стари интервал (ово се ради на страни графита). Ако један сервер изненада поквари, увек имамо други са сопственом копијом агрегираних података. Али ево проблема: ако сервер не успе, на графиконима се појављује „тела“. То је због чињенице да Брубецкови интервали од 30 секунди нису синхронизовани, а у тренутку пада један од њих није преписан. Када се покрене други сервер, дешава се иста ствар. Сасвим подношљиво, али желим боље! Проблем скалабилности такође није нестао. Све метрике и даље „лете“ на један сервер, па смо стога ограничени на истих 2-4 милиона МПС, у зависности од нивоа мреже.

Ако мало размислите о проблему и истовремено копате снег лопатом, онда вам може пасти на памет следећа очигледна идеја: потребан вам је статсд који може да ради у дистрибуираном режиму. То јест, онај који имплементира синхронизацију између чворова у времену и метрици. „Наравно, такво решење вероватно већ постоји“, рекли смо и отишли ​​у Гугл…. И нису нашли ништа. Након што прођете кроз документацију за различите статсд (https://github.com/etsy/statsd/wiki#server-implementations од 11.12.2017. децембра XNUMX. године) нисмо нашли апсолутно ништа. Очигледно, ни програмери ни корисници ових решења још нису наишли на ТОЛИКО метрика, иначе би сигурно нешто смислили.

А онда смо се сетили „играчке“ статсд - биоиино, која је написана на хакатону Јуст фор Фун (назив пројекта је генерисан скриптом пре почетка хакатона) и схватили да нам је хитно потребан сопствени статсд. За шта?

• јер има премало статсд клонова на свету,
• јер је могуће обезбедити жељену или близу жељене толеранције грешака и скалабилност (укључујући синхронизацију агрегираних метрика између сервера и решавање проблема слања конфликата),
• јер је могуће прецизније израчунати метрику него што то ради Брубецк,
• јер сами можете прикупити детаљнију статистику, коју нам Брубецк практично није дао,
• јер сам имао прилику да програмирам сопствену лабораторијску апликацију дистрибуиране скале хиперперформансе, која неће у потпуности поновити архитектуру другог сличног хиперфор... па, то је то.

На чему писати? Наравно, у Русту. Зашто?

• јер је већ постојало решење прототипа,
• јер је аутор чланка већ у то време познавао Руст и био је нестрпљив да напише нешто у њему за производњу са могућношћу да га стави у опен-соурце,
• јер језици са ГЦ-ом нису погодни за нас због природе примљеног саобраћаја (скоро у реалном времену) и ГЦ паузе су практично неприхватљиве,
• јер су вам потребне максималне перформансе упоредиве са Ц
• јер нам Руст пружа неустрашиву конкурентност, и да смо почели да га пишемо у Ц/Ц++, имали бисмо још више рањивости, преливања бафера, услова трке и других страшних речи од брубецк-а.

Било је и аргумента против Руста. Компанија није имала искуства у креирању пројеката у Русту, а сада такође не планирамо да га користимо у главном пројекту. Због тога је постојала озбиљна бојазан да ништа неће успети, али смо одлучили да ризикујемо и покушали.

Време је пролазило...

Коначно, након неколико неуспелих покушаја, прва радна верзија је била готова. Шта се десило? Ево шта се десило.

Сваки чвор прима сопствени скуп метрика и акумулира их, а не агрегира метрике за оне типове где је њихов пун скуп потребан за коначно агрегирање. Чворови су међусобно повезани неком врстом дистрибуираног протокола закључавања, који вам омогућава да међу њима изаберете једини (овде смо плакали) који је достојан слања метрике Великом. Овај проблем се тренутно решава од Цонсул, али се у будућности амбиције аутора протежу на свој имплементација Сплав, где ће највреднији, наравно, бити водећи чвор консензуса. Поред консензуса, чворови прилично често (подразумевано једном у секунди) својим суседима шаљу оне делове унапред агрегираних метрика које су успели да прикупе у тој секунди. Испоставило се да су скалирање и толеранција грешака очувани – сваки чвор и даље има пун скуп метрика, али се метрике шаљу већ агрегиране, преко ТЦП-а и кодиране у бинарни протокол, тако да су трошкови дуплирања значајно смањени у поређењу са УДП-ом. Упркос прилично великом броју долазних метрика, акумулација захтева врло мало меморије и још мање ЦПУ-а. За наше високо компресибилне мертике, ово је само неколико десетина мегабајта података. Као додатни бонус, не добијамо непотребно преписивање података у Грапхите, као што је био случај са бурбецк-ом.

УДП пакети са метриком су неуравнотежени између чворова на мрежној опреми кроз једноставан Роунд Робин. Наравно, мрежни хардвер не анализира садржај пакета и стога може повући много више од 4М пакета у секунди, а да не помињемо метрике о којима не зна ништа. Ако узмемо у обзир да метрика не долази један по један у сваком пакету, онда не предвиђамо проблеме у перформансама на овом месту. Ако се сервер сруши, мрежни уређај брзо (у року од 1-2 секунде) детектује ову чињеницу и уклања сервер који се срушио из ротације. Као резултат тога, пасивни (тј. не-лидерски) чворови се могу укључити и искључити практично без уочавања падања на графиконима. Максимум који губимо део је метрике која је дошла у последњој секунди. Изненадни губитак/гашење/пребацивање лидера ће и даље створити мању аномалију (интервал од 30 секунди је још увек несинхронизован), али ако постоји комуникација између чворова, ови проблеми се могу минимизирати, на пример, слањем пакета за синхронизацију .

Мало о унутрашњој структури. Апликација је, наравно, вишенитна, али архитектура навоја се разликује од оне која се користи у Брубецк-у. Нити у брубек-у су исти - сваки од њих је одговоран и за прикупљање и агрегацију информација. У биоиину радници су подељени у две групе: они који су одговорни за мрежу и они који су одговорни за агрегацију. Ова подела вам омогућава да флексибилније управљате апликацијом у зависности од типа метрике: тамо где је потребна интензивна агрегација, можете додати агрегаторе, где има много мрежног саобраћаја, можете додати број мрежних токова. Тренутно на нашим серверима радимо у 8 мрежних и 4 тока агрегације.

Део бројања (одговоран за агрегацију) је прилично досадан. Бафери испуњени мрежним токовима се дистрибуирају међу токовима за бројање, где се накнадно рашчлањују и агрегирају. На захтев, метрике се дају за слање другим чворовима. Све ово, укључујући слање података између чворова и рад са Цонсулом, се обавља асинхроно, ради на оквиру Токио.

Много више проблема током развоја проузроковао је део мреже одговоран за пријем метрике. Главни циљ раздвајања мрежних токова у засебне целине била је жеља да се смањи време које ток троши не за читање података из утичнице. Опције које користе асинхрони УДП и регуларни рецвмсг брзо су нестале: прва троши превише ЦПУ-а корисничког простора за обраду догађаја, друга захтева превише пребацивања контекста. Стога се сада користи рецвммсг са великим тампонима (а одбојници, господо официри, нису вам ништа!). Подршка за обичан УДП је резервисана за лаке случајеве где рецвммсг није потребан. У режиму више порука, могуће је постићи главну ствар: огромну већину времена, мрежна нит хвата ред за ОС - чита податке са сокета и преноси их у бафер корисничког простора, само повремено прелази на давање попуњеног бафера у агрегатори. Ред у утичници се практично не акумулира, број испуштених пакета практично не расте.

Приметити

У подразумеваним подешавањима, величина бафера је подешена да буде прилично велика. Ако изненада одлучите да сами испробате сервер, можда ћете наићи на чињеницу да након слања малог броја метрика неће стићи у Грапхите, остајући у баферу мрежног тока. Да бисте радили са малим бројем метрика, потребно је да подесите буфсизе и таск-куеуе-сизе на мање вредности у конфигурацији.

Коначно, неке карте за љубитеље графикона.

Статистика о броју долазних метрика за сваки сервер: више од 2 милиона МПС.

Онемогућавање једног од чворова и прерасподела долазних метрика.

Статистика о излазним метрикама: увек шаље само један чвор - шеф рације.

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

Детаљи долазних метрика (називи метрика су сакривени).

Шта планирамо са свим овим даље? Наравно, напиши код, проклетство...! Првобитно је планирано да пројекат буде отвореног кода и тако ће остати током свог животног века. Наши непосредни планови укључују прелазак на сопствену верзију Рафт-а, промену равноправног протокола на преносивији, увођење додатне интерне статистике, нових типова метрика, исправке грешака и друга побољшања.

Наравно, сви су добродошли да помогну у развоју пројекта: креирајте ПР, проблеме, ако је могуће одговорићемо, побољшати итд.

Уз то, то је све људи, купите наше слонове!

Извор: ввв.хабр.цом