Zabbix-шаблон для мониторинга DFS-репликации

    Я давно собирался настроить мониторинг службы 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

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 9

      0
      Скрипты для автодискавери на Powershell — делеко не самый оптимальный вариант (возможны таймауты под нагрузкой, скрипт может отвалиться с ошибкой итд). Помимо этого, нужно скрипты закидывать в агент и конфигурировать агент.

      Есть нативный дискавери для WMI — можно как-нибудь использовать его, не прибегая к кастомным скриптам?

      www.zabbix.com/documentation/current/manual/discovery/low_level_discovery/wmi
        0
        ПризнАюсь, не знал. Получается, что можно, но:
        1) в процессе продакшн-использования шаблона (десяток серверов и несколько ТБ данных) просадок по производительности не наблюдал, кроме одного сервера, которому изначально выдали всего два vCPU (на остальных было по 4 или 8), что легко решилось добавлением виртуалке процессорных мощностей; а вообще, как уже было сказано в статье, на тему оптимизации и производительности PS хорошо ответили тут

        2) не все WMI-запросы вернут вам данные в удобном виде, например, в некоторых не будет имён RG/RF, а будут только их GUID'ы — в итоге получите айтем с малоинформативным именем;

        3) не всё можно обнаружить WMI-запросами (например, обнаружить с их помощью партнёров репликации у меня не получилось)

        А так да, «идея богатая».
        0
        Попробуем.
          0
          Ох уж эта DFS Репликация!
          У нас по скрипту Powershell каждое утро приходит сколько баклога, доступность сервисов на DFS серверах и смысла нет даже что то еще вставлять.
          Главное чтобы полоса была нормальной между городами и странами.
            0
            Самое главное с чем столкнулись в своей реализации — таймауты от агентов при мониторинге беклога больших папок.
            На больших папках — они неизбежны, поскольку беклог в 1000+, а то и в 10000+ это норма у нас при больших изменениях.
            Выкручивались шедулером, который собирает инфу в текстовые файлы, заббикс уже работает с ними (дискавери и опрос).

            Как у вас это обходится?
              0
              Тайм-аут в настройках агента 10-15 секунд, периодичность опроса бэклогов 15 минут — полет нормальный. Правда, у нас больше 5000 бэклог не разрастался.
              А вы каким скриптом размер бэклога получаете?
                0
                даже на 30 сек таймаута фейлится, на особо больших папках получение размера беклога занимает до минуты иногда.
                Используется командлет Get-DfsrBacklog с -Verbose
                  0
                  Почитал ваш код — вижу что вы через WMI работаете. Интересно, спасибо, попробуем применить)
                0
                Не в ту ветку, сорри.
                У меня на одном из серверов виснет на этом месте
                $j = Get-WmiObject -ComputerName $RServerName -Namespace $DFSNamespace -Query $WMIQuery -ErrorAction Ignore -AsJob
                [void](Wait-Job $j -Timeout $RequestTimeout)

                Переписал вот так — работает.
                $j = Get-WmiObject -ComputerName $RServerName -Namespace $DFSNamespace -Query $WMIQuery -ErrorAction Ignore
                ...
                $VersionVector = $j.GetVersionVector().VersionVector

                На остальных вроде и так и так нормально.

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

                Самое читаемое