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