Zabbix для небольшой компании: что мониторить в первую очередь

Первый контур: доступность, диски, ресурсы, сервисы

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

Доступность узлов. Каждый сервер и сетевое устройство отвечают на ping, а агенты — на свой ping:

# сервер не отвечает на ping (простая проверка с сервера Zabbix)
last(/srv-1c/icmpping)=0

# агент не выходит на связь три минуты (item: agent.ping)
nodata(/srv-1c/agent.ping,3m)=1

Второй триггер — самый недооценённый: он срабатывает и тогда, когда сервер жив, но агент остановлен, — типовая ситуация после «лёгкого обновления».

Диски. Заполнение диска — причина номер один внезапных остановок: база и логи растут незаметно.

# предупреждение при 90%, критично при 95% (item: vfs.fs.size[/,pused])
last(/srv-1c/vfs.fs.size[/,pused])>90

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

# средняя загрузка CPU за 5 минут (item: system.cpu.util)
avg(/srv-1c/system.cpu.util,5m)>90

# доступной памяти меньше 10% (item: vm.memory.size[pavailable])
last(/srv-1c/vm.memory.size[pavailable])<10

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

# файловая шара не принимает подключения (item: net.tcp.service[tcp,,445])
last(/srv-file/net.tcp.service[tcp,,445])=0

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

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

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

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

Мониторинг без доведения до человека — графики для аффединков. Правильная петля собирается из трёх решений.

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

Куда. Zabbix умеет отправку почты и вызовы вебхуков — через них сообщение попадает в мессенджер, где его реально читают. Канал стоит выбрать тот, которым компания пользуется днём: «сообщения на служебную почту, которую открывают по пятницам» — это имитация петли.

Как. Разделение по важности важнее выбора канала. Критичные события — «сервер молчит», «копия не появилась» — доходят до человека сразу, в любое время. Предупреждающие («диск подбирается к 90%») спокойно ждут утра. Zabbix различает важность триггеров и поддерживает эскалацию — если проблема не закрыта, сообщение повторяется. Первое время уместен самый простой вариант: две важности, два сценария доставки.

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

Чего не стоит мониторить в маленькой инфраструктуре

• Всё подряд из шаблонов. Полный шаблон ОС приносит сотни метрик: загрузка каждого ядра, каждый раздел, каждая сеть. В небольшой компании это шум без владельца — включайте то, что входит в первый контур, остальное добавляйте по мере потребности.
• Каждый принтер и каждую точку Wi-Fi. Оборудование, простой которого никого не будит ночью, не заслуживает триггеров; при желании — доступность, но без уведомлений.
• Десятки дашбордов без триггеров. Красивые графики, на которые не смотрит никто, — наблюдение без действия. Сначала петля «обнаружили — узнали — исправили», дашборд потом.
• Второй мониторинг для страховки. Две системы мониторинга друг за другом удваивают сопровождение, а не надёжность. Лучше одна, но с работающими уведомлениями и дублёром на канале.
• Метрики, на которые нет реакции. Правило простое: для каждой включённой значимой проверки должен существовать ответ на вопрос «что я сделаю, если это сработает». Нет ответа — проверка пока ранняя.

Связанные материалы

Постановка мониторинга — от первого контура до уведомлений и пересмотра порогов — направление мониторинга и наблюдаемости.