1 :mod:`logging.handlers` --- Logging handlers 2 ============================================ 3 4 .. module:: logging.handlers 5 :synopsis: Handlers for the logging module. 6 7 8 .. moduleauthor:: Vinay Sajip <vinay_sajip (a] red-dove.com> 9 .. sectionauthor:: Vinay Sajip <vinay_sajip (a] red-dove.com> 10 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 **Source code:** :source:`Lib/logging/handlers.py` 21 22 -------------- 23 24 .. currentmodule:: logging 25 26 The following useful handlers are provided in the package. Note that three of 27 the handlers (:class:`StreamHandler`, :class:`FileHandler` and 28 :class:`NullHandler`) are actually defined in the :mod:`logging` module itself, 29 but have been documented here along with the other handlers. 30 31 .. _stream-handler: 32 33 StreamHandler 34 ^^^^^^^^^^^^^ 35 36 The :class:`StreamHandler` class, located in the core :mod:`logging` package, 37 sends logging output to streams such as *sys.stdout*, *sys.stderr* or any 38 file-like object (or, more precisely, any object which supports :meth:`write` 39 and :meth:`flush` methods). 40 41 42 .. class:: StreamHandler(stream=None) 43 44 Returns a new instance of the :class:`StreamHandler` class. If *stream* is 45 specified, the instance will use it for logging output; otherwise, *sys.stderr* 46 will be used. 47 48 49 .. method:: emit(record) 50 51 If a formatter is specified, it is used to format the record. The record 52 is then written to the stream with a newline terminator. If exception 53 information is present, it is formatted using 54 :func:`traceback.print_exception` and appended to the stream. 55 56 57 .. method:: flush() 58 59 Flushes the stream by calling its :meth:`flush` method. Note that the 60 :meth:`close` method is inherited from :class:`~logging.Handler` and so 61 does no output, so an explicit :meth:`flush` call may be needed at times. 62 63 .. _file-handler: 64 65 FileHandler 66 ^^^^^^^^^^^ 67 68 The :class:`FileHandler` class, located in the core :mod:`logging` package, 69 sends logging output to a disk file. It inherits the output functionality from 70 :class:`StreamHandler`. 71 72 73 .. class:: FileHandler(filename, mode='a', encoding=None, delay=False) 74 75 Returns a new instance of the :class:`FileHandler` class. The specified file is 76 opened and used as the stream for logging. If *mode* is not specified, 77 :const:`'a'` is used. If *encoding* is not ``None``, it is used to open the file 78 with that encoding. If *delay* is true, then file opening is deferred until the 79 first call to :meth:`emit`. By default, the file grows indefinitely. 80 81 .. versionchanged:: 2.6 82 *delay* was added. 83 84 .. method:: close() 85 86 Closes the file. 87 88 89 .. method:: emit(record) 90 91 Outputs the record to the file. 92 93 94 .. _null-handler: 95 96 NullHandler 97 ^^^^^^^^^^^ 98 99 .. versionadded:: 2.7 100 101 The :class:`NullHandler` class, located in the core :mod:`logging` package, 102 does not do any formatting or output. It is essentially a 'no-op' handler 103 for use by library developers. 104 105 .. class:: NullHandler() 106 107 Returns a new instance of the :class:`NullHandler` class. 108 109 .. method:: emit(record) 110 111 This method does nothing. 112 113 .. method:: handle(record) 114 115 This method does nothing. 116 117 .. method:: createLock() 118 119 This method returns ``None`` for the lock, since there is no 120 underlying I/O to which access needs to be serialized. 121 122 123 See :ref:`library-config` for more information on how to use 124 :class:`NullHandler`. 125 126 .. _watched-file-handler: 127 128 WatchedFileHandler 129 ^^^^^^^^^^^^^^^^^^ 130 131 .. currentmodule:: logging.handlers 132 133 .. versionadded:: 2.6 134 135 The :class:`WatchedFileHandler` class, located in the :mod:`logging.handlers` 136 module, is a :class:`FileHandler` which watches the file it is logging to. If 137 the file changes, it is closed and reopened using the file name. 138 139 A file change can happen because of usage of programs such as *newsyslog* and 140 *logrotate* which perform log file rotation. This handler, intended for use 141 under Unix/Linux, watches the file to see if it has changed since the last emit. 142 (A file is deemed to have changed if its device or inode have changed.) If the 143 file has changed, the old file stream is closed, and the file opened to get a 144 new stream. 145 146 This handler is not appropriate for use under Windows, because under Windows 147 open log files cannot be moved or renamed - logging opens the files with 148 exclusive locks - and so there is no need for such a handler. Furthermore, 149 *ST_INO* is not supported under Windows; :func:`~os.stat` always returns zero 150 for this value. 151 152 153 .. class:: WatchedFileHandler(filename[,mode[, encoding[, delay]]]) 154 155 Returns a new instance of the :class:`WatchedFileHandler` class. The specified 156 file is opened and used as the stream for logging. If *mode* is not specified, 157 :const:`'a'` is used. If *encoding* is not ``None``, it is used to open the file 158 with that encoding. If *delay* is true, then file opening is deferred until the 159 first call to :meth:`emit`. By default, the file grows indefinitely. 160 161 162 .. method:: emit(record) 163 164 Outputs the record to the file, but first checks to see if the file has 165 changed. If it has, the existing stream is flushed and closed and the 166 file opened again, before outputting the record to the file. 167 168 .. _rotating-file-handler: 169 170 RotatingFileHandler 171 ^^^^^^^^^^^^^^^^^^^ 172 173 The :class:`RotatingFileHandler` class, located in the :mod:`logging.handlers` 174 module, supports rotation of disk log files. 175 176 177 .. class:: RotatingFileHandler(filename, mode='a', maxBytes=0, backupCount=0, encoding=None, delay=0) 178 179 Returns a new instance of the :class:`RotatingFileHandler` class. The specified 180 file is opened and used as the stream for logging. If *mode* is not specified, 181 ``'a'`` is used. If *encoding* is not ``None``, it is used to open the file 182 with that encoding. If *delay* is true, then file opening is deferred until the 183 first call to :meth:`emit`. By default, the file grows indefinitely. 184 185 You can use the *maxBytes* and *backupCount* values to allow the file to 186 :dfn:`rollover` at a predetermined size. When the size is about to be exceeded, 187 the file is closed and a new file is silently opened for output. Rollover occurs 188 whenever the current log file is nearly *maxBytes* in length; if either of 189 *maxBytes* or *backupCount* is zero, rollover never occurs. If *backupCount* 190 is non-zero, the system will save old log files by appending the extensions 191 '.1', '.2' etc., to the filename. For example, with a *backupCount* of 5 and 192 a base file name of :file:`app.log`, you would get :file:`app.log`, 193 :file:`app.log.1`, :file:`app.log.2`, up to :file:`app.log.5`. The file being 194 written to is always :file:`app.log`. When this file is filled, it is closed 195 and renamed to :file:`app.log.1`, and if files :file:`app.log.1`, 196 :file:`app.log.2`, etc. exist, then they are renamed to :file:`app.log.2`, 197 :file:`app.log.3` etc. respectively. 198 199 .. versionchanged:: 2.6 200 *delay* was added. 201 202 203 .. method:: doRollover() 204 205 Does a rollover, as described above. 206 207 208 .. method:: emit(record) 209 210 Outputs the record to the file, catering for rollover as described 211 previously. 212 213 .. _timed-rotating-file-handler: 214 215 TimedRotatingFileHandler 216 ^^^^^^^^^^^^^^^^^^^^^^^^ 217 218 The :class:`TimedRotatingFileHandler` class, located in the 219 :mod:`logging.handlers` module, supports rotation of disk log files at certain 220 timed intervals. 221 222 223 .. class:: TimedRotatingFileHandler(filename, when='h', interval=1, backupCount=0, encoding=None, delay=False, utc=False) 224 225 Returns a new instance of the :class:`TimedRotatingFileHandler` class. The 226 specified file is opened and used as the stream for logging. On rotating it also 227 sets the filename suffix. Rotating happens based on the product of *when* and 228 *interval*. 229 230 You can use the *when* to specify the type of *interval*. The list of possible 231 values is below. Note that they are not case sensitive. 232 233 +----------------+-----------------------+ 234 | Value | Type of interval | 235 +================+=======================+ 236 | ``'S'`` | Seconds | 237 +----------------+-----------------------+ 238 | ``'M'`` | Minutes | 239 +----------------+-----------------------+ 240 | ``'H'`` | Hours | 241 +----------------+-----------------------+ 242 | ``'D'`` | Days | 243 +----------------+-----------------------+ 244 | ``'W0'-'W6'`` | Weekday (0=Monday) | 245 +----------------+-----------------------+ 246 | ``'midnight'`` | Roll over at midnight | 247 +----------------+-----------------------+ 248 249 When using weekday-based rotation, specify 'W0' for Monday, 'W1' for 250 Tuesday, and so on up to 'W6' for Sunday. In this case, the value passed for 251 *interval* isn't used. 252 253 The system will save old log files by appending extensions to the filename. 254 The extensions are date-and-time based, using the strftime format 255 ``%Y-%m-%d_%H-%M-%S`` or a leading portion thereof, depending on the 256 rollover interval. 257 258 When computing the next rollover time for the first time (when the handler 259 is created), the last modification time of an existing log file, or else 260 the current time, is used to compute when the next rotation will occur. 261 262 If the *utc* argument is true, times in UTC will be used; otherwise 263 local time is used. 264 265 If *backupCount* is nonzero, at most *backupCount* files 266 will be kept, and if more would be created when rollover occurs, the oldest 267 one is deleted. The deletion logic uses the interval to determine which 268 files to delete, so changing the interval may leave old files lying around. 269 270 If *delay* is true, then file opening is deferred until the first call to 271 :meth:`emit`. 272 273 .. versionchanged:: 2.6 274 *delay* and *utc* were added. 275 276 277 .. method:: doRollover() 278 279 Does a rollover, as described above. 280 281 282 .. method:: emit(record) 283 284 Outputs the record to the file, catering for rollover as described above. 285 286 287 .. _socket-handler: 288 289 SocketHandler 290 ^^^^^^^^^^^^^ 291 292 The :class:`SocketHandler` class, located in the :mod:`logging.handlers` module, 293 sends logging output to a network socket. The base class uses a TCP socket. 294 295 296 .. class:: SocketHandler(host, port) 297 298 Returns a new instance of the :class:`SocketHandler` class intended to 299 communicate with a remote machine whose address is given by *host* and *port*. 300 301 302 .. method:: close() 303 304 Closes the socket. 305 306 307 .. method:: emit() 308 309 Pickles the record's attribute dictionary and writes it to the socket in 310 binary format. If there is an error with the socket, silently drops the 311 packet. If the connection was previously lost, re-establishes the 312 connection. To unpickle the record at the receiving end into a 313 :class:`~logging.LogRecord`, use the :func:`~logging.makeLogRecord` 314 function. 315 316 317 .. method:: handleError() 318 319 Handles an error which has occurred during :meth:`emit`. The most likely 320 cause is a lost connection. Closes the socket so that we can retry on the 321 next event. 322 323 324 .. method:: makeSocket() 325 326 This is a factory method which allows subclasses to define the precise 327 type of socket they want. The default implementation creates a TCP socket 328 (:const:`socket.SOCK_STREAM`). 329 330 331 .. method:: makePickle(record) 332 333 Pickles the record's attribute dictionary in binary format with a length 334 prefix, and returns it ready for transmission across the socket. 335 336 Note that pickles aren't completely secure. If you are concerned about 337 security, you may want to override this method to implement a more secure 338 mechanism. For example, you can sign pickles using HMAC and then verify 339 them on the receiving end, or alternatively you can disable unpickling of 340 global objects on the receiving end. 341 342 343 .. method:: send(packet) 344 345 Send a pickled string *packet* to the socket. This function allows for 346 partial sends which can happen when the network is busy. 347 348 349 .. method:: createSocket() 350 351 Tries to create a socket; on failure, uses an exponential back-off 352 algorithm. On initial failure, the handler will drop the message it was 353 trying to send. When subsequent messages are handled by the same 354 instance, it will not try connecting until some time has passed. The 355 default parameters are such that the initial delay is one second, and if 356 after that delay the connection still can't be made, the handler will 357 double the delay each time up to a maximum of 30 seconds. 358 359 This behaviour is controlled by the following handler attributes: 360 361 * ``retryStart`` (initial delay, defaulting to 1.0 seconds). 362 * ``retryFactor`` (multiplier, defaulting to 2.0). 363 * ``retryMax`` (maximum delay, defaulting to 30.0 seconds). 364 365 This means that if the remote listener starts up *after* the handler has 366 been used, you could lose messages (since the handler won't even attempt 367 a connection until the delay has elapsed, but just silently drop messages 368 during the delay period). 369 370 371 .. _datagram-handler: 372 373 DatagramHandler 374 ^^^^^^^^^^^^^^^ 375 376 The :class:`DatagramHandler` class, located in the :mod:`logging.handlers` 377 module, inherits from :class:`SocketHandler` to support sending logging messages 378 over UDP sockets. 379 380 381 .. class:: DatagramHandler(host, port) 382 383 Returns a new instance of the :class:`DatagramHandler` class intended to 384 communicate with a remote machine whose address is given by *host* and *port*. 385 386 387 .. method:: emit() 388 389 Pickles the record's attribute dictionary and writes it to the socket in 390 binary format. If there is an error with the socket, silently drops the 391 packet. To unpickle the record at the receiving end into a 392 :class:`~logging.LogRecord`, use the :func:`~logging.makeLogRecord` 393 function. 394 395 396 .. method:: makeSocket() 397 398 The factory method of :class:`SocketHandler` is here overridden to create 399 a UDP socket (:const:`socket.SOCK_DGRAM`). 400 401 402 .. method:: send(s) 403 404 Send a pickled string to a socket. 405 406 407 .. _syslog-handler: 408 409 SysLogHandler 410 ^^^^^^^^^^^^^ 411 412 The :class:`SysLogHandler` class, located in the :mod:`logging.handlers` module, 413 supports sending logging messages to a remote or local Unix syslog. 414 415 416 .. class:: SysLogHandler(address=('localhost', SYSLOG_UDP_PORT), facility=LOG_USER, socktype=socket.SOCK_DGRAM) 417 418 Returns a new instance of the :class:`SysLogHandler` class intended to 419 communicate with a remote Unix machine whose address is given by *address* in 420 the form of a ``(host, port)`` tuple. If *address* is not specified, 421 ``('localhost', 514)`` is used. The address is used to open a socket. An 422 alternative to providing a ``(host, port)`` tuple is providing an address as a 423 string, for example '/dev/log'. In this case, a Unix domain socket is used to 424 send the message to the syslog. If *facility* is not specified, 425 :const:`LOG_USER` is used. The type of socket opened depends on the 426 *socktype* argument, which defaults to :const:`socket.SOCK_DGRAM` and thus 427 opens a UDP socket. To open a TCP socket (for use with the newer syslog 428 daemons such as rsyslog), specify a value of :const:`socket.SOCK_STREAM`. 429 430 Note that if your server is not listening on UDP port 514, 431 :class:`SysLogHandler` may appear not to work. In that case, check what 432 address you should be using for a domain socket - it's system dependent. 433 For example, on Linux it's usually '/dev/log' but on OS/X it's 434 '/var/run/syslog'. You'll need to check your platform and use the 435 appropriate address (you may need to do this check at runtime if your 436 application needs to run on several platforms). On Windows, you pretty 437 much have to use the UDP option. 438 439 .. versionchanged:: 2.7 440 *socktype* was added. 441 442 443 .. method:: close() 444 445 Closes the socket to the remote host. 446 447 448 .. method:: emit(record) 449 450 The record is formatted, and then sent to the syslog server. If exception 451 information is present, it is *not* sent to the server. 452 453 454 .. method:: encodePriority(facility, priority) 455 456 Encodes the facility and priority into an integer. You can pass in strings 457 or integers - if strings are passed, internal mapping dictionaries are 458 used to convert them to integers. 459 460 The symbolic ``LOG_`` values are defined in :class:`SysLogHandler` and 461 mirror the values defined in the ``sys/syslog.h`` header file. 462 463 **Priorities** 464 465 +--------------------------+---------------+ 466 | Name (string) | Symbolic value| 467 +==========================+===============+ 468 | ``alert`` | LOG_ALERT | 469 +--------------------------+---------------+ 470 | ``crit`` or ``critical`` | LOG_CRIT | 471 +--------------------------+---------------+ 472 | ``debug`` | LOG_DEBUG | 473 +--------------------------+---------------+ 474 | ``emerg`` or ``panic`` | LOG_EMERG | 475 +--------------------------+---------------+ 476 | ``err`` or ``error`` | LOG_ERR | 477 +--------------------------+---------------+ 478 | ``info`` | LOG_INFO | 479 +--------------------------+---------------+ 480 | ``notice`` | LOG_NOTICE | 481 +--------------------------+---------------+ 482 | ``warn`` or ``warning`` | LOG_WARNING | 483 +--------------------------+---------------+ 484 485 **Facilities** 486 487 +---------------+---------------+ 488 | Name (string) | Symbolic value| 489 +===============+===============+ 490 | ``auth`` | LOG_AUTH | 491 +---------------+---------------+ 492 | ``authpriv`` | LOG_AUTHPRIV | 493 +---------------+---------------+ 494 | ``cron`` | LOG_CRON | 495 +---------------+---------------+ 496 | ``daemon`` | LOG_DAEMON | 497 +---------------+---------------+ 498 | ``ftp`` | LOG_FTP | 499 +---------------+---------------+ 500 | ``kern`` | LOG_KERN | 501 +---------------+---------------+ 502 | ``lpr`` | LOG_LPR | 503 +---------------+---------------+ 504 | ``mail`` | LOG_MAIL | 505 +---------------+---------------+ 506 | ``news`` | LOG_NEWS | 507 +---------------+---------------+ 508 | ``syslog`` | LOG_SYSLOG | 509 +---------------+---------------+ 510 | ``user`` | LOG_USER | 511 +---------------+---------------+ 512 | ``uucp`` | LOG_UUCP | 513 +---------------+---------------+ 514 | ``local0`` | LOG_LOCAL0 | 515 +---------------+---------------+ 516 | ``local1`` | LOG_LOCAL1 | 517 +---------------+---------------+ 518 | ``local2`` | LOG_LOCAL2 | 519 +---------------+---------------+ 520 | ``local3`` | LOG_LOCAL3 | 521 +---------------+---------------+ 522 | ``local4`` | LOG_LOCAL4 | 523 +---------------+---------------+ 524 | ``local5`` | LOG_LOCAL5 | 525 +---------------+---------------+ 526 | ``local6`` | LOG_LOCAL6 | 527 +---------------+---------------+ 528 | ``local7`` | LOG_LOCAL7 | 529 +---------------+---------------+ 530 531 .. method:: mapPriority(levelname) 532 533 Maps a logging level name to a syslog priority name. 534 You may need to override this if you are using custom levels, or 535 if the default algorithm is not suitable for your needs. The 536 default algorithm maps ``DEBUG``, ``INFO``, ``WARNING``, ``ERROR`` and 537 ``CRITICAL`` to the equivalent syslog names, and all other level 538 names to 'warning'. 539 540 .. _nt-eventlog-handler: 541 542 NTEventLogHandler 543 ^^^^^^^^^^^^^^^^^ 544 545 The :class:`NTEventLogHandler` class, located in the :mod:`logging.handlers` 546 module, supports sending logging messages to a local Windows NT, Windows 2000 or 547 Windows XP event log. Before you can use it, you need Mark Hammond's Win32 548 extensions for Python installed. 549 550 551 .. class:: NTEventLogHandler(appname, dllname=None, logtype='Application') 552 553 Returns a new instance of the :class:`NTEventLogHandler` class. The *appname* is 554 used to define the application name as it appears in the event log. An 555 appropriate registry entry is created using this name. The *dllname* should give 556 the fully qualified pathname of a .dll or .exe which contains message 557 definitions to hold in the log (if not specified, ``'win32service.pyd'`` is used 558 - this is installed with the Win32 extensions and contains some basic 559 placeholder message definitions. Note that use of these placeholders will make 560 your event logs big, as the entire message source is held in the log. If you 561 want slimmer logs, you have to pass in the name of your own .dll or .exe which 562 contains the message definitions you want to use in the event log). The 563 *logtype* is one of ``'Application'``, ``'System'`` or ``'Security'``, and 564 defaults to ``'Application'``. 565 566 567 .. method:: close() 568 569 At this point, you can remove the application name from the registry as a 570 source of event log entries. However, if you do this, you will not be able 571 to see the events as you intended in the Event Log Viewer - it needs to be 572 able to access the registry to get the .dll name. The current version does 573 not do this. 574 575 576 .. method:: emit(record) 577 578 Determines the message ID, event category and event type, and then logs 579 the message in the NT event log. 580 581 582 .. method:: getEventCategory(record) 583 584 Returns the event category for the record. Override this if you want to 585 specify your own categories. This version returns 0. 586 587 588 .. method:: getEventType(record) 589 590 Returns the event type for the record. Override this if you want to 591 specify your own types. This version does a mapping using the handler's 592 typemap attribute, which is set up in :meth:`__init__` to a dictionary 593 which contains mappings for :const:`DEBUG`, :const:`INFO`, 594 :const:`WARNING`, :const:`ERROR` and :const:`CRITICAL`. If you are using 595 your own levels, you will either need to override this method or place a 596 suitable dictionary in the handler's *typemap* attribute. 597 598 599 .. method:: getMessageID(record) 600 601 Returns the message ID for the record. If you are using your own messages, 602 you could do this by having the *msg* passed to the logger being an ID 603 rather than a format string. Then, in here, you could use a dictionary 604 lookup to get the message ID. This version returns 1, which is the base 605 message ID in :file:`win32service.pyd`. 606 607 .. _smtp-handler: 608 609 SMTPHandler 610 ^^^^^^^^^^^ 611 612 The :class:`SMTPHandler` class, located in the :mod:`logging.handlers` module, 613 supports sending logging messages to an email address via SMTP. 614 615 616 .. class:: SMTPHandler(mailhost, fromaddr, toaddrs, subject, credentials=None, secure=None) 617 618 Returns a new instance of the :class:`SMTPHandler` class. The instance is 619 initialized with the from and to addresses and subject line of the email. 620 The *toaddrs* should be a list of strings. To specify a non-standard SMTP 621 port, use the (host, port) tuple format for the *mailhost* argument. If you 622 use a string, the standard SMTP port is used. If your SMTP server requires 623 authentication, you can specify a (username, password) tuple for the 624 *credentials* argument. 625 626 To specify the use of a secure protocol (TLS), pass in a tuple to the 627 *secure* argument. This will only be used when authentication credentials are 628 supplied. The tuple should be either an empty tuple, or a single-value tuple 629 with the name of a keyfile, or a 2-value tuple with the names of the keyfile 630 and certificate file. (This tuple is passed to the 631 :meth:`smtplib.SMTP.starttls` method.) 632 633 .. versionchanged:: 2.6 634 *credentials* was added. 635 636 .. versionchanged:: 2.7 637 *secure* was added. 638 639 640 .. method:: emit(record) 641 642 Formats the record and sends it to the specified addressees. 643 644 645 .. method:: getSubject(record) 646 647 If you want to specify a subject line which is record-dependent, override 648 this method. 649 650 .. _memory-handler: 651 652 MemoryHandler 653 ^^^^^^^^^^^^^ 654 655 The :class:`MemoryHandler` class, located in the :mod:`logging.handlers` module, 656 supports buffering of logging records in memory, periodically flushing them to a 657 :dfn:`target` handler. Flushing occurs whenever the buffer is full, or when an 658 event of a certain severity or greater is seen. 659 660 :class:`MemoryHandler` is a subclass of the more general 661 :class:`BufferingHandler`, which is an abstract class. This buffers logging 662 records in memory. Whenever each record is added to the buffer, a check is made 663 by calling :meth:`shouldFlush` to see if the buffer should be flushed. If it 664 should, then :meth:`flush` is expected to do the flushing. 665 666 667 .. class:: BufferingHandler(capacity) 668 669 Initializes the handler with a buffer of the specified capacity. 670 671 672 .. method:: emit(record) 673 674 Appends the record to the buffer. If :meth:`shouldFlush` returns true, 675 calls :meth:`flush` to process the buffer. 676 677 678 .. method:: flush() 679 680 You can override this to implement custom flushing behavior. This version 681 just zaps the buffer to empty. 682 683 684 .. method:: shouldFlush(record) 685 686 Returns true if the buffer is up to capacity. This method can be 687 overridden to implement custom flushing strategies. 688 689 690 .. class:: MemoryHandler(capacity, flushLevel=ERROR, target=None) 691 692 Returns a new instance of the :class:`MemoryHandler` class. The instance is 693 initialized with a buffer size of *capacity*. If *flushLevel* is not specified, 694 :const:`ERROR` is used. If no *target* is specified, the target will need to be 695 set using :meth:`setTarget` before this handler does anything useful. 696 697 698 .. method:: close() 699 700 Calls :meth:`flush`, sets the target to :const:`None` and clears the 701 buffer. 702 703 704 .. method:: flush() 705 706 For a :class:`MemoryHandler`, flushing means just sending the buffered 707 records to the target, if there is one. The buffer is also cleared when 708 this happens. Override if you want different behavior. 709 710 711 .. method:: setTarget(target) 712 713 Sets the target handler for this handler. 714 715 716 .. method:: shouldFlush(record) 717 718 Checks for buffer full or a record at the *flushLevel* or higher. 719 720 721 .. _http-handler: 722 723 HTTPHandler 724 ^^^^^^^^^^^ 725 726 The :class:`HTTPHandler` class, located in the :mod:`logging.handlers` module, 727 supports sending logging messages to a Web server, using either ``GET`` or 728 ``POST`` semantics. 729 730 731 .. class:: HTTPHandler(host, url, method='GET') 732 733 Returns a new instance of the :class:`HTTPHandler` class. The ``host`` can be 734 of the form ``host:port``, should you need to use a specific port number. 735 736 .. method:: mapLogRecord(record) 737 738 Provides a dictionary, based on ``record``, which is to be URL-encoded 739 and sent to the web server. The default implementation just returns 740 ``record.__dict__``. This method can be overridden if e.g. only a 741 subset of :class:`~logging.LogRecord` is to be sent to the web server, or 742 if more specific customization of what's sent to the server is required. 743 744 .. method:: emit(record) 745 746 Sends the record to the Web server as a URL-encoded dictionary. The 747 :meth:`mapLogRecord` method is used to convert the record to the 748 dictionary to be sent. 749 750 .. note:: Since preparing a record for sending it to a Web server is not 751 the same as a generic formatting operation, using :meth:`setFormatter` 752 to specify a :class:`Formatter` for a :class:`HTTPHandler` has no effect. 753 Instead of calling :meth:`format`, this handler calls :meth:`mapLogRecord` 754 and then :func:`urllib.urlencode` to encode the dictionary in a form 755 suitable for sending to a Web server. 756 757 .. seealso:: 758 759 Module :mod:`logging` 760 API reference for the logging module. 761 762 Module :mod:`logging.config` 763 Configuration API for the logging module. 764 765 766
