NAME
Log::Agent - logging agent
SYNOPSIS
use Log::Agent; # in all reusable components
logerr "error";
logtrc "notice:12", "notice that" if ...;
logdie "log and die";
use Log::Agent; # in application's main
logconfig(-prefix => $0); # simplest, uses default driver
use Log::Agent; # another more complex example
require Log::Agent::Driver::File; # logging made to file
logconfig(-driver =>
Log::Agent::Driver::File->make(
-prefix => $0,
-showpid => 1,
-channels => {
'error' => "$0.err",
'output' => "$0.out",
'debug' => "$0.dbg",
},
)
);
DESCRIPTION
The `Log::Agent' module provides an abstract layer for logging and
tracing, which is independant from the actual method used to physically
perform those activities. It acts as an agent (hence the name) that
collects the requests and delegates processing to a sublayer: the
logging driver.
The `Log::Agent' module is meant to be used in all reusable components,
since they cannot know in advance how the application which ends up
using them will perform its logging activities: either by emitting
messages on stdout and errors on stderr, or by directing messages to
logfiles, or by using syslog(3).
The logging interface is common for all the logging drivers, and is
therefore the result of a compromise between many logging schemes: any
information given at this level must be either handled by all drivers,
or may be ignored depending on the application's final choice.
PRIORITIES AND LEVEL
The `Log::Agent' module can use both priorities (as defined by
syslog(3)) or logging levels, or either, in which case there is an
implicit computation of the missing item (i.e. the level 4, for
instance, corresponds to the "warning" priority, and vice-versa). See
Log::Agent::Priorities for more details.
A logging level is defined as being a threshold: any level lesser than
or equal to that threshold will be logged.
At the `Log::Agent' level, it is possible to define a trace level and a
debug level. Only the messages below those levels (inclusive) will be
handed out to the underlying driver for logging. They are used by the
logtrc() and logdbg() routines, respectively.
CHANNELS
The `Log::Agent' class defines three logging channels, which are
`error', `output' and `debug'. Depending on the driver used for logging,
those channels are ignored (typically with syslog()) or may be
implicitely defined (default logging, i.e. the one achieved by the
`Log::Agent::Driver::Default' driver, remaps `error' and `debug' to
stderr, `output' to stdout).
INTERFACE
Anywhere a *message* is expected, it can be a single string, or a
printf()-like format string followed by the required arguments. The
special macro `%m' is handled directly by `Log::Agent' and is replaced
by the string version of $!, which is the last error message returned by
the last failing system call.
NOTE: There should not be any trailing "\n" in the *message* strings,
nor any embededed one, although this is not enforced. Remember that the
main purpose of `Log::Agent' is to specify logging messages in a
standard way! Therefore, most of the time, a "should" should be read as
"must" and "should not" as "must not", which is the strongest
interdiction form available in English, as far as I know.
Here are valid *message* examples:
"started since $time"
"started since %s", $time
"fork: %m"
The follwing logging interface is made available to modules:
logdbg *priority*, *message*
Debug logging of *message* to the `debug' channel.
You may specify any priority you want, i.e. a `debug' priority is
not enforced here. You may even specify `"notice:4"' if you wish, to
have the message logged if the debug level is set to 4 or less. If
handed over to syslog(3), the message will nonetheless be logged at
the `notice' priority.
logtrc *priority*, *message*
Trace logging of *message* to the `output' channel.
Like logdbg() above, you are not restricted to the `info' priority.
This routine checks the logging level (either explicit as in
`"info:14"' or implicit as in `"notice"') against the trace level.
logsay *message*
Log the message at the `notice' priority to the `output' channel.
The logging always takes place under the default `-trace' settings,
but only if the routine is called, naturally. This means you can
still say:
logsay "some trace message" if $verbose;
and control whether the message is emitted by using some external
configuration for your module (e.g. by adding a -verbose flag to the
creation routine of your class).
logwarn *message*
Log a warning message at the `warning' priority to the `error'
channel.
logcarp *message*
Same as logwarn(), but issues a Carp::carp(3) call instead, which
will warn from the perspective of the routine's caller.
logerr *message*
Log an error message at the `error' priority to the `error' channel.
logdie *message*
Log a fatal message at the `critical' priority to the `error'
channel, and then dies.
logconfess *message*
Same as logdie(), but issues a Carp::confess(3) call instead. It is
possible to configure the `Log::Agent' module via the `-confess'
switch to automatically redirect a logdie() to logconfess(), which
is invaluable during unit testing.
logcroak *message*
Same as logdie(), but issues a Carp::croak(3) call instead. It is
possible to configure the `Log::Agent' module via the `-confess'
switch to automatically redirect a logcroak() to logconfess(), which
is invaluable during unit testing.
Log::Agent::inited
Returns true when `Log::Agent' was initialized, either explicitely
via a logconfig() or implicitely via any logxxx() call.
Modules sometimes wish to report errors from the perspective of their
caller's caller, not really their caller. The following interface is
therefore provided:
logxcarp *offset*, *message*
Same a logcarp(), but with an additional offset to be applied on the
stack. To warn one level above your caller, set it to 1.
logxcroak *offset*, *message*
Same a logcroak(), but with an additional offset to be applied on
the stack. To report an error one level above your caller, set it to
1.
For applications that wish to implement a debug layer on top of
`Log::Agent', the following routine is provided. Note that it is not
imported by default, i.e. it needs to be explicitely mentionned at `use'
time, since it is not meant to be used directly under regular usage.
logwrite *channel*, *priority*, *message*
Unconditionally write the *message* at the given *priority* on
*channel*. The channel can be one of `debug', `error' or `output'.
At the application level, one needs to commit once and for all about the
logging scheme to be used. This is done thanks to the logconfig()
routine which takes the following switches, in alphabetical order:
`-caller' => [ *parameters* ]
Request that caller information (relative to the logxxx() call) be
part of the log message. The given *parameters* are handed off to
the creation routine of `Log::Agent::Tag::Caller' and are documented
there.
I usually say something like:
-caller => [ -display => '($sub/$line)', -postfix => 1 ]
which I find informative enough. On occasion, I found myself using
more complex sequences. See Log::Agent::Tag::Caller.
`-confess' => *flag*
When true, all logdie() calls will be automatically masqueraded as
logconfess().
`-debug' => *priority or level*
Sets the priority threshold (can be expressed as a string or a
number, the string being mapped to a logging level as described
above in PRIORITIES AND LEVEL) for logdbg() calls.
Calls tagged with a level less than or equal to the given threshold
will pass through, others will return prematurely without logging
anything.
`-driver' => *driver_object*
This switch defines the driver object to be used, which must be an
heir of the `Log::Agent::Driver' class. See Log::Agent::Driver(3)
for a list of the available drivers.
`-level' => *priority or level*
Specifies both `-debug' and `-trace' levels at the same time, to a
common value.
`-prefix' => *name*
Defines the application name which will be pre-pended to all
messages, followed by `": "' (a colon and a space). Using this
switch alone will configure the default driver to use that prefix
(stripped down to its basename component).
When a driver object is used, the `-prefix' switch is kept at the
`Log::Agent' level only and is not passed to the driver: it is up to
the driver's creation routine to request the `-prefix'. Having this
information in Log::Agent enables the module to die on critical
errors with that error prefix, since it cannot rely on the logging
driver for that, obviously.
`-priority' => [ *parameters* ]
Request that message priority information be part of the log
message. The given *parameters* are handed off to the creation
routine of `Log::Agent::Tag::Priority' and are documented there.
I usually say something like:
-priority => [ -display => '[$priority]' ]
which will display the whole priority name at the beginning of the
messages, e.g. "[warning]" for a logwarn() or "[error]" for
logerr(). See Log::Agent::Tag::Priority and Log::Agent::Priorities.
NOTE: Using `-priority' does not prevent the `-duperr' flag of the
file driver to also add its own hardwired prefixing in front of
duplicated error messages. The two options act at a different level.
`-tags' => [ *list of `Log::Agent::Tag' objects* ]
Specifies user-defined tags to be added to each message. The objects
given here must inherit from `Log::Agent::Tag' and conform to its
interface. See Log::Agent::Tag for details.
At runtime, well after logconfig() was issued, it may be desirable
to add (or remove) a user tag. Use the `logtags()' routine for this
purpose, and iteract directly with the tag list object.
For instance, a web module might wish to tag all the messages with a
session ID, information that might not have been available by the
time logconfig() was issued.
`-trace' => *priority or level*
Same a `-debug' but applies to logsay(), logwarn(), logerr() and
logtrc().
When unspecified, `Log::Agent' runs at the "notice" level.
Additional routines, not exported by default, are:
logtags
Returns a `Log::Agent::Tag_List' object, which holds all
user-defined tags that are to be added to each log message.
The initial list of tags is normally supplied by the application at
logconfig() time, via the `-tags' argument. To add or remove tags
after configuration time, one needs direct access to the tag list,
obtained via this routine. See Log::Agent::Tag_List for the
operations that can be performed.
KNOWN LIMITATIONS
The following limitations exist in this early version. They might be
addressed in future versions if they are perceived as annoying
limitatons instead of being just documented ones. :-)
* A module which calls logdie() may have its die trapped if called
from within an eval(), but unfortunately, the value of $@ is
unpredictable: it may be prefixed or not depending on the driver
used. This is harder to fix as one might think of at first glance.
* Some drivers lack customization and hardwire a few things that come
from my personal taste, like the prefixing done when *duperr* is set
in Log::Agent::Driver::File, or the fact that the `debug' and
`stderr' channels are merged as one in the
Log::Agent::Driver::Default driver.
* When using logcroak() or logconfess(), the place where the call was
made can still be visible when -caller is used, since the addition
of the caller information to the message is done before calling the
logging driver. Is this a problem?
AUTHOR
Log::Agent was originally authored by Raphael Manfredi
<Raphael_Manfredi@pobox.com> and is currently maintained by Mark Rogaski
<mrogaski@cpan.org>.
LICENSE
Copyright (c) 1999-2000 Raphael Manfredi.
Copyright (c) 2002-2017 Mark Rogaski; all rights reserved.
This module is free software. You can redistribute it and/or modify it
under the terms of the Artistic License 2.0.
This program is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of
merchantability or fitness for a particular purpose.
SEE ALSO
Log::Agent::Driver(3), Carp(3).