logging —- Python 的日志记录工具

源代码：Lib/logging/init.py

Important

此页面仅包含 API 参考信息。教程信息和更多高级用法的讨论，请参阅

• 基础教程

• 进阶教程

• 日志操作手册

这个模块为应用与库定义了实现灵活的事件日志系统的函数与类.

使用标准库提提供的 logging API 最主要的好处是，所有的 Python 模块都可能参与日志输出，包括你的日志消息和第三方模块的日志消息。

这个模块提供许多强大而灵活的功能。如果你对 logging 不太熟悉的话， 掌握它最好的方式就是查看它对应的教程（详见右侧的链接）。

该模块定义的基础类和函数都列在下面。

• 记录器暴露了应用程序代码直接使用的接口。

• 处理程序将日志记录（由记录器创建）发送到适当的目标。

• 过滤器提供了更精细的设施，用于确定要输出的日志记录。

• 格式化程序指定最终输出中日志记录的样式。

Logger 对象

Loggers 有以下的属性和方法。注意 永远 不要直接实例化 Loggers，应当通过模块级别的函数 logging.getLogger(name) 。多次使用相同的名字调用 getLogger() 会一直返回相同的 Logger 对象的引用。

name 是潜在的周期分割层级值, 像foo.bar.baz (例如, 抛出的可以只是明文的foo)。Loggers是进一步在子层次列表的更高loggers列表。例如，有个名叫foo的logger，名叫foo.bar，foo.bar.baz，和 foo.bam 都是 foo的衍生logger。logger的名字分级类似Python 包的层级，并且相同的如果你组织你的loggers在每模块级别基本上使用推荐的结构logging.getLogger(name)。这是因为在模块里，在Python包的命名空间的模块名为__name__。

• class logging.Logger
• • propagate
  • 如果这个属性为真，记录到这个记录器的事件将会传递给这个高级别处理器的记录器（原型），此外任何关联到这个记录器的处理器。消息会直接传递给原型记录器的处理器 - 既不是这个原型记录器的级别也不是过滤器是在考虑的问题。

如果等于假，记录消息将不会传递给这个原型记录器的处理器。

构造器将这个属性初始化为 True。

注解

如果你关联了一个处理器并且到它自己的一个或多个记录器，它可能发出多次相同的记录。总体来说，你不需要关联处理器到一个或多个记录器 - 如果你只是关联它到一个合适的记录器等级中的最高级别记录器，它将会看到子记录器所有记录的事件，他们的传播剩下的设置为True。一个常见的场景是只关联处理器到根记录器，并且让传播照顾剩下的。

• setLevel(level)
• 给 logger 设置阈值为 level 。日志等级小于 level 会被忽略。严重性为 level 或更高的日志消息将由该 logger 的任何一个或多个 handler 发出，除非将处理程序的级别设置为比 level 更高的级别。

创建一个 logger 时，设置级别为 NOTSET （当 logger 是根 logger 时，将处理所有消息；当 logger 是非根 logger 时，所有消息会委派给父级）。注意根 logger 创建时使用的是 WARNING 级别。

委派给父级的意思是如果一个 logger 的级别设置为 NOTSET，遍历其祖先 logger，直到找到另一个不是 NOTSET 级别的 logger，或者到根 logger 为止。

If an ancestor is found with a level other than NOTSET, then that ancestor'slevel is treated as the effective level of the logger where the ancestor searchbegan, and is used to determine how a logging event is handled.

If the root is reached, and it has a level of NOTSET, then all messages will beprocessed. Otherwise, the root's level will be used as the effective level.

参见 日志级别 级别列表。

在 3.2 版更改: The level parameter now accepts a string representation of thelevel such as 'INFO' as an alternative to the integer constantssuch as INFO. Note, however, that levels are internally storedas integers, and methods such as e.g. getEffectiveLevel() andisEnabledFor() will return/expect to be passed integers.

• isEnabledFor(level)

• Indicates if a message of severity level would be processed by this logger.This method checks first the module-level level set bylogging.disable(level) and then the logger's effective level as determinedby getEffectiveLevel().

• getEffectiveLevel()

• Indicates the effective level for this logger. If a value other thanNOTSET has been set using setLevel(), it is returned. Otherwise,the hierarchy is traversed towards the root until a value other thanNOTSET is found, and that value is returned. The value returned isan integer, typically one of logging.DEBUG, logging.INFOetc.

• getChild(suffix)

• Returns a logger which is a descendant to this logger, as determined by the suffix.Thus, logging.getLogger('abc').getChild('def.ghi') would return the samelogger as would be returned by logging.getLogger('abc.def.ghi'). This is aconvenience method, useful when the parent logger is named using e.g. namerather than a literal string.

3.2 新版功能.

• debug(msg, *args, **kwargs)
• Logs a message with level DEBUG on this logger. The msg is themessage format string, and the args are the arguments which are merged intomsg using the string formatting operator. (Note that this means that you canuse keywords in the format string, together with a single dictionary argument.)

There are four keyword arguments in kwargs which are inspected:exc_info, stack_info, stacklevel and extra.

If exc_info does not evaluate as false, it causes exception information to beadded to the logging message. If an exception tuple (in the format returned bysys.exc_info()) or an exception instance is provided, it is used;otherwise, sys.exc_info() is called to get the exception information.

The second optional keyword argument is stack_info, which defaults toFalse. If true, stack information is added to the loggingmessage, including the actual logging call. Note that this is not the samestack information as that displayed through specifying exc_info: Theformer is stack frames from the bottom of the stack up to the logging callin the current thread, whereas the latter is information about stack frameswhich have been unwound, following an exception, while searching forexception handlers.

You can specify stack_info independently of exc_info, e.g. to just showhow you got to a certain point in your code, even when no exceptions wereraised. The stack frames are printed following a header line which says:

Stack (most recent call last):

This mimics the Traceback (most recent call last): which is used whendisplaying exception frames.

The third optional keyword argument is stacklevel, which defaults to 1.If greater than 1, the corresponding number of stack frames are skippedwhen computing the line number and function name set in the LogRecordcreated for the logging event. This can be used in logging helpers so thatthe function name, filename and line number recorded are not the informationfor the helper function/method, but rather its caller. The name of thisparameter mirrors the equivalent one in the warnings module.

The fourth keyword argument is extra which can be used to pass adictionary which is used to populate the dict of the LogRecordcreated for the logging event with user-defined attributes. These customattributes can then be used as you like. For example, they could beincorporated into logged messages. For example:

FORMAT = '%(asctime)-15s %(clientip)s %(user)-8s %(message)s'
logging.basicConfig(format=FORMAT)
d = {'clientip': '192.168.0.1', 'user': 'fbloggs'}
logger = logging.getLogger('tcpserver')
logger.warning('Protocol problem: %s', 'connection reset', extra=d)

would print something like

2006-02-08 22:20:02,165 192.168.0.1 fbloggs  Protocol problem: connection reset

The keys in the dictionary passed in extra should not clash with the keys usedby the logging system. (See the Formatter documentation for moreinformation on which keys are used by the logging system.)

If you choose to use these attributes in logged messages, you need to exercisesome care. In the above example, for instance, the Formatter has beenset up with a format string which expects 'clientip' and 'user' in the attributedictionary of the LogRecord. If these are missing, the message willnot be logged because a string formatting exception will occur. So in this case,you always need to pass the extra dictionary with these keys.

While this might be annoying, this feature is intended for use in specializedcircumstances, such as multi-threaded servers where the same code executes inmany contexts, and interesting conditions which arise are dependent on thiscontext (such as remote client IP address and authenticated user name, in theabove example). In such circumstances, it is likely that specializedFormatters would be used with particular Handlers.

在 3.2 版更改: 增加了 stack_info 参数。

在 3.5 版更改: The exc_info parameter can now accept exception instances.

在 3.8 版更改: 增加了 stacklevel 参数。

• info(msg, *args, **kwargs)

• Logs a message with level INFO on this logger. The arguments areinterpreted as for debug().

• warning(msg, *args, **kwargs)

• Logs a message with level WARNING on this logger. The arguments areinterpreted as for debug().

注解

There is an obsolete method warn which is functionallyidentical to warning. As warn is deprecated, please do not useit - use warning instead.

• error(msg, *args, **kwargs)

• Logs a message with level ERROR on this logger. The arguments areinterpreted as for debug().

• critical(msg, *args, **kwargs)

• Logs a message with level CRITICAL on this logger. The arguments areinterpreted as for debug().

• log(level, msg, *args, **kwargs)

• Logs a message with integer level level on this logger. The other arguments areinterpreted as for debug().

• exception(msg, *args, **kwargs)

• Logs a message with level ERROR on this logger. The arguments areinterpreted as for debug(). Exception info is added to the loggingmessage. This method should only be called from an exception handler.

• addFilter(filter)

• Adds the specified filter filter to this logger.

• removeFilter(filter)

• Removes the specified filter filter from this logger.

• filter(record)

• Apply this logger's filters to the record and return True if therecord is to be processed. The filters are consulted in turn, until one ofthem returns a false value. If none of them return a false value, the recordwill be processed (passed to handlers). If one returns a false value, nofurther processing of the record occurs.

• addHandler(hdlr)

• Adds the specified handler hdlr to this logger.

• removeHandler(hdlr)

• Removes the specified handler hdlr from this logger.

• findCaller(stack_info=False, stacklevel=1)

• Finds the caller's source filename and line number. Returns the filename, linenumber, function name and stack information as a 4-element tuple. The stackinformation is returned as None unless stack_info is True.

The stacklevel parameter is passed from code calling the debug()and other APIs. If greater than 1, the excess is used to skip stack framesbefore determining the values to be returned. This will generally be usefulwhen calling logging APIs from helper/wrapper code, so that the informationin the event log refers not to the helper/wrapper code, but to the code thatcalls it.

• handle(record)

• Handles a record by passing it to all handlers associated with this logger andits ancestors (until a false value of propagate is found). This method is usedfor unpickled records received from a socket, as well as those created locally.Logger-level filtering is applied using filter().

• makeRecord(name, level, fn, lno, msg, args, exc_info, func=None, extra=None, sinfo=None)

• This is a factory method which can be overridden in subclasses to createspecialized LogRecord instances.

• hasHandlers()

• Checks to see if this logger has any handlers configured. This is done bylooking for handlers in this logger and its parents in the logger hierarchy.Returns True if a handler was found, else False. The method stops searchingup the hierarchy whenever a logger with the 'propagate' attribute set tofalse is found - that will be the last logger which is checked for theexistence of handlers.

3.2 新版功能.

在 3.7 版更改: Loggers can now be pickled and unpickled.

日志级别

日志记录级别的数值在下表中给出。如果你想要定义自己的级别，并且需要它们具有相对于预定义级别的特定值，那么这些内容可能是你感兴趣的。如果你定义具有相同数值的级别，它将覆盖预定义的值; 预定义的名称丢失。

处理器对象

Handler 有以下属性和方法。注意不要直接实例化 Handler ；这个类用来派生其他更有用的子类。但是，子类的 init() 方法需要调用 Handler.init() 。

• class logging.Handler
• • init(level=NOTSET)

  • 初始化 Handler 实例时，需要设置它的级别，将过滤列表置为空，并且创建锁（通过 createLock() ）来序列化对 I/O 的访问。

  • createLock()

  • 初始化一个线程锁，用来序列化对底层的 I/O 功能的访问，底层的 I/O 功能可能不是线程安全的。

  • acquire()

  • 使用 createLock() 获取线程锁。

  • release()

  • 使用 acquire() 来释放线程锁。

  • setLevel(level)

  • 给处理器设置阈值为 level 。日志级别小于 level 将被忽略。创建处理器时，日志级别被设置为 NOTSET （所有的消息都会被处理）。

参见 日志级别 级别列表。

在 3.2 版更改: level 形参现在接受像 'INFO' 这样的字符串形式的级别表达方式，也可以使用像 INFO 这样的整数常量。

• setFormatter(fmt)

• Sets the Formatter for this handler to fmt.

• addFilter(filter)

• Adds the specified filter filter to this handler.

• removeFilter(filter)

• Removes the specified filter filter from this handler.

• filter(record)

• Apply this handler's filters to the record and return True if therecord is to be processed. The filters are consulted in turn, until one ofthem returns a false value. If none of them return a false value, the recordwill be emitted. If one returns a false value, the handler will not emit therecord.

• flush()

• Ensure all logging output has been flushed. This version does nothing and isintended to be implemented by subclasses.

• close()

• Tidy up any resources used by the handler. This version does no output butremoves the handler from an internal list of handlers which is closed whenshutdown() is called. Subclasses should ensure that this gets calledfrom overridden close() methods.

• handle(record)

• Conditionally emits the specified logging record, depending on filters which mayhave been added to the handler. Wraps the actual emission of the record withacquisition/release of the I/O thread lock.

• handleError(record)

• This method should be called from handlers when an exception is encounteredduring an emit() call. If the module-level attributeraiseExceptions is False, exceptions get silently ignored. This iswhat is mostly wanted for a logging system - most users will not care abouterrors in the logging system, they are more interested in applicationerrors. You could, however, replace this with a custom handler if you wish.The specified record is the one which was being processed when the exceptionoccurred. (The default value of raiseExceptions is True, as that ismore useful during development).

• format(record)

• Do formatting for a record - if a formatter is set, use it. Otherwise, use thedefault formatter for the module.

• emit(record)

• Do whatever it takes to actually log the specified logging record. This versionis intended to be implemented by subclasses and so raises aNotImplementedError.

For a list of handlers included as standard, see logging.handlers.

Formatter Objects

Formatter objects have the following attributes and methods. They areresponsible for converting a LogRecord to (usually) a string which canbe interpreted by either a human or an external system. The baseFormatter allows a formatting string to be specified. If none issupplied, the default value of '%(message)s' is used, which just includesthe message in the logging call. To have additional items of information in theformatted output (such as a timestamp), keep reading.

A Formatter can be initialized with a format string which makes use of knowledgeof the LogRecord attributes - such as the default value mentioned abovemaking use of the fact that the user's message and arguments are pre-formattedinto a LogRecord's message attribute. This format string containsstandard Python %-style mapping keys. See section printf 风格的字符串格式化for more information on string formatting.

The useful mapping keys in a LogRecord are given in the section onLogRecord 属性.

• class logging.Formatter(fmt=None, datefmt=None, style='%')
• Returns a new instance of the Formatter class. The instance isinitialized with a format string for the message as a whole, as well as aformat string for the date/time portion of a message. If no fmt isspecified, '%(message)s' is used. If no datefmt is specified, a formatis used which is described in the formatTime() documentation.

The style parameter can be one of '%', '{' or '$' and determines howthe format string will be merged with its data: using one of %-formatting,str.format() or string.Template. See Using particular formatting styles throughout your applicationfor more information on using {- and $-formatting for log messages.

在 3.2 版更改: The style parameter was added.

在 3.8 版更改: The validate parameter was added. Incorrect or mismatched style and fmtwill raise a ValueError.For example: logging.Formatter('%(asctime)s - %(message)s', style='{').

• format(record)
• The record's attribute dictionary is used as the operand to a stringformatting operation. Returns the resulting string. Before formatting thedictionary, a couple of preparatory steps are carried out. The message_attribute of the record is computed using _msg % args. If theformatting string contains '(asctime)', formatTime() is calledto format the event time. If there is exception information, it isformatted using formatException() and appended to the message. Notethat the formatted exception information is cached in attributeexc_text. This is useful because the exception information can bepickled and sent across the wire, but you should be careful if you havemore than one Formatter subclass which customizes the formattingof exception information. In this case, you will have to clear the cachedvalue after a formatter has done its formatting, so that the nextformatter to handle the event doesn't use the cached value butrecalculates it afresh.

If stack information is available, it's appended after the exceptioninformation, using formatStack() to transform it if necessary.

• formatTime(record, datefmt=None)
• This method should be called from format() by a formatter whichwants to make use of a formatted time. This method can be overridden informatters to provide for any specific requirement, but the basic behavioris as follows: if datefmt (a string) is specified, it is used withtime.strftime() to format the creation time of therecord. Otherwise, the format '%Y-%m-%d %H:%M:%S,uuu' is used, where theuuu part is a millisecond value and the other letters are as per thetime.strftime() documentation. An example time in this format is2003-01-23 00:29:50,411. The resulting string is returned.

This function uses a user-configurable function to convert the creationtime to a tuple. By default, time.localtime() is used; to changethis for a particular formatter instance, set the converter attributeto a function with the same signature as time.localtime() ortime.gmtime(). To change it for all formatters, for example if youwant all logging times to be shown in GMT, set the converterattribute in the Formatter class.

在 3.3 版更改: Previously, the default format was hard-coded as in this example:2010-09-06 22:38:15,292 where the part before the comma ishandled by a strptime format string ('%Y-%m-%d %H:%M:%S'), and thepart after the comma is a millisecond value. Because strptime does nothave a format placeholder for milliseconds, the millisecond value isappended using another format string, '%s,%03d' —- and both of theseformat strings have been hardcoded into this method. With the change,these strings are defined as class-level attributes which can beoverridden at the instance level when desired. The names of theattributes are default_time_format (for the strptime format string)and default_msec_format (for appending the millisecond value).

• formatException(exc_info)

• Formats the specified exception information (a standard exception tuple asreturned by sys.exc_info()) as a string. This default implementationjust uses traceback.print_exception(). The resulting string isreturned.

• formatStack(stack_info)

• Formats the specified stack information (a string as returned bytraceback.print_stack(), but with the last newline removed) as astring. This default implementation just returns the input value.

Filter Objects

Filters can be used by Handlers and Loggers for more sophisticatedfiltering than is provided by levels. The base filter class only allows eventswhich are below a certain point in the logger hierarchy. For example, a filterinitialized with 'A.B' will allow events logged by loggers 'A.B', 'A.B.C','A.B.C.D', 'A.B.D' etc. but not 'A.BB', 'B.A.B' etc. If initialized with theempty string, all events are passed.

• class logging.Filter(name='')

• Returns an instance of the Filter class. If name is specified, itnames a logger which, together with its children, will have its events allowedthrough the filter. If name is the empty string, allows every event.

  • filter(record)
  • Is the specified record to be logged? Returns zero for no, nonzero foryes. If deemed appropriate, the record may be modified in-place by thismethod.

Note that filters attached to handlers are consulted before an event isemitted by the handler, whereas filters attached to loggers are consultedwhenever an event is logged (using debug(), info(),etc.), before sending an event to handlers. This means that events which havebeen generated by descendant loggers will not be filtered by a logger's filtersetting, unless the filter has also been applied to those descendant loggers.

You don't actually need to subclass Filter: you can pass any instancewhich has a filter method with the same semantics.

在 3.2 版更改: You don't need to create specialized Filter classes, or use otherclasses with a filter method: you can use a function (or othercallable) as a filter. The filtering logic will check to see if the filterobject has a filter attribute: if it does, it's assumed to be aFilter and its filter() method is called. Otherwise, it'sassumed to be a callable and called with the record as the singleparameter. The returned value should conform to that returned byfilter().

Although filters are used primarily to filter records based on moresophisticated criteria than levels, they get to see every record which isprocessed by the handler or logger they're attached to: this can be useful ifyou want to do things like counting how many records were processed by aparticular logger or handler, or adding, changing or removing attributes inthe LogRecord being processed. Obviously changing the LogRecord needsto be done with some care, but it does allow the injection of contextualinformation into logs (see 使用过滤器传递上下文信息).

LogRecord Objects

LogRecord instances are created automatically by the Loggerevery time something is logged, and can be created manually viamakeLogRecord() (for example, from a pickled event received over thewire).

• class logging.LogRecord(name, level, pathname, lineno, msg, args, exc_info, func=None, sinfo=None)
• Contains all the information pertinent to the event being logged.

The primary information is passed in msg and args, whichare combined using msg % args to create the message field of therecord.

• 参数

• • name — The name of the logger used to log the event represented bythis LogRecord. Note that this name will always have thisvalue, even though it may be emitted by a handler attached toa different (ancestor) logger.

  • level — The numeric level of the logging event (one of DEBUG, INFO etc.)Note that this is converted to two attributes of the LogRecord:levelno for the numeric value and levelname for thecorresponding level name.

  • pathname — The full pathname of the source file where the logging callwas made.

  • lineno — The line number in the source file where the logging call wasmade.

  • msg — The event description message, possibly a format string withplaceholders for variable data.

  • args — Variable data to merge into the msg argument to obtain theevent description.

  • exc_info — An exception tuple with the current exception information,or None if no exception information is available.

  • func — The name of the function or method from which the logging callwas invoked.

  • sinfo — A text string representing stack information from the base ofthe stack in the current thread, up to the logging call.

• getMessage()

• Returns the message for this LogRecord instance after merging anyuser-supplied arguments with the message. If the user-supplied messageargument to the logging call is not a string, str() is called on it toconvert it to a string. This allows use of user-defined classes asmessages, whose str method can return the actual format string tobe used.

在 3.2 版更改: The creation of a LogRecord has been made more configurable byproviding a factory which is used to create the record. The factory can beset using getLogRecordFactory() and setLogRecordFactory()(see this for the factory's signature).

This functionality can be used to inject your own values into aLogRecord at creation time. You can use the following pattern:

old_factory = logging.getLogRecordFactory()
 
def record_factory(*args, **kwargs):
    record = old_factory(*args, **kwargs)
    record.custom_attribute = 0xdecafbad
    return record
 
logging.setLogRecordFactory(record_factory)

With this pattern, multiple factories could be chained, and as longas they don't overwrite each other's attributes or unintentionallyoverwrite the standard attributes listed above, there should be nosurprises.

LogRecord 属性

The LogRecord has a number of attributes, most of which are derived from theparameters to the constructor. (Note that the names do not always correspondexactly between the LogRecord constructor parameters and the LogRecordattributes.) These attributes can be used to merge data from the record intothe format string. The following table lists (in alphabetical order) theattribute names, their meanings and the corresponding placeholder in a %-styleformat string.

If you are using {}-formatting (str.format()), you can use{attrname} as the placeholder in the format string. If you are using$-formatting (string.Template), use the form ${attrname}. Inboth cases, of course, replace attrname with the actual attribute nameyou want to use.

In the case of {}-formatting, you can specify formatting flags by placing themafter the attribute name, separated from it with a colon. For example: aplaceholder of {msecs:03d} would format a millisecond value of 4 as004. Refer to the str.format() documentation for full details onthe options available to you.

在 3.1 版更改: 添加了 processName

LoggerAdapter 对象

LoggerAdapter instances are used to conveniently pass contextualinformation into logging calls. For a usage example, see the section onadding contextual information to your logging output.

• class logging.LoggerAdapter(logger, extra)

• Returns an instance of LoggerAdapter initialized with anunderlying Logger instance and a dict-like object.

  • process(msg, kwargs)
  • Modifies the message and/or keyword arguments passed to a logging call inorder to insert contextual information. This implementation takes the objectpassed as extra to the constructor and adds it to kwargs using key'extra'. The return value is a (msg, kwargs) tuple which has the(possibly modified) versions of the arguments passed in.

In addition to the above, LoggerAdapter supports the followingmethods of Logger: debug(), info(),warning(), error(), exception(),critical(), log(), isEnabledFor(),getEffectiveLevel(), setLevel() andhasHandlers(). These methods have the same signatures as theircounterparts in Logger, so you can use the two types of instancesinterchangeably.

在 3.2 版更改: The isEnabledFor(), getEffectiveLevel(),setLevel() and hasHandlers() methods were addedto LoggerAdapter. These methods delegate to the underlying logger.

线程安全

The logging module is intended to be thread-safe without any special workneeding to be done by its clients. It achieves this though using threadinglocks; there is one lock to serialize access to the module's shared data, andeach handler also creates a lock to serialize access to its underlying I/O.

If you are implementing asynchronous signal handlers using the signalmodule, you may not be able to use logging from within such handlers. This isbecause lock implementations in the threading module are not alwaysre-entrant, and so cannot be invoked from such signal handlers.

模块级别函数

In addition to the classes described above, there are a number of module-levelfunctions.

• logging.getLogger(name=None)
• Return a logger with the specified name or, if name is None, return alogger which is the root logger of the hierarchy. If specified, the name istypically a dot-separated hierarchical name like 'a', 'a.b' or 'a.b.c.d'.Choice of these names is entirely up to the developer who is using logging.

All calls to this function with a given name return the same logger instance.This means that logger instances never need to be passed between different partsof an application.

• logging.getLoggerClass()
• Return either the standard Logger class, or the last class passed tosetLoggerClass(). This function may be called from within a new classdefinition, to ensure that installing a customized Logger class willnot undo customizations already applied by other code. For example:

class MyLogger(logging.getLoggerClass()):
    # ... override behaviour here

• logging.getLogRecordFactory()
• Return a callable which is used to create a LogRecord.

3.2 新版功能: This function has been provided, along with setLogRecordFactory(),to allow developers more control over how the LogRecordrepresenting a logging event is constructed.

See setLogRecordFactory() for more information about the how thefactory is called.

• logging.debug(msg, *args, **kwargs)
• Logs a message with level DEBUG on the root logger. The msg is themessage format string, and the args are the arguments which are merged intomsg using the string formatting operator. (Note that this means that you canuse keywords in the format string, together with a single dictionary argument.)

There are three keyword arguments in kwargs which are inspected: _exc_info_which, if it does not evaluate as false, causes exception information to beadded to the logging message. If an exception tuple (in the format returned bysys.exc_info()) or an exception instance is provided, it is used;otherwise, sys.exc_info() is called to get the exception information.

The second optional keyword argument is stack_info, which defaults toFalse. If true, stack information is added to the loggingmessage, including the actual logging call. Note that this is not the samestack information as that displayed through specifying exc_info: Theformer is stack frames from the bottom of the stack up to the logging callin the current thread, whereas the latter is information about stack frameswhich have been unwound, following an exception, while searching forexception handlers.

You can specify stack_info independently of exc_info, e.g. to just showhow you got to a certain point in your code, even when no exceptions wereraised. The stack frames are printed following a header line which says:

Stack (most recent call last):

This mimics the Traceback (most recent call last): which is used whendisplaying exception frames.

The third optional keyword argument is extra which can be used to pass adictionary which is used to populate the dict of the LogRecord created forthe logging event with user-defined attributes. These custom attributes can thenbe used as you like. For example, they could be incorporated into loggedmessages. For example:

FORMAT = '%(asctime)-15s %(clientip)s %(user)-8s %(message)s'
logging.basicConfig(format=FORMAT)
d = {'clientip': '192.168.0.1', 'user': 'fbloggs'}
logging.warning('Protocol problem: %s', 'connection reset', extra=d)

would print something like:

2006-02-08 22:20:02,165 192.168.0.1 fbloggs  Protocol problem: connection reset

The keys in the dictionary passed in extra should not clash with the keys usedby the logging system. (See the Formatter documentation for moreinformation on which keys are used by the logging system.)

If you choose to use these attributes in logged messages, you need to exercisesome care. In the above example, for instance, the Formatter has beenset up with a format string which expects 'clientip' and 'user' in the attributedictionary of the LogRecord. If these are missing, the message will not belogged because a string formatting exception will occur. So in this case, youalways need to pass the extra dictionary with these keys.

While this might be annoying, this feature is intended for use in specializedcircumstances, such as multi-threaded servers where the same code executes inmany contexts, and interesting conditions which arise are dependent on thiscontext (such as remote client IP address and authenticated user name, in theabove example). In such circumstances, it is likely that specializedFormatters would be used with particular Handlers.

在 3.2 版更改: 增加了 stack_info 参数。

• logging.info(msg, *args, **kwargs)

• Logs a message with level INFO on the root logger. The arguments areinterpreted as for debug().

• logging.warning(msg, *args, **kwargs)

• Logs a message with level WARNING on the root logger. The argumentsare interpreted as for debug().

注解

There is an obsolete function warn which is functionallyidentical to warning. As warn is deprecated, please do not useit - use warning instead.

• logging.error(msg, *args, **kwargs)

• Logs a message with level ERROR on the root logger. The arguments areinterpreted as for debug().

• logging.critical(msg, *args, **kwargs)

• Logs a message with level CRITICAL on the root logger. The argumentsare interpreted as for debug().

• logging.exception(msg, *args, **kwargs)

• Logs a message with level ERROR on the root logger. The arguments areinterpreted as for debug(). Exception info is added to the loggingmessage. This function should only be called from an exception handler.

• logging.log(level, msg, *args, **kwargs)

• Logs a message with level level on the root logger. The other arguments areinterpreted as for debug().

注解

The above module-level convenience functions, which delegate to theroot logger, call basicConfig() to ensure that at least one handleris available. Because of this, they should not be used in threads,in versions of Python earlier than 2.7.1 and 3.2, unless at least onehandler has been added to the root logger before the threads arestarted. In earlier versions of Python, due to a thread safety shortcomingin basicConfig(), this can (under rare circumstances) lead tohandlers being added multiple times to the root logger, which can in turnlead to multiple messages for the same event.

• logging.disable(level=CRITICAL)
• Provides an overriding level level for all loggers which takes precedence overthe logger's own level. When the need arises to temporarily throttle loggingoutput down across the whole application, this function can be useful. Itseffect is to disable all logging calls of severity level and below, so thatif you call it with a value of INFO, then all INFO and DEBUG events would bediscarded, whereas those of severity WARNING and above would be processedaccording to the logger's effective level. Iflogging.disable(logging.NOTSET) is called, it effectively removes thisoverriding level, so that logging output again depends on the effectivelevels of individual loggers.

Note that if you have defined any custom logging level higher thanCRITICAL (this is not recommended), you won't be able to rely on thedefault value for the level parameter, but will have to explicitly supply asuitable value.

在 3.7 版更改: The level parameter was defaulted to level CRITICAL. See Issue#28524 for more information about this change.

• logging.addLevelName(level, levelName)
• Associates level level with text levelName in an internal dictionary, which isused to map numeric levels to a textual representation, for example when aFormatter formats a message. This function can also be used to defineyour own levels. The only constraints are that all levels used must beregistered using this function, levels should be positive integers and theyshould increase in increasing order of severity.

注解

If you are thinking of defining your own levels, please see thesection on 自定义级别.

• logging.getLevelName(level)
• Returns the textual representation of logging level level. If the level is oneof the predefined levels CRITICAL, ERROR, WARNING,INFO or DEBUG then you get the corresponding string. If youhave associated levels with names using addLevelName() then the name youhave associated with level is returned. If a numeric value corresponding to oneof the defined levels is passed in, the corresponding string representation isreturned. Otherwise, the string 'Level %s' % level is returned.

注解

Levels are internally integers (as they need to be compared in thelogging logic). This function is used to convert between an integer leveland the level name displayed in the formatted log output by means of the%(levelname)s format specifier (see LogRecord 属性).

在 3.4 版更改: In Python versions earlier than 3.4, this function could also be passed atext level, and would return the corresponding numeric value of the level.This undocumented behaviour was considered a mistake, and was removed inPython 3.4, but reinstated in 3.4.2 due to retain backward compatibility.

• logging.makeLogRecord(attrdict)

• Creates and returns a new LogRecord instance whose attributes aredefined by attrdict. This function is useful for taking a pickledLogRecord attribute dictionary, sent over a socket, and reconstitutingit as a LogRecord instance at the receiving end.

• logging.basicConfig(**kwargs)

• Does basic configuration for the logging system by creating aStreamHandler with a default Formatter and adding it to theroot logger. The functions debug(), info(), warning(),error() and critical() will call basicConfig() automaticallyif no handlers are defined for the root logger.

This function does nothing if the root logger already has handlersconfigured, unless the keyword argument force is set to True.

注解

This function should be called from the main threadbefore other threads are started. In versions of Python prior to2.7.1 and 3.2, if this function is called from multiple threads,it is possible (in rare circumstances) that a handler will be addedto the root logger more than once, leading to unexpected resultssuch as messages being duplicated in the log.

支持以下关键字参数。

格式

描述

filename

Specifies that a FileHandler be created,using the specified filename, rather than aStreamHandler.

filemode

If filename is specified, open the filein this mode. Defaultsto 'a'.

format

Use the specified format string for thehandler.

datefmt

Use the specified date/time format, asaccepted by time.strftime().

style

If format is specified, use this stylefor the format string. One of '%','{' or '$' for printf-style,str.format() orstring.Template respectively.Defaults to '%'.

level

Set the root logger level to the specifiedlevel.

stream

Use the specified stream to initialize theStreamHandler. Note that this argument isincompatible with filename - if bothare present, a ValueError is raised.

handlers

If specified, this should be an iterable ofalready created handlers to add to the rootlogger. Any handlers which don't alreadyhave a formatter set will be assigned thedefault formatter created in this function.Note that this argument is incompatiblewith filename or stream - if bothare present, a ValueError is raised.

force

If this keyword argument is specified astrue, any existing handlers attached to theroot logger are removed and closed, beforecarrying out the configuration as specifiedby the other arguments.

在 3.2 版更改: 增加了 style 参数。

在 3.3 版更改: The handlers argument was added. Additional checks were added tocatch situations where incompatible arguments are specified (e.g.handlers together with stream or filename, or stream_together with _filename).

在 3.8 版更改: 增加了 force 参数。

• logging.shutdown()
• Informs the logging system to perform an orderly shutdown by flushing andclosing all handlers. This should be called at application exit and nofurther use of the logging system should be made after this call.

When the logging module is imported, it registers this function as an exithandler (see atexit), so normally there's no need to do thatmanually.

• logging.setLoggerClass(klass)

• Tells the logging system to use the class klass when instantiating a logger.The class should define init() such that only a name argument isrequired, and the init() should call Logger.init(). Thisfunction is typically called before any loggers are instantiated by applicationswhich need to use custom logger behavior. After this call, as at any othertime, do not instantiate loggers directly using the subclass: continue to usethe logging.getLogger() API to get your loggers.

• logging.setLogRecordFactory(factory)

• Set a callable which is used to create a LogRecord.

  • 参数
  • factory — The factory callable to be used to instantiate a log record.

3.2 新版功能: This function has been provided, along with getLogRecordFactory(), toallow developers more control over how the LogRecord representinga logging event is constructed.

The factory has the following signature:

factory(name, level, fn, lno, msg, args, exc_info, func=None, sinfo=None, **kwargs)

name

日志记录器名称

level

日志记录级别（数字）。

fn

进行日志记录调用的文件的完整路径名。

lno

记录调用所在文件中的行号。

msg

日志消息。

args

日志记录消息的参数。

exc_info

异常元组，或 None 。

func

调用日志记录调用的函数或方法的名称。

sinfo

A stack traceback such as is provided bytraceback.print_stack(), showing the call hierarchy.

kwargs

其他关键字参数。

模块级属性

• logging.lastResort
• A "handler of last resort" is available through this attribute. Thisis a StreamHandler writing to sys.stderr with a level ofWARNING, and is used to handle logging events in the absence of anylogging configuration. The end result is to just print the message tosys.stderr. This replaces the earlier error message saying that"no handlers could be found for logger XYZ". If you need the earlierbehaviour for some reason, lastResort can be set to None.

3.2 新版功能.

Integration with the warnings module

The captureWarnings() function can be used to integrate loggingwith the warnings module.

• logging.captureWarnings(capture)
• This function is used to turn the capture of warnings by logging on andoff.

If capture is True, warnings issued by the warnings module willbe redirected to the logging system. Specifically, a warning will beformatted using warnings.formatwarning() and the resulting stringlogged to a logger named 'py.warnings' with a severity of WARNING.

If capture is False, the redirection of warnings to the logging systemwill stop, and warnings will be redirected to their original destinations(i.e. those in effect before captureWarnings(True) was called).

参见

• 模块 logging.config

• 日志记录模块的配置 API 。

• 模块 logging.handlers

• 日志记录模块附带的有用处理程序。

• PEP 282 - Logging 系统

• 该提案描述了Python标准库中包含的这个特性。

• Original Python logging package

• This is the original source for the logging package. The version of thepackage available from this site is suitable for use with Python 1.5.2, 2.1.xand 2.2.x, which do not include the logging package in the standardlibrary.