Мониторинг ИТ-инфраструктуры — это система, которая сама опрашивает серверы, сеть и приложения по расписанию. Она присылает алерт при отклонении вместо того, чтобы вы узнавали о сбое от бухгалтера с фразой «1С не работает». Настраивается один раз, дальше требует только реакции на алерты и периодической проверки самих правил.
Что учитывать при выборе системы мониторинга
Малому и среднему бизнесу без своего центра мониторинга (NOC) тяжёлая enterprise-платформа не нужна. Достаточно системы, которая опрашивает ключевые узлы, хранит историю и умеет присылать алерт в мессенджер или на почту. Два инструмента закрывают почти весь рынок таких задач. Zabbix — агентный опрос с готовыми шаблонами под серверы и сетевое оборудование. Prometheus вместе с Grafana — метрики через HTTP и гибкие запросы, но настройка занимает больше времени.
Разница ощущается не в «красивости» дашборда, а в том, что именно можно опросить и с какой периодичностью. Zabbix из коробки умеет опрашивать элемент данных с интервалом от нескольких секунд и вплоть до 86 400 секунд — суток, если метрика меняется редко. У Prometheus глобальный интервал опроса (scrape_interval) по умолчанию — 15 секунд. Его можно переопределить отдельно для конкретной задачи мониторинга.
Как часто опрашивать инфраструктуру?
Частый опрос даёт более раннее обнаружение сбоя. Но он же нагружает и опрашиваемое оборудование, и саму систему мониторинга. Для критичных узлов — сервер 1С, основной коммутатор, канал в интернет — разумный ориентир близок к дефолту Prometheus в 15 секунд: это компромисс между точностью и нагрузкой на сеть, подтверждённый практикой инструмента, а не произвольная цифра. Для второстепенных параметров — свободное место на диске резервного сервера, температура в серверной — хватает интервала в минуты, а не в секунды.
Есть ошибка, которая встречается почти в каждом первом внедрении. Все элементы данных ставят на один и тот же короткий интервал «для надёжности». В результате система мониторинга сама создаёт заметную нагрузку на сеть и на опрашиваемые устройства, а полезность данных при этом не растёт. Сбой сервера раз в сутки одинаково хорошо ловится и при опросе каждые 15 секунд, и при опросе раз в две минуты.
Сколько истории хранить и зачем
История нужна для двух разных задач. Первая — разбор инцидента: что происходило перед сбоем. Вторая — анализ тренда: растёт ли нагрузка на диск за последние три месяца. Для первой задачи достаточно недель, для второй — месяцев. Prometheus по умолчанию хранит метрики 15 дней, если не задать флаг --storage.tsdb.retention.time вручную. Этого хватает на разбор инцидента, но мало для тренда — длинную историю для важных метрик стоит настраивать отдельно и заранее.
Требование наблюдать за соответствием ИТ-услуг согласованному уровню обслуживания закреплено не только производителями ПО. Оно есть и в стандарте ГОСТ Р ИСО/МЭК 20000-1-2021, который действует с 30 апреля 2022 года и заменил версию стандарта 2013 года. Формально стандарт добровольный. Но на него часто ссылаются в договорах с ИТ-подрядчиками и во внутренних регламентах — если такой договор есть у вашей компании, стоит проверить, не обещали ли вы уже вести мониторинг документально.
Что мониторинг может обнаружить раньше пользователя?
Три класса событий система мониторинга видит раньше сотрудников почти всегда. Первый — рост нагрузки на диск и процессор: пользователь замечает проблему только когда система уже заметно «тормозит». Второй — потеря связи с удалённым офисом или облаком: для сотрудника это выглядит как случайный обрыв, а для мониторинга — как пропавший ответ на регулярный опрос. Третий — деградация канала интернета: задержка растёт постепенно, и сотрудники жалуются, когда она уже втрое выше нормы.
Базовая проверка доступности узла — команда ping — работает поверх протокола ICMP, описанного ещё в RFC 792 в сентябре 1981 года. Опрос показателей сетевого оборудования — загрузка портов коммутатора, температура — чаще всего идёт по протоколу SNMP, стандартизированному в RFC 1157 в мае 1990 года. Оба протокола старше большинства ИТ-специалистов, которые ими пользуются сегодня. Это не недостаток, а признак того, что менять базовый механизм опроса не было практической причины почти сорок лет.
Отдельная категория событий — информационная безопасность, и здесь важно не путать инфраструктурный мониторинг с сервисом реагирования на инциденты (MDR или SOC). По данным отчёта Kaspersky MDR за 2024 год, среднее время расследования и реагирования на серьёзные инциденты у клиентов сервиса выросло на 48 % год к году. При этом система получает порядка 15 000 событий безопасности в сутки на один узел, из которых после фильтрации остаётся около двух подтверждённых серьёзных инцидентов в день. Обычный мониторинг инфраструктуры такие события не разбирает — он видит только «узел не отвечает» или «нагрузка выросла».
Во сколько обходится час без мониторинга?
Цена вопроса не абстрактная. По опросу ITIC, охватившему свыше тысячи компаний с ноября 2023 по март 2024 года, для более 90 % средних и крупных компаний час простоя ИТ-инфраструктуры обходится дороже 300 000 $, без учёта штрафов и судебных издержек. У 41 % опрошенных час простоя стоит от 1 до 5 и более миллионов долларов. Цифры западные, но логика применима и к российскому бизнесу: чем раньше обнаружен сбой, тем короче фактический простой и тем ниже суммарные потери.
Разницу удобно посчитать и через уровень доступности (SLA). При доступности 99 % допустимый простой — 5256 минут в год, это 87,6 часа, или 3,65 суток. При 99,9 % — уже 525,6 минуты, то есть 8,76 часа. При 99,99 % — всего 52,6 минуты в год. Разница между «три девятки» и «две девятки» — это разница между простоем в несколько часов и простоем в несколько суток за год, и именно мониторинг превращает эту разницу из теории в практику: он не увеличивает саму доступность оборудования, но сокращает время до момента, когда о сбое узнают и начинают чинить.
Сравнение подходов: своя система или готовый мониторинг
| Критерий | Своя установка Zabbix/Prometheus | Готовый сервис круглосуточного мониторинга |
|---|---|---|
| Кто настраивает пороги алертов | ИТ-специалист компании, разово и при изменениях | Инженер-подрядчик, с пересмотром по факту инцидентов |
| Кто реагирует на алерт ночью | Тот, кому пришло уведомление, если он на связи | Дежурная смена подрядчика |
| Стоимость входа | Время специалиста на настройку и поддержку | Абонентская плата за услугу |
| Риск «мониторинг настроен и забыт» | Высокий — пороги устаревают вместе с инфраструктурой | Ниже, обновление входит в услугу |
| Подходит для | Штата с постоянным системным администратором | Компании без своего дежурного ИТ-специалиста |
Выбор чаще всего определяется не техникой, а тем, кто физически среагирует на алерт в три часа ночи в пятницу перед длинными выходными. Система мониторинга сама по себе не чинит сбой. Она только сокращает время до момента, когда о нём узнает человек, а дальше решение принимает уже он — своими руками или через круглосуточный мониторинг сетей на аутсорсе.
Типичные ошибки при внедрении мониторинга
Мониторинг ставят и не проверяют цепочку алерта до конца. Система исправно фиксирует сбой, но письмо уходит на давно неактуальный адрес, а телеграм-бот остановлен полгода назад. Обнаруживается это обычно уже во время реального инцидента — и это хуже, чем отсутствие мониторинга вовсе, потому что создаёт ложное чувство защищённости.
Второй частый случай — мониторят только серверы, пропуская сетевое оборудование и каналы связи. Сервер отвечает исправно, а сотрудники не работают, потому что упал коммутатор в серверной или деградировал канал у провайдера. Если сеть не сегментирована на VLAN'ы, локализовать источник проблемы по данным мониторинга сложнее — придётся проверять сегмент за сегментом вручную.
Третья ошибка — мониторинг без резервных копий рассматривают как замену бэкапу. Это разные задачи. Мониторинг сообщает о сбое быстрее, но не восстанавливает данные. Правило 3-2-1 для резервного копирования работает независимо от того, насколько быстро вы узнали о сбое.
Если внедрять и поддерживать мониторинг своими силами некому — круглосуточный мониторинг сетей берёт на себя настройку порогов, дежурство и разбор ложных срабатываний, оставляя вам только решения по итогам алерта, а не саму слежку за инфраструктурой.
Частые вопросы
С чего начать мониторинг, если раньше его не было?
Начните с трёх точек: доступность интернет-канала, работоспособность основного сервера (1С, файловый сервер) и загрузка диска на нём. Эти три параметра закрывают большинство сценариев «сотрудники не могут работать». Остальные метрики можно добавлять постепенно, по мере появления реальных инцидентов.
Сколько метрик нужно снимать для офиса на 50 рабочих мест?
Точное число зависит от состава оборудования, а не от размера офиса — ориентироваться стоит на устройства, а не на людей. На каждое ключевое устройство (сервер, коммутатор, канал связи) обычно заводят метрики загрузки процессора, памяти, диска, температуры, доступности порта и сетевой задержки. Итоговый набор для типичного офиса такого размера остаётся управляемым и без выделенного администратора мониторинга — важнее не количество метрик, а то, что каждая из них привязана к реальному сценарию сбоя, а не добавлена «на всякий случай».
Чем мониторинг отличается от антивируса и файрвола?
Антивирус и файрвол — средства защиты, они блокируют или обнаруживают конкретные угрозы. Мониторинг инфраструктуры не защищает, а наблюдает. Он одинаково зафиксирует и сбой из-за атаки, и сбой из-за отказа диска или ошибки в настройках, но не отличит одно от другого без дополнительного анализа.
Нужен ли отдельный сотрудник для мониторинга?
Для настройки нужен человек с опытом администрирования сети и серверов — хотя бы на этапе внедрения. Для повседневного дежурства выделенный сотрудник не обязателен, если алерты доходят до того, кто и так отвечает за инфраструктуру, либо эту функцию передают внешнему сервису.
