logging.handlers --- Logging handlersSource code: Lib/logging/handlers.py
[UNKNOWN NODE sidebar][UNKNOWN NODE transition]The following useful handlers are provided in the package. Note that three of
the handlers (StreamHandler, FileHandler and
NullHandler) are actually defined in the logging module itself,
but have been documented here along with the other handlers.
The StreamHandler class, located in the core logging package,
sends logging output to streams such as sys.stdout, sys.stderr or any
file-like object (or, more precisely, any object which supports write()
and flush() methods).
class logging.StreamHandler(stream=None)[source]
Returns a new instance of the StreamHandler class. If stream is
specified, the instance will use it for logging output; otherwise, sys.stderr
will be used.
emit(record)[source]
If a formatter is specified, it is used to format the record. The record
is then written to the stream with a terminator. If exception information
is present, it is formatted using traceback.print_exception() and
appended to the stream.
flush()[source]
Flushes the stream by calling its flush() method. Note that the
close() method is inherited from Handler and so
does no output, so an explicit flush() call may be needed at times.
Changed in version 3.2: The StreamHandler class now has a terminator attribute, default
value '\n', which is used as the terminator when writing a formatted
record to a stream. If you don't want this newline termination, you can
set the handler instance's terminator attribute to the empty string.
In earlier versions, the terminator was hardcoded as '\n'.
The FileHandler class, located in the core logging package,
sends logging output to a disk file. It inherits the output functionality from
StreamHandler.
class logging.FileHandler(filename, mode='a', encoding=None, delay=False)[source]
Returns a new instance of the FileHandler class. The specified file is
opened and used as the stream for logging. If mode is not specified,
'a' is used. If encoding is not None, it is used to open the file
with that encoding. If delay is true, then file opening is deferred until the
first call to emit(). By default, the file grows indefinitely.
Changed in version 3.6: As well as string values, Path objects are also accepted
for the filename argument.
close()[source]
Closes the file.
emit(record)[source]
Outputs the record to the file.
New in version 3.1.
The NullHandler class, located in the core logging package,
does not do any formatting or output. It is essentially a 'no-op' handler
for use by library developers.
class logging.NullHandler[source]
Returns a new instance of the NullHandler class.
emit(record)[source]
This method does nothing.
handle(record)[source]
This method does nothing.
createLock()[source]
This method returns None for the lock, since there is no
underlying I/O to which access needs to be serialized.
See Configuring Logging for a Library for more information on how to use
NullHandler.
The WatchedFileHandler class, located in the logging.handlers
module, is a FileHandler which watches the file it is logging to. If
the file changes, it is closed and reopened using the file name.
A file change can happen because of usage of programs such as newsyslog and logrotate which perform log file rotation. This handler, intended for use under Unix/Linux, watches the file to see if it has changed since the last emit. (A file is deemed to have changed if its device or inode have changed.) If the file has changed, the old file stream is closed, and the file opened to get a new stream.
This handler is not appropriate for use under Windows, because under Windows
open log files cannot be moved or renamed - logging opens the files with
exclusive locks - and so there is no need for such a handler. Furthermore,
ST_INO is not supported under Windows; stat() always returns zero
for this value.
class logging.handlers.WatchedFileHandler(filename, mode='a', encoding=None, delay=False)[source]
Returns a new instance of the WatchedFileHandler class. The specified
file is opened and used as the stream for logging. If mode is not specified,
'a' is used. If encoding is not None, it is used to open the file
with that encoding. If delay is true, then file opening is deferred until the
first call to emit(). By default, the file grows indefinitely.
Changed in version 3.6: As well as string values, Path objects are also accepted
for the filename argument.
reopenIfNeeded()
Checks to see if the file has changed. If it has, the existing stream is flushed and closed and the file opened again, typically as a precursor to outputting the record to the file.
New in version 3.6.
emit(record)[source]
Outputs the record to the file, but first calls reopenIfNeeded() to
reopen the file if it has changed.
The BaseRotatingHandler class, located in the logging.handlers
module, is the base class for the rotating file handlers,
RotatingFileHandler and TimedRotatingFileHandler. You should
not need to instantiate this class, but it has attributes and methods you may
need to override.
class logging.handlers.BaseRotatingHandler(filename, mode, encoding=None, delay=False)[source]
The parameters are as for FileHandler. The attributes are:
namer
If this attribute is set to a callable, the rotation_filename()
method delegates to this callable. The parameters passed to the callable
are those passed to rotation_filename().
Note
The namer function is called quite a few times during rollover, so it should be as simple and as fast as possible. It should also return the same output every time for a given input, otherwise the rollover behaviour may not work as expected.
New in version 3.3.
rotator
If this attribute is set to a callable, the rotate() method
delegates to this callable. The parameters passed to the callable are
those passed to rotate().
New in version 3.3.
rotation_filename(default_name)
Modify the filename of a log file when rotating.
This is provided so that a custom filename can be provided.
The default implementation calls the 'namer' attribute of the handler,
if it's callable, passing the default name to it. If the attribute isn't
callable (the default is None), the name is returned unchanged.
New in version 3.3.
rotate(source, dest)
When rotating, rotate the current log.
The default implementation calls the 'rotator' attribute of the handler,
if it's callable, passing the source and dest arguments to it. If the
attribute isn't callable (the default is None), the source is simply
renamed to the destination.
- source -- The source filename. This is normally the base filename, e.g. 'test.log'.
- dest -- The destination filename. This is normally what the source is rotated to, e.g. 'test.log.1'.
New in version 3.3.
The reason the attributes exist is to save you having to subclass - you can use
the same callables for instances of RotatingFileHandler and
TimedRotatingFileHandler. If either the namer or rotator callable
raises an exception, this will be handled in the same way as any other
exception during an emit() call, i.e. via the handleError() method
of the handler.
If you need to make more significant changes to rotation processing, you can override the methods.
For an example, see Using a rotator and namer to customize log rotation processing.
The RotatingFileHandler class, located in the logging.handlers
module, supports rotation of disk log files.
class logging.handlers.RotatingFileHandler(filename, mode='a', maxBytes=0, backupCount=0, encoding=None, delay=False)[source]
Returns a new instance of the RotatingFileHandler class. The specified
file is opened and used as the stream for logging. If mode is not specified,
'a' is used. If encoding is not None, it is used to open the file
with that encoding. If delay is true, then file opening is deferred until the
first call to emit(). By default, the file grows indefinitely.
You can use the maxBytes and backupCount values to allow the file to
rollover at a predetermined size. When the size is about to be exceeded,
the file is closed and a new file is silently opened for output. Rollover occurs
whenever the current log file is nearly maxBytes in length; but if either of
maxBytes or backupCount is zero, rollover never occurs, so you generally want
to set backupCount to at least 1, and have a non-zero maxBytes.
When backupCount is non-zero, the system will save old log files by appending
the extensions '.1', '.2' etc., to the filename. For example, with a backupCount
of 5 and a base file name of app.log, you would get app.log,
app.log.1, app.log.2, up to app.log.5. The file being
written to is always app.log. When this file is filled, it is closed
and renamed to app.log.1, and if files app.log.1,
app.log.2, etc. exist, then they are renamed to app.log.2,
app.log.3 etc. respectively.
Changed in version 3.6: As well as string values, Path objects are also accepted
for the filename argument.
doRollover()[source]
Does a rollover, as described above.
emit(record)
Outputs the record to the file, catering for rollover as described previously.
The TimedRotatingFileHandler class, located in the
logging.handlers module, supports rotation of disk log files at certain
timed intervals.
class logging.handlers.TimedRotatingFileHandler(filename, when='h', interval=1, backupCount=0, encoding=None, delay=False, utc=False, atTime=None)[source]
Returns a new instance of the TimedRotatingFileHandler class. The
specified file is opened and used as the stream for logging. On rotating it also
sets the filename suffix. Rotating happens based on the product of when and
interval.
You can use the when to specify the type of interval. The list of possible values is below. Note that they are not case sensitive.
| Value | Type of interval | If/how atTime is used |
|---|---|---|
'S' | Seconds | Ignored |
'M' | Minutes | Ignored |
'H' | Hours | Ignored |
'D' | Days | Ignored |
'W0'-'W6' | Weekday (0=Monday) | Used to compute initial rollover time |
'midnight' | Roll over at midnight, if atTime not specified, else at time atTime | Used to compute initial rollover time |
When using weekday-based rotation, specify 'W0' for Monday, 'W1' for Tuesday, and so on up to 'W6' for Sunday. In this case, the value passed for interval isn't used.
The system will save old log files by appending extensions to the filename.
The extensions are date-and-time based, using the strftime format
%Y-%m-%d_%H-%M-%S or a leading portion thereof, depending on the
rollover interval.
When computing the next rollover time for the first time (when the handler is created), the last modification time of an existing log file, or else the current time, is used to compute when the next rotation will occur.
If the utc argument is true, times in UTC will be used; otherwise local time is used.
If backupCount is nonzero, at most backupCount files will be kept, and if more would be created when rollover occurs, the oldest one is deleted. The deletion logic uses the interval to determine which files to delete, so changing the interval may leave old files lying around.
If delay is true, then file opening is deferred until the first call to
emit().
If atTime is not None, it must be a datetime.time instance which
specifies the time of day when rollover occurs, for the cases where rollover
is set to happen "at midnight" or "on a particular weekday". Note that in
these cases, the atTime value is effectively used to compute the initial
rollover, and subsequent rollovers would be calculated via the normal
interval calculation.
Note
Calculation of the initial rollover time is done when the handler is initialised. Calculation of subsequent rollover times is done only when rollover occurs, and rollover occurs only when emitting output. If this is not kept in mind, it might lead to some confusion. For example, if an interval of "every minute" is set, that does not mean you will always see log files with times (in the filename) separated by a minute; if, during application execution, logging output is generated more frequently than once a minute, then you can expect to see log files with times separated by a minute. If, on the other hand, logging messages are only output once every five minutes (say), then there will be gaps in the file times corresponding to the minutes where no output (and hence no rollover) occurred.
Changed in version 3.4: atTime parameter was added.
Changed in version 3.6: As well as string values, Path objects are also accepted
for the filename argument.
doRollover()[source]
Does a rollover, as described above.
emit(record)
Outputs the record to the file, catering for rollover as described above.
The SocketHandler class, located in the logging.handlers module,
sends logging output to a network socket. The base class uses a TCP socket.
class logging.handlers.SocketHandler(host, port)[source]
Returns a new instance of the SocketHandler class intended to
communicate with a remote machine whose address is given by host and port.
Changed in version 3.4: If port is specified as None, a Unix domain socket is created
using the value in host - otherwise, a TCP socket is created.
close()[source]
Closes the socket.
emit()[source]
Pickles the record's attribute dictionary and writes it to the socket in
binary format. If there is an error with the socket, silently drops the
packet. If the connection was previously lost, re-establishes the
connection. To unpickle the record at the receiving end into a
LogRecord, use the makeLogRecord()
function.
handleError()[source]
Handles an error which has occurred during emit(). The most likely
cause is a lost connection. Closes the socket so that we can retry on the
next event.
makeSocket()[source]
This is a factory method which allows subclasses to define the precise
type of socket they want. The default implementation creates a TCP socket
(socket.SOCK_STREAM).
makePickle(record)[source]
Pickles the record's attribute dictionary in binary format with a length prefix, and returns it ready for transmission across the socket.
Note that pickles aren't completely secure. If you are concerned about security, you may want to override this method to implement a more secure mechanism. For example, you can sign pickles using HMAC and then verify them on the receiving end, or alternatively you can disable unpickling of global objects on the receiving end.
send(packet)[source]
Send a pickled string packet to the socket. This function allows for partial sends which can happen when the network is busy.
createSocket()[source]
Tries to create a socket; on failure, uses an exponential back-off algorithm. On initial failure, the handler will drop the message it was trying to send. When subsequent messages are handled by the same instance, it will not try connecting until some time has passed. The default parameters are such that the initial delay is one second, and if after that delay the connection still can't be made, the handler will double the delay each time up to a maximum of 30 seconds.
This behaviour is controlled by the following handler attributes:
retryStart(initial delay, defaulting to 1.0 seconds).retryFactor(multiplier, defaulting to 2.0).retryMax(maximum delay, defaulting to 30.0 seconds).
This means that if the remote listener starts up after the handler has been used, you could lose messages (since the handler won't even attempt a connection until the delay has elapsed, but just silently drop messages during the delay period).
The DatagramHandler class, located in the logging.handlers
module, inherits from SocketHandler to support sending logging messages
over UDP sockets.
class logging.handlers.DatagramHandler(host, port)[source]
Returns a new instance of the DatagramHandler class intended to
communicate with a remote machine whose address is given by host and port.
Changed in version 3.4: If port is specified as None, a Unix domain socket is created
using the value in host - otherwise, a TCP socket is created.
emit()
Pickles the record's attribute dictionary and writes it to the socket in
binary format. If there is an error with the socket, silently drops the
packet. To unpickle the record at the receiving end into a
LogRecord, use the makeLogRecord()
function.
makeSocket()[source]
The factory method of SocketHandler is here overridden to create
a UDP socket (socket.SOCK_DGRAM).
send(s)[source]
Send a pickled string to a socket.
The SysLogHandler class, located in the logging.handlers module,
supports sending logging messages to a remote or local Unix syslog.
class logging.handlers.SysLogHandler(address=('localhost', SYSLOG_UDP_PORT), facility=LOG_USER, socktype=socket.SOCK_DGRAM)[source]
Returns a new instance of the SysLogHandler class intended to
communicate with a remote Unix machine whose address is given by address in
the form of a (host, port) tuple. If address is not specified,
('localhost', 514) is used. The address is used to open a socket. An
alternative to providing a (host, port) tuple is providing an address as a
string, for example '/dev/log'. In this case, a Unix domain socket is used to
send the message to the syslog. If facility is not specified,
LOG_USER is used. The type of socket opened depends on the
socktype argument, which defaults to socket.SOCK_DGRAM and thus
opens a UDP socket. To open a TCP socket (for use with the newer syslog
daemons such as rsyslog), specify a value of socket.SOCK_STREAM.
Note that if your server is not listening on UDP port 514,
SysLogHandler may appear not to work. In that case, check what
address you should be using for a domain socket - it's system dependent.
For example, on Linux it's usually '/dev/log' but on OS/X it's
'/var/run/syslog'. You'll need to check your platform and use the
appropriate address (you may need to do this check at runtime if your
application needs to run on several platforms). On Windows, you pretty
much have to use the UDP option.
Changed in version 3.2: socktype was added.
close()[source]
Closes the socket to the remote host.
emit(record)[source]
The record is formatted, and then sent to the syslog server. If exception information is present, it is not sent to the server.
Changed in version 3.2.1: (See: bpo-12168.) In earlier versions, the message sent to the syslog daemons was always terminated with a NUL byte, because early versions of these daemons expected a NUL terminated message - even though it's not in the relevant specification (RFC 5424). More recent versions of these daemons don't expect the NUL byte but strip it off if it's there, and even more recent daemons (which adhere more closely to RFC 5424) pass the NUL byte on as part of the message.
To enable easier handling of syslog messages in the face of all these
differing daemon behaviours, the appending of the NUL byte has been
made configurable, through the use of a class-level attribute,
append_nul. This defaults to True (preserving the existing
behaviour) but can be set to False on a SysLogHandler instance
in order for that instance to not append the NUL terminator.
Changed in version 3.3: (See: bpo-12419.) In earlier versions, there was no facility for
an "ident" or "tag" prefix to identify the source of the message. This
can now be specified using a class-level attribute, defaulting to
"" to preserve existing behaviour, but which can be overridden on
a SysLogHandler instance in order for that instance to prepend
the ident to every message handled. Note that the provided ident must
be text, not bytes, and is prepended to the message exactly as is.
encodePriority(facility, priority)[source]
Encodes the facility and priority into an integer. You can pass in strings or integers - if strings are passed, internal mapping dictionaries are used to convert them to integers.
The symbolic LOG_ values are defined in SysLogHandler and
mirror the values defined in the sys/syslog.h header file.
Priorities
| Name (string) | Symbolic value |
|---|---|
alert | LOG_ALERT |
crit or critical | LOG_CRIT |
debug | LOG_DEBUG |
emerg or panic | LOG_EMERG |
err or error | LOG_ERR |
info | LOG_INFO |
notice | LOG_NOTICE |
warn or warning | LOG_WARNING |
Facilities
| Name (string) | Symbolic value |
|---|---|
auth | LOG_AUTH |
authpriv | LOG_AUTHPRIV |
cron | LOG_CRON |
daemon | LOG_DAEMON |
ftp | LOG_FTP |
kern | LOG_KERN |
lpr | LOG_LPR |
mail | LOG_MAIL |
news | LOG_NEWS |
syslog | LOG_SYSLOG |
user | LOG_USER |
uucp | LOG_UUCP |
local0 | LOG_LOCAL0 |
local1 | LOG_LOCAL1 |
local2 | LOG_LOCAL2 |
local3 | LOG_LOCAL3 |
local4 | LOG_LOCAL4 |
local5 | LOG_LOCAL5 |
local6 | LOG_LOCAL6 |
local7 | LOG_LOCAL7 |
mapPriority(levelname)[source]
Maps a logging level name to a syslog priority name.
You may need to override this if you are using custom levels, or
if the default algorithm is not suitable for your needs. The
default algorithm maps DEBUG, INFO, WARNING, ERROR and
CRITICAL to the equivalent syslog names, and all other level
names to 'warning'.
The NTEventLogHandler class, located in the logging.handlers
module, supports sending logging messages to a local Windows NT, Windows 2000 or
Windows XP event log. Before you can use it, you need Mark Hammond's Win32
extensions for Python installed.
class logging.handlers.NTEventLogHandler(appname, dllname=None, logtype='Application')[source]
Returns a new instance of the NTEventLogHandler class. The appname is
used to define the application name as it appears in the event log. An
appropriate registry entry is created using this name. The dllname should give
the fully qualified pathname of a .dll or .exe which contains message
definitions to hold in the log (if not specified, 'win32service.pyd' is used
- this is installed with the Win32 extensions and contains some basic
placeholder message definitions. Note that use of these placeholders will make
your event logs big, as the entire message source is held in the log. If you
want slimmer logs, you have to pass in the name of your own .dll or .exe which
contains the message definitions you want to use in the event log). The
logtype is one of 'Application', 'System' or 'Security', and
defaults to 'Application'.
close()[source]
At this point, you can remove the application name from the registry as a source of event log entries. However, if you do this, you will not be able to see the events as you intended in the Event Log Viewer - it needs to be able to access the registry to get the .dll name. The current version does not do this.
emit(record)[source]
Determines the message ID, event category and event type, and then logs the message in the NT event log.
getEventCategory(record)[source]
Returns the event category for the record. Override this if you want to specify your own categories. This version returns 0.
getEventType(record)[source]
Returns the event type for the record. Override this if you want to
specify your own types. This version does a mapping using the handler's
typemap attribute, which is set up in __init__() to a dictionary
which contains mappings for DEBUG, INFO,
WARNING, ERROR and CRITICAL. If you are using
your own levels, you will either need to override this method or place a
suitable dictionary in the handler's typemap attribute.
getMessageID(record)[source]
Returns the message ID for the record. If you are using your own messages,
you could do this by having the msg passed to the logger being an ID
rather than a format string. Then, in here, you could use a dictionary
lookup to get the message ID. This version returns 1, which is the base
message ID in win32service.pyd.
The SMTPHandler class, located in the logging.handlers module,
supports sending logging messages to an email address via SMTP.
class logging.handlers.SMTPHandler(mailhost, fromaddr, toaddrs, subject, credentials=None, secure=None, timeout=1.0)[source]
Returns a new instance of the SMTPHandler class. The instance is
initialized with the from and to addresses and subject line of the email. The
toaddrs should be a list of strings. To specify a non-standard SMTP port, use
the (host, port) tuple format for the mailhost argument. If you use a string,
the standard SMTP port is used. If your SMTP server requires authentication, you
can specify a (username, password) tuple for the credentials argument.
To specify the use of a secure protocol (TLS), pass in a tuple to the
secure argument. This will only be used when authentication credentials are
supplied. The tuple should be either an empty tuple, or a single-value tuple
with the name of a keyfile, or a 2-value tuple with the names of the keyfile
and certificate file. (This tuple is passed to the
smtplib.SMTP.starttls() method.)
A timeout can be specified for communication with the SMTP server using the timeout argument.
New in version 3.3: The timeout argument was added.
emit(record)[source]
Formats the record and sends it to the specified addressees.
getSubject(record)[source]
If you want to specify a subject line which is record-dependent, override this method.
The MemoryHandler class, located in the logging.handlers module,
supports buffering of logging records in memory, periodically flushing them to a
target handler. Flushing occurs whenever the buffer is full, or when an
event of a certain severity or greater is seen.
MemoryHandler is a subclass of the more general
BufferingHandler, which is an abstract class. This buffers logging
records in memory. Whenever each record is added to the buffer, a check is made
by calling shouldFlush() to see if the buffer should be flushed. If it
should, then flush() is expected to do the flushing.
class logging.handlers.BufferingHandler(capacity)[source]
Initializes the handler with a buffer of the specified capacity.
emit(record)[source]
Appends the record to the buffer. If shouldFlush() returns true,
calls flush() to process the buffer.
flush()[source]
You can override this to implement custom flushing behavior. This version just zaps the buffer to empty.
shouldFlush(record)[source]
Returns true if the buffer is up to capacity. This method can be overridden to implement custom flushing strategies.
class logging.handlers.MemoryHandler(capacity, flushLevel=ERROR, target=None, flushOnClose=True)[source]
Returns a new instance of the MemoryHandler class. The instance is
initialized with a buffer size of capacity. If flushLevel is not specified,
ERROR is used. If no target is specified, the target will need to be
set using setTarget() before this handler does anything useful. If
flushOnClose is specified as False, then the buffer is not flushed when
the handler is closed. If not specified or specified as True, the previous
behaviour of flushing the buffer will occur when the handler is closed.
Changed in version 3.6: The flushOnClose parameter was added.
close()[source]
Calls flush(), sets the target to None and clears the
buffer.
flush()[source]
For a MemoryHandler, flushing means just sending the buffered
records to the target, if there is one. The buffer is also cleared when
this happens. Override if you want different behavior.
setTarget(target)[source]
Sets the target handler for this handler.
shouldFlush(record)[source]
Checks for buffer full or a record at the flushLevel or higher.
The HTTPHandler class, located in the logging.handlers module,
supports sending logging messages to a Web server, using either GET or
POST semantics.
class logging.handlers.HTTPHandler(host, url, method='GET', secure=False, credentials=None, context=None)[source]
Returns a new instance of the HTTPHandler class. The host can be
of the form host:port, should you need to use a specific port number. If
no method is specified, GET is used. If secure is true, a HTTPS
connection will be used. The context parameter may be set to a
ssl.SSLContext instance to configure the SSL settings used for the
HTTPS connection. If credentials is specified, it should be a 2-tuple
consisting of userid and password, which will be placed in a HTTP
'Authorization' header using Basic authentication. If you specify
credentials, you should also specify secure=True so that your userid and
password are not passed in cleartext across the wire.
Changed in version 3.5: The context parameter was added.
mapLogRecord(record)[source]
Provides a dictionary, based on record, which is to be URL-encoded
and sent to the web server. The default implementation just returns
record.__dict__. This method can be overridden if e.g. only a
subset of LogRecord is to be sent to the web server, or
if more specific customization of what's sent to the server is required.
emit(record)[source]
Sends the record to the Web server as a URL-encoded dictionary. The
mapLogRecord() method is used to convert the record to the
dictionary to be sent.
Note
Since preparing a record for sending it to a Web server is not
the same as a generic formatting operation, using
setFormatter() to specify a
Formatter for a HTTPHandler has no effect.
Instead of calling format(), this handler calls
mapLogRecord() and then urllib.parse.urlencode() to encode the
dictionary in a form suitable for sending to a Web server.
New in version 3.2.
The QueueHandler class, located in the logging.handlers module,
supports sending logging messages to a queue, such as those implemented in the
queue or multiprocessing modules.
Along with the QueueListener class, QueueHandler can be used
to let handlers do their work on a separate thread from the one which does the
logging. This is important in Web applications and also other service
applications where threads servicing clients need to respond as quickly as
possible, while any potentially slow operations (such as sending an email via
SMTPHandler) are done on a separate thread.
class logging.handlers.QueueHandler(queue)
Returns a new instance of the QueueHandler class. The instance is
initialized with the queue to send messages to. The queue can be any
queue-like object; it's used as-is by the enqueue() method, which needs
to know how to send messages to it.
emit(record)
Enqueues the result of preparing the LogRecord.
prepare(record)
Prepares a record for queuing. The object returned by this method is enqueued.
The base implementation formats the record to merge the message and arguments, and removes unpickleable items from the record in-place.
You might want to override this method if you want to convert the record to a dict or JSON string, or send a modified copy of the record while leaving the original intact.
enqueue(record)
Enqueues the record on the queue using put_nowait(); you may
want to override this if you want to use blocking behaviour, or a
timeout, or a customized queue implementation.
New in version 3.2.
The QueueListener class, located in the logging.handlers
module, supports receiving logging messages from a queue, such as those
implemented in the queue or multiprocessing modules. The
messages are received from a queue in an internal thread and passed, on
the same thread, to one or more handlers for processing. While
QueueListener is not itself a handler, it is documented here
because it works hand-in-hand with QueueHandler.
Along with the QueueHandler class, QueueListener can be used
to let handlers do their work on a separate thread from the one which does the
logging. This is important in Web applications and also other service
applications where threads servicing clients need to respond as quickly as
possible, while any potentially slow operations (such as sending an email via
SMTPHandler) are done on a separate thread.
class logging.handlers.QueueListener(queue, *handlers, respect_handler_level=False)
Returns a new instance of the QueueListener class. The instance is
initialized with the queue to send messages to and a list of handlers which
will handle entries placed on the queue. The queue can be any queue-like
object; it's passed as-is to the dequeue() method, which needs
to know how to get messages from it. If respect_handler_level is True,
a handler's level is respected (compared with the level for the message) when
deciding whether to pass messages to that handler; otherwise, the behaviour
is as in previous Python versions - to always pass each message to each
handler.
Changed in version 3.5: The respect_handler_levels argument was added.
dequeue(block)
Dequeues a record and return it, optionally blocking.
The base implementation uses get(). You may want to override this
method if you want to use timeouts or work with custom queue
implementations.
prepare(record)
Prepare a record for handling.
This implementation just returns the passed-in record. You may want to override this method if you need to do any custom marshalling or manipulation of the record before passing it to the handlers.
handle(record)
Handle a record.
This just loops through the handlers offering them the record
to handle. The actual object passed to the handlers is that which
is returned from prepare().
start()
Starts the listener.
This starts up a background thread to monitor the queue for LogRecords to process.
stop()
Stops the listener.
This asks the thread to terminate, and then waits for it to do so. Note that if you don't call this before your application exits, there may be some records still left on the queue, which won't be processed.
enqueue_sentinel()
Writes a sentinel to the queue to tell the listener to quit. This
implementation uses put_nowait(). You may want to override this
method if you want to use timeouts or work with custom queue
implementations.
New in version 3.3.
See also
- Module
logging - API reference for the logging module.
- Module
logging.config - Configuration API for the logging module.