Kubernetes 稳定性保障手册 -- 日志专题-CFANZ编程社区

[](()开发阶段

[](()最佳实践

理解了日志使用者关注的重点后，开发阶段写日志时，推荐使用如下最佳实践：

使用 structured logs
不使用 format strings
使用 info 和 error 表征日志级别
info 又可细化为多个级别，0~10，信息的重要性依次降低 (也可以参考[《Kubernetes: sig-instrumentation/logging.md》](()
0：用户想要看到的信息
1：维护者关注的白盒行为信息
10：维护者调试用的信息
使用具有过滤器能力的 log lib，通过 logger 自动过滤敏感信息
参见 [《KEP: Kubernetes system components logs sanitization》](()
日志通过 stdout/stderr 输出，关闭不必要的文本日志
避免额外的磁盘占用、IO 消耗、日志清理任务的维护等

对于 golang，可以考虑使用 [klog](() 作为 logger 实现。

[](()FAQ

[](()为什么使用 structured logs？

structured logs 是一种结构化的日志格式，结构如下，其中 msg 表征通用的事件，多对的 k=v 用来具化事件：

示例：

对于开发阶段，structured logs 通过固化的结构和字段语义，协助开发者思考程序逻辑状态，有助于进一步控制程序复杂度和理解程序逻辑。

对于运行阶段，structured logs 中的 k 天然具备索引的属性，便于进行查询和分析。也可以考虑将 msg 规范化，增加事件语义，通过限制 msg 语义来增强 msg 的作用。

[](()为什么不使用 debug/warning/critical/fatal？

通过减少日志类型，降低使用和维护负担。

debug 可以融入到 info 级别。

warning/critical 对于用户和维护者都是模糊的词，对于要采取的行动通常不具备指导意义。warning/critical 和 error 类似，表征程序运行过程中出现了预期外的现象，此时程序要么自动处理，要么交由外部人工介入判断。若由程序自动处理，那么用户和维护者感知到这类现象即可，info 可以满足。若需要交由外部人工介入，那么 error 就可以满足。对于问题的严重性，可放在运行阶段，通过异常具体的信息来表征，如 ServiceUnavailable、Unauthorized 等。

fatal 是将 error 和 panic 两类逻辑封装了起来，在开发过程中可能会带来执行逻辑上的不清晰，如决定是否 panic 的逻辑需要放在最顶层逻辑中，若在顶层逻辑之下调用 fatal，可能会带来资源泄露、程序运行复杂度增加等问题。

[](()为什么不使用 format strings？

format strings 是形如如下的结构：

这种结构将 通用事件 和 具体内容 耦合在一起，不利于开发阶段降低理解程序逻辑的成本，也不便于使用阶段通过标准化的方式进行查询、分析，增加日志的使用成本。

一种改善方式：

[](()为什么要使用具有过滤器能力的 log lib？

开发过程中，可能会由于疏忽而将敏感信息输出到日志中，如密码、token 等信息。为了避免敏感信息泄露，需要加强 code review，同时也可以考虑在 logger 中配置过滤器，自动进行敏感信息的过滤，参见 [《KEP: Kubernetes system components logs sanitization》](() 。

对于 golang，可以考虑使用 [klog](() 作为 logger 实现，并配合 [Kubernetes/component-base: sanitization](() 进行使用。

[](()运行阶段

[](()最佳实践

运行阶段是对日志的使用，包括如下 4 个阶段：

采集
查询
分析
告警

由于日志服务对程序的运行以及后续的运营极为重要，建议采用托管型的日志产品来满足运行阶段对日志的使用需求，如[阿里云的 SLS 产品](()。

若在多个 region 部署集群，且集群的组件相同，在使用日志产品时，需要确保每个 region 中日志项目名称规则的一致性。以阿里云 SLS 产品为例，若需要分别收集多个 region 的日志，则 project、logstore 的名称需要在多个 region 中保持相同的规则，目的是便于通过统一的方法对不同集群的日志做查询和分析。

通常情况下，日志产品会提供上述 4 个阶段的服务，具体的使用方法可以参见对应日志产品的文档，下述针对告警做重点分析。