LINUX.ORG.RU
ФорумAdmin

очередной велосипед Zabbix LLD - не едет

 , ,


0

1

Упражняюсь с Zabbix LLD. Что-то затык в понимании, что дальше делать. Попробовал по примерам, только запутался. Что делаю по шагам…

  1. Написал скрипт sensors.sh, который возвращает JSON, вроде как правильный для LLD. У скрипта есть параметр - ip или dns хоста, его бы тоже надо задавать динамически, но если он не задан, то берется отладочный(1 хост известен). Итак, возвращается список сенсоров с запрошенного хоста.
{
  "data": [
    {
      "{#SENSOR}": "Core_1_CPU1",
      "{#VALUE}": 42
    },
    {
      "{#SENSOR}": "Core_2_CPU1",
      "{#VALUE}": 41
    },
    {
      "{#SENSOR}": "Core_3_CPU1",
      "{#VALUE}": 41
    },
    {
      "{#SENSOR}": "Core_4_CPU1",
      "{#VALUE}": 42
    },
    {
      "{#SENSOR}": "Core_5_CPU1",
      "{#VALUE}": 43
    },
    {
      "{#SENSOR}": "Core_6_CPU1",
      "{#VALUE}": 41
    },
    {
      "{#SENSOR}": "DIMM_A1_CPU1",
      "{#VALUE}": 34
    },
    {
      "{#SENSOR}": "DTS_CPU1",
      "{#VALUE}": 43.094
    },
    {
      "{#SENSOR}": "Die_CPU1",
      "{#VALUE}": 43.063
    }
  ]
}
  1. поместил скрипт в директорию /usr/lib/zabbix/externalscripts на сервере заббикса.

  2. Создал новую группу шаблонов и новый шаблон в группе

  3. В созданном шаблоне создал правило обнаружения

Имя = Get_Sensors
Тип = внешняя проверка
Ключ = sensors.sh
  1. Сохранил, перезашел в шаблон и в правило обнаружения и протестировал - кнопка «тест». В диалоговом окне получил тот-же JSON в виде текстовой строки.

  2. Создал узел, указал ему ip, связал его с шаблоном, но чуда не случилось. Всё активировано, узел доступен, скрипт с него данные забирает, но данные через LLD не поступают в Zabbix.

Всё. В шаблоне, кроме правила обнаружения, больше ничего нет. JSON в тесте читается, значит правильный. Интервал обновления задан. Ключи в формате макросов заданы, значит должны автоматически подхватываться. Пробовал и без них, потом парсить предобработкой JSONPath и макросы создавать, только еще более запутался и удалил , и предобработку и макросы. Парсить вроде бы нечего, макросы уже заданы.

Не понятно, надо ли создавать UserParameter, да и зачем, ведь это совсем другой механизм, отличный от LLD. Там опять скрипт запускать надо, а он уже итак работает в шаблоне.

Не понятно, надо ли создавать прототип элемента данных и что он из себя представляет… там опять требуется запускать скрипт, который вроде как уже и так отработал. И нельзя создать зависимый элемент от правила обнаружения, чтобы его результат распарсить или повторно использовать, без новых запросов, можно только от основного элемента - опять масло масленое. Зачем тогда правило обнаружения нужно…

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

Вопрос.

  1. Как дальше автоматизировать создание элементов данных с именами из {#SENSOR} и значениями из {#VALUE} ? Пусть значения будут типа float. Как и где ему это «сказать»?

  2. Как передать в скрипт ip или dns узла? В правиле обнаружения, правильно?

Ключ = sensors.sh[{$HOST.IP}]

{$HOST.IP} - такая встроенная переменная существует?

Что дальше делать, чтобы данные получить?



Последнее исправление: MariaRTI (всего исправлений: 7)

какая версия заббикса? С 5.0 формат изменился и теперь это массив словарей

Не понятно, надо ли создавать UserParameter, да и зачем, ведь это совсем другой механизм, отличный от LLD.

Я использовал Userparameter. Механизм получения данных для lld тот же, хоть Dependent item используй, особенно с возможностью на сервере запускать скрипты на js. Мне UserParameter удеобнее, т.к. большая часть проверок активная

Не понятно, надо ли создавать прототип элемента данных и что он из себя представляет…

надо, lld отвечает только за создание элементов по прототипам (ну и удаление).
Что это? Обычный элемент данных, только с lld макросами вместо конкретных параметров, примеры есть

Как дальше автоматизировать создание элементов данных с именами из {#SENSOR} и значениями из {#VALUE} ?

создать прототипы

Как передать в скрипт ip или dns узла? В правиле обнаружения, правильно?

я бы все же переложил выполнение на агента, если есть возможность

{$HOST.IP} - такая встроенная переменная существует?

у заббикса хорошая документация

xgatron
()

и по поводу выхлопа — в нем не должно быть никаких {#VALUE}
Скрипт выдает серверу список словарей, где перечислены {#SENSOR} (и другие пераметры, если есть), которые он нашел.
Используя прототип и значения макросов lld создает нужные элементы данных, которые уже будут опрашивать сенсоры. Т.е. для lld интервал обновления не надо делать слишком частым, количество сенсоров обычно редко меняется.
Как будут собираться данные (агент, snmp, dependent item) тебе тоже надо решить.

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

1)Вообще-то нет никакой разницы между получением списка всех сенсоров со значениями и получением одного сенсора, кроме того что второй вариант в десятки раз медленнее и требует больше запросов. Нет другого способа опроса сенсоров, кроме точно такого же запроса. Поэтому, экономичнее запросить список сенсоров и их значений, пусть даже с большой частотой (5 секунд), чем запрашивать сенсоры по отдельности.

Мне не понятно какие запросы должен делать LLD. Мне нужно просто вытащить из уже полученного JSON данные и поместить их в соотвествующие элементы данных, не делая повторных запросов. Желательно при этом НЕ сохранять исходный JSON, чтобы не замусоривать БД.

2)Способ получения единственно возможный, т.к. заббикс не имеет совместимого интерфейса с хостами. Данные получаются скриптом, скрипт лежит на сервере, либо в каталоге /etc/zabbix/sensors (для простых проверок или локального Zabbix-агента), либо в каталоге /usr/lib/zabbix/externalscripts для внешних проверок.

  1. локальный Zabbix-агент (по адресу 127.0.0.1) работает и получает данные с хоста(точнее, не данные а пока JSON-текст), указанного в скрипте по умолчанию, но мне не удалось передать в скрипт IP адрес реальных узлов подсетки (192.168.0.*) или заставить работать Агента с этими хостами, т.к. на хостах нет агентов. Поэтому Zabbix-агент не подходит, остаются только простые и внешние проверки.

При тесте элемента данных типа «простой проверки», получаю в диалоговой форме правильный адрес, указанный для узла для которого делаю проверку элемента данных({HOST.IP} => 192.168.0.123), но тест возвращает ошибку «Unsupported item key.»

Ключ в элементе данных указан так: sensors[{HOST.IP}]

где sensors это UserParameter, определенный так: UserParameter=sensors[*],sensors.sh

MariaRTI
() автор топика
Последнее исправление: MariaRTI (всего исправлений: 5)
Ответ на: комментарий от xgatron

версия Zabbix 6.2

Я могу переделать выхлоп на такой

{
  "data": [
    {
      "Core_1_CPU1" : 42
    },
    {
      "Core_2_CPU1" : 41
    },
...
]
}

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

MariaRTI
() автор топика
Ответ на: комментарий от xgatron

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

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

Вызов из командной строки тоже не работает как ожидалось zabbix_agentd -t my_sensors[«192.168.0.220»]

возвращает дефолтный хост, а не тот, который был передан в качестве аргумента.

Проверил в скрипте. При вызове zabbix_agentd в скрипт передается только нулевой аргумент, т.е. имя самого скрипта.

Почему не передается аргумент в скобках []?

/etc/zabbix/zabbix_agentd.d/zabbix_agentd.userparams.conf

UserParameter=my_sensors[*],sensors.sh
MariaRTI
() автор топика
Последнее исправление: MariaRTI (всего исправлений: 3)
Ответ на: комментарий от xgatron

Я остановился на «внешней проверке», аргумент в скрипт теперь передается. Но всё это не главное. Главные вопросы остались нерешенными. LLD не работает. Как создать прототип элемента, не понятно. Каким должен быть ключ в прототипе, не понятно, каким должно быть имя элемента данных, не понятно. Изменил выхлоп на простой список кортежей, т.е. убрал уровень data и внешние фигурные скобки. В документации описаны только стандартные случаи, стандартные ключи. Как формируются ключи в прототипе в случае, когда ключем основного элемента является внешний скрипт с параметром (scripts.sh[{HOST.IP}]), вообще нигде в документации не описано. При попытке написать по аналогии, получаю ошибки синтаксиса ключа. «Миллион» вариантов перепробовал.

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

версия Zabbix 6.2

скрипт должен вернуть что-то типа

[
    {
      "{#SENSOR}": "Core_1_CPU1" 
    },
    {
      "{#SENDOR}": "Core_2_CPU1"
    },
...
]

Вот так работает… Пришлось явно указать аргумент $1

я так понял передается адрес хоста.
Если тип проверки выбран Zabbix или Zabbix (active), то это значит, что вызов my_sensors произойдет на стороне агента, т.е. уже на интересующем нас сервере.

Как создать прототип элемента, не понятно.

Если кратко: так же как и элемент данных, только по ссылке Create prototype (или как она там)

В документации описаны только стандартные случаи, стандартные ключи.

ключ объявленный через UserParameter не отличается от «стандартного» и, при правильном объявлении, работает также как и стандартный

Каким должен быть ключ в прототипе, не понятно, каким должно быть имя элемента данных, не понятно.

Допустим вы написали на баше скрипт, который получает один аргумент — название сенсора. Этот скрипт делает свою магию и возвращает текущее значение для сенсора.
Допустим положили его на сервер и объявили как UserParameter=my_sensor_temp…
Тогда имя прототипа будет например {#SENSOR} temperature
И его ключ my_sensor_temp['{#SENSOR}']

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

Спасибо за ответ. Но я написал ранее, что запросы отдельного сенсора по имени сопоставимы по нагрузке с запросом всех сенсоров с именами и значениями. Поскольку сенсоров много, то общая нагрузка на каждый узел и на сервер возрастет в десятки и сотни раз, а между тем, данные уже полностью получены и всё что нужно это правильно распарсить пакет с данными и разложить их по элементам данных. Более рациональным было бы сбросить результат запроса в файл и потом читать из файла, однако этот вариант немногим лучше и давно устарел. Можно было бы реализовать это через локальный zabbix-sender, но и этот вариант изобилует костылями, хотя в «сто раз» производительнее. Самым лучшим был бы вариант разбора полученного пакета с данными на лету, без сохранения объекта JSON в базе или файле и без костылей. Очень прискорбно, что всемогущий Zabbix не умеет делать такого простого отображения. Мне представляется, что для этого даже макросы не нужны и их наличие в этой технологии просто недоработка разработчиков Zabbix.

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

Но я написал ранее, что запросы отдельного сенсора по имени сопоставимы по нагрузке с запросом всех сенсоров с именами и значениями.

тогда вам нужно создать элемент данных, в который будет складываться json со всеми значениями
LLD, как и прототипы, надо будет конфигурировать с использованием Dependent item ссылаясь на упомянутый элемент данных.
Для настройки всего этого вам потребуется еще разобраться как работает jsonpath или скриптовать на js.
Но сложность возрастает и я бы советовал сначала сделать более простой вариант

Импортируйте шаблон для haproxy и попробуйте разобраться, как он работает

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

Спасибо за ответ. Но я сделал, как хотел. ZABBIX это умеет, беру свои слова обратно. Если коротко

  1. оставил свой формат JSON
  2. создал в шаблоне основной элемент данных, типа «внешняя проверка»; частота обновления 10 секунд; без сохранения или с минимальной историей
  3. создал в шаблоне правило обнаружения, типа «Зависимый элемент», выбрал созданный основной элемент. Остальные поля в правиле произвольные, в том числе и ключ, и не имеют принципиального значения. Без сохранения истории или минимально.
  4. создал прототип элемента, типа «вычисляемый элемент». В формуле указал {#VALUE}, в имени указал {#SENSOR} с любым текстом, ключ - произвольный но уникальный, нужен только как идентификатор элемента и не более, можно составить из ключа правила и [{#SENSOR}]. Частота обновления 10 секунд. Период сохранения истории максимальный.

Больше ничего не делал.

Всё работает.

Но мне подсказали другой способ, несколько посложнее, без внешнего bash-скрипта, через встроенный JavaScript.

Тему можно закрыть.

MariaRTI
() автор топика
Последнее исправление: MariaRTI (всего исправлений: 2)