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 з 64Мбайт ОЗУ так і на х86_64 архітектурі з 32 Гбайт ОЗУ. Тому ми вирішили написати свою, яка вміє ось це все. Ось що в нас вийшло:
Підсумовування пропускної спроможності трьох каналів для різної топології мережі
Візуалізація деяких ключових метрик
Архітектура
Як основна мова програмування, як на пристрої так і в ЦОДі, ми використовуємо Golang. Він значно спростив життя своєю реалізацією багатозадачності та можливістю отримати один статично злинкований виконуваний бінарний файл для кожного сервісу. В результаті ми значно економимо в ресурсах, способах та трафіку деплою сервісу на кінцеві пристрої, часу розробки та налагодження коду.
Система реалізована за класичним модульним принципом і містить у собі кілька підсистем:
- Зареєструватись метрик.
Кожна метрика обслуговується власним потоком та синхронізується через канали. Нам удалося отримати точність синхронізації до 10 наносекунд. - Зберігання метрик
Ми вибирали тим часом, щоб написати своє сховище для тимчасових рядів або використати щось із наявного. База даних потрібна для ретроспективних даних, які підлягають подальшій візуалізації. Тобто в ній немає даних про затримки в каналі кожні 0.5 мілісекунд або показання помилок у транспортній мережі, але є швидкість на кожному інтерфейсі кожні 500 мілісекунд. Крім високих вимог до кросплатформенності та малого споживання ресурсів, нам дуже важливо мати можливість обробити. дані там де вони зберігаються. Це колосально заощаджує обчислювальний ресурс. Ми з 2016 року використовуємо СУБД Tarantool у цьому проекті і поки що в горизонті не бачимо йому заміни. Гнучкий, з оптимальним споживанням ресурсів, більш ніж адекватною техпідтримкою. Також у Tarantool реалізований GIS модуль. Він звичайно не такий потужний як PostGIS, але його вистачає для наших завдань зберігання деяких метрик, прив'язаних до локації (актуально для транспорту). - Візуалізація метрик
Тут усе відносно просто. Беремо дані зі сховища і показуємо їх у реальному часі або ретроспективно. - Синхронізація даних із центральною системою моніторингу.
Центральна система моніторингу приймає дані від усіх пристроїв, зберігає їх із заданою ретроспективою та через API віддає їх у систему моніторингу Замовника. На відміну від класичних систем моніторингу, в яких голова ходить і збирає дані — у нас зворотна схема. Пристрої самі надсилають дані тоді, коли є зв'язок. Це дуже важливий момент, оскільки він дозволяє отримати дані з пристрою за проміжки часу, в які воно було не доступне і не навантажувати канали і ресурси в той час коли пристрій недоступний. Як центральна система моніторингу ми використовуємо Influx monitoring server. На відміну від аналогів, вміє імпортувати ретроспективні дані (тобто з міткою часу, відмінною від моменту отримання метрики) Зібрані метрики візуалізує допрацьована напилком Grafana. Цей стандартний стек був обраний ще й тому, що має готові API інтеграції практично з будь-якою системою моніторингу замовника. - Синхронізація даних із центральною системою керування пристроями.
Система керування пристроями реалізує Zero Touch Provisioning (оновлення прошивки, конфігурації тощо) та на відміну від системи моніторингу отримує тільки проблеми по пристроях. Це тригери роботи бортових апаратних сторожових сервісів та всі метрики систем життєзабезпечення: температура CPU та SSD, навантаження CPU, вільне місце та SMART здоров'я на дисках. Сховище підсистеми збудовано також на Tarantool. Це дає нам значну швидкість в агрегації часових рядів по тисячам пристроїв, а також вирішує питання синхронізації даних з цими пристроями. У Tarantool вбудована чудова система черг та гарантованої доставки. Цю важливу фічу ми отримали з коробки, красиво!
Система управління мережею
Що далі
Поки що найслабшою ланкою у нас є центральна система моніторингу. Вона реалізована на 99.9% на стандартному стеку і має ряд недоліків:
- InfluxDB втрачає дані при відключенні живлення. Як правило, Замовник оперативно забирає все, що приходить від пристроїв і в самій БД немає даних старше 5 хвилин, проте в майбутньому це може стати болем.
- Grafana має ряд проблем із агрегацією даних та синхронністю їх відображення. Найчастіша проблема - коли в базі лежить часовий ряд з інтервалом в 2 секунди, починаючи скажімо з 00:00:00, а Grafana починає показувати дані в агрегації з +1 секунду. В результаті користувач бачить танцюючий графік.
- Надмірна кількість коду для API інтеграції зі сторонніми системами моніторингу. Можна зробити набагато компактніше і звичайно переписати на Go)
Вважаю всі ви чудово бачили як виглядає Grafana і без мене знаєте її проблеми, тому не перевантажуватиму пост картинками.
Висновок
Я свідомо не став описувати технічних деталей, а описав лише опорний дизайн цієї системи. По-перше, щоб технічно повно описати систему буде потрібна ще одна стаття. По-друге, далеко не всім буде це цікаво. Напишіть у коментарях якісь технічні деталі вам хотілося б дізнатися.
Якщо у когось виникнуть питання за межами цієї статті, мені можна писати на адресу [email protected]
Джерело: habr.com