Разведка файловых систем (vfs.fs.discovery)

[sperr0w]

Добрый день!

Может быть, кто то уже сталкивался с подобной проблемой.

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

Цель: Мониторить разные файловые системы с разными интервалами, настроить разные уровни критичности для разных файловых систем.

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

Первое правило будет работать для разведки обычных ФС (/, /home, /var и т.д.)
Второе правило будет работать на разведку разделов Oracle (/xoracle, /xoradata).

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

ключ vfs.fs.discovery также не допускает использования [], что решило бы проблему. например, сделать два правила обнаружения:

1) Mounted filesystem discovery customer c ключем vfs.fs.discovery[customer]

2)Mounted filesystem discovery Oracle c ключем vfs.fs.discovery[oracle]

Пока что решением вижу только создание собственного правила разведки ФС.

Есть другие предложения?

[glebs.ivanovskis]

Решение слегка костыльное, но ещё одним способом обхода ограничения на уникальность ключей - это агентские Alias.

[sperr0w]

Да, уже нашел такой вариант.

Некоторая информация есть в zbxnext-1606 и zbxnext-3206.
Хотелось бы, конечно, чтобы разработчики добавили всем ключам разведки возможность задавать на вход аргументы (для того, чтобы делать две разведки с одним ключом).

[DRVTiny]

О! Мы тут с коллегами прямо сегодня это же и обсуждали в течение наверное получаса (а о этого я раздумывал над данным вопросом полдня как-то).

Так вот, корень всей беды заключается в том, что непонятно, а где, собственно, вести некую структуру данных, в которой указано, что для /mount0/point1 такие пороги срабатывания триггеров, а для /mount2/point33 - совершенно другие.

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

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

Но где изначально их прописывать? И как получить доступ к редактированию этих порогов?

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

[glebs.ivanovskis]

В 3.0 проблему можно решить контекстными макросами. В качестве порога использовать {$limit:"{#lld_macro}"}.

[DRVTiny]

В результате нашего совещания среди себя было решено делать так:

1) Прописывать пользовательские макросы вида
{$FS_PFREE_PATCH_VAR_LIB} = /var/lib/\12,10,6,3,1
{$FS_PFREE_PATCH_001} = /mydb/\15,12,8,5,3
И т.д.
Здесь "/\" - это такой хитрый разделитель, универсально удобный для Windows и Linux

2) Вместо штатного vfs.fs.discovery использовать скрипт, распространяемый ansible'м (perl+DBI+DBD::mysql), который будет:
2.1 Перебирать все пользовательские макросы на хосте с именами вида
FS_PFREE_PATCH_(.+)
2.2 Парсить значения макросов и выдавать в JSON-поток:
Либо кастомные {#FSLIM0}: 12, {#FSLIM1}:10, ... (и т.д.)
Либо, если для данной точки монтирования нет кастомных значений - дефолтные значения (Zabbix никогда не узнает, был это дефолт или нет).

Из сложностей: пользователские макросы с точки зрения БД в Zabbix реализованы неочевидным образом, так что, возможно, придётся пользоваться Zabbix API вместо прямых запросов в базу.

[DRVTiny]

В 3.0 проблему можно решить контекстными макросами. В качестве порога использовать {$limit:"{#lld_macro}"}.

То есть???

Можно прописать на хосте что-то вроде {$limit:/var/lib/zabbix}=10 ?

[Kos]

То есть???

Можно прописать на хосте что-то вроде {$limit:/var/lib/zabbix}=10 ?

Вы таки не поверите
Документация, пример 4.

[DRVTiny]

Да, уже изменил набор прототипов триггеров и убедился, что это работает. Спасибо за наводку!