История изменений
Исправление MariaRTI, (текущая версия) :
1)Вообще-то нет никакой разницы между получением списка всех сенсоров со значениями и получением одного сенсора, кроме того что второй вариант в десятки раз медленнее и требует больше запросов. Нет другого способа опроса сенсоров, кроме точно такого же запроса. Поэтому, экономичнее запросить список сенсоров и их значений, пусть даже с большой частотой (5 секунд), чем запрашивать сенсоры по отдельности.
Мне не понятно какие запросы должен делать LLD. Мне нужно просто вытащить из уже полученного JSON данные и поместить их в соотвествующие элементы данных, не делая повторных запросов. Желательно при этом НЕ сохранять исходный JSON, чтобы не замусоривать БД.
2)Способ получения единственно возможный, т.к. заббикс не имеет совместимого интерфейса с хостами. Данные получаются скриптом, скрипт лежит на сервере, либо в каталоге /etc/zabbix/sensors (для простых проверок или локального Zabbix-агента), либо в каталоге /usr/lib/zabbix/externalscripts для внешних проверок.
- локальный 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, :
1)Вообще-то нет никакой разницы между получением списка всех сенсоров со значениями и получением одного сенсора, кроме того что второй вариант в десятки раз медленнее и требует больше запросов. Нет другого способа опроса сенсоров, кроме точно такого же запроса. Поэтому, экономичнее запросить список сенсоров и их значений, пусть даже с большой частотой (5 секунд), чем запрашивать сенсоры по отдельности.
Мне не понятно какие запросы должен делать LLD. Мне нужно просто вытащить из уже полученного JSON данные и поместить их в соотвествующие элементы данных, не делая повторных запросов. Желательно при этом НЕ сохранять исходный JSON, чтобы не замусоривать БД.
2)Способ получения единственно возможный, т.к. заббикс не имеет совместимого интерфейса с хостами. Данные получаются скриптом, скрипт лежит на сервере, либо в каталоге /etc/zabbix/sensors (для простых проверок или локального Zabbix-агента), либо в каталоге /usr/lib/zabbix/externalscripts для внешних проверок.
- локальный 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, :
1)Вообще-то нет никакой разницы между получением списка всех сенсоров со значениями и получением одного сенсора, кроме того что второй вариант в десятки раз медленнее и требует больше запросов. Нет другого способа опроса сенсоров, кроме точно такого же запроса. Поэтому, экономичнее запросить список сенсоров и их значений, пусть даже с большой частотой (5 секунд), чем запрашивать сенсоры по отдельности.
Мне не понятно какие запросы должен делать LLD. Мне нужно просто вытащить из уже полученного JSON данные и поместить их в соотвествующие элементы данных, не делая повторных запросов. Желательно при этом НЕ сохранять исходный JSON, чтобы не замусоривать БД.
2)Способ получения единственно возможный, т.к. заббикс не имеет совместимого интерфейса с хостами. Данные получаются скриптом, скрипт лежит на сервере, либо в каталоге /etc/zabbix/sensors (для простых проверок или локального Zabbix-агента), либо в каталоге /usr/lib/zabbix/externalscripts для внешних проверок.
- локальный 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, :
1)Вообще-то нет никакой разницы между получением списка всех сенсоров со значениями и получением одного сенсора, кроме того что второй вариант в десятки раз медленнее и требует больше запросов. Нет другого способа опроса сенсоров, кроме точно такого же запроса. Поэтому, экономичнее запросить список сенсоров и их значений, пусть даже с большой частотой (5 секунд), чем запрашивать сенсоры по отдельности.
Мне не понятно какие запросы должен делать LLD. Мне нужно просто вытащить из уже полученного JSON данные и поместить их в соотвествующие элементы данных, не делая повторных запросов. Желательно при этом НЕ сохранять исходный JSON, чтобы не замусоривать БД.
2)Способ получения единственно возможный, т.к. заббикс не имеет совместимого интерфейса с хостами. Данные получаются скриптом, скрипт лежит на сервере, либо в каталоге /etc/zabbix/sensors (для простых проверок или локального Zabbix-агента), либо в каталоге /usr/lib/zabbix/externalscripts для внешних проверок.
- локальный Zabbix-агент (по адресу 127.0.0.1) работает и получает данные с хоста(точнее, не данные а пока JSON-текст), указанного в скрипте по умолчанию, но мне не удалось передать в скрипт IP адрес реальных узлов подсетки (192.168.0.*) или заставить работать Агента с этими хостами, т.к. на хостах нет агентов. Поэтому Zabbix-агент не подходит, остаются только простые и внешние проверки.
Исправление MariaRTI, :
1)Вообще-то нет никакой разницы между получением списка всех сенсоров со значениями и получением одного сенсора, кроме того что второй вариант в десятки раз медленнее и требует больше запросов. Нет другого способа опроса сенсоров, кроме точно такого же запроса. Поэтому, экономичнее запросить список сенсоров и их значений, пусть даже с большой частотой (5 секунд), чем запрашивать сенсоры по отдельности.
2)Способ получения единственно возможный, т.к. заббикс не имеет совместимого интерфейса с хостами. Данные получаются скриптом, скрипт лежит на сервере, либо в каталоге /etc/zabbix/sensors (для простых проверок или локального Zabbix-агента), либо в каталоге /usr/lib/zabbix/externalscripts для внешних проверок.
- локальный Zabbix-агент (по адресу 127.0.0.1) работает и получает данные с хоста(точнее, не данные а пока JSON-текст), указанного в скрипте по умолчанию, но мне не удалось передать в скрипт IP адрес реальных узлов подсетки (192.168.0.*) или заставить работать Агента с этими хостами, т.к. на хостах нет агентов. Поэтому Zabbix-агент не подходит, остаются только простые и внешние проверки.
Исходная версия MariaRTI, :
1)Вообще-то нет никакой разницы между получением списка всех сенсоров со значениями и получением одного сенсора, кроме того что второй вариант в десятки раз медленнее и требует больше запросов. Нет другого способа опроса сенсоров, кроме точно такого же запроса. Поэтому, экономичнее запросить список сенсоров и их значений, пусть даже с большой частотой (5 секунд), чем запрашивать сенсоры по отдельности.
2)Способ получения единственно возможный, т.к. заббикс не имеет совместимого интерфейса с хостами. Данные получаются скриптом, скрипт лежит на сервере, либо в каталоге /etc/zabbix/sensors (для простых проверок или локального Zabbix-агента), либо в каталоге /usr/lib/zabbix/externalscripts для внешних проверок.
- локальный Zabbix-агент (по адресу 127.0.0.1) работает и получает данные с хоста, указанного в скрипте по умолчанию, но мне не удалось передать в скрипт IP адрес реальных узлов подсетки (192.168.0.*) или заставить работать Агента с этими хостами, т.к. на хостах нет агентов. Поэтому Zabbix-агент не подходит, остаются только простые и внешние проверки.