LINUX.ORG.RU
ФорумAdmin

разясните низкоуровневое обнаружение в zabbix

 , ,


0

2

Есть значит у меня скрипт который формирует мне такой json для zabbix

{
   "data" : [
      {
         "{#DFCOMPLEXDIRTYDATA}" : 0,
         "{#BCDISK}" : "bcache0"
      }
   ]
}
1)Добавил в конфиг агента UserParameter=bcache.discovery. В шаблоне в правилах обнаружения создал ключ этого параметра, пробую получить данные вручную на сервере, получаю.
2)В правилах обнаружения добавляю элемент данных например добавляю ключ bcache_dirty[data,{#DFCOMPLEXDIRTYDATA}]. Далее как я понимаю мне надо создать ключ bcache_dirty в конфиге агента чтобы эти данные получить, а переменная {#DFCOMPLEXDIRTYDATA} используются для передачи данных скрипту. Работает так как я выше описал? Правильно наверно надо передавать {#BCDISK} и через скрипт получать данные DFCOMPLEXDIRTYDATA для конкретного диска.

Возможно из json'а выше получить элементы данных автоматом для zabbix вида

bcache0 dirty_data 0
на стороне zabbix шаблона где то описать например
{#BCDISK} dirty_data {#DFCOMPLEXDIRTYDATA}
без вызова дополнительного ключа bcache_dirty который еще раз будет эти данные запрашивать у агента? Хотел подсовывать zabbix серверу данные а он уже сам разбирал на имя и значения этих данных. Такое возможно?
Или всё же проще переделать скрипт который будет принимать нужные переменные dirty_data,requests-hits и возвращать значения?


Хотел подсовывать zabbix серверу данные а он уже сам разбирал на имя и значения этих данных. Такое возможно?

zabbix-sender в помощь.

Deleted ()

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

Попробуйте отредактировать сообщение и последовательно описать:

1) Какое множество объектов у вас сейчас есть и как это множество представлено в формате JSON (уже есть в сообщении, но всё в том же сумбурном виде);

2) Какие метрики о каждом из объектов, принадлежащих описанному в п.1 множеству Вы хотели бы получать;

3) С какой периодичностью и в каких объёмах Вам удобно получать метрики из п.2 и требует ли получение этих метрик специальных прав доступа?

Поясню:

Если нужно получать метрики периодически, т.е. событием отправки является срабатывание зацикленного таймера, то Вам в несложных случаях (о более сложных - см. ниже) подойдёт и будет удобен встроенный в zabbix-agent механизм выполнения внешних скриптов.

Если же события, приводящие в действие механизм отправки значений метрик, являются непериодическими (например, вовсе случайными), то zabbix-agent не подойдёт, но будет удобна отправка по протоколу zabbix-sender (утилитой zabbix_sender, perl-модулем Zabbix::Sender или же как угодно ещё).

Также учтите, что zabbix-agent будет запускать один и тот же скрипт для получения значения каждой «обнаруженной» метрики для каждого из объектов, принадлежащих описанному в п.1 множеству. А вот по протоколу zabbix-sender Вы можете отправить за раз все метрики для всех объектов. Т.е. накладные расходы сбора метрик для метода zabbix-sender и для метода zabbix-agent могут различаться на несколько порядков, что само по себе запросто способно влиять на точность мониторинга и, например, на работу других сервисов, запущенных на той же машине, на которой работает скрипт для получения и отправки значений метрик.

Права доступа также важны: помните о том, что zabbix-agent по умолчанию (и это умолчание не следует изменять) работает под своим пользователем с ограниченными правами доступа. Хватит ли этих прав для сбора метрик? Если нет, то можно пойти 2-мя путями: дать соотв. пользователю больше прав (требует отдельного длинного описания, о чём идёт речь) или же сразу отправлять метрики с правами учётной записи того пользователя, у которого этих прав достаточно. В последнем случае Вам снова нужен протокол zabbix-sender.

Итого: не поленитесь и опишите свою задачу последовательно и структурированно - тогда вполне возможно, что вместо того, чтобы ждать ответа на форуме, Вам достаточно будет сделать всего один или два простых поиска в Google ;)

DRVTiny ★★★★★ ()
Последнее исправление: DRVTiny (всего исправлений: 4)
Ответ на: комментарий от DRVTiny

Чем больше пытаешься написать и объяснить, тем больше становится не понятней. Шаблоны раньше вручную не создавал, поэтому не корректно скорей всего описал что хочу.
1)Есть скрипт который считывает информацию из /sys, вывод допустим такой:

['bcache0', 'df_complex-dirty_data', 0]
['bcache0', 'cache_ratio-five_minute', 100]
['bcache0', 'cache_ratio-hour', 100]
['bcache0', 'cache_ratio-day', 40.121580547112465]
['bcache0', 'cache_ratio-total', 40.15687775014349]
['bcache0', 'requests-bypass_hits', 0]
['bcache0', 'requests-bypass_misses', 0]
['bcache0', 'requests-hits', 0]
['bcache0', 'requests-miss_collisions', 0]
['bcache0', 'requests-misses', 0]
['bcache0', 'requests-readaheads', 0]
['bcache0', 'bytes-bypassed', 0]
С выводом пока не определился, так как не знаю как правильно и лучше сделать. Почему стал использовать discovery объект,так как не до конца понимая как работает discovery решил что благодаря ему мне не придется делать каждому параметру ключ. Сейчас уже понял что он нужен для получение устройств например bcache0, bcache1 и уже получая полный список устройств запрашивает данные каждого устройства.
Если правильно понимаю то через zabbix-agent у меня не получится получить весь вывод и добавить все элементы данных за один раз используя один ключ?
Имеет смысл используя zabbix-agent на хосте дополнительно использовать zabbix-sender или zabbix-api(perl-модулем Zabbix::Sender, в моём случае pyzabbix) для отправки данных выше?
По организации прав к данными и с каким правами работает агент проблем нет.

avb ()

Обычно делается так:

1) bcache.discovery : отдаёт массив хэшей «имя устройства,[описание,[...]]». Данные должны быть валидным жсоном, проверять через zabbix_get + json_pp (например).

2) bcache.data({#NAME}, «param») : отдаёт конкретный параметр для указанного устройства. Проверять опять же через zabbix_get. Данные - уже простой тип: int, float, string.

Создаётся дискавери, туда пишется ключ из первого пункта. Опционально настраивается фильтр имён в виде регекспа. Всё остальное пихается в «прототипы <...>», обязательно с указанием макроса для имени устройства. Создаются «элементы данных», затем вешаются триггеры и графики, если надо.

Когда дискавери сработает, оно для каждого девайса наплодит из этих прототипов реальные «элементы», «триггеры» и «графики».

anonymous ()
Ответ на: комментарий от anonymous

Вот так примерно это выглядит в конфиге агента:

UserParameter=net.if.list,/etc/zabbix/bin/discovery-ifaces.pl
UserParameter=net.if.attr[*],/etc/zabbix/bin/iface-attr.pl "$1" "$2"
anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.