Мониторинг серверов и сети: что нужно видеть до звонка пользователей

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

Цель мониторинга — не собрать максимум графиков, а превратить важные отклонения в понятные действия.

Начните с бизнес-сервисов

Сервер может отвечать на ping, но приложение на нём не работает. Поэтому сначала составьте список того, что важно пользователям:

• 1С;
• файловые ресурсы;
• CRM;
• телефония;
• корпоративная почта;
• VPN;
• сайт;
• интернет в офисе;
• удалённые рабочие столы;
• резервное копирование.

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

Доступность — только первый уровень

Проверка «узел отвечает» полезна, но недостаточна. Нужны несколько уровней:

1. Инфраструктура — включён ли сервер, доступна ли сеть.
2. Ресурсы — хватает ли процессора, памяти, диска.
3. Службы — работает ли база, веб-сервер, агент резервного копирования.
4. Приложение — может ли пользователь выполнить ключевое действие.
5. Бизнес-процесс — проходит ли обмен, отправляется ли документ, создаётся ли заявка.

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

Что контролировать на серверах

Процессор

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

Оперативная память

Контролируйте не только процент использования, но и активное вытеснение, рост файла подкачки и поведение конкретных служб.

Диски

Минимум:

• свободное место;
• ошибки ввода-вывода;
• состояние массива;
• задержки;
• прогноз заполнения;
• SMART-показатели, где применимо.

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

Службы и процессы

Автоматический перезапуск полезен, но частые перезапуски нужно расследовать. Иначе система выглядит доступной, хотя причина остаётся.

Журналы

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

Сеть

Полезные показатели:

• доступность маршрутизаторов, коммутаторов и точек доступа;
• загрузка интерфейсов;
• ошибки и отбрасывания пакетов;
• состояние интернет-каналов;
• задержка и потери;
• состояние VPN;
• температура и питание оборудования;
• количество клиентов Wi‑Fi;
• переключение на резервный канал.

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

Резервное копирование

Мониторинг должен отвечать:

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

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

Сертификаты, домены и лицензии

Некоторые аварии происходят по календарю. Можно заранее отслеживать:

• срок действия TLS-сертификатов;
• продление доменов;
• окончание лицензий;
• срок действия токенов;
• заполнение квот облачных сервисов;
• окончание поддержки оборудования.

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

Как настраивать пороги

Одинаковый порог для всех систем редко работает. 80% диска на небольшом томе и на большом хранилище означает разный запас времени. Лучше учитывать:

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

После запуска мониторинга пороги придётся корректировать. Это нормальная часть настройки.

Борьба с шумом

Если уведомлений слишком много, их перестают читать. Для снижения шума:

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

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

Эскалация

Для события определяют:

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

Система мониторинга не заменяет процесс реагирования. Без ответственных она только красиво показывает проблему.

Отчёты

Руководителю полезны не сотни графиков, а ответы:

• какие сервисы были недоступны;
• сколько длились инциденты;
• какие риски растут;
• где заканчиваются ресурсы;
• какие повторяющиеся причины обнаружены;
• что требует бюджета;
• какие плановые работы выполнены.

Минимальный старт

1. Проверить интернет и VPN.
2. Контролировать доступность ключевых серверов.
3. Настроить дисковое пространство.
4. Получать статус резервных копий.
5. Следить за критичными службами.
6. Контролировать сертификаты и домены.
7. Создать правила эскалации.
8. Ежемесячно пересматривать шумные и бесполезные события.

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