Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1 2 След.
RSS
Создание лог-файлов, совместимых с syslog, из событий UniFi-Controller: Скрипт доступен, UniFi Network
 
Привет, *, мы написали скрипт на Python, который получает события, записанные внутри Unifi-Controller, и сохраняет их в лог-файл в формате, совместимом с syslog. Это помогает нам и работает для нас, возможно, будет полезно и вам... Кроме того, скрипт собирает статистику по использованию WLAN (и по трафику, и по количеству клиентов), счётчики tx и rx, и генерирует дополнительное событие в syslog с этой информацией. Формат записей syslog может показаться немного странным, но мы отправляем все наши данные syslog в «Splunk» для анализа, и этот формат отлично подходит для использования функции kv в Splunk. Хотите получить красивый линейный график количества WLAN-клиентов во времени в Splunk? Попробуйте «unifi statistics | timechart max(Stations_connected)»... Если вы используете Logstash, Kibana и Elasticsearch (ELK), скорее всего, сможете сделать что-то похожее.

Git-репозиторий доступен по адресу: https://gitlab.fokus.fraunhofer.de/vst/unifi-fokus, ZIP-файл для скачивания — https://gitlab.fokus.fraunhofer.de/vst/unifi-fokus/repository/archive.zip.

Как использовать: запускайте через crontab с примерно такой записью:
0,10,20,30,40,50 * * * * root /path-to/unifilog.py -c unifi -u a-user -p a-password -f /path-to/unifi.log -t /path-to/timestamp.cfg

Гарантий никаких, если что-то пойдёт не так и повредит вашу систему — извините... Удачи!
 
Не совсем понимаю, что ты имеешь в виду под «обязательными импортируемыми модулями». Разве модули не устанавливаются вместе с установкой Python? Если нет, то как тогда загрузить модуль datetime?
 
Привет! Я пытаюсь запустить скрипт unifilog.py на своем контроллере (версия 5.5.8) и получаю такую ошибку:  
Traceback (most recent call last):  
File "unifilog.py", line 130, in <module>  
 ap_name = "from-AP = %s, " % (get_ap_hostname(event['ap']))
File "unifilog.py", line 24, in get_ap_hostname  
 return ap['name']
KeyError: 'name'  

P.S. Проблема решилась сама, когда я задал точке доступа имя. Имя было MAC-адресом AP, но посмотрев код, я понял, что он так не работает, поэтому я присвоил AP псевдоним, и скрипт успешно запустился.
 
Внесено несколько небольших изменений и хаков для лучшей поддержки контроллера Unifi версии v5. Другие версии по-прежнему подходят для старых версий контроллера, так что выбирайте правильную версию из репозитория. Новое: создано больше статистики (отправленные/принятые байты WLAN, похожие на старые значения пропускной способности). Наслаждайтесь!
 
Сейчас мы перешли на контроллер версии 5. Скрипт по-прежнему работает с этой версией (но проблема с отсутствующими данными по значениям пропускной способности пока не решена). Впрочем, базовый функционал после обновления контроллера с версии 4 на 5 не пострадал...
 
Мне кажется, ситуация несколько отличается для контроллеров на Cloud Key и тех, что работают на других платформах. Для Cloud Key в идеале элементы интереса, сгенерированные контроллером, должны записываться в syslog, а затем весь syslog можно было бы отправлять на удалённый сервер тем же способом, что и для удалённого логирования других устройств Unifi. Так вы получаете не только события от контроллера, но и все остальные, которые генерирует всё остальное на устройстве.

Для контроллеров, работающих на других платформах, один из вариантов — просто отправлять события, сгенерированные контроллером, в syslog. Если администратор хочет, чтобы эти события захватывались удалённо, он может включить удалённое логирование для устройства и отправлять логи куда захочет.

В качестве альтернативы контроллер мог бы обрабатывать события, которые он сам генерирует, особым образом. Если включено удалённое логирование, то эти события отправлять напрямую на удалённый syslog-сервер, минуя локальную систему логирования. Это сохранило бы модель управления «в одном окне».

В любом случае появляется дополнительная сложность. Контроллер может управлять многими сайтами. Удалённое логирование включается отдельно для каждого. События, сгенерированные контроллером, обычно связаны с конкретным сайтом и, вероятно, должны отправляться в удалённый syslog для этого сайта. Другие события из syslog на Cloud Key с конкретным сайтом связать нельзя. Так куда же их отправлять?
 
События и оповещения контроллера, похоже, не отправляются через syslog, и в настоящее время, судя по всему, нет способа сделать это. Я согласен, что это было бы очень полезно. Контроллеру нужно было бы только отправлять через syslog, а нативная платформа уже бы решала, как и куда это делать. Это бы сработало на платформах, отличных от Windows, но на Windows может возникнуть проблема. Однако, возможно, существует прозрачная система ведения логов, которая использует syslog в качестве основы на системах с *nix и событийную систему Windows на самой Windows, хотя я этого не изучал.

Альтернативно контроллер мог бы включить собственную реализацию syslog, полностью независимую от платформы. В этом случае он мог бы использовать данные, предоставленные для управляемых устройств. Это, вероятно, самый прозрачный и последовательный вариант, к тому же есть Java-реализации syslog.
 
Вы говорите, что «не могут быть пересланы». Я не понимаю. Конечно, их *можно* переслать. Я могу поверить, что в данный момент их *не пересылают*. На мой взгляд, это упущение или недостаток. Ваш обходной путь – вариант, но, по моему мнению, вполне разумно ожидать, что эти сообщения будут включены в стандартный syslog с контроллера. (Контроллер сейчас вообще *генерирует* какие-либо syslog-сообщения?) А вот удалённое логирование syslog-сообщений с контроллера — это уже другой вопрос, и именно из-за того, что устройства Unifi включают полноценную ОС и явно привязаны к конкретному объекту, тогда как контроллер — это просто программа, работающая на разных ОС, и сервер, на котором она запущена, может находиться внутри сайта, а может и нет. Так что это, по крайней мере, немного другая ситуация. Тем не менее, я считаю, что должно быть возможно настроить удалённое логирование syslog с контроллера.
 
События контроллера по умолчанию нельзя пересылать как события syslog. Вот почему и нужен наш скрипт... Наш скрипт делает чуть больше, чем просто преобразует сообщения в формат syslog: он реорганизует сообщения для удобной обработки в Splunk (с использованием KV-хранилищ) и немного предварительно обрабатывает данные, например, добавляет имена клиентов вместо одних только MAC-адресов и подобные вещи...
 
Если я настрою удалённый логгирование на контроллере, то, похоже, устройства Unifi на площадке начинают отправлять логи на удалённый сервер. Если контроллер при этом тоже находится на площадке, то его логи тоже отправляются на удалённый лог? Думаю, что, скорее всего, нет, потому что контроллер, будь то Cloud Key или нет, не является Unifi *устройством*. Тем не менее, это кажется идеальным вариантом. Конечно, при условии, что события контроллера (Events и Alerts) действительно записываются в syslog. Не могу представить, почему этого не должно быть.
 
Без понятия... Ты уверен, что у тебя есть нужные модули для «import»? Похоже, что модуль datetime отсутствует...
 
Окей... спасибо! После исправления этого теперь получаю вот такую ошибку...  
Файл "./unifilog.py", строка 80, в <module>  
storedtimestamp = unixtimestamp_to_datetime(get_last_timestamp())  
Файл "./unifilog.py", строка 58, в unixtimestamp_to_datetime  
mytime = datetime.datetime.fromtimestamp(timestamp/1000)  
TypeError: неподдерживаемый тип операнда для /: 'NoneType' и 'int'  
Не уверен, какой операнд тут не тот.
 
Скрипту нужен ещё один файл, который находится в поддиректории под названием "unifi" и называется "controller.py". Похоже, что вы скачали не всю структуру каталогов, а только скрипт для логирования...
 
Пожалуйста, предоставьте текст для перевода.
 
Привет, рад познакомиться... Сейчас мы всё ещё используем контроллер версии v4 (точнее, 4.8.20). И да, скрипты по-прежнему в основном работают как задумано. За одним исключением: вычисления и выборки из базы данных по трафику сейчас не дают полезных значений, мы ещё не разбирались в этой проблеме. Исправим это, когда перейдём на контроллер версии v5. Планируем обновить контроллер до v5 в начале следующего года, после чего проверим, нужно ли будет обновлять скрипты. Не ожидаю больших изменений... Всего хорошего и с наступающим Рождеством, Стефан
 
Как инженер поддержки Splunk и энтузиаст Unifi, я бы хотел помочь настроить это для обработки в Splunk. Я заметил на GitHub, что проект не обновлялся уже 11 месяцев. Он по-прежнему хорошо работает с контроллером версии 5?
 
В нашем случае контроллер Unifi работает на сервере под управлением Windows. Однако REST-API-скрипт запускается на Linux-машине для сбора логов, и именно эта машина получает логи контроллера Unifi. Не все данные, полученные через REST-API, доступны в логах (например, статистика вроде общего числа клиентов). Эти данные на самом деле генерируются скриптом (который читает разные базы данных), а затем записываются в лог-файл на машине для сбора в формате, совместимом с syslog. Скрипт также сводит данные воедино, чтобы их было удобнее искать с помощью Splunk...
 
Я вижу сообщения в server.log и вижу сообщения в интерфейсе контроллера, и мне кажется, что сообщения в UI — это подмножество сообщений из логфайла. Логфайл генерируется с помощью log4j... Можно ли использовать log4j Syslog appender (http://help.papertrailapp.com/kb/configuration/java-log4j-logging/#setup-syslogappender-for-papertrail), чтобы писать напрямую в syslog вместо запросов через API к контроллеру? Смотрите также: https://community.ui.com/questions/90c38a29-87ee-4c71-8218-68e160e4179f https://community.ui.com/questions/e043a004-75f5-4db2-bafb-daca9c9d4693#answer/a18ba694-02c1-4280-9645-396ea239b333 (Контроллер UniFi всё ещё использует log4j 1.2...)
 
Спасибо, теперь понятно.
 
Вы можете получать сообщения syslog с точек доступа напрямую через UDP, но сам контроллер тоже пишет множество сообщений (которые можно просмотреть в веб-интерфейсе контроллера). Скрипты считывают json-описания сообщений контроллера (через REST-API), и на их основе создаются совместимые с syslog сообщения (в основном в формате ключ-значение для удобного поиска в Splunk или ELK). Подключение происходит к экземпляру контроллера, а не к отдельным точкам доступа.
Страницы: 1 2 След.
Читают тему (гостей: 1)