OpenStack 实现技术分解 (6) 通用库 — oslo_log

目录

  • 目录
  • 前文列表
  • 扩展阅读
  • 日志级别
  • oslolog
    • 初始化设置 DEMO
    • oslolog 的相关配置项
    • oslolog 的日志级别
    • oslolog 的使用技巧
      • 推荐使用 LOGdebug 的地方
      • 推荐使用 LOGinfo 的地方
      • 推荐使用 LOGexception 的地方
      • 推荐使用 LOGerror 的地方
      • 推荐使用 LOGcretical 的地方

前文列表

OpenStack 实现技术分解 (1) 开发环境 — Devstack 部署案例详解

OpenStack 实现技术分解 (2) 虚拟机初始化工具 — Cloud-Init & metadata & userdata

OpenStack 实现技术分解 (3) 开发工具 — VIM & dotfiles

OpenStack 实现技术分解 (4) 通用技术 — TaskFlow

OpenStack 实现技术分解 (5) 应用开发 — 使用 OpenStackClients 进行二次开发

扩展阅读

Usage — oslo.log 3.21.1.dev1 documentation

oslo.log – Oslo Logging Library

日志级别

在记录日志时, 需要将日志消息关联一个级别, 系统默认提供了 6 个级别，它们分别是：

critical > error > warning > info > debug > notset

级别越高打印的日志越少，反之亦然:

  • DEBUG: 打印全级别日志( notset 等同于 debug)
  • INFO: 打印 info/warning/error/critical 级别日志
  • WARNING: 打印 warning/error/critical 级别日志
  • ERROR: 打印 error/critical 级别日志
  • CRITICAL: 打印 critical 级别

一般而言, 在程序的开发阶段会打印大量的日志, 此时的日志级别应为 DEBUG. 直到程序稳定后, 为了提高程序的执行效率, 需要打印日志应该相对减少. 根据实际情况, 可能会删减 DEBUG 级别的日志代码. 此时, 程序员更关心的是跟踪用户的动作, 例如: 用户对于核心数据的修改动作就非常有必要记录在案, 所以可以选择 INFO 及以上级别的日志, 其中最重要的信息就应该选择 CRITICAL 级别了. 需要注意的是, 异常捕获代码块(try-except)中都应该使用 ERROR/EXCEPTION(由 oslo_log 提供的异常栈级别) 级别的日志, 以便定位具体的错误原因.

oslo.log

(摘自官方文档)The oslo.log (logging) configuration library provides standardized configuration for all openstack projects. It also provides custom formatters, handlers and support for context specific logging (like resource id’s etc).

oslo.log(logging) 库为所有的 OpenStack 项目提供了标准的日志处理方式, 它还提供能自定义日志格式以及各种 handlers, 同时也支持指定上下文对象的日志, 例如: resource_id 的日志等等.

实际上 oslo_log 是基于 Python’s standard logging library 标准库的封装, 在整体使用的简易性上得到了提升.

初始化设置 DEMO

from oslo_config import cfg
from oslo_log import log as logging

LOG = logging.getLogger(__name__)
CONF = cfg.CONF
DOMAIN = "demo"

logging.register_options(CONF)
logging.setup(CONF, DOMAIN)

# Oslo Logging uses INFO as default
LOG.info("Oslo Logging")
LOG.warning("Oslo Logging")
LOG.error("Oslo Logging")

显然的, 为了充分利用 oslo_conf 的跨文件作用域特性, oslo_log 一般会与 oslo_conf 结合使用, 由 oslo_conf 为 oslo_log 提供项目的日志配置项参数值. 对于 oslo_log 而言, 配置项引入是一个非常重要且具有实践价值的设计理念.

oslo.log 的相关配置项

各个配置项的含义在注释中也作了清晰的介绍:

################
# From oslo.log
################

# If set to true, the logging level will be set to DEBUG instead of the default
# INFO level. (boolean value)
# Note: This option can be changed without restarting.
debug = true

# DEPRECATED: If set to false, the logging level will be set to WARNING instead
# of the default INFO level. (boolean value)
# This option is deprecated for removal.
# Its value may be silently ignored in the future.
#verbose = true

# The name of a logging configuration file. This file is appended to any
# existing logging configuration files. For details about logging configuration
# files, see the Python logging module documentation. Note that when logging
# configuration files are used then all logging configuration is set in the
# configuration file and other logging configuration options are ignored (for
# example, logging_context_format_string). (string value)
# Note: This option can be changed without restarting.
# Deprecated group/name - [DEFAULT]/log_config
#log_config_append = <None>

# Defines the format string for %%(asctime)s in log records. Default:
# %(default)s . This option is ignored if log_config_append is set. (string
# value)
#log_date_format = %Y-%m-%d %H:%M:%S

# (Optional) Name of log file to send logging output to. If no default is set,
# logging will go to stderr as defined by use_stderr. This option is ignored if
# log_config_append is set. (string value)
# Deprecated group/name - [DEFAULT]/logfile
#log_file = <None>

# (Optional) The base directory used for relative log_file  paths. This option
# is ignored if log_config_append is set. (string value)
# Deprecated group/name - [DEFAULT]/logdir
#log_dir = <None>

# Uses logging handler designed to watch file system. When log file is moved or
# removed this handler will open a new log file with specified path
# instantaneously. It makes sense only if log_file option is specified and
# Linux platform is used. This option is ignored if log_config_append is set.
# (boolean value)
#watch_log_file = false

# Use syslog for logging. Existing syslog format is DEPRECATED and will be
# changed later to honor RFC5424. This option is ignored if log_config_append
# is set. (boolean value)
#use_syslog = false

# Syslog facility to receive log lines. This option is ignored if
# log_config_append is set. (string value)
#syslog_log_facility = LOG_USER

# Log output to standard error. This option is ignored if log_config_append is
# set. (boolean value)
#use_stderr = true

# Format string to use for log messages with context. (string value)
#logging_context_format_string = %(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [%(request_id)s %(user_identity)s] %(instance)s%(message)s

# Format string to use for log messages when context is undefined. (string
# value)
#logging_default_format_string = %(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [-] %(instance)s%(message)s

# Additional data to append to log message when logging level for the message
# is DEBUG. (string value)
#logging_debug_format_suffix = %(funcName)s %(pathname)s:%(lineno)d

# Prefix each line of exception output with this format. (string value)
#logging_exception_prefix = %(asctime)s.%(msecs)03d %(process)d ERROR %(name)s %(instance)s

# Defines the format string for %(user_identity)s that is used in
# logging_context_format_string. (string value)
#logging_user_identity_format = %(user)s %(tenant)s %(domain)s %(user_domain)s %(project_domain)s

# List of package logging levels in logger=LEVEL pairs. This option is ignored
# if log_config_append is set. (list value)
#default_log_levels = amqp=WARN,amqplib=WARN,boto=WARN,qpid=WARN,sqlalchemy=WARN,suds=INFO,oslo.messaging=INFO,iso8601=WARN,requests.packages.urllib3.connectionpool=WARN,urllib3.connectionpool=WARN,websocket=WARN,requests.packages.urllib3.util.retry=WARN,urllib3.util.retry=WARN,keystonemiddleware=WARN,routes.middleware=WARN,stevedore=WARN,taskflow=WARN,keystoneauth=WARN,oslo.cache=INFO,dogpile.core.dogpile=INFO

# Enables or disables publication of error events. (boolean value)
#publish_errors = false

# The format for an instance that is passed with the log message. (string
# value)
#instance_format = "[instance: %(uuid)s] "

# The format for an instance UUID that is passed with the log message. (string
# value)
#instance_uuid_format = "[instance: %(uuid)s] "

# Enables or disables fatal status of deprecations. (boolean value)
#fatal_deprecations = false

对于有 Python logging 标准库使用经验的程序员而言, 应该很容易的就能体会到 oslo_log 对 logging 进行封装后带来的好处. 以往使用 logging 时需要在代码中显式定义的状态信息(e.g. 日志级别/打印格式/handler 等), 现在都能够通过 oslo_log 配置文件的配置项参数值来简化定义. 有效的避免了在程序中写出许多无谓的代码, 而且通过阅读配置文件能够更清晰的理解当前程序的日志状态.

一般来说我们需要关心的 oslo_log 配置项有以下几个:

  • debug = true: 是否将日志级别设定为 DEBUG
  • verbose = true: 将日志级别设定为 INFO(true) 还是 WARNING(false)
  • log_date_format = %Y-%m-%d %H:%M:%S: 日志的日期格式
  • log_file = <None>: 日志文件名称
  • log_dir = <None>: 日志文件路径
  • use_stderr = true: 是否让日志以 system standard error 管道输出
  • logging_context_format_string: 日志内容格式
  • default_log_levels: 相关程序的默认日志级别
  • instance_format: instance 的日志打印格式, 所谓的上下文对象日志

oslo_log 支持通过调用 logger 的 register_options() method 来实现配置项的注册:

CONF = cfg.CONF

def prepare():

    # Required step to register common, logging and generic configuration
    # variables
    logging.register_options(CONF)

在注册了配置项之后, 还可以通过调用 logger 的 setup() method 来指定该 logger 的作用域, 支持在一个程序中存在多个不同 domain 的 logger:

DOMAIN = ‘demo‘

def prepare():

    # Required setup based on configuration and domain
    logging.setup(CONF, DOMAIN)

同时, oslo_log 也支持使用 logger 的 set_defaults method 来动态修改日志级别:

    # Optional step to set new defaults if necessary for
    # * logging_context_format_string
    # * default_log_levels

    extra_log_level_defaults = [
        ‘dogpile=INFO‘,
        ‘routes=INFO‘
        ]

    logging.set_defaults(
        default_log_levels=logging.get_default_log_levels() +
        extra_log_level_defaults)

上述的 3 个 method 让程序中日志的使用变得更加灵活.

oslo.log 的日志级别

oslo.log 常用的 5 个日志级及其对应的 function:

from oslo_log import log as logging

LOG = logging.getLogger(__name__)

LOG.debug("Some key is %s", "key")

LOG.info("Create something %s start", "test")

LOG.exception("Failed to create something %(something)s as error %(err)s", {"something": "something", "err": "err"})

LOG.error("Failed to create something")

LOG.cretical("Fatal error as %s", "fatal")

oslo.log 的使用技巧

一般而言, 我会建议程序中的日志宜多不宜少, 但在上文也有提到, 大量的日志会对程序运行效率造成影响, 所以理解如何精准的在程序中的不同场景使用不同级别的日志就显得很有必要了.

推荐使用 LOG.debug 的地方

LOG.debug 一般用于对实参数据体精确度较为敏感的 function/method 语句块的首行, 让开发者能够快速的判断是否得到了预期实参. 所以这里需要打印出 module_name & function_name/method_name & 实参值.

EXAMPLE 1: REST API controller method 中接收到的 request info:

def index(self, req):
    LOG.debug("Get server list with parameter %s,", req.GET())
    ...

EXAMPLE 2: 一些通过逻辑比较复杂的流程而得到的参数

...
# 执行一次复杂的排序操作
sort_result = _complex_sort(arr)
LOG.debug("Front list %(fro)s change to %(now)s after complex_sort.", {‘fro‘: arr, ‘now‘: sort_result})
...

推荐使用 LOG.info 的地方

LOG.info 一般用于标记业务逻辑步骤, 让运维/开发人员都能够快速判断程序流到了哪一个步, 所以这里需要打印 module_name & step_description & 业务对象的唯一标示

EXAMPLE: 当执行一个所需步骤大于等于二的程序流程时, 需要打印程序流开始到结束的过程

...
LOG.info("Create server %s start.", server.id)
...
LOG.info("Prepare image for server %s.", server.id)
...
LOG.info("Prepare network for server %s", server.id)
...
LOG.info("Create server %s successful", server.id)
...

推荐使用 LOG.exception 的地方

LOG.exception/LOG.error 一般用于 try-except 异常捕获语句块, 如果捕获到的是某一个准确的异常可以使用 LOG.error, 如果捕获的是某一类异常或全部异常时可以使用 LOG.exception 来打印出异常栈.

EXAMPLE: 在暴露的 RPC API 或者 HTTP API 方法中加入 exception 级别日志

def index(self, req):
    ...
    try:
        self.server_api.get_all_servers()
    except Exception as err:
        LOG.exception("Failed to get servers as error %s", six.text_type(err))
        raise exc.HTTPInnevalError()
    ...

推荐使用 LOG.error 的地方

EXAMPLE: 同上, 但如果程序流没有再上一层的调用时, 也可以使用LOG.error, 因为已经不需要打印异常栈了.

try:
    # do something
    ...
except Exception as err:
    LOG.error("Failed to do something as error %s", six.text_type(err))
    raise

推荐使用 LOG.cretical 的地方

LOG.cretical 一般用于当错误可能会导致程序进程崩溃等极其严重的逻辑块中

try:
    # 执行一些危险操作
    ...
except Exception as err:
    LOG.cretical("Failed to do something as error %s", six.text_type(err))
    raise
时间： 2024-11-03 19:09:50

OpenStack 实现技术分解 (6) 通用库 — oslo_log的相关文章

OpenStack 实现技术分解 (5) 应用开发 — 使用 OpenStackClients 进行二次开发

目录 目录 前文列表 参考阅读 前言 OpenStackClients 使用 OpenStackClients 获取 project_client object 的 demo 调用 project_client object 实例方法实现对 project 操作的 demo 最后 前文列表 OpenStack 实现技术分解 (1) 开发环境 - Devstack 部署案例详解 OpenStack 实现技术分解 (2) 虚拟机初始化工具 - Cloud-Init & metadata & u

Google之Chromium浏览器源码学习——base公共通用库(三)

本节将介绍base公共通用库中的containers,其包含堆栈.列表.集合.以及Most Recently Used cache(最近使用缓存模板). linked_list.h:一个简单的列表类型,通过模板实现,内部采用双链表的形式,有区别于c++标准模板库的std::list<T*>,它的使用方式为:base::LinkedList<T>; 相对std::list<T*>,其优点有: 1. 删除一个元素,操作复杂度为O(1),而std::list<T*>

[C++11笔记001]修改通用库中的XDynamicArray，使它可以支持C++11的初始化列表和for循环

今天,有空翻了一下<C++Primer plus(第六版)>,看到里面有介绍新的for循环和初始化列表,但是我实现的动态数组XDynamicArray不支持这些新特性,没办法,只好进行改造了. 首先是for循环,如下面的样式 for(auto e:stList) { cout<<e<<endl; } 是于就各种google,和查找C++11的array的源代码,总结:就是提供一个标准的iterator和begin,end这两个方法,就可以了. 是于定义了一个iterat

quagga源码分析--通用库thread

quagga是开源路由器软件,提供的用户界面与思科,华为的路由器的人机接口几乎一致,非常有学习价值,尤其是开源的协议代码,简直亮瞎了我丹的小眼睛. quagga的介绍,我就不赘述了,有兴趣的可以找度娘或者去官网看看. 一.通用库thread quagga是一个纯C实现的项目. C语言的项目,就是一个个C,H文件组成,当C文件很多的时候,相信一开始每个开源爱好者都会感到很头疼吧,完全不知道这么多文件要怎么组织,怎么去阅读吧? 哈,其实呢,quagga的C文件就像一个个散落在地上的珍珠,而threa

jQuery内核详解与实践读书笔记1:原型技术分解2

上一篇已经搭建了一个非常简陋的jQuery框架雏形,如没有阅读搭建过程,请先阅读<jQuery内核详解与实践读书笔记1:原型技术分解1>初始搭建过程.接下来,完成书中介绍的剩下三个步骤: 7. 延续--功能扩展 jQuery框架是通过extend()函数来扩展功能的,extend()函数的功能实现起来也很简单,它只是吧指定对象的方法复制给jQuery对象或jQuery.prototype对象,如下示例代码就为jQuery类和原型定义了一个扩展功能的函数extend(). 1 var $ = j

Google之Chromium浏览器源码学习——base公共通用库(二)

上次提到Chromium浏览器中base公共通用库中的内存分配器allocator,其中用到了三方库tcmalloc.jemalloc:对于这两个内存分配器,个人建议,对于内存,最好是自己维护内存池:此外在windows下使用可使用其自带的内存分配方式:具体的第三方库可以参阅:http://www.360doc.com/content/13/0915/09/8363527_314549128.shtml:目前我们主要的精力尽可能在Chromium浏览器中base公共通用库的主要内容上,所以不再详

jQuery内核详解与实践读书笔记1:原型技术分解1

一直以来都有研究一下jQuery源代码的想法,但是每次看到jQuery几千行的代码,头就大了,没有一点头绪,也不知道从哪里开始.昨天去图书馆无意间发现了这本<jQuery内核详解和实践>,翻看了一下里面的内容,这正是我寻觅多时剖析jQuery源码的好书. 废话不多说,直入正题吧.第一章介绍了一下jQuery的起步和一些历史故事,没什么重要内容.这里直接进入第二章,jQuery技术解密,从这一章开始就全部是干货了.这一章主要分四部分:jQuery原型技术分解,破解jQuery选择器接口,解析jQ

jQuery原型技术分解

jQuery原型技术分解 起源----原型继承 用户过javascript的都会明白,在javascript脚本中到处都是 函数,函数可以归置代码段,把相对独立的功能封闭在一个函数包中.函数也可以实现类,这个类是面向对象编程中最基本的概念,也是最高抽象,定义一个灰就相 当于制作一个模型,然后借助这个模型复制无数的实例. 例如,下面的就可定义最初的jQuery类,类名就是jQuery,你可以把它视为一个函数,函数名是jQuery.那当然也可以把它视为一个对象,对象 名是jQuery.与其也面向对象

深入浅出Neutron ：OpenStack网络技术

<深入浅出Neutron :OpenStack网络技术>一书今天上市了,有兴趣的童鞋可以购买啦,记得好评并大力推广哦  -:) http://search.jd.com/Search?keyword=%E6%B7%B1%E5%85%A5%E6%B5%85%E5%87%BANeutron&enc=utf-8&wq=%E6%B7%B1%E5%85%A5%E6%B5%85%E5%87%BANeutron&pvid=j83yzmgi.iuouof 版权声明:本文为博主原创文章,