Видеть состояние.
Понимать причину.
Действовать по плану.

На диске для архивов закончилось место

Пример сообщения: «Сервер SQL: диск архивов заполнен — резервная копия не создана».

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

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

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

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

Физический сервер нагревается выше заданного порога

Пример сообщения: «KRIT-HOST-01: температура CPU 78 °C при демонстрационном пороге 75 °C».

Что это означает: датчик сообщил о превышении настроенного значения. Это температура оборудования, а не отдельной виртуальной машины. Порог 75 °C здесь только пример: допустимые значения выбираем по модели оборудования и рекомендациям производителя.

Что проверяем: корректность датчика, историю нагрузки, охлаждение, вентиляторы и условия в помещении. Температуру собираем только при наличии поддерживаемых датчиков и разрешённого доступа, например через IPMI или SNMP.

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

Создан пользователь или изменены его права

Пример сообщения: «Сервер 1С: создан пользователь demo.operator» или «Сервер СКУД: изменены права demo.operator».

Что это означает: в журнале операционной системы появилось событие изменения учётной записи. Это может быть обычное действие администратора. Zabbix сообщает о событии, а не создаёт пользователя.

Что проверяем: кто и когда выполнил изменение, было ли оно согласовано и какие права выданы. Для сбора таких событий заранее настраиваем аудит ОС, доступ агента к журналу и правила уведомлений. Пользователи внутри приложений требуют отдельной интеграции.

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

Сервер недавно включился или перезапустился

Пример сообщения: «Сервер Patrul: сервер запущен, время работы — 3 минуты».

Что это означает: после запуска обнулилось время работы системы или появилась запись в системном журнале. Причиной может быть плановое обновление, ручная перезагрузка или аварийное отключение.

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

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

UniFi, WireGuard или телефония снова доступны

Пример сообщения: «Сервер UniFi: контроллер снова доступен», «Сервер WireGuard: VPN-соединение восстановлено» или «Asterisk: служба телефонии снова доступна».

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

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

Фиксируем восстановление и разбираем причину повторяющихся отключений, если они продолжаются.

Разовый пик или устойчивая проблема?

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

Понятный сигнал с контекстом

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

Кто принимает событие и что делает дальше

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

Обслуживание без лавины уведомлений

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

На сервере баз заканчивается место

Проверяем: свободное пространство и его изменение во времени.

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

Резервная копия давно не обновлялась

Проверяем: статус и время последнего успешного задания.

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

Недоступна удалённая площадка

Проверяем: связь с узлами и состояние нужных сетевых служб.

Дальше: отличаем недоступность канала от сбоя сервера, проверяем зависимости и порядок удалённого доступа. Для нескольких площадок рассматриваем подходящую схему сбора через Zabbix proxy.