一文看懂 K8s 日志系统设计和实践（一文看懂中行原油宝事件）

一文看懂 K8s 日志系统设计和实践（一文看懂中行原油宝事件）

导读：上一篇文章《6 个 K8s 日志系统建设中的典型问题，你遇到过几个？》中我们介绍了为什么需要一个日志系统、为什么云原生下的日志系统如此重要以及云原生背景下日志系统的建设难点，相信 DevOps、SRE、运维等同学看了之后深有体会。本篇文章单刀直入，会直接跟大家分享一下如何在云原生的场景下搭建一个灵活、功能强大、可靠、可扩容的日志系统。

需求驱动架构设计

技术架构，是将产品需求转变为技术实现的过程。对于所有的架构师而言，能够将产品需求分析透彻是非常基本也是非常重要的一点。很多系统刚建成没多久就要被推翻，最根本的原因还是没有解决好产品真正的需求。

我所在的日志服务团队在日志这块有近 10 年的经验，几乎服务阿里巴巴内部所有的团队，涉及电商、支付、物流、云计算、游戏、即时通讯、IoT 等领域，多年来，产品功能的优化和迭代都是基于各个团队的日志需求变化。

最近几年，我们有幸在阿里云上实现了产品化，服务了数以万计的企业用户，包括国内各大直播类、短视频、新闻媒体、游戏等行业 Top1 互联网客户。

产品功能从服务一个公司到服务上万家公司会有质的差别，上云促使我们更加深入地思考：究竟哪些功能是日志这个平台需要去为用户去解决的？日志最核心的诉求是什么？如何去满足各行各业、各种不同业务角色的需求......

需求分解与功能设计

上一节中我们分析了公司内各个不同角色对于日志的相关需求，总结起来有以下几点：

为满足上述功能需求，日志平台上必须具备的功能模块有：

全方位日志采集。支持 DaemonSet、Sidecar 各种采集方式以应对不同的采集需求，同时支持 Web、移动端、IoT 及物理机/虚拟机各种数据源的采集；

日志实时通道。这个是为了对接上下游所必备的功能，保证日志能够被多种系统便捷地使用；

数据清洗（ETL: Extract，Transform，Load）。对各种格式的日志进行清洗，支持过滤、富化、转换、补漏、分裂、聚合等；

日志展现与搜索。这是所有日志平台必须具备的功能，能够根据关键词快速地定位到日志并查看日志上下文，看似简单的功能却最难做好；

实时分析。搜索只能完成一些定位到问题，而分析统计功能可以帮助快速分析问题的根因，同时可以用于快速的计算一些业务指标；

流计算。通常我们都会使用流计算框架（Flink、Storm、Spark Stream 等）来计算一些实时的指标或对数据进行一些自定义的清洗等；

离线分析。运营、安全相关的需求都需要对大量的历史日志进行各种维度的关联计算，目前只有 T+1 的离线分析引擎能够完成；

机器学习框架。能够便捷、快速地将历史的日志对接到机器学习框架进行离线训练，并将训练后的结果加载到线上实时的算法库中。

开源方案设计

借助于强大的开源社区，我们可以很容易基于开源软件的组合来实现这样一套日志平台，上图是一个非常典型的以 ELK 为核心的日志平台方案：

利用 FileBeats、Fluentd 等采集 Agent 实现容器上的数据统一收集；

为了提供更加丰富的上下游以及缓冲能力，可以使用 kafka 作为数据采集的接收端；

采集到的原始数据还需要进一步的清洗，可以使用 Logstash 或者 Flink 订阅 Kafka 中的数据，清洗完毕后再写入 kafka 中；

清洗后的数据可以对接 ElasticSearch 来做实时的查询检索、对接 Flink 来计算实时的指标和告警、对接 Hadoop 来做离线的数据分析、对接 TensorFlow 来做离线模型训练；

数据的可视化可以使用 grafana、kibana 等常用的可视化组件。

为什么我们选择自研

采用开源软件的组合是非常高效的方案，得益于强大的开源社区以及庞大用户群体的经验积累，我们可以很快搭建出这样一套系统，并且可以满足我们绝大部分的需求。

当我们把这套系统部署好，能够把日志从容器上采集上来、elasticsearch 上能够查到、Hadoop 上能够成功执行 SQL、Grafana 上能看到图、告警短信能收到......完成上述流程打通后，加班可能只需要花费几天的时间，当系统跑通的时候，这时终于可以长舒一口气，躺在办公椅上放松放松。

然而理想很丰满现实很骨感，当我们预发通了，测试完了上到生产，开始接入第一个应用，逐渐更多的应用接入，越来越多的人开始使用......这时候很多问题都可能暴露出来：

随着业务量的上涨，日志量也越来越大，Kakfa 和 ES 要不断扩容，同时同步 Kafka 到 ES 的 Connector 也需要扩容，最烦的是采集 Agent，每台机器上部署的 DaemonSet Fluentd 根本没办法扩容，到了单 Agent 瓶颈就没办法了，只能换 Sidecar。换 Sidecar 工作量大不说，还会带来一系列其他的问题，比如怎么和 CICD 系统集成、资源消耗、配置规划、stdout 采集不支持等等；

从刚开始上的边缘业务，慢慢更多的核心业务接入，对于日志的可靠性要求越来越高，经常有研发反应从 ES 上查不到数据、运营说统计出来的报表不准、安全说拿到的数据不是实时的......每次问题的排查都要经过采集、队列、清洗、传输等等非常多的路径，排查代价非常高。同时还要为日志系统搭建一套监控方案，能够及时发现问题，而且这套方案还不能基于日志系统、不能自依赖；

当越来越多的开发开始用日志平台调查问题时，经常会出现因为某 1-2 个人提交一个大的查询，导致系统整体负载上升，其他人的查询都会被 Block，甚至出现 Full GC 等情况。这时候一些大能力的公司会对 ES 进行改造，来支持多租户隔离；或者为不同的业务部门搭建不同的 ES 集群，最后又要运维多个 ES 集群，工作量还是很大；

当投入了很多人力，终于能够把日志平台维持日常使用，这时候公司财务找过来了，说我们用了非常多的机器，成本太大。于是我们又要开始优化成本，但是思来想去就是需要这么多台机器，每天大部分的机器水位都在 20%-30%，但是高峰的水位可能到 70%，所以不能撤，撤了高峰顶不住，这时候只能搞搞削峰填谷，又是一堆工作量。

上述这些是一家中等规模的互联网企业在日志平台建设中经常会遇到的问题，在阿里巴巴这些问题会放大很多倍：

比如面对双 11 的流量，市面上所有的开源软件都无法满足我们那么大流量的需求；

面对阿里巴巴内部上万个业务应用，几千名工程师同时使用，并发和多租户隔离我们必须要做到极致；

面对非常多核心的订单、交易等场景，整个链路的稳定性必须要求 3 个 9 甚至 4 个 9 的可用性；

每天如此大的数据量，对于成本的优化显得极为重要，10% 的成本优化带来的收益可能就有上亿。

阿里巴巴 K8s 日志方案

针对上述的一些问题，我们经过多年的时间，开发并打磨出这样一套 K8s 日志方案：

使用我们自研的日志采集 Agent Logtail 实现 K8s 全方位的数据采集，目前 Logtail 在集团内有数百万的全量部署，性能、稳定性经过多次双 11 金融级考验；

化繁为简，数据队列、清洗加工、实时检索、实时分析、AI 算法等原生集成，而不是基于各种开源软件搭积木的形式实，大大降低了数据链路长度，链路长度的降低也意味着出错可能性的减少；

队列、清洗加工、检索、分析、AI 引擎等全部针对日志场景深度定制优化，满足大吞吐、动态扩容、亿级日志秒级可查、低成本、高可用性等需求；

对于流式计算、离线分析场景这种通用需求，无论是开源还是阿里巴巴内部都有非常成熟的产品，我们通过无缝对接的方式来支持，目前日志服务支持了数十种下游的开源、云上产品的对接。

这套系统目前支撑了整个阿里巴巴集团、蚂蚁集团、云上上万家企业的日志分析，每天写入的数据量 16PB+，开发、运维这样一套系统问题和挑战非常多，这里就不再展开。

总结

本篇文章主要从架构层面去介绍如何搭建一套 K8s 的日志分析平台，包括开源方案以及我们阿里巴巴自研的一套方案。

实际上这套系统落地到生产环境并有效运行仍有很多工作要做：

K8s 上以什么样的姿势来打日志？

K8s 上的日志采集方案选择，DaemonSet or Sidecar？

日志方案如何与 CICD 去集成？

微服务下各个应用的日志存储如何划分？

如何基于 K8s 系统的日志去做 K8s 监控？

如何去监控日志平台的可靠性？

如何去对多个微服务/组件去做自动的巡检？

如何自动的监控多个站点并实现流量异常时的快速定位？

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。