Source

python-clinic / Doc / library / logging.handlers.rst

Full commit

:mod:`logging.handlers` --- Logging handlers

The following useful handlers are provided in the package. Note that three of the handlers (:class:`StreamHandler`, :class:`FileHandler` and :class:`NullHandler`) are actually defined in the :mod:`logging` module itself, but have been documented here along with the other handlers.

StreamHandler

The :class:`StreamHandler` class, located in the core :mod:`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 :meth:`write` and :meth:`flush` methods).

Returns a new instance of the :class:`StreamHandler` class. If stream is specified, the instance will use it for logging output; otherwise, sys.stderr will be used.

FileHandler

The :class:`FileHandler` class, located in the core :mod:`logging` package, sends logging output to a disk file. It inherits the output functionality from :class:`StreamHandler`.

Returns a new instance of the :class:`FileHandler` class. The specified file is opened and used as the stream for logging. If mode is not specified, :const:`'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 :meth:`emit`. By default, the file grows indefinitely.

NullHandler

The :class:`NullHandler` class, located in the core :mod:`logging` package, does not do any formatting or output. It is essentially a 'no-op' handler for use by library developers.

Returns a new instance of the :class:`NullHandler` class.

See :ref:`library-config` for more information on how to use :class:`NullHandler`.

WatchedFileHandler

The :class:`WatchedFileHandler` class, located in the :mod:`logging.handlers` module, is a :class:`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; :func:`stat` always returns zero for this value.

Returns a new instance of the :class:`WatchedFileHandler` class. The specified file is opened and used as the stream for logging. If mode is not specified, :const:`'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 :meth:`emit`. By default, the file grows indefinitely.

BaseRotatingHandler

The :class:`BaseRotatingHandler` class, located in the :mod:`logging.handlers` module, is the base class for the rotating file handlers, :class:`RotatingFileHandler` and :class:`TimedRotatingFileHandler`. You should not need to instantiate this class, but it has attributes and methods you may need to override.

The parameters are as for :class:`FileHandler`. The attributes are:

The reason the attributes exist is to save you having to subclass - you can use the same callables for instances of :class:`RotatingFileHandler` and :class:`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 :meth:`emit` call, i.e. via the :meth:`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 :ref:`cookbook-rotator-namer`.

RotatingFileHandler

The :class:`RotatingFileHandler` class, located in the :mod:`logging.handlers` module, supports rotation of disk log files.

Returns a new instance of the :class:`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 :meth:`emit`. By default, the file grows indefinitely.

You can use the maxBytes and backupCount values to allow the file to :dfn:`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; if maxBytes is zero, rollover never occurs. If 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 :file:`app.log`, you would get :file:`app.log`, :file:`app.log.1`, :file:`app.log.2`, up to :file:`app.log.5`. The file being written to is always :file:`app.log`. When this file is filled, it is closed and renamed to :file:`app.log.1`, and if files :file:`app.log.1`, :file:`app.log.2`, etc. exist, then they are renamed to :file:`app.log.2`, :file:`app.log.3` etc. respectively.

TimedRotatingFileHandler

The :class:`TimedRotatingFileHandler` class, located in the :mod:`logging.handlers` module, supports rotation of disk log files at certain timed intervals.

Returns a new instance of the :class:`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
'S' Seconds
'M' Minutes
'H' Hours
'D' Days
'W0'-'W6' Weekday (0=Monday)
'midnight' Roll over at midnight

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 :meth:`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".

SocketHandler

The :class:`SocketHandler` class, located in the :mod:`logging.handlers` module, sends logging output to a network socket. The base class uses a TCP socket.

Returns a new instance of the :class:`SocketHandler` class intended to communicate with a remote machine whose address is given by host and port.

DatagramHandler

The :class:`DatagramHandler` class, located in the :mod:`logging.handlers` module, inherits from :class:`SocketHandler` to support sending logging messages over UDP sockets.

Returns a new instance of the :class:`DatagramHandler` class intended to communicate with a remote machine whose address is given by host and port.

SysLogHandler

The :class:`SysLogHandler` class, located in the :mod:`logging.handlers` module, supports sending logging messages to a remote or local Unix syslog.

Returns a new instance of the :class:`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, :const:`LOG_USER` is used. The type of socket opened depends on the socktype argument, which defaults to :const:`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 :const:`socket.SOCK_STREAM`.

Note that if your server is not listening on UDP port 514, :class:`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.

NTEventLogHandler

The :class:`NTEventLogHandler` class, located in the :mod:`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.

Returns a new instance of the :class:`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'.

SMTPHandler

The :class:`SMTPHandler` class, located in the :mod:`logging.handlers` module, supports sending logging messages to an email address via SMTP.

Returns a new instance of the :class:`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 :meth:`smtplib.SMTP.starttls` method.)

A timeout can be specified for communication with the SMTP server using the timeout argument.

MemoryHandler

The :class:`MemoryHandler` class, located in the :mod:`logging.handlers` module, supports buffering of logging records in memory, periodically flushing them to a :dfn:`target` handler. Flushing occurs whenever the buffer is full, or when an event of a certain severity or greater is seen.

:class:`MemoryHandler` is a subclass of the more general :class:`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 :meth:`shouldFlush` to see if the buffer should be flushed. If it should, then :meth:`flush` is expected to do the flushing.

Initializes the handler with a buffer of the specified capacity.

Returns a new instance of the :class:`MemoryHandler` class. The instance is initialized with a buffer size of capacity. If flushLevel is not specified, :const:`ERROR` is used. If no target is specified, the target will need to be set using :meth:`setTarget` before this handler does anything useful.

HTTPHandler

The :class:`HTTPHandler` class, located in the :mod:`logging.handlers` module, supports sending logging messages to a Web server, using either GET or POST semantics.

Returns a new instance of the :class:`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, an HTTPS connection will be used. If credentials is specified, it should be a 2-tuple consisting of userid and password, which will be placed in an 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.

QueueHandler

The :class:`QueueHandler` class, located in the :mod:`logging.handlers` module, supports sending logging messages to a queue, such as those implemented in the :mod:`queue` or :mod:`multiprocessing` modules.

Along with the :class:`QueueListener` class, :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 :class:`SMTPHandler`) are done on a separate thread.

Returns a new instance of the :class:`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 :meth:`enqueue` method, which needs to know how to send messages to it.

QueueListener

The :class:`QueueListener` class, located in the :mod:`logging.handlers` module, supports receiving logging messages from a queue, such as those implemented in the :mod:`queue` or :mod:`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 :class:`QueueListener` is not itself a handler, it is documented here because it works hand-in-hand with :class:`QueueHandler`.

Along with the :class:`QueueHandler` class, :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 :class:`SMTPHandler`) are done on a separate thread.

Returns a new instance of the :class:`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 :meth:`dequeue` method, which needs to know how to get messages from it.