Vinay Sajip | c63619b | 2010-12-19 12:56:57 +0000 | [diff] [blame] | 1 | :mod:`logging.config` --- Logging configuration |
| 2 | =============================================== |
| 3 | |
| 4 | .. module:: logging.config |
| 5 | :synopsis: Configuration of the logging module. |
| 6 | |
| 7 | |
| 8 | .. moduleauthor:: Vinay Sajip <vinay_sajip@red-dove.com> |
| 9 | .. sectionauthor:: Vinay Sajip <vinay_sajip@red-dove.com> |
| 10 | |
Vinay Sajip | 01094e1 | 2010-12-19 13:41:26 +0000 | [diff] [blame] | 11 | .. sidebar:: Important |
| 12 | |
| 13 | This page contains only reference information. For tutorials, |
| 14 | please see |
| 15 | |
| 16 | * :ref:`Basic Tutorial <logging-basic-tutorial>` |
| 17 | * :ref:`Advanced Tutorial <logging-advanced-tutorial>` |
| 18 | * :ref:`Logging Cookbook <logging-cookbook>` |
| 19 | |
Vinay Sajip | 31b862d | 2013-09-05 23:01:07 +0100 | [diff] [blame] | 20 | **Source code:** :source:`Lib/logging/config.py` |
| 21 | |
| 22 | -------------- |
| 23 | |
Vinay Sajip | 01094e1 | 2010-12-19 13:41:26 +0000 | [diff] [blame] | 24 | This section describes the API for configuring the logging module. |
Vinay Sajip | c63619b | 2010-12-19 12:56:57 +0000 | [diff] [blame] | 25 | |
| 26 | .. _logging-config-api: |
| 27 | |
| 28 | Configuration functions |
| 29 | ^^^^^^^^^^^^^^^^^^^^^^^ |
| 30 | |
| 31 | The following functions configure the logging module. They are located in the |
| 32 | :mod:`logging.config` module. Their use is optional --- you can configure the |
| 33 | logging module using these functions or by making calls to the main API (defined |
| 34 | in :mod:`logging` itself) and defining handlers which are declared either in |
| 35 | :mod:`logging` or :mod:`logging.handlers`. |
| 36 | |
| 37 | .. function:: dictConfig(config) |
| 38 | |
| 39 | Takes the logging configuration from a dictionary. The contents of |
| 40 | this dictionary are described in :ref:`logging-config-dictschema` |
| 41 | below. |
| 42 | |
| 43 | If an error is encountered during configuration, this function will |
| 44 | raise a :exc:`ValueError`, :exc:`TypeError`, :exc:`AttributeError` |
| 45 | or :exc:`ImportError` with a suitably descriptive message. The |
| 46 | following is a (possibly incomplete) list of conditions which will |
| 47 | raise an error: |
| 48 | |
| 49 | * A ``level`` which is not a string or which is a string not |
| 50 | corresponding to an actual logging level. |
| 51 | * A ``propagate`` value which is not a boolean. |
| 52 | * An id which does not have a corresponding destination. |
| 53 | * A non-existent handler id found during an incremental call. |
| 54 | * An invalid logger name. |
| 55 | * Inability to resolve to an internal or external object. |
| 56 | |
| 57 | Parsing is performed by the :class:`DictConfigurator` class, whose |
| 58 | constructor is passed the dictionary used for configuration, and |
| 59 | has a :meth:`configure` method. The :mod:`logging.config` module |
| 60 | has a callable attribute :attr:`dictConfigClass` |
| 61 | which is initially set to :class:`DictConfigurator`. |
| 62 | You can replace the value of :attr:`dictConfigClass` with a |
| 63 | suitable implementation of your own. |
| 64 | |
| 65 | :func:`dictConfig` calls :attr:`dictConfigClass` passing |
| 66 | the specified dictionary, and then calls the :meth:`configure` method on |
| 67 | the returned object to put the configuration into effect:: |
| 68 | |
| 69 | def dictConfig(config): |
| 70 | dictConfigClass(config).configure() |
| 71 | |
| 72 | For example, a subclass of :class:`DictConfigurator` could call |
| 73 | ``DictConfigurator.__init__()`` in its own :meth:`__init__()`, then |
| 74 | set up custom prefixes which would be usable in the subsequent |
| 75 | :meth:`configure` call. :attr:`dictConfigClass` would be bound to |
| 76 | this new subclass, and then :func:`dictConfig` could be called exactly as |
| 77 | in the default, uncustomized state. |
| 78 | |
Vinay Sajip | 1a90f9c | 2011-01-27 19:14:16 +0000 | [diff] [blame] | 79 | .. versionadded:: 3.2 |
| 80 | |
Vinay Sajip | f97255f | 2011-04-19 13:56:39 +0100 | [diff] [blame] | 81 | .. function:: fileConfig(fname, defaults=None, disable_existing_loggers=True) |
Vinay Sajip | c63619b | 2010-12-19 12:56:57 +0000 | [diff] [blame] | 82 | |
Vinay Sajip | d8b24d7 | 2014-02-04 16:42:04 +0000 | [diff] [blame] | 83 | Reads the logging configuration from a :mod:`configparser`\-format file. The |
| 84 | format of the file should be as described in |
| 85 | :ref:`logging-config-fileformat`. |
Vinay Sajip | cf9e2f2 | 2012-10-09 09:06:03 +0100 | [diff] [blame] | 86 | This function can be called several times from an application, allowing an |
| 87 | end user to select from various pre-canned configurations (if the developer |
| 88 | provides a mechanism to present the choices and load the chosen |
| 89 | configuration). |
| 90 | |
| 91 | :param fname: A filename, or a file-like object, or an instance derived |
| 92 | from :class:`~configparser.RawConfigParser`. If a |
| 93 | ``RawConfigParser``-derived instance is passed, it is used as |
| 94 | is. Otherwise, a :class:`~configparser.Configparser` is |
| 95 | instantiated, and the configuration read by it from the |
| 96 | object passed in ``fname``. If that has a :meth:`readline` |
| 97 | method, it is assumed to be a file-like object and read using |
| 98 | :meth:`~configparser.ConfigParser.read_file`; otherwise, |
| 99 | it is assumed to be a filename and passed to |
| 100 | :meth:`~configparser.ConfigParser.read`. |
| 101 | |
Vinay Sajip | f97255f | 2011-04-19 13:56:39 +0100 | [diff] [blame] | 102 | |
| 103 | :param defaults: Defaults to be passed to the ConfigParser can be specified |
| 104 | in this argument. |
| 105 | |
| 106 | :param disable_existing_loggers: If specified as ``False``, loggers which |
| 107 | exist when this call is made are left |
Vinay Sajip | 12d9ddf | 2014-08-05 10:34:16 +0100 | [diff] [blame] | 108 | enabled. The default is ``True`` because this |
Vinay Sajip | f97255f | 2011-04-19 13:56:39 +0100 | [diff] [blame] | 109 | enables old behaviour in a backward- |
| 110 | compatible way. This behaviour is to |
| 111 | disable any existing loggers unless they or |
| 112 | their ancestors are explicitly named in the |
| 113 | logging configuration. |
Vinay Sajip | c63619b | 2010-12-19 12:56:57 +0000 | [diff] [blame] | 114 | |
Vinay Sajip | cf9e2f2 | 2012-10-09 09:06:03 +0100 | [diff] [blame] | 115 | .. versionchanged:: 3.4 |
| 116 | An instance of a subclass of :class:`~configparser.RawConfigParser` is |
| 117 | now accepted as a value for ``fname``. This facilitates: |
| 118 | |
| 119 | * Use of a configuration file where logging configuration is just part |
| 120 | of the overall application configuration. |
| 121 | * Use of a configuration read from a file, and then modified by the using |
| 122 | application (e.g. based on command-line parameters or other aspects |
| 123 | of the runtime environment) before being passed to ``fileConfig``. |
Vinay Sajip | c63619b | 2010-12-19 12:56:57 +0000 | [diff] [blame] | 124 | |
Vinay Sajip | 4ded551 | 2012-10-02 15:56:16 +0100 | [diff] [blame] | 125 | .. function:: listen(port=DEFAULT_LOGGING_CONFIG_PORT, verify=None) |
Vinay Sajip | c63619b | 2010-12-19 12:56:57 +0000 | [diff] [blame] | 126 | |
| 127 | Starts up a socket server on the specified port, and listens for new |
| 128 | configurations. If no port is specified, the module's default |
| 129 | :const:`DEFAULT_LOGGING_CONFIG_PORT` is used. Logging configurations will be |
| 130 | sent as a file suitable for processing by :func:`fileConfig`. Returns a |
Vinay Sajip | 67f3977 | 2013-08-17 00:39:42 +0100 | [diff] [blame] | 131 | :class:`~threading.Thread` instance on which you can call |
| 132 | :meth:`~threading.Thread.start` to start the server, and which you can |
| 133 | :meth:`~threading.Thread.join` when appropriate. To stop the server, |
Vinay Sajip | c63619b | 2010-12-19 12:56:57 +0000 | [diff] [blame] | 134 | call :func:`stopListening`. |
| 135 | |
Vinay Sajip | 4ded551 | 2012-10-02 15:56:16 +0100 | [diff] [blame] | 136 | The ``verify`` argument, if specified, should be a callable which should |
| 137 | verify whether bytes received across the socket are valid and should be |
| 138 | processed. This could be done by encrypting and/or signing what is sent |
| 139 | across the socket, such that the ``verify`` callable can perform |
| 140 | signature verification and/or decryption. The ``verify`` callable is called |
| 141 | with a single argument - the bytes received across the socket - and should |
| 142 | return the bytes to be processed, or None to indicate that the bytes should |
| 143 | be discarded. The returned bytes could be the same as the passed in bytes |
| 144 | (e.g. when only verification is done), or they could be completely different |
| 145 | (perhaps if decryption were performed). |
| 146 | |
Vinay Sajip | c63619b | 2010-12-19 12:56:57 +0000 | [diff] [blame] | 147 | To send a configuration to the socket, read in the configuration file and |
| 148 | send it to the socket as a string of bytes preceded by a four-byte length |
| 149 | string packed in binary using ``struct.pack('>L', n)``. |
| 150 | |
Larry Hastings | 3732ed2 | 2014-03-15 21:13:56 -0700 | [diff] [blame] | 151 | .. note:: |
| 152 | |
| 153 | Because portions of the configuration are passed through |
Vinay Sajip | 393e23f | 2012-07-25 19:19:25 +0100 | [diff] [blame] | 154 | :func:`eval`, use of this function may open its users to a security risk. |
| 155 | While the function only binds to a socket on ``localhost``, and so does |
| 156 | not accept connections from remote machines, there are scenarios where |
| 157 | untrusted code could be run under the account of the process which calls |
| 158 | :func:`listen`. Specifically, if the process calling :func:`listen` runs |
| 159 | on a multi-user machine where users cannot trust each other, then a |
| 160 | malicious user could arrange to run essentially arbitrary code in a |
| 161 | victim user's process, simply by connecting to the victim's |
| 162 | :func:`listen` socket and sending a configuration which runs whatever |
| 163 | code the attacker wants to have executed in the victim's process. This is |
| 164 | especially easy to do if the default port is used, but not hard even if a |
Vinay Sajip | 4ded551 | 2012-10-02 15:56:16 +0100 | [diff] [blame] | 165 | different port is used). To avoid the risk of this happening, use the |
| 166 | ``verify`` argument to :func:`listen` to prevent unrecognised |
| 167 | configurations from being applied. |
| 168 | |
| 169 | .. versionchanged:: 3.4. |
| 170 | The ``verify`` argument was added. |
Vinay Sajip | c63619b | 2010-12-19 12:56:57 +0000 | [diff] [blame] | 171 | |
| 172 | .. function:: stopListening() |
| 173 | |
| 174 | Stops the listening server which was created with a call to :func:`listen`. |
| 175 | This is typically called before calling :meth:`join` on the return value from |
| 176 | :func:`listen`. |
| 177 | |
| 178 | |
| 179 | .. _logging-config-dictschema: |
| 180 | |
| 181 | Configuration dictionary schema |
| 182 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 183 | |
| 184 | Describing a logging configuration requires listing the various |
| 185 | objects to create and the connections between them; for example, you |
| 186 | may create a handler named 'console' and then say that the logger |
| 187 | named 'startup' will send its messages to the 'console' handler. |
| 188 | These objects aren't limited to those provided by the :mod:`logging` |
| 189 | module because you might write your own formatter or handler class. |
| 190 | The parameters to these classes may also need to include external |
| 191 | objects such as ``sys.stderr``. The syntax for describing these |
| 192 | objects and connections is defined in :ref:`logging-config-dict-connections` |
| 193 | below. |
| 194 | |
| 195 | Dictionary Schema Details |
| 196 | """"""""""""""""""""""""" |
| 197 | |
| 198 | The dictionary passed to :func:`dictConfig` must contain the following |
| 199 | keys: |
| 200 | |
| 201 | * *version* - to be set to an integer value representing the schema |
| 202 | version. The only valid value at present is 1, but having this key |
| 203 | allows the schema to evolve while still preserving backwards |
| 204 | compatibility. |
| 205 | |
| 206 | All other keys are optional, but if present they will be interpreted |
| 207 | as described below. In all cases below where a 'configuring dict' is |
| 208 | mentioned, it will be checked for the special ``'()'`` key to see if a |
| 209 | custom instantiation is required. If so, the mechanism described in |
| 210 | :ref:`logging-config-dict-userdef` below is used to create an instance; |
| 211 | otherwise, the context is used to determine what to instantiate. |
| 212 | |
| 213 | * *formatters* - the corresponding value will be a dict in which each |
| 214 | key is a formatter id and each value is a dict describing how to |
Vinay Sajip | 67f3977 | 2013-08-17 00:39:42 +0100 | [diff] [blame] | 215 | configure the corresponding :class:`~logging.Formatter` instance. |
Vinay Sajip | c63619b | 2010-12-19 12:56:57 +0000 | [diff] [blame] | 216 | |
| 217 | The configuring dict is searched for keys ``format`` and ``datefmt`` |
| 218 | (with defaults of ``None``) and these are used to construct a |
Vinay Sajip | 67f3977 | 2013-08-17 00:39:42 +0100 | [diff] [blame] | 219 | :class:`~logging.Formatter` instance. |
Vinay Sajip | c63619b | 2010-12-19 12:56:57 +0000 | [diff] [blame] | 220 | |
| 221 | * *filters* - the corresponding value will be a dict in which each key |
| 222 | is a filter id and each value is a dict describing how to configure |
| 223 | the corresponding Filter instance. |
| 224 | |
| 225 | The configuring dict is searched for the key ``name`` (defaulting to the |
| 226 | empty string) and this is used to construct a :class:`logging.Filter` |
| 227 | instance. |
| 228 | |
| 229 | * *handlers* - the corresponding value will be a dict in which each |
| 230 | key is a handler id and each value is a dict describing how to |
| 231 | configure the corresponding Handler instance. |
| 232 | |
| 233 | The configuring dict is searched for the following keys: |
| 234 | |
| 235 | * ``class`` (mandatory). This is the fully qualified name of the |
| 236 | handler class. |
| 237 | |
| 238 | * ``level`` (optional). The level of the handler. |
| 239 | |
| 240 | * ``formatter`` (optional). The id of the formatter for this |
| 241 | handler. |
| 242 | |
| 243 | * ``filters`` (optional). A list of ids of the filters for this |
| 244 | handler. |
| 245 | |
| 246 | All *other* keys are passed through as keyword arguments to the |
| 247 | handler's constructor. For example, given the snippet:: |
| 248 | |
| 249 | handlers: |
| 250 | console: |
| 251 | class : logging.StreamHandler |
| 252 | formatter: brief |
| 253 | level : INFO |
| 254 | filters: [allow_foo] |
| 255 | stream : ext://sys.stdout |
| 256 | file: |
| 257 | class : logging.handlers.RotatingFileHandler |
| 258 | formatter: precise |
| 259 | filename: logconfig.log |
| 260 | maxBytes: 1024 |
| 261 | backupCount: 3 |
| 262 | |
| 263 | the handler with id ``console`` is instantiated as a |
| 264 | :class:`logging.StreamHandler`, using ``sys.stdout`` as the underlying |
| 265 | stream. The handler with id ``file`` is instantiated as a |
| 266 | :class:`logging.handlers.RotatingFileHandler` with the keyword arguments |
| 267 | ``filename='logconfig.log', maxBytes=1024, backupCount=3``. |
| 268 | |
| 269 | * *loggers* - the corresponding value will be a dict in which each key |
| 270 | is a logger name and each value is a dict describing how to |
| 271 | configure the corresponding Logger instance. |
| 272 | |
| 273 | The configuring dict is searched for the following keys: |
| 274 | |
| 275 | * ``level`` (optional). The level of the logger. |
| 276 | |
| 277 | * ``propagate`` (optional). The propagation setting of the logger. |
| 278 | |
| 279 | * ``filters`` (optional). A list of ids of the filters for this |
| 280 | logger. |
| 281 | |
| 282 | * ``handlers`` (optional). A list of ids of the handlers for this |
| 283 | logger. |
| 284 | |
| 285 | The specified loggers will be configured according to the level, |
| 286 | propagation, filters and handlers specified. |
| 287 | |
| 288 | * *root* - this will be the configuration for the root logger. |
| 289 | Processing of the configuration will be as for any logger, except |
| 290 | that the ``propagate`` setting will not be applicable. |
| 291 | |
| 292 | * *incremental* - whether the configuration is to be interpreted as |
| 293 | incremental to the existing configuration. This value defaults to |
| 294 | ``False``, which means that the specified configuration replaces the |
| 295 | existing configuration with the same semantics as used by the |
| 296 | existing :func:`fileConfig` API. |
| 297 | |
| 298 | If the specified value is ``True``, the configuration is processed |
| 299 | as described in the section on :ref:`logging-config-dict-incremental`. |
| 300 | |
| 301 | * *disable_existing_loggers* - whether any existing loggers are to be |
| 302 | disabled. This setting mirrors the parameter of the same name in |
| 303 | :func:`fileConfig`. If absent, this parameter defaults to ``True``. |
| 304 | This value is ignored if *incremental* is ``True``. |
| 305 | |
| 306 | .. _logging-config-dict-incremental: |
| 307 | |
| 308 | Incremental Configuration |
| 309 | """"""""""""""""""""""""" |
| 310 | |
| 311 | It is difficult to provide complete flexibility for incremental |
| 312 | configuration. For example, because objects such as filters |
| 313 | and formatters are anonymous, once a configuration is set up, it is |
| 314 | not possible to refer to such anonymous objects when augmenting a |
| 315 | configuration. |
| 316 | |
| 317 | Furthermore, there is not a compelling case for arbitrarily altering |
| 318 | the object graph of loggers, handlers, filters, formatters at |
| 319 | run-time, once a configuration is set up; the verbosity of loggers and |
| 320 | handlers can be controlled just by setting levels (and, in the case of |
| 321 | loggers, propagation flags). Changing the object graph arbitrarily in |
| 322 | a safe way is problematic in a multi-threaded environment; while not |
| 323 | impossible, the benefits are not worth the complexity it adds to the |
| 324 | implementation. |
| 325 | |
| 326 | Thus, when the ``incremental`` key of a configuration dict is present |
| 327 | and is ``True``, the system will completely ignore any ``formatters`` and |
| 328 | ``filters`` entries, and process only the ``level`` |
| 329 | settings in the ``handlers`` entries, and the ``level`` and |
| 330 | ``propagate`` settings in the ``loggers`` and ``root`` entries. |
| 331 | |
| 332 | Using a value in the configuration dict lets configurations to be sent |
| 333 | over the wire as pickled dicts to a socket listener. Thus, the logging |
| 334 | verbosity of a long-running application can be altered over time with |
| 335 | no need to stop and restart the application. |
| 336 | |
| 337 | .. _logging-config-dict-connections: |
| 338 | |
| 339 | Object connections |
| 340 | """""""""""""""""" |
| 341 | |
| 342 | The schema describes a set of logging objects - loggers, |
| 343 | handlers, formatters, filters - which are connected to each other in |
| 344 | an object graph. Thus, the schema needs to represent connections |
| 345 | between the objects. For example, say that, once configured, a |
| 346 | particular logger has attached to it a particular handler. For the |
| 347 | purposes of this discussion, we can say that the logger represents the |
| 348 | source, and the handler the destination, of a connection between the |
| 349 | two. Of course in the configured objects this is represented by the |
| 350 | logger holding a reference to the handler. In the configuration dict, |
| 351 | this is done by giving each destination object an id which identifies |
| 352 | it unambiguously, and then using the id in the source object's |
| 353 | configuration to indicate that a connection exists between the source |
| 354 | and the destination object with that id. |
| 355 | |
| 356 | So, for example, consider the following YAML snippet:: |
| 357 | |
| 358 | formatters: |
| 359 | brief: |
| 360 | # configuration for formatter with id 'brief' goes here |
| 361 | precise: |
| 362 | # configuration for formatter with id 'precise' goes here |
| 363 | handlers: |
| 364 | h1: #This is an id |
| 365 | # configuration of handler with id 'h1' goes here |
| 366 | formatter: brief |
| 367 | h2: #This is another id |
| 368 | # configuration of handler with id 'h2' goes here |
| 369 | formatter: precise |
| 370 | loggers: |
| 371 | foo.bar.baz: |
| 372 | # other configuration for logger 'foo.bar.baz' |
| 373 | handlers: [h1, h2] |
| 374 | |
| 375 | (Note: YAML used here because it's a little more readable than the |
| 376 | equivalent Python source form for the dictionary.) |
| 377 | |
| 378 | The ids for loggers are the logger names which would be used |
| 379 | programmatically to obtain a reference to those loggers, e.g. |
| 380 | ``foo.bar.baz``. The ids for Formatters and Filters can be any string |
| 381 | value (such as ``brief``, ``precise`` above) and they are transient, |
| 382 | in that they are only meaningful for processing the configuration |
| 383 | dictionary and used to determine connections between objects, and are |
| 384 | not persisted anywhere when the configuration call is complete. |
| 385 | |
| 386 | The above snippet indicates that logger named ``foo.bar.baz`` should |
| 387 | have two handlers attached to it, which are described by the handler |
| 388 | ids ``h1`` and ``h2``. The formatter for ``h1`` is that described by id |
| 389 | ``brief``, and the formatter for ``h2`` is that described by id |
| 390 | ``precise``. |
| 391 | |
| 392 | |
| 393 | .. _logging-config-dict-userdef: |
| 394 | |
| 395 | User-defined objects |
| 396 | """""""""""""""""""" |
| 397 | |
| 398 | The schema supports user-defined objects for handlers, filters and |
| 399 | formatters. (Loggers do not need to have different types for |
| 400 | different instances, so there is no support in this configuration |
| 401 | schema for user-defined logger classes.) |
| 402 | |
| 403 | Objects to be configured are described by dictionaries |
| 404 | which detail their configuration. In some places, the logging system |
| 405 | will be able to infer from the context how an object is to be |
| 406 | instantiated, but when a user-defined object is to be instantiated, |
| 407 | the system will not know how to do this. In order to provide complete |
| 408 | flexibility for user-defined object instantiation, the user needs |
| 409 | to provide a 'factory' - a callable which is called with a |
| 410 | configuration dictionary and which returns the instantiated object. |
| 411 | This is signalled by an absolute import path to the factory being |
| 412 | made available under the special key ``'()'``. Here's a concrete |
| 413 | example:: |
| 414 | |
| 415 | formatters: |
| 416 | brief: |
| 417 | format: '%(message)s' |
| 418 | default: |
| 419 | format: '%(asctime)s %(levelname)-8s %(name)-15s %(message)s' |
| 420 | datefmt: '%Y-%m-%d %H:%M:%S' |
| 421 | custom: |
| 422 | (): my.package.customFormatterFactory |
| 423 | bar: baz |
| 424 | spam: 99.9 |
| 425 | answer: 42 |
| 426 | |
| 427 | The above YAML snippet defines three formatters. The first, with id |
| 428 | ``brief``, is a standard :class:`logging.Formatter` instance with the |
| 429 | specified format string. The second, with id ``default``, has a |
| 430 | longer format and also defines the time format explicitly, and will |
| 431 | result in a :class:`logging.Formatter` initialized with those two format |
| 432 | strings. Shown in Python source form, the ``brief`` and ``default`` |
| 433 | formatters have configuration sub-dictionaries:: |
| 434 | |
| 435 | { |
| 436 | 'format' : '%(message)s' |
| 437 | } |
| 438 | |
| 439 | and:: |
| 440 | |
| 441 | { |
| 442 | 'format' : '%(asctime)s %(levelname)-8s %(name)-15s %(message)s', |
| 443 | 'datefmt' : '%Y-%m-%d %H:%M:%S' |
| 444 | } |
| 445 | |
| 446 | respectively, and as these dictionaries do not contain the special key |
| 447 | ``'()'``, the instantiation is inferred from the context: as a result, |
| 448 | standard :class:`logging.Formatter` instances are created. The |
| 449 | configuration sub-dictionary for the third formatter, with id |
| 450 | ``custom``, is:: |
| 451 | |
| 452 | { |
| 453 | '()' : 'my.package.customFormatterFactory', |
| 454 | 'bar' : 'baz', |
| 455 | 'spam' : 99.9, |
| 456 | 'answer' : 42 |
| 457 | } |
| 458 | |
| 459 | and this contains the special key ``'()'``, which means that |
| 460 | user-defined instantiation is wanted. In this case, the specified |
| 461 | factory callable will be used. If it is an actual callable it will be |
| 462 | used directly - otherwise, if you specify a string (as in the example) |
| 463 | the actual callable will be located using normal import mechanisms. |
| 464 | The callable will be called with the **remaining** items in the |
| 465 | configuration sub-dictionary as keyword arguments. In the above |
| 466 | example, the formatter with id ``custom`` will be assumed to be |
| 467 | returned by the call:: |
| 468 | |
| 469 | my.package.customFormatterFactory(bar='baz', spam=99.9, answer=42) |
| 470 | |
| 471 | The key ``'()'`` has been used as the special key because it is not a |
| 472 | valid keyword parameter name, and so will not clash with the names of |
| 473 | the keyword arguments used in the call. The ``'()'`` also serves as a |
| 474 | mnemonic that the corresponding value is a callable. |
| 475 | |
| 476 | |
| 477 | .. _logging-config-dict-externalobj: |
| 478 | |
| 479 | Access to external objects |
| 480 | """""""""""""""""""""""""" |
| 481 | |
| 482 | There are times where a configuration needs to refer to objects |
| 483 | external to the configuration, for example ``sys.stderr``. If the |
| 484 | configuration dict is constructed using Python code, this is |
| 485 | straightforward, but a problem arises when the configuration is |
| 486 | provided via a text file (e.g. JSON, YAML). In a text file, there is |
| 487 | no standard way to distinguish ``sys.stderr`` from the literal string |
| 488 | ``'sys.stderr'``. To facilitate this distinction, the configuration |
| 489 | system looks for certain special prefixes in string values and |
| 490 | treat them specially. For example, if the literal string |
| 491 | ``'ext://sys.stderr'`` is provided as a value in the configuration, |
| 492 | then the ``ext://`` will be stripped off and the remainder of the |
| 493 | value processed using normal import mechanisms. |
| 494 | |
| 495 | The handling of such prefixes is done in a way analogous to protocol |
| 496 | handling: there is a generic mechanism to look for prefixes which |
| 497 | match the regular expression ``^(?P<prefix>[a-z]+)://(?P<suffix>.*)$`` |
| 498 | whereby, if the ``prefix`` is recognised, the ``suffix`` is processed |
| 499 | in a prefix-dependent manner and the result of the processing replaces |
| 500 | the string value. If the prefix is not recognised, then the string |
| 501 | value will be left as-is. |
| 502 | |
| 503 | |
| 504 | .. _logging-config-dict-internalobj: |
| 505 | |
| 506 | Access to internal objects |
| 507 | """""""""""""""""""""""""" |
| 508 | |
| 509 | As well as external objects, there is sometimes also a need to refer |
| 510 | to objects in the configuration. This will be done implicitly by the |
| 511 | configuration system for things that it knows about. For example, the |
| 512 | string value ``'DEBUG'`` for a ``level`` in a logger or handler will |
| 513 | automatically be converted to the value ``logging.DEBUG``, and the |
| 514 | ``handlers``, ``filters`` and ``formatter`` entries will take an |
| 515 | object id and resolve to the appropriate destination object. |
| 516 | |
| 517 | However, a more generic mechanism is needed for user-defined |
| 518 | objects which are not known to the :mod:`logging` module. For |
| 519 | example, consider :class:`logging.handlers.MemoryHandler`, which takes |
| 520 | a ``target`` argument which is another handler to delegate to. Since |
| 521 | the system already knows about this class, then in the configuration, |
| 522 | the given ``target`` just needs to be the object id of the relevant |
| 523 | target handler, and the system will resolve to the handler from the |
| 524 | id. If, however, a user defines a ``my.package.MyHandler`` which has |
| 525 | an ``alternate`` handler, the configuration system would not know that |
| 526 | the ``alternate`` referred to a handler. To cater for this, a generic |
| 527 | resolution system allows the user to specify:: |
| 528 | |
| 529 | handlers: |
| 530 | file: |
| 531 | # configuration of file handler goes here |
| 532 | |
| 533 | custom: |
| 534 | (): my.package.MyHandler |
| 535 | alternate: cfg://handlers.file |
| 536 | |
| 537 | The literal string ``'cfg://handlers.file'`` will be resolved in an |
| 538 | analogous way to strings with the ``ext://`` prefix, but looking |
| 539 | in the configuration itself rather than the import namespace. The |
| 540 | mechanism allows access by dot or by index, in a similar way to |
| 541 | that provided by ``str.format``. Thus, given the following snippet:: |
| 542 | |
| 543 | handlers: |
| 544 | email: |
| 545 | class: logging.handlers.SMTPHandler |
| 546 | mailhost: localhost |
| 547 | fromaddr: my_app@domain.tld |
| 548 | toaddrs: |
| 549 | - support_team@domain.tld |
| 550 | - dev_team@domain.tld |
| 551 | subject: Houston, we have a problem. |
| 552 | |
| 553 | in the configuration, the string ``'cfg://handlers'`` would resolve to |
| 554 | the dict with key ``handlers``, the string ``'cfg://handlers.email`` |
| 555 | would resolve to the dict with key ``email`` in the ``handlers`` dict, |
| 556 | and so on. The string ``'cfg://handlers.email.toaddrs[1]`` would |
| 557 | resolve to ``'dev_team.domain.tld'`` and the string |
| 558 | ``'cfg://handlers.email.toaddrs[0]'`` would resolve to the value |
| 559 | ``'support_team@domain.tld'``. The ``subject`` value could be accessed |
| 560 | using either ``'cfg://handlers.email.subject'`` or, equivalently, |
| 561 | ``'cfg://handlers.email[subject]'``. The latter form only needs to be |
| 562 | used if the key contains spaces or non-alphanumeric characters. If an |
| 563 | index value consists only of decimal digits, access will be attempted |
| 564 | using the corresponding integer value, falling back to the string |
| 565 | value if needed. |
| 566 | |
| 567 | Given a string ``cfg://handlers.myhandler.mykey.123``, this will |
| 568 | resolve to ``config_dict['handlers']['myhandler']['mykey']['123']``. |
| 569 | If the string is specified as ``cfg://handlers.myhandler.mykey[123]``, |
| 570 | the system will attempt to retrieve the value from |
| 571 | ``config_dict['handlers']['myhandler']['mykey'][123]``, and fall back |
| 572 | to ``config_dict['handlers']['myhandler']['mykey']['123']`` if that |
| 573 | fails. |
| 574 | |
Vinay Sajip | 817495a | 2011-08-11 13:45:48 +0100 | [diff] [blame] | 575 | |
| 576 | .. _logging-import-resolution: |
| 577 | |
| 578 | Import resolution and custom importers |
| 579 | """""""""""""""""""""""""""""""""""""" |
| 580 | |
| 581 | Import resolution, by default, uses the builtin :func:`__import__` function |
| 582 | to do its importing. You may want to replace this with your own importing |
| 583 | mechanism: if so, you can replace the :attr:`importer` attribute of the |
| 584 | :class:`DictConfigurator` or its superclass, the |
| 585 | :class:`BaseConfigurator` class. However, you need to be |
| 586 | careful because of the way functions are accessed from classes via |
| 587 | descriptors. If you are using a Python callable to do your imports, and you |
| 588 | want to define it at class level rather than instance level, you need to wrap |
| 589 | it with :func:`staticmethod`. For example:: |
| 590 | |
| 591 | from importlib import import_module |
| 592 | from logging.config import BaseConfigurator |
| 593 | |
| 594 | BaseConfigurator.importer = staticmethod(import_module) |
| 595 | |
| 596 | You don't need to wrap with :func:`staticmethod` if you're setting the import |
| 597 | callable on a configurator *instance*. |
| 598 | |
| 599 | |
Vinay Sajip | c63619b | 2010-12-19 12:56:57 +0000 | [diff] [blame] | 600 | .. _logging-config-fileformat: |
| 601 | |
| 602 | Configuration file format |
| 603 | ^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 604 | |
| 605 | The configuration file format understood by :func:`fileConfig` is based on |
| 606 | :mod:`configparser` functionality. The file must contain sections called |
| 607 | ``[loggers]``, ``[handlers]`` and ``[formatters]`` which identify by name the |
| 608 | entities of each type which are defined in the file. For each such entity, there |
| 609 | is a separate section which identifies how that entity is configured. Thus, for |
| 610 | a logger named ``log01`` in the ``[loggers]`` section, the relevant |
| 611 | configuration details are held in a section ``[logger_log01]``. Similarly, a |
| 612 | handler called ``hand01`` in the ``[handlers]`` section will have its |
| 613 | configuration held in a section called ``[handler_hand01]``, while a formatter |
| 614 | called ``form01`` in the ``[formatters]`` section will have its configuration |
| 615 | specified in a section called ``[formatter_form01]``. The root logger |
| 616 | configuration must be specified in a section called ``[logger_root]``. |
| 617 | |
| 618 | Examples of these sections in the file are given below. :: |
| 619 | |
| 620 | [loggers] |
| 621 | keys=root,log02,log03,log04,log05,log06,log07 |
| 622 | |
| 623 | [handlers] |
| 624 | keys=hand01,hand02,hand03,hand04,hand05,hand06,hand07,hand08,hand09 |
| 625 | |
| 626 | [formatters] |
| 627 | keys=form01,form02,form03,form04,form05,form06,form07,form08,form09 |
| 628 | |
| 629 | The root logger must specify a level and a list of handlers. An example of a |
| 630 | root logger section is given below. :: |
| 631 | |
| 632 | [logger_root] |
| 633 | level=NOTSET |
| 634 | handlers=hand01 |
| 635 | |
| 636 | The ``level`` entry can be one of ``DEBUG, INFO, WARNING, ERROR, CRITICAL`` or |
| 637 | ``NOTSET``. For the root logger only, ``NOTSET`` means that all messages will be |
| 638 | logged. Level values are :func:`eval`\ uated in the context of the ``logging`` |
| 639 | package's namespace. |
| 640 | |
| 641 | The ``handlers`` entry is a comma-separated list of handler names, which must |
| 642 | appear in the ``[handlers]`` section. These names must appear in the |
| 643 | ``[handlers]`` section and have corresponding sections in the configuration |
| 644 | file. |
| 645 | |
| 646 | For loggers other than the root logger, some additional information is required. |
| 647 | This is illustrated by the following example. :: |
| 648 | |
| 649 | [logger_parser] |
| 650 | level=DEBUG |
| 651 | handlers=hand01 |
| 652 | propagate=1 |
| 653 | qualname=compiler.parser |
| 654 | |
| 655 | The ``level`` and ``handlers`` entries are interpreted as for the root logger, |
| 656 | except that if a non-root logger's level is specified as ``NOTSET``, the system |
| 657 | consults loggers higher up the hierarchy to determine the effective level of the |
| 658 | logger. The ``propagate`` entry is set to 1 to indicate that messages must |
| 659 | propagate to handlers higher up the logger hierarchy from this logger, or 0 to |
| 660 | indicate that messages are **not** propagated to handlers up the hierarchy. The |
| 661 | ``qualname`` entry is the hierarchical channel name of the logger, that is to |
| 662 | say the name used by the application to get the logger. |
| 663 | |
| 664 | Sections which specify handler configuration are exemplified by the following. |
| 665 | :: |
| 666 | |
| 667 | [handler_hand01] |
| 668 | class=StreamHandler |
| 669 | level=NOTSET |
| 670 | formatter=form01 |
| 671 | args=(sys.stdout,) |
| 672 | |
| 673 | The ``class`` entry indicates the handler's class (as determined by :func:`eval` |
| 674 | in the ``logging`` package's namespace). The ``level`` is interpreted as for |
| 675 | loggers, and ``NOTSET`` is taken to mean 'log everything'. |
| 676 | |
| 677 | The ``formatter`` entry indicates the key name of the formatter for this |
| 678 | handler. If blank, a default formatter (``logging._defaultFormatter``) is used. |
| 679 | If a name is specified, it must appear in the ``[formatters]`` section and have |
| 680 | a corresponding section in the configuration file. |
| 681 | |
| 682 | The ``args`` entry, when :func:`eval`\ uated in the context of the ``logging`` |
| 683 | package's namespace, is the list of arguments to the constructor for the handler |
| 684 | class. Refer to the constructors for the relevant handlers, or to the examples |
| 685 | below, to see how typical entries are constructed. :: |
| 686 | |
| 687 | [handler_hand02] |
| 688 | class=FileHandler |
| 689 | level=DEBUG |
| 690 | formatter=form02 |
| 691 | args=('python.log', 'w') |
| 692 | |
| 693 | [handler_hand03] |
| 694 | class=handlers.SocketHandler |
| 695 | level=INFO |
| 696 | formatter=form03 |
| 697 | args=('localhost', handlers.DEFAULT_TCP_LOGGING_PORT) |
| 698 | |
| 699 | [handler_hand04] |
| 700 | class=handlers.DatagramHandler |
| 701 | level=WARN |
| 702 | formatter=form04 |
| 703 | args=('localhost', handlers.DEFAULT_UDP_LOGGING_PORT) |
| 704 | |
| 705 | [handler_hand05] |
| 706 | class=handlers.SysLogHandler |
| 707 | level=ERROR |
| 708 | formatter=form05 |
| 709 | args=(('localhost', handlers.SYSLOG_UDP_PORT), handlers.SysLogHandler.LOG_USER) |
| 710 | |
| 711 | [handler_hand06] |
| 712 | class=handlers.NTEventLogHandler |
| 713 | level=CRITICAL |
| 714 | formatter=form06 |
| 715 | args=('Python Application', '', 'Application') |
| 716 | |
| 717 | [handler_hand07] |
| 718 | class=handlers.SMTPHandler |
| 719 | level=WARN |
| 720 | formatter=form07 |
| 721 | args=('localhost', 'from@abc', ['user1@abc', 'user2@xyz'], 'Logger Subject') |
| 722 | |
| 723 | [handler_hand08] |
| 724 | class=handlers.MemoryHandler |
| 725 | level=NOTSET |
| 726 | formatter=form08 |
| 727 | target= |
| 728 | args=(10, ERROR) |
| 729 | |
| 730 | [handler_hand09] |
| 731 | class=handlers.HTTPHandler |
| 732 | level=NOTSET |
| 733 | formatter=form09 |
| 734 | args=('localhost:9022', '/log', 'GET') |
| 735 | |
| 736 | Sections which specify formatter configuration are typified by the following. :: |
| 737 | |
| 738 | [formatter_form01] |
| 739 | format=F1 %(asctime)s %(levelname)s %(message)s |
| 740 | datefmt= |
| 741 | class=logging.Formatter |
| 742 | |
| 743 | The ``format`` entry is the overall format string, and the ``datefmt`` entry is |
| 744 | the :func:`strftime`\ -compatible date/time format string. If empty, the |
| 745 | package substitutes ISO8601 format date/times, which is almost equivalent to |
| 746 | specifying the date format string ``'%Y-%m-%d %H:%M:%S'``. The ISO8601 format |
| 747 | also specifies milliseconds, which are appended to the result of using the above |
| 748 | format string, with a comma separator. An example time in ISO8601 format is |
| 749 | ``2003-01-23 00:29:50,411``. |
| 750 | |
| 751 | The ``class`` entry is optional. It indicates the name of the formatter's class |
| 752 | (as a dotted module and class name.) This option is useful for instantiating a |
Vinay Sajip | 67f3977 | 2013-08-17 00:39:42 +0100 | [diff] [blame] | 753 | :class:`~logging.Formatter` subclass. Subclasses of |
| 754 | :class:`~logging.Formatter` can present exception tracebacks in an expanded or |
| 755 | condensed format. |
Vinay Sajip | c63619b | 2010-12-19 12:56:57 +0000 | [diff] [blame] | 756 | |
Larry Hastings | 3732ed2 | 2014-03-15 21:13:56 -0700 | [diff] [blame] | 757 | .. note:: |
| 758 | |
| 759 | Due to the use of :func:`eval` as described above, there are |
Vinay Sajip | 393e23f | 2012-07-25 19:19:25 +0100 | [diff] [blame] | 760 | potential security risks which result from using the :func:`listen` to send |
| 761 | and receive configurations via sockets. The risks are limited to where |
| 762 | multiple users with no mutual trust run code on the same machine; see the |
| 763 | :func:`listen` documentation for more information. |
| 764 | |
Vinay Sajip | c63619b | 2010-12-19 12:56:57 +0000 | [diff] [blame] | 765 | .. seealso:: |
| 766 | |
| 767 | Module :mod:`logging` |
| 768 | API reference for the logging module. |
| 769 | |
| 770 | Module :mod:`logging.handlers` |
| 771 | Useful handlers included with the logging module. |
| 772 | |
| 773 | |