Мониторинг контроллеров домена: ключевые метрики в Prometheus, которые нельзя игнорировать

09.10.2026

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

Поэтому мониторинг Active Directory не должен ограничиваться проверкой, что сервер отвечает на ping. Надежная система наблюдения должна контролировать доступность LDAP, DNS и Kerberos, состояние репликации, синхронизацию времени, ресурсы Windows, ошибки служб и качество работы клиентов. Prometheus позволяет собирать эти показатели, хранить временные ряды и создавать оповещения до того, как локальная неисправность превратится в общедоменный инцидент.

1. Архитектура мониторинга: что и откуда собирать

Для полноценного наблюдения обычно комбинируют несколько источников телеметрии. Prometheus периодически опрашивает экспортёры и HTTP-эндпоинты, а Grafana используется для визуализации и анализа временных рядов. События Windows и подробные диагностические журналы при этом удобнее отправлять в систему логирования: метрики показывают масштаб и динамику проблемы, а логи помогают установить конкретную причину.

• windows_exporter: собирает системные метрики Windows — процессор, память, диски, сеть, службы, счетчики производительности и, при включенных коллекторах, данные Active Directory.
• Экспортёр AD/LDAP: проверяет доступность LDAP, выполняет запросы к каталогу, оценивает время ответа и ошибки bind/search.
• Экспортёр DNS или blackbox_exporter: проверяет разрешение критичных доменных имен и доступность TCP/UDP-портов.
• Сборщик репликационных данных: получает результаты диагностических команд или счётчики AD DS, преобразуя их в метрики Prometheus.
• Система логирования: централизованно хранит журналы Directory Service, DNS Server, System и Security для расследования событий.

Названия метрик зависят от версии экспортёра, набора включенных коллекторов и используемой схемы сбора. Перед настройкой правил проверьте фактические серии на странице /metrics и не копируйте PromQL-примеры, не сверив имена метрик с вашей конфигурацией.

2. Доступность служб и контрольные проверки

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

LDAP и LDAPS

Контролируйте доступность портов TCP 389 и 636, успешность подключения и время выполнения тестового LDAP-запроса. Простая проверка открытого порта не подтверждает, что сервер способен аутентифицировать клиента или вернуть объект. Для синтетического теста используйте безопасную сервисную учетную запись с минимальными правами и проверяйте bind, поиск заранее выбранного объекта и ожидаемый результат.

Полезные показатели:

• доля успешных LDAP-проверок;
• время ответа LDAP и LDAPS, включая 95-й и 99-й перцентили;
• количество ошибок bind и search;
• срок действия сертификата LDAPS и ошибки его проверки.

DNS и Kerberos

Active Directory критически зависит от корректного DNS. Проверяйте разрешение SRV-записей, например _ldap._tcp.dc._msdcs.example.local и _kerberos._tcp.example.local, а также разрешение A/AAAA-записей контроллеров. Следите за задержкой ответа, SERVFAIL, NXDOMAIN для ожидаемых записей и доступностью DNS-сервера по UDP и TCP 53.

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

3. Репликация Active Directory: метрики, которые нельзя пропускать

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

Отслеживайте:

• Состояние каждого партнёрского направления: успешна ли последняя попытка репликации между конкретными контроллерами.
• Возраст последней успешной репликации: время с момента последнего обмена изменениями по каждому naming context.
• Ошибки репликации: код ошибки, число подряд неудачных попыток и затронутые разделы каталога.
• Очередь и задержка: если доступна, длительность распространения изменений и количество ожидающих объектов.
• Согласованность топологии: наличие ожидаемых партнёров и доступность межсайтовых каналов.

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

Практически это удобно организовать так: регулярный проверяющий скрипт выполняет безопасную диагностику репликации, разбирает результат и публикует числовые значения в формате, который считывает Prometheus. В качестве первичной проверки применяют штатные инструменты AD, например repadmin /replsummary и repadmin /showrepl, но запуск и разбор вывода следует протестировать на конкретной версии Windows Server.

4. Синхронизация времени и Kerberos

Kerberos чувствителен к расхождению часов между клиентом и контроллером домена. Даже исправный LDAP может сопровождаться отказом входа, если системное время вышло за допустимое окно. Мониторьте отклонение локальных часов от доверенного источника времени, состояние службы Windows Time и результаты синхронизации.

• текущий time offset относительно доверенного NTP-источника;
• успешность последней синхронизации и выбранный источник;
• остановку или частые перезапуски службы времени;
• всплески Kerberos-ошибок, совпадающие с ростом временного смещения.

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

5. Ресурсы операционной системы и службы каталога

Высокая загрузка процессора сама по себе не всегда означает проблему, но в сочетании с замедлением LDAP или DNS может указывать на перегрузку. На контроллерах домена отслеживайте использование CPU, доступную память, дисковую задержку, пропускную способность сети и свободное место на томах.

• CPU: средняя и пиковая загрузка, длительные периоды насыщения, нагрузка процессов LSASS, DNS и службы каталогов.
• Память: доступная RAM, признаки paging, размер и динамика рабочего набора ключевых процессов.
• Диски: задержка чтения/записи, очередь диска, свободное место на системном томе и томе базы каталога.
• Сеть: ошибки интерфейса, потери пакетов, насыщение канала, задержка до партнеров репликации.
• Службы: состояние AD DS, DNS Server, Netlogon, Kerberos Key Distribution Center и Windows Time.

Не задавайте тревоги только по кратковременным пикам. Используйте окна наблюдения, например устойчивую загрузку CPU выше установленного порога в течение 10–15 минут, и связывайте системные симптомы с доступностью пользовательских сценариев.

6. Аутентификация, блокировки и безопасность

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

Для такой аналитики Prometheus может хранить агрегированные счетчики, а подробные события следует анализировать в системе SIEM или журналирования. Не экспортируйте в метрики имена пользователей без необходимости: высокая кардинальность меток увеличивает нагрузку на Prometheus и может раскрывать персональные данные. Лучше агрегировать события по типу, контроллеру, коду ошибки и площадке.

7. Метрики в Prometheus: метки, агрегирование и правила

Для эффективной работы Prometheus важно правильно проектировать имена и labels. В качестве меток полезны domain, site, dc, service и result. Избегайте меток с уникальными DN, логинами, GUID и сырыми сообщениями ошибок: они создают большое число временных рядов.

Примеры концептуальных метрик, которые может публиковать экспортёр или скрипт:

• ad_ldap_probe_success — успешность синтетической проверки LDAP;
• ad_ldap_probe_duration_seconds — длительность LDAP-запроса;
• ad_replication_last_success_timestamp_seconds — время последней успешной репликации;
• ad_replication_failures_total — число ошибок репликации;
• ad_dns_query_success — результат проверки DNS-запроса;
• ad_time_offset_seconds — отклонение времени от эталона.

Это примеры схем именования, а не гарантированные имена готовых метрик конкретного экспортёра. Перед написанием правил проверьте реальные серии и типы метрик, чтобы корректно применять функции PromQL.

alert: ADLDAPProbeFailure expr: ad_ldap_probe_success == 0 for: 5m labels: severity: critical annotations: summary: "LDAP-проверка контроллера домена не проходит" description: "Проверьте доступность службы, сеть, DNS и учетные данные синтетического теста."

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

8. Оповещения, дашборды и практическая организация

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

1. Обзор домена: доступность контроллеров, состояние основных служб и общий статус площадок.
2. Протоколы: LDAP/LDAPS, DNS и Kerberos — проверки и задержки.
3. Репликация: партнеры, naming contexts, ошибки и возраст последней синхронизации.
4. Ресурсы: CPU, память, диски и сеть.
5. Безопасность: агрегированные ошибки входа, блокировки и изменения критичных групп.

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

9. Типичные ошибки мониторинга AD

• Считать ping-проверку достаточным подтверждением работоспособности домена.
• Не отслеживать репликацию между площадками и отдельными naming contexts.
• Использовать слишком низкие пороги, из-за чего команда привыкает игнорировать тревоги.
• Экспортировать пользовательские идентификаторы как метки Prometheus и создавать взрывную кардинальность.
• Хранить пароли сервисных учетных записей в открытых конфигурациях экспортёров.
• Не проверять доступность метрик и сам exporter: отсутствие данных может выглядеть как нулевой показатель.
• Опираться только на метрики без событийных журналов и контекста изменений.

FAQ (часто задаваемые вопросы)

Достаточно ли контролировать CPU, память и ping?

Нет. Эти показатели не подтверждают, что LDAP-запросы, DNS-разрешение, Kerberos и репликация работают корректно. Добавьте функциональные проверки ключевых протоколов и контроль задержки репликации.

Нужен ли отдельный экспортёр для Active Directory?

Не обязательно: часть системных счетчиков можно собирать через windows_exporter. Для синтетических LDAP-, DNS- и репликационных проверок часто применяют отдельные скрипты или специализированные экспортёры.

Какой порог использовать для оповещения о репликации?

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

Можно ли хранить имена пользователей в labels Prometheus?

Обычно этого следует избегать. Уникальные значения резко увеличивают кардинальность временных рядов и могут раскрывать персональные данные. Для мониторинга используйте агрегированные счетчики и подробные журналы в ограниченной системе хранения.

Как обнаружить проблему с DNS для AD?

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

Заключение

Мониторинг контроллеров домена должен отражать не только состояние серверного оборудования, но и работоспособность самих функций каталога. Критически важны доступность LDAP, DNS и Kerberos, своевременная репликация, синхронизация времени, состояние служб и ресурсные показатели.

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