Opened 6 years ago
Closed 5 years ago
#285 closed улучшение (готово)
Добавить настройку "запись лога"
| Reported by: | san | Owned by: | alx |
|---|---|---|---|
| Priority: | средний | Milestone: | 1 очередь |
| Component: | VE-01 | Keywords: | |
| Cc: |
Description
Предлагаю добавить в плату настройку, которая будет включать/выключать запись лога в плате аналогично действиям описанным в инструкции: ve_diag.
Change History (14)
comment:1 by , 6 years ago
| Milestone: | 2 очередь → 1 очередь |
|---|
follow-up: 11 comment:2 by , 6 years ago
follow-up: 4 comment:3 by , 6 years ago
По поводу "1." конечно надо что-то делать, я помню несколько экспериментов когда в логе отсутствовали куски необходимые для разбора, если есть настройка которую можно покрутить, думаю это было бы проще всего.
По 2.1. я тоже согласен, нужна такая настройка рядом с кнопочкой "включить запись лога"
А насчёт 2.2 я сомневаюсь в целесообразности реализации.
comment:4 by , 6 years ago
Replying to san:
А насчёт 2.2 я сомневаюсь в целесообразности реализации.
Хм... Попробую пояснить мотивацию. Допустим, у нас имеется 250 абонентов. Один из них пожаловался, что у него что-то неправильно работает (не работает). Оператор хочет с помощью журнала выяснить, что же происходит. Он включает подробный лог и просит абонента повторить вызов. Но в это же время другие абоненты тоже куда-то звонят! В результате в журнале кроме сообщений, связанных с нужным канальным окончанием, будет куча ненужных сообщений об активности других канальных окончаний, что затруднит анализ. Возможность включать подробный лог только для событий, связанных с определенными канальными окончаниями, решает эту проблему, убирая заведомо ненужные сообщения из лога.
follow-up: 6 comment:5 by , 6 years ago
Кстати, Саша, как думаешь, может быть полезной функция направлять сообщения не своему собственному, а внешнему syslog'у (например указанием в конфиге адреса хоста, куда надо логгировать)?
comment:6 by , 6 years ago
Replying to alx:
направлять сообщения не своему собственному, а внешнему syslog'у
Предполагаемый сценарий: я обнаружил, что что-то работает неправильно. В конфигурации просто пишу адрес своего компьютера как получателя лога, одновременно повышаю подробность. И спокойно смотрю логи на своем компьютере - это избавляет меня от необходимости копировать логи из платы, автоматически решает проблему 1, плюс не расходуется ресурс ПЗУ постоянной записью в нее (точнее, я беспокоюсь не столько о ресурсе ПЗУ, сколько о том, что после записи большого объема на jffs2 плата начинает тормозить при старте - ей надо все записанное просканировать)... Плюс логи можно наблюдать практически в реальном времени, и для этого не надо сидеть в консоли платы, где все утилиты довольно убоги...
follow-up: 8 comment:7 by , 6 years ago
функция направлять сообщения не своему собственному, а внешнему syslog'у
Для применения "на столе" будет полезной, а в реальном применении наверное нет, т.к. у пользователей, судя по практике, практически никогда нет возможности дать нам доступ напрямую к блоку.
comment:8 by , 6 years ago
Replying to san:
Для применения "на столе" будет полезной, а в реальном применении наверное нет, т.к. у пользователей, судя по практике, практически никогда нет возможности дать нам доступ напрямую к блоку.
??? При чем тут мы? Я ничего не писал о даче доступа нам. Предполагаемый вариант использования функции описан в comment:6. Может быть тебя запутало то, что я там писал от имени оператора? Чтобы исключить возможную путаницу, перепишу от 3-го лица:
Предполагаемый сценарий: оператор, обслуживающий плату VE-01, обнаружил, что что-то работает неправильно. В конфигурации он просто пишет адрес своего компьютера как получателя лога, одновременно повышает подробность. И спокойно смотрит логи на своем компьютере - это избавляет его от необходимости копировать логи из платы... и так далее...
follow-up: 10 comment:9 by , 6 years ago
А, ну для предполагаемого оператора такое может быть полезно...но предполагаеемые операторы ничего не понимают в нашил логах(никакой инструкции/расшифровки логов у нас нет), сейчас логи нужны только для того чтобы если что-то не так, провести эксперимент и отправить нам.
comment:10 by , 6 years ago
Replying to san:
предполагаеемые операторы ничего не понимают в нашил логах
Я думаю, это у тебя выборка не репрезентативная. Ведь за поддержкой обращаются тогда, когда что-то непонятно, вот у тебя в результате таких обращений и сложилось впечатление, что всем что-то непонятно... :)
(никакой инструкции/расшифровки логов у нас нет),
Какая может быть инструкция по чтению лога? Никогда в жизни такой инструкции не видел (хотя логов разных прочитал множество). :) Читать учат в школе. Какая расшифровка? Лог не зашифрован. :) Вот недавно мне присылали логи станции ISKRATEL Si2000, которую я никогда не видел, так мне не потребовалось никакой инструкции чтобы их прочитать... Или вот пример с нашим логом по мотивам реальных событий. Допустим, у кого-то соединение отбилось по неизвестной причине. Человек смотрит лог и видит там запись "RTP timeout" (который он, действительно, установил). Какая еще инструкция и "расшифровка" нужна чтобы понять, что произошел тот самый таймаут RTP, который он сам установил в конфигурации? По-моему, никакая - все и так ясно, написано открытым текстом.
Конечно, в логе есть информация, которую пользователь без дополнительных пояснений не поймет - например в разных событиях есть поля flags=0001, data=2219. Но в 99% случаях этого ему понимать и не надо. А Incoming call, CAS event или Call disconnected вполне понятны без пояснений...
сейчас логи нужны только для того чтобы если что-то не так, провести эксперимент и отправить нам.
Это если что-то не так с платой VE-01 (или, как минимум, пользователь подозревает это). В противном случае лично мне, например, эти логи неинтересны. У меня своих полно. :)
comment:11 by , 6 years ago
Replying to alx:
- Как показали эксперименты, в busybox'овском syslogd есть какое-то ограничение на очередь сообщений или что-то типа этого.
Как оказалось, это ограничение не в busybox'е, а в ядре. Есть параметр sysctl net.unix.max_dgram_qlen, который равен 10. Предлагается где-нибудь в стартовом скрипте устанавливать его в значение, скажем, 100 - этого должно хватить для наших целей.
comment:14 by , 5 years ago
| Resolution: | → готово |
|---|---|
| Status: | new → closed |
В r1608 стало можно устанавливать как приоритет, так и режим журналирования (в файл или в буфер).
Режим и приоритет записываются в конфиг-файл /etc/config/system.
Чтобы не создавать новый тикет, изложу здесь дополнительные мысли по улучшению логгирования.
Саша, что ты думаешь по этому поводу? Давай обсудим, а по результатам создадим конкретные тикеты.