Viktor Talashuk@Unsplash良好的日志是运维、开发人员排查问题的好工具,本文建议定义JSON格式的结构化日志格式,从而有效优化人工以及机器排查日志的效能,并能方便创建机器索引。原文: The Art of Logging
从历史上看,日志对于诊断应用程序和基础设施性能非常重要,被广泛应用于业务仪表板的可视化和性能分析。
对日志文件中的数据进行结构化,以便能够有效提取、操作和分析数据(除了便于人类理解,也便于机器分析)的重要性正在迅速上升。此外,微服务的兴起也带来了另一个挑战,即怎样在整个系统中跟踪请求的传播。
本文将介绍便于人和机器解析、理解的日志结构的最佳格式,特别是跟用户登录有关的关键信息及数据结构的建议,并将尝试提供一些重要的注意事项。
尽管日志最初是由机器来解析、处理和存储的,但现在正越来越多的由人类来读取、理解和诊断。日志是我们调查凶杀现场的最佳指标,而凶手正是我们的死敌: Bug!
Elsa Ventur@Unsplash没什么比试图理解冗长而且非结构化的日志线中丢失的信息更令人沮丧和耗时的了。日志必须有有意义,并且人们应该可以很容易理解和深入挖掘与他们有关的内容。
66.249.65.159 - - [06/Nov/2014:19:10:38 +0000] "GET /news/53f8d72920ba2744fe873ebc.html HTTP/1.1" 404 177 "-" "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.16)"
尽管我们已经习惯了默认的Nginx格式,但上面的示例仍然很难阅读和处理。例如,这是为了再现生产bug而提取的巨大日志文件的一部分,很难理解其背后含义是什么。
JSON相对于其他数据交换格式(如XML)的优势非常明显,这是一种在数组中有序嵌套的键值对的简单语法,对人类来说很容易读、写和理解。
那么,用JSON编写的日志消息是什么样子的呢?以下是与之前相同的JSON格式的Nginx web服务器日志示例:
{
"time": "06/May/2022:19:10:38 +0100",
"remote_ip": "66.249.65.159",
"remote_user": "-",
"request": "GET /news/53f8d72920ba2744fe873ebc.html HTTP/1.1",
"response": 404,
"bytes": 177,
"referrer": "-",
"agent": "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.16)"
}
再次考虑上面的日志线示例:
66.249.65.159 - - [06/Nov/2014:19:10:38 +0000] "GET /news/53f8d72920ba2744fe873ebc.html HTTP/1.1" 404 177 "-" "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.16)"
为了理解,我们需要:
不幸的是,这种逻辑很脆弱,如果日志格式发生了更改(比如开发人员添加了一个新字段或更改了字段顺序),那么解析器就会崩溃,相信任何人都有面对或经历类似问题的时候。
而这就是像JSON这样的结构化格式可以提供帮助的地方。键值对使提取特定值和跨数据集筛选和搜索变得容易,如果添加了新的键值对,解析日志消息的软件将只是忽略那些非期望的键,而不会完全失效。
Alex Knight@Unsplash在机器上使用JSON日志的好处是:
通常,我们可以在日志解析系统(ELK、newRelic、Datadog等)中聚合JSON数据,从而为我们提供强大的报告、搜索和对数据的洞察能力。这些工具使索引某些字段变得更容易,从而解决在微服务环境下跟踪请求的问题。
这里列举了应该包含在日志中的信息列表,有些元素是可选的,字段名前面的(o)表示可选字段。
message
: 用于描述情况的人类可读的信息,在过滤时易于阅读,以获得对内容的概述。 level
: 优先级级别的数值表示(下一节将详细介绍),对于将消息按不同优先级排序或生成包含系统概述的仪表板非常有用。 level_name
: 优先级级别的字符串表示(更多细节将在下一节中介绍)。 datetime_iso
: iso8601格式的日期,因为我们需要将时间与其他事件相关联,因此是必填项。尽管可以使用服务器的日期-时间,但可能会产生误导,因为服务器的时间可能并不一致,甚至可能位于不同的时区。 correlation_id
: 这是微服务环境的一个重要字段,我们将基于解析后的消息/请求的correlation id来跟踪服务之间整个链路的请求。 hostname
: 用于确定是哪台机器生成了此日志,建议在微服务环境中使用。当服务器日志已经从docker的服务名映射到原始主机时,可能是多余的。 build_id
: 记录信息的软件版本,可以帮助跟踪不兼容问题,特别是那些在服务器端软件部署期间发生的问题。 application
: 用于识别哪个设备或应用程序生成了此日志。 owner_id
: 报告用户id或API key id(如果有的话),可以追踪用户执行了哪些步骤来再现他的操作。 tenant_id
: 报告可用的租户id,对于多租户系统非常有用。 tags
: 可以是一个元素数组,包含关于请求的元信息,如类型、使用的协议等。 stacktrace:
: 有stack trace时以字符串格式显示stack trace。 exception:
: 有异常消息时显示异常消息。 日志级别 | 日志码 | 描述 |
---|---|---|
Debug | 100 | 详细的调试信息。 |
Info | 200 | 感兴趣的事件。例如: 用户登录或SQL日志。 |
Notice | 250 | 正常但重要的事件。 |
Warning | 300 | 不是错误的异常事件。示例: 使用已弃用的API; API使用不当。 |
Error | 400 | 不需要立即处理的运行时错误,但通常应该记录和监控。 |
Critical | 500 | 严重事件。示例: 应用组件不可用; 意想不到的异常。 |
Alert | 550 | 必须立即采取行动。例如: 整个网站瘫痪。应该会触发SMS告警。 |
Emergency | 600 | 紧急情况: 系统不可用。 |
那么,用JSON编写的日志消息是什么样的呢?
以下是示例建议的日志概念格式:
使用carbon生成的示例消息观察
owner_id
、 tenant_id
、 correlation_id
、 level
、 level_name
和 application
。 correlation_id
,如果这个值不存在,应该生成一个新值并将其传递给下一个服务。API网关(如果有的话)应该始终关注该字段是否存在、是否需要生成。 最佳实践
最后
你好,我是俞凡,在Motorola做过研发,现在在Mavenir做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。
微信公众号:DeepNoMind
本文由 mdnice 多平台发布