🥇Друга система за наблюдение

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

въведение

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

О проекте

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

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

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

Проблем изявление

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

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

Какво стана

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

Обобщаване на пропускателната способност на три канала за различни мрежови топологии

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

архитектура

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

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

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

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

Какво следва?

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

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

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

Заключение

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

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

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

Друга система за наблюдение