Автоматизированные проверки состояния системы на Python

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

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

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

Чётко сформулируйте, какие проверки вам нужны и зачем. Начните с бизнес- или сервисных целей: какие функции предоставляет система и какие службы критичны? Затем определите метрики и пороги, по которым будете судить о состоянии.

Краткий чек-лист для определения проверок:

• Идентифицируйте критичные сервисы и бизнес-функции.
• Выберите метрики (CPU, память, диск, сеть, ответы сервисов, задержки).
• Установите пороги (на основе исторических данных или разумных предположений).
• Определите действия при срабатывании (лог, оповещение, эскалация).

Важно: пороговая логика должна быть понятной и воспроизводимой. Не используйте «магические» числа без объяснения источника.

Выбор библиотек и настройка окружения

Для примера на Python понадобятся библиотеки для сбора метрик и планирования задач:

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

Создайте виртуальное окружение, чтобы избежать конфликтов версий, затем установите зависимости:

pip install psutil schedule

Полный исходный код можно хранить в репозитории и расширять по мере необходимости.

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

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

import psutil
import schedule
import time
import logging

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

Логи — важнейший источник исторических данных и контекста инцидентов. Используйте logging для записи в файл system_monitor.log и печатайте оповещения в консоль для немедленного внимания.

# Function to log messages
def log_message(message):
    # Configure logging
    logging.basicConfig(filename='system_monitor.log', level=logging.INFO,
                        format='%(asctime)s - %(message)s')
    logging.info(message)

# Function to print alerts to the console
def print_alert(message):
    print(f"ALERT: {message}")

Совет: для продакшена лучше настраивать логгер один раз (в точке входа) и использовать ротацию логов (RotatingFileHandler) вместо повторного вызова basicConfig внутри функции.

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

Каждая проверка инкапсулирует конкретный тест критического ресурса.

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

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

# Health check functions
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)

Установите порог в процентах. При превышении фиксируется событие и происходит оповещение.

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

Регулярная проверка памяти помогает обнаружить утечки и процессы с чрезмерным потреблением.

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: {disk_usage}%"
        log_message(message)
        print_alert(message)

Учтите, что на Windows путь по умолчанию может быть ‘C:\’.

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

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

def check_network_traffic(threshold=100 * 1024 * 1024):
    network_traffic = psutil.net_io_counters().bytes_recv +\
                      psutil.net_io_counters().bytes_sent

    if network_traffic > threshold:
        message = f"High network traffic detected: {network_traffic:.2f} MB"
        log_message(message)
        print_alert(message)

Порог в коде приведён в байтах; при необходимости переводите в удобные единицы.

Реализация логики мониторинга

Контроллер вызывает все проверки и объединяет их в единый цикл проверки.

# Function to run health checks
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 для периодического запуска. В примере — каждая минута.

# Schedule health checks to run every minute   
schedule.every(1).minutes.do(run_health_checks)

Запустите основной цикл, который будет выполнять запланированные задачи:

# Main loop to run scheduled tasks
while True:
    schedule.run_pending()
    time.sleep(1)

При запуске программа будет записывать логи в system_monitor.log и показывать оповещения в терминале.

Улучшения и расширения

Базовые проверки легко расширяются. Ниже — набор практических вариантов улучшения и альтернативных подходов.

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

• Prometheus + node_exporter + Grafana: для метрик и долгосрочного хранения с гибкой агрегацией и визуализацией.
• Nagios / Icinga: классические решения для проверки хостов и сервисов с системой уведомлений.
• Systemd timers или cron: для простых периодических задач без дополнительной зависимости.
• APM-инструменты (Datadog, New Relic): глубокий анализ производительности приложений.

Когда использовать: Prometheus/Grafana — если нужна история метрик и графики; APM — если важен трассинг и профилирование. Простые скрипты подходят для быстрых проверок и локальных хостов.

Когда простые проверки не сработают

• Распределённые проблемы: локальные проверки не показывают зависимостей между сервисами.
• События короткой длительности: если интервал слишком большой, вы пропустите кратковременные всплески.
• Скрытая деградация производительности (например, рост латентности без нагрузки на CPU).

В таких случаях добавляйте синтетические проверки (health endpoints), транзакционные тесты и распределённый трейсинг.

Важное: одна лишь запись «CPU 95%» мало что даёт без контекста (какие процессы, когда началось, есть ли тренд).

Методология внедрения (мини-процесс)

1. Определите критичные сервисы и метрики.
2. Настройте сбор базовых метрик на тестовом окружении.
3. Выставьте разумные пороги и прогоните тесты нагрузки.
4. Настройте оповещения и каналы эскалации (email, Slack, PagerDuty).
5. Перенесите на прод, наблюдайте и корректируйте пороги.

Роль-ориентированные чек-листы

• SRE / Операции:

  • Настроить хранение исторических метрик.
  • Ввести эскалационные правила и SLA.
  • Настроить ротацию логов и ретеншн метрик.

• Разработчик:

  • Добавить health endpoints в сервисы.
  • Проверять использование ресурсов в CI при нагрузочных тестах.

• Инженер по безопасности:

  • Контролировать аномалии сетевого трафика.
  • Проанализировать логи на присутствие утечек данных.

SOP: базовый сценарий реагирования на оповещение

1. Получено оповещение о превышении порога.
2. Проверить текущие логи и метрики за последние 5–15 минут.
3. Определить причину (нормальная нагрузка, баг, атака, резервное копирование).
4. При необходимости перезапустить проблемный сервис или откатить недавнее изменение.
5. Эскалировать по расписанию, если проблема не устраняется.
6. По инциденту — постмортем и корректировка порогов/процессов.

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

• Скрипт запускается как сервис и сохраняет логи в файл.
• Оповещение отправляется при превышении настроенных порогов.
• История метрик хранится минимум 7 дней (для анализа трендов).
• Доступ к логам и настройкам имеют только уполномоченные лица.

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

• Моделирование пиков CPU: запустить нагрузку и убедиться, что приходит оповещение.
• Моделирование утечки памяти: постепенно увеличивать потребление и проверить триггер.
• Заполнение диска до порога: симулировать большой файл и проверить алерт.
• Сетевой всплеск: искусственно сгенерировать трафик и проверить обнаружение.

Шаблон: таблица порогов (пример)

Используйте эту таблицу как стартовую точку и корректируйте по своему ландшафту.

Безопасность и приватность

• Логи могут содержать PII — избегайте записи персональных данных в нешифрованные логи.
• Доступ к логам и метрикам следует ограничить ролями (RBAC).
• Для передачи оповещений используйте защищённые каналы (HTTPS, шифрованные интеграции).
• GDPR/локальное законодательство: убедитесь, что логи хранятся и обрабатываются согласно требованиям (минимизация данных, ретеншн).

Меры по усилению безопасности мониторинга

• Храните учётные данные и ключи в менеджере секретов.
• Ограничьте сеть: доступ к endpoint’ам мониторинга только из доверенной сети.
• Подпишите артефакты и используйте проверку целостности для автоматических скриптов.

Совместимость и переносимость

• psutil работает на Linux, Windows, macOS; пути по умолчанию и доступ к метрикам могут отличаться.
• Для контейнеров (Docker/Kubernetes) метрики внутри контейнера отражают ресурсы контейнера — учитывайте лимиты cgroups.
• Для облачных инстансов используйте нативные агенты (CloudWatch Agent, Azure Monitor) для интеграции с облачной платформой.

Пример расширения: отправка уведомлений по email (шаблон)

import smtplib
from email.message import EmailMessage

def send_email(subject, body, to_addrs):
    msg = EmailMessage()
    msg.set_content(body)
    msg['Subject'] = subject
    msg['From'] = 'monitor@example.com'
    msg['To'] = ', '.join(to_addrs)

    with smtplib.SMTP('smtp.example.com') as s:
        s.login('user', 'password')
        s.send_message(msg)

Используйте защищённые SMTP-сервисы и не храните пароли в коде.

Модель принятия решений при оповещении

flowchart TD
  A[Оповещение получено] --> B{Падает ли сервис?}
  B -->|Да| C[Эскалация инженеру на смене]
  B -->|Нет| D{Временная деградация}
  D -->|Да| E[Запуск скрипта временной стабилизации]
  D -->|Нет| F[Сбор метрик и анализ]
  E --> G[Наблюдение 15 мин]
  C --> G
  F --> G
  G --> H[Закрыть инцидент или продолжить расследование]

Когда стоит перейти на более сложную систему

• Если требуется хранение истории метрик за месяцы и сложные графики — подумайте о Prometheus + Grafana.
• Если важен трассинг запросов и профилирование — подключите APM.
• Если важна оркестрация оповещений и эскалация — интегрируйте с PagerDuty или аналогом.

Заключение

Автоматизированные проверки состояния системы — эффективный и относительно простой способ повысить надёжность инфраструктуры. Начните с базовых метрик на Python и psutil, отстройте пороги по результатам наблюдений и интегрируйте оповещения с процессом реагирования.

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

Эксперт: “Регулярный мониторинг превращает неизвестные сбои в прогнозируемые задачи”.

Краткое резюме:

• Настройте базовые проверки CPU, памяти, диска и сети.
• Храните логи и метрики для анализа трендов.
• Интегрируйте оповещения с процессом эскалации и SOP.
• По мере роста системы переходите на специализированные решения.