阿里PB级Kubernetes日志平台建设实践

2019-05-30 本文已影响123人阿里云云栖号

摘要： 将在QCon上分享的《阿里PB级Kubernetes日志平台建设实践》整理出来，分享给大家。

阿里PB级Kubernetes日志平台建设实践

QCon是由InfoQ主办的综合性技术盛会，每年在伦敦、北京、纽约、圣保罗、上海、旧金山召开。有幸参加这次QCon10周年大会，作为分享嘉宾在刘宇老师的运维专场发表了《阿里PB级Kubernetes日志平台建设实践》，现将PPT和文字稿整理下来，希望和更多的爱好者分享。

计算形态的发展与日志系统的演进

目前阿里的日志平台覆盖几乎所有的产品线和产品，同时我们的产品也在云上对外提供服务，已经服务了上万家的企业。每天写入流量16PB以上，对应日志行数40万亿+条，采集客户端200万，服务数千Kubernetes集群，是国内最大的日志平台之一。

为何选择自建

日志系统存在了十多年，目前也有非常多的开源的方案，例如最典型的ELK(Elastic Search、Logstash、Kibana)，通常一个日志系统具备以下功能：日志收集/解析、查询与检索、日志分析、可视化/告警等，这些功能通过开源软件的组合都可以实现，但最终我们选择自建，主要有几下几点考虑：

数据规模：这些开源日志系统可以很好的支持小规模的场景，但很难支持阿里这种超大规模（PB级）的场景。
资源消耗：我们拥有百万规模的服务器/容器，同时日志平台的集群规模也很大，我们需要减少对于采集以及平台自身的资源消耗。
多租户隔离：开源软件搭建的系统大部分都不是为了多租户而设计的，当非常多的业务 / 系统使用日志平台时，很容易因为部分用户的大流量 / 不恰当使用而导致打爆整个集群。
运维复杂度：在阿里内部有一套非常完整的服务部署和管理系统，基于内部组件实现会具备非常好的运维复杂度。
高级分析需求：日志系统的功能几乎全部来源与对应的场景需求，有很多特殊场景的高级分析需求开源软件没办法很好的支持，例如：上下文、智能分析、日志类特殊分析函数等等。

Kubernetes日志平台建设难点

围绕着Kubernetes场景的需求，日志平台建设的难点主要有以下几点：

日志采集：采集在Kubernetes中极其关键和复杂，主要因为Kubernetes是一个高度复杂的场景，K8s中有各式各样的子系统，上层业务支持各种语言和框架，同时日志采集需要尽可能的和Kubernetes系统打通，用K8的形式来完成数据采集。
资源消耗：在K8s中，服务通常都会拆的很小，因此数据采集对于服务自身的资源消耗要尽可能的少。这里我们简单的做一个计算，假设有100W个服务实例，没个采集Agent减少1M的内存、1%的CPU开销，那整体会减少1TB的内存和10000个CPU核心。
运维代价：运维一套日志平台的代价相当之大，因此我们不希望每个用户搭建一个Kubernetes集群时还需再运维一个独立的日志平台系统。因此日志平台一定是要SaaS化的，应用方/用户只需要简单的操作Web页面就能完成数据采集、分析的一整套流程。
便捷使用：日志系统最核心的功能是问题排查，问题排查的速度直接决定了工作效率、损失大小，在K8s场景中，更需要一套高性能、智能分析的功能来帮助用户快速定位问题，同时提供一系列简单有效的可视化手段进行辅助。

阿里PB级Kubernetes日志平台建设实践

Kubernetes日志数据采集

无论是在ITOM还是在未来的AIOps场景中，日志获取都是其中必不可少的一个部分，数据源直接决定了后续应用的形态和功能。在十多年中，我们积累了一套物理机、虚拟机的日志采集经验，但在Kubernetes中不能完全适用，这里我们以问题的形式展开：

问题1：DaemonSet or Sidecar

Kubernetes一个非常大的突破是使用声明式的API来完成服务部署、集群管理等工作。但在K8s集群环境下，业务应用/服务/组件的持续集成和自动发布已经成为常态，使用控制台或SDK操作采集配置的方式很难与各类CI、编排框架集成，导致业务应用发布后用户只能通过控制台手动配置的方式部署与之对应的日志采集配置。
因此我们基于Kubernetes的CRD（CustomResourceDefinition）扩展实现了采集配置的Operator，用户可以直接使用K8s API、Yaml、kubectl、Helm等方式直接配置采集方式，真正把日志采集融入到Kubernetes系统中，实现无缝集成。

问题4：如何管理百万级Logtail

为日志而生的分析引擎

在一些复杂的场景中，我们需要对日志中的数据进行统计来发现其中规律。例如根据ClientIP进行聚合来查找攻击源IP、将数据聚合计算P99/P9999延迟、从多个维度组合分析等。传统的方式需要配合流计算或离线计算的引擎进行聚合计算，再对接可视化系统进行图形化展示或对接告警系统。这种方式用户需要维护多套系统，数据实时性变差，并且各个系统间的衔接很容易出现问题。

因此我们平台原生集成了日志分析、可视化、告警等相关的功能，尽可能减少用户配置链路。通过多年的实践，我们发现用户最容易接受的还是SQL的分析方式，因此我们分析基于SQL92标准实现，在此基础上扩展了很多针对日志分析场景的高级函数，例如：

同比环比：前后数据对比是日志分析中最常用的方式之一，我们提供了同比/环比函数，一个函数即可计算今日PV同比昨日、上周的增幅。
IP地理函数：基于淘宝高精度IP地理库，提供IP到国家、省、市、运营商、经纬度等的转换，例如常见的Nginx访问日志、K8s Ingress访问日志中的remote-ip可以直接用来分析地理位置分布。
Join外部数据源：将日志和 MySQL、CSV等做Join分析，例如根据ID从数据库中查找用户对应的信息、和CMDB中的网络架构数据做关联等。
安全函数：支持日志安全分析中的常见方式，例如高危IP库查找、SQL注入分析、高危SQL检测等。

智能日志分析

在日志平台上，应用方/用户可以通过日志接入、查询、分析、可视化、告警等功能可以完成异常监控、问题调查与定位。但随着计算形态、应用形态以及开发人员职责的不断演变，尤其在近两年Kubernetes、ServiceMesh、Serverless等技术的兴起，问题的复杂度不断上升，常规手段已经很难适用。于是我们开始尝试向AIOps领域发展，例如时序分析、根因分析、日志聚类等。

时序分析

通过时序预测相关方法，我们可以对CPU、存储进行时序建模，进行更加智能的调度，让整体利用率如丝般平滑；存储团队通过对磁盘空间的增长预测，提前制定预算并采购机器；在做部门/产品预算时，根据历年账单预测全年的消费，进行更优的成本控制。
稍微大一些的服务可能会有几百、上千甚至上万台的机器，通过人肉很难发现每台机器行为（时序）的区别，而通过时序聚类就可以快速得到集群的行为分布，定位出异常的机器；同时对于单条时序，可以通过时序异常相关的检测方法，自动定位异常点。

根因分析

时序相关的函数主要用来发现问题，而查找问题根源还需要模式分析相关的方法（根因分析，Root Cause Analysis）。例如K8s集群整体Ingress错误率（5XX比例）突然上升时，如何排查是因为某个服务问题、某个用户引起、某个URL引起、某个浏览器引起、某些地域网络问题、某个节点异常还是整体性的问题？通常这种问题都需要人工从各个维度去排查，例如：

按照Service去Group，查看Service之间的错误率有无差别
没有差别，然后排查URL
还没有，按照浏览器
浏览器有点关系，继续看移动端、PC端
移动端错误率比较高，看看是Android还是IOS
...

这种问题的排查在维度越多时复杂度越高，排查时间也越久，可能等到发现问题的时候影响面已经全面扩大了。因此我们开发了根因分析相关的函数，可以直接从多维数据中定位对目标（例如延迟、失败率等）影响最大的一组（几组）维度组合。
为了更加精确的定位问题，我们还支持对比两个模式的差异，例如今天发生异常时，和昨天正常的模式进行对比，快速找到问题的原因；在发布时进行蓝绿对比以及A/B Test。

智能日志聚类

上面我们通过智能时序函数发现问题、通过根因分析定位到关键的维度组合，但涉及到最终的代码问题排查，还是离不开日志。当日志的数据量很大时，一次次的手动过滤太过耗时，我们希望可以通过智能聚类的方式，把相似的日志聚类到一起，最终可以通过聚类后的日志快速掌握系统的运行状态。

上下游生态对接

Kubernetes日志平台主要的目标在解决DevOps、Net/Site Ops、Sec Ops等问题上，然而这些并不能满足所有用户对于日志的所有需求，例如超大规模的日志分析、BI分析、极其庞大的安全规则过滤等。平台的强大更多的是生态的强大，我们通过对接上下游广泛的生态来满足用户越来越多的日志需求和场景。

优秀应用案例分析

案例1：混合云PAAS平台日志管理

某大型游戏公司在进行技术架构升级，大部分业务会迁移到基于Kubernetes搭建的PAAS平台上，为提高平台整体的可用性，用户采集混合云架构，对于日志的统一建设与管理存在很大困难：

众多内部应用方：不希望应用方过多的接触日志采集、存储等细节，并且能够为应用方提供全链路的日志；
1000+微服务：需要支持大规模的日志采集方式；
多云+线下IDC：希望多个云厂商以及线下IDC采用的是同一套采集方案；
应用周期短：部分应用的运行生命周期极短，需要能够及时将数据采集到服务端；
海外数据回国：海外节点的日志回国分析，需尽可能保证传输稳定性和可靠性。

用户最终选择使用阿里云Kubernetes日志平台的方案，使用Logtail的方案解决采集可靠性问题，通过公网、专线、全球加速的配合解决网络问题，由系统管理员使用DaemonSet统一采集所有系统组件级别的日志，应用方只需使用CRD采集自己的业务日志。对于平台侧，系统管理员可以访问所有系统级别日志，并进行统一的监控和告警；对于应用侧，应用方不仅可以查到自己的业务日志，还能访问到和业务相关的中间件、Ingress、系统组件日志，进行全链路的分析。

案例2：二次开发日志管理平台