日志是一种可以追踪某些软件运行时所发生事件的方法。软件开发人员可以向他们的代码中调用日志记录相关的方法来表明发生了某些事情。一个事件可以用一个可包含可选变量数据的消息来描述。此外,事件也有重要性的概念,这个重要性也可以被称为严重性级别(level)。
通过log的分析,可以方便用户了解系统或软件、应用的运行情况;如果你的应用log足够丰富,也可以分析以往用户的操作行为、类型喜好、地域分布或其他更多信息;如果一个应用的log同时也分了多个级别,那么可以很轻易地分析得到该应用的健康状况,及时发现问题并快速定位、解决问题,补救损失。 简单来讲就是,我们通过记录和分析日志可以了解一个系统或软件程序运行情况是否正常,也可以在应用程序出现故障时快速定位问题。比如,做运维的同学,在接收到报警或各种问题反馈后,进行问题排查时通常都会先去看各种日志,大部分问题都可以在日志中找到答案。再比如,做开发的同学,可以通过IDE控制台上输出的各种日志进行程序调试。对于运维老司机或者有经验的开发人员,可以快速的通过日志定位到问题的根源。可见,日志的重要性不可小觑。日志的作用可以简单总结为以下3点:
如果应用的日志信息足够详细和丰富,还可以用来做用户行为分析,如:分析用户的操作行为、类型洗好、地域分布以及其它更多的信息,由此可以实现改进业务、提高商业利益。
我们先来思考下下面的两个问题:
在软件开发阶段或部署开发环境时,为了尽可能详细的查看应用程序的运行状态来保证上线后的稳定性,我们可能需要把该应用程序所有的运行日志全部记录下来进行分析,这是非常耗费机器性能的。当应用程序正式发布或在生产环境部署应用程序时,我们通常只需要记录应用程序的异常信息、错误信息等,这样既可以减小服务器的I/O压力,也可以避免我们在排查故障时被淹没在日志的海洋里。那么,怎样才能在不改动应用程序代码的情况下实现在不同的环境记录不同详细程度的日志呢?这就是日志等级的作用了,我们通过配置文件指定我们需要的日志等级就可以了。
不同的应用程序所定义的日志等级可能会有所差别,分的详细点的会包含以下几个等级:
本节开始问题提到过,一条日志信息对应的是一个事件的发生,而一个事件通常需要包括以下几个内容:
上面这些都是一条日志记录中可能包含的字段信息,当然还可以包括一些其他信息,如进程ID、进程名称、线程ID、线程名称等。日志格式就是用来定义一条日志记录中包含那些字段的,且日志格式通常都是可以自定义的。
说明: 输出一条日志时,日志内容和日志级别是需要开发人员明确指定的。对于而其它字段信息,只需要是否显示在日志中就可以了。
说明:
输出一条日志时,日志内容和日志级别是需要开发人员明确指定的。对于而其它字段信息,只需要是否显示在日志中就可以了。
几乎所有开发语言都会内置日志相关功能,或者会有比较优秀的第三方库来提供日志操作功能,比如:log4j,log4php等。它们功能强大、使用简单。Python自身也提供了一个用于记录日志的标准库模块 --logging。
logging模块定义的函数和类为应用程序和库的开发实现了一个灵活的事件日志系统。logging模块是Python的一个标准库模块,由标准库模块提供日志记录API的关键好处是所有Python模块都可以使用这个日志记录功能。所以,你的应用日志可以将你自己的日志信息与来自第三方模块的信息整合起来。
logging模块默认定义了以下几个日志等级,它允许开发人员自定义其他日志级别,但是这是不被推荐的,尤其是在开发供别人使用的库时,因为这会导致日志级别的混乱。
<table> <tr> <th>
日志等级(level)
</th> <th>
描述
</th> </tr> <tr> <td> DEBUG </td> <td>
最详细的日志信息,典型应用场景是 问题诊断
</td> </tr> <tr> <td> INFO </td> <td>
信息详细程度仅次于DEBUG,通常只记录关键节点信息,用于确认一切都是按照我们预期的那样进行工作
</td> </tr> <tr> <td> WARNING </td> <td>
当某些不期望的事情发生时记录的信息(如,磁盘可用空间较低),但是此时应用程序还是正常运行的
</td> </tr> <tr> <td> ERROR </td> <td>
由于一个更严重的问题导致某些功能不能正常运行时记录的信息
</td> </tr> <tr> <td> CRITICAL </td> <td>
当发生严重错误,导致应用程序不能继续运行时记录的信息
</td> </tr> </table>
开发应用程序或部署开发环境时,可以使用DEBUG或INFO级别的日志获取尽可能详细的日志信息来进行开发或部署调试;应用上线或部署生产环境时,应该使用WARNING或ERROR或CRITICAL级别的日志来降低机器的I/O压力和提高获取错误日志信息的效率。日志级别的指定通常都是在应用程序的配置文件中进行指定的。
说明: 上面列表中的日志等级是从上到下依次升高的,即:DEBUG < INFO < WARNING < ERROR < CRITICAL,而日志的信息量是依次减少的; * 当为某个应用程序指定一个日志级别后,应用程序会记录所有日志级别大于或等于指定日志级别的日志信息,而不是仅仅记录指定级别的日志信息,nginx、php等应用程序以及这里要提高的python的logging模块都是这样的。同样,logging模块也可以指定日志记录器的日志级别,只有级别大于或等于该指定日志级别的日志记录才会被输出,小于该等级的日志记录将会被丢弃。
logging模块提供了两种记录日志的方式:
其实,logging所提供的模块级别的日志记录函数也是对logging日志系统相关类的封装而已。
<table> <tr> <th> 函数 </th> <th>
说明
</th> </tr> <tr> <td> logging.debug(msg, *args, **kwargs) </td> <td>
创建一条严重级别为DEBUG的日志记录
</td> </tr> <tr> <td> logging.info(msg, *args, **kwargs) </td> <td>
创建一条严重级别为INFO的日志记录
</td> </tr> <tr> <td> logging.warning(msg, *args, **kwargs) </td> <td>
创建一条严重级别为WARNING的日志记录
</td> </tr> <tr> <td> logging.error(msg, *args, **kwargs) </td> <td>
创建一条严重级别为ERROR的日志记录
</td> </tr> <tr> <td> logging.critical(msg, *args, **kwargs) </td> <td>
创建一条严重级别为CRITICAL的日志记录
</td> </tr> <tr> <td> logging.log(level, *args, **kwargs) </td> <td>
创建一条严重级别为level的日志记录
</td> </tr> <tr> <td> logging.basicConfig(**kwargs) </td> <td>
对root logger进行一次性配置
其中logging.basicConfig(**kwargs)函数用于指定“要记录的日志级别”、“日志格式”、“日志输出位置”、“日志文件的打开模式”等信息,其他几个都是用于记录各个级别日志的函数。
logging.basicConfig(**kwargs)
组件
</th> </tr> <tr> <td> loggers </td> <td>
提供应用程序代码直接使用的接口
</td> </tr> <tr> <td> handlers </td> <td>
用于将日志记录发送到指定的目的位置
</td> </tr> <tr> <td> filters </td> <td>
提供更细粒度的日志过滤功能,用于决定哪些日志记录将会被输出(其它的日志记录将会被忽略)
</td> </tr> <tr> <td> formatters </td> <td>
用于控制日志信息的最终输出格式
说明: logging模块提供的模块级别的那些函数实际上也是通过这几个组件的相关实现类来记录日志的,只是在创建这些类的实例时设置了一些默认值。
回顾下前面提到的几个重要信息:
先来试着分别输出一条不同日志级别的日志记录:
import logging logging.debug("This is a debug log.") logging.info("This is a info log.") logging.warning("This is a warning log.") logging.error("This is a error log.") logging.critical("This is a critical log.") 也可以这样写: logging.log(logging.DEBUG, "This is a debug log.") logging.log(logging.INFO, "This is a info log.") logging.log(logging.WARNING, "This is a warning log.") logging.log(logging.ERROR, "This is a error log.") logging.log(logging.CRITICAL, "This is a critical log.")
输出结果:
WARNING:root:This is a warning log. ERROR:root:This is a error log. CRITICAL:root:This is a critical log.
这是因为logging模块提供的日志记录函数所使用的日志器设置的日志级别是WARNING,因此只有WARNING级别的日志记录以及大于它的ERROR和CRITICAL级别的日志记录被输出了,而小于它的DEBUG和INFO级别的日志记录被丢弃了。
WARNING
ERROR
CRITICAL
DEBUG
INFO
上面输出结果中每行日志记录的各个字段含义分别是:
日志级别:日志器名称:日志内容
之所以会这样输出,是因为logging模块提供的日志记录函数所使用的日志器设置的日志格式默认是BASIC_FORMAT,其值为:
"%(levelname)s:%(name)s:%(message)s"
因为在logging模块提供的日志记录函数所使用的日志器设置的处理器所指定的日志输出位置默认为: sys.stderr。
sys.stderr
查看这些日志记录函数的实现代码,可以发现:当我们没有提供任何配置信息的时候,这些函数都会去调用logging.basicConfig(**kwargs)方法,且不会向该方法传递任何参数。继续查看basicConfig()方法的代码就可以找到上面这些问题的答案了。
basicConfig()
其实很简单,在我们调用上面这些日志记录函数之前,手动调用一下basicConfig()方法,把我们想设置的内容以参数的形式传递进去就可以了。
该方法用于为logging日志系统做一些基本配置,方法定义如下:
该函数可接收的关键字参数如下:
参数名称
</th> </tr> <tr> <td> filename </td> <td>
指定日志输出目标文件的文件名,指定该设置项后日志信心就不会被输出到控制台了
</td> </tr> <tr> <td> filemode </td> <td>
指定日志文件的打开模式,默认为'a'。需要注意的是,该选项要在filename指定时才有效
</td> </tr> <tr> <td> format </td> <td>
指定日志格式字符串,即指定日志输出时所包含的字段信息以及它们的顺序。logging模块定义的格式字段下面会列出。
</td> </tr>
datefmt
</td>
指定日期/时间格式。需要注意的是,该选项要在format中包含时间字段%(asctime)s时才有效
</td> </tr> <tr> <td> level </td> <td>
指定日志器的日志级别
</td> </tr> <tr> <td> stream </td> <td>
指定日志输出目标stream,如sys.stdout、sys.stderr以及网络stream。需要说明的是,stream和filename不能同时提供,否则会引发 ValueError异常
ValueError
</td> </tr> <tr> <td> style </td> <td>
Python 3.2中新添加的配置项。指定format格式字符串的风格,可取值为'%'、'{'和'$',默认为'%'
Python 3.3中新添加的配置项。该选项如果被指定,它应该是一个创建了多个Handler的可迭代对象,这些handler将会被添加到root logger。需要说明的是:filename、stream和handlers这三个配置项只能有一个存在,不能同时出现2个或3个,否则会引发ValueError异常。
我们来列举一下logging模块中定义好的可以用于format格式字符串中字段有哪些:
字段/属性名称
使用格式
</th> </tr> <tr> <td> asctime </td> <td> %(asctime)s </td> <td>
日志事件发生的时间--人类可读时间,如:2003-07-08 16:49:45,896
</td> </tr> <tr> <td> created </td> <td> %(created)f </td> <td>
日志事件发生的时间--时间戳,就是当时调用time.time()函数返回的值
</td> </tr> <tr> <td> relativeCreated </td> <td> %(relativeCreated)d </td> <td>
日志事件发生的时间相对于logging模块加载时间的相对毫秒数(目前还不知道干嘛用的)
</td> </tr> <tr> <td> msecs </td> <td> %(msecs)d </td> <td>
日志事件发生事件的毫秒部分
</td> </tr> <tr> <td> levelname </td> <td> %(levelname)s </td> <td>
该日志记录的文字形式的日志级别('DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL')
('DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL')
</td> </tr> <tr> <td> levelno </td> <td> %(levelno)s </td> <td>
该日志记录的数字形式的日志级别(10, 20, 30, 40, 50)
</td> </tr> <tr> <td> name </td> <td> %(name)s </td> <td>
所使用的日志器名称,默认是'root',因为默认使用的是 rootLogger
</td> </tr> <tr> <td> message </td> <td> %(message)s </td> <td>
日志记录的文本内容,通过 msg % args计算得到的
msg % args
</td> </tr> <tr> <td> pathname </td> <td> %(pathname)s </td> <td>
调用日志记录函数的源码文件的全路径
</td> </tr> <tr> <td> filename </td> <td> %(filename)s </td> <td>
pathname的文件名部分,包含文件后缀
</td> </tr> <tr> <td> module </td> <td> %(module)s </td> <td>
filename的名称部分,不包含后缀
</td> </tr> <tr> <td> lineno </td> <td> %(lineno)d </td> <td>
调用日志记录函数的源代码所在的行号
</td> </tr> <tr> <td> funcName </td> <td> %(funcName)s </td> <td>
调用日志记录函数的函数名
</td> </tr> <tr> <td> process </td> <td> %(process)d </td> <td>
进程ID
</td> </tr> <tr> <td> processName </td> <td> %(processName)s </td> <td>
进程名称,Python 3.1新增
</td> </tr> <tr> <td> thread </td> <td> %(thread)d </td> <td>
线程ID
</td> </tr> <tr> <td> threadName </td> <td> %(thread)s </td> <td>
线程名称
logging.basicConfig(level=logging.DEBUG) logging.debug("This is a debug log.") logging.info("This is a info log.") logging.warning("This is a warning log.") logging.error("This is a error log.") logging.critical("This is a critical log.")
DEBUG:root:This is a debug log. INFO:root:This is a info log. WARNING:root:This is a warning log. ERROR:root:This is a error log. CRITICAL:root:This is a critical log.
所有等级的日志信息都被输出了,说明配置生效了。
LOG_FORMAT = "%(asctime)s - %(levelname)s - %(message)s" logging.basicConfig(filename='my.log', level=logging.DEBUG, format=LOG_FORMAT) logging.debug("This is a debug log.") logging.info("This is a info log.") logging.warning("This is a warning log.") logging.error("This is a error log.") logging.critical("This is a critical log.")
此时会发现控制台中已经没有输出日志内容了,但是在python代码文件的相同目录下会生成一个名为'my.log'的日志文件,该文件中的内容为:
2017-05-08 14:29:53,783 - DEBUG - This is a debug log. 2017-05-08 14:29:53,784 - INFO - This is a info log. 2017-05-08 14:29:53,784 - WARNING - This is a warning log. 2017-05-08 14:29:53,784 - ERROR - This is a error log. 2017-05-08 14:29:53,784 - CRITICAL - This is a critical log.
LOG_FORMAT = "%(asctime)s - %(levelname)s - %(message)s" DATE_FORMAT = "%m/%d/%Y %H:%M:%S %p" logging.basicConfig(filename='my.log', level=logging.DEBUG, format=LOG_FORMAT, datefmt=DATE_FORMAT) logging.debug("This is a debug log.") logging.info("This is a info log.") logging.warning("This is a warning log.") logging.error("This is a error log.") logging.critical("This is a critical log.")
此时会在my.log日志文件中看到如下输出内容:
05/08/2017 14:29:04 PM - DEBUG - This is a debug log. 05/08/2017 14:29:04 PM - INFO - This is a info log. 05/08/2017 14:29:04 PM - WARNING - This is a warning log. 05/08/2017 14:29:04 PM - ERROR - This is a error log. 05/08/2017 14:29:04 PM - CRITICAL - This is a critical log.
掌握了上面的内容之后,已经能够满足我们平时开发中需要的日志记录功能。
logging.basicConfig()
RootLogger
logging.warning('%s is %d years old.', 'Tom', 10)
WARNING:root:Tom is 10 years old.
exc_info, stack_info, extra
在日志消息中添加exc_info和stack_info信息,并添加两个自定义的字端 ip和user
LOG_FORMAT = "%(asctime)s - %(levelname)s - %(user)s[%(ip)s] - %(message)s" DATE_FORMAT = "%m/%d/%Y %H:%M:%S %p" logging.basicConfig(format=LOG_FORMAT, datefmt=DATE_FORMAT) logging.warning("Some one delete the log file.", exc_info=True, stack_info=True, extra={'user': 'Tom', 'ip':'47.98.53.222'})
05/08/2017 16:35:00 PM - WARNING - Tom[47.98.53.222] - Some one delete the log file. NoneType Stack (most recent call last): File "C:/Users/wader/PycharmProjects/LearnPython/day06/log.py", line 45, in <module> logging.warning("Some one delete the log file.", exc_info=True, stack_info=True, extra={'user': 'Tom', 'ip':'47.98.53.222'})
在介绍logging模块的高级用法之前,很有必要对logging模块所包含的重要组件以及其工作流程做个全面、简要的介绍,这有助于我们更好的理解我们所写的代码(将会触发什么样的操作)。
在介绍logging模块的日志流处理流程之前,我们先来介绍下logging模块的四大组件:
组件名称
</th>
对应类名
<th>
功能描述
</th> </tr> <tr> <td>
</th> </tr>
<tr>
<td>
日志器
</td> <td>
Logger
提供了应用程序可一直使用的接口
</td> </tr> <tr> <td>
处理器
Handler
将logger创建的日志记录发送到合适的目的输出
过滤器
Filter
提供了更细粒度的控制工具来决定输出哪条日志记录,丢弃哪条日志记录
格式器
Formatter
决定日志记录的最终输出格式
logging模块就是通过这些组件来完成日志处理的,上面所使用的logging模块级别的函数也是通过这些组件对应的类来实现的。
简单点说就是:日志器(logger)是入口,真正干活儿的是处理器(handler),处理器(handler)还可以通过过滤器(filter)和格式器(formatter)对要输出的日志内容做过滤和格式化等处理操作。
下面介绍下与logging四大组件相关的类:Logger, Handler, Filter, Formatter。
Logger对象有3个任务要做:
Logger对象最常用的方法分为两类:配置方法 和 消息发送方法
最常用的配置方法如下:
<table>
方法
Logger.setLevel()
设置日志器将会处理的日志消息的最低严重级别
Logger.addHandler() 和 Logger.removeHandler()
为该logger对象添加 和 移除一个handler对象
Logger.addFilter() 和Logger.removeFilter()
Logger.addFilter()
Logger.removeFilter()
为该logger对象添加 和 移除一个filter对象
关于Logger.setLevel()方法的说明: 内建等级中,级别最低的是DEBUG,级别最高的是CRITICAL。例如setLevel(logging.INFO),此时函数参数为INFO,那么该logger将只会处理INFO、WARNING、ERROR和CRITICAL级别的日志,而DEBUG级别的消息将会被忽略/丢弃。
关于Logger.setLevel()方法的说明:
内建等级中,级别最低的是DEBUG,级别最高的是CRITICAL。例如setLevel(logging.INFO),此时函数参数为INFO,那么该logger将只会处理INFO、WARNING、ERROR和CRITICAL级别的日志,而DEBUG级别的消息将会被忽略/丢弃。
logger对象配置完成后,可以使用下面的方法来创建日志记录:
Logger.debug(), Logger.info(), Logger.warning(), Logger.error(),Logger.critical()
创建一个与它们的方法名对应等级的日志记录
Logger.exception()
创建一个类似于Logger.error()的日志消息
Logger.log()
需要获取一个明确的日志level参数来创建一个日志记录
说明: Logger.exception()与Logger.error()的区别在于:Logger.exception()将会输出堆栈追踪信息,另外通常只是在一个exception handler中调用该方法。 Logger.log()与Logger.debug()、Logger.info()等方法相比,虽然需要多传一个level参数,显得不是那么方便,但是当需要记录自定义level的日志时还是需要该方法来完成。
Logger.exception()与Logger.error()的区别在于:Logger.exception()将会输出堆栈追踪信息,另外通常只是在一个exception handler中调用该方法。 Logger.log()与Logger.debug()、Logger.info()等方法相比,虽然需要多传一个level参数,显得不是那么方便,但是当需要记录自定义level的日志时还是需要该方法来完成。
那么,怎样得到一个Logger对象呢?一种方式是通过Logger类的实例化方法创建一个Logger类的实例,但是我们通常都是用第二种方式-- logging.getLogger()方法。
logging.getLogger()方法有一个可选参数name,该参数表示将要返回的日志器的名称标识,如果不提供该参数,则其值为'root'。若以相同的name参数值多次调用getLogger()方法,将会返回指向同一个logger对象的引用。
关于logger的层级结构与有效等级的说明: logger的名称是一个以'.'分割的层级结构,每个'.'后面的logger都是'.'前面的logger的children,例如,有一个名称为 foo 的logger,其它名称分别为 foo.bar, foo.bar.baz 和 foo.bam都是 foo 的后代。 logger有一个"有效等级(effective level)"的概念。如果一个logger上没有被明确设置一个level,那么该logger就是使用它parent的level;如果它的parent也没有明确设置level则继续向上查找parent的parent的有效level,依次类推,直到找到个一个明确设置了level的祖先为止。需要说明的是,root logger总是会有一个明确的level设置(默认为 WARNING)。当决定是否去处理一个已发生的事件时,logger的有效等级将会被用来决定是否将该事件传递给该logger的handlers进行处理。 child loggers在完成对日志消息的处理后,默认会将日志消息传递给与它们的祖先loggers相关的handlers。因此,我们不必为一个应用程序中所使用的所有loggers定义和配置handlers,只需要为一个顶层的logger配置handlers,然后按照需要创建child loggers就可足够了。我们也可以通过将一个logger的propagate属性设置为False来关闭这种传递机制。
关于logger的层级结构与有效等级的说明:
Handler对象的作用是(基于日志消息的level)将消息分发到handler指定的位置(文件、网络、邮件等)。Logger对象可以通过addHandler()方法为自己添加0个或者更多个handler对象。比如,一个应用程序可能想要实现以下几个日志需求:
一个handler中只有非常少数的方法是需要应用开发人员去关心的。对于使用内建handler对象的应用开发人员来说,似乎唯一相关的handler方法就是下面这几个配置方法:
Handler.setLevel()
设置handler将会处理的日志消息的最低严重级别
Handler.setFormatter()
为handler设置一个格式器对象
Handler.addFilter() 和 Handler.removeFilter()
为handler添加 和 删除一个过滤器对象
需要说明的是,应用程序代码不应该直接实例化和使用Handler实例。因为Handler是一个基类,它只定义了素有handlers都应该有的接口,同时提供了一些子类可以直接使用或覆盖的默认行为。下面是一些常用的Handler:
logging.StreamHandler
将日志消息发送到输出到Stream,如std.out, std.err或任何file-like对象。
std.out, std.err
file-like
logging.FileHandler
将日志消息发送到磁盘文件,默认情况下文件大小会无限增长
logging.handlers.RotatingFileHandler
将日志消息发送到磁盘文件,并支持日志文件按大小切割
logging.hanlders.TimedRotatingFileHandler
将日志消息发送到磁盘文件,并支持日志文件按时间切割
logging.handlers.HTTPHandler
将日志消息以GET或POST的方式发送给一个HTTP服务器
logging.handlers.SMTPHandler
将日志消息发送给一个指定的email地址
logging.NullHandler
该Handler实例会忽略error messages,通常被想使用logging的library开发者使用来避免'No handlers could be found for logger XXX'信息的出现。
Formater对象用于配置日志信息的最终顺序、结构和内容。与logging.Handler基类不同的是,应用代码可以直接实例化Formatter类。另外,如果你的应用程序需要一些特殊的处理行为,也可以实现一个Formatter的子类来完成。
Formatter类的构造方法定义如下:
logging.Formatter.__init__(fmt=None, datefmt=None, style='%')
可见,该构造方法接收3个可选参数:
Filter可以被Handler和Logger用来做比level更细粒度的、更复杂的过滤功能。Filter是一个过滤器基类,它只允许某个logger层级下的日志事件通过过滤。该类定义如下:
class logging.Filter(name='') filter(record)
比如,一个filter实例化时传递的name参数值为'A.B',那么该filter实例将只允许名称为类似如下规则的loggers产生的日志记录通过过滤:'A.B','A.B,C','A.B.C.D','A.B.D',而名称为'A.BB','B.A.B'的loggers产生的日志则会被过滤掉。如果name的值为空字符串,则允许所有的日志事件通过过滤。
'A.B','A.B,C','A.B.C.D','A.B.D'
'A.BB','B.A.B'
filter方法用于具体控制传递的record记录是否能通过过滤,如果该方法返回值为0表示不能通过过滤,返回值为非0表示可以通过过滤。
说明: 如果有需要,也可以在filter(record)方法内部改变该record,比如添加、删除或修改一些属性。 我们还可以通过filter做一些统计工作,比如可以计算下被一个特殊的logger或handler所处理的record数量等。
下面这个图描述了日志流的处理流程:
我们来描述下上面这个图的日志流处理流程:
可见,一条日志信息要想被最终输出需要依次经过以下几次过滤:
需要说明的是: 关于上面第9个步骤,如果propagate值为1,那么日志消息会直接传递交给上一级logger的handlers进行处理,此时上一级logger的日志等级并不会对该日志消息进行等级过滤。
现在,我们对logging模块的重要组件及整个日志流处理流程都应该有了一个比较全面的了解,下面我们来看一个例子。
现在有以下几个日志记录的需求:
import logging import logging.handlers import datetime logger = logging.getLogger('mylogger') logger.setLevel(logging.DEBUG) rf_handler = logging.handlers.TimedRotatingFileHandler('all.log', when='midnight', interval=1, backupCount=7, atTime=datetime.time(0, 0, 0, 0)) rf_handler.setFormatter(logging.Formatter("%(asctime)s - %(levelname)s - %(message)s")) f_handler = logging.FileHandler('error.log') f_handler.setLevel(logging.ERROR) f_handler.setFormatter(logging.Formatter("%(asctime)s - %(levelname)s - %(filename)s[:%(lineno)d] - %(message)s")) logger.addHandler(rf_handler) logger.addHandler(f_handler) logger.debug('debug message') logger.info('info message') logger.warning('warning message') logger.error('error message') logger.critical('critical message')
all.log文件输出
2017-05-13 16:12:40,612 - DEBUG - debug message 2017-05-13 16:12:40,612 - INFO - info message 2017-05-13 16:12:40,612 - WARNING - warning message 2017-05-13 16:12:40,612 - ERROR - error message 2017-05-13 16:12:40,613 - CRITICAL - critical message
error.log文件输出
2017-05-13 16:12:40,612 - ERROR - log.py[:81] - error message 2017-05-13 16:12:40,613 - CRITICAL - log.py[:82] - critical message
作为开发者,我们可以通过以下3中方式来配置logging:
fileConfig()
dictConfig()
除了传递给日志记录函数的参数外,有时候我们还想在日志输出中包含一些额外的上下文信息。比如,在一个网络应用中,可能希望在日志中记录客户端的特定信息,如:远程客户端的IP地址和用户名。这里我们来介绍以下几种实现方式:
extra
原文链接:https://www.cnblogs.com/yyds/p/6901864.html