作者 | 元乙  阿里云存储服务技术专家

导读：近年来，越来越多的同学咨询如何为 Kubernetes 构建一个日志系统，或者是来求助在此过程中遇到一系列问题如何解决，授人以鱼不如授人以渔，于是作者想把这些年积累的经验以文章的形式发出来，让看到文章的同学少走弯路。K8s 日志系列文章内容偏向落地实操以及经验分享，且内容会随着技术的迭代而不定期更新，本文为该系列文章的第 3 篇。

第一篇： 《6 个 K8s 日志系统建设中的典型问题，你遇到过几个？》

第二篇： 《一文看懂 K8s 日志系统设计和实践》

前言

在上一篇文章 《一文看懂 K8s 日志系统设计和实践》中，主要和大家介绍从全局维度考虑如何去构建 K8s 中的日志系统，本文我们将从实践角度出发来一步步构建 K8s 中的日志监控体系。

构建日志系统的第一步是如何去产生这些日志，而这也往往是最繁杂最困难的一步。

2009 年阿里云春节上班第一天，在北京一间连暖气都没有的办公室里，一帮工程师一边口呼白气，一边敲出了“飞天”的第一行代码。“飞天”作为阿里云的核心技术平台，其英文名 Apsara——来自吴哥王朝的阿仆萨罗飞天仙女的名字。

阿里云飞天系统的第一行代码就是为了编写一个日志系统，而现在 apsara logging 的日志库应用在飞天所有的系统中，包括盘古、女娲、伏羲、洛神...

Kubernetes 中日志重要性

通常日志最基础的作用是记录程序的运行轨迹，在此之上会衍生出非常多的功能，例如线上监控、告警、运营分析、安全分析等等（详情可以参见第一篇文章 《6 个 K8s 日志系统建设中的典型问题，你遇到过几个？》，这些功能反过来也对日志具备一定的要求，我们需要尽可能的将日志规范化，以减少收集、解析、分析的代价。

在 Kubernetes 中，环境的动态性很强，日志基本上都是易失的，因此需要实时将日志采集到中心的存储中，为了配合日志采集，对于日志的输出、采集会有更多的要求。

下述我们列举了 Kubernetes 中，日志输出的常见注意事项（其中标记 (*)的是 Kubernetes 中特有的项目）：

1. 如何选择日志等级
2. 日志内容规范
3. 合理控制日志输出量
4. 选择多种日志输出目标
5. 控制日志性能消耗
6. 如何选择日志库
7. 日志形态选择（*）
8. 日志是否落盘以及落盘介质（*）
9. 如何保证日志存储周期（*）

如何选择日志等级

日志等级是用来区分日志对应事件严重程度的说明，这是所有日志中必须具备的一个选项。通常日志会分为 6 个不同的等级：

• FATAL（致命）：用来输出非常严重或预期中不会发生的错误，遇到此种错误应当立即报警并人工介入处理；
• ERROR （错误）：非预期中的错误，此种错误可能导致部分系统异常但不会影响核心业务和系统正常运行；
• WARN（警告）：潜在的危险或值得关注的信息（比较核心的路径）；
• INFO（信息）：应用执行过程中的详细信息，一般通过该信息可以看到每个请求的主要执行过程；
• DEBUG（调试）：用于线下调试的日志信息，用于分析应用执行逻辑，线上应用切勿开启；
• TRACE（跟踪）：输出最细致的运行轨迹，可能包含涉及的数据内容。

作为程序员，一定要合理设置日志等级，个人在开发过程中总结了以下几点经验：

1. FATAL 类型日志一定是非常严重的错误、需要人工处理的场景打印的；
2. ERROR 和 WARNING 的区别很多程序员难以选择，可以从告警角度考虑：ERROR 为一般需要告警，WARNING 为不需要；
3. 日志等级一方面是为了能够表示日志的严重程度，另一方面也是为了控制应用程序的日志输出量，通常线上只能打开 INFO 或 WARN 的日志；
4. DEBUG 日志可以多打，方便分析问题；
5. 所有用户请求日志，必须记录；
6. 对于不确定的外部系统调用，日志需尽可能覆盖周全；
7. 程序中的日志库需要具备运行期间变更日志等级的能力，方便在遇到问题需要分析时临时更改日志等级；
8. 通常在新功能上线，涉及的日志可适当提升一个等级，方便实时观察和监控，待稳定后再调整到正常（记得加上注释，方便改回来）。

日志内容规范

通常在没有约束的情况下，程序员的发挥天马行空，各种日志内容都会出现，这些只有开发自己才能看懂的日志很难进行分析和告警。因此我们需要一个日志顶向下的规范来约束项目中的开发人员，让所有的日志看起来是一个人打印的而且是易于分析的。

日志的字段

日志中通常必备的字段有：Time、Level、Location。对于特定模块/流程/业务，还需要有一些 Common 的字段，例如：

1. 如果使用 Trace 系统，可以把 TraceID 附加到日志中；
2. 固定的流程需要附加对应的字段，例如订单的生命周期中，一定要有订单号、用户 ID 等信息，这些信息可以通过 Context 附加到对应流程的日志实例上；
3. HTTP 请求需要记录：URL、Method、Status、Latency、Inflow、OutFlow、ClientIP、UserAgent 等，详情可以参考  Nginx日志格式；
4. 如果多个模块的日志都打印到同一个流/文件中，必须有字段标识模块名。

日志的字段规约最好由运维平台/中间件平台自顶向下推动，约束每个模块/流程的程序员按照规定打印日志。

日志表现形式

通常我们建议使用 KeyValue 对形式的日志格式，比如我们阿里的飞天日志库采用的就是这种形式：

[2019-12-30 21:45:30.611992] [WARNING] [958] [block_writer.cpp:671] path:pangu://localcluster/index/3/prom/7/1577711464522767696_0_1577711517 min_time:1577712000000000 max_time:1577715600000000 normal_count:27595 config:prom start_line:57315569 end_line:57343195 latency(ms):42 type:AddBlock

KeyValue 对的日志可以完全自解析且易于理解，同时便于日志采集时自动解析。

另外推荐的是 JSON 日志格式，支持以 JSON 格式输出的日志库很多，而且大部分的日志采集 Agent 都支持 JSON 格式的日志收集。

{"addr":"tcp://0.0.0.0:10010","caller":"main.go:98","err":"listen tcp: address tcp://0.0.0.0:10010: too many colons in address","level":"error","msg":"Failed to listen","ts":"2019-03-08T10:02:47.469421Z"}

注意：绝大部分场景不建议使用非可读的日志格式（例如 ProtoBuf、Binlog 等）。

单条日志换行问题

非必要情况下，尽量不要一条日志输出成多行，这种对于采集、解析和索引的代价都比较高。

合理控制日志输出量

日志的输出量直接影响到磁盘使用以及对于应用的性能消耗，日志太多不利于查看、采集、分析；日志太少不利于监控，同时在出现问题的时候没办法调查。

一般线上应用需合理控制日志的数据量：

1. 服务入口的请求和响应日志没有特殊原因都要输出并采集，采集的字段可以根据需求调整；
2. 错误日志一般都要打印，如果太多，可以使用采样方式打印；
3. 减少无效日志输出，尤其是循环中打印日志的情况需尽量减少；
4. 请求型的日志（比如 Ingress、Nginx 访问日志）一般不超过 5MB/s（500 字节每条，不超过 1W/s），应用程序日志不超过 200KB/s（2KB 每条，不超过 100 条/s）。

选择多种日志输出目标

建议一个应用不同类型的日志输出到不同的目标（文件），这样便于分类采集、查看和监控。例如：

1. 访问日志单独放到一个文件，如果域名不多，可以按照一个域名一个文件的形式；
2. 错误类的日志单独放一个文件，单独配置监控告警；
3. 调用外部系统的日志单独放一个文件，便于后续对账、审计；
4. 中间件通常都由统一的平台提供，日志一般单独打印一个文件。

控制日志性能消耗

日志作为业务系统的辅助模块，一定不能影响到业务正常的工作，因此日志模块的性能消耗需要单独额外注意，一般在选择/开发日志库时，需要对日志库进行性能测试，确保正常情况下日志的性能消耗不超过整体 CPU 占用的 5%。

注意：一定要确保日志打印是异步的，不能阻塞业务系统运行。

如何选择日志库

开源的日志库非常多，基本每个语言都有数十种，选择一个符合公司/业务需求的日志库需要精挑细选，有一个简单的指导原则是尽可能使用比较流行的日志库的稳定版本，入坑的几率要小一点。例如：

1. Java 使用 Log4J、LogBack；
2. Golang 使用 go-kit；
3. Python 默认集成的日志库大部分场景都够用，建议阅读一下  CookBook；
4. C++ 推荐使用 spdlog，高性能、跨平台。

日志形态选择

在虚拟机/物理机的场景中，绝大部分应用都以文件的形式输出日志（只有一些系统应用输出到 syslog/journal）；而在容器场景中，多了一个标准输出的方式，应用把日志打到 stdout 或 stderr 上，日志会自动进入到 docker 的日志模块，可以通过 docker logs 或 kubectl logs 直接查看。

容器的标准输出只适应于比较单一的应用，例如 K8s 中的一些系统组件，线上的服务类应用通常都会涉及到多个层级（中间件）、和各种服务交互，一般日志都会分为好几类，如果全部打印到容器的标准输出，很难区分处理。

同时容器标准输出对于 DockerEngine 的性能消耗特别大，实测 10W/s 的日志量会额外占用 DockerEngine 1 个核心的 CPU（单核 100%）。

日志是否落盘以及落盘介质

在 Kubernetes 中，还可以将日志库直接对接日志系统，日志打印的时候不落盘而直接传输到日志系统后端。这种使用方式免去了日志落盘、Agent 采集的过程，整体性能会高很多。

这种方式我们一般只建议日志量极大的场景使用，普通情况下还是直接落盘，相比直接发送到后端的方式，落盘增加了一层文件缓存，在网络失败的情况下还能缓存一定的数据，在日志系统不可用的情况下我们的研发运维同学可以直接查看文件的日志，提高整体的可靠性。

Kubernetes 提供了多种存储方式，一般在云上，都会提供本地存储、远程文件存储、对象存储等方式。由于日志写入的 QPS 很高，和应用也直接相关，如果使用远程类型的存储，会额外多 2-3 次网络通信开销。我们一般建议使用本地存储的方式，可以使用 HostVolume 或者 EmptyDir 的方式，这样对于写入和采集的性能影响会尽可能的小。

如何保证日志存储周期

相比传统虚拟机/物理机的场景，Kubernetes 对于节点、应用层提供了强大的调度、容错、缩/扩容能力，我们通过 Kubernetes 很容易就能让应用获得高可靠运行、极致弹性。这些优势带来的一个现象是：节点动态创建/删除、容器动态创建/删除，这样日志也会随时销毁，没办法保证日志的存储周期能够满足 DevOps、审计等相关的需求。

在动态的环境下实现日志的长期存储只能通过中心化的日志存储来实现，通过实时的日志采集方式，将各个节点、各个容器的日志在秒级内采集到日志中心系统上，即使节点/容器挂掉也能够通过日志还原当时的现场。

总结

日志输出是日志系统建设中非常重要的环节，公司/产品线一定要遵循一个统一的日志规范，这样才能保证后续日志采集、分析、监控、可视化能够顺利进行。

后面的章节会介绍如何为 Kubernetes 规划日志采集和存储的最佳实践，敬请期待。

“ 阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术圈。”