云原生下日志方案的架构设计

上一篇中咱们介绍了为何须要一个日志系统、为何云原生下的日志系统如此重要以及云原生下日志系统的建设难点，相信DevOps、SRE、运维等同窗看了是深有体会的。本篇文章单刀直入，会直接跟你们分享一下如何在云原生的场景下搭建一个灵活、功能强大、可靠、可扩容的日志系统。

需求驱动架构设计

技术架构，是将产品需求转变为技术实现的过程。对于全部的架构师而言，可以将产品需求分析透彻是很是基本也是很是重要的一点。不少系统刚建成没多久就要被推翻，最根本的缘由仍是没有解决好产品真正的需求。

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

有幸咱们最近几年在阿里云上实现了产品化，服务了数以万计的企业用户，包括国内各大直播类、短视频、新闻媒体、游戏等行业Top1互联网客户。产品功能从服务一个公司到服务上万家公司会有质的差异，上云促使咱们更加深刻的去思考：究竟哪些功能是日志这个平台须要去为用户去解决的，日志最核心的诉求是什么，如何去知足各行各业、各类不一样业务角色的需求...

需求分解与功能设计

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

1. 支持各类日志格式、数据源的采集，包括非K8s
2. 可以快速的查找/定位问题日志
3. 可以将各类格式的半结构化/非结构化日志格式化，并支持快速的统计分析、可视化
4. 支持经过日志进行实时计算并得到一些业务指标，并支持基于业务指标实时的告警（其实本质就是APM）
5. 支持对于超大规模的日志进行各类维度的关联分析，可接受必定时间的延迟
6. 可以便捷的对接各类外部系统或支持自定义的获取数据，例如对接第三方审计系统
7. 可以基于日志以及相关的时序信息，实现智能的告警、预测、根因分析等，并可以支持自定义的离线训练方式以得到更好的效果

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

1. 全方位日志采集，支持DaemonSet、Sidecar各类采集方式以应对不一样的采集需求，同时支持Web、移动端、IoT、物理机/虚拟机各类数据源的采集；
2. 日志实时通道，这个是为了对接上下游所必备的功能，保证日志可以被多种系统所便捷的使用；
3. 数据清洗（ETL: Extract，Transform，Load），对各类格式的日志进行清洗，支持过滤、富化、转换、补漏、分裂、聚合等；
4. 日志展示与搜索，这是全部日志平台必须具有的功能，可以根据关键词快速的定位到日志并查看日志上下文，看似简单的功能却最难作好；
5. 实时分析，搜索只能完成一些定位到问题，而分析统计功能能够帮助快速分析问题的根因，同时能够用于快速的计算一些业务指标；
6. 流计算，一般咱们都会使用流计算框架（Flink、Storm、Spark Stream等）来计算一些实时的指标或对数据进行一些自定义的清洗等；
7. 离线分析，运营、安全相关的需求都须要对大量的历史日志进行各类维度的关联计算，目前只有T+1的离线分析引擎可以完成；
8. 机器学习框架，可以便捷、快速的将历史的日志对接到机器学习框架进行离线训练，并将训练后的结果加载到线上实时的算法库中。

开源方案设计

借助于强大的开源社区，咱们能够很容易基于开源软件的组合来实现这样一套日志平台，上图是一个很是典型的以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%，因此不能撤，撤了高峰顶不住，这时候只能搞搞削峰填谷，又是一堆工做量。

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

• 好比面对双十一的流量，市面上全部的开源软件都没法知足咱们那么大流量的需求。
• 面对阿里内部上万个业务应用，几千名工程师同时使用，并发和多租户隔离咱们必需要作到极致。
• 面对很是多核心的订单、交易等场景，整个链路的稳定性必需要求3个9甚至4个9的可用性。
• 天天如此大的数据量，对于成本的优化显得极为重要，10%的成本优化带来的收益可能就有上亿。

阿里K8s日志方案

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

1. 使用咱们自研的日志采集Agent Logtail实现K8s全方位的数据采集，目前Logtail在集团内有数百万的全量部署，性能、稳定性通过屡次双十一金融级考验。
2. 化繁为简，数据队列、清洗加工、实时检索、实时分析、AI算法等原生集成，而不是基于各类开源软件搭积木的形式实，大大下降了数据链路长度，链路长度的下降也意味着出错可能性的减小。
3. 队列、清洗加工、检索、分析、AI引擎等所有针对日志场景深度定制优化，知足大吞吐、动态扩容、亿级日志秒级可查、低成本、高可用性等需求。
4. 对于流式计算、离线分析场景这种通用需求，不管是开源仍是阿里内部都有很是成熟的产品，咱们经过无缝对接的方式来支持，目前日志服务支持了数十种下游的开源、云上产品的对接。

这套系统目前支撑了整个阿里集团、蚂蚁集团、云上上万家企业的日志分析，天天写入的数据量16PB+，开发、运维这样一套系统问题和挑战很是多，这里就再也不展开，有兴趣的同窗能够参考咱们团队的技术分享：阿里10PB/天日志系统设计和实现。

总结

本篇主要从架构层面去介绍如何搭建一套K8s的日志分析平台，包括开源方案以及咱们阿里自研的一套方案。然而实际这套系统落地到生产环境并有效运行还有不少工做要作：

1. K8s上以什么样的姿式来打日志？
2. K8s上的日志采集方案选择，DaemonSet or Sidecar？
3. 日志方案如何与CICD去集成？
4. 微服务下各个应用的日志存储如何划分？
5. 如何基于K8s系统的日志去作K8s监控？
6. 如何去监控日志平台的可靠性？
7. 如何去对多个微服务/组件去作自动的巡检？
8. 如何自动的监控多个站点并实现流量异常时的快速定位？

后续文章咱们会一步一步来和你们分享如何把这套系统落地，敬请期待。

---

本文做者：元乙

阅读原文

本文为云栖社区原创内容，未经容许不得转载。