Мониторинг серверов: инструменты и лучшие практики

Мониторинг серверов работает как кардиомонитор в палате: пока показатели в норме — система тихо собирает метрики, а при отклонении поднимает тревогу до того, как сбой заметят пользователи. Речь здесь о корпоративной инфраструктуре — production-серверах, базах данных и сервисах компании, а не об игровых сервер-листингах. Ниже разберем, что измерять, какими инструментами собирать данные, как настроить алертинг и какие практики отличают рабочую систему наблюдения от набора графиков, на которые никто не смотрит.

Главная ценность мониторинга — перейти от тушения пожаров к их предотвращению. Без наблюдения о проблеме сообщает пользователь, звонком о том, что сервис недоступен; с мониторингом инженер видит рост задержек или заполнение диска раньше, чем это перерастет в отказ.

Наблюдение завязано на обещания бизнесу. Договорные гарантии доступности фиксирует SLA — например, 99,9% в месяц. Внутреннюю цель команды задает более строгий порог SLO, который оставляет запас до нарушения SLA. Мониторинг показывает, укладывается ли инфраструктура в эти цифры, и сигнализирует, когда бюджет ошибок начинает таять.

Один сервер с некритичным сервисом можно проверять вручную. Но как только машин становится больше десятка, а простой стоит денег, ручной контроль не масштабируется. Тогда система мониторинга окупается первым же предотвращенным простоем — особенно там, где отказ останавливает продажи или производство.

Полная картина складывается из четырех уровней наблюдения, и пропуск любого оставляет слепую зону, в которой и прячется будущий инцидент. Базовый слой — системные метрики: загрузка CPU, занятость RAM, заполнение и латентность дисков, трафик и ошибки сети, температура компонентов. Это фундамент, потому что при упершемся в потолок процессоре или заполненном диске страдают все сервисы поверх.

Уровнем выше идут сервисные метрики — запущен ли процесс, отвечает ли порт, проходит ли healthcheck. Сервер может быть жив по системным показателям, но веб-сервер или база при этом не отвечают, и отдельная проверка ловит именно это. Дальше — прикладной уровень: время ответа на запросы в БД, длина очередей задач, индекс удовлетворенности Apdex. Эти цифры показывают не «жив ли сервер», а «хорошо ли работает то, ради чего он стоит». Верхний слой связывает технику с деньгами через бизнес-метрики: число транзакций, оформленных заказов, активных сессий. Их падение при зеленых системных показателях — сигнал, что проблема в бизнес-логике, и поймать его можно только прикладным наблюдением.

Данные с серверов снимают двумя принципиально разными подходами. Агент — это служба, установленная на хосте: Zabbix Agent, node_exporter для Prometheus, универсальный сборщик Telegraf. Она знает систему изнутри и отдает подробные метрики, включая те, что снаружи не видны, но требует установки и обновления agent на каждой машине. Безагентный сбор, наоборот, работает по сетевым протоколам без установки ПО на цель: SNMP опрашивает коммутаторы и принтеры, IPMI снимает данные о железе через контроллер управления, SSH и WMI собирают показатели разовыми командами. Agentless удобен там, где агента поставить нельзя — на сетевом оборудовании или закрытых устройствах, и под него пригодится грамотно спроектированное сетевое оборудование с поддержкой нужных протоколов.

Различают и направление передачи. В pull-модели сервер мониторинга сам опрашивает цели по расписанию — так работает Prometheus; в push-модели агент отправляет метрики сам, что удобно для коротких задач и узлов за NAT. Отдельный нижний слой данных снимают с контроллера BMC по IPMI: температура, обороты вентиляторов, состояние блоков питания, записи журнала событий аппаратуры. Эти метрики приходят, даже когда ОС не загружена, поэтому деградацию диска или перегрев ловят на уровне платформы.

Рынок наблюдения сложился вокруг нескольких систем с разными сильными сторонами, и под любую из них мы подбираем серверы с запасом памяти и быстрыми дисками под базу метрик. Zabbix 7.0 LTS — зрелая система с агентами, шаблонами и встроенным алертингом, популярная в корпоративной среде и ЦОД; поддержка LTS-ветки идет до июня 2029 года, а сильна она там, где нужен единый инструмент под железо, сеть и приложения с готовыми шаблонами из коробки.

Связка Prometheus и Grafana стала стандартом для контейнеров и Kubernetes: первый собирает метрики по pull-модели в time-series базу, вторая отвечает за визуализацию. Prometheus — проект фонда CNCF, выпущенный в версии 3.0 в ноябре 2024 года; Grafana развивается параллельно, актуальная ветка — 12 и новее. Под динамичную инфраструктуру с автообнаружением целей эта пара подходит лучше классических систем.

Рядом стоят еще два инструмента под разные задачи: Checkmk — корпоративный stack на базе движка Nagios с обширной библиотекой проверок, а Netdata — легкий per-host мониторинг с метриками в реальном времени при низком потреблении ресурсов. В отечественном сегменте развиваются системы на открытых движках: Astra Monitoring на стеке VictoriaMetrics, продукт «Пульт» и форк Glaber на основе Zabbix — их выбирают, когда требуется запись в реестре российского ПО.

Метрики отвечают на вопрос «что сломалось», но не «почему». Полную наблюдаемость — observability — дает связка трех видов данных: метрик, логов и трейсов. Логи централизуют, чтобы не ходить по серверам руками: Loki с агентом Promtail хранит их компактно и дружит с Grafana, стек ELK на базе Elasticsearch дает мощный полнотекстовый поиск, а среди отечественных продуктов задачу закрывают системы класса Graylog и аналоги на OpenSearch.

Трейсинг прослеживает путь одного запроса через цепочку сервисов и показывает, на каком шаге теряется время; инструменты Jaeger и Tempo вместе со стандартом сбора OpenTelemetry дают эту картину для распределенных систем. Ценность observability — именно в связи данных: по всплеску метрики перейти к логам того же интервала, а от них — к трейсу конкретного медленного запроса. Когда метрики, логи и трейсы собраны в одном контуре, разбор инцидента занимает минуты вместо часов поиска вслепую.

Сбор данных без оповещений бесполезен: график проблему покажет, но только если на него смотрят. Алертинг превращает наблюдение в действие, и качество оповещений начинается с того, какие сервисы считать критичными — расставить приоритеты помогает аудит безопасности, который выявляет ключевые узлы инфраструктуры. Простые пороги срабатывают по абсолютному значению вроде заполнения диска на 90%, но более точный подход — алерты на основе SLO: система сравнивает скорость расходования бюджета ошибок и отличает короткий всплеск от устойчивой деградации, уходя от ложных тревог по каждому пиковому замеру.

Уведомления отправляют туда, где их увидят: Telegram-боты стали массовым каналом в РФ, email подходит для некритичных событий, мессенджеры Mattermost и Slack встраивают алерты в рабочие чаты. Если на алерт не отреагировали за заданное время, срабатывает эскалация на следующего по очереди дежурного. На время плановых работ оповещения глушат через silence, а связанные алерты подавляют через inhibition, чтобы один отказ не породил лавину сообщений — без этих механизмов команда быстро устает от шума.

За годы эксплуатации индустрия выработала несколько методик, которые помогают решить, какие именно метрики собирать и на что реагировать. Метод USE Брендана Грегга предлагает для каждого ресурса измерять использование, насыщение и ошибки: применительно к диску это занятость, длина очереди и сбои ввода-вывода. Подход дает системный чек-лист и не дает забыть про насыщение, которое при ручной настройке порогов упускают первым. Для сервисов и микросервисов работает метод RED Тома Уилки — частота запросов, доля ошибок и время ответа: эти три показателя описывают здоровье сервиса глазами его пользователя и хорошо ложатся на дашборды.

Подход Google SRE сводит наблюдение за сервисом к четырем «золотым сигналам»: задержка, трафик, ошибки, насыщение. И отдельная практика, экономящая больше всего времени: к каждому алерту прикладывают runbook — короткую инструкцию, что проверить и сделать при срабатывании. Дежурный не вспоминает порядок действий, а открывает готовый сценарий.

Одни и те же метрики разным людям нужно показывать по-разному, поэтому дашборды разделяют по аудитории, а не делают один универсальный экран на всех. NOC-дашборд для дежурной смены показывает состояние ключевых сервисов крупно и без деталей: зеленое работает, красное требует внимания, и задача такого экрана — за секунду показать, есть ли проблема и где она.

Дашборды для DevOps и разработчиков, наоборот, насыщены деталями: разбивка по инстансам, перцентили задержек, корреляция метрик — здесь важна глубина, потому что по этим экранам разбирают конкретный инцидент. А executive-дашборд переводит технику в язык бизнеса: доступность за месяц, выполнение SLA, тренды по инцидентам, ведь руководителю важны не графики загрузки CPU, а соответствие инфраструктуры обещаниям.

Выбор инструментов в РФ определяется не только технической стороной, но и регуляторными требованиями. Для части заказчиков ключевым становится переход на отечественные продукты — это часть импортозамещения серверов и всей сопутствующей инфраструктуры. Для госструктур и значимых объектов КИИ важна запись в реестре российского ПО: сам Zabbix — зарубежный open-source латвийской компании и в реестр не входит, зато туда включены продукты на его базе и отечественные системы «Пульт», Astra Monitoring и Glaber.

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

Большинство провалов в наблюдении — не про инструменты, а про процессы вокруг них. Чаще всего система собирает метрики, дашборды нарисованы, но оповещения уходят в чат, который никто не открывает, — наблюдение без реакции не отличается от его отсутствия, и инцидент все равно замечают по жалобе. Близкая по природе ошибка — сотни алертов уровня «warning», на которые нечего ответить: они приучают команду игнорировать оповещения, и в этом шуме теряется тот единственный сигнал, что действительно требовал действия. Лечится это аудитом, при котором алерт без сценария реагирования удаляют.

Третья ошибка — дашборды без владельца: брошенные после разовой задачи, они со временем показывают неверные данные и сбивают с толку, поэтому у каждого экрана должен быть ответственный, который держит его в актуальном состоянии или удаляет за ненадобностью.

Сводка по основным системам помогает выбрать стартовую точку под конкретную инфраструктуру.

Рабочую систему наблюдения собирают не с выбора инструмента, а с ответа на вопрос, что и зачем измерять. Короткий план для старта:

Такой контур ловит проблемы до того, как их заметят пользователи, и не тонет в собственном шуме.

Это автоматический сбор показателей работы серверов и оповещение ответственных при отклонениях. Система постоянно измеряет загрузку, доступность и ошибки, чтобы инженер узнал о проблеме раньше пользователя.

Минимум — системные: загрузка CPU, занятость RAM, заполнение и латентность дисков, трафик сети, температура. Поверх них добавляют проверки доступности сервисов и портов. Без прикладного слоя картина будет неполной.

Zabbix удобнее под классический парк серверов и сетевого железа с готовыми шаблонами. Prometheus с Grafana сильнее в динамичной cloud-native среде и Kubernetes. Выбор определяет тип инфраструктуры, а не абстрактное превосходство.

Сами Zabbix, Prometheus и Grafana бесплатны — основные расходы это сервер под систему и время инженеров на настройку. Для парка в сотню хостов хватает машины на 4-8 ядер и 16 ГБ RAM с быстрым диском под базу метрик.

USE применяют к ресурсам (диск, память, сеть) и измеряют использование, насыщение и ошибки. RED применяют к сервисам и измеряют частоту запросов, долю ошибок и время ответа. Первый — про железо, второй — про работу приложения.

В РФ массовый выбор — Telegram-боты за скорость и бесплатность. Email подходит для некритичных событий, мессенджеры команды — для рабочих чатов. Для критичных инцидентов с дежурствами добавляют каналы с гарантированным дозвоном.

Да, через agentless-протоколы: SNMP для сетевого оборудования, IPMI для железа, SSH или WMI для разовых проверок. Это удобно там, где агента поставить нельзя, но детализация будет ниже, чем с установленным агентом.

В реестре российского ПО присутствуют системы на базе открытых движков: «Пульт» и Glaber на основе Zabbix, Astra Monitoring на стеке VictoriaMetrics. Их выбирают, когда требуется формальная запись в реестре.

Внедряете наблюдение с нуля или хотите разгрести существующий зоопарк алертов? Инженеры Serverzilla подберут стек под вашу инфраструктуру (Zabbix, Prometheus с Grafana или Checkmk), развернут сбор метрик с парка серверов и спроектируют алертинг с runbook-ами. Начнем с аудита ИТ-инфраструктуры и предложим решение под ваши SLO. Оставьте заявку.