blob: 0119e0cf6539b64aba75672b46b2f2745433c3e9 [file] [log] [blame]
Georg Brandl8ec7f652007-08-15 14:28:01 +00001:mod:`logging` --- Logging facility for Python
2==============================================
3
4.. module:: logging
Vinay Sajip5dbca9c2011-04-08 11:40:38 +01005 :synopsis: Flexible event logging system for applications.
Georg Brandl8ec7f652007-08-15 14:28:01 +00006
7
8.. moduleauthor:: Vinay Sajip <vinay_sajip@red-dove.com>
9.. sectionauthor:: Vinay Sajip <vinay_sajip@red-dove.com>
10
11
Georg Brandl8ec7f652007-08-15 14:28:01 +000012.. index:: pair: Errors; logging
13
Vinay Sajip5dbca9c2011-04-08 11:40:38 +010014.. sidebar:: Important
15
16 This page contains the API reference information. For tutorial
17 information and discussion of more advanced topics, see
18
19 * :ref:`Basic Tutorial <logging-basic-tutorial>`
20 * :ref:`Advanced Tutorial <logging-advanced-tutorial>`
21 * :ref:`Logging Cookbook <logging-cookbook>`
22
23
Georg Brandl8ec7f652007-08-15 14:28:01 +000024.. versionadded:: 2.3
25
Vinay Sajip5dbca9c2011-04-08 11:40:38 +010026This module defines functions and classes which implement a flexible event
27logging system for applications and libraries.
Georg Brandlc37f2882007-12-04 17:46:27 +000028
29The key benefit of having the logging API provided by a standard library module
30is that all Python modules can participate in logging, so your application log
Vinay Sajip5dbca9c2011-04-08 11:40:38 +010031can include your own messages integrated with messages from third-party
32modules.
Georg Brandlc37f2882007-12-04 17:46:27 +000033
Vinay Sajip5dbca9c2011-04-08 11:40:38 +010034The module provides a lot of functionality and flexibility. If you are
35unfamiliar with logging, the best way to get to grips with it is to see the
36tutorials (see the links on the right).
Georg Brandlc37f2882007-12-04 17:46:27 +000037
Vinay Sajip5dbca9c2011-04-08 11:40:38 +010038The basic classes defined by the module, together with their functions, are
39listed below.
Georg Brandlc37f2882007-12-04 17:46:27 +000040
Vinay Sajip5dbca9c2011-04-08 11:40:38 +010041* Loggers expose the interface that application code directly uses.
42* Handlers send the log records (created by loggers) to the appropriate
43 destination.
44* Filters provide a finer grained facility for determining which log records
45 to output.
46* Formatters specify the layout of log records in the final output.
Georg Brandlc37f2882007-12-04 17:46:27 +000047
Georg Brandlc37f2882007-12-04 17:46:27 +000048
Vinay Sajip5dbca9c2011-04-08 11:40:38 +010049.. _logger:
Georg Brandlc37f2882007-12-04 17:46:27 +000050
Vinay Sajip5dbca9c2011-04-08 11:40:38 +010051Logger Objects
Georg Brandlc37f2882007-12-04 17:46:27 +000052--------------
53
Vinay Sajip5dbca9c2011-04-08 11:40:38 +010054Loggers have the following attributes and methods. Note that Loggers are never
55instantiated directly, but always through the module-level function
56``logging.getLogger(name)``.
Georg Brandl8ec7f652007-08-15 14:28:01 +000057
Vinay Sajip5dbca9c2011-04-08 11:40:38 +010058.. class:: Logger
Georg Brandl8ec7f652007-08-15 14:28:01 +000059
Vinay Sajip5dbca9c2011-04-08 11:40:38 +010060.. attribute:: Logger.propagate
Georg Brandl8ec7f652007-08-15 14:28:01 +000061
Vinay Sajip36398072011-11-23 08:51:35 +000062 If this evaluates to true, logging messages are passed by this logger and by
63 its child loggers to the handlers of higher level (ancestor) loggers.
64 Messages are passed directly to the ancestor loggers' handlers - neither the
65 level nor filters of the ancestor loggers in question are considered.
66
67 If this evaluates to false, logging messages are not passed to the handlers
68 of ancestor loggers.
69
Benjamin Petersonc016f462011-12-30 13:47:25 -060070 The constructor sets this attribute to ``True``.
Vinay Sajip89e1ae22010-09-17 10:09:04 +000071
72
Vinay Sajip5dbca9c2011-04-08 11:40:38 +010073.. method:: Logger.setLevel(lvl)
74
75 Sets the threshold for this logger to *lvl*. Logging messages which are less
76 severe than *lvl* will be ignored. When a logger is created, the level is set to
77 :const:`NOTSET` (which causes all messages to be processed when the logger is
78 the root logger, or delegation to the parent when the logger is a non-root
79 logger). Note that the root logger is created with level :const:`WARNING`.
80
81 The term 'delegation to the parent' means that if a logger has a level of
82 NOTSET, its chain of ancestor loggers is traversed until either an ancestor with
83 a level other than NOTSET is found, or the root is reached.
84
85 If an ancestor is found with a level other than NOTSET, then that ancestor's
86 level is treated as the effective level of the logger where the ancestor search
87 began, and is used to determine how a logging event is handled.
88
89 If the root is reached, and it has a level of NOTSET, then all messages will be
90 processed. Otherwise, the root's level will be used as the effective level.
91
92
93.. method:: Logger.isEnabledFor(lvl)
94
95 Indicates if a message of severity *lvl* would be processed by this logger.
96 This method checks first the module-level level set by
97 ``logging.disable(lvl)`` and then the logger's effective level as determined
98 by :meth:`getEffectiveLevel`.
99
100
101.. method:: Logger.getEffectiveLevel()
102
103 Indicates the effective level for this logger. If a value other than
104 :const:`NOTSET` has been set using :meth:`setLevel`, it is returned. Otherwise,
105 the hierarchy is traversed towards the root until a value other than
106 :const:`NOTSET` is found, and that value is returned.
107
108
109.. method:: Logger.getChild(suffix)
110
111 Returns a logger which is a descendant to this logger, as determined by the suffix.
112 Thus, ``logging.getLogger('abc').getChild('def.ghi')`` would return the same
113 logger as would be returned by ``logging.getLogger('abc.def.ghi')``. This is a
114 convenience method, useful when the parent logger is named using e.g. ``__name__``
115 rather than a literal string.
116
117 .. versionadded:: 2.7
118
119
120.. method:: Logger.debug(msg, *args, **kwargs)
121
122 Logs a message with level :const:`DEBUG` on this logger. The *msg* is the
123 message format string, and the *args* are the arguments which are merged into
124 *msg* using the string formatting operator. (Note that this means that you can
125 use keywords in the format string, together with a single dictionary argument.)
126
127 There are two keyword arguments in *kwargs* which are inspected: *exc_info*
128 which, if it does not evaluate as false, causes exception information to be
129 added to the logging message. If an exception tuple (in the format returned by
130 :func:`sys.exc_info`) is provided, it is used; otherwise, :func:`sys.exc_info`
131 is called to get the exception information.
132
133 The second keyword argument is *extra* which can be used to pass a
134 dictionary which is used to populate the __dict__ of the LogRecord created for
135 the logging event with user-defined attributes. These custom attributes can then
136 be used as you like. For example, they could be incorporated into logged
137 messages. For example::
138
139 FORMAT = '%(asctime)-15s %(clientip)s %(user)-8s %(message)s'
140 logging.basicConfig(format=FORMAT)
141 d = { 'clientip' : '192.168.0.1', 'user' : 'fbloggs' }
142 logger = logging.getLogger('tcpserver')
143 logger.warning('Protocol problem: %s', 'connection reset', extra=d)
144
145 would print something like ::
146
147 2006-02-08 22:20:02,165 192.168.0.1 fbloggs Protocol problem: connection reset
148
149 The keys in the dictionary passed in *extra* should not clash with the keys used
150 by the logging system. (See the :class:`Formatter` documentation for more
151 information on which keys are used by the logging system.)
152
153 If you choose to use these attributes in logged messages, you need to exercise
154 some care. In the above example, for instance, the :class:`Formatter` has been
155 set up with a format string which expects 'clientip' and 'user' in the attribute
156 dictionary of the LogRecord. If these are missing, the message will not be
157 logged because a string formatting exception will occur. So in this case, you
158 always need to pass the *extra* dictionary with these keys.
159
160 While this might be annoying, this feature is intended for use in specialized
161 circumstances, such as multi-threaded servers where the same code executes in
162 many contexts, and interesting conditions which arise are dependent on this
163 context (such as remote client IP address and authenticated user name, in the
164 above example). In such circumstances, it is likely that specialized
165 :class:`Formatter`\ s would be used with particular :class:`Handler`\ s.
166
167
168.. method:: Logger.info(msg, *args, **kwargs)
169
170 Logs a message with level :const:`INFO` on this logger. The arguments are
171 interpreted as for :meth:`debug`.
172
173
174.. method:: Logger.warning(msg, *args, **kwargs)
175
176 Logs a message with level :const:`WARNING` on this logger. The arguments are
177 interpreted as for :meth:`debug`.
178
179
180.. method:: Logger.error(msg, *args, **kwargs)
181
182 Logs a message with level :const:`ERROR` on this logger. The arguments are
183 interpreted as for :meth:`debug`.
184
185
186.. method:: Logger.critical(msg, *args, **kwargs)
187
188 Logs a message with level :const:`CRITICAL` on this logger. The arguments are
189 interpreted as for :meth:`debug`.
190
191
192.. method:: Logger.log(lvl, msg, *args, **kwargs)
193
194 Logs a message with integer level *lvl* on this logger. The other arguments are
195 interpreted as for :meth:`debug`.
196
197
198.. method:: Logger.exception(msg, *args)
199
200 Logs a message with level :const:`ERROR` on this logger. The arguments are
201 interpreted as for :meth:`debug`. Exception info is added to the logging
202 message. This method should only be called from an exception handler.
203
204
205.. method:: Logger.addFilter(filt)
206
207 Adds the specified filter *filt* to this logger.
208
209
210.. method:: Logger.removeFilter(filt)
211
212 Removes the specified filter *filt* from this logger.
213
214
215.. method:: Logger.filter(record)
216
217 Applies this logger's filters to the record and returns a true value if the
218 record is to be processed.
219
220
221.. method:: Logger.addHandler(hdlr)
222
223 Adds the specified handler *hdlr* to this logger.
224
225
226.. method:: Logger.removeHandler(hdlr)
227
228 Removes the specified handler *hdlr* from this logger.
229
230
231.. method:: Logger.findCaller()
232
233 Finds the caller's source filename and line number. Returns the filename, line
234 number and function name as a 3-element tuple.
235
236 .. versionchanged:: 2.4
237 The function name was added. In earlier versions, the filename and line
238 number were returned as a 2-element tuple.
239
240.. method:: Logger.handle(record)
241
242 Handles a record by passing it to all handlers associated with this logger and
243 its ancestors (until a false value of *propagate* is found). This method is used
244 for unpickled records received from a socket, as well as those created locally.
245 Logger-level filtering is applied using :meth:`~Logger.filter`.
246
247
248.. method:: Logger.makeRecord(name, lvl, fn, lno, msg, args, exc_info, func=None, extra=None)
249
250 This is a factory method which can be overridden in subclasses to create
251 specialized :class:`LogRecord` instances.
252
253 .. versionchanged:: 2.5
254 *func* and *extra* were added.
255
256.. _handler:
257
258Handler Objects
Vinay Sajipb5902e62009-01-15 22:48:13 +0000259---------------
260
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100261Handlers have the following attributes and methods. Note that :class:`Handler`
262is never instantiated directly; this class acts as a base for more useful
263subclasses. However, the :meth:`__init__` method in subclasses needs to call
264:meth:`Handler.__init__`.
Georg Brandl8ec7f652007-08-15 14:28:01 +0000265
Georg Brandl8ec7f652007-08-15 14:28:01 +0000266
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100267.. method:: Handler.__init__(level=NOTSET)
Vinay Sajipb1a15e42009-01-15 23:04:47 +0000268
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100269 Initializes the :class:`Handler` instance by setting its level, setting the list
270 of filters to the empty list and creating a lock (using :meth:`createLock`) for
271 serializing access to an I/O mechanism.
Vinay Sajipc2211ad2009-01-10 19:22:57 +0000272
Georg Brandl8ec7f652007-08-15 14:28:01 +0000273
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100274.. method:: Handler.createLock()
Georg Brandl8ec7f652007-08-15 14:28:01 +0000275
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100276 Initializes a thread lock which can be used to serialize access to underlying
277 I/O functionality which may not be threadsafe.
Georg Brandl8ec7f652007-08-15 14:28:01 +0000278
Georg Brandl8ec7f652007-08-15 14:28:01 +0000279
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100280.. method:: Handler.acquire()
Georg Brandl8ec7f652007-08-15 14:28:01 +0000281
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100282 Acquires the thread lock created with :meth:`createLock`.
Georg Brandl8ec7f652007-08-15 14:28:01 +0000283
Georg Brandl8ec7f652007-08-15 14:28:01 +0000284
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100285.. method:: Handler.release()
Georg Brandl8ec7f652007-08-15 14:28:01 +0000286
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100287 Releases the thread lock acquired with :meth:`acquire`.
Georg Brandl8ec7f652007-08-15 14:28:01 +0000288
Vinay Sajipc2211ad2009-01-10 19:22:57 +0000289
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100290.. method:: Handler.setLevel(lvl)
Vinay Sajip213faca2008-12-03 23:22:58 +0000291
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100292 Sets the threshold for this handler to *lvl*. Logging messages which are less
293 severe than *lvl* will be ignored. When a handler is created, the level is set
294 to :const:`NOTSET` (which causes all messages to be processed).
Vinay Sajip213faca2008-12-03 23:22:58 +0000295
Georg Brandl8ec7f652007-08-15 14:28:01 +0000296
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100297.. method:: Handler.setFormatter(form)
Georg Brandl8ec7f652007-08-15 14:28:01 +0000298
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100299 Sets the :class:`Formatter` for this handler to *form*.
Georg Brandl8ec7f652007-08-15 14:28:01 +0000300
Georg Brandl8ec7f652007-08-15 14:28:01 +0000301
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100302.. method:: Handler.addFilter(filt)
303
304 Adds the specified filter *filt* to this handler.
305
306
307.. method:: Handler.removeFilter(filt)
308
309 Removes the specified filter *filt* from this handler.
310
311
312.. method:: Handler.filter(record)
313
314 Applies this handler's filters to the record and returns a true value if the
315 record is to be processed.
316
317
318.. method:: Handler.flush()
319
320 Ensure all logging output has been flushed. This version does nothing and is
321 intended to be implemented by subclasses.
322
323
324.. method:: Handler.close()
325
326 Tidy up any resources used by the handler. This version does no output but
327 removes the handler from an internal list of handlers which is closed when
328 :func:`shutdown` is called. Subclasses should ensure that this gets called
329 from overridden :meth:`close` methods.
330
331
332.. method:: Handler.handle(record)
333
334 Conditionally emits the specified logging record, depending on filters which may
335 have been added to the handler. Wraps the actual emission of the record with
336 acquisition/release of the I/O thread lock.
337
338
339.. method:: Handler.handleError(record)
340
341 This method should be called from handlers when an exception is encountered
342 during an :meth:`emit` call. By default it does nothing, which means that
343 exceptions get silently ignored. This is what is mostly wanted for a logging
344 system - most users will not care about errors in the logging system, they are
345 more interested in application errors. You could, however, replace this with a
346 custom handler if you wish. The specified record is the one which was being
347 processed when the exception occurred.
348
349
350.. method:: Handler.format(record)
351
352 Do formatting for a record - if a formatter is set, use it. Otherwise, use the
353 default formatter for the module.
354
355
356.. method:: Handler.emit(record)
357
358 Do whatever it takes to actually log the specified logging record. This version
359 is intended to be implemented by subclasses and so raises a
360 :exc:`NotImplementedError`.
361
362For a list of handlers included as standard, see :mod:`logging.handlers`.
363
364.. _formatter-objects:
365
366Formatter Objects
367-----------------
368
369.. currentmodule:: logging
370
371:class:`Formatter` objects have the following attributes and methods. They are
372responsible for converting a :class:`LogRecord` to (usually) a string which can
373be interpreted by either a human or an external system. The base
374:class:`Formatter` allows a formatting string to be specified. If none is
375supplied, the default value of ``'%(message)s'`` is used.
376
377A Formatter can be initialized with a format string which makes use of knowledge
378of the :class:`LogRecord` attributes - such as the default value mentioned above
379making use of the fact that the user's message and arguments are pre-formatted
380into a :class:`LogRecord`'s *message* attribute. This format string contains
381standard Python %-style mapping keys. See section :ref:`string-formatting`
382for more information on string formatting.
383
384The useful mapping keys in a :class:`LogRecord` are given in the section on
385:ref:`logrecord-attributes`.
386
387
388.. class:: Formatter(fmt=None, datefmt=None)
389
390 Returns a new instance of the :class:`Formatter` class. The instance is
391 initialized with a format string for the message as a whole, as well as a
392 format string for the date/time portion of a message. If no *fmt* is
393 specified, ``'%(message)s'`` is used. If no *datefmt* is specified, the
394 ISO8601 date format is used.
395
396 .. method:: format(record)
397
398 The record's attribute dictionary is used as the operand to a string
399 formatting operation. Returns the resulting string. Before formatting the
400 dictionary, a couple of preparatory steps are carried out. The *message*
401 attribute of the record is computed using *msg* % *args*. If the
402 formatting string contains ``'(asctime)'``, :meth:`formatTime` is called
403 to format the event time. If there is exception information, it is
404 formatted using :meth:`formatException` and appended to the message. Note
405 that the formatted exception information is cached in attribute
406 *exc_text*. This is useful because the exception information can be
407 pickled and sent across the wire, but you should be careful if you have
408 more than one :class:`Formatter` subclass which customizes the formatting
409 of exception information. In this case, you will have to clear the cached
410 value after a formatter has done its formatting, so that the next
411 formatter to handle the event doesn't use the cached value but
412 recalculates it afresh.
413
414
415 .. method:: formatTime(record, datefmt=None)
416
417 This method should be called from :meth:`format` by a formatter which
418 wants to make use of a formatted time. This method can be overridden in
419 formatters to provide for any specific requirement, but the basic behavior
420 is as follows: if *datefmt* (a string) is specified, it is used with
421 :func:`time.strftime` to format the creation time of the
422 record. Otherwise, the ISO8601 format is used. The resulting string is
423 returned.
424
Vinay Sajipad52cb22011-06-13 14:59:36 +0100425 This function uses a user-configurable function to convert the creation
426 time to a tuple. By default, :func:`time.localtime` is used; to change
427 this for a particular formatter instance, set the ``converter`` attribute
428 to a function with the same signature as :func:`time.localtime` or
429 :func:`time.gmtime`. To change it for all formatters, for example if you
430 want all logging times to be shown in GMT, set the ``converter``
431 attribute in the ``Formatter`` class.
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100432
433 .. method:: formatException(exc_info)
434
435 Formats the specified exception information (a standard exception tuple as
436 returned by :func:`sys.exc_info`) as a string. This default implementation
437 just uses :func:`traceback.print_exception`. The resulting string is
438 returned.
439
440.. _filter:
441
442Filter Objects
443--------------
444
445``Filters`` can be used by ``Handlers`` and ``Loggers`` for more sophisticated
446filtering than is provided by levels. The base filter class only allows events
447which are below a certain point in the logger hierarchy. For example, a filter
448initialized with 'A.B' will allow events logged by loggers 'A.B', 'A.B.C',
449'A.B.C.D', 'A.B.D' etc. but not 'A.BB', 'B.A.B' etc. If initialized with the
450empty string, all events are passed.
451
452
453.. class:: Filter(name='')
454
455 Returns an instance of the :class:`Filter` class. If *name* is specified, it
456 names a logger which, together with its children, will have its events allowed
457 through the filter. If *name* is the empty string, allows every event.
458
459
460 .. method:: filter(record)
461
462 Is the specified record to be logged? Returns zero for no, nonzero for
463 yes. If deemed appropriate, the record may be modified in-place by this
464 method.
465
466Note that filters attached to handlers are consulted whenever an event is
467emitted by the handler, whereas filters attached to loggers are consulted
468whenever an event is logged to the handler (using :meth:`debug`, :meth:`info`,
469etc.) This means that events which have been generated by descendant loggers
470will not be filtered by a logger's filter setting, unless the filter has also
471been applied to those descendant loggers.
472
473You don't actually need to subclass ``Filter``: you can pass any instance
474which has a ``filter`` method with the same semantics.
475
476Although filters are used primarily to filter records based on more
477sophisticated criteria than levels, they get to see every record which is
478processed by the handler or logger they're attached to: this can be useful if
479you want to do things like counting how many records were processed by a
480particular logger or handler, or adding, changing or removing attributes in
481the LogRecord being processed. Obviously changing the LogRecord needs to be
482done with some care, but it does allow the injection of contextual information
483into logs (see :ref:`filters-contextual`).
484
485.. _log-record:
486
487LogRecord Objects
488-----------------
489
490:class:`LogRecord` instances are created automatically by the :class:`Logger`
491every time something is logged, and can be created manually via
492:func:`makeLogRecord` (for example, from a pickled event received over the
493wire).
494
495
496.. class:: LogRecord(name, level, pathname, lineno, msg, args, exc_info, func=None)
497
498 Contains all the information pertinent to the event being logged.
499
500 The primary information is passed in :attr:`msg` and :attr:`args`, which
501 are combined using ``msg % args`` to create the :attr:`message` field of the
502 record.
503
504 :param name: The name of the logger used to log the event represented by
505 this LogRecord.
506 :param level: The numeric level of the logging event (one of DEBUG, INFO etc.)
Vinay Sajipad52cb22011-06-13 14:59:36 +0100507 Note that this is converted to *two* attributes of the LogRecord:
508 ``levelno`` for the numeric value and ``levelname`` for the
509 corresponding level name.
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100510 :param pathname: The full pathname of the source file where the logging call
511 was made.
512 :param lineno: The line number in the source file where the logging call was
513 made.
514 :param msg: The event description message, possibly a format string with
515 placeholders for variable data.
516 :param args: Variable data to merge into the *msg* argument to obtain the
517 event description.
518 :param exc_info: An exception tuple with the current exception information,
519 or *None* if no exception information is available.
520 :param func: The name of the function or method from which the logging call
521 was invoked.
522
523 .. versionchanged:: 2.5
524 *func* was added.
525
526 .. method:: getMessage()
527
528 Returns the message for this :class:`LogRecord` instance after merging any
529 user-supplied arguments with the message. If the user-supplied message
530 argument to the logging call is not a string, :func:`str` is called on it to
531 convert it to a string. This allows use of user-defined classes as
532 messages, whose ``__str__`` method can return the actual format string to
533 be used.
534
535
536.. _logrecord-attributes:
537
538LogRecord attributes
539--------------------
540
541The LogRecord has a number of attributes, most of which are derived from the
542parameters to the constructor. (Note that the names do not always correspond
543exactly between the LogRecord constructor parameters and the LogRecord
544attributes.) These attributes can be used to merge data from the record into
545the format string. The following table lists (in alphabetical order) the
546attribute names, their meanings and the corresponding placeholder in a %-style
547format string.
548
549+----------------+-------------------------+-----------------------------------------------+
550| Attribute name | Format | Description |
551+================+=========================+===============================================+
552| args | You shouldn't need to | The tuple of arguments merged into ``msg`` to |
553| | format this yourself. | produce ``message``. |
554+----------------+-------------------------+-----------------------------------------------+
555| asctime | ``%(asctime)s`` | Human-readable time when the |
556| | | :class:`LogRecord` was created. By default |
557| | | this is of the form '2003-07-08 16:49:45,896' |
558| | | (the numbers after the comma are millisecond |
559| | | portion of the time). |
560+----------------+-------------------------+-----------------------------------------------+
561| created | ``%(created)f`` | Time when the :class:`LogRecord` was created |
562| | | (as returned by :func:`time.time`). |
563+----------------+-------------------------+-----------------------------------------------+
564| exc_info | You shouldn't need to | Exception tuple (à la ``sys.exc_info``) or, |
565| | format this yourself. | if no exception has occurred, *None*. |
566+----------------+-------------------------+-----------------------------------------------+
567| filename | ``%(filename)s`` | Filename portion of ``pathname``. |
568+----------------+-------------------------+-----------------------------------------------+
569| funcName | ``%(funcName)s`` | Name of function containing the logging call. |
570+----------------+-------------------------+-----------------------------------------------+
571| levelname | ``%(levelname)s`` | Text logging level for the message |
572| | | (``'DEBUG'``, ``'INFO'``, ``'WARNING'``, |
573| | | ``'ERROR'``, ``'CRITICAL'``). |
574+----------------+-------------------------+-----------------------------------------------+
575| levelno | ``%(levelno)s`` | Numeric logging level for the message |
576| | | (:const:`DEBUG`, :const:`INFO`, |
577| | | :const:`WARNING`, :const:`ERROR`, |
578| | | :const:`CRITICAL`). |
579+----------------+-------------------------+-----------------------------------------------+
580| lineno | ``%(lineno)d`` | Source line number where the logging call was |
581| | | issued (if available). |
582+----------------+-------------------------+-----------------------------------------------+
583| module | ``%(module)s`` | Module (name portion of ``filename``). |
584+----------------+-------------------------+-----------------------------------------------+
585| msecs | ``%(msecs)d`` | Millisecond portion of the time when the |
586| | | :class:`LogRecord` was created. |
587+----------------+-------------------------+-----------------------------------------------+
588| message | ``%(message)s`` | The logged message, computed as ``msg % |
589| | | args``. This is set when |
590| | | :meth:`Formatter.format` is invoked. |
591+----------------+-------------------------+-----------------------------------------------+
592| msg | You shouldn't need to | The format string passed in the original |
593| | format this yourself. | logging call. Merged with ``args`` to |
594| | | produce ``message``, or an arbitrary object |
595| | | (see :ref:`arbitrary-object-messages`). |
596+----------------+-------------------------+-----------------------------------------------+
597| name | ``%(name)s`` | Name of the logger used to log the call. |
598+----------------+-------------------------+-----------------------------------------------+
599| pathname | ``%(pathname)s`` | Full pathname of the source file where the |
600| | | logging call was issued (if available). |
601+----------------+-------------------------+-----------------------------------------------+
602| process | ``%(process)d`` | Process ID (if available). |
603+----------------+-------------------------+-----------------------------------------------+
604| processName | ``%(processName)s`` | Process name (if available). |
605+----------------+-------------------------+-----------------------------------------------+
606| relativeCreated| ``%(relativeCreated)d`` | Time in milliseconds when the LogRecord was |
607| | | created, relative to the time the logging |
608| | | module was loaded. |
609+----------------+-------------------------+-----------------------------------------------+
610| thread | ``%(thread)d`` | Thread ID (if available). |
611+----------------+-------------------------+-----------------------------------------------+
612| threadName | ``%(threadName)s`` | Thread name (if available). |
613+----------------+-------------------------+-----------------------------------------------+
614
615.. versionchanged:: 2.5
616 *funcName* was added.
617
618.. _logger-adapter:
619
620LoggerAdapter Objects
621---------------------
622
623:class:`LoggerAdapter` instances are used to conveniently pass contextual
624information into logging calls. For a usage example , see the section on
625:ref:`adding contextual information to your logging output <context-info>`.
626
627.. versionadded:: 2.6
628
629
630.. class:: LoggerAdapter(logger, extra)
631
632 Returns an instance of :class:`LoggerAdapter` initialized with an
633 underlying :class:`Logger` instance and a dict-like object.
634
635 .. method:: process(msg, kwargs)
636
637 Modifies the message and/or keyword arguments passed to a logging call in
638 order to insert contextual information. This implementation takes the object
639 passed as *extra* to the constructor and adds it to *kwargs* using key
640 'extra'. The return value is a (*msg*, *kwargs*) tuple which has the
641 (possibly modified) versions of the arguments passed in.
642
643In addition to the above, :class:`LoggerAdapter` supports the following
644methods of :class:`Logger`, i.e. :meth:`debug`, :meth:`info`, :meth:`warning`,
645:meth:`error`, :meth:`exception`, :meth:`critical`, :meth:`log`,
646:meth:`isEnabledFor`, :meth:`getEffectiveLevel`, :meth:`setLevel`,
647:meth:`hasHandlers`. These methods have the same signatures as their
648counterparts in :class:`Logger`, so you can use the two types of instances
649interchangeably.
650
651.. versionchanged:: 2.7
652 The :meth:`isEnabledFor` method was added to :class:`LoggerAdapter`. This
653 method delegates to the underlying logger.
654
655
656Thread Safety
657-------------
658
659The logging module is intended to be thread-safe without any special work
660needing to be done by its clients. It achieves this though using threading
661locks; there is one lock to serialize access to the module's shared data, and
662each handler also creates a lock to serialize access to its underlying I/O.
663
664If you are implementing asynchronous signal handlers using the :mod:`signal`
665module, you may not be able to use logging from within such handlers. This is
666because lock implementations in the :mod:`threading` module are not always
667re-entrant, and so cannot be invoked from such signal handlers.
668
Georg Brandl8ec7f652007-08-15 14:28:01 +0000669
Vinay Sajipb5902e62009-01-15 22:48:13 +0000670Module-Level Functions
671----------------------
672
Georg Brandl8ec7f652007-08-15 14:28:01 +0000673In addition to the classes described above, there are a number of module- level
674functions.
675
676
677.. function:: getLogger([name])
678
679 Return a logger with the specified name or, if no name is specified, return a
680 logger which is the root logger of the hierarchy. If specified, the name is
681 typically a dot-separated hierarchical name like *"a"*, *"a.b"* or *"a.b.c.d"*.
682 Choice of these names is entirely up to the developer who is using logging.
683
684 All calls to this function with a given name return the same logger instance.
685 This means that logger instances never need to be passed between different parts
686 of an application.
687
688
689.. function:: getLoggerClass()
690
691 Return either the standard :class:`Logger` class, or the last class passed to
692 :func:`setLoggerClass`. This function may be called from within a new class
693 definition, to ensure that installing a customised :class:`Logger` class will
694 not undo customisations already applied by other code. For example::
695
696 class MyLogger(logging.getLoggerClass()):
697 # ... override behaviour here
698
699
700.. function:: debug(msg[, *args[, **kwargs]])
701
702 Logs a message with level :const:`DEBUG` on the root logger. The *msg* is the
703 message format string, and the *args* are the arguments which are merged into
704 *msg* using the string formatting operator. (Note that this means that you can
705 use keywords in the format string, together with a single dictionary argument.)
706
707 There are two keyword arguments in *kwargs* which are inspected: *exc_info*
708 which, if it does not evaluate as false, causes exception information to be
709 added to the logging message. If an exception tuple (in the format returned by
710 :func:`sys.exc_info`) is provided, it is used; otherwise, :func:`sys.exc_info`
711 is called to get the exception information.
712
713 The other optional keyword argument is *extra* which can be used to pass a
714 dictionary which is used to populate the __dict__ of the LogRecord created for
715 the logging event with user-defined attributes. These custom attributes can then
716 be used as you like. For example, they could be incorporated into logged
717 messages. For example::
718
719 FORMAT = "%(asctime)-15s %(clientip)s %(user)-8s %(message)s"
720 logging.basicConfig(format=FORMAT)
721 d = {'clientip': '192.168.0.1', 'user': 'fbloggs'}
722 logging.warning("Protocol problem: %s", "connection reset", extra=d)
723
Vinay Sajipfe08e6f2010-09-11 10:25:28 +0000724 would print something like::
Georg Brandl8ec7f652007-08-15 14:28:01 +0000725
726 2006-02-08 22:20:02,165 192.168.0.1 fbloggs Protocol problem: connection reset
727
728 The keys in the dictionary passed in *extra* should not clash with the keys used
729 by the logging system. (See the :class:`Formatter` documentation for more
730 information on which keys are used by the logging system.)
731
732 If you choose to use these attributes in logged messages, you need to exercise
733 some care. In the above example, for instance, the :class:`Formatter` has been
734 set up with a format string which expects 'clientip' and 'user' in the attribute
735 dictionary of the LogRecord. If these are missing, the message will not be
736 logged because a string formatting exception will occur. So in this case, you
737 always need to pass the *extra* dictionary with these keys.
738
739 While this might be annoying, this feature is intended for use in specialized
740 circumstances, such as multi-threaded servers where the same code executes in
741 many contexts, and interesting conditions which arise are dependent on this
742 context (such as remote client IP address and authenticated user name, in the
743 above example). In such circumstances, it is likely that specialized
744 :class:`Formatter`\ s would be used with particular :class:`Handler`\ s.
745
746 .. versionchanged:: 2.5
747 *extra* was added.
748
749
750.. function:: info(msg[, *args[, **kwargs]])
751
752 Logs a message with level :const:`INFO` on the root logger. The arguments are
753 interpreted as for :func:`debug`.
754
755
756.. function:: warning(msg[, *args[, **kwargs]])
757
758 Logs a message with level :const:`WARNING` on the root logger. The arguments are
759 interpreted as for :func:`debug`.
760
761
762.. function:: error(msg[, *args[, **kwargs]])
763
764 Logs a message with level :const:`ERROR` on the root logger. The arguments are
765 interpreted as for :func:`debug`.
766
767
768.. function:: critical(msg[, *args[, **kwargs]])
769
770 Logs a message with level :const:`CRITICAL` on the root logger. The arguments
771 are interpreted as for :func:`debug`.
772
773
774.. function:: exception(msg[, *args])
775
776 Logs a message with level :const:`ERROR` on the root logger. The arguments are
777 interpreted as for :func:`debug`. Exception info is added to the logging
778 message. This function should only be called from an exception handler.
779
780
781.. function:: log(level, msg[, *args[, **kwargs]])
782
783 Logs a message with level *level* on the root logger. The other arguments are
784 interpreted as for :func:`debug`.
785
Vinay Sajip89e1ae22010-09-17 10:09:04 +0000786 PLEASE NOTE: The above module-level functions which delegate to the root
787 logger should *not* be used in threads, in versions of Python earlier than
788 2.7.1 and 3.2, unless at least one handler has been added to the root
789 logger *before* the threads are started. These convenience functions call
790 :func:`basicConfig` to ensure that at least one handler is available; in
791 earlier versions of Python, this can (under rare circumstances) lead to
792 handlers being added multiple times to the root logger, which can in turn
793 lead to multiple messages for the same event.
Georg Brandl8ec7f652007-08-15 14:28:01 +0000794
795.. function:: disable(lvl)
796
797 Provides an overriding level *lvl* for all loggers which takes precedence over
798 the logger's own level. When the need arises to temporarily throttle logging
Vinay Sajip2060e422010-03-17 15:05:57 +0000799 output down across the whole application, this function can be useful. Its
800 effect is to disable all logging calls of severity *lvl* and below, so that
801 if you call it with a value of INFO, then all INFO and DEBUG events would be
802 discarded, whereas those of severity WARNING and above would be processed
803 according to the logger's effective level.
Georg Brandl8ec7f652007-08-15 14:28:01 +0000804
805
806.. function:: addLevelName(lvl, levelName)
807
808 Associates level *lvl* with text *levelName* in an internal dictionary, which is
809 used to map numeric levels to a textual representation, for example when a
810 :class:`Formatter` formats a message. This function can also be used to define
811 your own levels. The only constraints are that all levels used must be
812 registered using this function, levels should be positive integers and they
813 should increase in increasing order of severity.
814
Vinay Sajip89e1ae22010-09-17 10:09:04 +0000815 NOTE: If you are thinking of defining your own levels, please see the section
816 on :ref:`custom-levels`.
Georg Brandl8ec7f652007-08-15 14:28:01 +0000817
818.. function:: getLevelName(lvl)
819
820 Returns the textual representation of logging level *lvl*. If the level is one
821 of the predefined levels :const:`CRITICAL`, :const:`ERROR`, :const:`WARNING`,
822 :const:`INFO` or :const:`DEBUG` then you get the corresponding string. If you
823 have associated levels with names using :func:`addLevelName` then the name you
824 have associated with *lvl* is returned. If a numeric value corresponding to one
825 of the defined levels is passed in, the corresponding string representation is
826 returned. Otherwise, the string "Level %s" % lvl is returned.
827
828
829.. function:: makeLogRecord(attrdict)
830
831 Creates and returns a new :class:`LogRecord` instance whose attributes are
832 defined by *attrdict*. This function is useful for taking a pickled
833 :class:`LogRecord` attribute dictionary, sent over a socket, and reconstituting
834 it as a :class:`LogRecord` instance at the receiving end.
835
836
837.. function:: basicConfig([**kwargs])
838
839 Does basic configuration for the logging system by creating a
840 :class:`StreamHandler` with a default :class:`Formatter` and adding it to the
Vinay Sajip1c77b7f2009-10-10 20:32:36 +0000841 root logger. The functions :func:`debug`, :func:`info`, :func:`warning`,
Georg Brandl8ec7f652007-08-15 14:28:01 +0000842 :func:`error` and :func:`critical` will call :func:`basicConfig` automatically
843 if no handlers are defined for the root logger.
844
Vinay Sajip1c77b7f2009-10-10 20:32:36 +0000845 This function does nothing if the root logger already has handlers
846 configured for it.
Georg Brandldfb5bbd2008-05-09 06:18:27 +0000847
Georg Brandl8ec7f652007-08-15 14:28:01 +0000848 .. versionchanged:: 2.4
849 Formerly, :func:`basicConfig` did not take any keyword arguments.
850
Vinay Sajip89e1ae22010-09-17 10:09:04 +0000851 PLEASE NOTE: This function should be called from the main thread
852 before other threads are started. In versions of Python prior to
853 2.7.1 and 3.2, if this function is called from multiple threads,
854 it is possible (in rare circumstances) that a handler will be added
855 to the root logger more than once, leading to unexpected results
856 such as messages being duplicated in the log.
857
Georg Brandl8ec7f652007-08-15 14:28:01 +0000858 The following keyword arguments are supported.
859
860 +--------------+---------------------------------------------+
861 | Format | Description |
862 +==============+=============================================+
863 | ``filename`` | Specifies that a FileHandler be created, |
864 | | using the specified filename, rather than a |
865 | | StreamHandler. |
866 +--------------+---------------------------------------------+
867 | ``filemode`` | Specifies the mode to open the file, if |
868 | | filename is specified (if filemode is |
869 | | unspecified, it defaults to 'a'). |
870 +--------------+---------------------------------------------+
871 | ``format`` | Use the specified format string for the |
872 | | handler. |
873 +--------------+---------------------------------------------+
874 | ``datefmt`` | Use the specified date/time format. |
875 +--------------+---------------------------------------------+
876 | ``level`` | Set the root logger level to the specified |
877 | | level. |
878 +--------------+---------------------------------------------+
879 | ``stream`` | Use the specified stream to initialize the |
880 | | StreamHandler. Note that this argument is |
881 | | incompatible with 'filename' - if both are |
882 | | present, 'stream' is ignored. |
883 +--------------+---------------------------------------------+
884
885
886.. function:: shutdown()
887
888 Informs the logging system to perform an orderly shutdown by flushing and
Vinay Sajip91f0ee42008-03-16 21:35:58 +0000889 closing all handlers. This should be called at application exit and no
890 further use of the logging system should be made after this call.
Georg Brandl8ec7f652007-08-15 14:28:01 +0000891
892
893.. function:: setLoggerClass(klass)
894
895 Tells the logging system to use the class *klass* when instantiating a logger.
896 The class should define :meth:`__init__` such that only a name argument is
897 required, and the :meth:`__init__` should call :meth:`Logger.__init__`. This
898 function is typically called before any loggers are instantiated by applications
899 which need to use custom logger behavior.
900
901
Vinay Sajip61afd262010-02-19 23:53:17 +0000902Integration with the warnings module
903------------------------------------
904
905The :func:`captureWarnings` function can be used to integrate :mod:`logging`
906with the :mod:`warnings` module.
907
908.. function:: captureWarnings(capture)
909
910 This function is used to turn the capture of warnings by logging on and
911 off.
912
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100913 If *capture* is ``True``, warnings issued by the :mod:`warnings` module will
914 be redirected to the logging system. Specifically, a warning will be
Vinay Sajip61afd262010-02-19 23:53:17 +0000915 formatted using :func:`warnings.formatwarning` and the resulting string
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100916 logged to a logger named 'py.warnings' with a severity of `WARNING`.
Vinay Sajip61afd262010-02-19 23:53:17 +0000917
Georg Brandlf6d367452010-03-12 10:02:03 +0000918 If *capture* is ``False``, the redirection of warnings to the logging system
Vinay Sajip61afd262010-02-19 23:53:17 +0000919 will stop, and warnings will be redirected to their original destinations
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100920 (i.e. those in effect before `captureWarnings(True)` was called).
Vinay Sajip61afd262010-02-19 23:53:17 +0000921
922
Georg Brandl8ec7f652007-08-15 14:28:01 +0000923
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100924.. seealso::
Georg Brandl8ec7f652007-08-15 14:28:01 +0000925
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100926 Module :mod:`logging.config`
927 Configuration API for the logging module.
Georg Brandl8ec7f652007-08-15 14:28:01 +0000928
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100929 Module :mod:`logging.handlers`
930 Useful handlers included with the logging module.
Georg Brandl8ec7f652007-08-15 14:28:01 +0000931
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100932 :pep:`282` - A Logging System
933 The proposal which described this feature for inclusion in the Python standard
934 library.
Georg Brandl8ec7f652007-08-15 14:28:01 +0000935
Vinay Sajip5dbca9c2011-04-08 11:40:38 +0100936 `Original Python logging package <http://www.red-dove.com/python_logging.html>`_
937 This is the original source for the :mod:`logging` package. The version of the
938 package available from this site is suitable for use with Python 1.5.2, 2.1.x
939 and 2.2.x, which do not include the :mod:`logging` package in the standard
940 library.
Georg Brandlc37f2882007-12-04 17:46:27 +0000941