Scribe Setting log level in Scribe

[Jeffrey Young]

Good afternoon all,

I have Scribe installed on my AC86U. Now, before Scribe, there was an option in the syslog page to set the log level. Since installing Scribe, I have not been able to find a spot where the log level can be set. Either in any of .conf files or UI.

I see two setting in the nvram; console_loglevel=5 and log_level=7.

In a bid to clean up the logs a bit in the router using Scribe, is it sufficient to set log_level in nvram to, say 5? Or does a setting need to be added in /opt/etc/syslog-ng.conf?

Cheers

 

[elorimer]

Good afternoon all,

I have Scribe installed on my AC86U. Now, before Scribe, there was an option in the syslog page to set the log level. Since installing Scribe, I have not been able to find a spot where the log level can be set. Either in any of .conf files or UI.

I see two setting in the nvram; console_loglevel=5 and log_level=7.

In a bid to clean up the logs a bit in the router using Scribe, is it sufficient to set log_level in nvram to, say 5? Or does a setting need to be added in /opt/etc/syslog-ng.conf?

Cheers

A few different things, I think. Out of the box the kernel is generating log messages. Those are read by syslogd and logged to /tmp/syslog.log. The webGUI displays that log, and I think exposes those settings of what log messages are generated and what are shown in the webGUI.

Scribe is a way of configuring syslog-ng to run on the router instead of syslogd. uiScribe is a replacement page in the webGUI that shows the log files syslog-ng manages. I think you are right that uiScribe is not showing those settings, and I wonder, @Jack Yaz , should it expose at least one of them? Mine are also 5/7, but those I think are the default settings.

Syslog-ng, as configured by Scribe, simply harvests the messages kicked out by the kernel and then does more extensive processing on them, separating them out into separate files or dropping them entirely. There is no setting in syslog-ng controlling what messages are generated by the kernel, but everything generated is read and processed. If you want to see fewer log messages, then you want to create a filter to sift out those messages and drop them, or put them in a file you never look at.

uiScribe then allows you to see (or not see) in the webGUI whatever separate files syslog-ng has created.

 

[Butterfly Bones]

I ran into that as well about a year ago. Simple fix is uninstall uiScribe only (NOT Scribe), set the log levels you seek, then reinstall uiScribe. Simple solution I use occasionally when chasing down a gremlin.

 

[Jeffrey Young]

Thanks @elorimer and @Butterfly Bones for the responses.

I like Butterbly's solution. Thanks all.

 

[archiel]

A couple of questions on the above

1. When using Scribe (syslog-ng instead of syslogd) which log setting is is Scribe using, console_loglevel=, log_level= or something else?
2. Rather than uninstalling / reinstalling uiScribe, would there be anything wrong in setting the level directly e.g. nvram set log_level=x (and adding nvram commit if it is to survive reboot)?

 

[elorimer]

When using Scribe (syslog-ng instead of syslogd) which log setting is is Scribe using, console_loglevel=, log_level= or something else?

Syslog-ng/scribe doesn't use those settings at all. It processes whatever the kernel generates. I think log_level might control what the kernel generates. ED: No, console_loglevel, being what goes to the god terminal in the server room.

Rather than uninstalling / reinstalling uiScribe, would there be anything wrong in setting the level directly e.g. nvram set log_level=x (and adding nvram commit if it is to survive reboot)?

I don't know whether changing the settings in the webgui as @Butterfly Bones suggests changes other variables as well.

 

[archiel]

Syslog-ng/scribe doesn't use those settings at all. It processes whatever the kernel generates. I think log_level might control what the kernel generates.

I don't know whether changing the settings in the webgui as @Butterfly Bones suggests changes other variables as well.

So, as I follow it, syslogd captures data based on log_level and displays data based on console_loglevel, where the levels rage from 0 (emergency) to 7 (debug). So if syslogd is replaced by syslog-ng does syslog-ng always capture at the debug level or is there a way of adjusting how much it captures and if so is it using the log_level value in nvram or does it use something else?

 

[Jeffrey Young]

So, as I follow it, syslogd captures data based on log_level and displays data based on console_loglevel, where the levels rage from 0 (emergency) to 7 (debug). So if syslogd is replaced by syslog-ng does syslog-ng always capture at the debug level or is there a way of adjusting how much it captures and if so is it using the log_level value in nvram or does it use something else?

I am hoping to test this week, if I get a chance. Right now my console_loglevel is set to 5 and log_level is set 7. I am going to set log_level to 5 and see if it affects the amount of message traffic from the kernel (nvram set log_level=5;commit;reboot)

 

[elorimer]

So, as I follow it, syslogd captures data based on log_level and displays data based on console_loglevel, where the levels rage from 0 (emergency) to 7 (debug).

I think the opposite is true. I won't pretend I understand this though.

If I follow, console_loglevel is a kernel setting that controls what messages are output by printk(). So if you change this to 6, only info and above messages go to klog. Out of the box, syslogd collects these messages and writes only those at log_level and above to /tmp/syslog.log. I thought syslogd was normally controlled by /etc/syslog.conf, but I can't find that file, but I think log_level is the equivalent of syslogd -l <insert log_level here>with additional parameters being -O /tmp/syslog.log -S, and so on.

Now, with syslog-ng running, it will read everything output by printk(), and the nvram variable log_level doesn't figure into things. If one wanted to, one could include in your log filters the syslog-ng equivalent, which is level().

The level() filter accepts the following levels: emerg, alert, crit, err, warning, notice, info, debug.

You could include a level() filter in any of scribe's filters to screen out messages. So you could have a logging statement that logged emerg messages to a remote server or perhaps email, minding here the placement of the log statement and the absence of the final() flag. I don't think there is much point in trying to read the nvram variable for this.

TBH, I don't think this has come up before.

 

[Jeffrey Young]

I really appreciate the effort all has out into this. More thought provoking than I anticipated.

In the end, I don't really have an issue other than just wanting to clean up the noise a bit now that my router is rolling along with out any issues.

Good conversations