[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Omaha.pm] RE: Net::Dev::Tools::Syslog -- local?
From: Scott Parsons [mailto:scott.parsons@marconi.com]
> For just syslog functionality you should not need both modules, just
> Sys::Syslog, it looks like it tries to handle streams.
Yes. Sys::Syslog works great for local and remote delivery until I want to log locally and simultaneously log to multiple remote machines, depending on the message / facility / priority / what have you. Since it's procedural code, calls to openlog() and closelog() are unilateral and I don't have granular control of open/close on multiple simultaeous sessions. If it was OO, I could just have as many $syslog objects as I wanted and do whatever. Unless I'm missing something, which wouldn't surprise me.
FWIW, below is a snippet of POD from one of my classes talking about the various Syslog'y packages...
> Thanks for the feedback, guess I should add to my doc about the intent of
> the functions, since its limiting.
Sure. Thanks for all your work on the module! It's slick! I'm using it to log to mutiple remote machines. (err.... I *will be* using it soon... -grin-)
Take care,
j
=item B<Sys::Syslog>
Procedural. Works great to local and remote syslogd processes.
Local delivery can be accomplished via "setlogsock 'unix';", which avoids
the overhead of UDP/TCP delivery. This is the B<only Perl class> that works
like this. Remote delivery via UDP or TCP can
be used by setting $Sys::Syslog::host. (Jay sent a POD patch to perl5-porters.)
=item B<Net::Syslog>
OO. Needs an open UDP port.
=item B<Net::Dev::Tools::Syslog>
OO. Needs an open UDP port. Very verbose interface w/ lots of
fancy dials and switches. Does parsing too, and is actively maintained.
=item B<Unix::Syslog>
Procedural. Sys::Syslog does everything Unix::Syslog does anyway? The
docs for Unix::Syslog make claims that don't seem true anymore while
comparing itself to Sys::Syslog.
=item B</usr/bin/logger>
Little command line utility that works great. Logs to syslog and metalog
with no problems. You can even open a filehandle to it, turn on autoflushing,
and just leave it running, which should avoid the overhead of forking it
every time.
=item B<Conclusion>
So... it's decision time. Let's do this:
local server
metalog
/usr/bin/logger
syslog
/usr/bin/logger
central server(s)
syslog - these have to be syslog. metalog won't listen.
One Net::Dev::Tools::Syslog instance per server