首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

如何定义日志消息的级别?详解日志的5个级别-2

如何定义日志消息的级别?详解日志的5个级别-2

Debug

如果你能读懂这个级别的日志,那么你离程序已经很近了。

这就是为什么你需要保存日志文件,在修复 bug 时需要这些日志。这是开发人员最关心的内容。

在转储程序运行流程和其他技术问题时,应该使用 Debug 级别的日志。除非日志太多了(在这种情况下使用 Trace 级别更合适)或者更适合使用更高级别的日志,否则 Debug 日志是非常值得保留的,毕竟是你自己在代码中记录这些日志的。如果和其他的 Debug 或更高级别的消息重叠,而且没有包含更多的信息,那么可以考虑将其删除。

风格:可以很容易就忽略的风格。我使用浅灰色或米黄色文本,也就是我的终端的默认文本颜色。

例子:

    从"/etc/octarine/octarine.conf"读取配置
    使用"/home/aib/.octarinerc"覆盖配置
    分析完成,创建图…
    作为”user”连接到服务器:4242
    发送两条消息
    渲染时故障:
    Foo 0.990 秒
    Bar 42.009 秒

Trace

这些技术细节可能与程序不是很相干,除非你正好需要它们。

Trace 的信息是更加具体的调试信息,你可能并不想看到它(除非你向保存日志的人卖硬盘的时候需要)。它会包含比如说调用了什么函数(函数名),或是和客户端交换了什么网络包等内容。它善于找到一些低级错误,但通常你可以在调试消息中缩小范围,找到问题。

大多数 Trace 消息包含了你已经知道的信息(Debug 消息中说了是“登录”,所以这肯定是登录相关的数据包),所以可能对你不是很有用,除非你的假设是错误的。(”它会不会是登出消息?!“、”这里应该调用 foo。为什么 foo 的 Trace 信息没有打印出来呢?”)

风格:使用比 Debug 消息更加不显眼的风格。我使用深灰色,通常用来表示禁用的颜色。

例子:

    调用参数 ("baz", "bar", 42) 函数”foo”
    ->GET / HTTP/1.1\nHost: localhost\n\n
    收到: <?xml version="1.0" encoding="UTF-8" ?>\n\n [...]

Fatal

发生了一个致命错误,我们要退出了。祝你好运!

它应该比 Error 更严重,但使用它的频率比 Trace 还少,所以我把它放在文章的最后。顾名思义,致命错误表示这种情况的发生将导致程序无法继续运行。因此,给它们专门设置一个级别没什么意义。但是致命的错误也可能是常见和可恢复的(比如重启就能解决),因此仍然值得一提。

风格:如果你想不出其他样式的话,可以选择比 Error 更显眼的风格。我使用紫色文本,从远处看的话和 Error 的红色文本相近,但近看就不一样。

例子:

    内存不足
    无法分配 65536 字节的磁盘空间
    许可过期,切换到免费软件模式

外部例子

任何成熟的日志记录 API 或库都应该有自己的日志级别(可能支持用户自定义)。以下是广泛使用的库,仅供参考:

    Linux 的 printk(https://en.wikipedia.org/wiki/Printk#Logging_Levels
    Python 的 logging(https://docs.python.org/library/logging.html#logging-levels
    Java 的 java.util.logging.Level(https://docs.oracle.com/javase/6 ... /logging/Level.html)或 log4j 的 org.apache.log4j.Level(https://logging.apache.org/log4j ... he/log4j/Level.html
    JavaScript 的 console.level 调用(WHATWG 或 Node.js 的 Console API 规范)
    NLog 的日志级别(https://github.com/nlog/nlog/wiki/Log-levels
返回列表