Мониторинг состояния системы на Python

Терминал компьютера с наложенным логотипом Python

Большинство организаций сильно зависят от своей IT-инфраструктуры для выполнения бизнес-процессов. Незапланированные сбои или ухудшение производительности приводят к простоям, финансовым потерям и урону репутации.

Автоматические проверки состояния системы (health checks) — ключевой инструмент для поддержания стабильности. Постоянный сбор критичных метрик и быстрый поиск аномалий позволяют минимизировать время простоя и ускорить реагирование.

Почему важны проверки состояния

Коротко: мониторинг помогает обнаружить деградацию до того, как она превратится в инцидент. Он показывает узкие места (bottlenecks), указывает на процессы, потребляющие ресурсы, и формирует исторические данные для анализа трендов.

Определите, какие сервисы и функции критичны для бизнеса, и начните с них. Мониторинг можно расширять по мере зрелости системы.

Определение проверок состояния

Чёткая дефиниция проверок — основа. Последовательность действий:

Определите цель мониторинга: доступность сервиса, задержки, загрузку ресурсов и т. п.
Выберите метрики: CPU, память, диск, сети, количество открытых дескрипторов, статус процессов или контейнеров.
Установите ориентировочные пороги (thresholds) и правила оповещения.
Решите, куда будут уходить алерты (терминал, лог, почта, мессенджер, система инцидентов).

Важно: пороги — это ориентиры. Настраивайте их по истории работы вашей системы.

Выбор библиотек и подготовка окружения

Для автоматизации мониторинга в Python пригодятся следующие библиотеки:

psutil — кроссплатформенная библиотека для метрик CPU, памяти, дисков, сети и сенсоров.
schedule — простая библиотека для планирования задач по расписанию.
time — встроенная библиотека для операций со временем.
logging — встроенная библиотека для записи логов.

Рекомендуется создать виртуальное окружение (venv) и установить зависимости:

python -m venv venv
source venv/bin/activate  # Unix/macOS
venv\Scripts\activate     # Windows
pip install psutil schedule

После установки окружение готово.

Important: запускайте мониторинг с правами, достаточными для чтения метрик, но избегайте запуска от root без необходимости.

Структура проекта

Минимальная структура файлов:

monitoring.py — основной скрипт с проверками
system_monitor.log — файл логов (создаётся автоматически)
requirements.txt — список зависимостей

Импорт нужных библиотек

Создайте файл monitoring.py и импортируйте библиотеки:

import psutil
import schedule
import time
import logging
from logging.handlers import RotatingFileHandler

Логирование и уведомления

Логи важны для постинцидентного анализа и аудита. Ниже — пример надёжной конфигурации логирования с ротацией файлов и уровнем INFO. Это лучше, чем инициализировать basicConfig внутри каждой функции.

# Настройка логирования один раз при старте модуля
logger = logging.getLogger('system_monitor')
logger.setLevel(logging.INFO)
handler = RotatingFileHandler('system_monitor.log', maxBytes=5 * 1024 * 1024, backupCount=3)
formatter = logging.Formatter('%(asctime)s - %(levelname)s - %(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)

# Функция для записи лога
def log_message(message):
    logger.info(message)

Для немедленного уведомления можно печатать в консоль или интегрировать с внешними каналами (email, Slack, PagerDuty). Простой вывод в консоль:

def print_alert(message):
    print(f"ALERT: {message}")

Сигнал можно расширить: отправлять HTTP-запрос в систему оповещений или помещать сообщение в очередь.

Создание функций проверок состояния

Ниже приведены примеры проверок для CPU, памяти, диска и сети. Функции компактны и легко расширяются.

Мониторинг загрузки CPU

CPU — индикатор общей нагрузки. Частые пики или длительная высокая загрузка указывают на проблемные процессы.

def check_cpu_usage(threshold=50):
    cpu_usage = psutil.cpu_percent(interval=1)
    if cpu_usage > threshold:
        message = f"High CPU usage detected: {cpu_usage}%"
        log_message(message)
        print_alert(message)

Примечание: интервал измерения влияет на сглаживание показателя. Для кратковременных пиков используйте меньший интервал.

Мониторинг использования памяти

Мониторинг памяти помогает обнаружить утечки и приложения, потребляющие слишком много RAM.

def check_memory_usage(threshold=80):
    memory_usage = psutil.virtual_memory().percent
    if memory_usage > threshold:
        message = f"High memory usage detected: {memory_usage}%"
        log_message(message)
        print_alert(message)

Мониторинг дискового пространства

Недостаток места может привести к сбоям сервисов и повреждению данных.

def check_disk_space(path='/', threshold=75):
    disk_usage = psutil.disk_usage(path).percent
    if disk_usage > threshold:
        message = f"Low disk space detected on {path}: {disk_usage}%"
        log_message(message)
        print_alert(message)

Учитывайте отдельные файловые системы и точки монтирования, особенно для контейнеров и томов.

Мониторинг сетевого трафика

Наблюдение за сетевым трафиком помогает обнаружить всплески активности и потенциальные утечки данных.

def check_network_traffic(threshold_bytes=100 * 1024 * 1024):
    counters = psutil.net_io_counters()
    network_traffic = counters.bytes_recv + counters.bytes_sent
    network_mb = network_traffic / (1024 * 1024)
    if network_traffic > threshold_bytes:
        message = f"High network traffic detected: {network_mb:.2f} MB"
        log_message(message)
        print_alert(message)

Threshold указывайте в байтах; для удобства используйте умножение на 1024**2 для мегабайтов.

Реализация контроллера проверок

Объедините проверки в одну функцию-координатор:

def run_health_checks():
    print("Monitoring the system...")
    log_message("Running system health checks...")

    check_cpu_usage()
    check_memory_usage()
    check_disk_space()
    check_network_traffic()

    log_message("Health checks completed.")

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

Для запуска проверок по расписанию используйте schedule или системные планировщики (cron, systemd timers). Пример — запуск каждую минуту с помощью schedule:

schedule.every(1).minutes.do(run_health_checks)

if __name__ == "__main__":
    while True:
        schedule.run_pending()
        time.sleep(1)

Если вы развертываете на сервере, рассмотрите запуск как системный сервис (systemd) вместо бесконечного цикла в терминале.

Вывод программы мониторинга системы в среде разработки

Программа сохраняет логи в system_monitor.log и выводит оповещения в терминал. Для промышленного применения интегрируйте с системой оповещений.

Расширение проверок и улучшение отчётности

psutil поддерживает множество дополнительных метрик: загрузка по ядрам, статистика по процессам, файловые дескрипторы, температура и энергия (если аппаратно доступно). Вы можете:

Добавить мониторинг процессов по имени или PID.
Следить за количеством открытых сокетов и дескрипторов.
Собирать метрики по контейнерам (cgroups) на хостах с Docker/Podman.
Генерировать сводные отчёты и отправлять их по почте или в систему BI.

Для удобства отчётов используйте экспортеры (Prometheus), которые позволяют хранить метрики во временных рядах и визуализировать их в Grafana.

Альтернативные подходы

Промежуточный: агент на хосте (node-exporter, Telegraf) + система сбора (Prometheus) + графики (Grafana).
Облачные решения: Cloud Monitoring (GCP), CloudWatch (AWS), Azure Monitor — интеграция упрощает сбор и алерты, но зависит от облака.
APM: New Relic, Datadog — глубже анализируют приложения, трассировку запросов и бизнес-метрики.

Выбор зависит от масштабов, бюджета и требований к ретенции данных.

Когда автоматические проверки могут не сработать

Неверно установленные пороги — слишком низкие/высокие пороги приводят к «шуму» или пропускам.
Метрики не охватывают проблемную область (например, мониторятся ресурсы, но не учитывается очередь задач).
Сбой механизма оповещений (почтовый сервер, webhook) — тогда алерт не дойдет до ответственного.
Недостаток прав у процесса мониторинга — не все метрики доступны без прав администратора.

Важно тестировать путь от генерации события до получения оповещения.

Ментальные модели и эвристики

Правило 80/20: мониторьте 20% метрик, которые дают 80% информации о здоровье системы.
Сначала доступность, затем производительность, затем оптимизация затрат.
Сначала обнаружьте проблему, затем собирайте данные для причины.

Уровни зрелости мониторинга

Уровень 1 (Базовый): локальные скрипты + логи в файл.
Уровень 2 (Операционный): централизованный сбор метрик, алерты в канал связи.
Уровень 3 (Продвинутый): временные ряды, dashboards, трассировки, автоэскалация инцидентов.

Переход между уровнями требует инвестиций в процессы и обучение команд.

Инцидент: план действий (runbook)

Получили оповещение — подтвердите инцидент (проверка метрик, логов).
Откройте тикет/incidunt в системе управления.
Снимите снимки состояния (top, ps, netstat, df, dmesg).
Примите временные меры (перезапуск сервиса, освобождение места, ограничение нагрузки).
Выполните корневой анализ и исправление.
Закройте инцидент и обновите playbook.

Чек-лист по ролям

Операции:
- Проверить доступность метрик и алертов.
- Убедиться в отработке руков по инцидентам.
Разработчики:
- Добавить пользовательские метрики для важной бизнес-логики.
- Проверить, что критичные ошибки логируются.
Руководитель команды:
- Контролировать SLA и частоту инцидентов.

Критерии приёмки

Скрипт собирает метрики CPU, RAM, диск и сеть без ошибок.
Логи сохраняются в файл и архивируются по ротации.
Алерт генерируется при превышении порога и доставляется в тестовый канал.
Скрипт корректно запускается как systemd-сервис.

Тесты и сценарии приёмки

Симулируйте высокую нагрузку CPU (stress-ng) и проверьте, что срабатывает алерт.
Создайте файл большого размера и заполните диск, проверив disk-алерт.
Смоделируйте высокую сетевую активность и проверьте threshold для трафика.
Отключите сетевой шлюз и проверьте устойчивость логирования.

Шпаргалка и шаблоны настроек

Примеры порогов (ориентиры): CPU 70–90%, память 70–90%, диск 75–95%. Настраивайте по истории.
Планирование: для частых проверок используйте schedule или cron для высокой надёжности.
Формат логов: ISO-время + уровень + сообщение.

Пример systemd unit для запуска скрипта:

[Unit]
Description=System Monitor
After=network.target

[Service]
Environment=PYTHONUNBUFFERED=1
ExecStart=/path/to/venv/bin/python /path/to/monitoring.py
Restart=always
User=monitor

[Install]
WantedBy=multi-user.target

Безопасность и конфиденциальность

Не логируйте секреты и персональные данные в открытом виде.
Храните логи с ограничением доступа и ротацией.
Для отправки алертов используйте защищённые каналы (HTTPS, TLS).
Сведите к минимуму привилегии процесса мониторинга.

Варианты интеграции и миграции

Перенос на Prometheus: написать экспортер или использовать existing exporters для метрик хоста.
Миграция в облако: воспользуйтесь встроенными агентами облачного провайдера.

Диаграмма принятия решения

flowchart TD
  A[Появился алерт] --> B{Есть метрика CPU/Memory/Disk/Network?}
  B -- Да --> C[Проверить текущее значение и историю]
  B -- Нет --> D[Собрать логи и трассировки]
  C --> E{Порог превышен?}
  E -- Да --> F[Перезапустить сервис / применить mitigations]
  E -- Нет --> D
  F --> G[Провести RCA и закрыть тикет]
  D --> G

Краткий глоссарий

Aлерт — уведомление о проблеме.
RCA — анализ первопричины (root cause analysis).
Экспортер — компонент, который предоставляет метрики внешней системе мониторинга.

Резюме

Автоматический мониторинг на Python с psutil — быстрый способ начать собирать метрики и получать уведомления. Для промышленного уровня рекомендуется интеграция с системами временных рядов и алертами (Prometheus, Grafana, облачные решения). Начните с простого набора проверок, постепенно добавляйте процессы и автоматические меры реагирования.

Дополнительные шаги: подключите централизованный сбор метрик, настройте дашборды и проведите тренировочные учения для команды по реагированию на инциденты.

Автоматический мониторинг состояния системы на Python