innd logging conventions

[Matus "fantomas" Uhlar]

...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.
comments ?


-> > 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
other reasons?

-> > 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