Json

[dobry_kot]

Всем привет. Появился такой вопрос, используем для снятия данных с хардов одновременно 2 программы. smartctl и OpenHardwareMonitorReport.
Смогли соединить так, что бы был массив типа:

/dev/sda; ata; Model; S/N; раздел1; free size;
/dev/sda; ata; Model; S/N; раздел2; free size;
/dev/sdb; ata; Model; S/N; раздел1; free size;
/dev/sdb; ata; Model; S/N; раздел2; free size;

Вопрос:
Как сделать так, что бы Zabbix смог проглотить и расфасовать массив внутри массива и имеет ли в принципе zabbix такой функционал?

[sadman]

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

Или заранее создаете последние и закидываете значения через zabbix_sender или используете LLD.

[d00m178]

или используете LLD.

а как его использовать если данные, который нужно "закинуть" в zabbix - находятся в JSON формате и доступны только по http URL?

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

[sadman]

а как его использовать если данные, который нужно "закинуть" в zabbix - находятся в JSON формате и доступны только по http URL?

Писать собственный парсер, который по запросу (через UserParameter или в TCP-сеансе) будет искать нужный JSON-ключ, брать у него значение и возвращать Zabbix-серверу. Я такую штуку делал для UniFi Controller - он тоже в API только через JSON, что по HTTP отдается, работает.

[d00m178]

Писать собственный парсер, который по запросу (через UserParameter или в TCP-сеансе) будет искать нужный JSON-ключ, брать у него значение и возвращать Zabbix-серверу.

вот тут я и буксую..

не могу понять как какойто внешний скрипт, который умеет парсить JSON скачаный по вебу можно подключить к item-у в zabbixe...
точнее как его в zabbix подключить то..

вот есть скрипт - запускаем, он в stdout выводит пару key:value
но как их скормить в zabbix? и причем тут LLD тогда? мне вот подсказывают, что LLD нужен только на этапе создания хоста в zabbix, но для мониторинга уже надо будет опять внешний скрипт. совсем запутался - вы ведь говорите, что это два разные варианта:

через zabbix_sender или используете LLD

[sadman]

Zabbix действует так: отправляет агенту имя метрики, получает значение.

Агент должен передать имя метрики скрипту, который получит ваши пары JSON-ключ:значение, найдет соответствующий имени метрики JSON-ключ, получит значение ключа, которое выведет в stdout. Это значение будет выловлено агентом заббикса и отправлено серверу.
Т.е. примерно так

UserParameter = myservice[*], /usr/local/bin/json-cruncher.pl "$1"
myservice[memory] -> /usr/local/bin/json-cruncher.pl "memory"


Однако, как вы понимаете, чтобы агенту отправить имя метрики, нужно ее знать. Если их мало, то можете создать руками элементы данных с соответствующими ключами, например myservice[memory], myservice[disk], myservice[speed].

В том же случае, когда необходимо мониторить много экземпляров/сервисов с одинаковыми метриками, создание руками айтемов превращается в боль. Для того, чтобы боль ушла - применяют LLD. Это второй скрипт, который проведет поиск всех доступных экземпляров в области его видимости и вернет специальным образом сформированный LLD-JSON, который содержит строки с уникальными идентификаторами каждого экземпляра (сервиса, раздела HDD, чего-то еще). После этого первый скрипт нужно модифицировать так, чтобы он умел не только по метрике вернуть значение JSON-ключа, но и сделал это для определенного экземпляра. Тогда всё будет примерно так:
UserParameter = myservice[*], /usr/local/bin/json-cruncher.pl "$1" "$2"
myservice[id20386,memory] -> /usr/local/bin/json-cruncher.pl "id20386" "memory"


Естественно, что эти два скрипта можно объединить в один, можно дергать его не через UserParameter, а через Zabbix Loadable module и найти еще сто тыщ способов доставить конкретное число в Zabbix DB.

В случае с zabbix_sender всё выглядит примерно так же, но json-cruncher.pl может просто сформировать файл, который будет скормлен zabbix_sender-у или поток данных, который будет передаваться через конвейер той же утилите. При этом забота о периодическом запуске скрипта ляжет на cron хоста, где находятся наблюдаемые объекты.

Однако, применение zabbix_sender точно так же требует создания на Zabbix-server соответствующих элементов данных с правильными ключами и типом Trapper вместо Zabbix Agent. Так что тот же LLD тут тоже необходим.

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