Мониторинг ИТ-инфраструктуры нужен, чтобы узнать о проблеме раньше пользователей: увидеть рост температуры, заполнение диска, ошибки на порту или переход ИБП на батарею до того, как это станет простоем.
Рабочая схема строится не от красивой панели, а от трёх вопросов: что отслеживаем, как собираем данные и кто реагирует на алерт. Если на оповещение нельзя ответить действием, это не мониторинг, а шум.
Подобрать инфраструктуру под мониторинг: коммутаторы, ИБП, PDU, датчики среды, серверы, услуги ANDPRO.
Что разобрано в статье
Слои контроля
Железо, ОС, сеть, приложения, питание и среда: что смотреть отдельно и вместе.
Метрики и пороги
Как отделить warning от critical и почему чужие проценты нельзя переносить вслепую.
Сбор данных
Агенты, SNMP, IPMI/Redfish и syslog: где какой подход уместен.
Инструменты
Zabbix, Prometheus + Grafana и специализированные решения без привязки к одному бренду.
Алертинг
Как сделать так, чтобы оповещения доходили до нужного человека и не превращались в шум.
Железная база
Коммутаторы, ИБП, PDU, датчики среды и сервер под саму систему мониторинга.
Зачем нужен мониторинг
Без мониторинга об отказе часто узнают от пользователей: сайт не открывается, 1С тормозит, база недоступна, а в серверной уже перегрев. Мониторинг нужен, чтобы заметить деградацию раньше: диск заполняется, температура растёт, канал перегружен, порт даёт ошибки, сертификат скоро истечёт.
Хороший мониторинг решает три задачи: предупреждает о риске, помогает быстро найти причину при сбое и показывает тренды для планирования. Поэтому современный подход шире простого «пингуем сервер»: метрики, логи и события надо собирать так, чтобы они складывались в картину состояния инфраструктуры.
Что отслеживать: пять слоёв
| Слой | Что контролировать | Зачем это нужно |
|---|---|---|
| Железо | Температуры, вентиляторы, блоки питания, диски, RAID, ECC-ошибки памяти, состояние BMC. | Поймать аппаратную деградацию до падения сервиса. |
| ОС и ресурсы | CPU, RAM, swap, место на дисках, inode, процессы, системные сервисы. | Понять, где заканчивается ресурс и что вызывает тормоза. |
| Сеть | Доступность узлов, загрузку портов, ошибки, потери, состояние коммутаторов и маршрутизаторов. | Отделить проблему приложения от проблемы канала или оборудования. |
| Приложения | Доступность сайта, 1С, БД, почты, время отклика, очереди, ошибки, срок TLS-сертификатов. | Видеть сервис глазами бизнеса, а не только железа. |
| Питание и среда | ИБП, PDU, нагрузку по линиям, температуру, влажность, протечку, задымление, дверь шкафа. | Поймать аварии, которые не увидит серверный агент. |
Метрики и пороги: warning, critical и тренды
Собрать метрику недостаточно: нужен порог и понятная реакция. Обычно разделяют warning и critical. Warning говорит «нужно посмотреть», critical — «нужно действовать сейчас». Один и тот же процент загрузки может быть нормой для базы данных и тревожным сигналом для шлюза, поэтому пороги задают под систему, а не по универсальной таблице.
Тренды важны не меньше мгновенного значения. Диск, который растёт на несколько процентов в неделю, может быть безопасен сегодня, но приведёт к инциденту через месяц. По трендам планируют расширение СХД, замену дисков, увеличение каналов и перенос нагрузки до аварии.
Как собирают данные: агент, SNMP, IPMI/Redfish и syslog
Агент ставится на сервер и отдаёт подробные метрики ОС и приложений: ресурсы, процессы, сервисы, файловые системы. Это максимальная детализация, но её нужно сопровождать и обновлять.
SNMP используют для сетевого оборудования, ИБП, PDU, принтеров и другой инфраструктуры. Он удобен там, где агент ставить нельзя или не нужно: устройство само отдаёт состояние, счётчики и события.
IPMI/Redfish дают аппаратный слой сервера через BMC: температуры, вентиляторы, блоки питания, диски и удалённое управление. Это особенно важно, потому что BMC работает даже тогда, когда операционная система уже недоступна.
Syslog и логи нужны для диагностики: они объясняют, что происходило вокруг метрики. Практичная схема обычно комбинирует агент на серверах, SNMP на сети и питании, BMC на железе и централизованный сбор логов.
Инструменты мониторинга
Единственного правильного инструмента нет: выбор зависит от масштаба, компетенций команды и того, что уже работает в инфраструктуре. Частые варианты:
- Zabbix — комплексная система «всё в одном»: сбор, хранение, триггеры, оповещения, карты и шаблоны. Сильна в SNMP, агентах и классической инфраструктуре.
- Prometheus + Grafana — Prometheus собирает и хранит метрики, Grafana строит дашборды и помогает с визуализацией. Связка популярна для инфраструктуры, контейнеров и сервисных метрик. Такой класс решений ANDPRO использует и для собственного мониторинга.
- Специализированные решения — сетевой мониторинг, APM, журналы безопасности, мониторинг виртуализации и облачных сред.
Ключ не в бренде, а в покрытии: инструмент должен видеть критичные слои, хранить историю, показывать понятные дашборды и отправлять оповещения туда, где на них реально реагируют.
Алертинг без «алерт-усталости»
Главная болезнь мониторинга — поток сообщений, который перестают читать. Хороший алерт должен быть действенным: по нему понятно, что случилось, насколько это срочно, кто отвечает и что делать первым шагом. Всё информационное лучше оставлять в дашборде, а не отправлять в срочные уведомления.
Помогают severity, маршрутизация, группировка и эскалация. Critical идёт в немедленный канал и дежурному, warning может ждать рабочего времени. Один инцидент не должен превращаться в сотню однотипных сообщений. Шумные правила пересматривают регулярно, иначе даже правильные критичные алерты потеряются.
Мониторинг питания и среды серверной
Серверный агент не заметит протечку, открытие шкафа или отказ кондиционера. Поэтому для серверной комнаты нужен отдельный слой контроля: ИБП, управляемые PDU и датчики среды.
Для ИБП важны заряд, нагрузка, состояние батарей и переход на батарейное питание. Для PDU — нагрузка по линиям и розеткам, а при необходимости удалённое отключение. Для среды — температура, влажность, протечка, задымление и открытие двери. Эти события часто дают время на реакцию до отказа оборудования.
С чего начать: практический порядок
- Инвентаризируйте инфраструктуру. Зафиксируйте серверы, виртуализацию, сеть, ИБП, PDU, сервисы, базы и ответственных.
- Начните с доступности критичных сервисов. Сайт, 1С, БД, почта, VPN и файловые ресурсы должны контролироваться первыми.
- Добавьте базовые метрики серверов. CPU, RAM, диски, файловые системы, службы и аппаратное здоровье через BMC.
- Подключите сеть, питание и среду. SNMP для коммутаторов, ИБП и PDU, датчики температуры, влажности и протечки.
- Настройте алерты по ролям. Дежурный видит critical, руководитель — сводку и тренды, информационный шум остаётся в дашборде.
- Пересматривайте правила. После каждого инцидента уточняйте пороги и маршрутизацию: мониторинг должен становиться тише и полезнее.
Как ANDPRO помогает с инфраструктурой мониторинга
Мониторинг — это программный слой, но он опирается на железо, которое корректно отдаёт телеметрию. ANDPRO подберёт управляемые коммутаторы со SNMP, серверы с BMC/IPMI/Redfish, ИБП, PDU, датчики среды и отдельный узел под систему мониторинга.
Перед закупкой важно проверить совместимость по интерфейсам управления, сетевую схему, запас по мощности и место для хранения метрик. Мы поможем собрать спецификацию, подготовить КП и не завязать мониторинг на оборудование, которое не умеет отдавать нужные данные.
Частые вопросы
Чем мониторинг отличается от наблюдаемости?
Мониторинг отслеживает известные метрики, события и пороги. Наблюдаемость шире: она объединяет метрики, логи, трассировки и контекст, чтобы разобраться не только в известной, но и в новой проблеме.
Что важнее всего отслеживать в первую очередь?
Начните с доступности критичных сервисов, места на дисках, здоровья железа через BMC, базовых ресурсов серверов, состояния сети и питания. Это даёт быстрый эффект и закрывает самые частые причины простоев.
Нужен ли агент на каждом сервере?
Не всегда. Серверные ресурсы удобнее собирать агентом, сетевое оборудование и ИБП — по SNMP, аппаратное состояние сервера — через IPMI или Redfish. Обычно эти методы комбинируют.
Zabbix или Prometheus + Grafana: что выбрать?
Оба варианта рабочие. Zabbix удобен как комплексная система для классической инфраструктуры и SNMP. Prometheus + Grafana часто выбирают для гибкого сбора метрик, дашбордов, контейнеров и сервисной наблюдаемости. Выбор зависит от задач и команды.
Как не утонуть в алертах?
Оставляйте только действенные оповещения, разделяйте severity, группируйте связанные события, настраивайте маршрутизацию и регулярно убирайте шумные правила. Информационные события лучше показывать в дашборде, а не слать как срочные.
Зачем мониторить питание и среду?
Отказ кондиционера, перегрев, протечку или переход ИБП на батарею серверный агент может не увидеть. Эти риски закрывают управляемые ИБП/PDU и датчики среды, которые предупреждают о проблеме до отказа оборудования.
Авторство и ответственность
Материал объясняет принципы мониторинга ИТ-инфраструктуры и не заменяет проектирование под конкретную сеть, серверы, регламенты реагирования и требования доступности. Перед закупкой оборудования нужно сверить интерфейсы управления, совместимость по SNMP/IPMI/Redfish, запас мощности, сетевую схему и сценарии оповещений.
Материал подготовлен при участии AI-ассистента, прошёл редакторскую вычитку и должен пройти техническое ревью QC-Lab ANDPRO перед публикацией.
Для подбора, проверки совместимости и КП: info@andpro.ru, +7 (495) 545-48-70, +7 (800) 707-78-15.
Дата последнего обновления материала: 2 июля 2026.
