Настройка системы мониторинга и логирования (Prometheus + Grafana) в Termux для отслеживания производительности мобильных скриптов и сервисов

Termux — удобная среда для запуска мобильных скриптов, фоновых задач и небольших сервисов прямо на Android-устройстве. Но когда скрипты начинают «жить своей жизнью», возникает потребность в контроле: как меняется потребление CPU и памяти, каков поток запросов, где именно происходят ошибки, как выглядит время выполнения задач и общее состояние системы.

В этой статье мы рассмотрим практический способ организовать мониторинг производительности и базовое логирование с использованием Prometheus и Grafana вместе с Termux. Цель — получить метрики в реальном времени и визуализировать их в дашбордах, а также выстроить удобный поток наблюдаемости для мобильных сервисов.

Рекомендация по архитектуре: Prometheus и Grafana обычно проще запускать на отдельной машине/сервере. При этом Termux выступает как источник метрик, отдавая их в формате Prometheus через HTTP-экспортер (или через встроенный endpoint ваших скриптов).

Как это работает (концепция)

Схема наблюдаемости выглядит так:

Termux — выполняет ваши скрипты/сервисы и отдает метрики (обычно по HTTP).
Prometheus — периодически опрашивает endpoint(ы) Termux и собирает метрики.
Grafana — читает метрики из Prometheus и строит дашборды, алерты и графики.

Логирование при этом можно организовать отдельно (через file/журнал и внешние инструменты). Однако даже если вы планируете хранить логи отдельно, метрики дадут быструю картину: «что именно ухудшилось и когда».

Подготовка окружения в Termux

Начнем с базовой подготовки. Далее мы установим необходимые пакеты, создадим пользователя/директорию под мониторинг и настроим доступность endpoint для Prometheus.

Обновите пакеты в Termux:

pkg update && pkg upgrade -y

Установите базовые инструменты. Набор ниже покрывает большинство сценариев (HTTP, Python, системные метрики):

pkg install -y wget curl tar proot openssh python clang git

Если планируете собирать системные метрики и/или реализовывать экспортер на Python, убедитесь, что Python доступен. Для удобства можно создать виртуальную среду:

python -m venv ~/venv-monitor

source ~/venv-monitor/bin/activate

Далее установим библиотеку для формата Prometheus. В большинстве случаев подойдет клиентская библиотека:

pip install --no-cache-dir prometheus-client psutil

Настройка экспортера метрик в Termux

Самый практичный путь: поднять небольшой HTTP-сервис в Termux, который отдает метрики в формате Prometheus. Этот сервис можно написать на Python через prometheus_client и psutil.

Создадим скрипт, который будет отдавать метрики по адресу /metrics. Для примера соберем CPU/память процесса/системы и счетчики выполнения задач.

Создайте файл:

mkdir -p ~/monitoring/exporters

nano ~/monitoring/exporters/termux_exporter.py

Содержимое (пример, который можно адаптировать под ваши сервисы):

from http.server import BaseHTTPRequestHandler, HTTPServer
import threading
import time

import psutil
from prometheus_client import Counter, Gauge, CollectorRegistry, generate_latest

registry = CollectorRegistry(auto_describe=True)

# Пример метрик: счетчик запусков задач и ошибок
task_runs_total = Counter('task_runs_total', 'Total task runs', registry=registry)
task_errors_total = Counter('task_errors_total', 'Total task errors', registry=registry)

# Пример системных метрик
cpu_percent = Gauge('system_cpu_percent', 'System CPU usage percent', registry=registry)
mem_used_mb = Gauge('system_mem_used_mb', 'Used memory in MB', registry=registry)
load_avg_1m = Gauge('system_loadavg_1m', 'Load average (1 minute)', registry=registry)

class MetricsHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path != '/metrics':
            self.send_response(404)
            self.end_headers()
            return
        data = generate_latest(registry)
        self.send_response(200)
        self.send_header('Content-Type', 'text/plain; version=0.0.4; charset=utf-8')
        self.send_header('Content-Length', str(len(data)))
        self.end_headers()
        self.wfile.write(data)

def metrics_updater():
    while True:
        try:
            cpu = psutil.cpu_percent(interval=1)
            vm = psutil.virtual_memory()
            cpu_percent.set(cpu)
            mem_used_mb.set(vm.used / (1024 * 1024))
            # psutil может не иметь loadavg на некоторых платформах; обработаем аккуратно
            try:
                la = psutil.getloadavg()
                load_avg_1m.set(la[0])
            except Exception:
                pass
        except Exception:
            # Если нужно — добавьте собственный счетчик ошибок
            pass
        time.sleep(2)

def run():
    server = HTTPServer(('0.0.0.0', 9108), MetricsHandler)
    t = threading.Thread(target=metrics_updater, daemon=True)
    t.start()
    print('Exporter started on :9108/metrics')
    server.serve_forever()

if name == 'main':
    run()

Запуск:

python ~/monitoring/exporters/termux_exporter.py

Проверьте доступность endpoint внутри Termux (или с того же устройства):

curl -s http://127.0.0.1:9108/metrics | head

Если вы планируете, чтобы Prometheus с другой машины опрашивал Termux, потребуется обеспечить сетевую доступность. На практике чаще всего удобно сделать так:

Запуск Prometheus и Grafana на локальной сети (ваш ПК/сервер и Android в одной сети).
Убедиться, что firewall/сеть не блокирует входящие подключения на порт 9108.

Если вам нужно создать локальную сеть для связки устройств, можно организовать ее через VPN-сервис, но только для удобства локального взаимодействия (без задач обхода блокировок). Важно соблюдать политики сети и доступ к портам.

Настройка Prometheus

Prometheus должен иметь конфигурацию scrape_configs, где указан ваш endpoint Termux.

Предположим, что Prometheus запущен на вашем ПК/сервере, а Termux доступен по IP в локальной сети, например 192.168.1.50. Тогда создайте/отредактируйте конфиг Prometheus prometheus.yml.

Пример prometheus.yml (фрагмент):

global:
  scrape_interval: 5s

scrape_configs:
  - job_name: 'termux'
    metrics_path: /metrics
    scheme: http
    static_configs:
      - targets: ['192.168.1.50:9108']

После изменения перезапустите Prometheus (как именно — зависит от вашего способа установки).

Проверьте, что Prometheus успешно опрашивает target: откройте веб-интерфейс Prometheus и смотрите статус /targets.

Установка и настройка Grafana

Grafana нужна для визуализации. После запуска Grafana:

Добавьте Data Source: Prometheus.
Укажите URL вашего Prometheus (например, http://localhost:9090 или адрес сервера).
Сохраните настройки.

Далее можно создать дашборд. В Grafana откройте раздел Dashboards и создайте новый. Метрики будут видны в окне Metrics (например, system_cpu_percent, system_mem_used_mb и т.п.).

Пример дашбордов: что мониторить

Для мобильных скриптов и сервисов особенно полезны следующие группы метрик:

Системная нагрузка: CPU, память, (по возможности) load average.
Метрики ваших задач: счетчики запусков/ошибок, длительности выполнения (если добавите гистограммы/таймеры).
Работоспособность сервиса: например, раз в N секунд обновляемый gauge «живости» (health).

Если вы расширите экспортёр, можно добавить:

Гистограммы времени выполнения (например, длительность скачивания/обработки данных).
Количество активных задач.
Статус внешних зависимостей (успех/ошибка API-отдачи) — через счетчики.

Логирование в связке с мониторингом

Метрики показывают «что происходит», а логи — «почему». На практике для Termux удобно:

Писать логи приложения в файл в ~/monitoring/logs.
Регулярно проверять размер логов и ротацию.
При необходимости — отправлять логи в отдельную систему (это уже отдельная тема, но логика подготовки такая же).

Пример базового подхода к логам для вашего сервиса:

mkdir -p ~/monitoring/logs

nano ~/monitoring/exporters/termux_exporter_with_logs.py

Вместо полного переписывания покажем идею: логируйте ошибки и ключевые события (а метрики — в /metrics). Например, используйте стандартный logging и при исключениях увеличивайте task_errors_total.

Даже без сложной интеграции, связка «метрика + лог» дает быстрый анализ инцидентов: сначала по Grafana видно деградацию/скачок ошибок, затем вы открываете соответствующий период в логах.

Сценарии применения для мобильных сервисов и скриптов

Ниже — типовые сценарии, где мониторинг особенно окупается:

Периодические фоновые задачи: парсинг, синхронизация, обработка очередей. Мониторинг показывает рост времени выполнения и ошибки.
Сервисные endpoints: небольшой API на Termux. Метрики помогают отличить сетевые сбои от проблем логики.
Тяжелые вычисления: распознавание, сжатие, обработка данных. CPU/память сразу отражают «узкое горлышко».
Интеграции: запросы к внешним API. Добавьте счетчики успехов/ошибок, и вы получите быстрый коридор качества.

Практики надежной эксплуатации

Чтобы система не развалилась на практике, придерживайтесь следующих правил:

Таймауты и обработка ошибок в exporter/скриптах. Если сбор метрик завис — Grafana начнет показывать «пропуски».
Контроль частоты обновления метрик: слишком частый сбор может сам стать нагрузкой.
Ротация логов: ограничивайте рост файлов.
Автозапуск (в рамках возможностей Android/Termux): учитывайте, что мобильная ОС может ограничивать фоновые процессы.

Тюнинг: добавляем пользовательские метрики под ваши задачи

Если вы уже запускаете в Termux свои скрипты, удобно обогатить экспортёр так, чтобы он «знал» о вашей работе. Типовой паттерн:

Вынести метрики в общий модуль.
В ваших задачах увеличивать Counter на успешные/ошибочные исходы.
Добавить Histogram для времени выполнения критичных операций.

Например, для обертки функции выполнения задачи можно добавить счетчик и время выполнения (конкретный код зависит от вашей структуры, но общий принцип — использовать метрики Prometheus-клиента).

Заключение

Настройка Prometheus + Grafana в сочетании с Termux позволяет превратить «на глаз» работающие мобильные скрипты и сервисы в управляемую систему наблюдаемости: вы получаете метрики в реальном времени, строите дашборды и быстро локализуете деградации через связку «метрики + логи». Это особенно важно, когда задачи становятся регулярными, нагрузочными и критичными для результата.

Если хотите, чтобы мы помогли с подбором архитектуры (где запускать Prometheus/Grafana, как организовать exporter, как правильно оформить метрики и дашборды под ваши скрипты), обращайтесь в РыбинскЛАБ — мы выполняем внедрение и настройку мониторинга на практике.