Ad Widget

**Kos** · 08-07-2016, 08:46

Поддерживаю.

Проблема
Хочу сделать триггер, который бы срабатывал в случае, если значение элемента данных в течение пяти минут равно нулю.
Пробую так:

Code:

{Host:Item.last(,5m)}=0

или так:

Code:

{Host:Item.last(5m)}=0

но результат какой-то некорректный.

Причина
Функция last() возвращает только одно значение: либо последнее (по умолчанию, без операндов), либо N-ное с конца (либо со сдвигом по времени). Она не анализирует несколько значений.
При этом аргументом этой функции (если он вообще есть) может быть только порядковый номер, т.е. "#<число>" (с решёткой перед числом), а периоды (как в данном примере: "5m") в старых версиях игнорировались, в современных - вообще не поддерживаются.

Решение
Использовать более подходящую триггерную функцию: min(), max(), count(). Например, если в нормальной ситуации значение элемента данных всегда положительное, и оно становится равным нулю только в момент сбоя, то можно использовать такую конструкцию:

Code:

{Host:Item.max(5m)}=0

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

**Kos** · 22-01-2019, 13:38

Проблема
Есть скрипт, который возвращает данные в виде JSON: список неких параметров вместе с их значениями.
Хочу прикрутить автообнаружение (Low-Level Discovering - LLD) таким образом, чтобы автоматически генерировались нужные элементы данных (Items), имеющие указанные значения.
Например, такой вот JSON:

Code:

{"data":[
{"{#HDD_NAME}":"/dev/sda"},
{"{#HDD_NAME}":"/dev/sdb"},
{"{#HDD_PARAM}":"name"},{"{#HDD_PARAM}":"model"},{"{#HDD_PARAM}":"serial"},{"{#HDD_PARAM}":"type"},{"{#HDD_PARAM}":"size"},{"{#HDD_PARAM}":"health"},{"software":"smartmontools"}]}

Или вот такой:

Code:

{"data": [
{"{#KEY}": "t1.WRK_workstation.Server_test.cpu_percent", "{#VALUE}": 7.4},
{"{#KEY}": "t1.WRK_workstation.Server_test.cpu_percent_total", "{#VALUE}": 2.5}
{"{#KEY}": "t1.WRK_workstation.Server_test.memory_percent", "{#VALUE}": 5.9},
{"{#KEY}": "t1.WRK_workstation.Server_test.memory_rss", "{#VALUE}": 100}
]}

Причина
Непонимание того, что создание элементов данных и присвоение им значений - это разные процессы, которые выполняются на разных этапах обработки.
Генерация нужных элементов данных выполняется при отработке процедуры LLD, на этом этапе создаются, изменяются, помечаются к удалению либо удаляются сами элементы данных и связанные с ними объекты (триггеры, графики) на основе прототипов этих объектов.
Присвоение значений может выполняться только после того как нужные элементы данных уже созданы.
Следует иметь в виду, что на отработку процедуры LLD уходит некоторое время (около минуты): нельзя посылать JSON, нужный для LLD, и тут же после этого засылать данные - они будут проигнорированы сервером Zabbix, поскольку нужные элементы данных могут быть ещё не созданы.

Решение
Чётко разбить обработку данных на два этапа.
Первый этап - это LLD, во время которого создаются нужные элементы данных. Для этого этапа нужен JSON, в котором корневым элементом будет "data" (это, как раз, в обоих примерах есть), а затем - массив строк, содержащих пары "имя макроса" и "значение макроса", необходимых для создания нужных объектов из прототипов. Здесь не место текущим значениям самих элементов данных, здесь место значениям макросов, которые могут оказаться полезными для генерации самого элемента данных из прототипа - например, чтобы получить уникальный именно для него ключ, или подставить какую-то строку в имя либо описание (элемента данных, триггера, графика). Все эти макросы относительно статичны.

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

Code:

{"data":[
{"{#HDD_NAME}":"/dev/sda"},"{#HDD_MODEL}":"ST1000DM003-1ER162","{#HDD_SERIAL}":"Z4Y1S7B6","{#HDD_TYPE}":"3.5","{#HDD_SIZE}":"1,00 TB"},
{"{#HDD_NAME}":"/dev/sdb"},"{#HDD_MODEL}":"ST0500DM003-1ER162","{#HDD_SERIAL}":"S76V3N0S","{#HDD_TYPE}":"3.5","{#HDD_SIZE}":"500 GB"}
]}

Соответственно, прототип для единственного элемента данных мог бы выглядеть как-то так:
Name: Health for {#HDD_NAME} ({#HDD_SIZE}, {#HDD_MODEL}, S/N:{#HDD_SERIAL}, Type:{#HDD_TYPE})
Key: hdd.health[{#HDD_NAME}]
Type of information: Character
...и т.д. по вкусу.

Триггер - как-то так:
Name: Disk {#HDD_NAME} ({#HDD_SIZE}, {#HDD_MODEL}, S/N:{#HDD_SERIAL}, Type:{#HDD_TYPE}) failed!
Expression: {Hostname:hdd.health[{#HDD_NAME}].regexp("^PASSED$")}=0

Для второго примера можно было бы предложить сделать JSON, имеющий вид:

Code:

{"data":[
{"{#KEY}":"cpu_percent"},
{"{#KEY}":"cpu_percent_total"},
{"{#KEY}":"memory_percent"},
{"{#KEY}":"memory_rss"}
]}

И создавать элементы данных, используя примерно такой прототип:
Name: Parameter {#KEY}
Key: t1.WRK_workstation.Server_test[{#KEY}]
Type of information: Numeric (float)

Вторым этапом уже осуществляется засылка непосредственно данных в сгенерированные механизмом LLD элементы данных.
В первом примере у нас будут сгенерированы элементы данных с ключами вида hdd.health[/dev/sda] и hdd.health[/dev/sdb], которым нужно присвоить значения "PASSED".
Как организовать саму засылку значений - возможны варианты, самый простой - используя утилиту zabbix_sender с ключом "-i" для чтения из файла или из стандартного входа (stdin) сразу множества значений. Если очень хочется, то, начиная с версии 3.4, можно формировать один JSON и парсить его на стороне сервера - оформляя нужные элементы данных как завсисимые от одного текстового (принимающего этот JSON) и используя препроцессинг для парсинга; но этот вариант заведомо сложнее.

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

Code:

#/bin/bash
ZABBIX_SERVER=192.168.1.1
HOST=$(hostname -s)
[...тут обработка и получение данных...]
{
printf "- t1.WRK_workstation.Server_test[%s] %s\n" cpu_percent 7.4
printf "- t1.WRK_workstation.Server_test[%s] %s\n" cpu_percent_total 2.5
printf "- t1.WRK_workstation.Server_test[%s] %s\n" memory_percent 5.9
printf "- t1.WRK_workstation.Server_test[%s] %s\n" memory_rss 100
} | /usr/local/bin/zabbix_sender -z $ZABBIX_SERVER -s $HOST -i - >/dev/null

**Elis** · 24-01-2019, 11:15

моя проблема развёрнута подробнее тут

**Kos** · 05-02-2021, 17:31

FAQ: триггер с несколькими элементами данных

Проблема
У меня есть несколько взаимосвязанных параметров, которые собираются одновременно, и я хочу сравнивать их между собой.
Для простоты предположим, что хост называется MyHost, а параметры - X и Y.
Однако, когда я пишу условие триггера "в лоб", в виде:

Code:

{MyHost:X.last()} < {MyHost.Y.last()}

- то Zabbix реагирует неадекватно. Чаще всего это выглядит так: при получении новой пары значений триггер срабатывает, генерируя проблему, которая тут же закрывается (т.е. продолжительность проблемы - нулевая). Или наоборот, при наличии реальной проблемы бывает так, что триггер закрывается и тут же срабатывает снова.
Это создаёт много ненужного "шума".
Почему так происходит и как это исправить?

Причина
Если в триггерной формуле используются два (или более) элемента данных, то формула пересчитывается при получении нового значения каждым из этих элементов. И когда приходят новые значения для каждого из них, то только для нас это будет "одновременно", а для триггера - нет: сначала он пересчитается, когда будет получено значение одного элемента данных, а потом - другого. И при первом вычислении будет использовано новое значение только для одного элемента данных, для остальных - по-прежнему будет браться прежнее значение.

Предположим, что для приведённого примера приходит первая пара значений: X=10, Y=10. Всё нормально, условие не выполняется, триггер не срабатывает.
Через 5 минут приходит следующая пара значений: X=5, Y=5. С вероятностью 50% триггер сработает и тут же закроется - в зависимости от того, в каком порядке будут производиться вычисления.

Вполне возможный сценарий:

первым вычисляется значение X. Триггер пересчитывается: X=5 (новое значение), Y=10 (старое значение, новое ещё не обработано). (X<Y) даёт true, триггер срабатывает.
тут же вычисляется и новое значение Y. Триггер снова пересчитывается: X=5 (пришло мгновением раньше), Y=5 (пришло только что), (X<Y) даёт false, триггер тут же закрывается.

Самое интересное, что если придёт новая пара значений (X=15, Y=15), то абсолютно тот же сценарий может повториться снова в случае, если первым будет вычислен Y, а не X.

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

Я в таких случаях применяю следующий приём: при помощи функции count() добавляю в условия триггера проверку того, что оба последних значения - свежие. Понятие "свежесть" можно определить как возраст значения, явно меньший интервала опроса, но явно бОльший времени, необходимого на вычисления (с существенным запасом в обоих случаях). Скажем, для интервала опроса 5 минут можно считать "свежим" значения, которые поступили за последнюю минуту.

Тогда условие триггера получится более громоздким на вид, но зато правильно работающим:

Code:

{MyHost:X.count(1m)}>0 and {MyHost:Y.count(1m)}>0 and {MyHost:X.last()} < {MyHost.Y.last()}

Только надо иметь в виду, что такого рода триггеры надо всегда снабжать условием восстановления, в данном случае это будет:

Code:

{MyHost:X.count(1m)}>0 and {MyHost:Y.count(1m)}>0 and {MyHost:X.last()} >= {MyHost.Y.last()}

Потому что иначе при срабатывании триггера по делу он в дальнейшем будет издавать аналогичный "дребезг" при последующих проверках. Т.е. на каждой проверке будет закрываться (из-за того, что не выполняется одно из условий "данные свежие") и тут же открываться заново (при обработке второго из значений). Проверка "свежести" последних данных в выражении восстановления нужна по тем же соображениям: чтобы сравнивать именно значения из последней пары.

**Semiadmin** · 05-02-2021, 22:18

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

Code:

{MyHost:X.count(1m)}>0 and {MyHost:Y.count(1m)}>0 and {MyHost:X.last()} >= {MyHost.Y.last()}

Ad Widget

Часто задаваемые вопросы по Zabbix

Часто задаваемые вопросы по Zabbix

Comment

Comment

Comment

Comment

Comment