Друг систем за следење

16 модеми, 4 мобилни оператори = Појдовна брзина 933.45 Mbit/s

Вовед

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

За проектот

Имаме прилично специфичен производ. Ние произведуваме сеопфатно решение за сумирање на пропусната моќ и толеранцијата на грешки на каналите за пренос на податоци. Ова е кога има неколку канали, да речеме Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Нешто друго (5 Mbit/s), резултатот е еден стабилен и брз канал, чија брзина ќе биде нешто како ова: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

Ваквите решенија се барани кога капацитетот на кој било канал е недоволен. На пример, транспорт, системи за видео надзор и видео стриминг во реално време, пренос на телевизиски и радио преноси во живо, какви било приградски објекти каде што меѓу телекомуникациските оператори има само претставници на големата четворка и брзината на еден модем/канал не е доволна. .
За секоја од овие области, произведуваме посебна линија на уреди, но нивниот софтверски дел е речиси ист и висококвалитетниот систем за следење е еден од неговите главни модули, без чија правилна имплементација производот не би бил возможен.

Во текот на неколку години, успеавме да создадеме систем за следење на повеќе нивоа, брз, меѓуплатформски и лесен систем за следење. Ова е она што сакаме да го споделиме со нашата почитувана заедница.

Проблем изјава

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

1. Високофреквентно синхроно стекнување на метрика во реално време и нивно пренесување на системот за управување со комуникација без одлагање.
   Високата фреквенција и синхронизацијата на различни метрики не е само важна, туку е од витално значење за анализа на ентропијата на каналите за пренос на податоци. Ако во еден канал за пренос на податоци просечното доцнење е 30 милисекунди, тогаш грешката во синхронизацијата помеѓу преостанатите метрики од само една милисекунда ќе доведе до деградација на брзината на добиениот канал за приближно 5%. Ако го погрешиме тајмингот за 1 милисекунда на 4 канали, деградацијата на брзината лесно може да падне до 30%. Покрај тоа, ентропијата во каналите се менува многу брзо, па ако ја измериме помалку од еднаш на секои 0.5 милисекунди, на брзите канали со мало задоцнување ќе добиеме голема брзина на деградација. Се разбира, таквата точност не е потребна за сите метрики и не во сите услови. Кога доцнењето во каналот е 500 милисекунди, а ние работиме со такви, тогаш грешката од 1 милисекунда речиси нема да се забележи. Исто така, за метрика на системот за поддршка на животот, имаме доволно стапки на гласање и синхронизација од 2 секунди, но самиот систем за следење мора да може да работи со ултра високи стапки на гласање и ултра прецизна синхронизација на метрика.
2. Минимална потрошувачка на ресурси и еден куп.
   Крајниот уред може да биде или моќен вграден комплекс кој може да ја анализира ситуацијата на патот или да спроведе биометриско снимање на луѓе, или компјутер со една плоча со големина на дланка што војник од специјалните сили го носи под неговиот оклоп за да пренесува видео во реално време во лоши услови за комуникација. И покрај таквата разновидност на архитектури и компјутерска моќ, би сакале да го имаме истиот софтверски пакет.
3. Архитектура на чадори
   Метриките мора да се собираат и соберат на крајниот уред, локално да се складираат и да се визуелизираат во реално време и ретроспективно. Ако има врска, префрлете ги податоците до централниот систем за следење. Кога нема врска, редот за испраќање треба да се акумулира и да не троши RAM меморија.
4. API за интеграција во системот за следење на клиентите, бидејќи никому не му требаат многу системи за следење. Клиентот мора да собира податоци од сите уреди и мрежи во еден мониторинг.

Што се случи

За да не го оптоварувам веќе импресивното долгогодишно, нема да давам примери и мерења на сите системи за следење. Ова ќе доведе до друга статија. Само ќе кажам дека не успеавме да најдеме систем за следење кој може да земе две метрики истовремено со грешка помала од 1 милисекунда и кој работи подеднакво ефикасно и на архитектурата ARM со 64 MB RAM и на архитектурата x86_64 со 32 GB RAM меморија. Затоа, решивме да напишеме своја, која може да го направи сето ова. Еве што добивме:

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

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

архитектура

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

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

1. Регистрација на метрика.
   Секоја метрика се опслужува со сопствена нишка и се синхронизира низ каналите. Можевме да постигнеме точност на синхронизација до 10 наносекунди.
2. Складирање на метрика
   Избиравме помеѓу пишување на сопствен склад за временски серии или користење на нешто што веќе беше достапно. Базата на податоци е потребна за ретроспективни податоци кои подлежат на последователна визуелизација, односно не содржи податоци за доцнење на каналот на секои 0.5 милисекунди или отчитувања на грешки во транспортната мрежа, но има брзина на секој интерфејс на секои 500 милисекунди. Покрај високите барања за крос-платформа и малата потрошувачка на ресурси, за нас е исклучително важно да можеме да обработуваме. податоците е местото каде што се чуваат. Ова заштедува огромни компјутерски ресурси. Tarantool DBMS го користиме во овој проект од 2016 година и засега не гледаме замена за него на хоризонтот. Флексибилен, со оптимална потрошувачка на ресурси, повеќе од соодветна техничка поддршка. Tarantool исто така имплементира ГИС модул. Се разбира, не е толку моќен како PostGIS, но е доволно за нашите задачи да складираме некои метрики поврзани со локацијата (релевантни за транспорт).
3. Визуелизација на метрика
   Сè е релативно едноставно овде. Земаме податоци од магацинот и ги прикажуваме или во реално време или ретроспективно.
4. Синхронизација на податоците со централниот мониторинг систем.
   Централниот систем за следење прима податоци од сите уреди, ги складира со одредена историја и ги испраќа до системот за следење на клиентот преку API. За разлика од класичните системи за следење, во кои „главата“ шета и собира податоци, имаме спротивна шема. Самите уреди испраќаат податоци кога има врска. Ова е многу важна точка, бидејќи ви овозможува да примате податоци од уредот за оние временски периоди во кои тој не бил достапен и да не вчитувате канали и ресурси додека уредот е недостапен. Ние користиме сервер за следење на приливот како централен систем за следење. За разлика од неговите аналози, тој може да увезува ретроспективни податоци (односно, со временски печат различен од моментот на прием на метриката) Собраните метрики се визуелизирани од Графана, модифицирани со датотека. Овој стандарден стек исто така беше избран затоа што има готови интеграции на API со речиси секој систем за следење на клиентите.
5. Синхронизација на податоци со централен систем за управување со уреди.
   Системот за управување со уреди имплементира Zero Touch Provisioning (ажурирање на фирмверот, конфигурација итн.) и, за разлика од системот за следење, прима само проблеми по уред. Ова се предизвикувачи за функционирање на хардверските чувари услуги на одборот и сите показатели за системите за поддршка на животот: температура на процесорот и SSD, оптоварување на процесорот, слободен простор и SMART здравје на дисковите. Подсистемското складирање е исто така изградено на Tarantool. Ова ни дава значителна брзина во собирањето временски серии на илјадници уреди, а исто така целосно го решава проблемот со синхронизирање на податоците со овие уреди. Tarantool има одличен систем за редици и гарантирана испорака. Ја добивме оваа важна карактеристика надвор од кутијата, одлично!

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

Што е следно

Засега најслабата алка ни е централниот мониторинг систем. Имплементиран е 99.9% на стандарден оџак и има голем број на недостатоци:

1. InfluxDB губи податоци кога се губи напојувањето. Како по правило, Клиентот навремено собира сè што доаѓа од уредите и самата база на податоци не содржи податоци постари од 5 минути, но во иднина тоа може да стане болка.
2. Grafana има голем број проблеми со собирање податоци и синхронизација на нејзиниот приказ. Најчест проблем е кога базата на податоци содржи временска серија со интервал од 2 секунди почнувајќи од, да речеме, 00:00:00 часот, а Grafana почнува да прикажува податоци збирно од +1 секунда. Како резултат на тоа, корисникот гледа графикон за танцување.
3. Прекумерна количина на код за интеграција на API со системи за следење од трети страни. Може да се направи многу покомпактен и секако да се преработи во Go)

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

Заклучок

Намерно не ги опишав техничките детали, туку го опишав само основниот дизајн на овој систем. Прво, за технички целосно опишување на системот, ќе биде потребен друг напис. Второ, нема сите да бидат заинтересирани за ова. Напишете во коментар кои технички детали би сакале да ги знаете.

Ако некој има прашања надвор од опсегот на оваа статија, може да ми пише на a.rodin @ qedr.com

Извор: www.habr.com