云本地日志方案的架构设计

在前一篇文章中，我们介绍了为什么需要日志系统，为什么云本地日志系统如此重要，以及构建云本地日志系统的困难。我相信来自SRE德文郡的学生，操作和维护等。有深刻的理解。本文开门见山，将直接与您分享如何在基于云的场景下构建灵活、强大、可靠和可扩展的日志系统。

需求驱动架构设计

技术架构是将产品需求转化为技术实现的过程。对于所有建筑师来说，能够彻底分析产品需求是非常基本和重要的。许多系统在建立后不久就会被推翻，但最根本的原因是对产品的真正需求没有得到解决。

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

幸运的是，近年来，我们已经实现了阿里云的产品转型，服务于成千上万的企业用户，包括直播、短视频、新闻媒体、游戏等国内主要行业的前1名互联网用户。从服务一家公司到服务成千上万家公司，产品功能将会有质的差异。云促使我们更深入地思考日志平台需要为用户解决哪些功能，日志的核心需求是什么，以及如何满足各行各业和不同业务角色的需求。...

需求分解和功能设计

在前一节中，我们分析了公司中不同角色对日志的相关要求，并总结了以下几点:

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

为了满足上述功能要求，日志平台上必要的功能模块包括:

全方位日志采集，支持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等常用的可视化组件。

为什么我们选择自己研究

开源软件的结合是一个非常有效的解决方案。由于强大的开源社区和大型用户社区的经验，我们可以快速构建这样一个系统并满足我们的大部分需求。

当我们部署这个系统时，我们可以从容器中收集日志，在弹性搜索中检查它们，在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%的成本优化带来的收益可能就有上亿。

阿里克8S测井方案

针对上述一些问题，我们在多年后开发并完善了这样一个K8s测井方案:

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

该系统目前支持对整个阿里集团、蚂蚁集团和云中数万家企业的日志分析。每天写入的数据量为16PB。在开发、操作和维护这样一个系统方面存在许多问题和挑战。它不会在这里启动。感兴趣的学生可以参考我们团队的技术共享:阿里10PB/日日志系统的设计与实现。

[/s2/][概要/S2/]

本文主要介绍了如何从架构层面构建K8s日志分析平台，包括开源方案和阿里开发的方案。然而，要使实际系统在生产环境中着陆并有效运行，仍有许多工作要做:

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

在接下来的文章中，我们将逐步与您分享如何实现这个系统。请期待它。

作者:袁遗

这篇文章是云起社区的原始内容，未经许可不得转载。