Измените параметр "syslog.level" на точках доступа с 7 ("debug") на что-то менее подробное.

Измените параметр "syslog.level" на точках доступа с 7 ("debug") на что-то менее подробное., UniFi Network

eddy34

Guest

27.05.2020 11:49:00

Недавно один из точек доступа сошел с ума и начал забивать наш удалённый syslog-сервер буквально десятками строк в секунду:

May 25 12:38:36 red-ap [kern.warning] U7SHD,fcecdaxxxxxx,v4.3.13.11253: kernel: [1376235.726386] FIXME:osif_forward_mgmt_to_app: Event length more than expected..dropping
May 25 12:38:36 red-ap [kern.warning] U7SHD,fcecdaxxxxxx,v4.3.13.11253: kernel: [1376235.726401] FIXME:osif_forward_mgmt_to_app: Event length more than expected..dropping
May 25 12:38:36 red-ap [kern.warning] U7SHD,fcecdaxxxxxx,v4.3.13.11253: kernel: [1376235.726413] FIXME:osif_forward_mgmt_to_app: Event length more than expected..dropping
May 25 12:38:36 red-ap [kern.warning] U7SHD,fcecdaxxxxxx,v4.3.13.11253: kernel: [1376235.793189] FIXME:osif_forward_mgmt_to_app: Event length more than expected..dropping
May 25 12:38:36 red-ap [kern.warning] U7SHD,fcecdaxxxxxx,v4.3.13.11253: kernel: [1376235.793208] FIXME:osif_forward_mgmt_to_app: Event length more than expected..dropping
May 25 12:38:36 red-ap [kern.warning] U7SHD,fcecdaxxxxxx,v4.3.13.11253: kernel: [1376235.793220] FIXME:osif_forward_mgmt_to_app: Event length more than expected..dropping
May 25 12:38:36 red-ap [kern.warning] U7SHD,fcecdaxxxxxx,v4.3.13.11253: kernel: [1376235.857408] FIXME:osif_forward_mgmt_to_app: Event length more than expected..dropping
May 25 12:38:36 red-ap [kern.warning] U7SHD,fcecdaxxxxxx,v4.3.13.11253: kernel: [1376235.857424] FIXME:osif_forward_mgmt_to_app: Event length more than expected..dropping
May 25 12:38:36 red-ap [kern.warning] U7SHD,fcecdaxxxxxx,v4.3.13.11253: kernel: [1376235.857437] FIXME:osif_forward_mgmt_to_app: Event length more than expected..dropping

Я залогинился на наш syslog-сервер и быстро сделал grep:
log-server:/var/log> grep 'FIXME:osif_forward_mgmt_to_app' wireless.1 wireless | wc -l
5164376

Это сообщение было залогировано более 5 миллионов раз менее чем за сутки!! (Почему оно вообще начало появляться — тема для отдельного разговора...)

Для ясности: в веб-интерфейсе UniFi Controller, в настройках на вкладке Site, в разделе Remote Logging я включил «Enable remote Syslog server», но НЕ включал «Enable debug logging».

Когда я залезаю в точку доступа и смотрю файл /tmp/running.cfg, там вижу:
syslog.status=enabled
syslog.level=7
syslog.remote.status=enabled

Проблема в том, что уровень 7 — это «debug» (как показано в этой таблице).

Если же я включаю «Enable debug logging», то syslog.level меняется на 8(!):
syslog.status=enabled
syslog.level=8
syslog.remote.status=enabled

Не ошибка ли это смещения на единицу, где при выключенном debug должен быть уровень 6, а при включенном — 7?

Кроме того, было бы круто, если бы можно было напрямую задавать syslog.level (например, через выпадающий список с 0–7). Мне не хочется, чтобы на наш syslog-сервер с точек доступа шли debug или информационные сообщения, только ошибки (или более серьёзные).

Сейчас у меня Controller версии 5.12.72, и для справки: в настройках Maintenance, в разделе Services, все выпадающие списки Log Level стоят на Normal.

Буду признателен за советы, как уменьшить syslog.level на точках доступа до значения ниже 7 (Debug). Спасибо!

waterside

Guest

11.07.2020 22:50:00

250 тысяч серверов, ещё 450 тысяч настольных и портативных компьютеров обслуживают сотни миллионов пользователей по всему миру. Плюс сюда же добавьте сетевую инфраструктуру и множество других устройств, подключённых к сети. Большинство из них требовали ведения логов уровня info с разных компонентов. На некоторых устройствах метрики логов оценивались в сообщениях в секунду и отправлялись на централизованные сборщики.

Мой опыт относится к времени, когда Интернета ещё не было в том виде, в каком мы его знаем сейчас, задолго до появления современных rsyslog и syslog-ng. Даже тогда, при удалённом логировании было вполне обычным делом пересылать все сообщения уровня info или notice на центральный сервер и там их обрабатывать. И это в те времена, когда 10 Мбит/с на полудуплексе считалось быстрым соединением. Обычно на самом исходном устройстве не решают, нужно ли отправлять что-то удалённо, особенно потому что такой подход плохо масштабируется и становится неуправляемым в больших средах. К тому же международные регулирующие органы могли бы предъявить претензии, если логи не пересылались должным образом. Особенно это касалось устройств инфраструктуры.

Я видел самый разный подход к удалённому логированию: от высококонфигурируемого до совершенно негибкого. Первый вариант обычно основывался на полноценных Linux-дистрибутивах с полнофункциональными syslogd.

Более детальные конфигурации syslog исторически регулировали локальное логирование, которое часто было более ограниченным, чем удалённое (именно поэтому изначально и появились такие настройки в оригинальном syslog). Часто первое желание — ограничить удалённое логирование, но это не считается хорошей практикой. Лучше принимать все сообщения, при необходимости делать локальную обработку (здесь и нужна детальная конфигурация) и пересылать сообщения как есть, позволяя удалённому серверу самому решать, что с ними делать.

Также стоит помнить, что UAP-устройства имеют ограниченные процессор и память, и на них не запускается стандартный полнофункциональный syslogd, скорее всего поэтому они почти не настраиваются. Вместо этого они используют очень лёгкий logd с фиксированным кольцевым буфером и отдельную утилиту logread для пересылки сообщений на удалённый сервер. Насколько я понимаю, logread практически не настраивается по уровню или facility, кроме режима отладки. Версия logread, кажется, была улучшена для поддержки шифрования, которое используется при логировании на контроллер, поэтому предполагаю, что любые возможности настройки потребовали бы кастомной доработки этой утилиты.

louis_s

Guest

11.07.2020 20:57:00

Рад сравнить размеры сетей. Последняя у меня была на 15 000 серверов с 10 миллионами пользователей. Самая большая — это оригинальный интернет-магистраль (NSFnet, после DARPAnet). Но это не суть. Протоколы были разработаны так, чтобы их можно было настраивать с обеих сторон, а во мне как в архитекторе говорит здравый смысл: не стоит отправлять информацию, если у получателя нет для неё цели. Опять же, просто разные точки зрения. Спасибо за подсказку с запросом на функцию. Обязательно посмотрю. /lou

waterside

Guest

11.07.2020 20:45:00

Syslog имеет уровни для управления на стороне коллектора и/или форвардера. Любой сервис, который пишет в syslog, всегда будет создавать запись — разница только в том, что происходит с этим сообщением в зависимости от facility и приоритета. Любая конфигурация syslog касается локального коллектора/форвардера. Сообщения генерирует именно AP, а не контроллер. В случае с AP они будут пересылать логи на ваш заданный syslog-коллектор либо на уровне INFO, либо на уровне DEBUG. Как я уже отметил, раньше думал, что можно использовать уровень NOTICE, но сейчас этого, похоже, нет.

Ваш syslog-коллектор, в свою очередь, может просто отбрасывать *.INFO, записывать их в отдельный файл или делать почти что угодно. Лично я в нескольких случаях использую Graylog, знаю и тех, кто применяет полный стек ELK. Оба варианта легко настроить и запустить за пару минут, даже используя полностью поддерживаемые docker-образы (хотя это не единственный вариант). Наличие сообщений уровня INFO действительно полезно в таких ситуациях.

Мне приходилось работать с syslog в очень крупных компаниях с более чем миллионом устройств, отправляющих логи на коллекторы. Там вполне обычно требовать уровень INFO, по крайней мере для аутентификации (возможно, это немного в сторону темы).

Знаю много устройств, которые вообще не настраиваются — либо они пишут в удалённый syslog, либо нет. Опять же, просто настраивайте ваш syslog-коллектор так, как вам удобно.

На самом деле управлять нежелательными сообщениями на уровне syslog-коллектора — очень просто. Полностью отключать удалённый syslog — это как бить молотком по кнопке, но такая возможность тоже есть.

Было бы здорово иметь возможность логировать только на уровне NOTICE? Возможно, да, но это вряд ли настолько важный момент, чтобы долго на нём зацикливаться.

Если вы считаете, что это действительно важно, попробуйте поискать Feature Request, и если он есть — проголосуйте за него. Если нет — создайте новый запрос с подробным описанием и обоснованием, чтобы другие тоже поняли и могли поддержать его голосом.

louis_s

Guest

11.07.2020 20:30:00

Разные мнения, @waterside. По моему мнению, нет смысла создавать сообщения на контроллере, если их всё равно проигнорирует приёмник syslog... это просто лишний трафик и нагрузка на обработку. Именно поэтому у syslog изначально есть разные уровни логирования. Отправитель должен быть настраиваемым в соответствии со стандартным диапазоном уровней syslog.

waterside

Guest

11.07.2020 20:21:00

Если честно, сообщения в исходном посте имеют уровень WARN. Если ты не хочешь даже такой уровень, то, наверное, вообще не стоит заморачиваться с удалённым syslog. Я вообще не считаю логи неуправляемыми, даже на уровне debug. За пределами домашнего использования часто встречаются сборщики syslog с фильтрацией и другими штуками для удобного управления логами. Если не хочешь, чтобы сообщения уровня INFO «засоряли» логи, то сборщик syslog просто перенаправит их в отдельный файл или даже просто отбросит. Это легко сделать даже с помощью стандартных rsyslog или syslog-ng, которые есть практически во всех дистрибутивах Linux и BSD, и именно так обычно с этим и работают. Аналогично дома это тоже несложно.

Из вышесказанного, параметр «syslog.level=5» будет записывать только WARN и более серьёзные события.

Раньше я думал, что уровень «Normal» для «Device» - это Notice, «More» — Informational, а «Debug» — это Debug, но, похоже, уровень логов для «Device» вообще никак не влияет на логи UAP.

ChessMck Guest	#7 11.07.2020 20:10:00 Я только что научился использовать grep -v для фильтрации... 😃 Если у вас нет USG и вы запускаете контроллер — загляните в /var/log/ui.log на контроллере (кстати, над этим уже работают).

louis_s

Guest

11.07.2020 19:51:00

Спасибо, @ChessMck. Надо было сказать раньше – у меня такая же проблема: syslog генерирует слишком много сообщений. У меня нет той конкретной ошибки, что у @eddy34, но логи просто забиты кучей неважной информации. Я отключил syslog на UniFi, по моему мнению, он пока не совсем готов к серьезной эксплуатации. :-/

ChessMck

Guest

11.07.2020 19:32:00

У меня версия 4.3.19, и такого сообщения в /var/log/messages нет. Я также веду логирование netconsole вместе с Syslog (может, из-за этого разница). И я согласен, что UniFi контроллеру стоило бы дать возможность настроить уровень логирования, как это сделано в EdgeRouter через System GUI.

# syslog
syslog.status=enabled
syslog.level=7
syslog.remote.ip=192.168.13.99
syslog.remote.port=514
syslog.remote.status=enabled
netconsole.host=192.168.13.97
netconsole.port=514
netconsole.status=enabled

louis_s Guest	#10 11.07.2020 17:13:00 У меня такая же проблема с syslog. Просто странно, что в веб-конфигураторе нельзя выставить допустимое значение. INFO — уж слишком болтливо, это точно. Делюсь своим статусом, может пригодится (предполагаю, что вы умеете работать с ssh и unix). Мне удалось зайти по ssh на AP и отредактировать /tmp/system.cfg. Там есть строка "syslog.level=7", её можно поменять на 5, а потом применить командой syswrapper.sh apply-config. Это позволяет выставить уровень логирования, но, насколько я понимаю, после репровижена это не сохраняется. Потом я смог зайти по ssh на контроллер и создать файл "/srv/unifi/data/sites/default/config.properties" (для моего контроллера и сайта с именем "default"). В этот файл добавил строку: config.system_cfg.1=syslog.level=5 После репровижена в каждом AP в файле /tmp/system.cfg появляется вот что, когда я делаю grep grep syslog.level /tmp/running.cfg: syslog.level=7 syslog.level=5 Вместо того, чтобы заменить уровень 7 на 5, как сообщали другие, он просто добавляет 5. Это было бы нормально, если бы подставлялось последнее значение, но в /tmp/running.cfg видны оба, и явно берётся значение 7. Я собираюсь отключить syslog — он слишком шумный, если только кто-то не знает, как настроить адекватный уровень. Люди жалуются на чрезмерную болтливость syslog уже годы, и жаль, что Ubiquiti так и не починили это. Надеюсь, это кому-то поможет!

Читают тему (гостей: 1)