Как я внедряю мониторинг заполнения scope и выдачи аренды Windows DHCP в Zabbix

Исходная ситуация: зелёная служба не гарантирует адрес

В проектах IT Fresh запрос на такой мониторинг обычно появляется, когда пользователи периодически не получают сетевые параметры, хотя служба DHCP Server запущена и сам сервер доступен. Я начинаю не с готового триггера, а с карты обслуживания: какие IPv4 scope существуют, какие VLAN приходят через relay, где действуют exclusions, reservations, policies и failover. Одновременно уточняю владельца адресного плана и ожидаемые периоды массовых подключений. Свободный адрес в соседнем scope не помогает клиенту конкретного сегмента, а общий запас сервера скрывает локальное исчерпание. Поэтому единицей наблюдения становится отдельный scope и, при необходимости, диапазон политики. Я фиксирую версию Windows Server и Zabbix agent, потому что доступные поля и безопасный способ сбора зависят от установленной среды. Имена серверов, MAC-адреса и сведения об арендаторах в рабочую статью не переношу.

Сигналы: ёмкость, динамика и события выдачи

Для каждого scope я сопоставляю три группы свидетельств. Первая — состояние диапазона: активность, размер, число занятых и свободных адресов, процент использования. Вторая — динамика: как меняется абсолютный остаток в сопоставимые периоды и возвращаются ли адреса после окончания аренды. Третья — события DHCP Server: предупреждения о малом запасе или полном диапазоне, NACK, decline и ошибки самой службы. Microsoft документирует эти события, но их наличие ещё не объясняет причину. Например, единичный decline отличается от устойчивой нехватки адресов, а NACK может относиться к клиенту, который пришёл с неподходящей прежней арендой. Рядом я сохраняю свежесть сбора и состояние службы. Так пропавшая телеметрия остаётся отдельной проблемой, а запущенная служба не маскирует неактивный scope или отказ конкретной ветви выдачи.

Проектирование метрик без универсального порога

Источником статистики выбираю штатный модуль DHCP Server и результат Get-DhcpServerv4ScopeStatistics, выполняемый на согласованном сервере для разрешённых scope. Я не публикую имя самодельного ключа как стандарт Zabbix и не назначаю всем диапазонам одинаковую частоту. В модели отдельно храню абсолютное число свободных адресов, использованные адреса, процент использования, состояние scope и отметку успешного получения. Процент удобен для обзора, остаток — для оценки реальной ёмкости, а тренд помогает увидеть скорость изменения. Порог обсуждаю с владельцем сети с учётом размера пула, срока аренды, резерва на подключение, exclusions, политик и времени реакции команды. Для failover проверяю режим и партнёра отдельно: локальная статистика одного узла без понимания отношений серверов может дать неполный вывод. Нулевое значение считается данными только при успешном и свежем ответе коллектора.

Настройка Zabbix: один снимок и зависимые элементы

Внедрение я строю вокруг ограниченного коллектора, который возвращает структурированный снимок только нужных scope без данных клиентов и произвольных параметров. Учётной записи оставляю минимально достаточное чтение; возможность менять scope, аренды или параметры службы ей не нужна. В Zabbix один master item принимает снимок, low-level discovery создаёт сущности scope, а dependent items извлекают состояние, свободные и занятые адреса, использование и свежесть. Такой подход уменьшает число повторных обращений к Windows и сохраняет согласованность значений одной выборки. Перед привязкой шаблона я тестирую JSON и каждый путь предобработки на обезличенном образце, затем проверяю unsupported-состояния и ограничение размера ответа. Интервал выбираю после оценки числа scope, стоимости запроса и требуемой скорости реакции. Конкретная реализация агента согласуется с его версией; широкое разрешение system.run и передаваемые извне аргументы я не использую.

Проверка выдачи и отказа из правильного сегмента

Статистика ёмкости отвечает на вопрос о запасе, но не доказывает прохождение DHCPDISCOVER и последующих сообщений через сеть. Поэтому контролируемую проверку провожу с разрешённого тестового устройства в выбранном VLAN. Сначала сохраняю его текущую конфигурацию и согласую окно, затем выполняю штатное обновление аренды либо новый цикл только на этой станции. Сопоставляю время клиентского результата, relay-путь, изменение аренды на сервере и события DHCP. Успех означает получение ожидаемого адреса и параметров из нужного scope, а не просто появление любой сети. Отказ воспроизвожу только безопасным способом: не заполняю боевой пул искусственными клиентами и не деактивирую scope. Для проверки маршрута события достаточно утверждённого тестового диапазона, лабораторного VLAN или заранее созданного условия, не влияющего на пользователей. Если настоящий отказ уже произошёл, его анализирую read-only по сохранённым событиям и состоянию диапазона.

Предупреждения и эскалации с различимой причиной

Я разделяю минимум три класса проблем. Первый — уменьшающийся запас: предупреждение учитывает и процент, и абсолютный остаток, а его серьёзность растёт при устойчивом тренде. Второй — подтверждённое исчерпание или серия отказов выдачи: здесь нужны scope, сегмент, временное окно и последние релевантные события. Третий — отсутствие свежих метрик: это ветвь коллектора, прав или агента, а не сообщение о заполненном пуле. Корреляция не должна прятать первичную причину. Если несколько scope одного сервера теряют данные одновременно, сначала проверяется сбор; если один сегмент получает отказы при свободном диапазоне, событие уходит сетевой команде с проверкой relay и VLAN. Владельцу DHCP передаю ёмкость, активность scope и события службы. Я избегаю текста «закончатся адреса через точное время»: без устойчивой модели подключений это предположение, а не доказанный прогноз.

Эксплуатация: изменения адресного плана не должны быть сюрпризом

После запуска я проверяю discovery при добавлении, отключении и переименовании scope в согласованном тесте, чтобы потерянная сущность не исчезала бесследно. Удаление прототипов откладывается на срок, выбранный командой, а событие о пропавшем scope рассматривается вместе с журналом изменений. Периодически владелец сверяет найденные диапазоны с утверждённым адресным планом, exclusions, reservations, policies и failover. Я отдельно наблюдаю, что коллектор завершается успешно, ответ остаётся валидным, предобработка не создаёт очередь и шаблон не раскрывает сведения об устройствах. После изменения срока аренды или размера пула прежние пороги пересматриваются: исторический профиль больше не описывает ту же ёмкость. В runbook остаются read-only шаги, маршрут эскалации и критерии остановки теста. Расширение scope, изменение политик и удаление аренд выполняются владельцем DHCP вне мониторинга и только через принятую процедуру изменений.

Вывод: доказательство складывается из нескольких слоёв

В нашей практике полезный мониторинг Windows DHCP не сводится к зелёному состоянию службы или одному проценту. Я считаю результат убедительным, когда Zabbix показывает свежую статистику конкретного scope, различает малый остаток и ошибку сбора, связывает серию отказов с событиями Windows и позволяет подтвердить выдачу из реального клиентского сегмента. При этом он не доказывает исправность relay, VLAN, DNS-регистрации или клиента без отдельных проверок. Границы вывода записываю рядом с сигналом, а пороги корректирую после изменения адресного плана и профиля подключений. Если вам нужно выстроить такую проверяемую схему без опасных действий на DHCP Server, обсудить задачу можно с IT Fresh: https://itfresh.ru/, https://t.me/ITfresh_Boss и tel:+79037296241. Я, Семёнов Евгений Сергеевич, начинаю с инвентаризации scope и безопасного пилота, а решение о боевых изменениях оставляю ответственному владельцу инфраструктуры.

Отвергнутые альтернативы

• Контролировать только состояние службы DHCP ServerЗапущенная служба может обслуживать одни scope и не выдавать адреса в другом из-за исчерпания, деактивации, политики, relay или сетевого пути.
• Считать один процент заполнения достаточным сигналомОдинаковый процент означает разный абсолютный запас в диапазонах разного размера и ничего не говорит о скорости расходования адресов.
• Приравнять отсутствие данных к нулю свободных адресовОшибка прав, модуля, агента или предобработки тогда выглядит как исчерпание scope и направляет дежурного по ложной ветви.
• Реагировать на любой NACK как на аварию DHCPОтдельный NACK имеет контекст протокола и клиента; значимы серия, затронутый сегмент, соседние события и результат нового получения аренды.
• Запускать произвольные команды из itemЯ применяю просмотренный коллектор без пользовательского ввода и только с правами чтения.

Конфигурация и сбор

Чтение статистики разрешённых IPv4 scope, согласованных каналов Microsoft-Windows-DHCP-Server и конфигурации Zabbix. Изменение scope, leases, failover и службы исключено.

• Сопоставить scope с VLAN, relay, владельцем, policies и схемой failover.
• Получить статистику scope без данных клиентов и проверить свежесть.
• Прочитать события DHCP Server за ограниченное окно без экспорта идентификаторов устройств.
• Проверить master item, discovery, dependent items и обработку ошибки на обезличенном снимке.
• Согласовать пороги и частоту с владельцем по ёмкости и профилю подключений.

Контролируемая проверка и свидетельство

На разрешённой тестовой станции в выбранном VLAN выполняется штатный цикл обновления или получения аренды. Сопоставляются клиентский результат, relay-путь, запись аренды, изменение статистики scope и события Windows. Тест прекращается при влиянии на других клиентов, неожиданном ответе чужого scope, ошибке сетевых параметров или ухудшении работы DHCP Server.

Фрагмент рабочего регламента

• Отличить ошибку сбора от действительного нулевого остатка.
• Проверить состояние scope, остаток, процент и тренд.
• Сопоставить предупреждение с событиями DHCP Server и изменениями.
• При свободном scope проверить VLAN и relay; при потере данных — коллектор и агент.
• Не менять DHCP из Zabbix; передать доказательства владельцу.

Откат

До пилота сохраняются версия шаблона, привязка хоста и права коллектора. Откат возвращает прежнюю версию и разрешения, затем проверяется агент. Клиентская станция возвращается к сохранённой сетевой конфигурации; DHCP тестом не изменяется.

Ограничения вывода

Статистика scope не доказывает прохождение relay. NACK не является диагнозом, процент не заменяет остаток. Порог и интервал зависят от диапазона, срока аренды и профиля подключений.