acme was asking about best practice for logging modules, citing Log::Log4Perl and Log::Dispatch. By preference and experience i'm a unix programmer, but recently (last couple of years) i've needed to write some stuff for the win32 platform. One of the more difficult things i've encountered is trying to log 'natively' on win32 and unix.
For me, native logging on win32 means logging to the windows event logger, which, as seen at Win32::EventLog, requires a numeric EventId and a set of parameters joined by the NUL character. Win32 combines these with a DLL provided by the application writer to produce the final localised message seen by the user in the event viewer. Unix on the other hand via syslog, requires a string which is sent to the appropriate log file. This presents a big problem when trying to create a common logging API.
So far, the usual way of combining the two seems to be by in the background, providing an EventId of 0 (or whatever number) and a single parameter consisting of the entire message. This allows this sort of interface:
Log->send($the_entire_log_message)
However, the EventId is the only thing visible in the event viewer until you double click on the specific event to see more details about it. Therefore scrolling through X completely different entries all with an EventId of 0 is a bit tedious to say the least. So this sort of interface is familiar to the Unix programmers, but possibly a little misleading if they think their work will ever run seamlessly on windows.
My best effort at creating a combined win32 / unix log library has been to provide a call like this:
Log->new($numericId, \@parameters)->send();
Which on unix opens the correct localisation file, creates the log message and sends it to syslog/wherever and on win32 sends direct to the event logger
Comments on these ideas?
I just started using log4net. Typically, I log info/debug to a file, then also push Error/Warn/Fatals to the event log to get picked up but event log monitoring software (like 2008 Server Event Log Subscriptions)
i would but ... :-)
ddick on 2008-08-30T10:31:50
Log::Log4perl::JavaMap::NTEventLogAppender calls Log::Dispatch::Win32EventLog calls Win32::EventLog and passes it an EventId of 0. Oh well.
Just because you are on Windows does not mean you need to use the event log. I personally don't like it and just use Log4perl.
Re:Logging
ddick on 2008-08-30T10:25:49
my two worries on that idea is;
firstly a native windows person (the customer installing the application) may get confused about why this application logs differently than the normal windows apps
secondly, you then need to choose/install/maintain your own logrotate stuff, if you wish to stop logs growing forever. the event logger, as you would expect for a native operating system function, does it's own housekeeping by default.
Re:Logging
jplindstrom on 2008-08-30T11:45:06
What, does anyone actually use and/or like the Windows event log?
Re:Logging
jk2addict on 2008-08-30T12:25:52
Normally, I hate it for logging. But things have changed in Vista/Server 2008.
Microsoft has tried to turn the Event log into a syslogd like system. You can have a central server receive and/or monitor all of the other servers events logs, and write monitoring rules (if you see x of y ad level z, email/netsend/script user $)
Now that it's easier to have a server to monitor logs (like in an ops or helpdesk area), I'm more inclined to use them, at least for Errors/Fatal level events.
Of course, if you're using something like log4net, you can push logs anywhere withotu even caring about changing your mind.
