Изменить триггер

[GUID]

Не могу сообразить как изменить триггер, созданный автоматически на основе данных "обнаружения".
В стандартном шаблоне (zabbix 2.2) "Template OS Linux" есть правило обнаружения "Mounted filesystem discovery". На основании этого правила создаются экземпляры прототипа триггера "Free disk space is less than 20% on volume {#FSNAME}" для моего хоста (test.network.local).

Например, такой: "Free disk space is less than 20% on volume /home". Я хочу изменить его (триггер), так чтобы уведомление приходило при 40% свободного места.

Как это сделать?

[Goshan]

Думаю можно в родительском шаблоне заменить 20% на макрос, а в нужном узле просто переопределять этот макрос.

[GUID]

Думаю можно в родительском шаблоне заменить 20% на макрос, а в нужном узле просто переопределять этот макрос.

Спасибо за идею. Пошел изучать макросы.

[GUID]

Пришел к выводу, что это невозможно (

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

В общем - первое разочарование в zabbix (

[Jimson]

Вы, походу, выдумали выводы и сами себя разочаровали, и, боюсь, не в первый раз.
На ваш вопрос дали ответ, но вот что вы там думали на самом деле, когда писали вопрос, никому не ведомо, а следовательно не известно чем вас не удовлетворило предложенное решение. Если вам были нужны различные treshold для разных mountmount в пределах одного хоста, то надо было писать это в вопросе.

То что вы хотите сделать можно, но для этого придется использовать другое правило дискаверинга, которое кроме mountpoint и fstype будет возвращать нужный treshold, в таком случае вы сможете использовать в прототипе триггера условие вида key.func(params) > {#TRESHOLD}.
Такое правило можно реализовать через UserParameter агента, на каждом хосте свое, нужное вам, не сказать что это очень гибкое и легко сопровождаемое решение, но и желание ваше весьма странное.

[GUID]

Во-первых, СПАСИБО за Ваш ответ.
Вы, походу, выдумали выводы и сами себя разочаровали, и, боюсь, не в первый раз.

Если вам были нужны различные treshold для разных mountmount в пределах одного хоста, то надо было писать это в вопросе.

Согласен, сформулировано туманно. Но, я старался!

На самом деле, как мне кажется проблема в терминах. То, что в zabbix названо шаблоном - просто пример конфигурации, который по-хорошему нужно допиливать для каждого наблюдаемого объекта. Дело в том, что я ожидал увидеть что-то более "гибкое"/"динамичное", а при ближайшем рассмотрении увидел железобетонный конфиг.

желание ваше весьма странное.

Я хочу чтобы для одной ФС (из 12 на хосте) мне пришло уведомление о том, что свободного места на ней не 20%, а 10%. Вы считаете это странным желанием? Почему?!

Я нахожу намного более странным, что для этого я должен:

То что вы хотите сделать можно, но для этого придется использовать другое правило дискаверинга, которое кроме mountpoint и fstype будет возвращать нужный treshold, в таком случае вы сможете использовать в прототипе триггера условие вида key.func(params) > {#TRESHOLD}.

Если еще вспомнить, что не могут быть (в пределах хоста) правила дискаверинга с одинаковым ключом => мне нужно писать свой "ключ", только для того, чтобы отфильтровать 1 из 12 ФС.
К этому дискаверингу мне нужно будет написать новые элементы данных и триггеры.
При этом нельзя использовать нигде одинаковые ключи (!). А это значит, что придется корежить и настройки исходного шаблона.
И все это ради того, чтобы получить немного другое уведомление?! Мне кажется, что "в консерватории надо что-то подправить".

[Jimson]

Я хочу чтобы для одной ФС (из 12 на хосте) мне пришло уведомление о том, что свободного места на ней не 20%, а 10%. Вы считаете это странным желанием? Почему?!

Потому что 12 фс это скорее эксперементальный десктопный компьютер под линуксом, а не продакшен сервер. Потому что в ситуациях когда требуется мониторинг сети речь уже идет о минимум сотнях "хостов" и никто уже не будет заморачиваться на 15% vs 14%, оценка делается грубая - есть проблема или нет проблемы.

Если еще вспомнить, что не могут быть (в пределах хоста) правила дискаверинга с одинаковым ключом => мне нужно писать свой "ключ", только для того, чтобы отфильтровать 1 из 12 ФС.
К этому дискаверингу мне нужно будет написать новые элементы данных и триггеры.
При этом нельзя использовать нигде одинаковые ключи (!). А это значит, что придется корежить и настройки исходного шаблона.
И все это ради того, чтобы получить немного другое уведомление?! Мне кажется, что "в консерватории надо что-то подправить".

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

[GUID]

Потому что 12 фс это скорее эксперементальный десктопный компьютер под линуксом, а не продакшен сервер. Потому что в ситуациях когда требуется мониторинг сети речь уже идет о минимум сотнях "хостов" и никто уже не будет заморачиваться на 15% vs 14%, оценка делается грубая - есть проблема или нет проблемы.

Ок, я услышал Ваше мнение. Хотя с ним и не согласен не будем продолжать оффтоп.

Нет вы опять все выдумали. Или вы уже все решили и задержались только что бы нам здесь открыть глаза?

Что именно я выдумал?!
Я здесь, чтобы узнать то, чего не знаю. А вот Вы уже второй раз пытаетесь перейти на личности.
По существу: или я плохо объясняю или Вы не хотите меня понять.

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

За решение - спасибо.
Ну вот неправда ваша, неправда. Ваша фраза звучит, как будто нужно переписать одно условие (правило). Вы сами прекрасно понимаете, что в данном случае это не так. Данный подход интересен именно для =минимум сотни "хостов"= и для =грубой оценки=.

[Jimson]

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

Не условие надо переписать, а ПРАВИЛО. Есть несколько правил LLD которые zabbix предоставляет "из коробки", в том числе правило с ключем vfs.fs.discovery реализуемое агентом. Однако в документации подробно описано как реализуется LLD и как создавать свои правила дискаверинга. Вы прочитали документацию?
Коробочное правило vfs.fs.discovery возвращает два ключа для каждого элемента: {#FSNAME} и {#FSTYPE}, вам этого не достаточно, так как требуется для каждого элемента (FS) дополнительный параметр - treshold по которому будет срабатывать триггер, следовательно вы должны написать свое правило дискаверинга, скажем vfs.fs.descovery2, реализовать вы его можете либо через внешнюю проверку (скрипт выполняемый zabbix server/proxy), либо через пользовательский ключ zabbix agent (UserParameter), в вашем случае вероятнее всего больше подойдет именно UserParameter. Более того, при обоих способах реализации вы можете передать правилу дискаверинга дополнительные параметры, реализовать это можно через пользовательский макрос, например, vfs.fs.discovery2[{$MACRO_1}, {$MACRO_2}], при этом значения макросов по умолчанию определяются на уровне шаблона, а при необходимости переопределяются их на хосте.

Как вариант, вы определяете 2 или более "класса" FS и указываете какой порог у вас будет для каждого класса, скажем для класса 1 порог 40%, для класса 2 - 20%. Эти классы вы определяете пользовательскими макросам {$FSC1_FREE_TRESHOLD} и {$FSC1_FREE_TRESHOLD}, при этом значения 40 и 20 это их значения по умолчанию, на конкретном хосте макросы можно переопределить. Далее вы пишите ваше правило дискаверинга, которое, предположим для mountpoints / и /usr в качестве {#FSTRESHOLD} выбирает значение "первого класса", а для остальных "второй класс". Таким образом вы получили и разные пороги для разных классов FS и возможность менять классы относительно каждого хоста. Мало гибкости? Можете добавить еще параметров-макросов определяющих маску для mountpoints попадающих в тот или иной класс.

Так вы прочитали документацию или нет?

Триггер вы исправите в шаблоне и исправите "20" на {#FSTRESHOLD} или какое вы там выберете имя для дополнительного LLD макроса.

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

Я здесь, чтобы узнать то, чего не знаю. А вот Вы уже второй раз пытаетесь перейти на личности.

Серьезно?

[GUID]

Документацию читал (кстати именно ее наличие и качество сподвигло "окунуться" в zabbix). Однако, пропустил два момента, которые наверное решат мою проблему:

реализовать вы его можете либо через внешнюю проверку (скрипт выполняемый zabbix server/proxy), либо через пользовательский ключ zabbix agent (UserParameter)

Не рассматривал возможность "внешней проверки" (делал через UserParameter).

можете передать правилу дискаверинга дополнительные параметры, реализовать это можно через пользовательский макрос, например, vfs.fs.discovery2[{$MACRO_1}, {$MACRO_2}], при этом значения макросов по умолчанию определяются на уровне шаблона, а при необходимости переопределяются их на хосте.

В документации не увидел явного упоминания этого, а сам не догадался.

Спасибо, что не бросили и все расжевали.

[Jimson]

Не рассматривал возможность "внешней проверки" (делал через UserParameter).

Вам и нужен UserParameter, скрипт-правило который вы опеределите с его помощью будет исполнятся непосредственно на хосте, точнее этот скрипт будет вызывать агент работающий на хосте, а внешние проверки исполняются на ZabbixServer/ZabbixProxy.

[GUID]

Вам и нужен UserParameter, скрипт-правило который вы опеределите с его помощью будет исполнятся непосредственно на хосте, точнее этот скрипт будет вызывать агент работающий на хосте, а внешние проверки исполняются на ZabbixServer/ZabbixProxy.

Этот вариант у меня реализован для получения напряжения материнки (цепи, пределы - то что sensors выдает).
Как я уже писал - не догодавлся про параметры у него.
А вариант с "внешней проверкой" мне понравился тем, что нужно вносить минимум изменения на проверяемом хосте.
В общем - есть над чем подумать.

Еще раз - спасибо!

[vvlad]

А чем, собственно, не устроило решение с макросами? Макросы можно определять как на уровне шаблона, так и на уровне конкретного узла. И потом, без каких-бы то ни было проблем использовать в выражениях тригеров.

Сдается мне, что определить пользовательский макрос в узле несколько проще, чем наворачивать альтернативное правило lld...

[Jimson]

А чем, собственно, не устроило решение с макросами? Макросы можно определять как на уровне шаблона, так и на уровне конкретного узла.

Ну так автор вопроса захотел что бы в пределах одного хоста на /usr триггер срабатывал при 20%, а на /home при 40%

[GUID]

А чем, собственно, не устроило решение с макросами? Макросы можно определять как на уровне шаблона, так и на уровне конкретного узла. И потом, без каких-бы то ни было проблем использовать в выражениях тригеров.

Сдается мне, что определить пользовательский макрос в узле несколько проще, чем наворачивать альтернативное правило lld...

Стандарное lld по файловой системе даст мне список всех файловых систем. Например: "/", "/var", "/usr". Допустим, что мне нужно оповещение о том, что на "/", "/var" осталось 20% свободного места и при 10% для "/usr".
Макросы (если я правильно понимаю) помогут мне "играться" числами 20 и 10, а вот разбивать ФС на группы уже не получится.
Без "навороченного lld" мне придется удалять (деактивация не поможет) стандартный триггер и писать триггеры для каждой ФС. А их ~12 (lvm) и они уникальны для каждого хоста - у меня маленькая сетка и нет однотипных физических машин.