请使用支持脚本的浏览器！
该日志尚未公开，你暂时不能查看。博主可在此
不如去逛逛吧。
网易公司版权所有&&&当前位置： &
3,464 次阅读 -
在现实生活中，记录日志非常重要。银行转账时会有转账记录；飞机飞行过程中，会有黑盒子（飞行数据记录器）记录飞行过程中的一切。如果有出现什么问题，人们可以通过日志数据来搞清楚到底发生了什么。
对于系统开发、调试以及运行，记录日志都是同样的重要。如果没有日志记录，程序崩溃时你几乎就没办法弄明白到底发生了什么事情。举个例子，当你在写一个服务器程序时，记录日志是非常有必要的。下面展示的就是 EZComet.com 服务器的日志文件截图。
服务崩溃后，如果没有日志，我几乎没办法知道到底发生了错误。日志不仅对于服务器很重要，对于桌面图形应用同样十分重要。比如，当你的客户的 PC 机程序崩溃时，你可以让他们把日志文件发给你，这样你就可以找到问题到底出在哪儿。相信我，在不同的 PC 环境下，你永远不会知道会有怎样奇怪的问题。我曾经就接收到过这样的错误日志。
2011-08-22 17:52:54,828 - root - ERROR - [Errno 10104] getaddrinfo failed
Traceback (most recent call last):
File "&string&", line 124, in main
File "&string&", line 20, in __init__
File "h:workspaceprojectbuildpyi.win32mrdjoutPYZ1.pyz/wx._core", line 7978, in __init__
File "h:workspaceprojectbuildpyi.win32mrdjoutPYZ1.pyz/wx._core", line 7552, in _BootstrapApp
File "&string&", line 84, in OnInit
File "h:workspaceprojectbuildpyi.win32mrdjoutPYZ1.pyz/twisted.internet.wxreactor", line 175, in install
File "h:workspaceprojectbuildpyi.win32mrdjoutPYZ1.pyz/twisted.internet._threadedselect", line 106, in __init__
File "h:workspaceprojectbuildpyi.win32mrdjoutPYZ1.pyz/twisted.internet.base", line 488, in __init__
File "h:workspaceprojectbuildpyi.win32mrdjoutPYZ1.pyz/twisted.internet.posixbase", line 266, in installWaker
File "h:workspaceprojectbuildpyi.win32mrdjoutPYZ1.pyz/twisted.internet.posixbase", line 74, in __init__
File "h:workspaceprojectbuildpyi.win32mrdjoutPYZ1.pyz/socket", line 224, in meth
gaierror: [Errno 10104] getaddrinfo failed
我最终发现，这个客户的 PC 机被一种病毒感染，导致了调用 gethostname 函数失败。看吧，如果没有日志可以查你怎么可能知道这些。
打印输出不是个好办法
尽管记录日志非常重要，但是并不是所有的开发者都能正确地使用它。我曾看到一些开发者是这样记录日志的，在开发的过程中插入 print 语句，开发结束后再将这些语句移除。就像这样:
print 'Start reading database'
records = model.read_recrods()
print '# records', records
print 'Updating record ...'
model.update_records(records)
print 'done'
这种方式对于简单脚本型程序有用，但是如果是复杂的系统，你最好不要使用这样的方式。首先，你没办法做到在日志文件中只留下极其重要的消息。你会看到大量的消息日志。但是你却找不到任何有用的信息。你除了移除这输出语句这外，没别的办法控制代码，但是极有可能的是你忘记了移出那些没用的输出。再者，print 输出的所有信息都到了标准输出中，这将严重影响到你从标准输出中查看其它输出数据。当然，你也可以把消息输出到 stderr ，但是用 print 做日志记录的方式还是不好。
使用 python 的标准日志模块
那么，怎么样记录日志才是正确的呢？其实非常简单，使用 python 的标准日志模块。多亏 python 社区将日志做成了一个标准模块。它非常简单易用且十分灵活。你可以像这样使用日志系统：
import logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)
logger.info('Start reading database')
records = {'john': 55, 'tom': 66}
logger.debug('Records: %s', records)
logger.info('Updating records ...')
logger.info('Finish updating records')
运行的时候就可看到：
INFO:__main__:Start reading database
INFO:__main__:Updating records ...
INFO:__main__:Finish updating records
你可能会问这与使用 print 有什么不同呢。它有以下的优势：
你可以控制消息的级别，过滤掉那些并不重要的消息。
你可决定输出到什么地方，以及怎么输出。
有许多的重要性别级可供选择，debug、info、warning、error 以及 critical。通过赋予 logger 或者 handler 不同的级别，你就可以只输出错误消息到特定的记录文件中，或者在调试时只记录调试信息。让我们把 logger 的级别改成 DEBUG 再看一下输出结果：
logging.basicConfig(level=logging.DEBUG)
输出变成了：
INFO:__main__:Start reading database
DEBUG:__main__:Records: {'john': 55, 'tom': 66}
INFO:__main__:Updating records ...
INFO:__main__:Finish updating records
正如看到的那样，我们把 logger 的等级改为 DEBUG 后，调试记录就出现在了输出当中。你也可以选择怎么处理这些消息。例如，你可以使用 FileHandler 把记录写进文件中：
import logging
logger = logging.getLogger(__name__)
logger.setLevel(logging.INFO)
handler = logging.FileHandler('hello.log')
handler.setLevel(logging.INFO)
formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)
logger.info('Hello baby')
标准库模块中提供了许多的 handler ，你可以将记录发送到邮箱甚至发送到一个远程的服务器。你也可以实现自己的记录 handler 。这里将不具体讲述实现的细节，你可以参考官方文档：、 与 。
以合适的等级输出日志记录
有了灵活的日志记录模块后，你可以按适当的等级将日志记录输出到任何地方然后配置它们。那么你可能会问，什么是合适的等级呢？在这儿我将分享一些我的经验。
大多数的情况下，你都不想阅读日志中的太多细节。因此，只有你在调试过程中才会使用 DEBUG 等级。我只使用 DEBUG 获取详细的调试信息，特别是当数据量很大或者频率很高的时候，比如算法内部每个循环的中间状态。
def complex_algorithm(items):
for i, item in enumerate(items):
logger.debug('%s iteration, item=%s', i, item)
在处理请求或者服务器状态变化等日常事务中，我会使用 INFO 等级。
def handle_request(request):
logger.info('Handling request %s', request)
result = 'result'
logger.info('Return result: %s', result)
def start_service():
logger.info('Starting service at port %s ...', port)
service.start()
logger.info('Service is started')
当发生很重要的事件，但是并不是错误时，我会使用 WARNING 。比如，当用户登录密码错误时，或者连接变慢时。
def authenticate(user_name, password, ip_address):
if user_name != USER_NAME and password != PASSWORD:
logger.warn('Login attempt to %s from IP %s', user_name, ip_address)
return False
有错误发生时肯定会使用 ERROR 等级了。比如抛出异常，IO 操作失败或者连接问题等。
def get_user_by_id(user_id):
user = db.read_user(user_id)
if user is None:
logger.error('Cannot find user with user_id=%s', user_id)
return user
return user
我很少使用 CRITIAL 。当一些特别糟糕的事情发生时，你可以使用这个级别来记录。比方说，内存耗尽，磁盘满了或者核危机（希望永远别发生 :S）。
使用 __name__ 作为 logger 的名称
虽然不是非得将 logger 的名称设置为 __name__ ，但是这样做会给我们带来诸多益处。在 python 中，变量 __name__ 的名称就是当前模块的名称。比如，在模块 “foo.bar.my_module” 中调用 logger.getLogger(__name__) 等价于调用logger.getLogger(“foo.bar.my_module”) 。当你需要配置 logger 时，你可以配置到 “foo” 中，这样包 foo 中的所有模块都会使用相同的配置。当你在读日志文件的时候，你就能够明白消息到底来自于哪一个模块。
捕捉异常并使用 traceback 记录它
出问题的时候记录下来是个好习惯，但是如果没有 traceback ，那么它一点儿用也没有。你应该捕获异常并用 traceback 把它们记录下来。比如下面这个例子：
open('/path/to/does/not/exist', 'rb')
except (SystemExit, KeyboardInterrupt):
except Exception, e:
logger.error('Failed to open file', exc_info=True)
使用参数 exc_info=true 调用 logger 方法, traceback 会输出到 logger 中。你可以看到下面的结果：
ERROR:__main__:Failed to open file
Traceback (most recent call last):
File "example.py", line 6, in &module&
open('/path/to/does/not/exist', 'rb')
IOError: [Errno 2] No such file or directory: '/path/to/does/not/exist'
你也可以调用 logger.exception(msg, _args)，它等价于 logger.error(msg, exc_info=True, _args)。
千万不要在模块层次获取 Logger，除非 disable_existing_loggers 被设置为 False
你可以看到很多在模块层次获取 logger 的例子（在这篇文章我也使用了很多，但这仅仅为了让示例更短一些）。它们看上去没什么坏处，但事实上，这儿是有陷阱的 – 如果你像这样在模块中使用 Logger，Python 会保留从文件中读入配置前所有创建的所有 logger。
my_module.py
import logging
logger = logging.getLogger(__name__)
def foo():
logger.info('Hi, foo')
class Bar(object):
def bar(self):
logger.info('Hi, bar')
import logging
logger = logging.getLogger(__name__)
def foo():
logger.info('Hi, foo')
class Bar(object):
def bar(self):
logger.info('Hi, bar')
logging.ini
[handlers]
keys=consoleHandler
[formatters]
keys=simpleFormatter
[logger_root]
level=DEBUG
handlers=consoleHandler
[handler_consoleHandler]
class=StreamHandler
level=DEBUG
formatter=simpleFormatter
args=(sys.stdout,)
[formatter_simpleFormatter]
format=%(asctime)s - %(name)s - %(levelname)s - %(message)s
本应该在日志中看到记录，但是你却什么也没有看到。为什么呢？这就是因为你在模块层次创建了 logger，然后你又在加载日志配置文件之前就导入了模块。logging.fileConfig 与 logging.dictConfig 默认情况下会使得已经存在的 logger 失效。所以，这些配置信息不会应用到你的 Logger 上。你最好只在你需要 logger 的时候才获得它。反正创建或者取得 logger 的成本很低。你可以这样写你的代码：
import logging
def foo():
logger = logging.getLogger(__name__)
logger.info('Hi, foo')
class Bar(object):
def __init__(self, logger=None):
self.logger = logger or logging.getLogger(__name__)
def bar(self):
self.logger.info('Hi, bar')
这样，logger 就会在你加载配置后才会被创建。这样配置信息就可以正常应用。
python2.7 之后的版本中 fileConfg 与 dictConfig 都新添加了 “disable_existing_loggers” 参数，将其设置为 False，上面提到的问题就可以解决了。例如：
import logging
import logging.config
logger = logging.getLogger(__name__)
logging.config.dictConfig({
'version': 1,
'disable_existing_loggers': False,
'formatters': {
'standard': {
'format': '%(asctime)s [%(levelname)s] %(name)s: %(message)s'
'handlers': {
'default': {
'level':'INFO',
'class':'logging.StreamHandler',
'loggers': {
'handlers': ['default'],
'level': 'INFO',
'propagate': True
logger.info('It works!')
使用 JSON 或者 YAML 记录配置
虽然你可以在 python 代码中配置你的日志系统，但是这样并不够灵活。最好的方法是使用一个配置文件来配置。在 Python2.7 及之后的版本中，你可以从字典中加载 logging 配置。这也就意味着你可以从 JSON 或者 YAML 文件中加载日志的配置。尽管你还能用原来 .ini 文件来配置，但是它既很难读也很难写。下面我给你们看一个用 JSON 和 YAML 文件配置的例子:
logging.json
"version": 1,
"disable_existing_loggers": false,
"formatters": {
"simple": {
"format": "%(asctime)s - %(name)s - %(levelname)s - %(message)s"
"handlers": {
"console": {
"class": "logging.StreamHandler",
"level": "DEBUG",
"formatter": "simple",
"stream": "ext://sys.stdout"
"info_file_handler": {
"class": "logging.handlers.RotatingFileHandler",
"level": "INFO",
"formatter": "simple",
"filename": "info.log",
"maxBytes": ,
"backupCount": 20,
"encoding": "utf8"
"error_file_handler": {
"class": "logging.handlers.RotatingFileHandler",
"level": "ERROR",
"formatter": "simple",
"filename": "errors.log",
"maxBytes": ,
"backupCount": 20,
"encoding": "utf8"
"loggers": {
"my_module": {
"level": "ERROR",
"handlers": ["console"],
"propagate": "no"
"level": "INFO",
"handlers": ["console", "info_file_handler", "error_file_handler"]
logging.yaml
version: 1
disable_existing_loggers: False
formatters:
format: "%(asctime)s - %(name)s - %(levelname)s - %(message)s"
class: logging.StreamHandler
level: DEBUG
formatter: simple
stream: ext://sys.stdout
info_file_handler:
class: logging.handlers.RotatingFileHandler
level: INFO
formatter: simple
filename: info.log
backupCount: 20
encoding: utf8
error_file_handler:
class: logging.handlers.RotatingFileHandler
level: ERROR
formatter: simple
filename: errors.log
backupCount: 20
encoding: utf8
my_module:
level: ERROR
handlers: [console]
propagate: no
level: INFO
handlers: [console, info_file_handler, error_file_handler]
接下来将展示怎样从 JSON 文件中读入日志的配置信息：
import json
import logging.config
def setup_logging(
default_path='logging.json',
default_level=logging.INFO,
env_key='LOG_CFG'
path = default_path
value = os.getenv(env_key, None)
path = value
if os.path.exists(path):
with open(path, 'rt') as f:
config = json.load(f)
logging.config.dictConfig(config)
logging.basicConfig(level=default_level)
使用 JSON 的一个优点就是 json是一个标准库，你不需要额外安装它。但是从我个人来说，我比较喜欢 YAML 一些。它无论是读起来还是写起来都比较容易。你也可以使用下面的方法来加载一个 YAML 配置文件：
import logging.config
import yaml
def setup_logging(
default_path='logging.yaml',
default_level=logging.INFO,
env_key='LOG_CFG'
path = default_path
value = os.getenv(env_key, None)
path = value
if os.path.exists(path):
with open(path, 'rt') as f:
config = yaml.load(f.read())
logging.config.dictConfig(config)
接下来，你就可以在运行程序的时候调用 setup_logging 来启动日志记录了。它默认会读取 logging.json 或 logging.yaml 文件 。你也可以设置环境变量 LOG_CCFG 从指定路径加载日志配置。例如：
LOG_CFG=my_logging.json python my_server.py
如果你喜欢 YAML：
LOG_CFG=my_logging.yaml python my_server.py
使用旋转文件句柄
如果你用 FileHandler 写日志，文件的大小会随着时间推移而不断增大。最终有一天它会占满你所有的磁盘空间。为了避免这种情况出现，你可以在你的生成环境中使用 RotatingFileHandler 替代 FileHandler。
如果你有多个服务器可以启用一个专用的日志服务器
当你有多个服务器和不同的日志文件时，你可以创建一个集中式的日志系统来收集重要的（大多数情况是警告或者错误消息）信息。然后通过监测这些日志信息，你就可以很容易地发现系统中的问题了。
Python 的日志库设计得如此之好，真是让人欣慰，我觉得这是标准库中最好的一部分了，你不得不选择它。它很灵活，你可以用你自己的 handler 或者 filter。已经有很多的第三方的 handler 了，比如 pyzmq 提供的 ZeroMQ 日志句柄，它允许你通过 zmq 套接字发送日志消息。如果你还不知道怎么正确的使用日志系统，这篇文章将会非常有用。有了很好的日志记录实践，你就能非常容易地发现系统中的问题。这是很非常值得投资的。:)
翻译 英文出处：
注：转载文章均来自于公开网络，仅供学习使用，不会用于任何商业用途，如果侵犯到原作者的权益，请您与我们联系删除或者授权事宜，联系邮箱：contact@dataunion.org。转载数盟网站文章请注明原文章作者，否则产生的任何版权纠纷与数盟无关。
相关文章！
不用想啦，马上 发表自已的想法.
做最棒的数据科学社区
扫描二维码,加微信公众号
联系我们：一篇文章教你如何用 Python 记录日志
编译： Python开发者 - 李趴趴要化身女超人，英文：Mario Corchero
http://python.jobbole.com/89007/
对一名开发者来说最糟糕的情况，莫过于要弄清楚一个不熟悉的应用为何不工作。有时候，你甚至不知道系统运行，是否跟原始设计一致。
在线运行的应用就是黑盒子，需要被跟踪监控。最简单也最重要的方式就是记录日志。记录日志允许我们在开发软件的同时，让程序在系统运行时发出信息，这些信息对于我们和系统管理员来说都是有用的。
就像为将来的程序员写代码文档一样，我们应该让新软件产生足够的日志供系统的开发者和管理员使用。日志是关于应用运行状态的系统文件的关键部分。给软件加日志产生句时，要向给未来维护系统的开发者和管理员写文档一样。
一些纯粹主义者认为一个受过训练的开发者使用日志和测试的时候几乎不需要交互调试器。如果我们不能用详细的日志解释开发过程中的应用，那么当代码在线上运行的时候，解释它们会变得更困难。
这篇文章介绍了 Python 的 logging 模块，包括它的设计以及针对更多复杂案例的适用方法。这篇文章不是写给开发者的文档，它更像是一个指导手册，来说明 Python 的 logging 模板是如何搭建的，并且激发感兴趣的人深入研究。
为什么使用 logging 模块？
也许会有开发者会问，为什么不是简单的 print 语句呢？ Logging 模块有很多优势，包括：
多线程支持
通过不同级别的日志分类
灵活性和可配置性
将如何记录日志与记录什么内容分离
最后一点，将我们记录内容从记录方式中真正分离，保证了软件不同部分的合作。举个例子，它允许一个框架或库的开发者增加日志并且让系统管理员或负责运行配置的人员决定稍后应该记录什么。
Logging 模块中有什么
Logging 模块完美地将它的每个部分的职责分离（遵循 Apache Log4j API 的方法）。让我们看看一个日志线是如何通过这个模块的代码，并且研究下它的不同部分。
记录器（Logger）
记录器是开发者经常交互的对象。那些主要的 API 说明了我们想要记录的内容。
举个记录器的例子，我们可以分类请求发出一条信息，而不用担心它们是如何从哪里被发出的。
比如，当我们写下 logger.info(“Stock was sold at %s”, price) 我们在头脑中就有如下模块：
我们需要一条线。假设有些代码在记录器中运行，让这条线出现在控制台或文件中。但是在内部实际发生了什么呢？
日志记录是 logging 模块用来满足所有需求信息的包。它们包含了需要记录日志的地方、变化的字符串、参数、请求的信息队列等信息。
它们都是被记录的对象。每次我们调用记录器时，都会生成这些对象。但这些对象是如何序列化到流中的呢？通过处理器！
处理器将日志记录发送给其他输出终端，他们获取日志记录并用相关函数中处理它们。
比如，一个文件处理器将会获取一条日志记录，并且把它添加到文件中。
标准的 logging 模块已经具备了多种内置的处理器，例如：
多种文件处理器（TimeRotated, SizeRotated, Watched），可以写入文件中
StreamHandler 输出目标流比如 stdout 或 stderr
SMTPHandler 通过 email 发送日志记录
SocketHandler 将日志文件发送到流套接字
SyslogHandler、NTEventHandler、HTTPHandler及MemoryHandler等
目前我们有个类似于真实情况的模型：
大部分的处理器都在处理字符串(SMTPHandler和FileHandler等)。或许你想知道这些结构化的日志记录是如何转变为易于序列化的字节的。
格式器负责将丰富的元数据日志记录转换为字符串，如果什么都没有提供，将会有个默认的格式器。
一般的格式器类由 logging 库提供，采用模板和风格作为输入。然后占位符可以在一个 LogRecord 对象中声明所有属性。
比如：’%(asctime)s %(levelname)s %(name)s: %(message)s’ 将会生成日志类似于
15:31:13,942 INFO parent.child: Hello EuroPython.
请注意：属性信息是通过提供的参数对日志的原始模板进行插值的结果。（比如，对于 logger.info(“Hello %s”, “Laszlo”) 这条信息将会是 “Hello Laszlo”）
所有默认的属性都可以在日志文档中找到。
好了，现在我们了解了格式器，我们的模型又发生了变化：
我们日志工具的最后一个对象就是过滤器。
过滤器允许对应该发送的日志记录进行细粒度控制。多种过滤器能同时应用在记录器和处理器中。对于一条发送的日志来说，所有的过滤器都应该通过这条记录。
用户可以声明他们自己的过滤器作为对象，使用 filter 方法获取日志记录作为输入，反馈 True / False 作为输出。
出于这种考虑，以下是当前的日志工作流：
记录器层级
此时，你可能会对大量复杂的内容和巧妙隐藏的模块配置印象深刻，但是还有更需要考虑的：记录器分层。
我们可以通过 logging.getLogger() 创建一个记录器。这条字符向 getLogger 传递了一个参数，这个参数可以通过使用圆点分隔元素来定义一个层级。
举个例子，logging.getLogger(“parent.child”) 将会创建一个 “child” 的记录器，它的父级记录器叫做 “parent.” 记录器是被 logging 模块管理的全局对象，所以我们可以方便地在项目中的任何地方检索他们。
记录器的例子通常也被认为是渠道。层级允许开发者去定义渠道和他们的层级。
在日志记录被传递到所有记录器内的处理器时，父级处理器将会进行递归处理，直到我们到达顶级的记录器（被定义为一个空字符串），或者有一个记录器设置了 propagate = False。我们可通过更新的图中看出：
请注意父级记录器没有被调用，只有它的处理器被调用。这意味着过滤器和其他在记录器类中的代码不会在父级中被执行。当我们在记录器中增加过滤器时，这通常是个陷阱。
工作流小结
我们已经阐明过职责的划分以及我们是如何微调日志过滤。然而还是有两个其他的属性我们没有提及：
记录器可以是残缺的，从而不允许任何记录从这被发出。
一个有效的层级可以同时在记录器和处理器中被设置。
举个例子，当一个记录器被设置为 INFO 的等级，只有 INFO 等级及以上的才会被传递，同样的规则适用于处理器。
基于以上所有的考虑，最后的日志记录的流程图看起来像这样：
如何使用日志记录模块
现在我们已经了解了 logging 模块的部分及设计，是时候去了解一个开发者是如何与它交互的了。以下是一个代码例子：
import logging
def sample_function(secret_parameter):
logger= logging.getLogger(__name__)# __name__=projectA.moduleB
logger.debug("Going to perform magic with '%s'",secret_parameter)
result= do_magic(secret_parameter)
except IndexError:
logger.exception("OMG it happened again, someone please tell Laszlo")
logger.info("Unexpected exception",exc_info=True)
logger.info("Magic with '%s' resulted in '%s'",secret_parameter,result,stack_info=True)
它用模块 __name__创建了一个日志记录器。它会基于项目结构创建渠道和等级，正如 Pyhon 模块用圆点连接一样。
记录器变量引用记录器的 “module” ，用 “projectA” 作为父级， “root” 作为父级的父级。
在第五行，我们看到如何执行调用去发送日志。我们可以用 debug 、 info 、error 或 critical 这些方法之一在合适的等级上去记录日志。
当记录一条信息时，除了模板参数，我们可以通过特殊的含义传递密码参数，最有意思的是 exc_info 和 stack_info。它们将会分别增加关于当前异常和栈帧的信息。为了方便起见，在记录器对象中有一个方法异常，正如这个错误调用 exc_info=True 。
这些是如何使用记录器模块的基础，但是有些通常被认为是不良操作的做法同样值得说明。
过度格式化字符串
应该尽量避免使用 loggger.info(“string template {}”.format(argument)) ，可能的话尽量使用 logger.info(“string template %s”, argument)。 这是个更好的实践，因为只有当日志被发送时，字符串才会发生真正改变。当我们记录的层级在 INFO 之上时，不这么做会导致浪费周期，因为这个改变仍然会发生。
捕捉和格式化异常
通常，我们想记录在抓取模块异常的日志信息，如果这样写会很直观：
except Exception aserror:
logger.info("Something bad happened: %s",error)
但是这样的代码会给我们显示类似于 Something bad happened: “secret_key.” 的日志行，这并不是很有用。如果我们使用 exc_info 作为事先说明，那么它将会如下显示：
except Exception:
logger.info("Something bad happened",exc_info=True)
Something bad happened
Traceback(most recent call last):
File"sample_project.py",line10,incode
inner_code()
File"sample_project.py",line6,ininner_code
x= data["secret_key"]
KeyError: 'secret_key'
这不仅仅会包含异常的准确资源，同时也会包含它的类型。
设置记录器
装备我们的软件很简单，我们需要设置日志栈，并且制定这些记录是如何被发出的。
以下是设置日志栈的多种方法
这是至今最简单的设置日志记录的方法。使用 logging.basicConfig(level=”INFO”) 搭建一个基础的 StreamHandler ，这样就会记录在 INFO 上的任何东西，并且到控制台以上的级别。以下是编写基础设置的一些参数：
指定创建的文件处理器，使用特定的文件名，而不是流处理器
/var/logs/logs.txt
为处理器使用特定格式的字符串
“‘%(asctime)s %(message)s'”
使用特定的日期/时间格式
“%H:%M:%S”
为根记录器等级设置特定等级
在设置简单的脚本上，这是简单又使用的方法。
请注意， basicConfig 仅仅在运行的一开始可以这么调用。如果你已经设置了你的根记录器，调用 basicConfig 将不会奏效。
所有元素的设置以及如何连接它们可以作为字典来说明。这个字典应当由不同的部分组成，包括记录器、处理器、格式化以及一些基本的通用参数。
例子如下：
'disable_existing_loggers': False,
'version': 1,
'formatters': {
'short': {
'format': '%(asctime)s %(levelname)s %(name)s: %(message)s'
'handlers': {
'console': {
'level': 'INFO',
'formatter': 'short',
'class': 'logging.StreamHandler',
'loggers': {
'handlers': ['console'],
'level': 'ERROR',
'plugins': {
'handlers': ['console'],
'level': 'INFO',
'propagate': False
import logging.config
logging.config.dictConfig(config)
当被引用时， dictConfig 将会禁用所有运行的记录器，除非 disable_existing_loggers 被设置为 false。这通常是需要的，因为很多模块声明了一个全球记录器，它在 dictConfig 被调用之前被导入的时候将会实例化。
你可以查看 schema that can be used for the dictConfig method（链接）。通常，这些设置将会存储在一个 YAML 文件中，并且从那里设置。很多开发者会倾向于使用这种方式而不是使用 fileConfig（链接）,因为它为定制化提供了更好的支持。
拓展 logging
幸亏设计了这种方式，拓展 logging 模块很容易。让我们来看些例子：
logging JSON | 记录 JSON
只要我们想要记录，我们可以通过创建一种自定义格式化来记录 JSON ，它会将日志记录转化为 JSON 编码的字符串。
import logging
import logging.config
import json
ATTR_TO_JSON= ['created','filename','funcName','levelname','lineno','module','msecs','msg','name','pathname','process','processName','relativeCreated','thread','threadName']
classJsonFormatter:
def format(self,record):
obj= {attr: getattr(record,attr)
forattr inATTR_TO_JSON}
returnjson.dumps(obj,indent=4)
handler= logging.StreamHandler()
handler.formatter= JsonFormatter()
logger= logging.getLogger(__name__)
logger.addHandler(handler)
logger.error("Hello")
添加更多上下文
在格式化中，我们可以指定任何日志记录的属性。
我们可以通过多种方式增加属性，在这个例子中，我们用过滤器来丰富日志记录。
import logging
import logging.config
GLOBAL_STUFF= 1
classContextFilter(logging.Filter):
def filter(self,record):
globalGLOBAL_STUFF
GLOBAL_STUFF+= 1
record.global_data= GLOBAL_STUFF
returnTrue
handler= logging.StreamHandler()
handler.formatter= logging.Formatter("%(global_data)s %(message)s")
handler.addFilter(ContextFilter())
logger= logging.getLogger(__name__)
logger.addHandler(handler)
logger.error("Hi1")
logger.error("Hi2")
这样有效地在所有日志记录中增加了一个属性，它可以通过记录器。格式化会在日志行中包含这个属性。
请注意这会在你的应用中影响所有的日志记录，包含你可能用到以及你发送日志的库和其他的框架。它可以用来记录类似于在所有日志行里的一个独立请求 ID ，去追踪请求或者去添加额外的上下文信息。
从 Python 3.2 开始，你可以使用 setLogRecordFactory 去获得所有日志的创建记录和增加额外的信息。这个 extra attribute 和 LoggerAdapter class 或许同样是有趣的。
有时候当错误发生时，我们想要排除日志故障。创建一个缓冲的处理器，来记录当错误发生时的最新故障信息是一种可行的办法。下面的代码是个非人为策划的例子：
import logging
import logging.handlers
classSmartBufferHandler(logging.handlers.MemoryHandler):
def __init__(self,num_buffered,*args,**kwargs):
kwargs["capacity"]= num_buffered+ 2# +2 one for current, one for prepop
super().__init__(*args,**kwargs)
def emit(self,record):
iflen(self.buffer)== self.capacity- 1:
self.buffer.pop(0)
super().emit(record)
handler= SmartBufferHandler(num_buffered=2,target=logging.StreamHandler(),flushLevel=logging.ERROR)
logger= logging.getLogger(__name__)
logger.setLevel("DEBUG")
logger.addHandler(handler)
logger.error("Hello1")
logger.debug("Hello2")# This line won't be logged
logger.debug("Hello3")
logger.debug("Hello4")
logger.error("Hello5")# As error will flush the buffered logs, the two last debugs will be logged
这篇关于日志记录库的灵活性和可配置性的介绍，目的在于证明它如何设计了分别的关注点的美学。它同样为任何对 logging documentation 和 how-to guide 感兴趣的人提供了一个坚实的基础。虽然这篇文章对于 Python 日志模块并不是一个综合性的知道，但是这里有一些针对于常见的问题的回答。
问：我的库发送了一个“ no logger configured” 的警告
答：从 The Hitchhiker’s Guide to Python 查阅 how to configure logging in a library
问：如果一个记录器没有层级设置会怎么样？
答：记录器的有效层级，会由它的父级递归定义。
问：我所有的日志都在本地时间，我如何记录在 UTC ？
答：格式化就是答案！你需要在你的格式化中设置 converter 属性为通用的 UTC 时间。使用 converter = time.gmtime 。
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点}