Классический мониторинг инфраструктуры с Zabbix: от установки до Enterprise-решений

Представьте инфраструктуру среднего банка: 5000 серверов, 2000 единиц сетевого оборудования, десятки баз данных. Если с каждого устройства собирать всего 100 метрик раз в минуту, система мониторинга должна принимать, обрабатывать, оценивать на предмет аварий и записывать на диск более 11 000 значений каждую секунду. Монолитное приложение захлебнётся под такой нагрузкой в первый же час работы. Способность Zabbix выживать и масштабироваться в подобных условиях заложена не в оптимизации конкретного куска кода, а в его строгой, раздельной архитектуре.

Анатомия системы: пять столпов Zabbix

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

1. Zabbix Server (Ядро)

Это центральный процесс, написанный на языке C для максимального быстродействия. Zabbix Server — это мозг системы. Он не хранит данные долгосрочно и не рисует графики. Его задачи:

Сбор данных (опрос агентов и прием данных от них).

Вычисление триггеров (сравнение полученных метрик с порогами аварий).

Отправка уведомлений (генерация email, сообщений в Telegram или вызов webhook).

Внутри Server состоит из множества подпроцессов. Например, pollers (поллеры) сами ходят за метриками, trappers (трапперы) слушают входящие соединения, а escalators (эскалаторы) отвечают за логику отправки алертов. Если система начинает тормозить, инженер настраивает количество конкретных подпроцессов в конфигурационном файле, а не просто "выделяет больше оперативной памяти".

2. База данных (Память)

Zabbix Server абсолютно "амнезичен" без базы данных. В реляционной СУБД (чаще всего MySQL/MariaDB или PostgreSQL) хранится всё:

Конфигурация (какие узлы мониторить, какие пароли использовать).

Исторические данные (каждое собранное значение).

Динамика или тренды (усредненные значения за час для долгосрочного хранения).

События (когда произошла авария и когда она закрылась).

Именно база данных в 90% случаев становится узким местом (bottleneck) при масштабировании мониторинга. Скорость дисковой подсистемы (IOPS), на которой лежит БД, определяет максимальный размер инсталляции Zabbix.

3. Zabbix Frontend (Веб-интерфейс)

Лицо системы, написанное на PHP. Frontend работает под управлением веб-сервера (Apache или Nginx). Важнейший архитектурный нюанс: веб-интерфейс практически не общается с Zabbix Server напрямую.

Когда вы открываете график в браузере, Frontend делает SQL-запрос напрямую в Базу данных, минуя Server. Когда вы добавляете новый сервер для мониторинга в интерфейсе, Frontend записывает эту конфигурацию в Базу данных. Zabbix Server раз в минуту (по умолчанию) перечитывает конфигурацию из БД в свою оперативную память (Configuration Cache) и только тогда начинает мониторить новый узел.

!Архитектура Zabbix: потоки данных между Server, DB, Frontend и Agents

4. Zabbix Agent

Легковесная служба, устанавливаемая на целевые ОС (Linux, Windows). Агент имеет прямой доступ к ядру ОС, файловой системе и счетчикам производительности. Он может работать в двух режимах: пассивном (ждет запроса от сервера) и активном (сам собирает метрики и отправляет их на сервер).

5. Zabbix Proxy

Прокси-сервер — это "младший брат" Zabbix Server. Он устанавливается в удаленных дата-центрах, закрытых сетевых сегментах или филиалах. Прокси берет на себя черновую работу: собирает метрики с локальных агентов, буферизует их в свою собственную небольшую базу данных (часто SQLite) и затем пакетами отправляет на центральный Zabbix Server.

Подготовка Linux-окружения: фундамент для установки

Установка Zabbix из исходных кодов (компиляция) применяется редко и только для специфических платформ. В Enterprise-среде стандартом является установка из официальных пакетных репозиториев (APT для Debian/Ubuntu или DNF для RHEL/AlmaLinux/Rocky).

Перед выполнением команд apt install или dnf install, инфраструктура должна быть подготовлена. Ошибки на этом этапе гарантируют проблемы в будущем.

Синхронизация времени (NTP)

В системах мониторинга время — это критический параметр. Если время на сервере базы данных отстает от времени на Zabbix Server на 2 минуты, метрики будут записываться "в прошлое", триггеры начнут ложно срабатывать, а графики отобразят разрывы. Службы chronyd или systemd-timesyncd должны быть настроены и синхронизированы с надежными NTP-серверами до начала установки компонентов.

Выбор СУБД и кодировки

Исторически Zabbix поддерживает MySQL и PostgreSQL. Для новых инсталляций часто выбирают PostgreSQL из-за встроенной поддержки партиционирования таблиц (TimescaleDB), что радикально решает проблему очистки старых данных. Однако MySQL/MariaDB остается самым популярным и простым в настройке вариантом.

Критический нюанс при создании базы данных MySQL — правильная кодировка и параметры сопоставления (collation). Zabbix требует строгой чувствительности к регистру. Имена хостов Server-A и server-a — это разные объекты. При создании БД необходимо использовать: CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

Использование стандартного utf8mb4_general_ci (case-insensitive) приведет к тому, что база данных откажется импортировать схему Zabbix, выдав ошибку о дублирующихся ключах, так как для нее Host1 и host1 станут идентичными.

Проблема безопасных функций в MySQL 8.0+

Современные версии MySQL по умолчанию запрещают создание пользовательских функций без строгих гарантий безопасности. Схема базы данных Zabbix использует такие функции. Поэтому перед импортом схемы необходимо временно ослабить этот параметр: set global log_bin_trust_function_creators = 1; После успешного импорта структуры таблиц этот параметр обязательно возвращается в значение 0 ради безопасности.

Пошаговая логика развертывания

Процесс установки Zabbix Server с MySQL и Nginx на современный Linux-дистрибутив подчиняется строгой последовательности. Попытка запустить веб-интерфейс до импорта базы данных приведет к фатальным ошибкам PHP.

Шаг 1. Подключение официального репозитория. Штатные репозитории ОС содержат безнадежно устаревшие версии Zabbix (например, версию 4.0 или 5.0, когда актуальна 7.0). Установка начинается с загрузки .deb или .rpm пакета zabbix-release, который добавляет ключи GPG и ссылки на серверы repo.zabbix.com.

Шаг 2. Установка пакетов. Устанавливается мета-пакет. Для связки с MySQL и Nginx команда выглядит как установка zabbix-server-mysql, zabbix-frontend-php, zabbix-nginx-conf, zabbix-sql-scripts и zabbix-agent.

Шаг 3. Инициализация базы данных. После создания пустой БД с правильным COLLATE, в нее загружается схема и начальные данные. В пакете zabbix-sql-scripts поставляется сжатый файл server.sql.gz. Импорт выполняется утилитой zcat, которая читает архив и передает SQL-команды в клиент базы данных. Этот процесс может занимать от 1 до 5 минут, так как создаются сотни таблиц и загружаются дефолтные шаблоны мониторинга.

Шаг 4. Конфигурация Zabbix Server. Главный конфигурационный файл — /etc/zabbix/zabbix_server.conf. На этапе установки в нем необходимо изменить ровно один параметр: DBPassword. Сервер должен знать, как подключиться к базе данных. Остальные параметры (количество поллеров, размеры кэшей) на старте можно оставить по умолчанию.

Шаг 5. Настройка веб-сервера и PHP. Zabbix Frontend требователен к настройкам PHP. Конфигурационный файл Nginx для Zabbix (обычно /etc/zabbix/nginx.conf) требует раскомментирования строк с директивами listen (порт 8080 или 80) и server_name. В настройках PHP-FPM обязательно задается часовой пояс (date.timezone), иначе веб-интерфейс откажется завершать процесс установки.

Шаг 6. Запуск и автозагрузка. Только после выполнения всех предыдущих шагов службы zabbix-server, zabbix-agent, nginx и php-fpm запускаются и добавляются в автозагрузку (systemctl enable --now).

Невидимые барьеры: Сеть и Mandatory Access Control

Частая ситуация: службы запущены, статус active (running), но веб-интерфейс пишет "Zabbix server is not running", а агенты не присылают данные. Проблема кроется на уровне ОС.

Сетевые порты

Компоненты Zabbix общаются по строго определенным TCP-портам, которые должны быть открыты в Firewall (iptables, firewalld или ufw):

TCP 10051 — слушает Zabbix Server (и Zabbix Proxy). Сюда присылают данные активные агенты и прокси.

TCP 10050 — слушает Zabbix Agent. Сюда стучится сервер для пассивных проверок.

TCP 80/443 — слушает веб-сервер для доступа к Frontend.

SELinux (Security-Enhanced Linux)

В дистрибутивах семейства RHEL (CentOS, Rocky, AlmaLinux) по умолчанию включен SELinux в режиме Enforcing. Это система принудительного контроля доступа. Даже если процесс запущен от пользователя root, SELinux может запретить ему определенные действия.

Для Zabbix SELinux создает две классические проблемы:

Веб-серверу (httpd/nginx) запрещено устанавливать исходящие сетевые соединения. Из-за этого Frontend не может подключиться к Zabbix Server на порт 10051, чтобы проверить его статус. Решается включением булева значения: setsebool -P httpd_can_connect_zabbix on.

Zabbix Server не может подключиться к нестандартным портам баз данных или внешним скриптам.

Отключение SELinux (setenforce 0) — это плохая практика, нарушающая стандарты корпоративной безопасности. Правильный подход — установка пакета политик zabbix-selinux-policy, который автоматически настраивает нужные контексты и разрешения для демонов Zabbix.

Масштабирование архитектуры: роль Zabbix Proxy

Когда инфраструктура выходит за пределы одного дата-центра, прямая отправка метрик от агентов к центральному серверу становится неэффективной и опасной.

Представьте филиал с 200 серверами. Если канал связи между филиалом и головным офисом обрывается на час, метрики за этот час будут безвозвратно потеряны. Кроме того, центральный Zabbix Server вынужден поддерживать 200 отдельных TCP-соединений через WAN-канал.

Внедрение Zabbix Proxy меняет топологию. Прокси устанавливается внутри филиала.

Все 200 локальных агентов отправляют данные на локальный IP-адрес Proxy.

Proxy сохраняет эти данные в свою БД.

Proxy устанавливает одно соединение с центральным Zabbix Server и отправляет данные сжатым потоком.

!Сравнение топологий: прямая связь агентов с сервером против использования Zabbix Proxy

Если канал связи падает, Proxy продолжает собирать данные. Как только связь восстанавливается, он выгружает всю накопленную историю на центральный сервер. Графики достраиваются, потери данных не происходит.

Zabbix Proxy не вычисляет триггеры и не отправляет алерты. Его задача — исключительно сбор и буферизация. Конфигурацию (какие метрики собирать) Proxy получает от центрального сервера. Это делает управление централизованным: инженеру не нужно заходить на прокси-сервер для добавления нового узла сети, всё делается в едином веб-интерфейсе.

В Enterprise-инсталляциях центральный Zabbix Server часто вообще не опрашивает конечные устройства. Вся нагрузка по сбору данных (включая тяжелые SNMP-запросы и WMI-проверки) распределяется между десятками Zabbix Proxy, оставляя ядру системы только оценку триггеров и запись в мощную центральную базу данных.

Понимание архитектурного разделения на Server, Frontend, DB и Proxy позволяет не просто "установить программу по инструкции", а спроектировать отказоустойчивую систему мониторинга, способную пережить падение сети, рост количества собираемых метрик и строгие требования корпоративной безопасности. В следующих этапах мы начнем наполнять эту пустую архитектуру реальными данными, начав с настройки агентов на Linux-системах.

Мониторинг Linux-серверов: Zabbix Agent, пассивные и активные проверки

Представьте инфраструктуру из 5000 виртуальных машин, распределенных между тремя облачными провайдерами. Виртуальные машины находятся за NAT, их IP-адреса динамически меняются, а каналы связи периодически испытывают микроразрывы. Если центральный сервер мониторинга попытается самостоятельно опрашивать каждую машину по расписанию, он столкнется с тысячами таймаутов, исчерпанием лимита TCP-соединений и, в конечном итоге, остановкой сбора данных. Эта архитектурная проблема решается сменой парадигмы сбора метрик — переходом от классического поллинга (опроса) к пуш-модели.

Взаимодействие между Zabbix Server и конечным узлом строится вокруг легковесного демона — Zabbix Agent. Понимание того, как именно агент извлекает данные из операционной системы и какими способами доставляет их на сервер, определяет, сможет ли система мониторинга масштабироваться за пределы одной серверной стойки.

Анатомия Zabbix Agent в среде Linux

Zabbix Agent не использует скрытых или недокументированных механизмов для получения метрик. В среде Linux он работает как транслятор, переводящий стандартные системные вызовы и данные из виртуальных файловых систем в понятный серверу формат.

Когда сервер запрашивает метрику system.cpu.load[all,avg1], агент не вычисляет загрузку процессора самостоятельно. Он обращается к системному файлу /proc/loadavg, считывает первое значение и передает его обратно. При запросе vfs.fs.size[/,free] агент использует POSIX-совместимый системный вызов statvfs, получая данные напрямую от ядра ОС.

Исторически Zabbix Agent писался на языке C. Это невероятно легкий и быстрый демон, потребляющий мегабайты оперативной памяти. Однако его архитектура базируется на пуле процессов-воркеров. Если агент получает команду выполнить пользовательский скрипт, который отрабатывает за 5 секунд, один из процессов полностью блокируется на это время. При исчерпании пула свободных процессов агент перестает отвечать на новые запросы.

Для решения проблемы конкурентности был разработан Zabbix Agent 2, написанный на языке Go. Он сохраняет полную обратную совместимость по протоколу и конфигурации, но меняет внутреннюю механику. Вместо тяжелых процессов ОС используются легковесные горутины (goroutines).

!Сравнение обработки пула метрик классическим Agent и Agent 2

Agent 2 также поддерживает плагинную архитектуру. Если классический агент требует написания внешних bash-скриптов для мониторинга, например, Docker-контейнеров или баз данных Redis, то Agent 2 может держать постоянные пулы соединений с этими сервисами внутри себя, значительно снижая накладные расходы на создание новых подключений при каждом сборе метрики.

Пассивные проверки (Polling): Сервер диктует правила

Пассивная проверка означает, что Zabbix Agent ведет себя как классический веб-сервер. Он слушает сетевой интерфейс и пассивно ожидает входящих запросов. Инициатором соединения всегда выступает Zabbix Server (или Zabbix Proxy).

Жизненный цикл пассивной проверки:

Процесс Poller на стороне Zabbix Server открывает TCP-соединение к агенту.

Сервер отправляет текстовую строку — ключ элемента данных (например, agent.ping).

Агент парсит ключ, выполняет соответствующую проверку в ОС.

Агент отправляет текстовый ответ (например, 1).

TCP-соединение закрывается.

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

Главный недостаток пассивных проверок — масштабируемость и чувствительность к сетевым задержкам. Каждый запрос требует полного цикла TCP Handshake. Если время ответа агента увеличивается (из-за нагрузки на диск или сеть), процессы Poller на сервере простаивают в ожидании.

Пропускную способность пассивного мониторинга можно описать формулой:

Где — максимальное количество проверок в секунду, — количество запущенных процессов Poller на сервере, а — среднее время ответа агента в секундах, включая сетевую задержку.

Если у нас запущено 100 поллеров, а из-за проблем с маршрутизацией среднее время ответа возросло до 0.5 секунд, то максимальная пропускная способность сервера упадет до проверок в секунду. Для Enterprise-инфраструктуры это критически мало. Увеличение количества поллеров () ведет к экспоненциальному росту потребления оперативной памяти и процессорного времени на самом Zabbix Server, что делает бесконечное масштабирование пассивных проверок невозможным.

Активные проверки (Trapping): Агент берет инициативу

Для обхода ограничений поллинга используются активные проверки. В этом режиме роли меняются: Zabbix Agent сам инициирует TCP-соединение с Zabbix Server, запрашивает конфигурацию и затем отправляет собранные данные. Сервер лишь пассивно принимает входящие пакеты через процессы Trapper.

!Архитектура потоков данных при пассивных и активных проверках

Жизненный цикл активной проверки кардинально отличается:

Агент подключается к серверу и запрашивает список метрик для своего имени хоста (Hostname).

Сервер отдает JSON-массив с перечнем ключей и интервалами их сбора (например, собирать system.cpu.load каждые 60 секунд, а vfs.fs.size — каждый час).

Агент сохраняет это расписание в оперативной памяти и закрывает соединение.

Внутренние таймеры агента инициируют сбор данных. Значения складываются в локальный буфер.

Раз в несколько секунд (по умолчанию 5) агент открывает новое TCP-соединение с сервером и отправляет весь накопленный буфер метрик одним JSON-пакетом.

Этот механизм решает сразу несколько фундаментальных проблем:

Обход NAT и Firewall. Серверу не нужно иметь прямого доступа к IP-адресу агента. Достаточно, чтобы агент мог достучаться до порта сервера. Это делает активные проверки стандартом для мониторинга облачных инстансов и удаленных филиалов.

Производительность. Отправка 100 метрик одним пакетом раз в 5 секунд требует в десятки раз меньше сетевых ресурсов и процессорного времени, чем 100 отдельных TCP-соединений. Процессы Trapper на сервере работают асинхронно и способны переваривать десятки тысяч метрик в секунду.

Устойчивость к обрывам связи. Если сервер временно недоступен, агент не отбрасывает собранные данные. Он сохраняет их в локальном буфере в оперативной памяти (размер буфера регулируется параметром BufferSend и BufferSize). При восстановлении связи агент отправит всю накопленную историю с правильными временными метками (timestamps).

Единственный строгий нюанс активных проверок — точное совпадение имени хоста. Поскольку агент сам приходит к серверу, сервер должен понять, от кого пришли данные. Идентификация происходит по параметру Hostname в конфигурационном файле агента. Если в веб-интерфейсе Zabbix узел сети назван web-server-01, а в конфиге агента указано Hostname=web-server-1, сервер отбросит все присланные метрики с ошибкой "host not found", так как не найдет точного совпадения в своей базе данных.

Конфигурация агента: разделение потоков

Поведение агента жестко задается в файле zabbix_agentd.conf (или zabbix_agent2.conf). Для понимания маршрутизации метрик критически важно различать два параметра, которые часто путают новички: Server и ServerActive.

Параметр Server отвечает исключительно за пассивные проверки. Он определяет белый список IP-адресов, которым агент разрешает подключаться к себе и запрашивать метрики. > Server=192.168.1.50, 10.0.0.15 Если запрос придет с IP-адреса, которого нет в этом списке, агент сбросит соединение, не ответив ни байта, а в логе зафиксирует попытку несанкционированного доступа.

Параметр ServerActive отвечает исключительно за активные проверки. Он указывает агенту, куда именно нужно стучаться для получения конфигурации и отправки собранных данных. > ServerActive=192.168.1.50:10051 Здесь можно указывать порт, так как агент выступает в роли клиента.

В гибридных инфраструктурах агент часто настраивают на использование обоих режимов одновременно. Базовые метрики ОС (процессор, память) отправляются активно для снижения нагрузки, а специфические команды удаленного выполнения или проверки доступности сервисов инициируются сервером пассивно для немедленного отклика.

Расширение возможностей: UserParameter

Встроенных ключей Zabbix Agent хватает для 90% задач системного мониторинга. Но когда требуется получить специфичную бизнес-метрику или данные из проприетарного приложения, на помощь приходит механизм UserParameter.

UserParameter позволяет привязать любую консольную команду или скрипт к пользовательскому ключу Zabbix. Синтаксис в конфигурационном файле выглядит так: UserParameter=<ключ>,<команда>

Например, нам нужно мониторить количество установленных TCP-соединений к веб-серверу Nginx на 80 порту. Мы можем использовать утилиту ss и фильтрацию grep. Добавляем в конфигурацию агента строку: UserParameter=nginx.connections,ss -ant | grep ESTAB | grep :80 | wc -l

После перезапуска агента, Zabbix Server сможет запрашивать ключ nginx.connections точно так же, как встроенный system.cpu.load. Агент получит запрос, выполнит bash-команду, перехватит её стандартный вывод (STDOUT) и вернет число на сервер.

Механизм поддерживает передачу аргументов через конструкцию [*]. UserParameter=app.queue_size[*],/opt/scripts/get_queue.sh $1 При запросе ключа app.queue_size[orders] агент выполнит скрипт /opt/scripts/get_queue.sh orders. Это позволяет создавать универсальные обработчики без дублирования конфигурации.

При работе с UserParameter действует жесткое ограничение: время выполнения команды не должно превышать значение параметра Timeout (по умолчанию 3 секунды). Если скрипт обращается к медленной базе данных и ждет ответа 5 секунд, агент принудительно прервет его выполнение и вернет серверу статус ZBX_NOTSUPPORTED. Для тяжелых скриптов необходимо либо увеличивать таймаут (что негативно скажется на пропускной способности поллеров), либо переводить такие проверки в режим активного пуша с помощью утилиты zabbix_sender, которая отправляет данные асинхронно, не блокируя процессы агента.

Траблшутинг и диагностика на уровне ОС

При настройке мониторинга неизбежно возникают ситуации, когда метрика не собирается. Для диагностики на стороне Linux-сервера используются встроенные инструменты.

Утилита zabbix_get — главный инструмент администратора для проверки пассивного режима. Она эмулирует запрос от Zabbix Server. Запуская её прямо с сервера, можно проверить всю цепочку: сетевую связность, права доступа и корректность ответа. Синтаксис: zabbix_get -s <IP_агента> -k <ключ_метрики> Если в ответ возвращается ZBX_NOTSUPPORTED: Unsupported item key, это означает, что сеть работает отлично, белый список Server настроен верно, но агент не знает такого ключа (возможно, допущена опечатка или забыт перезапуск демона после добавления UserParameter).

Если проблема возникает с локальным скриптом, применяется тестирование самого агента в консоли: zabbix_agentd -t <ключ_метрики> Этот флаг заставляет агента выполнить проверку от своего имени и вывести результат в терминал.

Частая проблема при расширении мониторинга — права доступа. Zabbix Agent запускается в ОС под непривилегированным пользователем zabbix. Если UserParameter пытается прочитать лог-файл /var/log/syslog, владельцем которого является root, команда завершится с ошибкой Permission denied. Агент честно вернет пустую строку или ошибку на сервер. Решением является настройка прав через ACL, добавление пользователя zabbix в нужную группу или аккуратное использование sudo внутри скриптов с настройкой visudo без требования пароля для конкретных команд.

Понимание разницы между активными и пассивными проверками, а также умение расширять функционал агента через пользовательские параметры, формирует фундамент для построения отказоустойчивого мониторинга. Выбор правильного режима сбора данных на этапе проектирования избавляет от необходимости перестраивать архитектуру при росте инфраструктуры с десятков до тысяч серверов.

Мониторинг Windows-инфраструктуры: Performance Counters и работа с WMI

Если в Linux «всё есть файл», и для получения метрик агенту достаточно прочитать текстовые данные из виртуальной файловой системы /proc, то архитектура Windows представляет собой закрытый «черный ящик». Операционная система от Microsoft не отдает системную информацию через простые файлы. Вместо этого она предоставляет разработчикам и администраторам строгие программные интерфейсы (API) и специализированные подсистемы. Чтобы эффективно собирать данные с Windows-серверов, Zabbix Agent должен уметь общаться с этими подсистемами на их языке.

Установка агента на Windows также имеет свои особенности. Чаще всего он разворачивается не через пакетный менеджер, а устанавливается как системная служба (Windows Service) с помощью MSI-пакета или командной строки (zabbix_agentd.exe -i). Однако главная сложность кроется не в развертывании, а в выборе правильного инструмента для извлечения конкретной метрики. В арсенале инженера мониторинга есть два главных механизма: быстрые, но жестко структурированные Performance Counters, и невероятно гибкий, но ресурсоемкий WMI.

Performance Counters: пульсометр операционной системы

Performance Counters (Счетчики производительности) — это встроенный в Windows механизм реального времени для отслеживания состояния аппаратных ресурсов, операционной системы и приложений (таких как MS SQL Server, IIS, Exchange). Это самый быстрый и легковесный способ получить количественные метрики.

Структура любого счетчика всегда подчиняется строгой иерархии, состоящей из трех элементов: Объект, Экземпляр (опционально) и Счетчик.

!Иерархия Performance Counters в Windows

Объект (Object) — логическая или физическая сущность. Например: Processor, LogicalDisk, Memory, Web Service.

Экземпляр (Instance) — конкретный представитель объекта, если их несколько. Например, если у сервера несколько дисков, экземплярами объекта LogicalDisk будут C:, D:, _Total. У объекта Memory экземпляров нет, так как память в системе рассматривается как единое целое.

Счетчик (Counter) — конкретная измеряемая характеристика. Например: % Processor Time, Free Megabytes, Current Connections.

В Zabbix для получения этих данных используется ключ perf_counter[<путь>]. Полный путь формируется по шаблону \Объект(Экземпляр)\Счетчик.

Пример ключа для мониторинга свободного места на диске C: в мегабайтах: perf_counter["\LogicalDisk(C:)\Free Megabytes"]

Проблема локализации и пути её решения

Одна из самых частых и болезненных проблем при развертывании Zabbix в разнородной Windows-инфраструктуре — локализация ОС. Названия объектов и счетчиков зависят от языка системы.

Если вы примените шаблон с ключом perf_counter["\Processor(_Total)\% Processor Time"] к серверу с русской версией Windows Server, метрика перейдет в состояние Not supported. Операционная система просто не найдет объект Processor, потому что в русской локализации он называется Процессор. Писать отдельные шаблоны под каждый язык ОС — путь, ведущий к хаосу в конфигурации.

Для решения этой архитектурной проблемы существует три подхода:

1. Использование ключа perf_counter_en Начиная с определенной версии, Zabbix Agent поддерживает ключ perf_counter_en. При его использовании агент берет английское название счетчика, обращается к системному реестру Windows, находит его числовой идентификатор, а затем запрашивает у ОС метрику по этому идентификатору, игнорируя язык интерфейса. Это самый предпочтительный и читаемый способ. Пример: perf_counter_en["\LogicalDisk(_Total)\% Free Space"]

2. Использование числовых индексов (Numeric IDs) Каждому объекту и счетчику в Windows при установке присваивается уникальный числовой ID. Эти ID хранятся в ветке реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009. Например, объект Processor всегда имеет ID 238, а счетчик % Processor Time — ID 6. Ключ Zabbix будет выглядеть так: perf_counter["\238(_Total)\6"]. Этот метод работает на 100% языков, но делает конфигурацию абсолютно нечитаемой для человека. Без документации невозможно понять, что измеряет метрика \238(_Total)\6.

3. Утилита typeperf для отладки Прежде чем добавлять метрику в Zabbix, её необходимо протестировать на самом сервере. Для этого в Windows встроена консольная утилита typeperf. Команда typeperf -qx выведет список всех доступных в системе счетчиков. Вы можете отфильтровать вывод, чтобы найти точное написание: typeperf -qx | findstr "LogicalDisk"

Rate-метрики и интервалы сбора

Многие счетчики производительности (например, Network Interface\Bytes Total/sec) возвращают не абсолютное значение, а скорость (Rate). Однако сама Windows часто хранит под капотом постоянно растущее число (Raw counter) — например, общее количество переданных байт с момента включения сервера.

Когда Zabbix Agent запрашивает такой счетчик, он должен вычислить дельту между двумя измерениями.

!Влияние интервала сбора на сглаживание Rate-метрик

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

где и — значения счетчика при первом и втором запросе, а и — временные метки этих запросов в секундах.

Если вы установите интервал опроса (Update interval) в Zabbix равным 1 минуте, вы получите усредненную скорость за эту минуту. Короткие всплески сетевой активности (микроберсты длительностью 2-3 секунды) будут полностью сглажены и невидимы на графике. Для критичных узлов (например, базы данных или балансировщики нагрузки) интервал сбора Performance Counters часто снижают до 10–15 секунд, чтобы видеть реальную картину утилизации ресурсов.

В ключе perf_counter также есть опциональный второй параметр — интервал усреднения на стороне самого агента: perf_counter[<путь>,<интервал>]. Если указать perf_counter["\Processor(_Total)\% Processor Time", 60], агент будет опрашивать систему каждую секунду, а Zabbix-серверу раз в минуту отдавать среднее арифметическое за последние 60 секунд.

Windows Management Instrumentation (WMI): глубокая инвентаризация

Если Performance Counters — это пульсометр, то WMI — это аппарат МРТ для Windows. WMI (Windows Management Instrumentation) предоставляет унифицированный интерфейс для запроса практически любой информации об аппаратном обеспечении, состоянии ОС, установленном ПО и конфигурации.

Концептуально WMI построен на архитектуре CIM (Common Information Model) и представляет данные в виде объектно-ориентированной базы данных.

!Архитектура взаимодействия Zabbix Agent с WMI

Чтобы получить данные из WMI, используется язык запросов WQL (WMI Query Language), который синтаксически очень похож на SQL. Запрос состоит из трех основных частей:

Пространство имен (Namespace) — логический раздел, где хранятся классы. Самое популярное пространство, содержащее информацию об ОС и железе — root\cimv2.

Класс (Class) — таблица с данными. Например, Win32_OperatingSystem или Win32_LogicalDisk.

Свойство (Property) — конкретный столбец (атрибут), который мы хотим получить.

Ключ Zabbix для выполнения запроса: wmi.get[<пространство_имен>,<запрос>].

Рассмотрим практический пример. Нам нужно получить серийный номер физического диска для инвентаризации. Performance Counters такую информацию не хранят. Мы используем WMI: wmi.get[root\cimv2,Select SerialNumber from Win32_PhysicalMedia where Tag="\\\\.\\PHYSICALDRIVE0"]

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

Цена гибкости: влияние WMI на производительность

Главное правило мониторинга Windows: никогда не используйте WMI для метрик, которые можно получить через Performance Counters.

Служба WMI (Winmgmt) работает поверх DCOM и RPC. Каждый WQL-запрос заставляет службу WMI обращаться к соответствующему WMI-провайдеру (например, драйверу диска или службе Active Directory), собирать данные, формировать объекты и возвращать их агенту. Это тяжелая, ресурсоемкая операция.

Если вы настроите сбор 50 метрик через WMI с интервалом в 30 секунд (например, загрузку процессора, память, сеть), процесс WmiPrvSE.exe (WMI Provider Host) загрузит CPU сервера на 20-40%, а сам мониторинг станет причиной деградации инфраструктуры.

Архитектурный паттерн применения:

Performance Counters: CPU, RAM, Disk I/O, Network I/O, метрики приложений. Интервал опроса: 10 секунд — 5 минут.

WMI: Серийные номера, версии драйверов, редакция ОС, состояние специфических компонентов (например, статус репликации DFS). Интервал опроса: 1 час — 1 сутки.

Для тестирования WQL-запросов на Windows-сервере не нужно устанавливать стороннее ПО. Достаточно нажать Win+R и ввести wbemtest. Это встроенная графическая утилита, позволяющая подключиться к нужному пространству имен, выполнить WQL-запрос и посмотреть структуру возвращаемых классов. Для работы в консоли (например, PowerShell) используется командлет Get-WmiObject или более современный Get-CimInstance.

Мониторинг журналов событий (Event Logs)

В отличие от Linux, где логи обычно пишутся в плоские текстовые файлы (например, /var/log/syslog), Windows использует бинарную систему журналирования Event Tracing for Windows (ETW) и Event Logs. Прочитать их обычным tail или grep невозможно.

Zabbix Agent обладает встроенным механизмом для чтения этих бинарных журналов с помощью ключа eventlog.

Синтаксис ключа: eventlog[name,<regexp>,<severity>,<source>,<eventid>,<maxlines>,<mode>]

Где:

name — имя журнала (System, Security, Application).

regexp — регулярное выражение для поиска в тексте события.

severity — уровень критичности (Information, Warning, Error, Critical, Verbose).

source — источник события (название службы или приложения).

eventid — конкретный идентификатор события.

Критическое архитектурное требование: Элементы данных типа eventlog работают только в режиме активных проверок (Active Checks).

Специфика чтения логов заключается в том, что агент должен запоминать позицию (закладку), на которой он остановился в прошлый раз, чтобы не отправлять одни и те же события повторно. При пассивном поллинге сервер просто запрашивает значение «здесь и сейчас». При активной проверке агент сам читает журнал, формирует пакет из новых событий (до значения <maxlines> за один раз) и пушит их на Zabbix Server.

Пример использования: мониторинг неудачных попыток входа в систему по RDP. В Windows неудачный вход фиксируется в журнале Security под Event ID 4625. Ключ в Zabbix будет выглядеть так: eventlog[Security,,,,4625] Этот элемент данных соберет все события 4625. Далее на стороне Zabbix Server можно настроить триггер, который сработает, если количество таких событий превысит 5 за последние 3 минуты, что может свидетельствовать о брутфорс-атаке.

Мониторинг служб Windows (Windows Services)

Контроль состояния критичных служб (СУБД, веб-серверы, агенты резервного копирования) — базовая задача мониторинга. Для этого в Zabbix используется ключ service.info[<служба>,<параметр>].

В качестве <служба> указывается системное имя сервиса (Service name), а не его отображаемое имя (Display name). Например, служба «Диспетчер печати» в системе называется Spooler.

Параметр state (по умолчанию) возвращает числовое значение текущего состояния службы. Ключ service.info[Spooler,state] вернет:

0 — Running (Работает)

1 — Paused (Приостановлена)

2 — Start pending (Ожидает запуска)

3 — Pause pending (Ожидает приостановки)

4 — Continue pending (Ожидает продолжения)

5 — Stop pending (Ожидает остановки)

6 — Stopped (Остановлена)

7 — Unknown (Неизвестно)

Частая ошибка начинающих инженеров — создавать триггер вида (служба не работает) для всех служб подряд. Многие службы в Windows имеют тип запуска Manual или Automatic (Delayed Start) и останавливаются операционной системой за ненадобностью для экономии ресурсов (например, служба обновления Windows). Срабатывание триггера на такую службу создаст ложный алерт.

Чтобы сделать мониторинг умнее, можно запрашивать тип запуска службы параметром startup: service.info[Spooler,startup] Это вернет 0 для Automatic, 1 для Automatic delayed, 2 для Manual и так далее. Комбинируя эти данные, можно создать логику: «Алертить об остановке службы, только если её тип запуска — Automatic».

Комплексный мониторинг Windows-инфраструктуры строится на грамотном балансе. Performance Counters обеспечивают плотный и частый сбор числовых метрик с минимальной нагрузкой на CPU. WMI закрывает потребности в инвентаризации и получении сложных текстовых статусов, запрашиваемых редко. А активные проверки Event Logs позволяют моментально реагировать на системные ошибки и инциденты безопасности, превращая разрозненные Windows-серверы в прозрачную и управляемую среду.