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

Домашний сервер выходит из строя тихо: диск деградирует неделями, вентилятор забивается пылью, сервис падает ночью, а провайдер «моргает» на минуту. Без уведомлений вы узнаёте об этом, когда уже потеряли данные или доступ. Ниже — практическая схема: что мониторить, чем, какие пороги ставить и как не утонуть в ложных тревогах.

Что нужно мониторить на домашнем сервере

Разделите мониторинг на четыре слоя — так проще настраивать пороги и каналы. Каждый слой отвечает на свой вопрос и имеет разную срочность.

• Железо: SMART дисков, температура CPU и накопителей, вентиляторы, питание (UPS).
• Сервисы: доступность веб-панелей, баз данных, файловых шар, контейнеров.
• Сеть: наличие интернета, задержка, потери пакетов, доступность внешнего IP.
• Система: свободное место, нагрузка, память, время работы без перезагрузки.

Мониторинг SMART и состояния диска

SMART — основной ранний индикатор отказа HDD и SSD. Ключевые атрибуты, за которыми стоит следить: Reallocated_Sector_Ct, Current_Pending_Sector, Offline_Uncorrectable, а для SSD — Wear_Leveling_Count и Media_Wearout_Indicator. Рост переназначенных и ожидающих секторов важнее абсолютных значений: даже один новый pending-сектор — повод проверить бэкап.

• Проверяйте SMART регулярно, а не только при сбое: smartctl -a /dev/sdX или smartctl -a /dev/nvme0.
• Запускайте короткий self-test по расписанию (smartctl -t short), длинный — реже, например раз в месяц.
• Следите за температурой накопителя: перегрев ускоряет износ и провоцирует ошибки.
• Храните историю значений, чтобы видеть тренд, а не одну точку.

# Посмотреть SMART и запустить короткий тест
sudo smartctl -a /dev/sda
sudo smartctl -t short /dev/sda

# Для NVMe
sudo smartctl -a /dev/nvme0

Контроль температуры CPU и дисков

Температура — самый частый источник ложных и настоящих тревог. Для CPU ориентируйтесь на паспортный TjMax производителя: тревога имеет смысл при устойчивом приближении к нему, а не при кратковременных пиках под нагрузкой. Для HDD комфортный диапазон обычно 25–45 °C, для NVMe — до 70 °C под нагрузкой с учётом троттлинга.

Снимать показания можно через lm-sensors (sensors), smartctl для дисков и nvme smart-log для NVMe. Настройте уведомление не на мгновенное значение, а на удержание порога в течение нескольких минут — это отсекает пики.

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

Доступность сервиса проверяется двумя способами: проверкой порта (TCP-connect) и проверкой ответа приложения (HTTP-код, содержимое, время ответа). Второй надёжнее: порт может быть открыт, а приложение уже не отвечает корректно.

• Для веб-сервисов используйте HTTP-проверку с ожидаемым кодом 200 и таймаутом.
• Для баз данных и брокеров — проверку порта или лёгкий запрос.
• Для контейнеров — healthcheck внутри Docker/Compose.
• Проверяйте не только «жив ли», но и «отвечает ли за приемлемое время».

# Простая проверка HTTP-доступности
curl -fsS -o /dev/null -w "%{http_code} %{time_total}s\n" --max-time 5 http://127.0.0.1:8080/health

Мониторинг интернет-соединения

Отделяйте «упал сервер» от «упал интернет». Проверяйте доступность внешнего ресурса (например, ping или HTTP к надёжному хосту), задержку и потери пакетов. Полезно отслеживать и внешний IP, если вы используете проброс портов или DDNS.

• Пинг внешнего хоста: потеря пакетов и рост задержки — ранние признаки проблем у провайдера.
• HTTP-проверка внешнего сайта: отличает полный обрыв от проблем с DNS.
• Проверка DNS-резолвинга отдельно: сбой DNS выглядит как «интернета нет».
• Фиксируйте смену внешнего IP, если от него зависят доступ и сертификаты.

Выбор каналов доставки уведомлений

Канал должен быть независим от самого сервера: если уведомление идёт через сервис на том же хосте, при его падении вы ничего не узнаете. Держите минимум два канала разной природы.

Настройка порогов и защита от ложных тревог

Ложные тревоги опаснее пропущенных: к ним привыкают и перестают реагировать. Основные приёмы — задержка на срабатывание, повторные проверки и группировка событий.

1. Требуйте удержания условия N минут перед отправкой (for: 5m в Prometheus Alertmanager).
2. Используйте повторную проверку: два-три неудачных запроса подряд, прежде чем поднять тревогу.
3. Разделяйте severity: warning и critical — с разными каналами и порогами.
4. Группируйте и подавляйте дубли: одна проблема — одно уведомление.
5. Настройте «тихие часы» для некритичных событий, но не для дисков и питания.

# Пример правила с задержкой и повторной проверкой (Alertmanager-стиль)
groups:
  - name: disk
    rules:
      - alert: DiskPendingSectors
        expr: smart_pending_sectors > 0
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "Появились pending-секторы на диске"

Тестирование и обслуживание системы мониторинга

Мониторинг, который никто не проверял, отказывает в самый неподходящий момент. Регулярно тестируйте доставку уведомлений и актуальность проверок.

• Раз в месяц отправляйте тестовое уведомление по каждому каналу.
• Проверяйте, что агенты и экспортёры живы и отдают метрики.
• Обновляйте пороги при замене железа или смене нагрузки.
• Ведите короткий журнал инцидентов: что сработало, что пропустили.
• Проверяйте, что резервный канал не зависит от основного сервера.

Начните с минимума: SMART, температура и один внешний канал уведомлений. Затем добавьте проверки сервисов и интернета, а пороги настраивайте по реальной статистике, а не по интуиции.