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

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

Од нашите претходни написи (1, 2) можете да дознаете дека до одредено време собиравме оценки користејќи Брубек. Напишано е во C. Од гледна точка на кодот, тој е едноставен како приклучок (ова е важно кога сакате да придонесете) и што е најважно, се справува со нашите волумени од 2 милиони метрика во секунда (MPS) на врвот без никакви проблеми. Во документацијата стои поддршка за 4 милиони MPS со ѕвездичка. Ова значи дека ќе ја добиете наведената бројка ако правилно ја конфигурирате мрежата на Linux. (Не знаеме колку MPS може да добиете ако ја напуштите мрежата како што е). И покрај овие предности, имавме неколку сериозни поплаки за брубек.

Барање 1. Github, развивачот на проектот, престана да го поддржува: објавување закрпи и поправки, прифаќање на нашиот и (не само наш) ПР. Во последните неколку месеци (некаде од февруари-март 2018) активноста е обновена, но пред тоа имаше речиси 2 години целосна смиреност. Дополнително, проектот се развива за внатрешни потреби на Gihub, што може да стане сериозна пречка за воведување нови функции.

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

Како што беше

Како требаше да биде

Од истата причина, износите генерално се пресметуваат погрешно. Додајте тука грешка со 32-битен float overflow, што генерално го испраќа серверот на segfault кога добива навидум невина метрика и сè станува одлично. Патем, грешката не е поправена.

И, конечно, Барање X. Во моментот на пишување, ние сме подготвени да го претставиме на сите 14 повеќе или помалку работни имплементации на статистика што успеавме да ги најдеме. Да замислиме дека некоја единствена инфраструктура порасна толку многу што прифаќањето 4 милиони MPS веќе не е доволно. Или дури и ако сè уште не пораснало, но метриката е веќе толку важна за вас што дури и кратките падови од 2-3 минути во графиконите веќе можат да станат критични и да предизвикаат напади на непремостлива депресија кај менаџерите. Бидејќи лекувањето на депресијата е неблагодарна задача, потребни се технички решенија.

Прво, толеранција на грешки, за ненадеен проблем на серверот да не предизвика психијатриска зомби апокалипса во канцеларијата. Второ, скалирање за да може да прифати повеќе од 4 милиони MPS, без да се копа длабоко во оџакот на мрежата на Linux и мирно да расте „во ширина“ до потребната големина.

Бидејќи имавме простор за скалирање, решивме да започнеме со толеранција на грешки. „За! Толеранција на грешки! Едноставно е, можеме да го направиме тоа“, си помисливме и лансиравме 2 сервери, подигајќи копија од брубек на секој. За да го направите ова, моравме да го копираме сообраќајот со метрика на двата сервери, па дури и да пишуваме за ова мала корист. Со ова го решивме проблемот со толеранција на грешки, но... не баш добро. На почетокот сè изгледаше одлично: секој брубек собира своја верзија на агрегација, запишува податоци на Graphite еднаш на секои 30 секунди, препишувајќи го стариот интервал (ова се прави на страната Graphite). Ако еден сервер одеднаш откажа, секогаш имаме втор со своја копија од збирните податоци. Но, тука е проблемот: ако серверот не успее, на графиконите се појавува „пила“. Ова се должи на фактот што интервалите од 30 секунди на брубек не се синхронизирани, а во моментот на падот еден од нив не е препишан. Кога ќе стартува вториот сервер, се случува истото. Сосема подносливо, но сакам подобро! Проблемот со приспособливост исто така не исчезна. Сите метрики сè уште „летаат“ на еден сервер, и затоа сме ограничени на истите 2-4 милиони MPS, во зависност од нивото на мрежата.

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

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

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

На што да пишувам? Се разбира, во Руст. Зошто?

• бидејќи веќе постоеше прототип на решение,
• бидејќи авторот на статијата веќе го познавал Руст во тоа време и сакал да напише нешто во него за производство со можност да го стави во отворен код,
• бидејќи јазиците со GC не се соодветни за нас поради природата на примениот сообраќај (речиси во реално време), а паузите на GC се практично неприфатливи,
• затоа што ви требаат максимални перформанси споредливи со C
• затоа што Rust ни обезбедува бестрашна истовременост, и ако почнеме да го пишуваме во C/C++, ќе наидевме на уште повеќе ранливости, прелевање на тампон, услови за трка и други страшни зборови освен брубек.

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

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

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

Секој јазол добива свој сет на метрика и ги акумулира, и не ги собира метриките за оние типови каде што е потребно нивно целосен сет за конечна агрегација. Јазлите се поврзани едни со други со некој вид дистрибуиран протокол за заклучување, кој ви овозможува да изберете меѓу нив единствениот (тука плачевме) што е достоен да испрати метрика до Големиот. Овој проблем во моментов се решава од Конзул, но во иднина амбициите на авторот се прошируваат на свој имплементација Сплав, каде што најдостојниот, се разбира, ќе биде јазол на лидерот на консензус. Покрај консензусот, јазлите доста често (еднаш во секунда стандардно) ги испраќаат до своите соседи оние делови од претходно собрани метрика што успеале да ги соберат во таа секунда. Излегува дека скалирањето и толеранцијата на грешки се зачувани - секој јазол сè уште има целосен сет на метрика, но метриките се испраќаат веќе собрани, преку TCP и кодирани во бинарен протокол, така што трошоците за дуплирање се значително намалени во споредба со UDP. И покрај прилично големиот број на дојдовни метрики, акумулацијата бара многу малку меморија и уште помалку процесор. За нашите висококомпресибилни вредности, ова е само неколку десетици мегабајти податоци. Како дополнителен бонус, не добиваме непотребни препишувања на податоци во Графит, како што беше случајот со Бурбек.

UDP пакетите со метрика се небалансирани помеѓу јазлите на мрежната опрема преку едноставен Round Robin. Се разбира, мрежниот хардвер не ја анализира содржината на пакетите и затоа може да повлече многу повеќе од 4 милиони пакети во секунда, а да не зборуваме за метрика за која воопшто не знае ништо. Ако земеме предвид дека метриката не доаѓа една по една во секој пакет, тогаш не предвидуваме никакви проблеми со перформансите на ова место. Ако серверот падне, мрежниот уред брзо (во рок од 1-2 секунди) го открива овој факт и го отстранува урнатиот сервер од ротација. Како резултат на ова, пасивните (т.е. не-лидерски) јазли може да се вклучат и исклучуваат практично без да се забележат повлекувања на графиконите. Максимумот што го губиме е дел од метриката што се појави во последната секунда. Ненадејното губење/исклучување/прекинување на лидерот сепак ќе создаде мала аномалија (интервалот од 30 секунди сè уште не е синхронизиран), но ако има комуникација помеѓу јазлите, овие проблеми може да се минимизираат, на пример, со испраќање пакети за синхронизација .

Малку за внатрешната структура. Апликацијата, се разбира, е со повеќе нишки, но архитектурата на нишки е различна од онаа што се користи во брубек. Нишките во брубек се исти - секоја од нив е одговорна и за собирање информации и за собирање. Во bioyino, работниците се поделени во две групи: оние кои се одговорни за мрежата и оние кои се одговорни за агрегација. Оваа поделба ви овозможува пофлексибилно да управувате со апликацијата во зависност од типот на метрика: каде што е потребно интензивно собирање, можете да додавате агрегатори, каде што има многу мрежен сообраќај, можете да го додадете бројот на мрежни текови. Во моментов, на нашите сервери работиме во 8 мрежни и 4 агрегациски текови.

Делот за броење (одговорен за собирање) е прилично досаден. Баферите исполнети со мрежни текови се дистрибуираат меѓу тековите за броење, каде што последователно се анализираат и агрегираат. По барање, метрика се дадени за испраќање до други јазли. Сето ова, вклучително и испраќање податоци помеѓу јазли и работа со конзул, се изведува асинхроно, работи на рамката tokio.

Многу повеќе проблеми за време на развојот беа предизвикани од мрежниот дел одговорен за примање метрика. Главната цел на одвојувањето на мрежните текови во посебни ентитети беше желбата да се намали времето што го троши протокот. Нема за читање податоци од штекерот. Опциите со користење на асинхрон UDP и редовни recvmsg брзо исчезнаа: првиот троши премногу кориснички процесорски простор за обработка на настани, а вториот бара премногу контекстуални прекинувачи. Затоа сега се користи recvmmsg со големи бафери (и баферите, господа офицери, не ви се ништо!). Поддршката за редовниот UDP е резервирана за лесни случаи каде што не е потребен recvmmsg. Во режимот на повеќе пораки, можно е да се постигне главната работа: огромното мнозинство од времето, мрежната нишка ја гребе редицата за ОС - ги чита податоците од штекерот и ги пренесува во баферот на корисничкиот простор, само повремено се префрла на давање на пополнетиот бафер на агрегатори. Редот во штекерот практично не се акумулира, бројот на паднати пакети практично не расте.

Имајте на ум

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

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

Статистика за бројот на дојдовни метрики за секој сервер: повеќе од 2 милиони MPS.

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

Статистика за појдовна метрика: само еден јазол секогаш испраќа - шефот на рацијата.

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

Детали за дојдовните метрика (метричките имиња се скриени).

Што планираме да правиме со сето ова следно? Се разбира, пиши код, проклето...! Проектот првично беше планиран да биде со отворен код и така ќе остане во текот на својот животен век. Нашите непосредни планови вклучуваат префрлување на нашата сопствена верзија на Raft, промена на протоколот за врсници на попренослив, воведување дополнителна внатрешна статистика, нови типови на метрика, поправени грешки и други подобрувања.

Се разбира, секој е добредојден да помогне во развојот на проектот: креирајте ПР, прашања, ако е можно ќе одговориме, подобриме итн.

Со тоа што се вели, тоа е сè луѓе, купете ги нашите слонови!

Извор: www.habr.com