Још један систем за праћење

16 модема, 4 мобилна оператера = Одлазна брзина 933.45 Мбит/с

Увод

Здраво! Овај чланак говори о томе како смо за себе написали нови систем за праћење. Од постојећих се разликује по својој способности да добије високофреквентне синхроне метрике и веома ниску потрошњу ресурса. Брзина анкетирања може да достигне 0.1 милисекунду са тачношћу синхронизације између метрика од 10 наносекунди. Све бинарне датотеке заузимају 6 мегабајта.

око

Имамо прилично специфичан производ. Производимо свеобухватно решење за сумирање пропусности и толеранције грешака канала за пренос података. Ово је када постоји неколико канала, рецимо Оператор1 (40Мбит/с) + Оператор2 (30Мбит/с)+ Нешто друго (5 Мбит/с), резултат је један стабилан и брз канал чија ће брзина бити отприлике ово: (40+ 30+5)к0.92=75×0.92=69 Мбит/с.

Таква решења су тражена тамо где је капацитет било ког канала недовољан. На пример, транспорт, системи видео-надзора и видео стриминг у реалном времену, емитовање телевизијских и радио преноса уживо, било који приградски објекти где међу телеком оператерима постоје само представници велике четворке и брзина на једном модему/каналу није довољна. .
За сваку од ових области производимо посебну линију уређаја, али њихов софтверски део је скоро исти и квалитетан систем за праћење је један од његових главних модула, без чије правилне имплементације производ не би био могућ.

Током неколико година успели смо да креирамо систем за праћење на више нивоа, брз, вишеплатформски и лаган. То је оно што желимо да поделимо са нашом поштованом заједницом.

Проблем статемент

Систем за праћење обезбеђује метрику две фундаментално различите класе: метрике у реалном времену и све остале. Систем за праћење је имао само следеће захтеве:

1. Високофреквентно синхроно прикупљање метрике у реалном времену и њихов пренос у систем управљања комуникацијама без одлагања.
   Висока фреквенција и синхронизација различитих метрика није само важна, већ је од виталног значаја за анализу ентропије канала за пренос података. Ако је у једном каналу преноса података просечно кашњење 30 милисекунди, онда ће грешка у синхронизацији између преосталих метрика од само једне милисекунди довести до деградације брзине резултирајућег канала за приближно 5%. Ако погрешимо тајминг за 1 милисекунду на 4 канала, деградација брзине може лако пасти на 30%. Поред тога, ентропија у каналима се веома брзо мења, па ако је меримо мање од једном у сваких 0.5 милисекунди, на брзим каналима са малим кашњењем добићемо деградацију велике брзине. Наравно, таква тачност није потребна за све метрике и не у свим условима. Када је кашњење у каналу 500 милисекунди, а ми радимо са таквим, онда грешка од 1 милисекунде скоро да неће бити приметна. Такође, за метрику система за одржавање живота, имамо довољне стопе анкетирања и синхронизације од 2 секунде, али сам систем за праћење мора бити у стању да ради са ултра високим стопама анкетирања и ултра прецизном синхронизацијом метрика.
2. Минимална потрошња ресурса и један стек.
   Крајњи уређај може бити или моћан комплекс у возилу који може анализирати ситуацију на путу или вршити биометријско снимање људи, или једноплатни рачунар величине длана који војник специјалних снага носи испод панцира за пренос видео записа у реалном времену у лошим условима комуникације. Упркос таквој разноликости архитектура и рачунарске снаге, желели бисмо да имамо исти софтверски стог.
3. Архитектура кишобрана
   Метрике морају бити прикупљене и агрегиране на крајњем уређају, локално ускладиштене и визуализоване у реалном времену и ретроспективно. Ако постоји веза, пренесите податке у централни систем за надзор. Када нема везе, ред за слање треба да се акумулира и да не троши РАМ.
4. АПИ за интеграцију у систем за праћење корисника, јер никоме није потребно много система за праћење. Купац мора прикупљати податке са било ког уређаја и мреже у један надзор.

Шта се десило

Да не бих оптеретио ионако импресиван лонгреад, нећу давати примере и мерења свих система за праћење. Ово ће довести до другог чланка. Рећи ћу само да нисмо успели да пронађемо систем за надзор који је способан да узима две метрике истовремено са грешком мањом од 1 милисекунде и који подједнако ефикасно ради и на АРМ архитектури са 64 МБ РАМ-а и на архитектури к86_64 са 32 ГБ РАМ-а. Стога смо одлучили да напишемо своју, која све ово може. Ево шта смо добили:

Сумирање пропусности три канала за различите мрежне топологије

Визуелизација неких кључних метрика

архитектура

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

Систем је реализован по класичном модуларном принципу и садржи неколико подсистема:

1. Регистрација метрика.
   Сваку метрику опслужује сопствена нит и синхронизује се на свим каналима. Успели смо да постигнемо тачност синхронизације до 10 наносекунди.
2. Складиштење метрика
   Бирали смо између писања сопственог складишта за временске серије или коришћења нечега што је већ било доступно. База података је потребна за ретроспективне податке који подлежу накнадној визуелизацији, односно не садржи податке о кашњењима у каналу на сваких 0.5 милисекунди или очитавању грешака у транспортној мрежи, већ постоји брзина на сваком интерфејсу сваких 500 милисекунди. Поред високих захтева за више платформи и ниске потрошње ресурса, изузетно нам је важно да можемо да обрађујемо. подаци су тамо где се чувају. Ово штеди огромне рачунарске ресурсе. Тарантоол ДБМС користимо у овом пројекту од 2016. године и до сада не видимо замену за њега на хоризонту. Флексибилан, са оптималном потрошњом ресурса, више него адекватна техничка подршка. Тарантоол такође имплементира ГИС модул. Наравно, није тако моћан као ПостГИС, али је довољан за наше задатке чувања неких метрика везаних за локацију (релевантне за транспорт).
3. Визуелизација метрике
   Овде је све релативно једноставно. Узимамо податке из складишта и приказујемо их у реалном времену или ретроспективно.
4. Синхронизација података са централним системом за праћење.
   Централни систем за надзор прима податке са свих уређаја, складишти их са одређеном историјом и шаље их систему за надзор Купца преко АПИ-ја. За разлику од класичних система за праћење, у којима „глава“ шета около и прикупља податке, имамо супротну шему. Сами уређаји шаљу податке када постоји веза. Ово је веома важна тачка, јер вам омогућава да примате податке са уређаја за оне периоде током којих није био доступан и да не учитавате канале и ресурсе док уређај није доступан. Ми користимо Инфлук мониторинг сервер као централни систем за надзор. За разлику од својих аналога, може да увози ретроспективне податке (тј. са временском ознаком различитом од тренутка пријема метрике) Прикупљене метрике визуелизује Графана, модификоване датотеком. Овај стандардни стек је такође изабран зато што има готове АПИ интеграције са скоро сваким системом за праћење корисника.
5. Синхронизација података са централним системом за управљање уређајима.
   Систем за управљање уређајем имплементира Зеро Тоуцх Провисионинг (ажурирање фирмвера, конфигурације, итд.) и, за разлику од система за надзор, добија само проблеме по уређају. Ово су покретачи за рад уграђених хардверских надзорних сервиса и свих метрика система за одржавање живота: температура ЦПУ-а и ССД-а, оптерећење ЦПУ-а, слободан простор и СМАРТ здравље на дисковима. Подсистем за складиштење је такође изграђен на Тарантоол-у. Ово нам даје значајну брзину у агрегирању временских серија на хиљадама уређаја, а такође у потпуности решава проблем синхронизације података са овим уређајима. Тарантоол има одличан систем чекања и гарантоване испоруке. Извукли смо ову важну функцију из кутије, одлично!

Систем управљања мрежом

Шта је следеће

До сада нам је најслабија карика централни систем праћења. Имплементиран је 99.9% на стандардном стеку и има низ недостатака:

1. ИнфлукДБ губи податке када се изгуби напајање. По правилу, Купац ажурно прикупља све што долази са уређаја, а сама база података не садржи податке старије од 5 минута, али у будућности то може постати мука.
2. Графана има низ проблема са агрегацијом података и синхронизацијом приказа. Најчешћи проблем је када база података садржи временску серију са интервалом од 2 секунде почевши, рецимо, од 00:00:00, а Графана почиње да приказује податке у агрегацији од +1 секунде. Као резултат, корисник види плесни графикон.
3. Превелика количина кода за интеграцију АПИ-ја са системима за праћење независних произвођача. Може се учинити много компактнијим и наравно преписати у Го)

Мислим да сте сви одлично видели како Графана изгледа и знате њене проблеме и без мене, тако да нећу преоптеретити пост сликама.

Закључак

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

Ако неко има питања изван оквира овог чланка, можете ми писати на а.родин @ кедр.цом

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