Требования агента

В этом документе описаны системные требования для запуска агента мониторинга StatusRadar.

Минимальные системные требования

Операционная система

Установщик автоматически определяет ваш менеджер пакетов (apt, dnf, yum, zypper, pacman или apk) и устанавливает зависимости соответствующим образом. Поддерживается любой современный дистрибутив Linux, который поставляется с одним из них.

Поддерживается (полная автоматическая установка + systemd-сервис):

Частичная поддержка:

• Alpine Linux (apk): сам агент работает нормально, но настройка сервиса выполняется вручную — Alpine использует OpenRC, а автоматическая установка systemd-сервиса пока недоступна. Установщику также требуется bash, поэтому сначала установите его:

  apk add bash

  После установки агента запустите его под своей системой инициализации (OpenRC) или напрямую. Ручную команду см. в разделе Установка.

Не поддерживается:

• Windows
• macOS
• Варианты BSD (FreeBSD, OpenBSD)
• Дистрибутивы Linux, снятые с поддержки (EOL)

Требования к оборудованию

Минимальная конфигурация (только базовый мониторинг)

• CPU: 1 ядро @ 1.0 ГГц
• RAM: 256 МБ доступно
• Диск: 100 МБ свободного места
• Сеть: 10 Кбит/с устойчивой полосы пропускания

Рекомендуемая конфигурация (production-использование)

• CPU: 1 ядро @ 2.0 ГГц или быстрее
• RAM: 512 МБ доступно
• Диск: 500 МБ свободного места
• Сеть: 100 Кбит/с устойчивой полосы пропускания

Конфигурация для высокой нагрузки (много включённых плагинов)

• CPU: 2 ядра @ 2.0 ГГц
• RAM: 1 ГБ доступно
• Диск: 1 ГБ свободного места
• Сеть: 1 Мбит/с устойчивой полосы пропускания

Программные зависимости

Обязательно:

• Python 3.6 или новее
• systemd (для автоматического управления сервисом; необязательно на Alpine/OpenRC)

Пакеты Python (устанавливаются установщиком автоматически):

• psutil — сбор системных метрик (CPU, память, диск, сеть)
• requests — HTTP-клиент для связи с API

Установщик предпочитает пакеты дистрибутива (например, python3-psutil, python3-requests; py3-* на Alpine, python-* на Arch), затем переходит к pip, а затем — к виртуальному окружению в /opt/statusradar/venv, если системный Python управляется извне (PEP 668).

Необязательно (только когда включён соответствующий плагин):

• redis — плагин Redis
• docker — плагин Docker

Остальные плагины (MySQL, PostgreSQL, MongoDB, Nginx, Apache, PHP-FPM, Memcached, RabbitMQ, Elasticsearch, Meilisearch, Varnish, HAProxy, VictoriaMetrics, mdadm) используют стандартную библиотеку или requests либо читают системные файлы напрямую и не требуют дополнительных пакетов Python.

Потребление ресурсов

Базовый агент (без плагинов)

Типичное потребление ресурсов:

• CPU: 0.1–0.5% (в простое) до 5–10% (во время сбора)
• Память: 30–50 МБ RSS
• Дисковый ввод-вывод: < 1 МБ/мин (логи и состояние)
• Сеть: 2–5 КБ/мин

Влияние сбора метрик:

• Интервал сбора: 5 минут (по умолчанию, INTERVAL=300; минимум 60 секунд)
• Длительность сбора: 1–3 секунды
• Размер полезной нагрузки: ~2 КБ на отчёт

Потребление ресурсов по плагинам

Примеры конфигураций

Веб-сервер (Nginx + PHP-FPM + Redis + MySQL)

• Всего памяти: ~120 МБ
• Загрузка CPU: 10–15% во время сбора, < 1% в простое
• Сеть: ~10 КБ/мин
• Диск: < 2 МБ/мин

Сервер базы данных (PostgreSQL + Redis)

• Всего памяти: ~100 МБ
• Загрузка CPU: 8–12% во время сбора
• Сеть: ~8 КБ/мин

Хост контейнеров (Docker с 20 контейнерами)

• Всего памяти: ~150 МБ
• Загрузка CPU: 15–20% во время сбора
• Сеть: ~15 КБ/мин

Сетевые требования

Исходящая связь

Обязательно:

• HTTPS (порт 443) к api.statusradar.dev
• Протокол: HTTPS с TLS 1.2 или новее
• Firewall: исходящий HTTPS должен быть разрешён

Полоса пропускания:

• Минимум: 10 Кбит/с устойчиво
• Рекомендуется: 100 Кбит/с устойчиво
• Пик: до 1 Мбит/с во время сбора метрик

Требования DNS

Необходимое разрешение DNS:

• api.statusradar.dev → разрешается в сервер API
• statusradar.dev → разрешается в веб-интерфейс

DNS-серверы:

• Используйте любой публичный или частный DNS-сервер
• Для надёжности рекомендуется Google DNS (8.8.8.8, 8.8.4.4)

Поддержка прокси

HTTP/HTTPS-прокси: Агент поддерживает HTTP-прокси через переменные окружения:

export HTTP_PROXY="http://proxy.example.com:8080"
export HTTPS_PROXY="http://proxy.example.com:8080"
export NO_PROXY="localhost,127.0.0.1"

Прокси с аутентификацией:

export HTTPS_PROXY="http://user:[email protected]:8080"

Требования к дисковому пространству

Установка

• Код агента: 5–10 МБ
• Зависимости Python: 50–100 МБ
• Конфигурация: < 1 МБ
• Всего на установку: ~100 МБ (/opt/statusradar)

Во время работы

• Логи: 1–10 МБ/день (/var/log/statusradar/agent.log, в зависимости от детализации)
• Кеш: < 1 МБ
• Файлы состояния: < 1 МБ
• Всего во время работы: 10–50 МБ/неделю

Ротация логов

• На systemd >= 240 агент пишет напрямую в /var/log/statusradar/agent.log — ротируйте его с помощью logrotate.
• На более старом systemd вывод идёт в журнал — настройте срок хранения через /etc/systemd/journald.conf.

Влияние на производительность

Нагрузка на систему

Влияние на CPU:

• Сбор выполняется каждые 5 минут (по умолчанию)
• Каждый сбор занимает 1–5 секунд
• Всплеск CPU во время сбора: 5–20%
• Загрузка CPU в простое: < 0.5%

Влияние на память:

• Resident Set Size (RSS): 50–200 МБ в зависимости от плагинов
• Виртуальная память (VSZ): 100–500 МБ
• Без утечек памяти (протестировано при 30+ днях непрерывной работы)

Влияние на дисковый ввод-вывод:

• Чтение: < 100 КБ/сбор (чтение статистики сервисов)
• Запись: < 50 КБ/сбор (логи и кеш)
• Без устойчивой нагрузки на ввод-вывод

Влияние конкретных плагинов

Плагины баз данных (MySQL, PostgreSQL, MongoDB):

• Выполняют запросы мониторинга (например, SHOW STATUS, SELECT pg_stat_database)
• Запросы используют индексы и доступны только для чтения
• Пренебрежимо малое влияние на производительность базы данных
• Рекомендуется: создать выделенного пользователя мониторинга только для чтения

Плагины веб-серверов (Nginx, Apache):

• Опрашивают эндпоинты статуса (например, /nginx_status, /server-status)
• Нулевое влияние — эндпоинты статуса оптимизированы для мониторинга
• Без накладных расходов на логирование (access_log отключён на эндпоинтах статуса)

Плагин контейнеров (Docker):

• Запрашивает у Docker API статистику контейнеров
• Более высокое потребление CPU/памяти при большом числе контейнеров
• Влияние растёт линейно с числом контейнеров
• Рекомендация: ограничьтесь 50 контейнерами или скорректируйте интервал сбора

Масштабируемость

Ограничения одного сервера

Поддерживаемый масштаб:

• Отслеживаемых сервисов: до 16 плагинов одновременно
• Контейнеров Docker: до 100 контейнеров
• Интервал сбора: минимум 60 секунд
• Время работы: протестировано при месяцах непрерывной работы

Развёртывания на нескольких серверах

Один агент на сервер:

• Каждый сервер запускает собственный инстанс агента
• Агенты независимо отправляют данные в API
• Связь между серверами не требуется

Планирование ресурсов:

Total Memory = Base (50 MB) + (Plugins × 15 MB avg)
Total CPU = Base (0.5%) + (Plugins × 2% avg)

Пример:

• 100 серверов × 100 МБ в среднем = 10 ГБ суммарно по всему парку
• Пренебрежимо мало по сравнению с отслеживаемыми сервисами

Замечания по платформам

Установщик автоматически определяет ваш менеджер пакетов, поэтому в большинстве случаев устанавливать Python вручную не нужно. Команды ниже нужны только в случае, если Python или bash отсутствует.

Debian / Ubuntu (apt)

sudo apt-get update
sudo apt-get install -y python3

systemd включён по умолчанию в Ubuntu 16.04+ и Debian 8+.

RHEL / Rocky / AlmaLinux / CentOS / Fedora (dnf / yum)

sudo dnf install -y python3

SELinux: агент работает при SELinux в режиме enforcing — пользовательские политики не требуются. Он запускается от root со стандартными правами.

Arch Linux (pacman)

sudo pacman -S --needed python

openSUSE (zypper)

sudo zypper install -y python3

Alpine Linux (apk)

Установщику требуется bash, а настройка сервиса выполняется вручную (без systemd):

apk add --no-cache bash python3 py3-psutil py3-requests

После запуска установщика запустите агент под OpenRC или напрямую. Сам процесс агента полностью совместим; недоступна только автоматическая регистрация сервиса.

Требования безопасности

Права пользователя

Агент запускается от root:

• Требуется для системных метрик (CPU, память, диск, сеть)
• Требуется для доступа к сокетам сервисов (Docker, systemd)
• Следуйте рекомендациям по безопасности (см. ниже)

Права доступа к файлам

Установщик автоматически защищает файл конфигурации. Чтобы проверить или восстановить:

chown root:root /opt/statusradar/config.env
chmod 600 /opt/statusradar/config.env

Каталог агента должен принадлежать root:

chown -R root:root /opt/statusradar
chmod 755 /opt/statusradar

Сетевая безопасность

Правила firewall:

# Debian/Ubuntu (ufw)
sudo ufw allow out 443/tcp

# RHEL/Rocky/Fedora (firewalld)
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Проверка сертификатов:

• Агент проверяет SSL-сертификат сервера API
• Использует системное хранилище CA-сертификатов
• Регулярно обновляйте CA-сертификаты:

# Debian/Ubuntu
sudo apt-get install -y ca-certificates
sudo update-ca-certificates

# RHEL/Rocky/Fedora
sudo dnf install -y ca-certificates
sudo update-ca-trust

Совместимость

Версии Python

Версии systemd

Минимум: systemd 219 (2015) Рекомендуется: systemd 240+ — включает прямое логирование в файл /var/log/statusradar/agent.log (более старые версии переходят на журнал).

Проверить версию:

systemctl --version

Требования к ядру

Минимум: ядро Linux 3.10 (эпоха CentOS 7) Рекомендуется: ядро Linux 4.15+ (эпоха Ubuntu 18.04)

Необходимые возможности ядра:

• Файловая система /proc
• Файловая система /sys
• Netlink-сокеты (для сетевой статистики)

Поддержка виртуализации

Поддерживаемые платформы

Полностью поддерживается:

• ✅ KVM / QEMU
• ✅ VMware ESXi
• ✅ Hyper-V
• ✅ Xen
• ✅ Proxmox VE
• ✅ AWS EC2
• ✅ Google Compute Engine
• ✅ Azure Virtual Machines
• ✅ DigitalOcean Droplets
• ✅ Linode
• ✅ Vultr

Платформы контейнеров:

• ✅ Docker (установка на хост, не в контейнере)
• ✅ LXC / LXD
• ⚠️ Kubernetes (устанавливать как DaemonSet, а не обычный pod)

Не рекомендуется:

• ❌ Запуск агента внутри контейнера Docker (устанавливайте на хост)
• ❌ Запуск агента внутри pod Kubernetes (используйте DaemonSet)
• ❌ Вложенная виртуализация (агент на ВМ внутри ВМ)

Особенности облачных провайдеров

AWS EC2:

• Работает на всех типах инстансов (t2, t3, m5, c5 и т. д.)
• Для точной сетевой статистики рекомендуется enhanced networking
• Работает как с EBS, так и с instance store

Google Cloud:

• Работает на всех типах машин
• Особая настройка не требуется

Azure:

• Работает на всех размерах ВМ
• Поддерживает как Linux VM, так и Virtual Machine Scale Sets

Рекомендации по ресурсам для облака:

• Минимально жизнеспособный инстанс: эквивалент t2.micro / f1-micro
• Рекомендуется: эквивалент t3.small / e2-small или крупнее

Путь обновления

Агент обратно совместим в пределах основных версий. Повторно запустите установщик в режиме обновления:

curl -s https://statusradar.dev/install-agent.sh | sudo bash -s update

• Формат файла конфигурации обратно совместим
• Миграция базы данных не требуется
• Простоя сервиса во время обновления нет

Подробности см. в разделе Обновление.

Ограничения

Известные ограничения

Сбор метрик:

• Максимум плагинов на агент: 16 (все доступные плагины)
• Минимальный интервал сбора: 60 секунд
• Максимум отслеживаемых контейнеров Docker: 100 (мягкое ограничение)

Сеть:

• Тайм-аут запроса к API: 30 секунд
• Максимальный размер полезной нагрузки: 10 МБ (фактически без ограничений для метрик)

Неподдерживаемые сценарии

• ❌ Несколько агентов на одном сервере, сообщающих о себе как о разных серверах
• ❌ Агент, работающий в контейнере Docker (устанавливайте на хост)
• ❌ Мониторинг сервисов Windows
• ❌ Мониторинг macOS
• ❌ Изолированные сети без доступа к интернету (требуется подключение к интернету)

Устранение неполадок с требованиями

Проверьте версию Python

python3 --version

Ожидается: Python 3.6.0 или новее.

Проверьте доступную память

free -h

Убедитесь, что свободно не менее 256 МБ.

Проверьте дисковое пространство

df -h /opt/statusradar

Убедитесь, что свободно не менее 100 МБ.

Проверьте сетевую доступность

curl -I https://api.statusradar.dev

Ожидается: HTTP/2 200.

Проверьте сервис

systemctl --version
systemctl status statusradar-agent

Дальнейшие шаги

• Установка агента
• Настройка плагинов
• Устранение неполадок
• Документация по плагинам