1、日志的相关概念
日志是一种可以追踪某些软件运行时所发生事件的方法。软件开发人员可以向他们的代码中调用日志记录相关的方法来表明发生了某些事情。一个事件可以用一个可包含可选变量数据的消息来描述。此外,事件也有重要性的概念,这个重要性也可以被称为严重性级别(level)
日志的作用
通过log的分析,克以方便用户了解系统软件,和应用的运行情况,如果你的log足够丰富,也可以分析出用户的行为,类型喜好,地域分布等等。
若果一个应用的log同时也分了多个级别,那么可以很轻易的分析出应用的健康情况,及时发线问题并快速定位问题点,弥补损失。
简单的来说 我们可以通过记录和分析日志 可以了解一个系统或软件的运行情况是否正常,也可以快速定位问题点。
比如:
运维的同学在接收警报或个种问题反馈后 ,进行问题排查都会先看各种日志,大部分问题都是可以在日志中找到答案。
开发同学,可以通过ide控制台数出各种日志进行调试。
对于老运维或者有经验的开发人员,可以快速的通过日志定位到问题的根源。可见,日志的重要性不可小觑。日志的作用可以简单总结为以下3点:
- 程序调试
- 了解软件运行情况,是否正常
- 应用出现故障快速定位
如果应用的日志信息足够详细和丰富,还可以用来做用户行为分析,如:分析用户的操作行为、类型洗好、地域分布以及其它更多的信息,由此可以实现改进业务、提高商业利益。
日志的等级
我们先来思考下面的两个问题:
- 作为开发人员,在开发应用程序的时候需要什么日志信息,应用程序上线之后需要什么日志信息
- 作为运维人员,在部署开发环境需要什么日志信息,在部署生产环境之后需要什么日志信息
在软件开发阶段或部署开发环境时,为了尽可能详细的查看应用程序的运行状态来保证上线后的稳定性,我们可能需要把该应用程序所有的运行日志全部记录下来进行分析,这是非常耗费机器性能的。当应用程序正式发布或在生产环境部署应用程序时,我们通常只需要记录应用程序的异常信息、错误信息等,这样既可以减小服务器的I/O压力,也可以避免我们在排查故障时被淹没在日志的海洋里。那么,怎样才能在不改动应用程序代码的情况下实现在不同的环境记录不同详细程度的日志呢?这就是日志等级的作用了,我们通过配置文件指定我们需要的日志等级就可以了。
不同的应用程序所定义的日志等级可能会有所差别,分别详细点的包含一下几个等级:
一般用的时候会一起讨论日志级别的颜色。
详细作用:https://www.infoq.cn/article/five-levels-of-logging
ALL 最低等级的,用于打开所有日志记录。
TRACE designates finer-grained informational events than the DEBUG.Since:1.2.12,很低的日志级别,一般不会使用。
DEBUG 指出细粒度信息事件对调试应用程序是非常有帮助的,主要用于开发过程中打印一些运行信息。
INFO 消息在粗粒度级别上突出强调应用程序的运行过程。打印一些你感兴趣的或者重要的信息,这个可以用于生产环境中输出程序运行的一些重要信息,但是不能滥用,避免打印过多的日志。
WARN 表明会出现潜在错误的情形,有些信息不是错误信息,但是也要给程序员的一些提示。
ERROR 指出虽然发生错误事件,但仍然不影响系统的继续运行。打印错误和异常信息,如果不想输出太多的日志,可以使用这个级别。
FATAL 指出每个严重的错误事件将会导致应用程序的退出。这个级别比较高了。重大错误,这种级别你可以直接停止程序了。
OFF 最高等级的,用于关闭所有日志记录。
日志字段信息与日志格式
一条日志信息对应的是一个事件的发生,而一个事件通常需要包括以下几个内容:
- 事件发生时间
- 事件发生位置
- 事件严重程度--也就是日志级别
- 事件内容
出了上面这些 还可以包括什么其他信息,进程id,进程名称,线程id
说明:
输出一条日志时,日志内容和日志级别是需要开发人员明确指定的。对于而其它字段信息,只需要是否显示在日志中就可以了。
日志功能的实现
几乎所有的语言都有日志的相关功能,或者比较优秀的地三方库
python就有一个标准库logging模块
2、logging模块简介
logging模块定义的函数和类为应用程序和库的开发实现了一个灵活的事件日志系统。logging模块是Python的一个标准库模块,由标准库模块提供日志记录API的关键好处是所有Python模块都可以使用这个日志记录功能。所以,你的应用日志可以将你自己的日志信息与来自第三方模块的信息整合起来。
logging模块的日志级别
logging模块默认定义了以下几个日志等级,它允许开发人员自定义其他日志级别,但是这是不被推荐的,尤其是在开发供别人使用的库时,因为这会导致日志级别的混乱。
不能修改日志级别
级别 | 值 | 描述 |
---|---|---|
CRITICAL/FATAL | 50 | 关键错误/消息 |
ERROR | 40 | 错误 |
WARNING | 30 | 警告消息 |
INFO | 20 | 通知消息 |
DEBUG | 10 | 调试 |
NOTSET | 0 | 无级别 |
- 开饭应用程序或部署开发环境时
- 可以使用debug或info级别的日志获取尽可能详细的日志信息
- 应用上线或部署生产环境时
- 应该使用warning或error或critcal级别的日志来降低机器的I/O压力和提高获取错误日志信息效率。
- 日志级别的日志级别的指定通常是在配置文件进行指定。
当某个应用程序指定日志级别后,应用程序会记录所有日志级别大于或者小于指定日志级别的日志信息,
而不仅仅是指定日志级别的日志信息nginx、php等应用程序以及这里要提高的python的logging模块都是这样的。同样,logging模块也可以指定日志记录器的日志级别,只有级别大于或等于该指定日志级别的日志记录才会被输出,小于该等级的日志记录将会被丢弃。
logging模块的使用方式介绍
logging 有两种使用方式
- 第一种方式使用logging提供的模块级别的函数
- 也就是对logging日志系统相关类的封装
- 第二种是使用Logging日志系统的四大组件
logging模块定义的模块级别的常用函数
函数 | 说明 |
---|---|
logging.debug(msg, args, *kwargs) | 创建一条严重级别为DEBUG的日志记录 |
logging.info(msg, args, *kwargs) | 创建一条严重级别为INFO的日志记录 |
logging.warning(msg, args, *kwargs) | 创建一条严重级别为WARNING的日志记录 |
logging.error(msg, args, *kwargs) | 创建一条严重级别为ERROR的日志记录 |
logging.critical(msg, args, *kwargs) | 创建一条严重级别为CRITICAL的日志记录 |
logging.log(level, args, *kwargs) | 创建一条严重级别为level的日志记录 |
logging.basicConfig(**kwargs) | 对root logger进行一次性配置 |
其中logging.basicConfig(**kwargs)
函数用于指定“要记录的日志级别”、“日志格式”、“日志输出位置”、“日志文件的打开模式”等信息,其他几个都是用于记录各个级别日志的函数。
logging模块的四大组件
组件 | 说明 |
---|---|
日志记录器 loggers | 提供应用程序代码直接使用的接口 |
处理器 handlers | 用于将日志记录发送到指定的目的位置 |
过滤器 filters | 提供更细粒度的日志过滤功能,用于决定哪些日志记录将会被输出(其它的日志记录将会被忽略) |
格式化器formatters | 用于控制日志信息的最终输出格式 |
说明: logging模块提供的模块级别的那些函数实际上也是通过这几个组件的相关实现类来记录日志的,只是在创建这些类的实例时设置了一些默认值
3、使用logging提供的模块级别的函数记录日志
- 可以通过logging模块定制模块级别的方法完成简单日志记录
- 只有级别大于或等于日志记录器级别才能输出,小于的会呗抛弃
最简单的日志输出
先写一个简单不同的日志级别
import logging
logging.debug("debug log") #程序信息
logging.info("info log") # 用户级别信息
logging.warning("warning log") # 警告信息 潜在报警
logging.error("error log") # 有错但不影响运行
logging.fatal("fatal log") # 必须查看 可以停止程序
# 问前两个没有输出
也可以
logging.log(logging.DEBUG,"debug log")
logging.log(logging.INFO,"INFO log")
logging.log(logging.WARNING,"WARNING log")
logging.log(logging.ERROR,"ERROR log")
logging.log(logging.FATAL,"FATAL log")
输出结果:
WARNING:root:debug log
ERROR:root:debug log
CRITICAL:root:debug log
问题来了
问:为什么前两条为什么没有打印
这是因为logging模块提供的日志记录函数的日志级别WARNING(警告级别),因此WARNING级别大于它的error和fatal 输出小于的就被丢弃了
问:打印出来的是什么意识
因为:
WARNING:root:debug log
# 日志级别:日志器名称:日志内容
为什是这样的呢 日志器设置的日志格式默认的是BASIC_FORMAT
BASIC_FORMAT = "%(levelname)s:%(name)s:%(message)s" # 源码是460行
logging.basicCongfig()函数说明
这个方法用于logging日志的的一些基本配置
方法如下:
logging.basicConfig(**kwargs)
该函数可接收的关键字参数如下:
参数名称 | 描述 |
---|---|
filename | 指定日志输出目标文件的文件名,指定该设置项后日志信心就不会被输出到控制台了 |
filemode | 指定日志文件的打开模式,默认为‘a‘。需要注意的是,该选项要在filename指定时才有效 |
format | 指定日志格式字符串,即指定日志输出时所包含的字段信息以及它们的顺序。logging模块定义的格式字段下面会列出。 |
datefmt | 指定日期/时间格式。需要注意的是,该选项要在format中包含时间字段%(asctime)s时才有效 |
level | 指定日志器的日志级别 |
stream | 指定日志输出目标stream,如sys.stdout、sys.stderr以及网络stream。需要说明的是,stream和filename不能同时提供,否则会引发 ValueError 异常 |
style | Python 3.2中新添加的配置项。指定format格式字符串的风格,可取值为‘%‘、‘{‘和‘$‘,默认为‘%‘ |
handlers | Python 3.3中新添加的配置项。该选项如果被指定,它应该是一个创建了多个Handler的可迭代对象,这些handler将会被添加到root logger。需要说明的是:filename、stream和handlers这三个配置项只能有一个存在,不能同时出现2个或3个,否则会引发ValueError异常。 |
import logging
import time
import datetime
log_format = " %(process)d -%(module)s - %(name)s - %(asctime)s PM - %(levelname)s - %(message)s" # 固定写法
log_date = "%s"%datetime.datetime.now().date() # 定制时间
logging.basicConfig(
filemode="a", # 文件打开模式
filename="test", # 文件名
format=log_format, # 格式化
level=logging.DEBUG, # 级别定制
datefmt=log_date, # 定制时间格式
)
logging.debug("debug log") #程序信息
logging.info("info log") # 用户级别信息
logging.warning("warning log") # 警告信息 潜在报警
logging.error("error log") # 有错但不影响运行
logging.fatal("fatal log") # 必须查看 可以停
# 问前两个没有输出
logging模块定义的格式字符串字段
们来列举一下logging模块中定义好的可以用于format格式字符串中字段有哪些:
字段/属性名称 | 使用格式 | 描述 |
---|---|---|
asctime | %(asctime)s | 日志事件发生的时间--人类可读时间,如:2003-07-08 16:49:45,896 |
created | %(created)f | 日志事件发生的时间--时间戳,就是当时调用time.time()函数返回的值 |
relativeCreated | %(relativeCreated)d | 日志事件发生的时间相对于logging模块加载时间的相对毫秒数(目前还不知道干嘛用的) |
msecs | %(msecs)d | 日志事件发生事件的毫秒部分 |
levelname | %(levelname)s | 该日志记录的文字形式的日志级别(‘DEBUG‘, ‘INFO‘, ‘WARNING‘, ‘ERROR‘, ‘CRITICAL‘) |
levelno | %(levelno)s | 该日志记录的数字形式的日志级别(10, 20, 30, 40, 50) |
name | %(name)s | 所使用的日志器名称,默认是‘root‘,因为默认使用的是 rootLogger |
message | %(message)s | 日志记录的文本内容,通过 msg % args 计算得到的 |
pathname | %(pathname)s | 调用日志记录函数的源码文件的全路径 |
filename | %(filename)s | pathname的文件名部分,包含文件后缀 |
module | %(module)s | filename的名称部分,不包含后缀 |
lineno | %(lineno)d | 调用日志记录函数的源代码所在的行号 |
funcName | %(funcName)s | 调用日志记录函数的函数名 |
process | %(process)d | 进程ID |
processName | %(processName)s | 进程名称,Python 3.1新增 |
thread | %(thread)d | 线程ID |
threadName | %(thread)s | 线程名称 |
经过配置的日志输出
先简单配置下日志器的日志级别
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.")
此时我们就发现已经输出我的文件里面去了
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.
坑
- logging.basicConfig()是一个简单的配置工具,一次性的配置工具,也就是说只有在第一次该函数被调用的时候会气作用 ,多次调用并不会累加。
- logging.warning("%s is %s warning log."%("This",1))不能这样用。只能作为将变量数据作为第二个参数*args的值进行传递logging.warning("%s is %d warning log.g","This",3)
- 日志器(Logger)是有层级关系的,上面调用的logging模块级别的函数所使用的日志器是
RootLogger
类的实例,其名称为‘root‘,它是处于日志器层级关系最顶层的日志器,且该实例是以单例模式存在的 - logging.debug(), logging.info()等方法的定义中,除了msg和args参数外,还有一个**kwargs参数。它们支持3个关键字参数:
exc_info, stack_info, extra
,下面对这几个关键字参数作个说明。- exc_info: 其值为布尔值,如果该参数的值设置为True,则会将异常异常信息添加到日志消息中。如果没有异常信息则添加None到日志信息中。
- stack_info: 其值也为布尔值,默认值为False。如果该参数的值设置为True,栈信息将会被添加到日志信息中。
- extra: 这是一个字典(dict)参数,它可以用来自定义消息格式中所包含的字段,但是它的key不能与logging模块定义的字段冲突
例子:
在日志消息中添加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‘})
4、logging模块日志流处理流程
在介绍logging模块的高级用法之前,很有必要对logging模块所包含的重要组件以及其工作流程做个全面、简要的介绍,这有助于我们更好的理解我们所写的代码(将会触发什么样的操作)。
logging日志模块四大组件
在介绍logging模块的日志流处理流程之前,我们先来介绍下logging模块的四大组件:
组件名称 | 对应类名 | 功能描述 |
---|---|---|
日志器 | Logger | 提供了应用程序可一直使用的接口 |
处理器 | Handler | 将logger创建的日志记录发送到合适的目的输出 |
过滤器 | Filter | 提供了更细粒度的控制工具来决定输出哪条日志记录,丢弃哪条日志记录 |
格式器 | Formatter | 决定日志记录的最终输出格式 |
Logging是通过这些组件来完成日志处理的上面所使用的logging函数也是通过这几个类来实现的
这些组件之间的关系描述:
- 日志器(logger)需要通过处理器(handler)将日志信息输出到目标位置,如:文件、sys.stdout、网络等;
- 不同的处理器(handler)可以将日志输出到不同的位置;
- 日志器(logger)可以设置多个处理器(handler)将同一条日志记录输出到不同的位置;
- 每个处理器(handler)都可以设置自己的过滤器(filter)实现日志过滤,从而只保留感兴趣的日志;
- 每个处理器(handler)都可以设置自己的格式器(formatter)实现同一条日志以不同的格式输出到不同的地方。
简单的说日志器是入口,真正干活的是处理器,处理器还可通过过滤器和格式器对要输出的日志做过滤和格式化操作。
logging日志模块相关类及其常用方法介绍
下面介绍下与logging四大组件相关的类:Logger, Handler, Filter, Formatt
Logger类
logger对象有3个任务
- 向应用程序暴露代码几个方法,使应用程序可以在运行时记录日志
- 基于日志的等级过滤filter对象来决定要对那些日志进行后续处理
- 将日志信息传给所有感兴趣的日志handlers
logger对象最常用的方法分为两类:
- 配置方法
- 消息发送方法
最常用的配置方法如下:
方法 | 描述 |
---|---|
Logger.setLevel() | 设置日志器将会处理的日志消息的最低严重级别 |
Logger.addHandler() 和 Logger.removeHandler() | 为该logger对象添加 和 移除一个handler对象 |
Logger.addFilter() 和 Logger.removeFilter() | 为该logger对象添加 和 移除一个filter对象 |
关于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对象呢?一种方式是通过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来关闭这种传递机制。
Handler类
Handler对象的作用是(基于日志消息的level)将消息分发到handler指定的位置(文件、网络、邮件等)。Logger对象可以通过addHandler()方法为自己添加0个或者更多个handler对象。比如,一个应用程序可能想要实现以下几个日志需求:
- 1)把所有日志都发送到一个日志文件中;
- 2)把所有严重级别大于等于error的日志发送到stdout(标准输出);
- 3)把所有严重级别为critical的日志发送到一个email邮件地址。
这种场景就需要3个不同的handlers,每个handler复杂发送一个特定严重级别的日志到一个特定的位置。
一个handler中只有非常少数的方法是需要应用开发人员去关心的。对于使用内建handler对象的应用开发人员来说,似乎唯一相关的handler方法就是下面这几个配置方法:
方法 | 描述 |
---|---|
Handler.setLevel() | 设置handler将会处理的日志消息的最低严重级别 |
Handler.setFormatter() | 为handler设置一个格式器对象 |
Handler.addFilter() 和 Handler.removeFilter() | 为handler添加 和 删除一个过滤器对象 |
需要说明的是,应用程序代码不应该直接实例化和使用Handler实例。因为Handler是一个基类,它只定义了素有handlers都应该有的接口,同时提供了一些子类可以直接使用或覆盖的默认行为。下面是一些常用的Handler:
Handler | 描述 |
---|---|
logging.StreamHandler | 将日志消息发送到输出到Stream,如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类
Formater对象用于配置日志信息的最终顺序、结构和内容。与logging.Handler基类不同的是,应用代码可以直接实例化Formatter类。另外,如果你的应用程序需要一些特殊的处理行为,也可以实现一个Formatter的子类来完成。
Formatter类的构造方法定义如下:
logging.Formatter.__init__(fmt=None, datefmt=None, style=‘%‘)
可见,该构造方法接收3个可选参数:
- fmt:指定消息格式化字符串,如果不指定该参数则默认使用message的原始值
- datefmt:指定日期格式字符串,如果不指定该参数则默认使用"%Y-%m-%d %H:%M:%S"
- style:Python 3.2新增的参数,可取值为 ‘%‘, ‘{‘和 ‘$‘,如果不指定该参数则默认使用‘%‘
Filter类
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的值为空字符串,则允许所有的日志事件通过过滤。
filter方法用于具体控制传递的record记录是否能通过过滤,如果该方法返回值为0表示不能通过过滤,返回值为非0表示可以通过过滤。
说明:
- 如果有需要,也可以在filter(record)方法内部改变该record,比如添加、删除或修改一些属性。
- 我们还可以通过filter做一些统计工作,比如可以计算下被一个特殊的logger或handler所处理的record数量等。
logging日志流处理流程
我们来描述下上面这个图的日志流处理流程:
- 1)(在用户代码中进行)日志记录函数调用,如:logger.info(...),logger.debug(...)等;
- 2)判断要记录的日志级别是否满足日志器设置的级别要求(要记录的日志级别要大于或等于日志器设置的级别才算满足要求),如果不满足则该日志记录会被丢弃并终止后续的操作,如果满足则继续下一步操作;
- 3)根据日志记录函数调用时掺入的参数,创建一个日志记录(LogRecord类)对象;
- 4)判断日志记录器上设置的过滤器是否拒绝这条日志记录,如果日志记录器上的某个过滤器拒绝,则该日志记录会被丢弃并终止后续的操作,如果日志记录器上设置的过滤器不拒绝这条日志记录或者日志记录器上没有设置过滤器则继续下一步操作--将日志记录分别交给该日志器上添加的各个处理器;
- 5)判断要记录的日志级别是否满足处理器设置的级别要求(要记录的日志级别要大于或等于该处理器设置的日志级别才算满足要求),如果不满足记录将会被该处理器丢弃并终止后续的操作,如果满足则继续下一步操作;
- 6)判断该处理器上设置的过滤器是否拒绝这条日志记录,如果该处理器上的某个过滤器拒绝,则该日志记录会被当前处理器丢弃并终止后续的操作,如果当前处理器上设置的过滤器不拒绝这条日志记录或当前处理器上没有设置过滤器测继续下一步操作;
- 7)如果能到这一步,说明这条日志记录经过了层层关卡允许被输出了,此时当前处理器会根据自身被设置的格式器(如果没有设置则使用默认格式)将这条日志记录进行格式化,最后将格式化后的结果输出到指定位置(文件、网络、类文件的Stream等);
- 8)如果日志器被设置了多个处理器的话,上面的第5-8步会执行多次;
- 9)这里才是完整流程的最后一步:判断该日志器输出的日志消息是否需要传递给上一级logger(之前提到过,日志器是有层级关系的)的处理器,如果propagate属性值为1则表示日志消息将会被输出到处理器指定的位置,同时还会被传递给parent日志器的handlers进行处理直到当前日志器的propagate属性为0停止,如果propagate值为0则表示不向parent日志器的handlers传递该消息,到此结束。
可见,一条日志信息要想被最终输出需要依次经过以下几次过滤:
- 日志器等级过滤;
- 日志器的过滤器过滤;
- 日志器的处理器等级过滤;
- 日志器的处理器的过滤器过滤;
需要说明的是: 关于上面第9个步骤,如果propagate值为1,那么日志消息会直接传递交给上一级logger的handlers进行处理,此时上一级logger的日志等级并不会对该日志消息进行等级过滤。
5、使用logging四大组件记录日志现在
我们对logging模块的重要组件及整个日志流处理流程都应该有了一个比较全面的了解,下面我们来看一个例子。
1. 需求
现在有以下几个日志记录的需求:
- 1)要求将所有级别的所有日志都写入磁盘文件中
- 2)all.log文件中记录所有的日志信息,日志格式为:日期和时间 - 日志级别 - 日志信息
- 3)error.log文件中单独记录error及以上级别的日志信息,日志格式为:日期和时间 - 日志级别 - 文件名[:行号] - 日志信息
- 4)要求all.log在每天凌晨进行日志切割
2. 分析
- 1)要记录所有级别的日志,因此日志器的有效level需要设置为最低级别--DEBUG;
- 2)日志需要被发送到两个不同的目的地,因此需要为日志器设置两个handler;另外,两个目的地都是磁盘文件,因此这两个handler都是与FileHandler相关的;
- 3)all.log要求按照时间进行日志切割,因此他需要用logging.handlers.TimedRotatingFileHandler; 而error.log没有要求日志切割,因此可以使用FileHandler;
- 4)两个日志文件的格式不同,因此需要对这两个handler分别设置格式器;
3. 代码实现
import logging
import logging.handlers
import datetime
print(datetime.datetime.now())
logger = logging.getLogger(‘mylogger‘)
logger.setLevel(logging.DEBUG)
# 设置邮箱存入本地加入时间间隔
rf_handler = logging.handlers.TimedRotatingFileHandler(‘all.log‘, when=‘midnight‘, interval=1, backupCount=7, atTime=datetime.datetime.now())
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 - %(name)s - %(levelname)s - %(filename)s[:%(lineno)d] - %(message)s"))
# 设置日志发送邮箱邮箱
ret = logging.handlers.SMTPHandler(
mailhost=("smtp.163.com",25), # 设置服务器
fromaddr="chunsheng199433@163.com", # 设置用户客户端
toaddrs=["jiangyi@oldboyedu.com"],# 设置服务端
subject="logging from my app", # 设置标题
credentials=["chunsheng199433@163.com","*******"], #设置你的用户名和密码
)
ret.setLevel(logging.DEBUG)
ret.setFormatter(logging.Formatter("%(asctime)s - %(levelname)s - %(message)s"))
# ret.setFormatter(logging.Formatter("%(asctime)s - %(name)s - %(levelname)s - %(filename)s[:%(lineno)d] - %(message)s"))
logger.addHandler(rf_handler)
logger.addHandler(ret)
logger.addHandler(f_handler)
logger.debug(‘debug message‘)
logger.info(‘info message‘)
logger.warning(‘warning message‘)
logger.error(‘error message‘)
logger.critical("critical 我是警告")
6、django使用日志
settings.py
BASE_LOG_DIR = os.path.join(BASE_DIR, "logs")
import logging
LOGGING = {
‘version‘: 1,
‘disable_existing_loggers‘: False,
‘formatters‘: {
‘standard‘: {
‘format‘: ‘[%(levelname)s][%(asctime)s][%(filename)s][%(funcName)s][%(lineno)d] > %(message)s‘
},
‘simple‘: {
‘format‘: ‘[%(levelname)s]> %(message)s‘,
‘datefmt‘: ‘%Y-%m-%d %H:%M:%S‘
},
},
‘filters‘: {
‘require_debug_true‘: {
‘()‘: ‘django.utils.log.RequireDebugTrue‘,
},
},
‘handlers‘: {
‘console‘: {
‘level‘: ‘DEBUG‘,
‘filters‘: [‘require_debug_true‘],
‘class‘: ‘logging.StreamHandler‘,
‘formatter‘: ‘simple‘
},
‘file_handler‘: {
‘level‘: ‘INFO‘,
‘class‘: ‘logging.handlers.TimedRotatingFileHandler‘,
‘filename‘: os.path.join(BASE_LOG_DIR, ‘django.log‘),
‘formatter‘: ‘standard‘,
‘encoding‘: ‘utf-8‘
}, # 用于文件输出
‘error‘: { # error 定义类型错误
‘level‘: ‘ERROR‘,
‘class‘: ‘logging.handlers.RotatingFileHandler‘, # 保存到文件,自动切
‘filename‘: os.path.join(BASE_LOG_DIR, ‘django.errorlog‘), # 日志文件
‘maxBytes‘: 1024 * 1024 * 50, # 日志大小 50M
‘backupCount‘: 5,
‘formatter‘: ‘standard‘,
‘encoding‘: ‘utf-8‘,
},
‘mail_admins‘: {
‘level‘: ‘ERROR‘,
‘class‘: ‘django.utils.log.AdminEmailHandler‘,
‘formatter‘: ‘standard‘
},
},
‘loggers‘: {
‘mdjango‘: {
# 一个记录器中可以使用多个处理器
‘handlers‘: [‘console‘, ‘file_handler‘,"error"], # 挂载
‘level‘: ‘DEBUG‘,
‘propagate‘: True,
},
‘django.request‘: {
‘handlers‘: [‘mail_admins‘],
‘level‘: ‘ERROR‘,
‘propagate‘: False,
},
}
}
logger = logging.getLogger("mdjango")
views.py
from django.shortcuts import render,HttpResponse
import logging
from django_log.settings import logger
# Create your views here.
def login(request):
logger.info("IndexHandler request Handler begin")
logger.debug(‘query total:‘)
logger.error("error")
logger.warning("warning")
return HttpResponse("ok")
自己定义
import logging
class Singleton(object):
_instance = None
def __new__(cls, *args, **kwargs):
if not cls._instance:
cls._instance = super(Singleton, cls).__new__(cls,
*args, **kwargs)
return cls._instance
app_name = "appName"
log_file = "test.log"
class SingletonLogger(Singleton):
def __init__(self):
super(SingletonLogger, self).__init__()
self.logger = logging.getLogger(app_name)
format_str = "[%(asctime)s][%(levelname)s]> %(message)s"
formatter = logging.Formatter(format_str)
file_handler = logging.FileHandler(log_file)
file_handler.setFormatter(formatter)
self.logger.addHandler(file_handler)
self.logger.setLevel(logging.INFO)
def debug(self, data):
self.logger.debug(data)
def info(self, data):
self.logger.info(data)
def warning(self, data):
self.logger.warning(data)
def error(self, data):
self.logger.error(data)
#执行函数
def test_log():
logger = SingletonLogger()
#output the log msg
logger.debug("this is the debug message")
logger.info("this is the info message")
logger.warning("this is the warning message")
logger.error("this is the error message")
标签:比较 proc UNC 改变 经验 简单的 ike levels val
原文地址:https://www.cnblogs.com/taosiyu/p/11438314.html