Мониторинг Microsoft Windows на базе Zabbix

03.09.2019 Update

Кстати новые шаблоны уже доступны

Сегодня мы расскажем о том, как мы ведем мониторинг Windows систем (в скором времени планируем такой же обзор про Linux и как обычно с доступным шаблоном).

Наш путь начался, как часто бывает, со штатного шаблона Zabbix «Template OS Windows Active» для мониторинга Windows-клиентов (рабочие станции и сервера), но ровно через неделю активного использования поняли, в нем много чего не хватает.

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

Общая концепция

1. Отдельные настройки шаблона в файле os_windows_active.conf

2. Отдельный скрипт PowerShell — os_windows_active.ps1 для работы шаблона, при этом скрипт должен быть универсальным и работать на большинстве операционных систем с минимумом внешних зависимостей.

3. Шаблон должен быть не зависимым от языка операционной системы, поэтому лучше всего снимать данные со счётчиков используя либо WMI, либо скрипт + zabbix trapper.

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

Основные возможности

• логических дисков;
• физических дисков;
• сетевых адаптеров;
• системных сервисов.

Triggers

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

• Продолжительная нагрузка на процессор в течении часа.

Physical Memory

• Объём доступной физической памяти меньше заданного лимита;
• Объём Commited памяти больше физической.

Physical disk

• Скорость доступа к дискам на чтение и запись.

Logical disk

• Критический объём дисков с возможностью прогноза на 12 часов.

Network

• Смена MAC-адреса сетевого адаптера (для виртуальных машин очень актуально, если не поставили статический MAC-адрес);
• Отключение Link-а сетевого адаптера;
• Отброшенные пакеты на сетевом адаптере.

Operation system

• Дата последней установки обновлений Windows
• Изменение статуса Firewall

Инвентаризация

Так как клиенты имеют разные компьютеры, нам требуется получать краткую инвентаризацию по ним, поэтому мы добавили в шаблон сбор данных о компьютере, и этими данными заполняем стандартные поля Zabbix Inventory:

• OS
• tag
• Chassis
• Desktop
• Model
• HW architecture
• Vendor
• Host networks

Графики

Мы сделали несколько полезных общих графиков, чтобы наглядно видеть общее состояние клиента и отдельных его подсистем.

OS overview performance

OS detail performance

Где скачать

Данный шаблон и скрипт вы можете бесплатно скачать с GitHub, а также в Zabbix Share.

Наши шаблоны мы продолжим выкладываем в открытый доступ в наш репозитарий Zabbix.

Системное администрирование серверов и DevOps

Шаблоны Windows в ZABBIX

Шаблоны Windows в ZABBIX отличаются главным образом использованием специфическими для этой ОС счетчиками производительности. Счетчики представляют из себя встроенное средство анализа основных показателей операционной системы, некоторого программного обеспечения, а также аппаратных ресурсов. Подавляющее большинство серьезных систем мониторинга умеют использовать эти счетчики, вот и ZABBIX не исключение . В этой статье я постараюсь рассказать об основных «подводных камнях», встретившихся мне при работе с этим инструментом.

Вводная статья по шаблонам мониторинга ZABBIX — Шаблоны ZABBIX.

Если вам интересна тематика ZABBIX, рекомендую обратиться к основной статье — Система мониторинга ZABBIX, в ней вы найдете дополнительную информацию.

Шаблоны Windows — нюансы

Прочитав документацию ZABBIX касательно настройки счетчиков (кому интересно, глава «6 Счетчики производительности Windows«), я поразился насколько все просто и был удивлен столь богатой функциональностью, но не тут то было… Поначалу я пользовался встроенными в систему шаблонами, но в итоге на некоторых узлах сети счетчики у меня работали, а на некоторых данные просто не приходили не по одному ключу. В конечном счете я решил пройти процесс создания ключа данных с использованием счетчика Windoows с самого начала и до момента пока не увижу красивые графики с необходимой мне информацией.

В руководстве все просто:

Вы можете эффективно мониторить счетчики производительности Windows используя ключ perf_counter[].
Например:
perf_counter[«\Processor(0)\Interrupts/sec»]
или
perf_counter[«\Processor(0)\Interrupts/sec», 10]

Но почему счетчики работают не на каждом узле сети? Ответ тоже прост:

В зависимости от настроек местоположения, именования счетчиков производительности могут быть разными на разных серверах Windows. Это может ввести определенные проблемы при создании шаблонов для Windows, имеющих разные настройки местоположения.
Каждый счетчик производительности может быть переведен в цифровую форму, которая является уникальной и независимой от языковых настроек, так что вы можете использовать числовое представление, а не строковое.
Для того чтобы найти цифровые эквиваленты, выполните regedit, а затем найдите HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009.

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

С переводом все элементарно: просто ищем необходимый ключ реестра (см. выше), выгружаем данные в любой текстовый файл и ищем необходимые ключи:

Здесь вы можете найти соответствующие числа для каждой части строки счетчика производительности, как для ‘\System\% Processor Time’:
System -> 2
% Processor Time -> 6
Затем используйте эти числа для преобразования пути в числа:
\2\6

UPD: 2016.05.19: есть некоторые неприятные нюансы, подробнее см. в Изменения счетчиков производительности CPU

Но тут меня ждал сюрприз: на некоторых серверах с использованием большого количества ролей я находил в этом файле несколько ключей данных! Какой из них выбрать, какой будет правильным? Я определил для себя следующие правила: поскольку счетчик состоит из двух параметров, надо найти сначала первый (ваш Кэп), запомнить примерное месторасположение в файле, а потом найти второй и если он будет выше первого по месторасположению, то игнорировать его; если же сразу после месторасположения первого мы найдем ниже него несколько одинаковых вторых ключей, то нам будет нужен ближайший к первому второй ключ. Подобная логика должна вам помочь выбрать правильный ключ данных. В противном случае получаемая информация будет некорректная или в ней не будет смысла, либо вы вообще не получите никаких данных. Нигде в интернете этого я почему-то не нашел, видимо авторы статей не слишком сильно углублялись в мониторинг счетчиков.

Далее. Следующий неприятный момент в этой системе мониторинга — это типы данных элементов мониторинга. В принципе все просто, но вы должны помнить, что тип данных автоматически не определяется и вы должны определить его самостоятельно и, что самое главное, при неправильном выборе вы останетесь без данных, они просто не будут приниматься. В случае со счетчиками производительности вам будет нужен исключительно «Числовой (с плавающей точкой)» как показано на скриншоте ниже:

Чтобы уяснить это простое правило, несколько лет назад у меня ушла куча времени и я дошел почти до отчаяния, ведь не знал ни основные проблемы при настройке, ни методики «траблшутинга». В таких случаях есть одно проверенное средство — zabbix_get, рекомендую использовать его всякий раз. когда вы находитесь в тупике.

В принципе это все, что я и хотел сказать. В интернете куча статей на тему «zabbix счетчики производительности» и копировать я их не намерен, я лишь хочу поделиться основным опытом в решении ранее казалось бы тупиковых проблем. Мало кто ставит целью не изобретение велосипеда, а описание рассуждений и логики мышления при решении обыденных для них задач, но ведь информации в интернете сейчас масса, а вырабатыванию подхода не учит почти никто.

Zabbix шаблон для мониторинга Microsoft SQL Server 2014

Делюсь полезным шаблоном для мониторинга Microsoft SQL Server 2014. Ось — Windows Server 2012 R2.

В шаблоне 70 элементов данных и 23 триггера. Плюс 11 прототипов элементов данных и 3 прототипа триггеров.

Дополнительно может понадобиться добавить в Administration > General > Regular expressions следующее регулярное выражение:

Name: Databases for discovery
Expression: ^(master|model|msdb|ReportServer|ReportServerTempDB|tempdb)$
Type: Result is FALSE

Также на сервере нужно настроить пользовательские параметры и залить ps скрипты для получения данных из базы.

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

Установка и модификация шаблона

Сначала скачиваем zbx-mssql-master.zip по ссылке выше или прямо из этой статьи. Возможно, в исходнике будет уже более полная версия. Архив содержит инструкцию по установке, опишу как действовал я. Распаковываем архив.

На вашем MSSQL сервере редактируем файл конфигурации zabbix агента zabbix_agentd.win.conf. Добавляем строку

Собственно, вы можете указать свой собственный путь, который вам нужен.

Файл userparameter_mssql.conf копируем из архива по указанному в Include пути.

Редактируем скопированный userparameter_mssql.conf. В нём есть два пользовательских параметра:

Пути к скриптам mssql_basename.ps1 и mssql_version.ps1 меняем на свои.

Копируем папку scripts из архива по указанному вами пути.

В zabbix добавляем регулярное выражение в Administration > General > Regular expressions:

Name: MS SQL Databases for discovery
Expression: ^(master|model|msdb|ReportServer|ReportServerTempDB|tempdb)$
Type: Result is FALSE

Внимание: на сайте с исходным шаблоном и в инструкции совершена ошибка, название регулярки должно быть «MS SQL Databases for discovery», а не «Databases for discovery»!

Примечание: Если вы собираетесь использовать мой модифицированный шаблон, то добавлять value mapping нет необходимости. Если же вы планируете использовать исходный шаблон, то добавляйте.

Импортируем value mapping из файла zbx_valuemaps_mssql.xml

Дальше импортируем сам шаблон. Или мой модифицированный zbx_mssql_2014.xml или исходный из архива zbx_template_mssql.xml.

Шаблон появляется в списке. Модифицированный шаблон имеет в названии 2014.

Модифицируем файл mssql_basename.ps1. Прописываем пользователя и пароль для доступа к базе данных.

Перезапускаем zabbix agent.

Своему хосту добавляем свежесозданный шаблон.

Если вы используете исходный шаблон, то внесите изменения в несколько элементов данных. Проверьте все элементы шаблона, которые содержат в названии «(KB)».

Зайдите во вкладку Preprocessing. Если нет Custom multiplier, то добавьте его со значением 1024. Я нашёл три таких «забытых» элемента данных.

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

Если вы используете исходный шаблон, то найдите сломанный элемент данных как на рисунке и измените тип на Numeric (float).

В моём шаблоне это уже исправлено.

Я ещё внес несколько изменений в исходный шаблон. В частности, удалил элемент данных и триггер связанный с получением статуса каждой базы данных через ODBC. Ибо нечего заббиксу иметь доступ к базе данных, кто это вообще придумал. Я переживу отсутствие этого элемента данных. Данный шаг позволил грохнуть требуемый value mapping. Если вы со мной согласны — можете его тоже удалить.

Также я удалил следующие элементы данных и триттеры:

Они делают следующее, как только лог базы данных пару раз увеличивается — триггер срабатывает. И всегда висит, потому что это счётчик, он не уменьшается. Зачем был нужен такой триггер — не понимаю. Со сжатием лога — то же самое, только он срабатывал после 15-го сжатия. У меня БД ежедневно жмётся и увеличивается. Для режима FULL это просто необходимо, иначе место на диске закончится. Так что не увидел смысла в этих триггерах.

Свои элементы данных

Я обещал рассказать про возможность добавлять свои элементы данных. Всё очень просто. Данный шаблон использует виндовые счётчики производительности, которые ставятся вместе с MSSQL сервером. Но не все. Вы можете добавлять свои, из списка имеющихся. Список счётчиков производительности и объектов можно увидеть здесь: https://docs.microsoft.com/en-us/sql/relational-databases/performance-monitor/use-sql-server-objects.

К примеру, прототип элемента данных perf_counter[«\SQLServer:Databases(<#DBNAME>)\Active Transactions»] использует счётчик Active Transactions объекта Databases.

Клонируете текущий элемент данных и вписываете из списка требуемый счётчик.