🥇Още една система за мониторинг

16 модема, 4 мобилни оператора = Изходяща скорост 933.45 Мбит/с

Въведение

Здравейте! Това е статия за новата система за мониторинг, която разработихме за себе си. Тя се отличава от съществуващите с възможността за височестотен синхронен получаване на метрики и много малко потребление на ресурси. Честотата на запитванията може да достигне 0.1 милисекунди с точност на синхронизация между метриките от 10 наносекунди. Всички бинарни файлове заемат 6 мегабайта.

За проекта

Имаме доста специфичен продукт. Произвеждаме комплексно решение за агрегиране на пропускателна способност и отказоустойчивост на канали за предаване на данни. Това е, когато има няколко канала, например Оператор1 (40Мбит/с) + Оператор2 (30Мбит/с) + Нещо друго (5 Мбит/с), в резултат на което получаваме един стабилен и бърз канал, чиято скорост ще бъде приблизително такава: (40+30+5)x0.92=75×0.92=69 Мбит/с.

Такива решения са търсени, когато капацитетът на един канал не е достатъчен. Например транспорт, системи за видеонаблюдение и потоково видео предаване в реално време, излъчване на директни телевизионни и радио предавания, всякакви извънградски обекти, където операторите са само представители на голямата четворка и скоростта на един модем/канал не е достатъчна.
За всяка от тези области произвеждаме отделна линия устройства, но софтуерната им част е почти еднаква, а качествената система за мониторинг е един от основните модули, без правилната реализация на който продуктът би бил невъзможен.

В течение на няколко години успяхме да създадем многостепенна, бърза, кросплатформена и лека система за мониторинг. С което искаме да споделим с уважаваната общност.

Формулиране на задачата

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

Височестотно синхронно получаване на метрики в реално време и предаване на тях към системата за управление на връзките без забавяне.
Високата честота и синхронизация на различни метрики не е просто важна, а е жизненоважна за анализа на ентропията на каналите за предаване на данни. Ако в един канал за предаване на данни средното забавяне е 30 милисекунди, то грешка в синхронизацията между останалите метрики само с една милисекунда ще доведе до деградация на скоростта на резултата на канала с около 5%. Ако сбъркаме в синхронизацията с 1 милисекунда в 4 канала, деградацията на скоростта лесно може да спадне до 30%. Освен това, ентропията в каналите се променя много бързо, затова ако измерваме по-рядко от веднъж на 0.5 милисекунди, на бързи канали с малко забавяне ще получим висока деградация на скоростта. Разбира се, такава точност не е необходима за всички метрики и при всички условия. Когато забавянето в канала е 500 милисекунди, а работим и с такива, грешката от 1 милисекунда почти няма да се забележи. Също така, за метрики на системи за жизненосигуряване ни е достатъчна честота на запитвания и синхронизация от 2 секунди, но самата система за мониторинг трябва да е в състояние да работи с изключително високи честоти на запитвания и изключително точна синхронизация на метриките.
Минимално потребление на ресурси и единен стек.
Крайната единица може да представлява мощен бортов комплекс, който може да анализира ситуацията на пътя или да извършва биометрично наблюдение на хора, както и едноплатен компютър с размер на длан, носен под бронежилета от специален войник за предаване на видео в реално време при лоша свързаност. Въпреки такова разнообразие от архитектури и изчислителни мощности, искаме да имаме единен софтуерен стек.
Зонтична архитектура
Метриките трябва да се събират и агрегатират на крайната единица, да имат локална система за съхранение и визуализация в реално време и ретроспективно. В случай на налична свързаност — да предават данни в централната система за мониторинг. Когато свързаност няма — опашката за изпращане трябва да се натрупва и да не изразходва оперативната памет.
API за интеграция в системата за мониторинг на клиента, защото никому не е необходима множество системи за мониторинг. Клиентът трябва да събира данни от всякакви устройства и мрежи в единен мониторинг.

Какво се получи

За да не натоварвам допълнително и без това обширния лонгрид, няма да давам примери и измервания на всички системи за мониторинг. Това ще изисква още една статия. Просто ще кажа, че не успяхме да намерим система за мониторинг, способна да вземе две метрики едновременно с грешност под 1 милисекунда и която да функционира еднакво ефективно както на ARM архитектура с 64MB RAM, така и на x86_64 архитектура с 32GB RAM. Затова решихме да напишем своя, която да може да прави всичко това. Ето какво постигнахме:

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

Визуализация на някои ключови метрики

Архитектура

Като основен език за програмиране, както на устройствата, така и в ЦОД-а, използваме Golang. Той значително улесни живота ни с реализираният многозадачен подход и възможността да получим един статично линкван изпълняем бинарен файл за всеки сервиз. В резултат на това значително спестяваме ресурси, методи и трафик при разгръщането на сервиза на крайни устройства, време за разработка и отстраняване на кодови грешки.

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

Регистрация на метрики.
Всяка метрика се обслужва от собствен поток и се синхронизира чрез канали. Успяхме да постигнем точност на синхронизация до 10 наносекунди.
Съхранение на метрики
Избирахме между написването на собствено хранилище за времеви редици или използването на нещо налично. Базата данни е необходима за ретроспективни данни, които подлежат на последваща визуализация. Т.е. в нея няма данни за забавяния в канала на всеки 0.5 милисекунди или показания за грешки в транспортната мрежа, но има скорост на всеки интерфейс на всеки 500 милисекунди. Освен високите изисквания за кроссплатформеност и ниско потребление на ресурси, изключително важно за нас е да можем да обработваме данните там, където се съхраняват. Това значително икономисва изчислителни ресурси. От 2016 година използваме СУБД Tarantool в този проект и за момента не виждаме заместник в хоризонта. Гъвкав, с оптимално потребление на ресурси и адекватна техническа поддръжка. Tarantool също така внедрява модул за ГИС. Той, разбира се, не е толкова мощен като PostGIS, но е достатъчен за нашите нужди за съхранение на метрики, свързани с локации (актуално за транспорта).
Визуализация на метрики
Тук всичко е относително просто. Вземаме данни от хранилището и ги показваме или в реално време, или ретроспективно.
Синхронизация на данни с централната система за мониторинг.
Централната система за мониторинг приема данни от всички устройства, съхранява ги с определена ретроспектива и чрез API ги предоставя на системата за мониторинг на Заказчика. За разлика от класическите системи за мониторинг, при които „главата“ събира данни, при нас схемата е обратна. Устройствата сами изпращат данни, когато имат връзка. Това е много важен момент, тъй като позволява получаването на данни от устройството за времеви интервали, в които то не е било достъпно, а не натоварва каналите и ресурсите, когато устройството не е налично. Като централна система за мониторинг използваме Influx monitoring server. За разлика от аналогичните системи, той може да импортира ретроспективни данни (т.е. с времева метка, различна от момента на получаване на метриката). Събраните метрики визуализираме с подобрената Grafana. Този стандартен стек беше избран и поради факта, че има готови API интеграции практически с всяка система за мониторинг на клиента.
Синхронизация на данни с централната система за управление на устройствата.
Системата за управление на устройствата осъществява Zero Touch Provisioning (обновление на фърмуера, конфигурацията и т.н.) и за разлика от системата за мониторинг, получава само проблеми с устройствата. Това са тригери за работа на бордовите хардуерни сторидж услуги и всички метрики на системите за животоподдържане: температура на CPU и SSD, натоварване на CPU, свободно място и S.M.A.R.T здраве на дисковете. Съхранението на подсистемата е изградена също на Tarantool. Това ни дава значителна скорост при агрегацията на времевите редици за хиляди устройства, а също така напълно решава въпроса за синхронизация на данните с тези устройства. Tarantool включва отлична система за опашки и гарантирано доставяне. Тази важна функция получихме от кутията, прекрасно!

Система за управление на мрежата

Какво следва

В момента най-слабото звено е централната система за мониторинг. Тя е реализирана на 99.9% на стандартния стек и има редица недостатъци:

InfluxDB губи данни при изключване на захранването. Обикновено клиентът бързо взима всичко, което идва от устройството, и в самата база данни няма данни по-стари от 5 минути, но в бъдеще това може да стане проблем.
Grafana има редица проблеми с агрегацията на данни и синхронността на тяхното отображение. Най-честият проблем е, когато в базата има времеви ред с интервал от 2 секунди, започващ от 00:00:00, а Grafana започва да показва данни в агрегация с +1 секунда. В резултат на това потребителят вижда пляскащ график.
Излишно количество код за API интеграция с външни системи за мониторинг. Може да се направи много по-компактно и разбира се, да се пренапише на Go)

Сигурен съм, че всички вие прекрасно сте виждали как изглежда Grafana и без мен знаете нейните проблеми, затова няма да натоварвам поста с картинки.

Заключение

Съзнателно не описах техническите детайли, а само основния дизайн на тази система. Първо, за технически пълно описание на системата е нужна още една статия. На второ място, не всеки ще намери това интересно. Напишете в коментарите какви технически детайли бихте искали да разберете.

Ако някой има въпроси извън тази статия, може да ми пише на адрес a.rodin @ qedr.com

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