innd logging conventions
Matus "fantomas" Uhlar
uhlar at fantomas.sk
Fri Jan 26 09:45:05 UTC 2001
...a bit later but...
-> > - 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.
and it's much easier to parse messages when they stare by SERVER or CLIENT
then if they start with the SERVER or <hostname> or anything like that.
what everything can innd put in logfile?
- connections from remote sites
- feed statistics
- child processes status
- internal informations
- server commands
each of these could get its own keywors that would be first in logfile.
-> > 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.
maybe these could be changed to news.debug, or is it (DEBUG) being used for
-> > 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.
these could be defined when building.
-> What's wrong with the existing names?
well, expecting any name of a file is bad imho. there are many reasons why
admin could change file name/location etc
Matus "fantomas" Uhlar, sysadmin at NEXTRA, Slovakia; IRCNET admin of *.sk
uhlar at fantomas.sk ; http://www.fantomas.sk/ ; http://www.nextra.sk/
42.7 percent of all statistics are made up on the spot.
Odchozí zpráva obsahuje viry.
Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz).
Verze: 6.0.217 / Virová báze: 102 - datum vydání: 1/12/2000
More information about the inn-workers