Мониторинг использования CPU в Zabbix

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

Допустим на высоконагруженном NAT сервере основная нагрузка от softirq, присутствует один процессор с 8 ядрами, а также на сервере установлен Zabbix агент.
И чтобы увидеть равномерно ли распределены прерывания сетевого адаптера по ядрам процессора, создадим элементы данных на Zabbix сервере, в которых укажем:
Тип: Zabbix агент
Тип информации: Числовой (с плавающей точкой)
Единица измерения: %
А также ключ:

Где 0 — номер процессора, softirq — тип нагрузки, avg5 — средняя нагрузка за 5 минут. Аналогично создадим элементы данных для других ядер процессора с ключами, а также добавим их на один график:

Вместо softirq можно указать idle, nice, user (по умолчанию для Linux), system (по умолчанию для Windows), iowait, interrupt, softirq, steal, guest, guest_nice.
А вместо avg5 можно указать: avg1 (среднее за одну минуту, по умолчанию) или avg15 (среднее за 15 минут).

Чтобы не указывать ядра процессоров вручную, можно создать правило обнаружения:

И указать в нем элемент данных, например:

Также можно создать триггер, чтобы узнать когда значение будет больше 90:

Ниже приведу примеры элементов данных, которые отображают различную информацию о CPU, кстати эти элементы данных по умолчанию присутствуют в шаблоне «Template OS Linux».

Блог белорусского сисадмина

полезные записки

Zabbix и счетчики производительности (perf counters)

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

Стоит начать с того, что имя счетчика пишется в двойных кавычках, начиная с бэкслэша (\). В точности так, как выводит его команда typeperf -qx. Т.е. правильный вид для мониторинга загрузки всех ядер CPU будет выглядеть примерно так:

Все бы ничего, но при вводе такого счетчика и довольных мыслях («ща всё замониторю с красивыми графиками») мы получаем ответ от заббикса в виде Not supported. Начинаем долго и нудно гуглить по этому вопросу и никак не натыкаемся на ответ. В качестве одной из предполагаемых причин такого поведения может быть запуск 32-битного агента на 64-битном хосте. Но даже при запуске правильного, 64-битного клиента, мы не получаем удовлетворения и видим Not supported.

А все потому, что по умолчанию, у вновь создаваемых элементов (item) мониторинга выставлен тип информации (type of information) — numeric(unsigned). Казалось бы, ничего в этом страшного нет. Загрузка процессора не может быть отрицательной. Так и есть. Но почему-то, разработчики заббикса посчитали, что под понятие numeric(unsigned) попадают ТОЛЬКО целые числа. О чем, в принципе, они честно сообщают в доках: Numeric (unsigned) — 64bit unsigned integer. Выставляем numeric(float) и тихо радуемся работающему мониторингу.

Zabbix и счетчики производительности (perf counters) : 8 комментариев

Добрый день!
Мне этот способ не помог. Странно то, что у меня очень много Windows-серверов на мониторинге и небольшая часть из них не реагирует на это ключ, остальные работают нормально. Что я только уже не делал. Идеи у меня закончились.
Может есть ещё какие-нибудь нюансы по данной проблеме?

Здравствуйте!
Какой именно ключ не помог? Загрузка процессора? Если используется локализованная винда (русская или любая другая), то ключ в таком виде работать не будет, т.к. его нет в системе. Надо подбирать вместо этого цифровое значение ключа. Например, ключ для получения процента использования файла подкачки выглядит так:
perf_counter[\700(_Total)\702]

Да, Windows на русском.
Использую вот этот ключ:
perf_counter[«\Processor(_Total)\% Processor Time»]
он не работает.
Пробовал вот этот:
perf_counter[\Процессор(_Total)\% общей загруженности процессоров]
тоже не работает.
Пробовал такой:
perf_counter[\238(_Total)\240]
тоже не поддерживается.
Во всех трёх случаях пишет: «Not supported».
Причём, я непосредственно на сервере, где нужно мониторить нагрузку на CPU из командой строки вытянул счётчики с помощью команды:
lodctr /s:perfcount.txt
и ориентировался при построении ключа для Zabbix именно по ним.
Даже не знаю что делать.

Для русской винды надо использовать только цифровое значение. Zabbix далеко не сразу пытается проверять «Not supported» счетчики после их изменения. Самый верный вариант — перезапустить сервис заббикса и агент. Опять же, можно попробовать включить дебаг-лог — он может сказать что именно ему не нравится.
Я встречал такие случаи, когда заббикс писал «Not supported» на часть айтемов на разных серверах, а на следующий день уже все работало. Можно попробовать просто оставить правильное значение для счетчика (цифровое) и подождать.

Согласен, просто понять бы какое всё-таки правильное значение. Не подскажете правильное числовое значение для общей нагрузки процессора, аналог: perf_counter[«\Processor(_Total)\% Processor Time»]
Заранее спасибо!

Найдено решение.
Для локализованной русской версии Windows аналогом ключа:
perf_counter[«\Processor(_Total)\% Processor Time»]
является ключ:
perf_counter[\Процессор(_Total)\Процент времени бездействия]

Надеюсь кому-то типа меня поможет не так долго мучаться с проблемой.
Всем большое спасибо за помощь!

Мониторинг процесса Windows с помощью Zabbix?

Как организовать мониторинг процессов windows c помощью zabbix? Интересует способ узнать сколько процентов от общего ресурса процессора потребляет тот или иной процесс.

Версия Windows: Windows 10 pro 1909 x64
Версия zabbix сервера: 4.4.3
Способ снятия метрик: активный агент

• Вопрос задан более года назад
• 1215 просмотров

1.открываем perfmon.msc (не перепутайте с perfmon.exe — это немного другая программа.)
2.в «системном мониторе» (сейчас под рукой руссифицированная ось, поэтому ищите аналогичное на английском, благо монитор по умолчанию там один) нажимаем «добавить счетчики»
3. выбираем Process и ваш процесс, нужные метрики.
Все это только для понимания «что» вы будете мониторить.
теперь «как»: идем и внимательно читаем:
https://www.zabbix.com/documentation/4.2/ru/manual.
https://www.zabbix.com/documentation/4.2/ru/manual.
В последней статье ищем proc_info — это оно и есть
Если есть какие то перфкаунтеры которых вы не нашли в заббикс — в 1й статье в конце есть как добавить нужные через user parameters

Почему perfcounters а не WMI? Потому что обращение к WMI — довольно дорогая операция, часто не позапрашиваешь (а если залезть в глубины того что доступно через WMI — выяснится что там те же перфкаунтеры, облагороженные и обогащенные) — частое обращение довольно сильно жрет CPU
Почему не сторонняя программа? Потому что Win уже собирает данные процессов и основная задача — добраться до них

Zabbix: Мониторинг выборочного процесса (CPU, MEM) с защитой от ложных срабатываний

Как создать универсальный Zabbix шаблон для мониторинга Linux процесса, указанного по имени.

1. Создание нового шаблона Zabbix

Идем в Configuration -> Templates -> Create template и добавляем имя, группу и описание шаблона.

2. Добавление макроса

Мы хотим мониторить 3 параметра:

• количество процессов, с уведомлением о том, что процессов стало меньше (упали)
• использование памяти, с уведомлением о превышении
• использование процессора, с уведомлением о превышении

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

В этом примере мы создали 6 макросов.

Тут вы можете увидеть максимально использование cpu 70%, использование памяти 2G, минимально 1 запущенный процесс, а так же имя процесса для примера: apache2. Так же мы должны задать нормальные значения наших параметров для построения гистерезиса в целях защиты от ложных срабатываний (описано ниже). По этому мы так же указываем как 10% и как 1G.

3. Добавление элементов данных

Теперь мы должны добавить элементы входных данных (items). Переходим в меню Items нашего шаблона и кликаем кнопку: Create item. Затем создаем 3 элемента:

• количество процессов
• использование cpu
• использование памяти

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

Заметим, что параметры могут иметь различные типы данных. Так к примеру proc.num, proc.mem имеет тип данных: Numeric (int), а proc.cpu.util – Numeric (float). Вы можете удостовериться в правильности указания типа данных в меню Key -> Select или официальной документации Zabbix.

4. Триггеры с гистерезисом

Пришло время создать тригеры. Переходим в закладку Triggers нашего шаблона. Вы можете использовать встроенный конструктор выражений, нажав Problem expression -> Add, затем выбрав item и function. К примеру last (most recent) T value. Но это только одно последнее значение. Оно будет меняться каждый раз, что вызовет нестабильность в определении статуса. Чтобы определить жесткое (установившееся) значение статуса, это значение должно повториться несколько раз подряд. Для такого подсчета лучше использовать функцию count. Болле подробную информацию о функциях вы можете получить в официальной документации Zabbix.

Итак, создаем триггер, который будет срабатывать при привышении потребления памяти больше чем <$PROC_MEM_MAX>3 раза подряд.

Мы можем прочитать его так: “Количество (count) последних 3 значений (#3), которые были больше (gt) чем равно >= 3″. Что означает, что все последние 3 значения были были больше чем PROC_MEM_MAX. Это хороший способ определения устоявшегося значения.

Но что делать с возвратом в нормальное состояние? Если мы просто оставим так как есть, мы рискуем получить что-то на подобие этого:

Каждые 5-10 минут статус меняет значение, колеблясь то выше, то ниже указанного порога. Он получает 3 подряд превышающих значения и триггер срабатывает, после чего он получает 3 нормальных значения и помечает проблему как RESOLVED (решена)! Что же делать? Нам поможет гистерезис с указанием не только максимального, но и нормального значения. Триггер будет в состоянии PROBLEM (проблема) до тех пор, пока значение нашего элемента не опустится до $.

Итак, нажимаем OK event generation -> Recovery expression и добавляем выражение:

Его можно прочитать как: “Количество (count) последних трех (#3) значений элемента, которые были меньше или равны (le) числу было >= 3 раз. То есть установившееся в нормальном положении значение.

Подобным образом добавляем остальные тригеры (для использования процессора и количества процессов):

5. Конфигурация хоста

Теперь мы можем добавить наш шаблон к хосту. Идем в Configuration -> Hosts -> ваш сервер -> Templates. И добавляем только что созданный шаблон к серверу. Далее мы должны переопределись макросы.

Для примера на нашем сервере необходимо мониторить процесс node (node.js). Давайте посмотрим один из моих графиков данного процесса:

Вы видите, что у меня он потребляет порядка 4Gb RAM. Это нормальное состояние для моего сервиса. Так же вы видите колебание в районе красной линии. Без гистерезиса Zabbix нас просто заспамил бы сообщениями об изменении статуса в районе этой линии. В моем примере нормальное значение потребления памяти для указания в гистерезисе это 4G, а максимальное – больше чем 4.20G, пусть будет 4,5G. Добавим эти значения, а так же имя нашего процесса как макросы для данного хоста:

Итак, мой триггер перейдет в состоянии PROBLEM только когда значение потребляемой памяти будет больше чем 4,5Gb 3 раза подряд. А вернется он в нормальное состояние только тогда, когда потребление снизится ниже 4Г 3 раза подряд.

Готово! Позравляю! Теперь можно проверить последние данные в разделе Monitoring -> Latest data.

Zabbix Documentation 5.2

Sidebar

Table of Contents

7 Счетчики производительности Windows

Обзор

Вы можете эффективно мониторить счетчики производительности Windows используя ключ perf_counter[].

Для получения более подробной информации об этом ключе, смотрите специфичные ключи элементов данных для Windows.

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

Числовое представление

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

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

Для того чтобы найти цифровые эквиваленты, выполните regedit, а затем найдите HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009.

Запись в реестре содержит информацию наподобии этой:

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

Затем вы можете использовать эти числа для преобразования пути в числа:

Пользовательские параметры

Вы можете разворачивать некоторые PerfCounter параметры для мониторинга счетчиков производительности Windows.

Например, вы можете добавить следующее в файл конфигурации Zabbix агента:

С такими параметрами, вы можете просто использовать UserPerfCounter1 или UserPerfCounter2 как ключи при создании соответствующих элементов данных.

Не забудьте перезапустить Zabbix агента после внесения изменений в файл конфигурации.