需求驱动架构设计技术架构是将产品需求转化为技术实现的过程。对于所有的架构师来说，能够把产品需求分析透彻是非常基础的，也是非常重要的。很多制度建成后很快就会被推翻。最根本的原因是没有解决产品的真正需求。我的日志服务团队在日志领域有近10年的经验，服务过阿里内部几乎所有的团队，涉及电商、支付、物流、云计算、游戏、即时通讯、IoT等领域。多年来，产品功能的优化和迭代都是基于各个团队对日志需求的变化。幸运的是，我们这几年已经在阿里云上实现了产品化，服务了数以万计的企业用户，包括国内主要直播、短视频、新闻媒体、游戏等行业的Top1互联网客户。从服务一家企业到服务几万家企业，在产品功能上会有质的区别。上云促使我们更深入地思考：平台需要为用户解决的日志有哪些功能，日志的核心诉求是什么？,如何满足各行各业、不同业务角色的需求……需求分解与功能设计上一节我们分析了公司中不同角色对日志的相关需求。总结如下：支持各种各种日志格式和数据源的收集，包括非K8s，可以快速查找/定位问题日志。可以格式化各种格式的半结构化/非结构化日志，支持快速统计分析和可视化。支持通过日志进行实时监控。计算获取部分业务指标，支持基于业务指标的实时告警（其实本质就是APM），支持超大规模日志的各个维度的关联分析。可以接受一定的延迟，方便对接各种外部系统或支持自定义获取数据，例如，对接第三方审计系统可以实现基于日志和相关时间序列的智能告警、预测、根因分析等信息，并可支持定制化的离线训练方式，以达到更好的效果。为满足上述功能需求，日志平台必须具备的功能模块包括：完善的日志采集，支持DaemonSet、Sidecar等多种采集方式满足不同的采集需求，支持Web、移动端、IoT、物理machine/virtual计算机各种数据源的集合；实时日志通道，是连接上下游的必备功能，保证日志可以方便的被各个系统使用；数据清洗（ETL：Extract,Transform,Load），可以对各种格式的Log进行清洗，支持过滤、富集、转换、陷印、拆分、聚合等；日志展示和搜索是所有日志平台必备的功能，可以根据关键词快速定位日志和查看日志上下文，看似简单的功能是最难做好的；实时分析，搜索只能完成一些定位问题，分析统计功能可以帮助快速分析问题的根源，可以用来快速计算一些业务指标；流计算，通常我们使用流计算框架（Flink、Storm、SparkStream等）来计算一些实时指标或者对数据进行一些自定义清洗；离线分析、运营、安全相关的需求，都需要大量的历史日志，各个维度的关联计算，目前只能通过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，每台机器上部署的DaemonSetFluentd根本没有办法扩容。到了单个agent的瓶颈，就没办法了。只能改为Sidecar。不说更改Sidecar的工作量大，还会带来其他一系列问题，比如如何与CICD系统集成通信、资源消耗、配置规划、不支持stdout收集等。从一开始的边缘业务，逐渐接入越来越多的核心业务，对日志的可靠性要求也越来越高。经常有研发反应从ES上查不到数据，运营报告上的报告不准确。安全说获取的数据不是实时的……每一次问题排查都要经过采集、排队、清洗、传输等多条路径，排查成本非常高。同时需要为日志系统构建一个监控方案，可以第一时间发现问题，而这个方案不能基于日志系统，不能自立。当越来越多的开发者开始使用日志平台排查问题时，经常会出现一两个人提交一个大查询，导致系统整体负载增加，其他人的查询会被阻塞，或者甚至会发生完整的GC。.这时候一些有实力的公司会改造ES，支持多租户隔离；或者为不同的业务部门搭建不同的ES集群，最后运维多个ES集群，工作量还是很大的。在投入大量人力后，日志平台终于可以维持日常使用。这时候，公司的财务团队上前说，我们用了很多机器，成本太高了。这个时候我们就需要优化成本，但是转念一想，我们需要那么多机器。大多数机器的水位每天都在20%-30%，但峰值水位可能达到70%，所以我们不能撤掉。我没办法。这时候只能削峰填谷，又是一堆工作量。这些都是一个中型互联网公司在日志平台建设中经常遇到的问题。在阿里，这些问题会被放大很多倍：比如面对双十一的流量，市面上所有的开源软件都不能满足我们。这么大的流量需求。面对阿里内部数以万计的业务应用，同时有数以千计的工程师在使用，我们必须把并发和多租户隔离做到极致。面对非常多的核心订单、交易等场景，整个链路的稳定性必然需要3个9甚至4个9的可用性。每天如此大量的数据对于成本优化来说是极其重要的，10%的成本优化可能会带来上亿的收益。阿里的K8s日志解决方案解决了上述部分问题。经过多年的开发打磨，我们开发打磨了这样一个K8s日志方案：使用我们自研的日志采集AgentLogtail，实现K8s全方位的数据采集。目前群内已上线Logtail。百万级全量部署，性能和稳定性通过多项双十一金融级测试。化繁为简，原生集成数据队列、清洗处理、实时检索、实时分析、AI算法等，而不是基于各种开源软件的积木，大大缩短数据链路的长度，意味着更少出错的机会。队列、清洗处理、检索、分析、AI引擎等均针对日志场景进行深度定制和优化，满足大吞吐、动态扩展、亿级日志秒查、成本低、高可用性。对于一般的流式计算和离线分析场景的需求，不管是开源的还是阿里内部都有非常成熟的产品，我们通过无缝对接的方式来支持。目前，日志服务支持数十家下游开源、云产品对接。该系统目前支持整个阿里巴巴集团、蚂蚁集团以及云上数万家企业的日志分析。每天写入的数据量为16PB+。这样的系统在开发、运维中存在很多问题和挑战，这里就不展开了。有兴趣的同学可以参考我们团队的技术分享：阿里10PB/天的日志系统设计与实现。总结本文主要从架构层面介绍如何搭建一个K8s日志分析平台，包括开源方案和阿里自研的一套方案。但是，这套系统要在生产环境落地并有效运行，还有很多工作要做：应该用什么样的姿势登录K8s？K8s上日志收集方案的选择，DaemonSet还是Sidecar？日志解决方案如何与CICD集成？微服务下各个应用的日志存储如何划分？如何根据K8s系统的日志做K8s监控？如何监控日志平台的可靠性？如何对多个微服务/组件进行自动检测？如何自动监控多个站点并快速定位异常流量？原文链接本文为云栖社区原创内容，未经允许不得转载。
