Ленивые записки

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

• Получить ссылку
• Facebook
• Твиттер
• Pinterest
• Электронная почта
• Другие приложения

Иногда требуется передавать собственные параметры на Zabbix сервер с помощью агента. Для этого в конфиге агента предусмотрен параметр UserParameter= , . Всё что нужно — это прописать его, перезапустить агента и создать элемент данных на сервере.

Обратившись к официальной документации Zabbix об этой возможности можно прочитать подробнее. Покажу на примере из той же документации:
Как видно из примера этот ключ всегда будет возвращать значение 1.

Пропиываем в конфигурации агента (zabbix_agentd.conf), перезапускаем агент. Можно запустить агента с ключом -p, который выведет на экран все параметры и их состояния на момент запуска агента. Там можно найти и свой, вновь определенный.

С помощью утилиты zabbix_get можно с сервера запросить параметр и убедиться что всё передается корректно: zabbix_get -s 10.10.10.10 -k ping

Далее добавляем к узлу элемент данных, типа Zabbix Agent, прописываем имя получаемого параметра, в нашем случае «ping» выбираем тип данных и прочие свойства элемента данных.

После его добавление элемент данных будет в состоянии «Not supported by zabbix agent». По умолчанию обновление неподдерживаемых элементов данных установлено в 600 секунд, этот параметр можно изменить: администрирование -> общие параметры -> прочие -> обновлять неподдерживаемые элементы данных (секунды). После обновления элемент данных начнёт собирать значения.

Мониторим всё: расширение агентов 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.

Zabbix Agent User Parameters

Learn how to extend Zabbix agent functionality by adding your own checks that can be both – dynamic and static.

Contents

Introduction

The topic for today is user parameters in the Zabbix agent. Earlier we talked about how you can install the Zabbix server and Zabbix proxy. I have the same training virtual machine with CentOS 7, and SELinux and firewall are disabled because we are learning Zabbix.

So what is the user parameter and why should we use it in the context of the Zabbix agent?

Zabbix agent

You know that the Zabbix agent is a utility that is widely used to monitor local resources and applications in any Zabbix infrastructure. This is definitely the most popular monitoring tool simply because the Zabbix agent is a super lightweight software that consumes just a couple of MBs and does not burden the CPU.

We have RPM packages for the most popular Linux versions. It is also possible to easily install the Zabbix agent on any Windows machine.

What are the benefits of the Zabbix agent? The Zabbix agent has a lot of metrics that you can monitor from the box. This means that it is not required to invent something new. You don’t need to write custom scripts or figure out complex monitoring scenarios. All you need to do is spend two minutes of your time to install the Zabbix agent on the machine, then open the documentation.

In Configuration > Items > Item type > Zabbix agent, you will find all available monitoring items supported from the box that you can use without any additional configuration. Simply go to the front end, create a host for your Zabbix agent, create a new item, and make the one that you need with the help of documentation. You can monitor service state or free disk space, network interfaces, memory, and many other things from the box, or do some discovery.

User parameters

What is a user parameter? Sometimes you might need to monitor something on a Windows or Linux machine that is not very common, not the disk space or CPU load, but a specific application. And you know that you can get the desired metric easily with just a couple of commands in the CLI.

However, you cannot find the item in the documentation for that, and you need to somehow teach Zabbix to execute that small command or a bit more complex script and received value from the script or the command line as a value inside Zabbix.

Today we’ll actually talk about how to do that. We will also discuss the possible differences between what I would call a static user parameter and a dynamic user parameter.

In the CLI, we need to open the configuration file of the Zabbix agent that by default is stored here:

Search for UserParameter to create your own small or a larger item to collect some kind of specific data.

Creating user parameters

You can run a command in the CLI which returns information about the service, e.g. the copyright, revision, and also version — 4.0.5:

A similar script can be run for the agent:

Let’s try to create a user parameter to collect the major version of our binary, which is 4.0.5.

First, edit Zabbix agent configuration file:

Creating a new item

We can leave the default value as it is and write a new line. I’ll write ‘UserParameter=’ which is the key that you’ll have to use in the front end. It must be unique and must follow the key syntax that you can check in our official documentation. And you need to remember it.

When I create an item inside the front end with ‘Zabbix agent’ as Type and ‘static’ as Key, I will receive the same value as when executing this command.

Let’s make another user parameter. In the next line, I add ‘UserParameter’ with ‘dynamic’ as key, and then in the brackets, which we use in the front end to specify different parameters, we need to write *, then a comma and then the command that will be executed. The last part will depend on what we specify in the front end as item parameters. I will specify ‘$1’ which means the first parameter from my front end from the item configuration.

You can save the new parameters with ‘:wq’.

I’ll run the third parameter to show you that you need to be careful with user parameters:

So we have three user parameters. Remember that each time you make some changes to any Zabbix configuration file, Zabbix agent, a server or a proxy, etc., you always need to restart the process on the server itself, but only the process to which you’ve changed the configuration file. In our case, I use the following command:

Now we can actually go to the front end. In Configuration > Hosts I’ve added a new host which is called UserParameters with my localhost agent.

Adding new items

Let’s create new items in Configuration > Hosts > UserParameters > Items > Create Item.

We select ‘Agent version’ for Name, ‘Zabbix agent’ for Type, and ‘static’ for Key.

In the Type of information, you can specify ‘Numeric (float)’ because we will be extracting the actual 4.0 value from all that bunch of text. But since it is Zabbix 4.0, Zabbix will show it simply as ‘4’. Instead, we might be using ‘Text’. And I’ll set the Update interval of 5 seconds to make it work quicker.

Creating a new user parameter

As can be seen in the CLI, the command ‘zabbix_server −V’ displays a lot of information, while we need to extract only the information about the version. This means that we need to add a preprocessing step in Configuration > Hosts > UserParameters > Items > Preprocessing > Preprocessing steps.

In my case, I’ll select ‘Regular expression’ for Name. To select the Parameter value, let’s check what lines we have in the CLI. We have ‘zabbix_server (Zabbix) 4.0.5’.

So in the pattern, it will be ‘zabbix_.* ([0–9].[0–9])’, where * means there can be anything and [0–9] interval means a place for any number. And we want to display the first one as follows:

Click Add to add this new item. Now you can check the information about the version by clicking the Agent version in Configuration > Hosts > Items.

This is the static item, while we have also created a dynamic one. To check the user parameters, you can run:

So let us Clone the one that we’ve just created and change some values.

Here we will have ‘Server version’ for Name, the same ‘Zabbix agent’ for Type, but the Key is ‘dynamic’.

In the parameter, we specify the binary name that we want to use instead of ‘$1’:

As for the preprocessing, the Name and Parameter remain the same, as well as the first capturing rule.

Let’s add another item by clicking Clone. This one should have ‘Timeout example’ for Name and ‘Zabbix agent’ for Type. And we type ‘timeout’ for Key from our last user parameter:

Timeout user parameter

Preprocessing won’t actually matter here, so we won’t make any changes in the Preprocessing tab. I’ll just add this item with the same 5-second Update interval.

Then I’ll run the following command in the CLI simply to reload all the changes that we’ve just made in the front end and save us some time.

Note. If anything does not work properly, for example, an item is not supported because the regular expression does not match, you can run these commands to check for mistakes:

Make corrections in the vim file, then run ‘:wq’ to save changes, if any, and restart the agent:

Results

In Monitoring > Latest data, I can check the results by specifying the hostname, ticking off Show details and clicking Apply.

UserParameter latest data

We have three items. We have Agent version and Server version with the Last value of ‘4.0’. Remember that we are actually getting multiple lines of random text, but the preprocessing function helps us to filter for the version number.

The last item Timeout example is not supported. The error message reads “Timeout while executing a shell script”. Remember that in all the Zabbix processes there is a timeout parameter. It means that any custom user parameter that you create and that will be running for more than the timeout parameter will not be supported in the Zabbix front end.

So when you are creating your own custom checks, you need to make sure that those are running fast enough. If you have some custom scripts that are running for a longer period, you need to figure out another way to execute it and gather a metric as a value.

In the next videos we’ll definitely talk about it, and about other options to use UNIX scripts together with the Zabbix sender utility to monitor user-specific applications.

Conclusion

This was a quick insight into the Zabbix agent and Zabbix user parameters. If you have any additional questions about this topic or maybe some wishes for the next topics, you are welcome to comment and make suggestions.