Инфраструктура
Мониторинг серверов и сайта для ИП и сети клубов — без «Zabbix на год»
Материал подготовлен с участием ИИ, проверен редакцией.
Мониторинг в малом бизнесе часто появляется после аварии: «почему никто не заметил, что диск забит за неделю до падения 1С?» До этого достаточно звонка администратору «у нас всё тормозит». Для одной студии йоги это ещё терпимо. Для клуба с кассой, термами в выходные и сетью из трёх точек — уже нет: простой учёта или сайта с онлайн-оплатой бьёт по выручке и по нервам гостей на ресепшене.
При этом ставить полноценный Zabbix, Prometheus и Grafana «на вырост» без специалиста, который будет этим жить, — типичная ловушка. Через полгода алерты отключены, дашборды никто не смотрит, а лицензии и сервер мониторинга стоят денег. Задача практичнее: видеть заранее то, что ломается чаще всего, и доставлять сигнал тому, кто может среагировать — владельцу, старшему админу, подрядчику по серверам.
Что мониторить в первую очередь
Не всё подряд, а контур, от которого зависит день.
Доступность сервисов снаружи — открывается ли сайт, работает ли форма записи или оплаты, жив ли VPN для удалённой поддержки. Внешние проверки доступности с нескольких точек ловят проблемы DNS, сертификата и хостинга быстрее, чем звонок «у клиентов не грузится».
Сервер 1С и СУБД — не только «ping прошёл», а диск (свободное место и рост), память, загрузка CPU в пики, службы 1С и SQL/PostgreSQL. Падение базы в субботу утром на термах — классика, если ночью отработало обновление или разросся лог.
Резервное копирование — успех последнего задания, возраст последней удачной копии. Мониторинг бэкапа важнее красивого графика сети, если копии никто не проверял (см. резервное копирование без своего ИТ).
Критичная сеть — не каждый порт на каждом коммутаторе, а хотя бы: интернет-канал на площадке, основной маршрутизатор, иногда контроллер Wi‑Fi. Если «пропал интернет» — отдельный алерт, а не общий «что-то не так».
Почта и домен — реже падают, но истечение SSL на сайте или почтовом сервере любят делать сюрпризом в воскресенье.
Камеры и СКУД мониторят выборочно: недоступность регистратора или NVR часто важнее, чем ping каждой камеры.
Алерты — куда и с какой «шумностью»

Мониторинг без доставки сигнала — архив графиков. Для ИП и небольшой сети обычно хватает:
- Telegram или почта дежурному и подрядчику;
- эскалация — если за 15–30 минут никто не взял в работу, второй канал или звонок по регламенту;
- разделение срочного и информационного — «диск 85%» может быть предупреждением раз в день, «сайт недоступен 5 минут» — сразу.
Главное правило: мало алертов, но каждый значимый. Иначе люди отключают уведомления, и система слепнет в момент реального сбоя.
Ночные окна обслуживания стоит заглушать заранее в календаре мониторинга — иначе каждое плановое обновление превращается в ложную тревогу и подрывает доверие к системе.
«Лёгкий» стек против тяжёлого
Для одного-двух серверов и VPS часто достаточно связки: агент на хосте (или встроенные проверки облака) + внешняя проверка «сайт открывается» + централизованный сбор логов хотя бы ошибок 1С и веб-сервера. Многие хостеры и облака дают базовые метрики и алерты по CPU/RAM/диску — ими грех не пользоваться, если сервер уже там.
Zabbix, Nagios и тяжёлые «центры наблюдения» имеют смысл, когда:
- много хостов и сервисов;
- есть человек, который настраивает шаблоны и чистит шум;
- нужна глубокая корреляция и история на годы.
Для сети клубов без отдельной команды, которая целый день смотрит в мониторы, разумнее управляемый мониторинг от подрядчика: вы видите статус и инциденты, а администрирование серверов включает реакцию по согласованным срокам. Это ближе к модели ИТ-аутсорсинга, чем к покупке софта «чтобы было».
Отдельно стоит следить за сайтом и формами заявок: открывается ли главная, не истёк ли SSL-сертификат, отвечает ли сервер на отправку формы (тестовая заявка по расписанию). Это не заменяет веб-аналитику посещаемости, но помогает заметить «сайт лежит» раньше, чем перестанут приходить обращения.
Процесс: не только железо
Мониторинг работает, когда есть краткий регламент на типовые алерты. «Диск полон» — что чистим, кого спрашиваем, можно ли расширить том. «1С не отвечает» — перезапуск служб по порядку, кто звонит франчайзи, когда подключается подрядчик. Одна страница текста экономит часы паники.
Для сети площадок полезен единый дашборд «зелёный / жёлтый / красный» по клубам: директор видит картину, а не три разных чата с «у нас опять интернет».
Раз в месяц — короткий разбор: какие алерты были ложными, что добавить, что убрать. Иначе система раздувается и снова умирает от шума.
Чего мониторинг не делает
Он не чинит сам, не заменяет бэкапы и не закрывает дыры в гостевом Wi‑Fi. Он даёт время среагировать до того, как гость стоит у турникета, а база не открывается.
Если у вас пока только «администратор звонит, когда уже всё упало», имеет смысл начать с пяти проверок: сайт, 1С снаружи/изнутри, диск на сервере, бэкап, канал интернета. Остальное — следующими итерациями.
Хотите подобрать уровень мониторинга под одну площадку или сеть без разворачивания «центра управления полётами» — напишите нам, разберём контур и формат сопровождения.