Суммирование скорости на 16 модемах 4 операторов сотовой связи.
Исходящая скорость на поток - 933,45 Мбит/с.
Введение
Привет! Эта статья о том, как мы писали для себя новую систему мониторинга.От существующих он отличается возможностью получения высокочастотных синхронных метрик и очень низким потреблением ресурсов.
Скорость опроса может достигать 0,1 миллисекунды при точности синхронизации между метриками 10 наносекунд. Все бинарные файлы занимают 6 мегабайт.
о проекте
У нас довольно специфический продукт. Мы производим комплексное решение по суммированию пропускной способности и отказоустойчивости каналов передачи данных.Это когда каналов несколько, допустим Оператор1 (40Мбит/с) + Оператор2 (30Мбит/с)+ Еще что-то (5 Мбит/с), в результате получается один стабильный и быстрый канал, скорость которого будет примерно такой: это: (40+ 30+5)x0,92=75x0,92=69 Мбит/с.
Подобные решения востребованы там, где недостаточно мощности какого-либо одного канала.
Например, транспорт, системы видеонаблюдения и потокового видео в реальном времени, трансляция прямых теле- и радиопередач, любые загородные объекты, где среди операторов связи только представители «большой четверки» и скорости на одном модеме/канале недостаточно.
.
Для каждого из этих направлений мы выпускаем отдельную линейку устройств, но их программная часть практически одинакова и качественная система мониторинга является одним из ее основных модулей, без правильной реализации которого создание продукта было бы невозможным.
За несколько лет нам удалось создать многоуровневую, быструю, кроссплатформенную и легкую систему мониторинга.
Это то, чем мы хотим поделиться с нашим уважаемым сообществом.
Постановка задачи
Система мониторинга предоставляет метрики двух принципиально разных классов: метрики реального времени и все остальные.К системе мониторинга предъявлялись только следующие требования:
- Высокочастотный синхронный сбор метрик в реальном времени и их передача в систему управления связью без задержек.
Высокая частота и синхронизация разных метрик не просто важны, они жизненно необходимы для анализа энтропии каналов передачи данных.
Если в одном канале передачи данных средняя задержка составляет 30 миллисекунд, то ошибка синхронизации между остальными метриками всего в одну миллисекунду приведет к ухудшению скорости результирующего канала примерно на 5%.
Если мы ошибемся во времени на 1 миллисекунду по 4 каналам, снижение скорости может легко упасть до 30%.
Кроме того, энтропия в каналах меняется очень быстро, поэтому, если мы будем измерять ее реже, чем раз в 0,5 миллисекунды, на быстрых каналах с небольшой задержкой мы получим большую деградацию скорости.
Конечно, такая точность нужна не для всех показателей и не во всех условиях.
Когда задержка в канале 500 миллисекунд, а мы работаем с такими, то ошибка в 1 миллисекунду будет почти не заметна.
Также для метрик системы жизнеобеспечения нам достаточно скорости опроса и синхронизации в 2 секунды, но сама система мониторинга должна уметь работать со сверхвысокими скоростями опроса и сверхточной синхронизацией метрик.
- Минимальное потребление ресурсов и единый стек.
Конечным устройством может быть как мощный бортовой комплекс, способный анализировать ситуацию на дороге или вести биометрическую запись людей, так и одноплатный компьютер размером с ладонь, который боец спецназа носит под бронежилетом для передачи видео в в режиме реального времени в плохих условиях связи.
Несмотря на такое разнообразие архитектур и вычислительных мощностей, нам хотелось бы иметь один и тот же программный стек.
- Зонтичная архитектура
Метрики необходимо собирать и агрегировать на конечном устройстве, хранить локально и визуализировать в режиме реального времени и ретроспективно.
Если связь есть, передайте данные в центральную систему мониторинга.
При отсутствии соединения очередь отправки должна накапливаться, а не потреблять оперативную память.
- API для интеграции в систему мониторинга заказчика, ведь много систем мониторинга никому не нужно.
Заказчик должен собрать данные с любых устройств и сетей в единый мониторинг.
Что случилось
Чтобы не утяжелять и без того впечатляющий лонгрид, я не буду приводить примеры и замеры всех систем мониторинга.Это приведет к другой статье.
Скажу лишь, что нам не удалось найти систему мониторинга, способную снимать две метрики одновременно с погрешностью менее 1 миллисекунды и работающую одинаково эффективно как на архитектуре ARM с 64 МБ ОЗУ, так и на архитектуре x86_64 с 32 МБ ОЗУ.
ГБ ОЗУ.
Поэтому мы решили написать свой, который всё это умеет. Вот что мы получили:
Суммирование пропускной способности трёх каналов для разных топологий сети
Визуализация некоторых ключевых показателей
Архитектура
Мы используем Golang в качестве основного языка программирования, как на устройстве, так и в дата-центре.Он значительно упростил жизнь благодаря реализации многозадачности и возможности получить один статически связанный исполняемый двоичный файл для каждого сервиса.
В результате мы существенно экономим ресурсы, методы и трафик для развертывания сервиса на конечных устройствах, время разработки и отладки кода.
Система реализована по классическому модульному принципу и содержит несколько подсистем:
- Регистрация метрик.
Каждая метрика обслуживается отдельным потоком и синхронизируется по каналам.
Нам удалось добиться точности синхронизации до 10 наносекунд.
- Хранение метрик
Мы выбирали между написанием собственного хранилища для временных рядов или использованием того, что уже было доступно.
База данных нужна для ретроспективных данных, подлежащих последующей визуализации.
То есть там нет данных о задержках в канале каждые 0,5 миллисекунды или показаниях ошибок в транспортной сети, но есть скорость на каждом интерфейсе каждые 500 миллисекунд. Помимо высоких требований к кроссплатформенности и низкому потреблению ресурсов, нам крайне важно уметь обрабатывать.
данные там, где они хранятся.
Это экономит огромные вычислительные ресурсы.
Мы используем СУБД Tarantool в этом проекте с 2016 года и пока не видим ей замены на горизонте.
Гибкий, с оптимальным потреблением ресурсов, более чем адекватной технической поддержкой.
В Tarantool также реализован модуль ГИС.
Конечно, он не такой мощный, как PostGIS, но для наших задач по хранению некоторых метрик, связанных с местоположением (актуальных для транспорта), вполне достаточен.
- Визуализация метрик
Здесь все относительно просто.
Мы берем данные со склада и отображаем их как в реальном времени, так и ретроспективно.
- Синхронизация данных с центральной системой мониторинга.
Система централизованного мониторинга получает данные со всех устройств, сохраняет их с заданной историей и отправляет в систему мониторинга Заказчика через API. В отличие от классических систем мониторинга, в которых «голова» ходит и собирает данные, у нас обратная схема.
Устройства сами отправляют данные при наличии соединения.
Это очень важный момент, так как он позволяет получать данные от устройства за те периоды времени, в течение которых оно было недоступно, и не загружать каналы и ресурсы, пока устройство недоступно.
В качестве центральной системы мониторинга мы используем сервер мониторинга Influx. В отличие от своих аналогов, он может импортировать ретроспективные данные (то есть с отметкой времени, отличной от момента получения метрик).
Собранные метрики визуализируются Grafana и модифицируются с помощью файла.
Этот стандартный стек был выбран еще и потому, что он имеет готовые API-интеграции практически с любой системой мониторинга клиентов.
- Синхронизация данных с центральной системой управления устройствами.
Система управления устройствами реализует Zero Touch Provisioning (обновление прошивки, конфигурации и т. д.) и, в отличие от системы мониторинга, получает только проблемы по каждому устройству.
Это триггеры работы бортовых аппаратных сторожевых служб и всех метрик систем жизнеобеспечения: температуры процессора и SSD, загрузки процессора, свободного места и работоспособности S.M.A.R.T на дисках.
Подсистема хранения также построена на Tarantool. Это дает нам значительную скорость агрегирования временных рядов по тысячам устройств, а также полностью решает вопрос синхронизации данных с этими устройствами.
Tarantool имеет отличную систему очередей и гарантированной доставки.
Мы получили эту важную функцию «из коробки», отлично!
Система управления сетью
Что дальше
Пока что наше самое слабое звено — это центральная система мониторинга.Он на 99,9% реализован на стандартном стеке и имеет ряд недостатков:
- InfluxDB теряет данные при отключении питания.
Как правило, Заказчик оперативно собирает все, что поступает с устройств и сама база данных не содержит данных старше 5 минут, но в будущем это может стать проблемой.
- У Grafana есть ряд проблем с агрегацией данных и синхронизацией их отображения.
Самая распространенная проблема — когда в базе данных есть временной ряд с интервалом в 2 секунды, начиная, скажем, с 00:00:00, а Grafana начинает показывать данные в агрегации с +1 секунды.
В результате пользователь видит танцующий график.
- Чрезмерное количество кода для интеграции API со сторонними системами мониторинга.
Его можно сделать гораздо компактнее и конечно переписать на Go)
Заключение
Я намеренно не стал описывать технические подробности, а описал лишь базовую конструкцию этой системы.Во-первых, для полного технического описания системы потребуется еще одна статья.
Во-вторых, не всем это будет интересно.
Напишите в комментариях, какие технические подробности вы хотели бы узнать.
Если у кого-то есть вопросы, выходящие за рамки этой статьи, вы можете написать мне на [email protected]. Теги: #*nix #iot #it инфраструктура #Go #tarantool #monitoring #vue.js #qedr summa
-
В Погоне За Арендой Онлайн-Игр
19 Oct, 24 -
Медли По Информационной Безопасности
19 Oct, 24 -
Прошивка 2.00 Для Ps3 Выйдет 8 Ноября
19 Oct, 24 -
Книга «Секреты Веб-Приложений Google»
19 Oct, 24
