Ñò
Ã#xPc @ s d Z d d k Z d d k Z d d k Z d d k Z d d k Z d d k Z d Z h e i d 6e i d 6e i
d 6e i d 6e i d 6e i d 6e i
d
6Z e i e i
e i e i e i
f Z d Z d „ Z d
„ Z d „ Z d „ Z d e f d „ ƒ YZ d S( s†Q
Quick Start Guide For Using This Module
=======================================
This module implements a Log Manager class which wraps the Python
logging module and provides some utility functions for use with
logging. All logging operations should be done through the
`LogManager` where available. *DO NOT create objects using the
Python logging module, the log manager will be unaware of them.*
This module was designed for ease of use while preserving advanced
functionality and performance. You must perform the following steps.
1. Import the log_manger module and instantiate *one* `LogManager`
instance for your application or library. The `LogManager` is
configured via `LogManager.configure()` whose values are
easily populated from command line options or a config file. You
can modify the configuration again at any point.
2. Create one or more output handlers via
`LogManager.create_log_handlers()` an easy to use yet powerful
interface.
3. In your code create loggers via `LogManager.get_logger()`. Since
loggers are normally bound to a class this method is optimized for
that case, all you need to do in the call ``__init__()`` is::
log_mgr.get_logger(self, True)
Then emitting messages is as simple as ``self.debug()`` or ``self.error()``
Example:
--------
::
# Step 1, Create log manager and configure it
prog_name = 'my_app'
log_mgr = LogManager(prog_name)
log_mgr.configure(dict(verbose=True))
# Step 2, Create handlers
log_mgr.create_log_handlers([dict(name='my_app stdout',
stream=sys.stdout,
level=logging.INFO),
dict(name='my_app file',
filename='my_app.log',
level=logging.DEBUG)])
# Step 3, Create and use a logger in your code
class FooBar:
def __init__(self, name):
log_mgr.get_logger(self, True)
self.info("I'm alive! %s", name)
foobar = FooBar('Dr. Frankenstein')
# Dump the log manager state for illustration
print
print log_mgr
Running the above code would produce::
: I'm alive! Dr. Frankenstein
root_logger_name: my_app
configure_state: None
default_level: INFO
debug: False
verbose: True
number of loggers: 2
"my_app" [level=INFO]
"my_app.__main__.FooBar" [level=INFO]
number of handlers: 2
"my_app file" [level=DEBUG]
"my_app stdout" [level=INFO]
number of logger regexps: 0
*Note, Steps 1 & 2 were broken out for expository purposes.* You can
pass your handler configuration into `LogManager.configure()`. The above
could have been simpler and more compact.::
# Step 1 & 2, Create log manager, and configure it and handlers
prog_name = 'my_app'
log_mgr = LogManager(prog_name)
log_mgr.configure(dict(verbose=True,
handlers = [dict(name='my_app stdout',
stream=sys.stdout,
level=logging.INFO),
dict(name='my_app file',
filename='my_app.log',
level=logging.DEBUG)])
FAQ (Frequently Asked Questions)
================================
#. **Why is this better than logging.basicConfig? The short example
for the LogManager doesn't seem much different in complexity from
basicConfig?**
* You get independent logging namespaces. You can instantiate
multiple logging namespaces. If you use this module you'll be
isolated from other users of the Python logging module avoiding
conflicts.
* Creating and initializing loggers for classes is trivial. One
simple call creates the logger, configures it, and sets logging
methods on the class instance.
* You can easily configure individual loggers to different
levels. For example turn on debuging for just the part of the
code you're working on.
* The configuration is both simple and powerful. You get many more
options than with basicConfig.
* You can dynamically reset the logging configuration during
execution, you're not forced to live with the config established
during program initialization.
* The manager optimizes the use of the logging objects, you'll
spend less time executing pointless logging code for messages
that won't be emitted.
* You can see the state of all the logging objects in your
namespace from one centrally managed location.
* You can configure a LogManager to use the standard logging root
logger and get all the benefits of this API.
#. **How do I turn on debug logging for a specific class without
affecting the rest of the logging configuration?**
Use a logger regular expression to bind a custom level to loggers
whose name matches the regexp. See `LogManager.configure()`
for details.
Lets say you want to set your Foo.Bar class to debug, then do
this::
log_mgr.configure(dict(logger_regexps=[(r'Foo\.Bar', 'debug')]))
#. **I set the default_level but all my loggers are configured
with a higher level, what happened?**
You probably don't have any handlers defined at or below the
default_level. The level set on a logger will never be
lower than the lowest level handler available to that logger.
#. **My logger's all have their level set to a huge integer, why?**
See above. Logger's will never have a level less than the level of
the handlers visible to the logger. If there are no handlers then
loggers can't output anything so their level is set to maxint.
#. **I set the default_level but all the loggers are configured
at INFO or DEBUG, what happened?**
The verbose and debug config flags set the default_level to
INFO and DEBUG respectively as a convenience.
#. **I'm not seeing messages output when I expect them to be, what's
wrong?**
For a message to be emitted the following 3 conditions must hold:
* Message level >= logger's level
* Message level >= handler's level
* The message was not elided by a filter
To verify the above conditions hold print out the log manager state
(e.g. print log_mgr). Locate your logger, what level is at? Locate
the handler you expected to see the message appear on, what level
is it?
A General Discussion of Python Logging
======================================
The design of this module is driven by how the Python logging module
works. The following discussion complements the Python Logging Howto,
fills in some missing information and covers strategies for
implementing different functionality along with the trade-offs
involved.
Understanding when & how log messages are emitted:
--------------------------------------------------
Loggers provide the application interface for logging. Every logger
object has the following methods debug(), info(), warning(), error(),
critical(), exception() and log() all of which can accept a format
string and arguments. Applications generate logging messages by
calling one of these methods to produce a formatted message.
A logger's effective level is the first explicitly set level found
when searching from the logger through it's ancestors terminating at
the root logger. The root logger always has an explicit level
(defaults to WARNING).
For a message to be emitted by a handler the following must be true:
The logger's effective level must >= message level and it must not
be filtered by a filter attached to the logger, otherwise the
message is discarded.
If the message survives the logger check it is passed to a list of
handlers. A handler will emit the message if the handler's level >=
message level and its not filtered by a filter attached to the
handler.
The list of handlers is determined thusly: Each logger has a list of
handlers (which may be empty). Starting with the logger the message
was bound to the message is passed to each of it's handlers. Then
the process repeats itself by traversing the chain of loggers
through all of it's ancestors until it reaches the root logger. The
logger traversal will be terminated if the propagate flag on a logger
is False (by default propagate is True).
Let's look at a hypothetical logger hierarchy (tree)::
A
/ \
B D
/
C
There are 4 loggers and 3 handlers
Loggers:
+-------+---------+---------+-----------+----------+
|Logger | Level | Filters | Propagate | Handlers |
+=======+=========+=========+===========+==========+
| A | WARNING | [] | False | [h1,h2] |
+-------+---------+---------+-----------+----------+
| A.B | ERROR | [] | False | [h3] |
+-------+---------+---------+-----------+----------+
| A.B.C | DEBUG | [] | True | |
+-------+---------+---------+-----------+----------+
| A.D | | [] | True | |
+-------+---------+---------+-----------+----------+
Handlers:
+---------+---------+---------+
| Handler | Level | Filters |
+=========+=========+=========+
| h1 | ERROR | [] |
+---------+---------+---------+
| h2 | WARNING | [] |
+---------+---------+---------+
| h3 | DEBUG | [] |
+---------+---------+---------+
Each of the loggers and handlers have empty filter lists in this
example thus the filter checks will always pass.
If a debug message is posted logger A.B.C the following would
happen. The effective level is determined. Since it does not have a
level set it's parent (A.B) is examined which has ERROR set,
therefore the effective level of A.B.C is ERROR. Processing
immediately stops because the logger's level of ERROR does not
permit debug messages.
If an error message is posted on logger A.B.C it passes the logger
level check and filter check therefore the message is passed along
to the handlers. The list of handlers on A.B.C is empty so no
handlers are called at this position in the logging hierarchy. Logger
A.B.C's propagate flag is True so parent logger A.B handlers are
invoked. Handler h3's level is DEBUG, it passes both the level and
filter check thus h3 emits the message. Processing now stops because
logger A.B's propagate flag is False.
Now let's see what would happen if a warning message was posted on
logger A.D. It's effective level is WARNING because logger A.D does
not have a level set, it's only ancestor is logger A, the root
logger which has a level of WARNING, thus logger's A.D effective
level is WARNING. Logger A.D has no handlers, it's propagate flag is
True so the message is passed to it's parent logger A, the root
logger. Logger A has two handlers h1 and h2. The level of h1 is
ERROR so the warning message is discarded by h1, nothing is emitted
by h1. Next handler h2 is invoked, it's level is WARNING so it
passes both the level check and the filter check, thus h2 emits the
warning message.
How to configure independent logging spaces:
--------------------------------------------
A common idiom is to hang all handlers off the root logger and set
the root loggers level to the desired verbosity. But this simplistic
approach runs afoul of several problems, in particular who controls
logging (accomplished by configuring the root logger). The usual
advice is to check and see if the root logger has any handlers set,
if so someone before you has configured logging and you should
inherit their configuration, all you do is add your own loggers
without any explicitly set level. If the root logger doesn't have
handlers set then you go ahead and configure the root logger to your
preference. The idea here is if your code is being loaded by another
application you want to defer to that applications logging
configuration but if your code is running stand-alone you need to
set up logging yourself.
But sometimes your code really wants it's own logging configuration
managed only by yourself completely independent of any logging
configuration by someone who may have loaded your code. Even if you
code is not designed to be loaded as a package or module you may be
faced with this problem. A trivial example of this is running your
code under a unit test framework which itself uses the logging
facility (remember there is only ever one root logger in any Python
process).
Fortunately there is a simple way to accommodate this. All you need
to do is create a "fake" root in the logging hierarchy which belongs
to you. You set your fake root's propagate flag to False, set a
level on it and you'll hang your handlers off this fake root. Then
when you create your loggers each should be a descendant of this
fake root. Now you've completely isolated yourself in the logging
hierarchy and won't be influenced by any other logging
configuration. As an example let's say your your code is called
'foo' and so you name your fake root logger 'foo'.::
my_root = logging.getLogger('foo') # child of the root logger
my_root.propagate = False
my_root.setLevel(logging.DEBUG)
my_root.addHandler(my_handler)
Then every logger you create should have 'foo.' prepended to it's
name. If you're logging my module your module's logger would be
created like this::
module_logger = logging.getLogger('foo.%s' % __module__)
If you're logging by class then your class logger would be::
class_logger = logging.getLogger('foo.%s.%s' % (self.__module__, self.__class__.__name__))
How to set levels:
------------------
An instinctive or simplistic assumption is to set the root logger to a
high logging level, for example ERROR. After all you don't want to be
spamming users with debug and info messages. Let's also assume you've
got two handlers, one for a file and one for the console, both
attached to the root logger (a common configuration) and you haven't
set the level on either handler (in which case the handler will emit
all levels).
But now let's say you want to turn on debugging, but just to the file,
the console should continue to only emit error messages.
You set the root logger's level to DEBUG. The first thing you notice is
that you're getting debug message both in the file and on the console
because the console's handler does not have a level set. Not what you
want.
So you go back restore the root loggers level back to it's original
ERROR level and set the file handler's level to DEBUG and the console
handler's level to ERROR. Now you don't get any debug messages because
the root logger is blocking all messages below the level of ERROR and
doesn't invoke any handlers. The file handler attached to the root
logger even though it's level is set to DEBUG never gets a chance to
process the message.
*IMPORTANT:* You have to set the logger's level to the minimum of all
the attached handler's levels, otherwise the logger may block the
message from ever reaching any handler.
In this example the root logger's level must be set to DEBUG, the file
handler's level to DEBUG, and the console handler's level set to
ERROR.
Now let's take a more real world example which is a bit more
complicated. It's typical to assign loggers to every major class. In
fact this is the design strategy of Java logging from which the Python
logging is modeled. In a large complex application or library that
means dozens or possibly hundreds of loggers. Now lets say you need to
trace what is happening with one class. If you use the simplistic
configuration outlined above you'll set the log level of the root
logger and one of the handlers to debug. Now you're flooded with debug
message from every logger in the system when all you wanted was the
debug messages from just one class.
How can you get fine grained control over which loggers emit debug
messages? Here are some possibilities:
(1) Set a filter.
.................
When a message is propagated to a logger in the hierarchy first the
loggers level is checked. If logger level passes then the logger
iterates over every handler attached to the logger first checking the
handler level. If the handler level check passes then the filters
attached to the handler are run.
Filters are passed the record (i.e. the message), it does not have
access to either the logger or handler it's executing within. You
can't just set the filter to only pass the records of the classes you
want to debug because that would block other important info, warning,
error and critical messages from other classes. The filter would have
to know about the "global" log level which is in effect and also pass
any messages at that level or higher. It's unfortunate the filter
cannot know the level of the logger or handler it's executing inside
of.
Also logger filters only are applied to the logger they are attached
to, i.e. the logger the message was generated on. They do not get
applied to any ancestor loggers. That means you can't just set a
filter on the root logger. You have to either set the filters on the
handlers or on every logger created.
The filter first checks the level of the message record. If it's
greater than debug it passes it. For debug messages it checks the set
of loggers which have debug messages enabled, if the message record
was generated on one of those loggers it passes the record, otherwise
it blocks it.
The only question is whether you attach the filter to every logger or
to a handful of handlers. The advantage of attaching the filter to
every logger is efficiency, the time spent handling the message can be
short circuited much sooner if the message is filtered earlier in the
process. The advantage of attaching the filter to a handler is
simplicity, you only have to do that when a handler is created, not
every place in the code where a logger is created.
(2) Conditionally set the level of each logger.
...............................................
When loggers are created a check is performed to see if the logger is
in the set of loggers for which debug information is desired, if so
it's level is set to DEBUG, otherwise it's set to the global
level. One has to recall there really isn't a single global level if
you want some handlers to emit info and above, some handlers error and
above, etc. In this case if the logger is not in the set of logger's
emitting debug the logger level should be set to the next increment
above debug level.
A good question to ask would be why not just leave the logger's level
unset if it's not in the set of loggers to be debugged? After all it
will just inherit the root level right? There are two problems with
that. 1) It wold actually inherit the level any ancestor logger and if
an ancestor was set to debug you've effectively turned on debugging
for all children of that ancestor logger. There are times you might
want that behavior, where all your children inherit your level, but
there are many cases where that's not the behavior you want. 2) A more
pernicious problem exists. The logger your handlers are attached to
MUST be set to debug level, otherwise your debug messages will never
reach the handlers for output. Thus if you leave a loggers level unset
and let it inherit it's effective level from an ancestor it might very
well inherit the debug level from the root logger. That means you've
completely negated your attempt to selectively set debug logging on
specific loggers. Bottom line, you really have to set the level on
every logger created if you want fine grained control.
Approach 2 has some distinct performance advantages. First of all
filters are not used, this avoids a whole processing step and extra
filter function calls on every message. Secondly a logger level check
is a simple integer compare which is very efficient. Thirdly the
processing of a message can be short circuited very early in the
processing pipeline, no ancestor loggers will be invoked and no
handlers will be invoked.
The downside is some added complexity at logger creation time. But
this is easily mitigated by using a utility function or method to
create the logger instead of just calling logger.getLogger().
Like every thing else in computer science which approach you take boils
down to a series of trade offs, most around how your code is
organized. You might find it easier to set a filter on just one or two
handlers. It might be easier to modify the configuration during
execution if the logic is centralized in just a filter function, but
don't let that sway you too much because it's trivial to iterate over
every logger and dynamically reset it's log level.
Now at least you've got a basic understanding of how this stuff hangs
together and what your options are. That's not insignificant, when I
was first introduced to logging in Java and Python I found it
bewildering difficult to get it do what I wanted.
John Dennis
iÿÿÿÿNs %(levelname)s %(message)st notsett debugt infot warnt warningt errort criticalt exceptionc C sj t ƒ } xD | D]< } t | d t i ƒ } | t i j o | i | ƒ q q Wt | ƒ } | i ƒ | S( s
Given a iterable of objects containing a logging level return a
ordered list (min to max) of unique levels.
:parameters:
iterable
Iterable yielding objects with a logging level attribute.
:returns:
Ordered list (min to max) of unique levels.
t level( t sett getattrt syst maxintt loggingt NOTSETt addt listt sort( t iterablet levelst objR ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt get_unique_levels s
c C s^ t i } xN | D]F } t | d t i ƒ } | t i j o | | j o
| } qV q q W| S( sC
Given a iterable of objects containing a logging level return the
minimum level. If no levels are defined return maxint.
set of unique levels.
:parameters:
iterable
Iterable yielding objects with a logging level attribute.
:returns:
Ordered list (min to max) of unique levels.
R ( R R R
R
R ( R t min_levelR R ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt get_minimum_level* s
c C sÜ t | t ƒ o y t | ƒ } Wq. q. Xn t | t ƒ o; t i | i ƒ ƒ } | d j o t d | ƒ ‚ n | St | t ƒ o9 | t i j p | t i
j o t d | ƒ ‚ n | St d t | ƒ ƒ ‚ d S( s`
Given a log level either as a string or integer
return a numeric logging level. The following case insensitive
names are recognized::
* notset
* debug
* info
* warn
* warning
* error
* critical
A string containing an integer is also recognized, for example
``"10"`` would map to ``logging.DEBUG``
The integer value must be the range [``logging.NOTSET``,
``logging.CRITICAL``] otherwise a value exception will be raised.
:parameters:
level
basestring or integer, level value to convert
:returns:
integer level value
s unknown log level (%s)s log level (%d) out of ranges- log level must be basestring or int, got (%s)N(
t
isinstancet
basestringt intt log_level_name_mapt gett lowert Nonet
ValueErrorR
R t CRITICALt TypeErrort type( R t result( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt parse_log_level? s
c C s` t | d t | ƒ ƒ } d | t i | i ƒ f } t | t i ƒ o | d | i 7} n | S( sò
Unfortunately the logging Logger and Handler classes do not have a
custom __str__() function which converts the object into a human
readable string representation. This function takes any object
with a level attribute and outputs the objects name with it's
associated level. If a name was never set for the object then it's
repr is used instead.
:parameters:
obj
Object with a logging level attribute
:returns:
string describing the object
t names "%s" [level=%s]s filename="%s"( R
t reprR
t getLevelNameR R t FileHandlert baseFilename( R R% t text( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt logging_obj_strp s
t
LogManagerc B sÝ e Z d Z d e d „ Z d „ Z d „ Z e e e d d ƒZ e d „ Z d „ Z
e d „ Z e e d
„ Z d „ Z
e d „ Z d
„ Z e e d „ Z e d „ Z d „ Z d „ Z d „ Z d „ Z e d „ Z RS( s
This class wraps the functionality in the logging module to
provide an easier to use API for logging while providing advanced
features including a independent namespace. Each application or
library wishing to have it's own logging namespace should instantiate
exactly one instance of this class and use it to manage all it's
logging.
Traditionally (or simplistically) logging was set up with a single
global root logger with output handlers bound to it. The global
root logger (whose name is the empty string) was shared by all
code in a loaded process. The only the global unamed root logger
had a level set on it, all other loggers created inherited this
global level. This can cause conflicts in more complex scenarios
where loaded code wants to maintain it's own logging configuration
independent of whomever loaded it's code. By using only a single
logger level set on the global root logger it was not possible to
have fine grained control over individual logger output. The
pattern seen with this simplistic setup has been frequently copied
despite being clumsy and awkward. The logging module has the tools
available to support a more sophisitcated and useful model, but it
requires an overarching framework to manage. This class provides
such a framework.
The features of this logging manager are:
* Independent logging namespace.
* Simplifed method to create handlers.
* Simple setup for applications with command line args.
* Sophisitcated handler configuration
(e.g. file ownership & permissions)
* Easy fine grained control of logger output
(e.g. turning on debug for just 1 or 2 loggers)
* Holistic management of the interrelationships between
logging components.
* Ability to dynamically adjust logging configuration in
a running process.
An independent namespace is established by creating a independent
root logger for this manager (root_logger_name). This root logger
is a direct child of the global unamed root logger. All loggers
created by this manager will be descendants of this managers root
logger. The managers root logger has it's propagate flag set
to False which means all loggers and handlers created by this
manager will be isolated in the global logging tree.
Log level management:
---------------------
Traditionally loggers inherited their logging level from the root
logger. This was simple but made it impossible to independently
control logging output from different loggers. If you set the root
level to DEBUG you got DEBUG output from every logger in the
system, often overwhelming in it's voluminous output. Many times
you want to turn on debug for just one class (a common idom is to
have one logger per class). To achieve the fine grained control
you can either use filters or set a logging level on every logger
(see the module documentation for the pros and cons). This manager
sets a log level on every logger instead of using level
inheritence because it's more efficient at run time.
Global levels are supported via the verbose and debug flags
setting every logger level to INFO and DEBUG respectively. Fine
grained level control is provided via regular expression matching
on logger names (see `configure()` for the details. For
example if you want to set a debug level for the foo.bar logger
set a regular expression to match it and bind it to the debug
level. Note, the global verbose and debug flags always override
the regular expression level configuration. Do not set these
global flags if you want fine grained control.
The manager maintains the minimum level for all loggers under it's
control and the minimum level for all handlers under it's
control. The reason it does this is because there is no point in
generating debug messages on a logger if there is no handler
defined which will output a debug message. Thus when the level is
set on a logger it takes into consideration the set of handlers
that logger can emit to.
IMPORTANT: Because the manager maintains knowledge about all the
loggers and handlers under it's control it is essential you use
only the managers interface to modify a logger or handler and not
set levels on the objects directly, otherwise the manger will not
know to visit every object under it's control when a configuraiton
changes (see '`LogManager.apply_configuration()`).
Example Usage::
# Create a log managers for use by 'my_app'
log_mgr = LogManager('my_app')
# Create a handler to send error messages to stderr
log_mgr.create_log_handlers([dict(stream=sys.stdout,
level=logging.ERROR)])
# Create logger for a class
class Foo(object):
def __init__(self):
self.log = log_mgr.get_logger(self)
t c C sm h | _ h | _ | | _ | | _ d | _ t | _ t | _ g | _ | i | i ƒ | _
t | i
_ d S( s
Create a new LogManager instance using root_logger_name as the
parent of all loggers maintained by the manager.
Only one log manger should be created for each logging namespace.
:parameters:
root_logger_name
The name of the root logger. All loggers will be prefixed
by this name.
configure_state
Used by clients of the log manager to track the
configuration state, may be any object.
:return:
LogManager instance
R N( t loggerst handlerst configure_statet root_logger_namet
default_levelt FalseR t verboset logger_regexpst
get_loggert root_loggert propagate( t selfR1 R0 ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt __init__ñ s c C s | i S( N( t _default_level( R9 ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt _get_default_level s c C s# t | ƒ } | | _ | i ƒ d S( N( R$ R; t apply_configuration( R9 t valueR ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt _set_default_level s t docsd see log_manager.parse_log_level()` for details on how the level can be specified during assignement.c C s& t | ƒ } | | _ | i | ƒ d S( s
Reset the default logger level, updates all loggers.
Note, the default_level may also be set by assigning to the
default_level attribute but that does not update the configure_state,
this method is provided as a convenience to simultaneously set the
configure_state if so desired.
:parameters:
level
The new default level for the log manager. See
`log_manager.parse_log_level()` for details on how the
level can be specified.
configure_state
If other than None update the log manger's configure_state
variable to this object. Clients of the log manager can
use configure_state to track the state of the log manager.
N( R$ R; R= ( R9 R R0 ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt set_default_level s c C s– d } | d | i 7} | d | i 7} | d t i | i ƒ 7} | d | i 7} | d | i 7} | d t | i ƒ 7} g } | i i ƒ D] } | t
| ƒ q ~ } | i ƒ x | D] } | d | 7} q¼ W| d t | i ƒ 7} g } | i i ƒ D] } | t
| ƒ qÿ ~ } | i ƒ x | D] } | d | 7} q,W| d
t | i
ƒ 7} x4 | i
D]) \ } }
| d | t i |
ƒ f 7} qeW| S( sK
When str() is called on the LogManager output it's state.
R- s root_logger_name: %s
s configure_state: %s
s default_level: %s
s
debug: %s
s verbose: %s
s number of loggers: %d
s %s
s number of handlers: %d
s number of logger regexps: %d
s "%s" => %s
( R1 R0 R
R' R2 R R4 t lenR. t valuesR+ R R/ R5 ( R9 R* t _[1]t xR. t loggert _[2]R/ t handlert regexpR ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt __str__6 s. 0
0
!c
C sK x> d D]6 } | i | ƒ } | d j o t | | | ƒ q q Wd } | i | ƒ } | d j oR y t | ƒ } Wn+ t j
o } t d | | f ƒ ‚ n Xt | | | ƒ n d } | i | ƒ } | d j o/x,| D] } | i } d } t | t ƒ o
| } ni t | t ƒ o? t
| ƒ d j o t d | ƒ ‚ n | d } | d
} n t d t | ƒ | ƒ ‚ t | t ƒ p t d t | ƒ ƒ ‚ n t | t
ƒ o | i | ƒ } n( t | t i ƒ p t d
| ƒ ‚ n | i | g | | ƒ qÞ Wn | i o t i | _ n | i o t i | _ n | i | ƒ d S( sN
The log manager is initialized from key,value pairs in the
config dict. This may be called any time to modify the
logging configuration at run time.
The supported entries in the config dict are:
default_level
The default level applied to a logger when not indivdually
configured. The verbose and debug config items override
the default level. See `log_manager.parse_log_level()` for
details on how the level can be specified.
verbose
Boolean, if True sets default_level to INFO.
debug
Boolean, if True sets default_level to DEBUG.
logger_regexps
List of (regexp, level) tuples. This is a an ordered list
regular expressions used to match against a logger name to
configure the logger's level. The first regexp in the
sequence which matches the logger name will use the the
level bound to that regexp to set the logger's level. If
no regexp matches the logger name then the logger will be
assigned the default_level.
The regular expression comparision is performed with the
re.search() function which means the match can be located
anywhere in the name string (as opposed to the start of
the string). Do not forget to escape regular
expression metacharacters when appropriate. For example
dot ('.') is used to seperate loggers in a logging
hierarchy path (e.g. a.b.c)
Examples::
# To match exactly the logger a.b.c and set it to DEBUG:
logger_regexps = [(r'^a\.b\.c$', 'debug')]
# To match any child of a.b and set it to INFO:
logger_regexps = [(r'^a\.b\..*', 'info')]
# To match any leaf logger with the name c and set it to level 5:
logger_regexps = [(r'\.c$', 5)]
handlers
List of handler config dicts or (config, logger)
tuples. See `create_log_handlers()` for details
of a hanlder config.
The simple form where handlers is a list of dicts each
handler is bound to the log mangers root logger (see
`create_log_handlers()` optional ``logger``
parameter). If you want to bind each handler to a specific
logger other then root handler then group the handler config
with a logger in a (config, logger) tuple. The logger may be
either a logger name or a logger instance. The following are
all valid methods of passing handler configuration.::
# List of 2 config dicts; both handlers bound to root logger
[{}, {}]
# List of 2 tuples; first handler bound to logger_name1
# by name, second bound to logger2 by object.
[({}, 'logger_name1'), ({}, logger2']
# List of 1 dict, 1 tuple; first bound to root logger,
# second bound to logger_name by name
[{}, ({}, 'logger_name']
:parameters:
config
Dict of pairs describing the configuration.
configure_state
If other than None update the log manger's configure_state
variable to this object. Clients of the log manager can
use configure_state to track the state of the log manager.
R R4 R5 R2 s could not set %s (%s)R/ i s1 handler tuple must have exactly 2 items, got "%s"i i s> expected dict or tuple for handler item, got "%s", handlers=%ss* expected dict for handler config, got "%s"s, expected logger name or logger object in %sN( s debugs verboses logger_regexps( R R t setattrR$ t ExceptionR R7 R t dictt tupleRB R! R" R R6 R
t Loggert create_log_handlersR4 t INFOR2 R t DEBUGR= (
R9 t configR0 t attrR> R t eR/ t itemRF ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt configureS sR N
c C sÛ | d j o
| i } n g } xO| D]G} | i d ƒ } | o| i d ƒ o t d | ƒ ‚ n t i i | ƒ } | i d d ƒ } t i | | ƒ } | i d ƒ }
|
d j o d | }
n |
| _
d } } | i d ƒ }
| i d ƒ } |
d j oZ t |
t ƒ o t
i |
ƒ } | i } q_t |
t ƒ o
|
} q_t d
|
ƒ ‚ n | d j oZ t | t ƒ o t
i | ƒ } | i } qÆt | t ƒ o
| } qÆt d | ƒ ‚ n | d j p
| d j oE | d j o
d } n | d j o
d } n t i | | | ƒ n | i d
ƒ } | d j o t i | | ƒ qËns | i d ƒ } | d j o t d | ƒ ‚ n t i | ƒ } | i d ƒ }
|
d j o d | }
n |
| _
| i | ƒ | i d t ƒ } | i d d ƒ } t i | | ƒ } | i d t i ƒ } t | t ƒ ol h t i d 6t i d 6t i d 6t i d 6t i d 6i | i ƒ ƒ } | d j o t d | ƒ ‚ qÌn. t | ƒ o
| } n t d t | ƒ ƒ ‚ | | _ | i | ƒ | i d ƒ } | d j oI y t! | ƒ } WqGt" j
o& } t# i$ d | | f IJd } qGXn | d j o
| i% } n | i& | ƒ q' WxU | D]M } | i
| i' j o t d | i
ƒ ‚ n | i( | ƒ | | i' | i
time.localtime
'localtime' => time.localtime
'gmt' => time.gmtime
'gmtime' => time.gmtime
'utc' => time.gmtime
datefmt
Use the specified time.strftime date/time format when
formatting a timestamp via the %(asctime)s format
substitution. The timestamp is first converted using the
time_zone_converter to either local or UTC
level
Set the handler logger level to the specified level. May be
one of the following strings: 'debug', 'info', 'warn',
'warning', 'error', 'critical' or any of the logging level
constants. Thus level='debug' is equivalent to
level=logging.DEBUG. Defaults to self.default_level.
File handler keys:
------------------
filemode
Specifies the mode to open the file. Defaults to 'a' for
append, use 'w' for write.
permission
Set the permission bits on the file (i.e. chmod).
Must be a valid integer (e.g. 0660 for rw-rw----)
user
Set the user owning the file. May be either a numeric uid or a
basestring with a user name in the passwd file.
group
Set the group associated with the file, May be either a
numeric gid or a basestring with a group name in the groups
file.
Examples:
---------
The following shows how to set two handlers, one for a file
(ipa.log) at the debug log level and a second handler set to
stdout (e.g. console) at the info log level. (One handler sets it
level with a simple name, the other with a logging constant just
to illustrate the flexibility) ::
# Get a root logger
log_mgr = LogManger('my_app')
# Create the handlers
log_mgr.create_log_handlers([dict(filename='my_app.log',
level='info',
user='root',
group='root',
permission=0600,
time_zone_converter='utc',
datefmt='%Y-%m-%dT%H:%M:%SZ', # ISO 8601
format='<%(levelname)s> [%(asctime)s] module=%(name)s "%(message)s"'),
dict(stream=sys.stdout,
level=logging.ERROR,
format='%(levelname)s: %(message)s')])
# Create a logger for my_app.foo.bar
foo_bar_log = log_mgr.get_logger('foo.bar')
root_logger.info("Ready to process requests")
foo_bar_log.error("something went boom")
In the file my_app.log you would see::
[2011-10-26T01:39:00Z] module=my_app "Ready to process requests"
[2011-10-26T01:39:00Z] module=may_app.foo.bar "something went boom"
On the console you would see::
ERROR: something went boom
:parameters:
configs
Sequence of dicts (any iterable yielding a dict). Each
dict creates one handler and contains the configuration
parameters used to create that handler.
logger
If unspecified the handlers will be attached to the
LogManager.root_logger, otherwise the handlers will be
attached to the specified logger.
configure_state
If other than None update the log manger's configure_state
variable to this object. Clients of the log manager can
use configure_state to track the state of the log manager.
:return:
The list of created handers.
t filenamet streamsL both filename and stream are specified, must be one or the other, config: %st filemodet aR% s file:%st usert groups" user (%s) is not int or basestrings# group (%s) is not int or basestringiÿÿÿÿt
permissions/ neither file nor stream specified in config: %ss stream:%st formatt datefmtt time_zone_convertert localt localtimet gmtt gmtimet utcs% invalid time_zone_converter name (%s)s: time_zone_converter must be basestring or callable, not %sR s) could not set handler log level "%s" (%s)s handler "%s" already existsN(* R R7 R t has_keyR t ost patht abspathR
R( R% R R t pwdt getpwnamt pw_uidR R! t pw_gidt chownt chmodt
StreamHandlert appendt LOGGING_DEFAULT_FORMATt Formattert timeRc Re R t callableR" t convertert setFormatterR$ RL R t stderrR2 t setLevelR/ t
addHandlerR= ( R9 t configsRF R0 R/ t cfgRX Ri RZ RH R% t uidt gidR\ R] t pwR^ RY R_ R` t formatterRa Rw R RU ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyRP Ò s° ž
c C s7 | i i | ƒ } | d j o t d | ƒ ‚ n | S( s
Given a handler name return the handler object associated with
it.
:parameters:
handler_name
Name of the handler to look-up.
:returns:
The handler object associated with the handler name.
s handler "%s" is not definedN( R/ R R t KeyError( R9 t handler_nameRH ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt get_handlerâ s
c C sB | i | ƒ } t | ƒ } | i } | i | ƒ | i | ƒ | S( s}
Given a handler name, set the handler's level, return previous level.
:parameters:
handler_name
Name of the handler to look-up.
level
The new level for the handler. See
`log_manager.parse_log_level()` for details on how the
level can be specified.
configure_state
If other than None update the log manger's configure_state
variable to this object. Clients of the log manager can
use configure_state to track the state of the log manager.
:returns:
The handler's previous level
( R„ R$ R Rz R= ( R9 Rƒ R R0 RH t
prev_level( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt set_handler_leveló s
c C sÅ t | t ƒ o | i | ƒ } n^ t | t i ƒ o4 | | i i ƒ j o t d t | ƒ ƒ ‚ q€ n t d t
| ƒ ƒ ‚ g } x8 | i i ƒ D]' } | | i j o | i | ƒ q– q– W| S( sþ
Given a handler return a list of loggers that hander is bound to.
:parameters:
handler
The name of a handler or a handler object.
:returns:
List of loggers with the handler is bound to.
s/ handler "%s" is not managed by this log managers4 handler must be basestring or Handler object, got %s(
R R R„ R
t HandlerR/ RC R R+ R! R" R. Rr ( R9 RH R. RF ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt get_loggers_with_handler
s
c C s4 t | t ƒ o | i | ƒ } n. t | t i ƒ p t d t | ƒ ƒ ‚ n | i } | d j o t d t
| ƒ ƒ ‚ n | i | ƒ } | d j o, x | D] } | i | ƒ q£ W| i
| =n\ | | j o t d | t
| ƒ f ƒ ‚ n | i | ƒ t | ƒ d j o | i
| =n | i | ƒ d S( s½
Remove the named handler. If logger is unspecified the handler
will be removed from all managed loggers, otherwise it will be
removed from only the specified logger.
:parameters:
handler
The name of the handler to be removed or the handler object.
logger
If unspecified the handler is removed from all loggers,
otherwise the handler is removed from only this logger.
configure_state
If other than None update the log manger's configure_state
variable to this object. Clients of the log manager can
use configure_state to track the state of the log manager.
s4 handler must be basestring or Handler object, got %ss! handler "%s" does not have a names( handler "%s" is not bound to logger "%s"i N( R R R„ R
R‡ R! R" R% R R R+ Rˆ t
removeHandlerR/ RB R= ( R9 RH RF R0 Rƒ R. ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt remove_handler* s(
c C sE | d j o
| | _ n x$ | i i ƒ D] } | i | ƒ q* Wd S( s˜
Using the log manager's internal configuration state apply the
configuration to all the objects managed by the log manager.
:parameters:
configure_state
If other than None update the log manger's configure_state
variable to this object. Clients of the log manager can
use configure_state to track the state of the log manager.
N( R R0 R. RC t _set_configured_logger_level( R9 R0 RF ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyR= U s
c C sQ | i } x5 | i D]* \ } } t i | | ƒ o | } Pq q Wt | ƒ } | S( sÐ
Given a logger name return it's level as defined by the
`LogManager` configuration.
:parameters:
name
logger name
:returns:
log level
( R2 R5 t ret searchR$ ( R9 R% R RI t config_level( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt get_configured_logger_levelf s
c C sZ t ƒ } xJ | oB x | i D] } | i | ƒ q W| i o
| i } q d } q W| S( sê
Return the set of unique handlers visible to this logger.
:parameters:
logger
The logger whose visible and enabled handlers will be returned.
:return:
Set of handlers
N( R R/ R R8 t parentR ( R9 RF R/ RH ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt get_logger_handlersz s
c C s | i | ƒ } t | ƒ } | S( sN
Return the minimum handler level of all the handlers the
logger is exposed to.
:parameters:
logger
The logger whose handlers will be examined.
:return:
The minimum of all the handler's levels. If no
handlers are defined sys.maxint will be returned.
( R‘ R ( R9 RF R/ R ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt$ get_minimum_handler_level_for_logger s c C sI | i | i ƒ } | i | ƒ } | | j o
| } n | i | ƒ | S( s‰
Based on the current configuration maintained by the log
manager set this logger's level.
If the level specified for this logger by the configuration is
less than the minimum level supported by the output handlers
the logger is exposed to then adjust the logger's level higher
to the minimum handler level. This is a performance
optimization, no point in emitting a log message if no
handlers will ever output it.
:parameters:
logger
The logger whose level is being configured.
:return:
The level actually set on the logger.
( R R% R’ Rz ( R9 RF R t minimum_handler_level( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyR‹ ¢ s
c C s• t } t | t ƒ o
| } n t } d | i | i i f } | | i j o
| } n | i d | } | i i | ƒ } | d j o- t i | ƒ } | | i | <| i
| ƒ n | oÔ | oÍ t | d d ƒ d j o´ t | d | ƒ d } t | | ƒ o t d | t | ƒ f ƒ ‚ n t | | | ƒ x[ t D]O } t | | ƒ o t d | t | ƒ f ƒ ‚ n t | | t | | ƒ ƒ q:Wn | S( s
Return the logger for an object or a name. If the logger
already exists return the existing instance otherwise create
the logger.
The who parameter may be either a name or an object.
Loggers are identified by a name but because loggers are
usually bound to a class this method is optimized to handle
that case. If who is an object:
* The name object's module name (dot seperated) and the
object's class name.
* Optionally the logging output methods can be bound to the
object if bind_logger_names is True.
Otherwise if who is a basestring it is used as the logger
name.
In all instances the root_logger_name is prefixed to every
logger created by the manager.
:parameters:
who
If a basestring then use this as the logger name,
prefixed with the root_logger_name. Otherwise who is treated
as a class instance. The logger name is formed by prepending
the root_logger_name to the module name and then appending the
class name. All name components are dot seperated. Thus if the
root_logger_name is 'my_app', the class is ParseFileConfig
living in the config.parsers module the logger name will be:
``my_app.config.parsers.ParseFileConfig``.
bind_logger_names
If true the class instance will have the following bound
to it: ``log``, ``debug()``, ``info()``, ``warning()``,
``error()``, ``exception()``, ``critical()``. Where log is
the logger object and the others are the loggers output
methods. This is a convenience which allows you emit
logging messages directly, for example::
self.debug('%d names defined', self.num_names).
:return:
The logger matching the name indicated by who. If the
logger pre-existed return that instance otherwise create the
named logger return it.
s %s.%st .t
__log_managert logs %s is already bound to %sN( R3 R R t Truet
__module__t __class__t __name__R1 R. R R R
t getLoggerR‹ R
RK t hasattrR R& t logger_method_names( R9 t whot bind_logger_namest is_objectt obj_namet logger_nameRF t method( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyR6 ¼ s2 1
' !( Rš R˜ t __doc__R R: R< R? t propertyR2 RA RJ RW RP R„ R† Rˆ RŠ R= R R‘ R’ R‹ R3 R6 ( ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyR, … s* k" ÿ + ( s debugs infoR s errorR R ( R¤ R Rh Rk R
RΠRu Rs R RR RQ t WARNINGt ERRORR R t
log_levelsR R R R$ R+ t objectR, ( ( ( s9 /usr/lib/python2.6/site-packages/ipapython/log_manager.pyt ö s,
$ 1