Ubiquiti UniFi + zabbix

[sadman]

А может кто-то подсказать как запустить аналогичный мониторинг на контроллере UniFi который работает под Windows

Я вижу два способа:
1) через ActiveState Perl;
2) Поставить все на машину с Zabbix Server, через -l в Miner и UniFiLocationв Proxy определить удаленный интерфейс контроллера.

Второй, думаю, проще.

[letusattack]

Прежде всего присоединяюсь к восторгу и благодарностям за проделанную работу!

Завел unifi_proxy.pl на машине с Zabbix Server, в конфиге подружил с удаленным контроллером на Windows-машине, все работает отлично.

Есть инетерес к Experimental-фичам:

Кроме того - появилась возможность делать LLD по произвольны вложенным JSON-ключам (только первого уровня), если они связаны с json-массивом или json-объектом. Для чего? Например - для дискаверинга портов UniFi Switch, которые интегрированны массивом в JSON-объект с типом usw. Ну или vap_table в UAP можно подискаверить, правда я не знаю зачем ))

В распоряжении конфигурация из одного сайта с 14 точками (UAP и UAP Pro), время от времени клиенты испытывают проблемы с доступом к сети. Есть желание получать через LLD метаданные устройств, подключенных к UAP - и использовать их для, например, ICMP проверок на loss/latency.

Если делать mca-dump непосредственно на точке, то данные о клиентах видны в sta_table. Можно ли получить данные о клиентах с помощью unifi_proxy? И создать LLD в темплейте, для ведения истории IP, подключений к точкам, потерь, задержек, сигнала... Тогда на выходе будет исчерпывающая информация для диагностики

[sadman]

Если делать mca-dump непосредственно на точке, то данные о клиентах видны в sta_table. Можно ли получить данные о клиентах с помощью unifi_proxy? И создать LLD в темплейте, для ведения истории IP, подключений к точкам, потерь, задержек, сигнала... Тогда на выходе будет исчерпывающая информация для диагностики

Не уверен, что информация будет исчерпывающая, но кое-что можно с контроллера получить.

LLD по устройствам, находящимся в онлайне, возможно получить с помощью дискаверинга объектов типа user, например - unifi.proxy[discovery, user]. Сейчас не могу проверить, но должны придти макросы {#ID}, {#NAME} (hostname устройства), {#IP} и еще какие-то. В ряде случаев hostname бывает пустым, поэтому туда помещается mac-адрес.

Затем, опираясь на {#ID}, можно сформировать прототипы с ключами, наподобии unifi.proxy[get,user,{#SITENAME},<metric>,{#ID}].
Полезными, полагаю, могут оказаться следующие метрики: ccq, noise, powersave_enabled, rssi,signal,tx_power,oui.

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

Не могу не предупредить о том, что заббикс читает пакеты размером не более, чем 65кб. Так что, если объектов будет много, то LLD-JSONу может обрезаться хвост и придется выкидывать лишние макросы из выдачи. Так же, если пользователи не только беспроводные (но и подключенные в проводные Ubnt-устройства), в запросах прототипов придется применять ключ-фильтр по [is_wired=0]. ...надо, наверное, подумать над фильтром в дискавере, чтобы лишние объекты не таскать в заббикс.

[letusattack]

LLD по устройствам, находящимся в онлайне, возможно получить с помощью дискаверинга объектов типа user, например - unifi.proxy[discovery, user]. Сейчас не могу проверить, но должны придти макросы {#ID}, {#NAME} (hostname устройства), {#IP} и еще какие-то. В ряде случаев hostname бывает пустым, поэтому туда помещается mac-адрес.

Затем, опираясь на {#ID}, можно сформировать прототипы с ключами, наподобии unifi.proxy[get,user,{#SITENAME},<metric>,{#ID}].
Полезными, полагаю, могут оказаться следующие метрики: ccq, noise, powersave_enabled, rssi,signal,tx_power,oui.

Спасибо, LLD настроить удалось, ICMP-проверки появились. Полная картина пока, действительно, не достигнута, поэтому зайду с другой стороны - а где можно узнать весь перечень возможных метрик? Ubiquiti свой UniFi JSON API не задокументировали, а mca-dump на точках показывает другие данные, нежели контроллер

P.S. После включения LLD Users Discovery ощутимо увеличилось количество Item'ов, что, видимо, усложнило работу unifi_proxy.pl

Т.е. теперь при проверках все чаще приходит пустота вместо JSON'а. При этом простые ICMP-проверки в тех же условиях работают четко. Что можно потюнить в unifi_proxy.pl? Попробовал увеличить количество процессов до 10, без особых изменений

[sadman]

Полная картина пока, действительно, не достигнута, поэтому зайду с другой стороны - а где можно узнать весь перечень возможных метрик? Ubiquiti свой UniFi JSON API не задокументировали

Они еще его и меняют часто
Смотреть метрики можно прямо в файлах кэша - там обычный JSON, который забирается с контроллера. Я, к примеру, просто в JsonViewer его вставляю и копаюсь. А так, из первых рук - это по API URI нужно брать JSON. Конкретно по пользователям в онлайне - это https://<unifi>:8443/api/s/<sitename>/stat/sta.

а mca-dump на точках показывает другие данные, нежели контроллер

Например? На точках они просто меняются быстрее, как я думаю. Или там какие-то иные метрики есть, которые отсутствуют на контроллере? В этом случае я помочь особо не могу - snmp на точках то появляется в прошивках, то выпиливается. Через ssh парсить stdout... ну, как-то так себе занятие. В целом я не стал бы рассматривать данные с контроллера, как отражающие состояние точки/эфира/пользователя в конкретный момент времени. Запаздываний отчетов в цепочке UAP-Zabbix предостаточно. Но как оценочные величины эти данные можно применять. Естественно, держа в уме, что всё, что ты видишь на графике - случилось пару минут назад.

Для тонкой настройки Ubnt выпускает специальный инструмент - он и чистоту эфира покажет и картинки нарисует в реалтайме.

P.S. После включения LLD Users Discovery ощутимо увеличилось количество Item'ов, что, видимо, усложнило работу unifi_proxy.pl

Исключать эту вероятность не буду, но могу сообщить, что испытывал релиз Proxy на 48-портовом коммутаторе, снимая по 10-15 метрик с порта + метрики с набора точек. В общей сложности - 1200-1500 айтемов с периодичностью в 30-60 сек. Дырок в графиках не было. На ранних версиях такое случалось. Без озвучивания нагрузочной статистики ничего внятного посоветовать не могу.

Из собственного опыта могу сказать, что большое количество часто опрашиваемых айтемов порождает огромные списки FIN_WAIT соединений. Тут варианты такие - или реже запросы делать или уменьшать таймаут закрытия соединения. Мне помогала такая конструкция: echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle. Помониторить можно через UserParameter=netstat8448,netstat -n | grep 8448 | wc -l в агенте.

Так же дырки могут быть из-за вылета айтема в NOTSUPPORTED. Это, порой, может быть вызвано тем, что в метрике содержится не цифровое значение, а null, которое конвертируется в '' и, как следствие, роняет элемент данных, который ждет цифровое значение. Зачем так делает Ubiquiti - не могу сказать. Можете задать NullReplacer=0 и понаблюдать - уйдут провалы или нет. ...на моих точках всегда отваливались одни и те же айтемы.

При этом простые ICMP-проверки в тех же условиях работают четко.

icmp* обрабатывается самим заббиксом, так что тут проблем ожидать не стоит...

Что можно потюнить в unifi_proxy.pl? Попробовал увеличить количество процессов до 10, без особых изменений

Я бы начал с того, что посмотрел, сколько времени в среднем выполняется запрос:

$ time zabbix_agentd -t unifi.proxy[sum,uap,,vap_table.[is_guest=1].is_guest]
unifi.proxy[sum,uap,,vap_table.[is_guest=1].is_guest] [s|0]
real    0m0.911s
user    0m0.000s
sys     0m0.012s

$ time zabbix_agentd -t unifi.proxy[sum,uap,,vap_table.[is_guest=1].is_guest]
unifi.proxy[sum,uap,,vap_table.[is_guest=1].is_guest] [s|0]
real    0m0.025s
user    0m0.008s
sys     0m0.004s

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

На своей виртуалке я достигал потоковой скорости в 1000req/sec при 3-х предзапущенных процессах, но она у меня на приличном сервере висит.

Вобщем, четыре потенциальные точки отказа:
1) Скорость выполнения запроса (отвал заббикс-агента по таймауту)
2) Большое количество айтемов, ведущее к большому кол-ву соединений.
3) Null-значения метрик
4) Неотловленный баг.

Нужно что-то исключать, собирать статистику.

[fermion]

sadman

Спасибо за ваш юнифи-прокси. Штука замечательная.

2 вопроса - у меня как и у товарища выше тоже наблюдаются дырки в графиках. Сервера что на забикс что на контролер вполне нормальные по производительности. Зависших соединений тоже нет. В какую сторону можно еще поглядеть?
И второе - вы упоминали какую то штуку от ubnt для тонкой настройки. Можно чуть подробнее что это софт/железка и как называется

[fermion]

Спасибо, lld настроить удалось, icmp-проверки появились. Полная картина пока, действительно, не достигнута, поэтому зайду с другой стороны - а где можно узнать весь перечень возможных метрик? Ubiquiti свой unifi json api не задокументировали, а mca-dump на точках показывает другие данные, нежели контроллер

P.s. После включения lld users discovery ощутимо увеличилось количество item'ов, что, видимо, усложнило работу unifi_proxy.pl

Т.е. теперь при проверках все чаще приходит пустота вместо json'а. При этом простые icmp-проверки в тех же условиях работают четко. Что можно потюнить в unifi_proxy.pl? Попробовал увеличить количество процессов до 10, без особых изменений

А можете поделиться подправленным шаблоном?

[sadman]

sadman

Спасибо за ваш юнифи-прокси. Штука замечательная.

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

Можем подебажить, конечно, если не исчезнете, как товарищ выше.

Вопрос N1: проблема наблюдается на каких-то определенных метриках? Если да, то каких?

Вопрос N2: проблема исчезает при уменьшении кол-ва метрик?

И второе - вы упоминали какую то штуку от ubnt для тонкой настройки. Можно чуть подробнее что это софт/железка и как называется

Скорее эта штука для анализа: http://www.wmd.ru/products/airview9.html

Вот такая выпускалась отдельным продуктом. Но, как я понял, данная функциональность включена в продукт https://www.ubnt.com/airmax/rocketm/

Ни того, ни другого у меня нет )

[fermion]

Можем подебажить, конечно, если не исчезнете, как товарищ выше.

Вопрос n1: проблема наблюдается на каких-то определенных метриках? Если да, то каких?

Вопрос n2: проблема исчезает при уменьшении кол-ва метрик?


Скорее эта штука для анализа: http://www.wmd.ru/products/airview9.html

Вот такая выпускалась отдельным продуктом. Но, как я понял, данная функциональность включена в продукт https://www.ubnt.com/airmax/rocketm/

Ни того, ни другого у меня нет )

1. Метрики выпадают рандомно. Базы для анализа мало - 2-3 дня всего как запущен прокси. Одну из метрик заменил активные проверки на простые, по виду вроде бы как нормально, погляжу до завтра
2. Количество метрик пока не уменьшали, на текущий момент собирается около 450 параметров

[sadman]

Т.е. теперь при проверках все чаще приходит пустота вместо JSON'а. При этом простые ICMP-проверки в тех же условиях работают четко.

Эта проблема предположительно отловлена - загружаемый модуль не всегда принимает отдаваемый сервером буфер целиком, если его длина более некоего неустановленного объема (JSON усекался то на 8кб, то на 16, то на 24...). Меньшие размеры пролетают без проблем, так что метрики не должны затрагиваться.

Как временное решение для Discovery rule можно применить обновленный unifi_proxy_get (стащить с гитхаба, перекомпилировать), подключенный, например, так:

UserParameter=unifi.discovery[*],/usr/local/bin/zabbix/unifi_proxy_get 127.0.0.1 8448 "discovery,$1,$2"

Так же можно воспользоваться nc:

UserParameter=unifi.discovery[*],echo "discovery,$1,$2" | nc 127.0.0.1 8448 -q 1

Ключ для правила: unifi.discovery[<object>,<sitename>]

Слежение за параметрами пользователей поставил, но они у меня неконтролируемо бегают туда-сюда, отключаются-подключаются, так что баги по дыркам в графиках ловить сложновато - пока ничего такого не замечаю.
Нагрузка такая: UniFi Users (880 Items), прототипы на RSSI, Noise, CCQ, PowerEnabled, Signal.

P.S. unifi.so подправлен и выложен на гитхаб, отрубаний JSON пока не наблюдается.

[fermion]

Эта проблема предположительно отловлена - загружаемый модуль не всегда принимает отдаваемый сервером буфер целиком, если его длина более некоего неустановленного объема (JSON усекался то на 8кб, то на 16, то на 24...). Меньшие размеры пролетают без проблем, так что метрики не должны затрагиваться.

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

Параметры тянутся агентом вот таким способом

UserParameter=unifi.proxy[*],echo "$1,$2,$3,$4,$5,$6" | nc 127.0.0.1 8448 -q 1

А с чем был связан выбор именно активных проверок?

Нагрузка такая: UniFi Users (880 Items), прототипы на RSSI, Noise, CCQ, PowerEnabled, Signal.

А можете поделиться получившимся шаблоном?

[sadman]

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

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

Параметры тянутся агентом вот таким способом

UserParameter=unifi.proxy[*],echo "$1,$2,$3,$4,$5,$6" | nc 127.0.0.1 8448 -q 1

Способ простой, но затратный по ресурсам - на каждый запрос форкается процесс. По графикам памяти/процессора нет драматических нагрузок?
Я сейчас тестирую на связке: загружаемый модуль на агенте (unifi.so) + unifi.discovery через unifi_proxy_get.

UniFi Users (2343 Items)
Clients connected to UAPs: 102
СPU idle time - 91.36 %
С nc было бы, наверное, idle = 60%.

А с чем был связан выбор именно активных проверок?

Общие рекомендации по разгрузке заббикс сервера - использовать активные проверки.

А можете поделиться получившимся шаблоном?

Через PM, так как он на коленке собран.

[fermion]

Способ простой, но затратный по ресурсам - на каждый запрос форкается процесс. По графикам памяти/процессора нет драматических нагрузок?
Я сейчас тестирую на связке: загружаемый модуль на агенте (unifi.so) + unifi.discovery через unifi_proxy_get.

UniFi Users (2343 Items)
Clients connected to UAPs: 102
СPU idle time - 91.36 %
С nc было бы, наверное, idle = 60%.

Нагрузок не вижу от слова совсем. Сейчас где-то около 450 итемов именно по юнифи собирается. На 13 точек доступа, но я шаблон несколько поправил для себя, некоторые данные мне не важны, некоторые довольно реже собираю.
СPU idle time - 97 %

Через PM, так как он на коленке собран.

Большое спасибо, буду к себе прикручивать.

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

[sadman]

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

Философский вопрос, конечно. Контроллер не контролирует интернет, как таковой. Он контролирует точки... Правда, он там какой-то Health рисует у себя в интерфейсе. Я делал для него отдельный объект, но там было небогато информации, а обработка получалась путанная. Так что пришлось его выпилить до лучших времен.

[fermion]

Философский вопрос, конечно. Контроллер не контролирует интернет, как таковой. Он контролирует точки... Правда, он там какой-то Health рисует у себя в интерфейсе. Я делал для него отдельный объект, но там было небогато информации, а обработка получалась путанная. Так что пришлось его выпилить до лучших времен.

Ну он мог бы какую нибудь более глубокую аналитику с точек снимать, мы сейчас у себя по всей видимости уперлись именно в производительность отдельной точки - в незагруженные часы все еще как то работает, в час пик вместо 2 мегабит на пользователя получаем рандомно от нуля до 0,5. Вифи открытый. Вот начали искать пути мониторинга, потому как в контроллере есть какая то настройка snmp, но данных оно нам не отдает. Ваша разработка более чем подошла

Глупый вопрос - куда копнуть, у меня забикс говорит на unifi.discovery[user] нот саппорт, хотя
echo "discovery,user" | nc 127.0.0.1 8448 -q 1
вполне себе работает, и еще в консоль на сервере с прокси сыпет вот такое
Use of uninitialized value in concatenation (.) or string at /usr/local/sbin/unifi_proxy.pl line 584.