Что должен контролировать мониторинг серверов кроме доступности по ping

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

Ниже — что стоит проверять, разбитое по слоям, и отдельно про уведомления: плохо настроенные оповещения вредят не меньше, чем их отсутствие.

Слой 1: ресурсы

Слой 2: службы и приложения

• Служба запущена — но этого мало: процесс может висеть, не обслуживая запросы.
• Порт принимает соединения — следующий уровень достоверности.
• Приложение отвечает по существу — обращение к служебному адресу состояния, а не к порту.
• Время ответа — деградация обычно начинается задолго до отказа.
• Число ошибок в ответах — рост доли ошибочных ответов при формально работающем сервисе.
• Автозапуск включён — служба поднимется после перезагрузки. Проверяется редко, а вспоминается всегда некстати.

Разница между «порт открыт» и «приложение отвечает» принципиальна: веб-сервер может принимать соединения и на каждое отдавать ошибку.

Слой 3: сайты и внешняя доступность

• код ответа главной и одной-двух ключевых страниц;
• время полного ответа;
• срок действия TLS-сертификата — предупреждение минимум за две недели;
• корректность редиректов с HTTP и с www;
• доступность извне, а не только изнутри сети;
• наличие ожидаемого фрагмента в содержимом страницы.

Последний пункт ловит подмену и «пустые» ответы: страница отдаёт 200, но вместо содержимого — заглушка или чужой сайт.

Слой 4: базы данных

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

Исчерпание лимита подключений выглядит для пользователя как полный отказ сервиса, хотя и сервер, и база формально работают.

Слой 5: резервные копии и регламентные задания

Отдельный слой, который забывают чаще всего. Мониторить нужно не запуск задания, а его результат и давность.

Проверка по времени последней успешной копии — самая ценная из перечисленных: она срабатывает даже тогда, когда система копирования не подаёт признаков жизни. Подробно о том, почему сам факт наличия копии ничего не гарантирует, — в материале о тестовом восстановлении.

Слой 6: сеть и оборудование

• состояние сетевых интерфейсов и ошибки на них;
• загрузка каналов и доступность резервного канала;
• SMART и состояние массивов — деградировавший массив продолжает работать до второго отказа;
• состояние блоков питания и температура;
• события контроллера управления сервером;
• заряд и время работы источника бесперебойного питания.

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

Уведомления: как не утонуть в шуме

Мониторинг, присылающий сотню сообщений в день, работает хуже, чем его отсутствие: на оповещения перестают смотреть, и настоящая авария теряется среди мусора.

1. Шаг 1

   Разделите уведомления по важности

   «Сервис недоступен» и «загрузка процессора 80% пять минут» не должны приходить одинаково. Первое — немедленно, второе — в сводку.

2. Шаг 2

   Добавьте задержку срабатывания

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

3. Шаг 3

   Настройте зависимости

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

4. Шаг 4

   Уведомляйте о восстановлении

   Без этого непонятно, продолжается ли авария. Сообщение о закрытии проблемы так же важно, как о её начале.

5. Шаг 5

   Учитывайте окна обслуживания

   Плановые работы не должны порождать оповещения — иначе к ним привыкают и перестают реагировать.

6. Шаг 6

   Пересматривайте пороги

   Если оповещение приходит каждый день и его каждый раз игнорируют — либо порог неверный, либо проблему нужно наконец решить.

Хороший критерий: на каждое пришедшее оповещение должно быть понятное действие. Если действия нет — это не оповещение, а строка в отчёте.

Куда отправлять

Мессенджер удобен: сообщения читают быстро и с телефона. Но именно поэтому в него нельзя направлять всё подряд.

• Критичное — в мессенджер немедленно, отдельным каналом.
• Предупреждения — в отдельный канал или в ежедневную сводку.
• Информационное — только в интерфейс мониторинга.
• Разные каналы для разных систем, если за них отвечают разные люди.

Минимальный набор для одного сервера

Если начинать с нуля, эти проверки закрывают большинство реальных инцидентов:

1. 1Доступность узла.
2. 2Свободное место на дисках с прогнозом расходования.
3. 3Память и активность подкачки.
4. 4Состояние ключевых служб и их автозапуск.
5. 5HTTP-код и время ответа сайта или приложения.
6. 6Срок действия TLS-сертификата.
7. 7Время последней успешной резервной копии.
8. 8Приём подключений базой данных.
9. 9SMART и состояние дискового массива.
10. 10Время работы системы — резкий сброс означает незамеченную перезагрузку.

Для сервисов, опубликованных наружу, к этому добавляются проверки извне — иначе недоступность увидят пользователи, а не вы. Как устроена такая публикация, разобрано в материале о размещении сервисов за одним внешним адресом.