Суммирование скорости на 16-ти модемах 4-х сотовых операторов. Исходящая скорость в один поток — 933.45 Мбит/с  Привет! Это статья про то, как мы написали для себя новую систему мониторинга. От существующих она отличается возможностью высокочастотного синхронного получения метрик и очень маленьким потреблением ресурсов. Частота опроса может достигать 0.1 миллисекунды с точностью синхронизации между метриками в 10 наносекунд. Все бинарные файлы занимают 6 мегабайт.  У нас довольно специфичный продукт. Мы производим комплексное решение для суммирования пропускной способности и отказоустойчивости каналов передачи данных. Это когда есть несколько каналов, допустим Оператор1 (40Мбит/с) + Оператор2 (30Мбит/с)+ Что-то еще(5 Мбит/с), в результате получается один стабильный и быстрый канал, скорость которого будет примерно такой: (40+30+5)x0.92=75x0.92=69 Мбит/с.  Такие решения востребованы там, где емкость любого одного канала недостаточна. Например транспорт, системы видео-наблюдения и потоковой видео-трансляции в реальном времени, трансляция прямых теле- радио- эфиров, любые загородные объекты где из операторов связи есть только представители большой четверки и скорости на одном модеме/канале недостаточно.
Для каждого из этих направлений мы выпускаем отдельную линейку устройств, однако программная их часть почти одинаковая и качественная система мониторинга — один из главных ее модулей, без правильной реализации которого продукт был бы невозможен. За несколько лет, нам удалось создать многоуровневую быструю, кроссплатформенную и легковесную систему мониторинга. Чем и хотим поделиться с уважаемым сообществом. Система мониторинга обеспечивает получение метрик двух принципиально разных классов: метрики реального времени и все остальные. К системе мониторинга было всего следующие требования: Чтобы на нагружать и без того внушительный лонгрид, я не буду приводить примеры и измерения всех систем мониторинга. Это потянет еще на одну статью. Просто скажу, что нам не удалось найти систему мониторинга, которая способна взять две метрики одновременно с погрешностью менее 1 миллисекунды и которая одинаково эффективно работает как на ARM архитектуре с 64Мбайт ОЗУ так и на х86_64 архитектуре с 32 Гбайт ОЗУ. Поэтому мы решили написать свою, которая умеет вот это вот все. Вот что у нас получилось: В качестве основного языка программирования, как на устройстве так и в ЦОДе, мы используем Golang. Он значительно упростил жизнь своей реализацией многозадачности и возможностью получить один статически слинкованный исполняемый бинарный файл для каждого сервиса. В результате мы значительно экономим в ресурсах, способах и трафике деплоя сервиса на конечные устройства, времени разработки и отладки кода.  Система реализована по классическому модульному принципу и содержит в себе несколько подсистем: Пока самым слабым звеном у нас является центральная система мониторинга. Она реализована на 99.9% на стандартном стеке и у нее есть ряд недостатков: Полагаю все вы прекрасно видели как выглядит Grafana и без меня знаете ее проблемы, поэтому не буду перегружать пост картинками. Я сознательно не стал описывать технические детали, а описал лишь опорный дизайн этой системы. Во первых, чтобы технически полно описать систему потребуется еще одна статья. Во вторых, далеко не всем будет это интересно. Напишите в комментариях какие технические детали вам хотелось бы узнать.  Если у кого-то возникнут вопросы за пределами этой статьи, мне можно писать на адрес a.rodin @ qedr.com Внимание! Продукт не продается.
Все существующие каналы продаж решения, под маркой QEDR, а также элементы визуализации принципиальных схем и пользовательских интерфейсов — банальное воровство и не имеют ко мне никакого отношения. «Знатный балалаечник» ©