Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ddick (5726)

ddick
  (email not shown publicly)

I'm based out of Melbourne, Australia. I attend the excellent melbourne.pm.org meetings whenever i get the chance, which is not often enough.

Journal of ddick (5726)

Friday August 29, 2008
06:59 PM

Modules for logging on win32

[ #37311 ]

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?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • http://search.cpan.org/~mschilli/Log-Log4perl-1.18/lib/Log/Log4perl/JavaMap/NTEv entLogAppender.pm [cpan.org]

    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)

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

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

      • What, does anyone actually use and/or like the Windows event log?

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