System.run в Zabbix на примере мониторинга кластера Proxmox

System.run довольная простая, но в то же время очень полезная проверка. Прямо в гуе заббикса в активной проверке указываем system.run(команда) и получаем её вывод. Получается, с помощью этой проверки мы можем получать какие угодно метрики и состояния, которые можем получить из комадной строки. И это всё «от и до» в веб-гуе заббикса, в отличие от UserParameter.

Самое важное, что можем узнать о кластере из комманды pvecm:

• Статус кластера
• Количество нод в кластере
• Активные ноды
• Зафейленые ноды

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

Статус кластера можем получить из состояния переменной Quorate. Если Yes — всё ок, No — не ок. Нужное значение отфильтруем с помощью регулярного выражения

Но текстовое значение нам не нужно, нужно 1 либо 0. Параметр «-с» grep даёт количество строк, которое соответствует запрошенному значению, при grep -c Yes, мы как раз получим то, что нужно

Вешаем триггер, проверяющим последнее значение, если последнее значение не будет равно 1 — триггер загорится

За общее количество нод отвечает переменная Expected votes

За количество активных нод отвечает переменная Nodes

Переменной, которая показывает зафейленые ноды в promox версии 5.2, нет. Поэтому будем вычитать из общего количества нод активные ноды. С помощью комманды paste делаем выражение и скармливаем его bc, которое уже делает вычитание

Так же вешаем простой тригер. Он сработает, если это значение больше нуля

Ещё надо проверять службы pve-manager и pve-cluster. Zabbix 3.4 ещё пока не умеет смотреть статус служб в systemd. Поэтому и здесь используем system.run

Уверен, что можно не вызывать два раза grep каждый раз. Если знаете как — прошу в комментарии.

How to run command on Zabbix agents?

I want to run a command on Zabbix agents:

• Some simple unix commands, to obtain our reporting data.
• When there is some processing required on the agent side.

There seem to be a variety approaches being talked about. So how to execute such commands on a Zabbix agent?

2 Answers 2

Run commands from the server directly from a new item.

First, set: EnableRemoteCommands=1 in the agent conf file (for all of your agents). To enable this feature.

Create a new item. A field on the «new item» page says ‘key’. Enter:

As the ‘key’ string. Where command is the command you want to be downloaded and run on the agent. Here is an example:

Perhaps you need to run something substantially more complex that is too long to fit in there? Then you will need to make a custom script. Put your custom scripts on a local webserver, or somewhere on the web.

Then you might set the item’s key to:

To fetch and download the missing script to the agent the first time it’s executed. However that is a rather crude hack. Not very elegant.

A better way is to go to «Administration» —> «Scripts» in the menu. From there, you can create a new script to use in an item which may be configured to run on any of your agents.

Make a special custom item to re-run your script periodically (like a cron job). The job of the special script item is to update the agent with a collection of your other needed custom scripts.

Of course you could just write all of your custom scripts directly into zabbix’s MYSQL database. And it is very tempting to do that. But be aware that then they’d be lost and vulnerable if your zabbix database ever gets fried or corrupted / lost. Zabbix databases always have a habit of growing large, unwieldy and out-of-control. So don’t do that. Storing them separately somewhere else and under version control (git or subversion).

Once that’s all sorted, we can finally go ahead and create further custom items to run your custom scripts. Again using:

as the item’s key just as before. Where ‘script’ is the command (plus any arguments), to execute your custom script locally on the agent.

Zabbix Documentation 5.2

Sidebar

Table of Contents

5 Zabbix agent (Windows)

Overview

This section lists parameters supported in a Zabbix agent (Windows) configuration file (zabbix_agent.conf). Note that:

Parameters

Parameter	Mandatory	Range	Default	Description
Alias	no	Sets an alias for an item key. It can be used to substitute long and complex item key with a smaller and simpler one. Multiple Alias parameters may be present. Multiple parameters with the same Alias key are allowed. Different Alias keys may reference the same item key. Aliases can be used in HostMetadataItem but not in HostnameItem or PerfCounter parameters.

1. Retrieving paging file usage in percents from the server.
Alias=pg_usage:perf_counter[\Paging File(_Total)\% Usage]
Now shorthand key pg_usage may be used to retrieve data.

2. Getting CPU load with default and custom parameters.
Alias=cpu.load:system.cpu.load
Alias=cpu.load[*]:system.cpu.load[*]
This allows use cpu.load key to get CPU utilization percentage with default parameters as well as use cpu.load[percpu,avg15] to get specific data about CPU load.

3. Running multiple low-level discovery rules processing the same discovery items.
Alias=vfs.fs.discovery[*]:vfs.fs.discovery
Now it is possible to set up several discovery rules using vfs.fs.discovery with different parameters for each rule, e.g., vfs.fs.discovery[foo], vfs.fs.discovery[bar], etc. AllowKey no Allow execution of those item keys that match a pattern. Key pattern is a wildcard expression that supports “*” character to match any number of any characters.
Multiple key matching rules may be defined in combination with DenyKey. The parameters are processed one by one according to their appearance order.
This parameter is supported since Zabbix 5.0.0.
See also: Restricting agent checks. BufferSend no 1-3600 5 Do not keep data longer than N seconds in buffer. BufferSize no 2-65535 100 Maximum number of values in a memory buffer. The agent will send
all collected data to Zabbix server or proxy if the buffer is full. DebugLevel no 0-5 3 Specifies debug level:
0 — basic information about starting and stopping of Zabbix processes
1 — critical information
2 — error information
3 — warnings
4 — for debugging (produces lots of information)
5 — extended debugging (produces even more information) DenyKey no Deny execution of those item keys that match a pattern. Key pattern is a wildcard expression that supports “*” character to match any number of any characters.
Multiple key matching rules may be defined in combination with AllowKey. The parameters are processed one by one according to their appearance order.
This parameter is supported since Zabbix 5.0.0.
See also: Restricting agent checks. EnableRemoteCommands no 0 Whether remote commands from Zabbix server are allowed. This parameter is deprecated, use AllowKey=system.run[*] or DenyKey=system.run[*] instead
It is internal alias for AllowKey/DenyKey parameters depending on value: 0 — DenyKey=system.run[*]
1 — AllowKey=system.run[*]. HostInterface no 0-255 characters Optional parameter that defines host interface.
Host interface is used at host autoregistration process.
An agent will issue an error and not start if the value is over the limit of 255 characters.
If not defined, value will be acquired from HostInterfaceItem.
Supported since Zabbix 4.4.0. HostInterfaceItem no Optional parameter that defines an item used for getting host interface.
Host interface is used at host autoregistration process.
During an autoregistration request an agent will log a warning message if the value returned by specified item is over limit of 255 characters.
This option is only used when HostInterface is not defined.
Supported since Zabbix 4.4.0. HostMetadata no 0-255 characters Optional parameter that defines host metadata. Host metadata is used only at host autoregistration process (active agent).
If not defined, the value will be acquired from HostMetadataItem.
An agent will issue an error and not start if the specified value is over the limit or a non-UTF-8 string.
This option is supported in version 2.2.0 and higher. HostMetadataItem no Optional parameter that defines a Zabbix agent item used for getting host metadata. This option is only used when HostMetadata is not defined.
Supports UserParameters, performance counters and aliases. Supports system.run[] regardless of EnableRemoteCommands value.
HostMetadataItem value is retrieved on each autoregistration attempt and is used only at host autoregistration process (active agent).
During an autoregistration request an agent will log a warning message if the value returned by the specified item is over the limit of 255 characters.
The value returned by the item must be a UTF-8 string otherwise it will be ignored.
This option is supported in version 2.2.0 and higher. Hostname no Set by HostnameItem List of comma-delimited unique, case-sensitive hostnames.
Required for active checks and must match hostnames as configured on the server. Value is acquired from HostnameItem if undefined.
Allowed characters: alphanumeric, ‘.’, ‘ ‘, ‘_’ and ‘-‘.
Maximum length: 128 characters per hostname, 2048 characters for the entire line. HostnameItem no system.hostname Optional parameter that defines a Zabbix agent item used for getting host name. This option is only used when Hostname is not defined.
Does not support UserParameters, performance counters or aliases, but does support system.run[] regardless of EnableRemoteCommands value.
The output length is limited to 512KB.
See also a more detailed description. Include no You may include individual files or all files in a directory in the configuration file.
To only include relevant files in the specified directory, the asterisk wildcard character is supported for pattern matching. For example: /absolute/path/to/config/files/*.conf . Pattern matching is supported since Zabbix 2.4.0.
See special notes about limitations. ListenIP no 0.0.0.0 List of comma-delimited IP addresses that the agent should listen on.
Multiple IP addresses are supported since Zabbix 1.8.3. ListenPort no 1024-32767 10050 Agent will listen on this port for connections from the server. LogFile yes, if LogType is set to file, otherwise
no C:\zabbix_agentd.log Name of the agent log file. LogFileSize no 0-1024 1 Maximum size of log file in MB .
0 — disable automatic log rotation.
Note: If the log file size limit is reached and file rotation fails, for whatever reason, the existing log file is truncated and started anew. LogType no file Log output type:
file — write log to file specified by LogFile parameter,
system — write log Windows Event Log,
console — write log to standard output.
This parameter is supported since Zabbix 3.0.0. LogRemoteCommands no 0 Enable logging of executed shell commands as warnings.
0 — disabled
1 — enabled MaxLinesPerSecond no 1-1000 20 Maximum number of new lines the agent will send per second to Zabbix server
or proxy processing ‘log’, ‘logrt’ and ‘eventlog’ active checks.
The provided value will be overridden by the parameter ‘maxlines’,
provided in ‘log’, ‘logrt’ or ‘eventlog’ item keys.
Note: Zabbix will process 10 times more new lines than set in MaxLinesPerSecond to seek the required string in log items. PerfCounter no Defines a new parameter

which is an average value for system performance counter

for the specified time period

(in seconds).
Syntax:

For example, if you wish to receive average number of processor interrupts per second for last minute, you can define a new parameter “interrupts” as the following:
PerfCounter = interrupts,“\Processor(0)\Interrupts/sec”,60
Please note double quotes around performance counter path.
The parameter name (interrupts) is to be used as the item key when creating an item.
Samples for calculating average value will be taken every second.
You may run “typeperf -qx” to get list of all performance counters available in Windows. PerfCounterEn no Defines a new parameter

which is an average value for system performance counter

Мониторим всё: расширение агентов Windows и Linux при помощи скриптов

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

Первый способ — это при помощи SNMP-запросов, с отправкой которых Zabbix замечательно справляется. Так можно вытащить и загрузку сетевых интерфейсов, и загрузку процессора, памяти. Поверх этого, производители сервера могут выдать нам по SNMP еще много информации о состоянии железа.

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

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

Нам оставили несколько стандартных интерфейсов для того, чтобы расширить возможности Заббикса по мониторингу серверов настолько, насколько позволит нам наша фантазия и наличие свободного времени на написание скриптов. Интерфейсы эти UserParameter и zabbix_sender. О первом и пойдет речь, а в качестве примеров будет показано как можно собирать состояние S.M.A.R.T жестких дисков и контролировать, когда кто-то удаляет или устанавливает новые программы на своей Windows-машине.

Немного матчасти

Если вы уже хоть раз настраивали Zabbix агент на сервере, то начать использовать UserParameter не составит труда. Чтобы добавить новый параметр нужно сделать несколько вещей:

• Добавить в конце конфигурационного файла zabbix_agentd.conf строчку вида

где:

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

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

Итак, ключ здесь system.test, а выполняем команду who | wc -l, которая возвращает нам количество открытых сессий в системе. Добавляем (или раскомментируем данную строчку если уже есть), идем дальше.

• В Веб-консоли Zabbix создать новый элемент данных с ключом, который мы использовали, если брать пример выше, то это system.test.

Для этого нажимаем «Создать элемент данных»

и затем выставляем ключ такой же, как указали в конфиг-файле, а тип Zabbix агент:

• Перезагрузить Zabbix агента, чтобы изменения в конфиг-файле вступили в силу

Наблюдаем результат в последних данных:

Мониторинг SMART через UserParameter

Пример выше имеет мало практического применения, учитывая, что уже итак существует стандартный ключ system.users.num, который делает ровно тоже самое.

Так что теперь рассмотрим пример, который уже больше будет походить на реалистичный.

Если нам интересно мониторить момент, когда пора планово менять жесткие диски, то есть два варианта:

1. Если диски за аппаратным RAID-контроллером, то, как правило, сами диски операционная система «не видит». Поэтому ищем способы как вытащить информацию о состоянии жестких дисков через утилиты или SNMP-сабагента, которые нам любезно предоставил(или не предоставил) производитель RAID-контроллера. Для каждой отдельной серии контроллеров свой путь до этой информации.
2. Если речь идет о просто рабочих станциях, серверах с софтовом RAID и т.д., то тогда к дискам есть доступ из операционной системы, и мы вольны использовать различные утилиты для чтения их статуса. В случае Zabbix нам подходит утилита smartctl, из пакета SMARTMONTOOLS.

В Debian установка SMARTMONTOOLS сводится к:

и утилита готова к использованию.

Для каждого диска, который есть в системе сначала проверим, что SMART включен:

если вдруг SMART поддерживается диском, но выключен, то активируем его:

Теперь мы можем проверять статус SMART командой:

Именно эту команду мы и запишем в наш zabbix_agentd.conf:

где uHDD.health — ключ.

Мониторинг SMART через Flexible UserParameter

Тут возникает резонный вопрос, как быть если дисков два. Легче всего решить эту проблему поможет способность UserParameter передавать параметры агенту, про которую мы еще не упоминали. Но делается все очень просто, сразу пример:

В веб-интерфейсе Zabbix в ключе мы будем подставлять параметры в квадратные скобки вместо *. Например, для одного элемента данных мы напишем sda, а для другого sdb. В команде этот параметр найдет отражение там, где стоит переменная $1.

Создадим для второго диска элемент данных:

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

Мониторинг SMART через Flexible UserParameter c Low-level Discovery

Все получилось. Но тут возникает резонный вопрос, как быть если дисков не два, а двадцать два. И тут нам пригодится замечательная возможность низкоуровнего обнаружения (LLD), про которую мы уже говорили.

Низкоуровневое обнаружение позволяет системе мониторинга обнаруживать какое количество однотипных элементов присутствует на узле сети и динамически по шаблону создавать необходимые элементы данных, триггеры и графики для этих элементов. «Из коробки» системе доступна возможность находить файловые системы, сетевые интерфейсы и SNMP OID’ы. Однако, и здесь разработчики оставили возможность дополнить стандартные возможности, нужно просто передать в систему информацию о том, какие элементы обнаружены в формате JSON. Этим и воспользуемся.

Создадим маленький скрипт на perl, smartctl-disks-discovery.pl. Он будет находить все диски в системе и выводить эту информацию в JSON, передавая также информацию, включен ли у диска SMART или нет, а также попытается сам включить SMART, если он выключен:

При запуске скрипт выдает:

Теперь, для того чтобы скрипт автоматически запускался Zabbix’ом, просто добавим еще один UserParameter в zabbix_agentd.conf:

Покончив с настройкой конфига, переходим в веб-интерфейс, где создаем новое правило обнаружения для smartctl:

Обратите внимание на ключ и на фильтр, (<#SMART_ENABLED>=1) благодаря последнему будут добавляться только те обнаруженные диски, которые поддерживают SMART. Теперь мы можем переписать два наших элемента данных для дисков sda и sdb в один прототип элементов данных, просто заменив имя диска на макрос <#DISKNAME>:

Последнее, перед тем, как Zabbix сможет запускать команды, которые мы прописали в zabbix_agentd.conf из-под root и мониторить SMART, нужно добавить разрешения для его пользователя запускать эту команду без ввода пароля, для этого добавим в /etc/sudoers строчку:

Готовый шаблон для мониторинга SMART с остальными элементами данных, триггерами прикладываю, так же как и настроенный под него конфиг.

Контроль за установкой новых программ на Windows

Zabbix агент, установленный на Windows, точно также может быть расширен через UserParameter, только команды будут уже другие. Хотя, например, smartctl — кроссплатформенная утилита, и точно также можно ее использовать для контроля за жесткими дисками в Windows.

Кратко рассмотрим еще другой пример. Задача получать уведомление каждый раз, когда пользователь самостоятельно удаляет или устанавливает программы.
Для этого будем использовать наш vbs-скрипт:

Для его интеграции с Zabbix добавим UserParameter в конфиг-файл:

Добавим элемент данных в шаблон для Windows:

Добавим триггер:

и действие, которое будет отправлять e-mail уведомление:

Весь процесс мониторинга выглядит так: каждый час запускается скрипт Zabbix агентом, который сравнивает два списка программ: текущий и предыдущий. Затем скрипт выписывает все изменения в отдельный файл. Если же изменений нет, то в файл пишется 0x0

Содержимое файла уходит на Zabbix сервер, где поднимается триггер в случае, если значение элемента данных uDiffProgramms отлично от 0x0. Затем отдельное действие отправляет по почте уведомление со списком того, что было установлено или удалено на данном компьютере:

В итоге

UserParameter — отличная и простая возможность расширить функционал системы самостоятельно. Стоит упомянуть и альтернативы: zabbix_sender, который, например, подойдет для тех случаев, когда нужно отправлять данные в Zabbix не по расписанию, (как это делает UserParameter), а по какому-то событию; и system.run[], который похож на UserParameter, но удобнее тем, что не нужно вносить изменения во все конфиги агентов, достаточно просто добавить этот элемент данных в шаблон. Более того, в следующем крупном релизе Zabbix 2.2 нас ожидает еще один новый способ расширить возможности агента- это подключаемые модули. Ждем с нетерпением!

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