Hey,
I think in the next days I will go around the sourcecode and change a couple of logging messages. My two primary goals are increase the usefulness to figure out what was going wrong and the second to be able to put some of these into the syslog. Should we use DEBUG* to also log to syslog or introduce a new set of macros?
Log Levels:
I think Harald has expressed the wish to introduce log levels. Should we follow the log levels of syslog(3)?
Messages:
I would like to collect formats for various actions. Currently I'm thinking of the following but would like to have more input.
subscriber: When talking about a subscriber use TMSI, IMSI and Extension.
lchan: Include refcount, channel type, link_id, subscriber
sccp: Talk about SCCP source local reference and pointer
transaction: Print the transaction?
gsm0408: Print the lchan which prints the subscriber?
comments?
holger
Hi Zecke,
On Wed, Oct 07, 2009 at 10:38:04AM +0200, Holger Freyther wrote:
I think in the next days I will go around the sourcecode and change a couple of logging messages. My two primary goals are increase the usefulness to figure out what was going wrong and the second to be able to put some of these into the syslog.
Thanks for addressing this. I always wanted to get around to do it, but didn't find time so far.
Should we use DEBUG* to also log to syslog or introduce a new set of macros?
I think it would be best to introduce a new logging macro, and turn DEBUGP into a backwards compatibility macro that then calls/uses the new logging macro to print a DEBUG level message
There is some code for log file handling in ulogd (http://git.netfilter.org/cgi-bin/gitweb.cgi?p=ulogd2), see ulogd_log() and __ulog_log() in ulogd.h as well as __ulogd_log() in ulogd.c. It already handles logging to a runtime choice of either syslog or a dedicated text file. This is a feature that I'd like to see in openbsc, too.
In addition to that, we should support enabling of certain log levels and log 'groups' (like syslog facility, but more fine grained) to print to the telnet interface.
So from the telnet interface, I want to be able to use vty commands to do things like * enable "WARNING" level messages on this telnet vty for all groups (MM, CC, ...) * enable "DEBUG" level messages on this telnet vty for one specific group (SMS) * change the log level and log groups for the logfile
Log Levels:
I think Harald has expressed the wish to introduce log levels. Should we follow the log levels of syslog(3)?
yes.
I would like to collect formats for various actions. Currently I'm thinking of the following but would like to have more input.
all of those, plus
abis_nm needs formats for * object class and object instance * nm_state
since we probably need more and more of these, it might be interesting to think of adding a new format character instead of %... % is already heavily used especially in glibc.g
Regards,
On Wednesday 07 October 2009 16:56:47 Harald Welte wrote:
Hi Zecke,
since we probably need more and more of these, it might be interesting to think of adding a new format character instead of %... % is already heavily used especially in glibc.g
Do we mind GNUism? If not we could register special handlers for lchan, subscriber and such.
holger
On Wed, Oct 07, 2009 at 05:18:41PM +0200, Holger Freyther wrote:
since we probably need more and more of these, it might be interesting to think of adding a new format character instead of %... % is already heavily used especially in glibc.g
Do we mind GNUism? If not we could register special handlers for lchan, subscriber and such.
I think we can make the assumption that we need gcc for compilation, but we should not introduce arbitrary dependencies on things like the libc we're using (which would make it impossible to build on BSD, windows, solaris or macos, I guess).
Regards,
Hey LaForge,
in one way this is a continuation of the thread but there is no real need to quote anything. I went to ulogd and had a look (and copied the levels), I looked at what we have and what would be neat and came up with a small interface right now[1]...
The first thing is the introduction to have a log level. This will allow to set a global log level or one by subsystem...
The next thing is the concept of a target. We can add multiple targets (stdout, syslog, file, telnet) and have them be active at the same time (think of a loop inside the debugp statement). We can have a log level per target...
The next thing is a "context". On the receive message path we start with the phsyical connection to the BTS, then with MM or RSL, going to GSM04.08, and then more protocols. On this path we can add a "context". E.g. we received this message for this bts, it was this lchan, it was this subscriber... (and the same for the sending path)
Having the context will allow to have filters. E.g. only show me RSL messages sent for the LCHAN assigned to SUBSCRIBER with the IMSI:XYZ. I foresee this useful when trying to debug things with the telnet interface in a real network.
At this point I would appreciate API feedback to see if it is useful to continue this way or if another solution is better.
regards z
[1] In the holger/new-debug-arch branch
Hi zecke,
On Mon, Nov 09, 2009 at 04:20:09AM +0100, Holger Freyther wrote:
in one way this is a continuation of the thread but there is no real need to quote anything. I went to ulogd and had a look (and copied the levels), I looked at what we have and what would be neat and came up with a small interface right now[1]...
ok, I will look at it asap.
The first thing is the introduction to have a log level. This will allow to set a global log level or one by subsystem...
yes, that makes sense.
The next thing is the concept of a target. We can add multiple targets (stdout, syslog, file, telnet) and have them be active at the same time (think of a loop inside the debugp statement). We can have a log level per target...
also makes sense, of course.
The next thing is a "context". On the receive message path we start with the phsyical connection to the BTS, then with MM or RSL, going to GSM04.08, and then more protocols. On this path we can add a "context". E.g. we received this message for this bts, it was this lchan, it was this subscriber... (and the same for the sending path)
agree here, too.
Having the context will allow to have filters. E.g. only show me RSL messages sent for the LCHAN assigned to SUBSCRIBER with the IMSI:XYZ. I foresee this useful when trying to debug things with the telnet interface in a real network.
yes, that makes even more sense. not sure to what level of complexity we need to go. It's probably sufficient if we can already set the context+loglevel, and then indicate a subscriber/imsi as filter. If anybody wants something more sophisticated, like all messages on one specific lchan/trx/bts/..., it's probably sufficient to simply ask him to write the filter function in c code and somehow easily hook that into the logging.
I mean, in any case we always have wireshark, too. But what wireshark doesn't have at the moment is the context to trace all actions of one subscriber, e.g.
So we should not try to over-engineer for every possible use case
On Tue, Nov 10, 2009 at 04:17:05PM +0900, Harald Welte wrote:
in one way this is a continuation of the thread but there is no real need to quote anything. I went to ulogd and had a look (and copied the levels), I looked at what we have and what would be neat and came up with a small interface right now[1]...
ok, I will look at it asap.
I've now looked at it. I am not sure if we really need our own filter language, whoch would just add a lot of ugly string parsing/handling code and overall complexity. I mean, if you want to write that, do it :) But I think there are other more important things to take care of...
Another topic is: How do you want to handle the log targets? I mean, there's only one logfile or one syslog target, sure. But what about the VTY's? We can have a number of VTY connections, and it may very well make sense to use one non-debug VTY for issuing commands (without scrolling debug messages) and a different VTY where you are mainly interested in seeing [scrolling] debug log.
So every VTY would register its own debug target after the telnet connection is established?
Otherwise everything looks fine to me.
On Wednesday 11 November 2009 14:57:25 Harald Welte wrote:
On Tue, Nov 10, 2009 at 04:17:05PM +0900, Harald Welte wrote:
in one way this is a continuation of the thread but there is no real need to quote anything. I went to ulogd and had a look (and copied the levels), I looked at what we have and what would be neat and came up with a small interface right now[1]...
ok, I will look at it asap.
I've now looked at it. I am not sure if we really need our own filter language, whoch would just add a lot of ugly string parsing/handling code and overall complexity. I mean, if you want to write that, do it :) But I think there are other more important things to take care of...
I agree. I was thinking about the VTY case and we need to have a way to go from string to code (enabling/configuring the filter) and I didn't want to add a lot of VTY commands. Let me think about something easy here..
Another topic is: How do you want to handle the log targets? I mean, there's only one logfile or one syslog target, sure. But what about the VTY's? We can have a number of VTY connections, and it may very well make sense to use one non-debug VTY for issuing commands (without scrolling debug messages) and a different VTY where you are mainly interested in seeing [scrolling] debug log.
My idea was to add a "target" when the telnet connection is opened and remove it when it is closed and by default not output anything.
So every VTY would register its own debug target after the telnet connection is established?
Yeah.
Otherwise everything looks fine to me.
I hope to have a first implementation to toy with soon.
regards holger
Hi,
I think it would be nice to have Cisco-like approach with term mon/term no mon commands in order to enable debug on one vty.
Regards
Roch.
Holger Freyther wrote:
On Wednesday 11 November 2009 14:57:25 Harald Welte wrote:
On Tue, Nov 10, 2009 at 04:17:05PM +0900, Harald Welte wrote:
in one way this is a continuation of the thread but there is no real need to quote anything. I went to ulogd and had a look (and copied the levels), I looked at what we have and what would be neat and came up with a small interface right now[1]...
ok, I will look at it asap.
I've now looked at it. I am not sure if we really need our own filter language, whoch would just add a lot of ugly string parsing/handling code and overall complexity. I mean, if you want to write that, do it :) But I think there are other more important things to take care of...
I agree. I was thinking about the VTY case and we need to have a way to go from string to code (enabling/configuring the filter) and I didn't want to add a lot of VTY commands. Let me think about something easy here..
Another topic is: How do you want to handle the log targets? I mean, there's only one logfile or one syslog target, sure. But what about the VTY's? We can have a number of VTY connections, and it may very well make sense to use one non-debug VTY for issuing commands (without scrolling debug messages) and a different VTY where you are mainly interested in seeing [scrolling] debug log.
My idea was to add a "target" when the telnet connection is opened and remove it when it is closed and by default not output anything.
So every VTY would register its own debug target after the telnet connection is established?
Yeah.
Otherwise everything looks fine to me.
I hope to have a first implementation to toy with soon.
regards holger
-
Harald Welte -
Holger Freyther -
Roch