IoT‑ландшафт редко ограничивается одной «коробкой»: датчики, контроллеры и шлюзы распределены по цеху, складу или кампусу. Для надёжной эксплуатации нужен мониторинг, который одинаково прозрачно показывает метрики «на месте» и позволяет централизованно строить дашборды, а также автоматически реагировать на аномалии.
В этой статье мы разберём практическое решение: построение распределённого мониторинга IoT‑устройств через Prometheus и Grafana, а также настройку Alertmanager — всё в окружении Termux на Android. Архитектура ориентирована на локальную сеть и удобна для стендов, пилотов и реальных объектов, где доступ к интернету ограничен или нежелателен.
Архитектура решения
Предложенная схема состоит из следующих компонентов:
- IoT‑устройства/шлюзы (или Android‑хосты в качестве агентов), где в Termux работает экспортер или сервис, отдающий метрики.
- Prometheus (сервер мониторинга), который собирает метрики со множества таргетов.
- Grafana для визуализации метрик (дашборды, панели, метки времени).
- Alertmanager для маршрутизации и агрегации алертов (уведомления, эскалации).
Ключевой принцип: все компоненты запускаются и обслуживаются в Termux. Для «распределённости» используется сеть между устройствами в локальной среде.
Требования и подготовка Termux
Вам понадобятся:
- Несколько устройств (минимум: устройство с Prometheus/Grafana/Alertmanager и устройство(а) с метриками).
- Termux на каждом Android‑устройстве.
- Доступ по IP‑адресам в локальной сети (например, одна Wi‑Fi сеть или локальная сеть через VPN для объединения устройств в один сегмент — строго для формирования локальной сети, а не для обхода ограничений).
Рекомендуется фиксировать IP (через роутер/DHCP reservations) или использовать понятные хостнеймы. На практике это снижает «дрейф» адресов и упрощает обслуживание.
Установка пакетов в Termux
На устройствах, где будет запускаться серверная часть (Prometheus/Grafana/Alertmanager), ставим зависимости и скачиваем бинарники. На устройствах‑агентах — обеспечиваем экспорт метрик.
Начнём с базовой подготовки Termux (выполняйте на каждом устройстве по необходимости):
pkg update && pkg upgrade -y
pkg install -y wget curl tar gzip jq proot-distroДалее — создание рабочих директорий:
mkdir -p ~/monitoring/{prometheus,grafana,alertmanager,configs,bin}Сетевая часть: локальная доступность
Prometheus должен «видеть» HTTP‑эндпоинты экспортёров. Поэтому важно проверить доступность портов между устройствами.
Минимальная проверка:
- на устройстве‑сервере Prometheus убедитесь, что вы можете открыть с устройства браузер/команду на адрес агента;
- на устройстве‑агенте убедитесь, что экспортёр слушает на нужном интерфейсе (или на 0.0.0.0), а не только на localhost.
Проверка доступности порта обычно выполняется через curl с сервера:
curl -s http://IP_АГЕНТА:ПОРТ/metrics | headЕсли ответ есть — можно переходить к настройкам Prometheus.
Prometheus в Termux: настройка сбора метрик
На устройстве, где будет Prometheus, скачайте бинарник Prometheus. Вариант ниже показывает общий подход. Для точного соответствия архитектуре Android часто требуется выбрать подходящую сборку. Обычно хорошо работает официальная поставка для Linux; в Termux бинарник может быть доступен в подходящем формате, но если архитектура отличается — потребуется адаптация под ваш случай.
Пример структуры конфигурации:
cd ~/monitoring/configs
nano prometheus.ymlПример prometheus.yml для распределённого мониторинга через static_configs:
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'iot-agents'
metrics_path: /metrics
scheme: http
static_configs:
- targets:
- 'IP_АГЕНТА_1:ПОРТ'
- 'IP_АГЕНТА_2:ПОРТ'
# добавляйте далееЗапуск Prometheus в Termux:
cd ~/monitoring/prometheus
# предполагаем, что бинарник prometheus лежит в ~/monitoring/bin/prometheus
~/monitoring/bin/prometheus
--config.file=~/monitoring/configs/prometheus.yml
--storage.tsdb.path=~/monitoring/prometheus/data
--web.listen-address=0.0.0.0:9090Проверка интерфейса Prometheus (с устройства в локальной сети):
curl -s http://IP_СЕРВЕРА:9090/-/healthyЕсли возвращается ok или HTTP‑статус 200 — всё успешно.
Grafana в Termux: визуализация и дашборды
Grafana обычно запускают как веб‑приложение. В Termux подход может зависеть от способа установки (бинарник/контейнер). Ниже приводится схема запуска сервера Grafana и базовая настройка источника данных.
В типовом варианте сначала загружаете Grafana‑бинарник или запускаете через подходящий runtime/сборку для Android. В рамках идеи статьи важно, чтобы Grafana слушал на порту внутри локальной сети.
Сценарий настройки порта:
# Примерная команда запуска, адаптируйте под вашу сборку grafana:
~/monitoring/bin/grafana-server
--homepath ~/monitoring/grafana
--config ~/monitoring/grafana/conf/grafana.ini
&В grafana.ini проверьте параметры:
http_addr = 0.0.0.0
http_port = 3000Далее в браузере на любом устройстве локальной сети откройте:
http://IP_СЕРВЕРА:3000После входа (по умолчанию логин/пароль задаются в конфигурации/дистрибутиве) добавьте источник данных:
- Data source: Prometheus
- URL:
http://IP_СЕРВЕРА:9090 - Сохранить и проверить
Дальше создавайте дашборды: графики по CPU/температуре/влажности/энергопотреблению — в зависимости от того, какие метрики вы экспортируете.
Alertmanager в Termux: маршрутизация и правила алертов
Alertmanager нужен для нормальной эксплуатации: он группирует алерты, снижает шум и управляет доставкой уведомлений.
Создайте конфигурацию:
cd ~/monitoring/configs
nano alertmanager.ymlПример базового alertmanager.yml:
global:
resolve_timeout: 5m
route:
receiver: 'local-notifier'
group_by: ['alertname', 'job']
group_wait: 30s
group_interval: 5m
repeat_interval: 3h
receivers:
- name: 'local-notifier'
# В зависимости от вашей модели уведомлений добавляйте:
# - email_configs
# - webhook_configs
# - или другие поддерживаемые механизмы
webhook_configs:
- url: 'http://IP_СЕРВЕРА:порт_вашего_шлюза' # примерВажно: при настройке уведомлений используйте механизмы, соответствующие вашей инфраструктуре (локальная обработка, вебхуки на внутренний сервис). Если у вас нет внешней инфраструктуры — проще поднять внутренний «уведомлятор» в локальной сети или использовать локальные действия.
Запуск Alertmanager:
cd ~/monitoring/alertmanager
~/monitoring/bin/alertmanager
--config.file=~/monitoring/configs/alertmanager.yml
--storage.path=~/monitoring/alertmanager/data
--web.listen-address=0.0.0.0:9093Проверка:
curl -s http://IP_СЕРВЕРА:9093/#/statusСвязка Prometheus ↔ Alertmanager: alerting в prometheus.yml
Чтобы Prometheus отправлял алерты в Alertmanager, добавьте секции alerting.
Пример фрагмента prometheus.yml (вставьте в конфиг):
alerting:
alertmanagers:
- static_configs:
- targets:
- 'IP_СЕРВЕРА:9093'Затем добавьте правила алертов. Обычно они хранятся в директории rule_files. Например:
rule_files:
- 'configs/alerts.yml'Пример alerts.yml:
groups:
- name: iot.rules
rules:
- alert: HighTemperature
expr: iot_temperature_celsius > 60
for: 2m
labels:
severity: critical
annotations:
summary: "Высокая температура на {{ $labels.device }}"
description: "Значение {{ $value }} °C превышает порог 60 °C."После изменения конфигов перезапустите Prometheus или перезагрузите конфигурацию (зависит от способа запуска и настроек).
Экспортеры для IoT: как отдавать метрики в формате Prometheus
Для распределённого мониторинга каждому агенту требуется отдавать HTTP‑эндпоинт /metrics с метриками в формате Prometheus. В контексте Termux это может быть реализовано:
- скриптом, который периодически собирает данные (например, из датчиков, логов, пингов, веб‑запросов);
- небольшим локальным сервисом, формирующим метрики;
- адаптером под ваш IoT‑шлюз.
Практический минимум: HTTP‑сервер в Termux, который возвращает текст метрик. Формат должен быть совместим с Prometheus.
Пример «скелета» на уровне идеи (конкретная реализация зависит от языка/скрипта, который вы выберете):
# Вариант: сервис слушает на 0.0.0.0:ПОРТ и возвращает /metrics
# /metrics:
# iot_temperature_celsius{device="sensor-1"} 42.3
# iot_humidity_percent{device="sensor-1"} 18.9Если вы используете существующий экспортер (например, для системных показателей Android), убедитесь, что он слушает внешний интерфейс и корректно выставляет порты.
Работа с доступом и безопасностью внутри локальной сети
При размещении Prometheus/Grafana/Alertmanager в локальной сети не забывайте о базовой гигиене:
- используйте минимально необходимые порты;
- закрепляйте правила доступа на Wi‑Fi роутере (по возможности);
- не открывайте веб‑интерфейсы наружу без необходимости;
- учитывайте, что Prometheus/Grafana — это веб‑сервисы: доступ должен быть доверенным.
Если вам нужен единый сегмент между устройствами через VPN, применяйте его только для создания локальной сети между хостами (для адресуемости), а не для обхода ограничений.
Тестирование и типовые проверки
Перед запуском на «боевом» стенде сделайте короткий чек‑лист:
- Проверка метрик: с сервера Prometheus выполните
curlна/metricsкаждого агента. - Проверка scraping: откройте
http://IP_СЕРВЕРА:9090/targetsи убедитесь, что статусы UP. - Проверка дашбордов: создайте временную панель с одной метрикой и проверьте обновления.
- Проверка алертов: вручную проверьте правила в разделе Prometheus / Alerts (или через временное изменение метрик).
Заключение
Распределённый мониторинг IoT в Termux через Prometheus и Grafana, дополненный Alertmanager, позволяет получить контролируемую, расширяемую и наглядную систему наблюдения — при этом все компоненты запускаются и администрируются в рамках Android Termux. Правильная сетевая адресация внутри локальной сети, единый формат метрик и грамотно настроенные правила алертов превращают стенд в полезный инструмент эксплуатации.
Хотите собрать такую систему под ваш сценарий (количество устройств, тип метрик, схема алертинга и уведомлений)? Обратитесь в РыбинскЛАБ — мы поможем спроектировать архитектуру, развернуть компоненты в Termux и настроить мониторинг и алерты под ваши IoT‑задачи.