Оффлайн
- Регистрация
- 21.07.20
- Сообщения
- 40.408
- Реакции
- 1
- Репутация
- 0
Я давно собирался настроить мониторинг службы DFS Replication на нашем Zabbix, но готовых шаблонов в сети не нашел. Попалось несколько заброшенных проектов
велосипед с круглым рулем и турбинами шаблон с дискавери и скриптами. Начал уже давно, но довести дело до конца всё руки не доходили. Как говорится, нет худа без добра: на удаленке в самоизоляции наконец доделал. Работы было проделано много, но я не жадный, поэтому делюсь. 
Before you begin
В первую очередь надо было определить для себя, что мониторить и как мониторить.
Ответить на второй вопрос мне было легко. Разумеется, это будет мониторинг агентом с LLD и кастомными скриптами. Выбирая язык для скриптов, я, не долго думая, остановился на PowerShell. Много возможностей, активно продвигается Microsoft, горячо любим мной. Была еще мысль сделать на VBScript для легковесности совместимости со старыми версиями Windows, но,
Всего в решении два PS-скрипта: Get-DFSRObjectDiscovery.ps1 и Get-DFSRObjectParam.ps1
Как легко понять из названия, первый - для обнаружения объектов мониторинга (item или элемент данных в терминлогии Zabbix), второй - для получения значений свойств этих объектов. Данные в основном собираются посредством WMI-запросов. Разбирать скрипты здесь не буду, т.к. комментарии есть в самом коде.
Ответить на вопрос "что мониторить?" было сложнее.Методом тыка Полагаясь на свой опыт развертывания 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)
Параметры:
Все эти параметры и триггеры для них описаны в правиле обнаружения DFS Replication Groups LLD.
С количеством подключений и папок, думаю, понятно, про расписание немного поясню. Для группы репликации задается расписание по умолчанию, которое будут наследовать подключения, создаваемые между партнерами этой группы. Администратор может ограничить использование полосы пропускания в зависимости от дня недели и времени суток вплоть до полной остановки репликации в определенное время. В случае, если в расписании репликация отключена полностью для каждого часа каждого дня недели, этот параметр будет равен 1, в противном случае должен возвращаться 0.
С помощью триггеров отслеживается отключение расписания, изменение количества подключений и реплицируемых папок в группе. Триггеры простые, поэтому разбирать их не буду.
Реплицируемые папки (DFS Replicated Folders)
Параметры:
Для бэклогов создано правило обнаружения 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 - это состояние папки, которое может принимать одно из следующих значений:
Redundancy - это количество партнеров, на которых есть копия папки в состоянии Normal. Если окажется, что у папки нет рабочих копий ни на одном из партнеров, сработает соответствующий триггер.
Предвосхищая резонный вопрос про stage free (percentage) и conflict free (percentage), сразу отвечу. Да, можно было бы сделать их в виде
Если в промежуточной папке или папке конфликтов остается менее 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-решения. И лучше об этом заранее узнать от системы мониторинга, чем потом от пользователей.
Разумеется, есть случаи, когда конфликты - это нормальная ситуация, которая не приводит к потере бизнес-значимых данных, но обычно обилие конфликтов говорит о неверно продуманной архитектуре DFS-решения. И лучше об этом заранее узнать от системы мониторинга, чем потом от пользователей.
Для RF есть 4 прототипа графиков:
Параметры:
Два правила обнаружения: DFS Replication Connections LLD - для первых трех параметров, DFS Replication Connections PerfCounters LLD - для счетчиков.
State - это состояние подключения, может быть таким:
Enabled - тут понятно.
Blank schedule - аналогично параметру для RG. Подключение может иметь индивидуальное расписание, отличное от дефолтного, заданного на уровне RG.
Как и для RF, прототипы айтемов здесь почти все отключены, оставлен только счетчик bytes received per second, для которого также есть график:
Тома DFSR (DFS Replication Service Volumes)
Параметры:
Два правила обнаружения: DFS Replication Service Volumes LLD и DFS Replication Service Volumes PerfCounters LLD. Первое - для параметра state, который может принимать следующие значения:
Второе правило обнаружения используется для счетчиков производительности и по умолчанию отключено.
Партнеры (DFS Replication Partners)
Параметры:
За оба параметра отвечает правило обнаружения DFS Replication Partners LLD. Как следует из названия, это два типа проверки: проверяется, может ли хост "достучаться" до каждого из партнеров по ICMP и WMI. Подключение по WMI будет выполняться под учетной записью, из-под которой работает служба zabbix-агента. При этом единственное назначение WMI-проверки - убедиться, что установленный на хосте агент может связаться с DFSR-партнером для сбора параметров backlog size и redundancy (они были описаны выше при разборе метрик для реплицируемых папок). А для этого необходимо, чтобы учетная запись zabbix-агента обладала правами локального администратора на каждом из партнеров. Иными словами, WMI-проверка подскажет, если у учетной записи агента не хватает прав на каком-либо из партнеров. Выглядеть это будет вот так:
Общее состояние (General)
Параметры:
Последние два параметра по умолчанию отключены.
Здесь правила обнаружения не нужны, поэтому все параметры находятся в разделе Items шаблона.
Немного замечаний о мониторинге журнала событий. За это отвечают 3 айтема, каждый из которых мониторит события определенного уровня критичности:
Парсинг журнала был отдан на откуп агенту, а точнее - PS-скрипту. На входе скрипт получает тип событий (предупреждение, ошибка, критическое) и период, за который нужно проанализировать журнал. На выходе отдает количество событий, соответствующих заданным критериям. Если за последний час в логе найдется хотя бы одно предупреждение или ошибка, то сработает триггер. Эти настройки можно поменять с помощью макросов:
{$DFSRLOGCRITICALMAX} - количество событий со статусом "Критическое" в логе DFSR, при превышении которого должен срабатывать high-триггер (по умолчанию 0);
{$DFSRLOGERRORSMAX} - количество событий со статусом "Ошибка" в логе DFSR, при превышении которого должен срабатывать average-триггер (по умолчанию 0);
{$DFSRLOGWARNINGSMAX} - количество событий со статусом "Предупреждение" в логе DFSR, при превышении которого должен срабатывать warning-триггер (по умолчанию 0);
{$DFSRLOGPERIOD} - за какое время надо анализировать лог (по умолчанию 1 час)
Состояние службы может принимать такие значения:
Остальные параметры разбирать не буду, там всё ясно из названия.
Напоследок
Чтобы иметь наглядную картину, я создал для каждой 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-счетчиков, счетчики для других сущностей (например, для подключений) агент опрашивает без проблем.
Шаблон и инструкции по установке есть на
Буду рад конструктивной критике и предложениям по улучшению шаблона.
Источники вдохновения
You must be registered for see links
и
You must be registered for see links
, но первый автор так и не довел до конца, а во втором не работала ссылка для скачивания шаблона. К тому же, оба ограничивались лишь мониторингом бэклогов, хотя по факту метрик намного больше. Поэтому я решил сделать свой Before you begin
Далее в тексте под хостом я буду иметь в виду сервер с ролью DFSR, для которого настраивается мониторинг.
Иногда для краткости вместо словосочетаний группа репликации и реплицируемая папка я буду пользоваться аббревиатурами RG и RF.
В первую очередь надо было определить для себя, что мониторить и как мониторить.
Ответить на второй вопрос мне было легко. Разумеется, это будет мониторинг агентом с LLD и кастомными скриптами. Выбирая язык для скриптов, я, не долго думая, остановился на PowerShell. Много возможностей, активно продвигается Microsoft, горячо любим мной
. Была еще мысль сделать на VBScript для легковесности совместимости со старыми версиями Windows, но,
You must be registered for see links
, отказался от этой затеи.Всего в решении два PS-скрипта: Get-DFSRObjectDiscovery.ps1 и Get-DFSRObjectParam.ps1
Как легко понять из названия, первый - для обнаружения объектов мониторинга (item или элемент данных в терминлогии Zabbix), второй - для получения значений свойств этих объектов. Данные в основном собираются посредством WMI-запросов. Разбирать скрипты здесь не буду, т.к. комментарии есть в самом коде.
Ответить на вопрос "что мониторить?" было сложнее.
Итак, сущности:
группы репликации;
реплицируемые папки;
подключения;
тома 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), сразу отвечу. Да, можно было бы сделать их в виде
You must be registered for see links
, но я решил выполнять эти вычисления на стороне хостов, чтобы снизить нагрузку на 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 минут, как его учили технари. Благо, данные таки
You must be registered for see links
, но зуб на ИТ у Иванова останется, ибо виноват во всем админ Сидоров, который не предусмотрел такой сценарий.Разумеется, есть случаи, когда конфликты - это нормальная ситуация, которая не приводит к потере бизнес-значимых данных, но обычно обилие конфликтов говорит о неверно продуманной архитектуре DFS-решения. И лучше об этом заранее узнать от системы мониторинга, чем потом от пользователей.
Разумеется, есть случаи, когда конфликты - это нормальная ситуация, которая не приводит к потере бизнес-значимых данных, но обычно обилие конфликтов говорит о неверно продуманной архитектуре DFS-решения. И лучше об этом заранее узнать от системы мониторинга, чем потом от пользователей.
Для RF есть 4 прототипа графиков:
использование места в папке конфликтов и удалений (conflict space usage)
использование места в промежуточной папке (stage space usage)
размер данных, полученных от партнеров с учетом сжатия и без него (received bytes)
количество принятых файлов и количество конфликтов (received files and conflicts)
Параметры:
состояние (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-счетчиков, счетчики для других сущностей (например, для подключений) агент опрашивает без проблем.
Шаблон и инструкции по установке есть на
You must be registered for see links
и
You must be registered for see links
. Забирайте!Буду рад конструктивной критике и предложениям по улучшению шаблона.
Источники вдохновения
You must be registered for see links
You must be registered for see links
You must be registered for see links
You must be registered for see links
You must be registered for see links
You must be registered for see links
You must be registered for see links
You must be registered for see links
You must be registered for see links
You must be registered for see links
You must be registered for see links
You must be registered for see links