Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
UniFi Controller 4.6.6 Огромный файл Server.log, UniFi Network
 
Привет! У нас возникли проблемы с файлом server.log: за 6 дней он растет до 220 ГБ, заполняет диск и вызывает сбой. Есть ли способ это как-то остановить? Мы работаем в среде Windows. Спасибо!
 
Кто-нибудь нашёл решение этой проблемы? Понимаю, что для устранения неполадок нужно много логов, но я намеренно хочу поднять уровень логирования, чтобы программа UniFi не писала так много данных на SD-карту в моём Raspberry Pi. Спасибо!

EDIT: Похоже, решение не сложное, просто найти его нелегко. Надеюсь, это поможет другим.

ИСПОЛЬЗУЙТЕ С ОСТОРОЖНОСТЬЮ, поскольку снижение уровня логирования не позволит UBNT эффективно устранять сетевые проблемы. См. ниже:

Мне кажется, что опция для уменьшения объёма логов задаётся в файле /var/lib/unifi/system.properties.

Просто добавьте строку:  
log.inform=xxx  
где xxx — это уровень логирования (например, debug, info, warn, error).

Также в этом файле можно задать и другие уровни логирования. (Этот пост помог мне выяснить эту информацию.)  
log.inform.ap=xxx  
log.inform.sta=xxxx  
log.guest=xxx  

Не утверждаю, что точно знаю, что именно делают эти параметры и как правильно ими пользоваться, но изменение log.inform на warn сильно уменьшило (почти прекратило) количество сообщений в syslog моего Raspberry Pi.

Было бы интересно узнать мнение разработчиков на этот счёт. Понимаю, что тогда ваша возможность помогать с настройкой сети практически отсутствует, но пока проблем нет, я лучше сохраню ресурс SD-карты своего RPi.
 
Это неправда. В более ранних версиях ПО контроллера Unifi у точек доступа наследуется имя пользователя и пароль администратора, а в версии 4, если зайти в Настройки, на главной странице (Site) внизу раздела Services есть секция Device Authentication, где можно задать имя пользователя и пароль для доступа. По моим данным, по умолчанию это совпадает с учётной записью администратора, чтобы сохранить совместимость с более старым ПО контроллера, но потом можно поменять их на любые другие, независимо от аккаунта администратора.

Пока у вас есть эти имя пользователя и пароль, вы можете подключиться по ssh к точке доступа и сбросить или заново подключить её без необходимости физически трогать устройство. Ещё удобнее: если вы настроите новый контроллер (по крайней мере в версии 4), любую точку доступа, которая помечена как «Managed by other», можно выбрать, нажать кнопку управления/подключения (точное название забыл) и ввести имя пользователя и пароль, после чего контроллер автоматически выполнит сброс и подключение.
 
Удача улыбнулась: только сегодня утром зашел на сервер, а файл логов растет на 10 МБ каждую секунду! Я выключил сервер, смог открыть логи и увидел это тысячами повторов:

[2016-02-26 07:57:28,527] <inform-175> WARN inform - inflater() remaining=0, needsInput()=true, needsDictionary=false
[2016-02-26 07:57:28,527] <inform-175> WARN inform - inflater() returns 0, remaining=0, needsInput()=true
… (и так далее, повторяется)

Буду очень признателен за любую помощь. Спасибо!
 
Операционная система — Raspbian Jessie на Raspberry Pi B+. Запустил контроллер, удалив родную библиотеку и заменив jar-файл snappy. Вот небольшой фрагмент моего лог-файла за 5 минут... учтите, что я очистил лог два дня назад, а он уже занимает 4 МБ. Ничего необычного, кроме информирования примерно каждые 10 секунд и ТОЛЬКО ОДНОЙ точки доступа.

[2016-02-25 10:55:11,891] <inform-196> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346337
[2016-02-25 10:55:26,163] <inform-197> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346351
[2016-02-25 10:55:38,434] <inform-198> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346363
[2016-02-25 10:55:51,690] <inform-1> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346376
[2016-02-25 10:56:03,957] <inform-199> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346389
[2016-02-25 10:56:15,221] <inform-3> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346400
[2016-02-25 10:56:29,587] <inform-200> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346414
[2016-02-25 10:56:40,857] <inform-5> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346426
[2016-02-25 10:56:55,130] <inform-2> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346440
[2016-02-25 10:57:05,394] <inform-4> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346450
[2016-02-25 10:57:19,653] <inform-8> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346464
[2016-02-25 10:57:33,927] <inform-6> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346479
[2016-02-25 10:57:48,196] <inform-9> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346493
[2016-02-25 10:58:02,535] <inform-10> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346507
[2016-02-25 10:58:12,790] <inform-12> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346518
[2016-02-25 10:58:26,054] <inform-11> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346531
[2016-02-25 10:58:38,317] <inform-16> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346543
[2016-02-25 10:58:48,622] <inform-7> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346553
[2016-02-25 10:59:01,894] <inform-13> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346567
[2016-02-25 10:59:16,165] <inform-17> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346581
[2016-02-25 10:59:28,436] <inform-15> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346593
[2016-02-25 10:59:40,697] <inform-19> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346605
[2016-02-25 10:59:50,968] <inform-14> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346616
[2016-02-25 11:00:04,229] <inform-21> INFO inform - от [dc:9f:db:72:66:5d](UpstairsAP, BZ2, 3.3.17.3991): состояние=CONNECTED, ext/stun_ip=10.0.0.2, dev_ip=10.0.0.2, uptime=346629
 
В итоге мы бросили попытки использовать контроллер для Windows. Установили его на Linux, и там он работает стабильно. Мы отправили копии, скриншоты файла server.log в службу поддержки, и нам сказали, что проблема на нашей стороне. Они отметили, что, похоже, один из удалённых объектов периодически теряет связь, из-за чего лог сервера заполняется сообщениями, но с тех пор как мы перешли на Linux-контроллер, это больше не проблема.
 
@dansonamission и @mbrotherson,  
Вы вообще видите кучу сообщений inform в файле server.log или что там по содержимому? Что-то явно не так.  

И ещё, @mbrotherson, какая у вас операционная система?  

Чтобы примерно ориентироваться, у моего контроллера время работы уже 219 дней, и у меня есть 3 файла server.log, каждый по 10.5 МБ, плюс один файл server.log на 2.1 МБ. Это при ~20 точках доступа. Да, не 200 пользователей, но разница в размере файла заметная.
 
Я вижу это на версии 4.8.12 с точкой доступа на последней прошивке. У меня одна точка доступа, и она оповещает примерно каждые 10 секунд. Лог-файл становится гигантским!
 
Кто-нибудь нашёл ответ на это? У нас такая же проблема на сервере Windows 2012 — диск на 500 ГБ заполняется всего за неделю работы. Пробовали на другом сервере 2012, та же история. Версия 4.7.58, APs 10, коммутаторы 200 пользователей.
 
@UBNT-Cody

Есть где-нибудь справочник, где можно посмотреть, что означают записи в файле server.log? Уже пару недель файл server.log растёт и занимает всё место на диске, а решения так и нет. Обращение в поддержку пока не помогло.
 
Наши логи достигают размера 250 ГБ или 500 ГБ, в зависимости от сервера, на котором они находятся, и полностью заполняют жесткий диск. Один день сервер работает нормально, а на следующий жесткий диск уже полный. Из-за такого большого размера мы не нашли ничего, что смогло бы их открыть!
Страницы: 1
Читают тему (гостей: 1)