Zabbix и Grafana для малого офиса: как узнавать о падении сервера раньше, чем это сделает бухгалтер

Классика жанра: сервер лёг в пятницу в 18:40, а узнал я об этом в понедельник в 9:05, когда главбух написала «1С не открывается, я уже два часа жду». Два часа. В пятницу. За выходные никто даже не заметил. После третьего такого случая я поставил себе Zabbix и Grafana и настроил, чтобы бот в Telegram будил меня раньше, чем клиент успевал разозлиться.

Проблема не в серверах, а в тишине

У малого офиса на 15-40 рабочих мест обычно нет айтишника в штате. Есть я, приходящий раз в неделю, или удалённый подрядчик, который включается по звонку. Пока звонка нет — тишина. Сервер может ронять службу терминалов в четверг ночью, диск C: может забиться логами до 2 гигабайт свободных, бэкап через Veeam может тихо перестать выполняться ещё три недели назад. Никто не узнает, пока не рванёт по-настоящему.

Самое обидное — что все эти события оставляют следы. Zabbix умеет их читать. Диск заполнен на 92%? Событие есть. Служба остановилась? Есть. Сервер не отвечает на пинг? Тоже есть, и почти сразу. Вопрос не в том, есть ли данные. Вопрос в том, смотрит ли их кто-то вовремя.

У одного клиента, юрфирмы на Пресне, сервер терминалов зависал раз в 8-10 дней из-за утечки памяти в стороннем плагине для сканирования документов. Без мониторинга это выглядело как случайность: то полетело, то само прошло. С Zabbix стало видно чёткий паттерн — память RAM росла линейно и упиралась в потолок ровно на девятый день. Мы поставили перезагрузку службы по расписанию, и жалобы прекратились.

Почему Zabbix, а не платный SaaS-мониторинг

Есть куча облачных сервисов мониторинга — Uptime Kuma в облачной версии, Datadog, PRTG. Они хороши, но почти все или платят за агента на хосте, или считают деньги за количество метрик. Для офиса с двумя серверами и десятком рабочих станций это быстро превращается в подписку на 3000-8000 рублей в месяц просто за то, чтобы узнать «жив ли сервер».

Zabbix бесплатный, open source, и живёт у меня же на маленькой виртуалке. Хватает 2 vCPU и 4 гигабайт RAM, если это не сотня серверов, а пять-десять хостов малого офиса. PostgreSQL или MySQL под базу, сам Zabbix Server, веб-интерфейс — и всё это спокойно тянет виртуалка за 300-400 рублей в месяц на любом отечественном хостинге или вообще на том же сервере, который вы мониторите, если он не единственный.

PRTG тоже неплох, кстати, и у него симпатичнее интерфейс из коробки. Но у него лицензия по числу сенсоров, и уже на третьем сервере с десятком метрик каждый вы упрётесь в бесплатный лимит в 100 сенсоров. Zabbix считает хосты и метрики без ограничений — потому его и выбирают, когда бюджет — это в первую очередь моё время, а не строчка в смете.

Минимальная установка: без плясок с бубном

Ставлю Zabbix Server 7.0 на Ubuntu 22.04 из официального репозитория — это буквально пять команд apt и один мастер настройки в браузере. На каждый мониторимый сервер, будь то Windows Server 2019 с 1С или Linux-машина с nginx, ставится Zabbix Agent 2 — маленькая служба, которая раз в минуту отдаёт метрики: CPU, память, диски, сеть, список служб.

Для Windows-серверов есть готовый MSI-установщик агента, ставится за две минуты, спрашивает только IP сервера мониторинга. Дальше в Zabbix накидываете шаблон Windows — там уже прописаны нужные проверки: свободное место на диске, загрузка процессора, доступность RDP-порта 3389, состояние ключевых служб. Для 1С отдельно добавляю проверку процесса ragent.exe и rphost.exe — если процесс сервера 1С падает, я хочу знать через минуту, а не когда позвонит клиент.

На всё уходит вечер. Не неделя, не «выделенный проект», а один вечер после работы, если серверов в офисе два-три. Я специально засекал время у последнего клиента: 55 минут от чистой виртуалки до первого алерта в телеграм.

Grafana поверх Zabbix — не для галочки, а для директора

Сам Zabbix умеет строить графики, и они рабочие, но выглядят как из 2010 года. Grafana даёт красивые дашборды, и это не просто эстетика. Когда я показываю владельцу бизнеса график загрузки сервера за месяц с явным трендом на переполнение диска, он понимает проблему за 10 секунд. Когда я говорю то же самое словами, он кивает и забывает через час.

Подключение простое: в Grafana есть официальный плагин-источник данных Zabbix, ставится за пару кликов, дальше просто выбираете хосты и метрики и собираете дашборд. Я обычно делаю один экран на весь офис: загрузка CPU и RAM по всем серверам, свободное место на дисках в процентах, статус последнего бэкапа Veeam, аптайм по каждому хосту. Всё на одном экране, обновляется каждые 30 секунд.

У меня в переговорке одного клиента такой дашборд вывешен на телевизор — не потому что это модно, а потому что директор реально в него поглядывает между встречами. Один раз он сам заметил, что диск на файловом сервере подбирается к 85%, и написал мне раньше, чем сработал алерт. Приятный побочный эффект прозрачности.

Алерты в Telegram: сердце всей схемы

Без алертов вся эта красота бесполезна — я же не буду сидеть и смотреть на дашборд весь день. Поэтому ключевая часть — это уведомления. В Zabbix есть встроенная интеграция с Telegram через media type, настраивается через бота: создаёте бота у @BotFather, получаете токен, привязываете чат ID, и в Zabbix прописываете webhook-скрипт, который отправляет сообщение при срабатывании триггера.

Я настраиваю три уровня серьёзности. Warning — диск заполнен на 80%, память нагружена больше 85% дольше 10 минут — приходит одним сообщением без звука, читаю утром. Average — служба остановлена, сервер не отвечает на порт RDP — сообщение со звуком, я смотрю в течение часа. Disaster — сервер не пингуется вообще — это отдельный чат, куда падает сообщение каждые 5 минут, пока проблема не решится, чтобы точно не пропустить.

Формат сообщения настраиваю сам: имя хоста, что случилось, значение метрики, время. Никакого «Trigger fired» на английском — пишу по-русски и понятно: «Сервер SRV-1C: диск C свободно 4.2 ГБ (было 40 ГБ неделю назад)». Дежурный смысл сообщения должен быть понятен даже если читаешь его в метро в 23:40, а не за компом с открытым Zabbix.

Что мониторить в первую очередь, а что можно отложить

Не пытайтесь охватить всё сразу — это главная ошибка. Начинайте с четырёх вещей, которые реально роняют бизнес: доступность сервера по сети, свободное место на системном диске, состояние ключевых служб (1С, SQL Server, терминальные сессии, файловый сервер), и завершение бэкапа. Именно в таком порядке, потому что именно в таком порядке эти проблемы обычно и всплывают у клиентов.

Отдельно советую подключить мониторинг результата бэкапа Veeam через его же лог или через простую проверку файла-маркера с timestamp — банально, но работает. У одного клиента, производство мебели под Домодедово, бэкап падал с ошибкой уже месяц из-за забитого диска на хранилище, а узнали об этом только когда понадобилось восстановить случайно удалённую папку с чертежами. С тех пор у меня отдельный триггер: если файл последнего успешного бэкапа старше 26 часов — сразу алерт.

ИБП тоже стоит подключить, если он сетевой — через SNMP Zabbix спокойно читает статус батареи и факт перехода на автономное питание. Это дешёвая страховка: за 10 минут настройки вы получите предупреждение о пропадании электричества за несколько минут до того, как сервер начнёт мигать и выключаться некорректно.

Сколько это реально стоит и когда окупается

Деньгами почти ничего — виртуалка под Zabbix и Grafana обходится в 300-500 рублей в месяц, сам софт бесплатный. Основная стоимость — это время на настройку, и оно окупается с первого же инцидента, который вы поймали до звонка клиента. Час моей работы стоит дороже, чем месяц простоя виртуалки под мониторинг, так что арифметика тут не в пользу «само рассосётся».

Есть и подводный камень: мониторинг сам по себе требует внимания в первую неделю. Триггеры по умолчанию слишком чувствительные — Zabbix будет сыпать алертами по загрузке CPU на 90% на секунду, что абсолютно нормально для сервера с 1С в момент формирования отчёта. Я обычно подстраиваю пороги и добавляю условие «дольше 5 минут подряд», иначе через три дня боты в Telegram банально заглушают, и вот тогда весь смысл теряется.

Второй месяц — самый показательный. Если алертов стало резко меньше, а не больше, значит настройка прижилась: пороги правильные, ложных срабатываний нет, а реальные проблемы либо решились сами (диск почистили, старый бэкап поправили), либо ловятся заранее. У меня три клиента прошли этот путь за последний год, и все три говорят одно и то же — «мы теперь узнаём о проблеме сами, а не от клиентов клиентов».

Частые вопросы

Нужен ли отдельный физический сервер под Zabbix?
Нет, вполне хватит одной небольшой виртуальной машины на 2 vCPU и 4 ГБ RAM — держать Zabbix и Grafana на одной виртуалке для офиса из пяти-десяти хостов совершенно нормально. Если серверов больше пятнадцати-двадцати, стоит развести базу данных и сам Zabbix Server по разным машинам, но для малого офиса это избыточно.

А что если сеть упадёт целиком и сам мониторинг тоже отвалится?
Тут поможет простое правило: держите виртуалку с Zabbix вне того же физического узла или той же подсети, что и мониторимые серверы, а лучше вообще на внешнем VPS. Тогда при пропадании интернета в офисе Zabbix не сможет достучаться до хостов и как раз пришлёт алерт «сервер недоступен» — это тоже полезная информация, даже если причина не в самом сервере.

Если выбирать только одно — Zabbix или Grafana — что важнее?
Для алертов и сбора метрик обязателен Zabbix — именно он опрашивает хосты и решает, когда слать уведомление в Telegram. Grafana же добавляет только красивую визуализацию поверх собранных данных, и без неё мониторинг прекрасно работает, просто выглядит не так презентабельно на большом экране в переговорке.

Сколько времени реально уходит на внедрение с нуля?
Для типового офиса с двумя-тремя серверами — от 40 минут до трёх часов, в зависимости от того, сколько триггеров и шаблонов вы настраиваете сразу. Базовая связка «сервер недоступен плюс диск заполнен плюс алерт в Telegram» разворачивается в течение одного вечера, а тонкая настройка порогов под конкретную нагрузку обычно занимает ещё неделю наблюдений.