Построение распределённой системы сбора телеметрии на базе MQTT‑брокеров, работающих в Termux

Ведущий эксперт РыбинскЛАБ рассказывает, как построить практичную распределённую систему сбора телеметрии на базе MQTT‑брокеров, работающих в Termux. MQTT — лёгкий протокол обмена сообщениями «издатель‑подписчик», который удобно применять для телеметрии датчиков, событий, логов телеметрических устройств и систем мониторинга. В связке с Termux вы получаете гибкую инфраструктуру для прототипов и локальных стендов: телефоны, мини‑ПК, серверные Android‑устройства, а также полевые узлы.

Концепция системы и базовая топология

Распределённая система телеметрии обычно состоит из трёх логических частей:

Узлы‑издатели (publishers): устройства или приложения, которые публикуют телеметрию в MQTT.
MQTT‑брокер(ы): центральная (или иерархическая) точка маршрутизации сообщений.
Узлы‑подписчики (subscribers): сборщики/агрегаторы, сервисы хранения, визуализация, обработчики.

Для распределённости брокер(ов) можно сделать несколько: например, один брокер на «локальном контуре» и второй — на «контуре агрегации», а также использовать мосты между брокерами (MQTT bridging) или правила маршрутизации на уровне клиентов.

Важный принцип проектирования: разделяйте ответственность. Брокер не должен превращаться в «всё сразу»: лучше направлять сообщения в пайплайн обработки и хранения, а брокеру оставить транспорт.

Выбор MQTT‑брокера для Termux

Для Termux чаще всего выбирают легковесные брокеры, которые можно запустить в пользовательском окружении. На практике популярны подходы через:

mosquitto (часто применяется для MQTT‑брокера, удобен для настройки и совместим со стандартным клиентским стеком),
или альтернативы в зависимости от доступности пакетов в конкретной среде сборок.

Ниже описан типовой сценарий с mosquitto как распространённым вариантом. Если у вас другой брокер — логика топик‑структуры, QoS и безопасности остаётся той же.

Подготовка Termux и сетевого режима

Для стабильной работы важны 3 момента: репозитории, корректная DNS/сеть и фиксированный сценарий адресации. Вариант для локальной сети (рекомендуется для стендов): организуйте локальную сеть (например, через Wi‑Fi и корректные настройки доступности), чтобы клиенты и брокеры видели друг друга.

Установите базовые пакеты:

pkg update
pkg upgrade
pkg install mosquitto mosquitto-clients

Проверьте, что брокер реально запускается:

mosquitto -v

Если команда требует конфигурацию, используйте отдельный конфиг (см. дальше). В зависимости от версии mosquitto и окружения Termux могут отличаться пути конфигурационных файлов.

Конфигурация MQTT‑брокера (mosquitto) в Termux

Создайте конфигурационный файл. Типовой подход: задайте порт, настройте логирование и (при необходимости) аутентификацию.

Пример минимального конфига для локального запуска (адаптируйте пути под вашу систему):

mkdir -p $HOME/mqtt
cat > $HOME/mqtt/mosquitto.conf << 'EOF'
listener 1883
allow_anonymous true
persistence false
log_dest stdout
EOF

Запуск брокера:

mosquitto -c $HOME/mqtt/mosquitto.conf

На ранней стадии можно использовать allow_anonymous true только для отладки в закрытой локальной среде. Для промышленного/полевого применения включайте аутентификацию и шифрование там, где это возможно в вашей инфраструктуре.

Структура топиков для телеметрии

Успех MQTT‑системы во многом определяется топиками. Практичный шаблон для телеметрии:

tenant или site (опционально)
device (идентификатор устройства)
metric (тип метрики)
context (опционально: версия, агрегатор, тип события)

Пример: telemetry/<site>/<deviceId>/<metric>

Примеры топиков:

telemetry/rybinsk/lamp-01/temperature
telemetry/rybinsk/lamp-01/humidity
events/rybinsk/lamp-01/status

Если вам нужна команда управления (особенно в системе IoT), используйте отдельное пространство топиков, например: control/<site>/<deviceId>/command. Это упрощает права доступа и снижает риск путаницы.

Издатель телеметрии в Termux: publish

Для экспериментов используйте CLI‑клиенты mosquitto. Например, опубликуйте данные датчика в выбранный топик:

mosquitto_pub -h <IP_брокера> -p 1883 -t "telemetry/rybinsk/lamp-01/temperature" -m "24.7"

Если вы публикуете JSON‑телеметрию, задавайте полезную нагрузку как строку JSON:

mosquitto_pub -h <IP_брокера> -p 1883 -t "telemetry/rybinsk/lamp-01" \
  -m '{"ts":'"$(date +%s)'" ,"temperature":24.7,"humidity":41.2}'

Рекомендация: всегда включайте временную метку (ts) либо в полезной нагрузке, либо через topic/context. Это критично для аналитики и корреляции событий.

Подписчик и сохранение телеметрии

Для чтения сообщений используйте mosquitto_sub. Простейший сборщик — сохранить сообщения в файл для последующей обработки:

mkdir -p $HOME/mqtt/data
mosquitto_sub -h <IP_брокера> -p 1883 \
  -t "telemetry/rybinsk/+/+" \
  -v > $HOME/mqtt/data/telemetry.log

Варианты улучшения:

Отдельные подписки на «сырые» данные и «агрегированные» (например, интервалами по минутам).
Нормализация формата (фиксированная структура JSON).
Проверка целостности и обработка повторов (если QoS > 0).

Распределённость: несколько брокеров и межконтурная маршрутизация

Для распределённой системы вы можете организовать несколько брокеров:

Брокер‑контур на каждом сегменте (например, одна точка на этаж/цех/район).
Агрегирующий брокер в центре мониторинга.

Далее возможны две практичные стратегии:

Мосты между брокерами (bridging): брокеры реплицируют выбранные топики.
Агрегатор как клиент: отдельный подписчик пересылает сообщения в другой брокер.

Стратегию «клиент‑агрегатор» проще внедрять в Termux: сервис‑подписчик получает сообщения с брокера A и публикует их в брокер B, сохраняя необходимую структуру топиков.

Принцип выбора: мосты удобны, если хотите минимизировать код. Агрегатор‑клиент удобнее, если вы делаете преобразование форматов, фильтрацию и обогащение данных.

QoS, retained и устойчивость к потерям

Для телеметрии важно понимать уровни QoS:

QoS 0: «как есть», без гарантий доставки. Подходит для не критичных данных, где важна скорость.
QoS 1: минимум один раз. Возможны дубликаты.
QoS 2: ровно один раз. Обычно тяжелее и сложнее, редко нужен для простых задач.

Также используйте retained messages там, где это уместно: например, статус устройства (status) или последняя известная конфигурация. Для ретейна ограничивайте размер сообщения и не злоупотребляйте — иначе брокер начнёт хранить слишком много «последних значений».

Безопасность в локальной сети

Для реальных проектов в закрытой локальной среде рекомендуется:

Включать аутентификацию (учётные записи/пароли).
Изолировать сегменты сети (по VLAN/подсетям).
Ограничивать, какие топики разрешены для подписки/публикации (ACL).

Если аутентификация недоступна в вашем минимальном прототипе, хотя бы обеспечьте сегментацию сети и физическую/логическую изоляцию. Это особенно актуально, если брокер доступен за пределами вашей «локальной сети».

Практический сценарий: стенд «датчик → брокер → хранилище»

Ниже — типовой порядок действий, который удобно воспроизводить:

На узле A (Termux) запустите брокер.
На узле B запустите издатель: публикуйте телеметрию в топики.
На узле C запустите подписчик и сохраняйте данные в файл/очередь.
Проверьте, что сообщения приходят с ожидаемой частотой и в корректном формате.

Проверка публикации через подписчик:

mosquitto_sub -h <IP_брокера> -p 1883 -t "telemetry/rybinsk/lamp-01/temperature" -v

И публикация с другого Termux‑узла:

mosquitto_pub -h <IP_брокера> -p 1883 -t "telemetry/rybinsk/lamp-01/temperature" -m "25.1" -q 0

После отладки добавляйте QoS и обработку ошибок по ситуации.

Производительность и эксплуатация

Для эксплуатационной надёжности продумайте:

Частоту публикаций: слишком частые сообщения увеличивают нагрузку на сеть, CPU и хранилище.
Буферизацию у подписчика: если хранение медленнее, чем приход сообщений, добавьте очередь или пакетную запись.
Логи и метрики: фиксируйте количество сообщений, задержки и ошибки.
Перезапуски: планируйте сценарии восстановления брокера и клиентов после падений.

Для корректной работы в Termux также следите за ограничениями мобильной платформы: фоновые ограничения, энергосбережение и ограничения доступа к сети могут влиять на устойчивость.

Куда «приземлять» данные: от логов к аналитике

На первом этапе удобно сохранять сообщения в файлы (как показано выше). Затем, когда схема стабилизируется, переходите к более управляемому хранилищу:

логирование в structured формате (JSONL),
пакетная запись в БД/временные ряды (если применимо),
агрегация на стороне подписчика (например, усреднение/минимум/максимум по интервалам).

Ключевой момент: брокер — не склад для аналитики, а транспорт. Хранение и обработку вынесите в отдельный сервис.

Заключение

Построение распределённой системы сбора телеметрии на базе MQTT‑брокеров в Termux — это быстрый и практичный путь к локальным стендам и прототипам мониторинга. Правильно подобранные топики, грамотные QoS/retained настройки, изоляция локальной сети и разделение ролей (издатели, брокер, подписчики/хранилище) дают предсказуемое поведение и упрощают поддержку.

Если вы хотите спроектировать архитектуру под ваши устройства, частоту телеметрии, требования к надёжности и формат данных, команда РыбинскЛАБ поможет с внедрением, настройкой MQTT‑инфраструктуры, интеграцией клиентов и настройкой отказоустойчивости.