innd logging conventions
rra at stanford.edu
Tue Jan 16 14:41:07 UTC 2001
Matus \"fantomas\" Uhlar <uhlar at fantomas.sk> writes:
> - these are quite easy to process
> Oct 22 00:34:16 virtual innd: localhost connected 15 streaming allowed
> Oct 22 21:52:00 virtual innd: localhost connected 17
> Oct 22 00:34:16 virtual innd: localhost:15 closed seconds 0 accepted 0 refused 0 rejected 0
> Oct 22 00:22:00 virtual innd: news.ke.sanet.sk closed
> Oct 22 00:22:00 virtual innd: news.ke.sanet.sk flush
> Oct 22 20:42:00 virtual innd: news.ke.sanet.sk opened news.ke.sanet.sk:17:file
> Oct 22 11:11:10 virtual innd: news.ke.sanet.sk:17 NCmode "mode stream" received
> - the second parameter is important and should be the first imho:
> <date> virtual innd: connected <host> <fd> <args>
> <date> virtual innd: closed <host> <fd> <args>
> <date> virtual innd: flush <host>
Not that I'm necessarily disagreeing, but this was actually intentional
and documented, and I think there's a method to the madness. It's easier
to parse innd's log messages when you know that the first "word" is either
SERVER or the name of a host. If you're only interested in connection
reports, you can toss all the SERVER stuff, and likewise if you're only
interested in a connection you can just scan for that connection.
> Oct 22 00:22:00 virtual innd: f:news.ke.sanet.sk
> Oct 22 07:42:01 virtual innd: f:news.vol.cz
> Oct 22 01:00:54 virtual innd: h:Expiring process 90065
> Oct 22 01:00:00 virtual innd: j:
> Oct 22 01:00:53 virtual innd: m:Expiring process 90065
> Oct 22 01:02:32 virtual innd: n:
> Oct 22 01:00:00 virtual innd: s
> Oct 22 01:00:39 virtual innd: z:Expiring process 90065
> well, need to play much with these. afaik these are received commands
> via control socket (ctlinnd blahblahblah) - it could be changed probably
> to make it easier to process:
Bear in mind that the above is trace information that isn't even logged by
default if you follow the log instructions in INSTALL; the ctlinnd
messages above are logged as news.info and the default syslog
configuration ignores anything lower than news.notice. That doesn't mean
we can't make it clearer, of course, but it explains why it's not.
> Well I know that the logs should be readable by people, and computer is
> very fast ant it can process any kind of messages that are unique. But
> why to make it harder ?
Sure, I agree.
> maybe every routine/module could prepend its name before the message ?
That's not a bad idea. There's some intention already for doing this, but
it's handled a bit oddly. Hm. I'll keep that in mind.
> another one suggestion... news.daily (or better scanlogs) shouldn't
> expect logfiles to be names news.notice, news.err, news.crit - let
> user(admin?) define as he wants.
Eek, *more* configurable parameters? One reaches a point where adding
more configuration parameters just make things more confusing rather than
really adding flexibility.
What's wrong with the existing names?
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-workers