Любой IT-подрядчик рано или поздно сталкивается с одним и тем же вопросом: «У нас и так всё работает — зачем нам мониторинг?». Ответ короткий: мониторинг нужен не когда «всё работает», а ровно для того момента, когда что-то ломается. Чем раньше система сообщит о проблеме, тем меньше у клиента простой, потерянные транзакции и нервы.
В этой статье мы рассказываем, как у нас в «ИТС» устроен выбор инструмента мониторинга для серверов клиентов. Без идеологии и фанатизма — что и почему мы ставим в типовых сценариях, что отбрасываем и почему.
С чего мы начинаем — не с инструмента, а с инвентаризации
Прежде чем спорить про Zabbix vs Prometheus, мы делаем простое: садимся и описываем, что вообще нужно мониторить у конкретного клиента. Чек-лист на одну страницу — за час разбираем с инженером клиента и пишем:
- какие сервера в продуктиве и какие у них роли (1С, web, БД, файловый, AD);
- какие сервисы критичны и какой простой допустим (RTO / RPO);
- какие у клиента уже есть инструменты — Active Directory, бэкапы, антивирус, гипервизор;
- кто и как должен получать уведомления (телефон дежурного, корпоративный чат, e-mail);
- что считается «инцидентом», а что — «информационным сообщением».
Без этого списка любой выбор инструмента — гадание. С ним становится видно: где-то достаточно UptimeRobot и одного агента, а где-то без полноценного стека не обойтись.
Три типовых сценария и три разных решения
В нашей практике 90% случаев укладываются в три коробки.
1. Малый клиент: 1–5 серверов, нет своего админа
Здесь нет смысла поднимать тяжёлый стек. Метрик мало, штата у клиента нет, поддерживать сервер мониторинга будем мы сами. В таких случаях мы обычно используем Zabbix Cloud + один лёгкий агент на каждый сервер. Что это даёт:
- быстрый старт — за день поднимается шаблон под Windows / Linux;
- понятные базовые триггеры: диск, память, доступность портов, состояние служб;
- алёрты в один корпоративный чат — без отдельного дежурного канала.
Главное правило для малых клиентов — лучше один работающий мониторинг с пятью триггерами, чем красивый дашборд, на который никто не смотрит.
2. Средний клиент: 1С-сервер + RDP + почта + сайт
Это самая массовая история — несколько серверов, есть пара ключевых бизнес-приложений, и важно ловить деградацию до того, как пользователи начнут звонить. Здесь мы ставим связку из нескольких компонентов:
- Zabbix как центральный сборщик метрик (CPU, RAM, диск, сеть, службы Windows);
- синтетика — отдельные скрипты-проверки, которые имитируют действия пользователя: логин в 1С, открытие документа, проверка скорости отчёта;
- Uptime-проверка извне — отдельный сервис, который не зависит от внутренней сети клиента и видит сервис «как пользователь из интернета»;
- сбор логов — централизованный сбор Windows Event Log и логов 1С, чтобы при инциденте не бегать по серверам.
Связка не дорогая по железу, но даёт сильный эффект: 80% инцидентов мы видим раньше клиента и часто закрываем до того, как кто-то заметит.
3. Крупный клиент: серверная ферма, виртуализация, кластер 1С
Здесь нужен полноценный стек — без шуток. Мы обычно собираем гибридную схему:
- Prometheus + Grafana на инфраструктурные метрики и виртуализацию;
- Zabbix на бизнес-уровень (службы, БД, очередь репликации);
- ELK / OpenSearch на логи, если у клиента жёсткие требования по аудиту;
- отдельный alertmanager с маршрутизацией: техническое — в дежурный канал, бизнес-критичное — звонком ответственному.
В этой категории мы уже отдельно проектируем мониторинг — пишем регламент, что и кому приходит, как эскалируется, что делать дежурному в первые 15 минут. Без регламента любой стек превращается в шум, который перестают читать через две недели.
Что мы перестали ставить и почему
За годы практики мы отказались от нескольких популярных схем:
- Голый Nagios без надстроек — поддерживать дороже, чем переехать на Zabbix;
- «Самописные» bash-скрипты по cron, шлющие на почту» — отлично работают, пока инженер, который их написал, в компании. Потом превращаются в чёрный ящик;
- Мониторинг «всего, что движется» — больше триггеров не значит лучше. Лишние алёрты быстро обучают дежурного игнорировать уведомления.
Чек-лист: на что смотреть при выборе мониторинга
Если вам нужно решить задачу самостоятельно — вот короткий список вопросов, на которые стоит ответить до установки чего-либо:
- Сколько серверов и какие у них роли?
- Кто будет реагировать на алёрты и в каком режиме (24/7, 8/5, по запросу)?
- Есть ли у клиента ресурсы поддерживать сам сервер мониторинга?
- Нужны ли журналы и логи или достаточно метрик?
- Какие у бизнеса требования по простою и RTO / RPO?
- Кто будет интерпретировать графики через полгода?
Ответы на эти шесть вопросов почти всегда сами «выталкивают» правильное решение. Если ответов нет — начинать с инструмента бессмысленно, нужно начинать с разговора.
Коротко
Мониторинг — это не «поставить и забыть», а часть эксплуатационной зрелости клиента. Мы подбираем инструмент под задачу, а не задачу под инструмент: лёгкий стек для малых клиентов, гибридный — для средних, проектный — для крупных. И всегда фиксируем регламент реакции: без него любой мониторинг через полгода превращается в шум.
Если у вас есть инфраструктура, по которой непонятно, есть мониторинг или нет — приходите на аудит. Час разговора обычно показывает, что нужно усилить в первую очередь.