Я давно собирался настроить мониторинг службы DFS Replication на нашем Zabbix, но готовых шаблонов в сети не нашел. Попалось несколько заброшенных проектов тут и тут, но первый автор так и не довел до конца, а во втором не работала ссылка для скачивания шаблона. К тому же, оба ограничивались лишь мониторингом бэклогов, хотя по факту метрик намного больше. Поэтому я решил сделать свой велосипед с круглым рулем и турбинами шаблон с дискавери и скриптами. Начал уже давно, но довести дело до конца всё руки не доходили. Как говорится, нет худа без добра: на удаленке в самоизоляции наконец доделал. Работы было проделано много, но я не жадный, поэтому делюсь. :)

Before you begin

• Далее в тексте под хостом я буду иметь в виду сервер с ролью DFSR, для которого настраивается мониторинг.

• Иногда для краткости вместо словосочетаний группа репликации и реплицируемая папка я буду пользоваться аббревиатурами RG и RF.

В общем и целом

В первую очередь надо было определить для себя, что мониторить и как мониторить.

Ответить на второй вопрос мне было легко. Разумеется, это будет мониторинг агентом с LLD и кастомными скриптами. Выбирая язык для скриптов, я, не долго думая, остановился на PowerShell. Много возможностей, активно продвигается Microsoft, горячо любим мной :). Была еще мысль сделать на VBScript для легковесности совместимости со старыми версиями Windows, но, подумав, отказался от этой затеи.

Всего в решении два PS-скрипта: Get-DFSRObjectDiscovery.ps1 и Get-DFSRObjectParam.ps1

Как легко понять из названия, первый - для обнаружения объектов мониторинга (item или элемент данных в терминлогии Zabbix), второй - для получения значений свойств этих объектов. Данные в основном собираются посредством WMI-запросов. Разбирать скрипты здесь не буду, т.к. комментарии есть в самом коде.

Ответить на вопрос "что мониторить?" было сложнее. Методом тыка Полагаясь на свой опыт развертывания DFSR и изучив документацию, я выделил несколько основных сущностей, относящихся к DFSR, для каждой из этих сущностей составил список параметров, значения которых мне было бы интересно мониторить.

Итак, сущности:

• группы репликации;

• реплицируемые папки;

• подключения;

• тома DFSR;

• партнеры;

• общее состояние.

Метрики для каждой из сущностей и способы их сбора будут описаны ниже.

Данные будут собираться только для тех объектов DFSR, к которым имеет отношение хост. Например, если в Active Directory есть группа репликации MyRG3, но хост в нее не входит, то метрики для нее собираться не будут. Аналогично с папками и подключениями.

Для большинства айтемов и триггеров в шаблоне есть описания и ссылки на статьи из базы знаний Microsoft.

В лабе я тестировал шаблон на разных версиях Zabbix от 2.2 до 5.0 и Windows от 2008R2 SP1 до 2019, в продакшне опробовал на Zabbix 3.4, Zabbix 5.0 и Windows 2012 R2.

В шаблоне используются преобразования значений (value mapping), поэтому потребуются права суперадмина на сервере Zabbix.

Группы репликации (DFS Replication Groups)

Параметры:

• количество исходящих подключений (outbound connections);

• количество входящих подключений (inbound connections);

• количество реплицируемых папок (number of folders);

• отключенное расписание (blank schedule).

Все эти параметры и триггеры для них описаны в правиле обнаружения DFS Replication Groups LLD.

С количеством подключений и папок, думаю, понятно, про расписание немного поясню. Для группы репликации задается расписание по умолчанию, которое будут наследовать подключения, создаваемые между партнерами этой группы. Администратор может ограничить использование полосы пропускания в зависимости от дня недели и времени суток вплоть до полной остановки репликации в определенное время. В случае, если в расписании репликация отключена полностью для каждого часа каждого дня недели, этот параметр будет равен 1, в противном случае должен возвращаться 0.

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

Реплицируемые папки (DFS Replicated Folders)

Параметры:

• количество файлов в бэклогах (backlog size);

• состояние (state)

• включена или выключена (enabled)

• режим "только чтение" ('read-only' mode)

• настройка "Переместить удаленные файлы в папку конфликтов и удалений" ('remove deleted' enabled)

• отказоустойчивость (redundancy)

• размер, заданный для промежуточной папки (stage quota)

• занятое место в промежуточной папке (stage used)

• процент свободного места в промежуточной папке (stage free (percentage))

• размер, заданный для папки конфликтов и удалений (conflict quota)

• занятое место в папке конфликтов и удалений (conflict used)

• процент свободного места в папке конфликтов и удалений (conflict free (percentage))

• данные счетчиков производительности;

Для бэклогов создано правило обнаружения DFS Replicated Folders Backlog LLD. Я решил мониторить только исходящие бэклоги. Во-первых, DFSR - распределенная система, поэтому предполагается, что мониторинг будет настроен комплексный, на все DFSR-серверы. И, учитывая, что исходящий бэклог сервера = входящий бэклог его партнера, я решил не дублировать по сути одну и ту же метрику, привязывая ее к разным хостам. Во-вторых, очередь входящих файлов характеризует больше не локальный сервер, а его партнера, расходуя место в его промежуточной папке и, как правило, вызывая предупреждения в журнале событий этого партнера.

Для кастомизации мониторинга бэклогов есть 3 макроса:

{$BACKLOGMAXWARNING} - порог для warning-триггера (по умолчанию равен 10);

{$BACKLOGMAXAVERAGE} - порог для average-триггера (по умолчанию равен 100);

{$BACKLOGPERIOD} - как долго размер бэклога должен быть выше порогового значения (по умолчанию 15 минут).

Таким образом, если количество файлов в бэклоге превышает 10 в течение 15 минут, срабатывает warning-триггер. Если же количество файлов переваливает за 100, то срабатывает уже average-триггер.

Кстати, пока прорабатывал тему мониторинга DFSR, с удивлением обнаружил, что в Managment Pack для SCOM ("православная" система мониторинга для продуктов Microsoft) сбор данных о бэклогах по умолчанию отключен для экономии ресурсов сервера. Мне же это видится одной из главных метрик, дающих представление о состоянии сервиса. Поэтому я добавил для него еще и график:

За сбор остальных параметров (кроме счетчиков производительности) отвечает правило DFS Replicated Folders LLD. Здесь всё должно быть понятно, поясню только параметры state и redundancy.

State - это состояние папки, которое может принимать одно из следующих значений:

• Uninitialized (0)

• Initialized (1)

• Initial Sync (2)

• Auto Recovery (3)

• Normal (4)

• In Error (5)

Redundancy - это количество партнеров, на которых есть копия папки в состоянии Normal. Если окажется, что у папки нет рабочих копий ни на одном из партнеров, сработает соответствующий триггер.

Предвосхищая резонный вопрос про stage free (percentage) и conflict free (percentage), сразу отвечу. Да, можно было бы сделать их в виде вычисляемых айтемов, но я решил выполнять эти вычисления на стороне хостов, чтобы снизить нагрузку на zabbix-сервер.

Если в промежуточной папке или папке конфликтов остается менее 5% свободного места, срабатывают соответствующие триггеры. Стандартное значение 5% можно переназначить с помощью макросов {$STAGEDIRPFREEMIN} и {$CONFLICTDIRPFREEMIN}.

Для счетчиков производительности есть правило обнаружения DFS Replicated Folders PerfCounters LLD. Большинство прототипов в нем отключено по умолчанию, т.к., на мой взгляд, это лишняя информация, которая будет расходовать место в базе данных и отнимать процессорное время. Но ничто не мешает вам включить нужные счетчики как на уровне шаблона, так и для конкретного хоста или даже айтема на этом хосте. Кстати, при работе со счетчиками есть свои нюансы, о которых я расскажу позже в отдельной статье.

А вот одним из полезных, на мой взгляд, счетчиков счетчик Conflict Files Generated, который возвращает суммарное число файлов, проигравших в конфликтах для определенной RF. Поэтому для него есть соответствующий прототип айтемов и триггеры. Для кастомизации этих триггеров есть макросы:

{$CONFLICTSGENERATEDCHANGEWARNING} - пороговое значение, при превышении которого сработает warning-триггер (по умолчанию 10);

{$CONFLICTSGENERATEDCHANGEAVERAGE} - аналогично для average-триггера (по умолчанию 100);

{$CONFLICTSGENERATEDPERIOD} - период времени, в течение которого должно произойти нужное количество конфликтов, чтобы сработал триггер (по умолчанию 5 минут).

Таким образом, если за 5 минут обнаружится более 10-ти конфликтов, то сработает warning-триггер, если больше 100 - то average-триггер.

Зачем вообще отслеживать конфликты? Представим такую ситуацию. У нас есть общая папка, опубликованная  в DFSN в виде виртуального пути \\abc.com\Share. Для папки есть два конечных объекта (реальные шары на файловых серверах): \\server1\Share и \\server2\Share. Эти шары входят в группу репликации и доступны конечным пользователям в режиме чтение+запись на обоих серверах. Файловые серверы расположены в разных AD-сайтах (пусть будет Office1 и Office2). Пользователь Иванов из Office1, обратившись по пути \\abc.com\Share, попадает на server1, а его коллега Петров из Office2 - на server2 (разумеется, для пользователей это происходит прозрачно и они не подозревают, что каждый из них работает со своей копией файлов, которые фактически расположены на разных серверах). Иванов и Петров открывают файл \\abc.com\Share\Важный_отчет.xlsx (каждый - со своего сервера) и заносят туда данные. А потом перед совещанием внезапно оказывается, что сохранились только те данные, которые внес Петров, а то, что сделано Ивановым, чудесным образом исчезло, хотя он честно жал Ctrl+S каждые 5 минут, как его учили технари. Благо, данные таки можно восстановить, но зуб на ИТ у Иванова останется, ибо виноват во всем админ Сидоров, который не предусмотрел такой сценарий.

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

Для RF есть 4 прототипа графиков:

• использование места в папке конфликтов и удалений (conflict space usage)

• использование места в промежуточной папке (stage space usage)

• размер данных, полученных от партнеров с учетом сжатия и без него (received bytes)

• количество принятых файлов и количество конфликтов (received files and conflicts)

Подключения (DFS Replication Connections)

Параметры:

• состояние (state);

• включено или выключено (enabled);

• отключенное расписание (blank schedule);

• данные счетчиков производительности.

Два правила обнаружения: DFS Replication Connections LLD - для первых трех параметров, DFS Replication Connections PerfCounters LLD - для счетчиков.

State - это состояние подключения, может быть таким:

• Connecting (0)

• Online (1)

• Offline (2)

• In Error (3)

Enabled - тут понятно.

Blank schedule - аналогично параметру для RG. Подключение может иметь индивидуальное расписание, отличное от дефолтного, заданного на уровне RG.

Как и для RF, прототипы айтемов здесь почти все отключены, оставлен только счетчик bytes received per second, для которого также есть график:

Тома DFSR (DFS Replication Service Volumes)

Параметры:

• состояние (state);

• данные счетчиков производительности.

Два правила обнаружения: DFS Replication Service Volumes LLD и DFS Replication Service Volumes PerfCounters LLD. Первое - для параметра state, который может принимать следующие значения:

• Initialized (0)

• Shutting Down (1)

• In Error (2)

• Auto Recovery (3)

Второе правило обнаружения используется для счетчиков производительности и по умолчанию отключено.

Партнеры (DFS Replication Partners)

Параметры:

• доступность по PING (ping check);

• доступность по WMI (WMI check).

За оба параметра отвечает правило обнаружения DFS Replication Partners LLD. Как следует из названия, это два типа проверки: проверяется, может ли хост "достучаться" до каждого из партнеров по ICMP и WMI. Подключение по WMI будет выполняться под учетной записью, из-под которой работает служба zabbix-агента. При этом единственное назначение WMI-проверки - убедиться, что установленный на хосте агент может связаться с DFSR-партнером для сбора параметров backlog size и redundancy (они были описаны выше при разборе метрик для реплицируемых папок). А для этого необходимо, чтобы учетная запись zabbix-агента обладала правами локального администратора на каждом из партнеров. Иными словами, WMI-проверка подскажет, если у учетной записи агента не хватает прав на каком-либо из партнеров. Выглядеть это будет вот так:

Общее состояние (General)

Параметры:

• установлена ли роль DFSR (DFS Replication role installed);

• количество групп репликации, в которые входит сервер (Number of replication groups);

• количество ошибок и предупреждений в журнале событий DFSR (DFSR Event Log);

• состояние службы (DFS Replication service state);

• аптайм службы (DFS Replication service uptime);

• версия службы (DFSR Service Version);

• версия поставщика DFSR (DFSR Provider Version);

• версия поставщика мониторинга DFSR (DFSR Monitoring Provider Version);

Последние два параметра по умолчанию отключены.

Здесь правила обнаружения не нужны, поэтому все параметры находятся в разделе Items шаблона.

Немного замечаний о мониторинге журнала событий. За это отвечают 3 айтема, каждый из которых мониторит события определенного уровня критичности:

• DFSR Event Log: number of warnings

• DFSR Event Log: number of errors

• DFSR Event Log: number of critical errors

Парсинг журнала был отдан на откуп агенту, а точнее - PS-скрипту. На входе скрипт получает тип событий (предупреждение, ошибка, критическое) и период, за который нужно проанализировать журнал. На выходе отдает количество событий, соответствующих заданным критериям. Если за последний час в логе найдется хотя бы одно предупреждение или ошибка, то сработает триггер. Эти настройки можно поменять с помощью макросов:

{$DFSRLOGCRITICALMAX} - количество событий со статусом "Критическое" в логе DFSR, при превышении которого должен срабатывать high-триггер (по умолчанию 0);

{$DFSRLOGERRORSMAX} - количество событий со статусом "Ошибка" в логе DFSR, при превышении которого должен срабатывать average-триггер (по умолчанию 0);

{$DFSRLOGWARNINGSMAX} - количество событий со статусом "Предупреждение" в логе DFSR, при превышении которого должен срабатывать warning-триггер (по умолчанию 0);

{$DFSRLOGPERIOD} - за какое время надо анализировать лог (по умолчанию 1 час)

Состояние службы может принимать такие значения:

• Service Starting (0)

• Service Running (1)

• Service Degraded (2)

• Service Shutting Down (3)

• Stopped (100)

• Not Found (101)

Остальные параметры разбирать не буду, там всё ясно из названия.

Напоследок

Чтобы иметь наглядную картину, я создал для каждой RG соответствующую группу хостов на Zabbix-сервере и сделал для каждой RG скрин, на котором видно общее состояние хостов группы и графики для различных метрик.

Получилось примерно так:

В процессе продакшн-эксплуатации шаблона выявилась проблема с опросом значений счетчиков производительности для RF: по непонятным мне причинам агент Zabbix перестает получать их показания и генерирует в своем логе ошибки вида "perf_counter[\XXX\YYY]" is not supported: Cannot obtain performance information from collector. Средствами же самой Windows (perfmon, typeperf, Get-Counter) эти счетчики опрашиваются нормально. Лечится перезапуском службы Zabbix Agent. Проблема касается только RF-счетчиков, счетчики для других сущностей (например, для подключений) агент опрашивает без проблем.

Шаблон и инструкции по установке есть на GitHub и Zabbix Share. Забирайте!

Буду рад конструктивной критике и предложениям по улучшению шаблона.

Источники вдохновения

Monitoring DFSR

DFSR WMI Classes

DFSR Performance Objects, Their Counters, Corresponding WMI Classes, and Using WMIC or Vbscript to View Them

Get-DFSRBacklog (Technet gallery)

DFS Replication Backlog Discovery

DFS Replication Management Pack for Windows Server 2008 R2

Optional configuration for the DFS Replication Management Pack

PowerShell — Zabbix — Json и ConvertTo-Json2

Displaying Unicode in Powershell

powershell : changing the culture of current session

Searching the Active Directory with PowerShell

PowerShell scripting performance considerations