Ubiquiti UniFi + zabbix

[sadman]

Взял последнюю версию с git

zabbix_get -s wifi.gipsr.ru -k "unifi.proxy[discovery,wlan]"
{"data":[]}

@wifi:~# /usr/local/lib/zabbix/unifi_miner.pl -a "discovery" -o "wlan" -s "" -k "" -i "" -n "" -c ""
{"data":[]}

Ну вот, ошибки нет. Правда и данных нет. Внутри скрипта всё правильно указали (пользователя, пароль, локейшн и пр)?

У меня-то данных не было, так как дома UniFi-сеть не растянута, а у вас должны быть.

Логи агента на машине с контроллером

   572:20160627:112104.575 active check "unifi.proxy[get,setting,,"[key=locale].timezone"]" is not supported: Special characters "\, ', ", `, *, ?, [, ], {, }, ~, $, !, &, ;, (, ), <, >, |, #, @, 0x0a" are not allowed in the parameters.

https://github.com/zbx-sadman/unifi_miner/wiki/UniFi-Miner-guide-in-Russian

Переход элемента данных в состояние UNSUPPORTED

Проявление: Использование составных ключей, содержащих фильтр вызывает переход элемента данных Zabbix в состояние UNSUPPORTED.

Возможная причина: Zabbix агент не может обработать ключ, содержащий в себе знаки '[', '&', ']' и пр.

Исправление: используйте директиву UnsafeUserParameters=1 в конфигурационном файле Zabbix-агента.

Там же, чуть выше параграф, который вам понадобится: "Не выполняется правило автообнаружения или в элементы данных перестает поступать новая информация"

[xhtml]

Да, написал логин с ошибкой. Спасибо. Данные в zabbix начали заливаться понаблюдаю! Пока не вижу Unifi Users

[xhtml]

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

P.S.
забыл проверить и включить Discovery в шаблоне users

[vanomel]

Поставил на данный момент последнюю версию скрипта, но до него дело не доходит, так как при

[I]cat /etc/redhat-release[/I]
CentOS Linux release 7.2.1511 (Core)
[I]zabbix_agentd -V[/I]
zabbix_agentd (daemon) (Zabbix) 3.0.3
Revision 60173 18 May 2016, compilation time: May 23 2016 09:02:47
[I]sudo -u zabbix zabbix_agentd -t unifi.proxy[get,health,default,"[subsystem=wlan].num_user",,0][/I]
unifi.proxy[get,health,default,[subsystem=wlan].num_user,,0] [B][m|ZBX_NOTSUPPORTED] [Invalid item key format.][/B]

В настройках

cat /etc/zabbix/zabbix_agentd.conf | grep Unsafe
UnsafeUserParameters=1

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

[sadman]

[I]sudo -u zabbix zabbix_agentd -t unifi.proxy[get,health,default,"[subsystem=wlan].num_user",,0][/I]
unifi.proxy[get,health,default,[subsystem=wlan].num_user,,0] [B][m|ZBX_NOTSUPPORTED] [Invalid item key format.][/B]

Это же shell issue:

$ zabbix_agentd -t "unifi.proxy[get,health,default,\"[subsystem=wlan].num_user\",,0]"
unifi.proxy[get,health,default,"[subsystem=wlan].num_user",,0] [s|0]

[vanomel]

sadman, понял, исправил.
В первый запрос всегда ответ пустой, если запросить тут же ещё раз, то показывает данные. Временной папкой указан /tmp. В чём может быть причина, как узнать?

[sadman]

sadman, понял, исправил.
В первый запрос всегда ответ пустой, если запросить тут же ещё раз, то показывает данные. Временной папкой указан /tmp. В чём может быть причина, как узнать?

Первый после какого события?

Всё, что тащится с контроллера, лежит в соотв. файлах. Например: /tmp/https___localhost_8443_api_s_default_stat_health
Внутри обычный JSON, его можно посмотреть любым online viewer-ом. В том случае, если ключ num_user в JSON объекте с subsystem=wlan ненулевой, а возвращается 0 - разбираться нужно. Если же значения эквивалентные - проблема на стороне контроллера или просто так совпадает: например, бегает единственный пользователь туда-сюда. В веб-интерфейс данные попадают раз в две минуты и он там как бы есть, а API отдает свежак, где он уже отключился и поэтому общее количество - 0.

Отлаживать лучше на Miner, там есть ключ -c 0 - запросы будут миновать кэш, т.е. всегда получите актуальные данные. Возможно, что они вам дадут пищу для размышлений.

[vanomel]

Удалил эти файлы временные, про которые ты пишешь, вроде бы стало лучше.
Видимо, файлы принадлежали какому-то другому пользователю и скрипт просто их не могу убить, но трогал? В следующий запуск видел, что данные "свежие" и выдавал их.
Но теперь это только догадки, потому как после удаления файлов они были пересозданы очередным запросом.
Почему-то выросла очередь в заббиксе до 2000 и потом упал агент и пока что не запускается. Разбираюсь.
Кстати, а зачем запросы сделаны через активную часть агента? В чем выгода?

[sadman]

Удалил эти файлы временные, про которые ты пишешь, вроде бы стало лучше.
Видимо, файлы принадлежали какому-то другому пользователю и скрипт просто их не могу убить, но трогал? В следующий запуск видел, что данные "свежие" и выдавал их.

https://github.com/zbx-sadman/unifi_...ide-in-Russian -> "Не выполняется правило автообнаружения или в элементы данных перестает поступать новая информация"

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

https://github.com/zbx-sadman/unifi_...ide-in-Russian-> Нарушена периодичность поступления данных в Zabbix, наблюдаются "дыры" в графиках, растет очередь Zabbix
+ нужно настроить ActiveServer на агенте.

Кстати, а зачем запросы сделаны через активную часть агента? В чем выгода?

UniFi Proxy обрабатывает запросы быстрее, поэтому все активные элементы данных успевают обрабатываться. Благодаря этому не нужно увеличивать кол-во пулеров на Zabbix Server-е до безумных значений.
Но перекрутить элементы данных в пассивный режим никто не мешает. Просто это сразу может прихлопнуть очередь Заббикс сервера, так как количество исследованных LLD элементов данных может быть приличным. А подобный затык наврядли обрадует оператора Zabbix, которому нужно будет править сразу конфиги, рестартовать сервер и т.п.

[vrosansys]

Ребят, как мониторить какие точки disconnected, пробовал изменить аналогичный итем:
unifi.proxy[get,uap,{#SITENAME},isolated,{#ID}] на
unifi.proxy[get,uap,{#SITENAME},disconnected,{#ID}]
- не работает....

[sadman]

Ребят, как мониторить какие точки disconnected, пробовал изменить аналогичный итем:
unifi.proxy[get,uap,{#SITENAME},isolated,{#ID}] на
unifi.proxy[get,uap,{#SITENAME},disconnected,{#ID}]
- не работает....

Удивительно... В шаблоне же есть и прототип и триггер на disconnected:

unifi.proxy[get,uap,{#SITENAME},state,{#ID}]

{Template UBNT UniFi Controller:unifi.proxy[get,uap,{#SITENAME},state,{#ID}].max(1m)}=0

state == 0 это AP disconnected

[vrosansys]

Удивительно... В шаблоне же есть и прототип и триггер на disconnected:

unifi.proxy[get,uap,{#sitename},state,{#id}]

{template ubnt unifi controller:unifi.proxy[get,uap,{#sitename},state,{#id}].max(1m)}=0

state == 0 это ap disconnected

Понял, есть такое, странно че-то он у меня выключен был)

[mishanya1389]

Привет, столкнулся со следующей проблеммой. Скрипт прекрасно отрабатывает если я опрашиваю софтовый контроллер на ubuntu 14.04. Вызов происходит командой ./unifi_miner.pl -u user -p pass -l https://IP:8443 -c 0. Но вот с контроллером на базе Unifi Cloud Key, получаю ошибку Comminication error: '500 Server closed connection without sending any data back'

[29465] 2016-10-10 20:40:35 [+] fetchData() started
[29465] 2016-10-10 20:40:35 [>] args: object type: 'site'
[29465] 2016-10-10 20:40:35 [.] Object path: 'https://192.168.1.30:8443/api/self/sites'
[29465] 2016-10-10 20:40:35 [.] No read/update cache because CacheMaxAge = 0
[29465] 2016-10-10 20:40:35 [+] fetchDataFromController() started
[29465] 2016-10-10 20:40:35 [>] args: object path: 'https://192.168.1.30:8443/api/self/sites'
[29465] 2016-10-10 20:40:42 [!] Comminication error: '500 Server closed connection without sending any data back'

[29465] 2016-10-10 20:40:42 [!] Can't fetch data from controller
[29465] 2016-10-10 20:40:42 [.] Going over all sites
[29465] 2016-10-10 20:40:42 [.] Make LLD JSON
[29465] 2016-10-10 20:40:42[*] Logout from UniFi controller

Никаких отличий в версиях контроллеров нет, Current Version 5.0.7
В чем может быть проблема?

[sadman]

Но вот с контроллером на базе Unifi Cloud Key, получаю ошибку Comminication error: '500 Server closed connection without sending any data back'
В чем может быть проблема?

CloudKey мне недоступен, но вот в этом длинющем треде пишут про сложные взаимоотношения перлового LWP и хождением на https через прокси. Хотя, по адресу вашего CloudKey сложно предположить, что для его достижения необходимо использование прокси-сервера, но всё же проверьте - не тут ли свинья порылась.

[mishanya1389]

cloudkey мне недоступен, но вот в этом длинющем треде пишут про сложные взаимоотношения перлового lwp и хождением на https через прокси. Хотя, по адресу вашего cloudkey сложно предположить, что для его достижения необходимо использование прокси-сервера, но всё же проверьте - не тут ли свинья порылась.

Спасибо за совет. Прокси не используется, единственное - машина, с которой осуществляется опрос, находится в другой подсети (на другом vlan). За наводку спасибо, попробую поковыряться