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

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

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

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

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

在阿里的十多年中，日志系统伴随着计算形态的发展在不断演进，大体分为3个主要阶段：

1. 在单机时代，几乎全部的应用都是单机部署，当服务压力增大时，只能切换更高规格的IBM小型机。日志做为应用系统的一部分，主要用做程序Debug，一般结合grep等Linux常见的文本命令进行分析。
2. 随着单机系统成为制约阿里业务发展的瓶颈，为了真正的Scale out，飞天项目启动：2009年开始了飞天的第一行代码，2013年飞天5K项目正式上线。在这个阶段各个业务开始了分布式改造，服务之间的调用也从本地变为分布式，为了更好的管理、调试、分析分布式应用，咱们开发了Trace（分布式链路追踪）系统、各式各样的监控系统，这些系统的统一特色是将全部的日志（包括Metric等）进行集中化的存储。
3. 为了支持更快的开发、迭代效率，近年来咱们开始了容器化改造，并开始了拥抱Kubernetes生态、业务全量上云、Serverless等工做。要实现这些改造，一个很是重要的部分是可观察性的工做，而日志是做为分析系统运行过程的最佳方式。在这阶段，日志不管从规模、种类都呈现爆炸式的增加，对日志进行数字化、智能化分析的需求也愈来愈高，所以统一的日志平台应运而生。

日志平台的重要性与建设目标

日志不只仅是服务器、容器、应用的Debug日志，也包括各种访问日志、中间件日志、用户点击、IoT/移动端日志、数据库Binlog等等。这些日志随着时效性的不一样而应用在不一样的场景：

1. 准实时级别：这类日志主要用于准实时（秒级延迟）的线上监控、日志查看、运维数据支撑、问题诊断等场景，最近两年也出现了准实时的业务洞察，也是基于这类准实时的日志实现。
2. 小时/天级别：当数据积累到小时/天级别的时候，这时一些T+1的分析工做就能够开始了，例如用户留存分析、广告投放效果分析、反欺诈、运营监测、用户行为分析等。
3. 季度/年级别：在阿里，数据是咱们最重要的资产，所以很是多的日志都是保存一年以上或永久保存，这类日志主要用于归档、审计、攻击溯源、业务走势分析、数据挖掘等。

在阿里，几乎全部的业务角色都会涉及到各式各样的日志数据，为了支撑各种应用场景，咱们开发了很是多的工具和功能：日志实时分析、链路追踪、监控、数据清洗、流计算、离线计算、BI系统、审计系统等等。其中不少系统都很是成熟，日志平台主要专一于智能分析、监控等实时的场景，其余功能一般打通的形式支持。

阿里日志平台现状

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

为什么选择自建                       

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

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

Kubernetes日志平台建设难点

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

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

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

Kubernetes日志数据采集

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

问题1：DaemonSet or Sidecar

日志最主要的采集工具是Agent，在Kubernetes场景下，一般会分为两种采集方式：

1. DaemonSet方式：在K8S的每一个node上部署日志agent，由agent采集全部容器的日志到服务端。
2. Sidecar方式：一个POD中运行一个sidecar的日志agent容器，用于采集该POD主容器产生的日志。

每种采集方式都有其对应的优缺点，这里简单总结以下：

	DaemonSet方式	Sidecar方式
采集日志类型	标准输出+部分文件	文件
部署运维	通常，需维护DaemonSet	较高，每一个须要采集日志的POD都须要部署sidecar容器
日志分类存储	通常，可经过容器/路径等映射	每一个POD可单独配置，灵活性高
多租户隔离	通常，只能经过配置间隔离	强，经过容器进行隔离，可单独分配资源
支持集群规模	中小型规模，业务数最多支持百级别	无限制
资源占用	较低，每一个节点运行一个容器	较高，每一个POD运行一个容器
查询便捷性	较高，可进行自定义的查询、统计	高，可根据业务特色进行定制
可定制性	低	高，每一个POD单独配置
适用场景	功能单一型的集群	大型、混合型、PAAS型集群

在阿里内部，对于大型的PAAS集群，主要使用Sidecar方式采集数据，相对隔离性、灵活性最好；而对与功能比较单一（部门内部/产品自建）的集群，基本都采用DaemonSet的方式，资源占用最低。

问题2：如何下降资源消耗

咱们数据采集Agent使用的是自研的Logtail，Logtail用C++/Go编写，相对开源Agent在资源消耗上具备很是大的优点，但咱们还一直在压榨数据采集的资源消耗，尤为在容器场景。一般，为了提升打日志和采集的性能，咱们都使用本地SSD盘做为日志盘。这里咱们能够作个简答的计算：假设每一个容器挂载1GB的SSD盘，1个物理机运行40个容器，那每台物理机须要40GB的SSD做为日志存储，那5W物理机则会占用2PB的SSD盘。
为了下降这部分资源消耗，咱们和蚂蚁金服团队的同窗们一块儿开发了FUSE的日志采集方式，使用FUSE（Filesystem in Userspace，用户态文件系统）虚拟化出日志盘，应用直接将日志写入到虚拟的日志盘中，最终数据将直接从内存中被Logtail采集到服务端。这种采集的好处有：

1. 物理机无需为容器提供日志盘，真正实现日志无盘化。
2. 应用程序视角看到的仍是普通的文件系统，无需作任何额外改造。
3. 数据采集绕过磁盘，直接从内存中将数据采集到服务端。
4. 全部的数据都存在服务端，服务端支持横向扩展，对于应用来讲他们看到的日志盘具备无线存储空间。

问题3：如何与Kubernetes无缝集成

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

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

对于人才管理有个经典的原则：10我的要用心良苦，100我的要杀伐果断，1000我的要甩手掌柜。而一样对于Logtail这款日志采集Agent的管理也是如此，这里咱们分为3个主要过程：

1. 百规模：在好几年前，Logtail刚开始部署时，也就在几百台物理机上运行，这个时期的Logtail和其余主流的Agent同样，主要完成数据采集的功能，主要流程为数据输入、处理、聚合、发送，这个时期的管理基本靠手，采集出现问题的时候人工登陆机器去看问题。
2. 万规模：当愈来愈多的应用方接入，每台机器上可能会有多个应用方采集不一样类型的数据，手动配置的接入过程也愈来愈难以维护。所以咱们重点在多租户隔离以及中心化的配置管理，同时增长了不少控制相关的手段，好比限流、降级等。
3. 百万规模：当部署量打到百万级别的时候，异常发生已经成为常态，咱们更须要的是靠一系列的监控、可靠性保证机制、自动化的运维管理工具，让这些机制、工具来自动完成Agent安装、监控、自恢复等一系列工做，真正作到甩手掌柜。

Kubernetes日志平台架构

上图是阿里Kubernetes日志平台的总体架构，从底到上分为日志接入层、平台核心层以及方案整合层：

1. 平台提供了很是多的手段用来接入各类类型的日志数据。不只仅只有Kubernetes中的日志，同时还包括和Kubernetes业务相关的全部日志，例如移动端日志、Web端应用点击日志、IoT日志等等。全部数据支持主动Push、被动Agent采集，Agent不只支持咱们自研的Logtail，也支持使用开源Agent（Logstash、Fluentd、Filebeats等）。

2. 日志首先会到达平台提供的实时队列中，相似于Kafka的consumer group，咱们提供实时数据订阅的功能，用户能够基于该功能实现ETL的相关需求。平台最核心的功能包括：

   1. 实时搜索：相似于搜索引擎的方式，支持从全部日志中根据关键词查找，支持超大规模（PB级）。
   2. 实时分析：基于SQL92语法提供交互式的日志分析方法。
   3. 机器学习：提供时序预测、时序聚类、根因分析、日志聚合等智能分析方法。
   4. 流计算：对接各种流计算引擎，例如：Flink、Spark Stream、Storm等。
   5. 离线分析：对接离线分析引擎，例如Hadoop、Max Compute等。
3. 基于全方位的数据源以及平台提供的核心功能，并结合Kubernetes日志特色以及应用场景，向上构建Kubernetes日志的通用解决方案，例如：审计日志、Ingress日志分析、ServiceMesh日志等等。同时对于有特定需求的应用方/用户，可直接基于平台提供的OpenAPI构建上层方案，例如Trace系统、性能分析系统等。

下面咱们从问题排查的角度来具体展开平台提供的核心功能。

PB级日志查询

排查问题的最佳手段是查日志，大部分人脑海中最早想到的是用 grep 命令查找日志中的一些关键错误信息， grep 是Linux程序员最受欢迎的命令之一，对于简单的问题排查场景也很是实用。若是应用部署在多台机器，那还会配合使用pgm、pssh等命令。然而这些命令对于Kubernetes这种动态、大规模的场景并不适用，主要问题有：

1. 查询不够灵活，grep命令很难实现各类逻辑条件的组合。
2. grep是针对纯文本的分析手段，很难将日志格式化成对应的类型，例如Long、Double甚至JSON类型。
3. grep命令的前提条件是日志存储在磁盘上。而在Kubernetes中，应用的本地日志空间都很小，而且服务也会动态的迁移、伸缩，本地的数据源极可能会不存在。
4. grep是典型的全量扫描方式，若是数据量在1GB之内，查询时间还能够接受，但当数据量上升到TB甚至PB时，必须依赖搜索引擎的技术才能工做。

咱们在2009年开始在飞天平台研发过程当中，为够解决大规模（例如5000台）下的研发效率、问题诊断等问题，开始研支持超大规模的日志查询平台，其中最主要的目标是“快”，对于几十亿的数据也可以轻松在秒级完成。

日志上下文

当咱们经过查询的方式定位到关键的日志后，须要分析当时系统的行为，并还原出当时的现场状况。而现场其实就是当时的日志上下文，例如：

• 一个错误，同一个日志文件中的先后数据
• 一行LogAppender中输出，同一个进程顺序输出到日志模块先后顺序
• 一次请求，同一个Session组合
• 一次跨服务请求，同一个TraceId组合

在Kubernetes的场景中，每一个容器的标准输出（stdout）、文件都有对应的组合方式构成一个上下文分区，例如Namesapce+Pod+ContainerID+FileName/Stdout。
为支持上下文，咱们在采集协议中对每一个最小区分单元会带上一个全局惟一而且单调递增的游标，这个游标对单机日志、Docker、K8S以及移动端SDK、Log4J/LogBack等输出中有不同的形式。

为日志而生的分析引擎

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

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

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

智能日志分析

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

时序分析

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

根因分析

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

1. 按照Service去Group，查看Service之间的错误率有无差异
2. 没有差异，而后排查URL
3. 尚未，按照浏览器
4. 浏览器有点关系，继续看移动端、PC端
5. 移动端错误率比较高，看看是Android仍是IOS
6. ...

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

智能日志聚类

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

上下游生态对接

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

优秀应用案例分析

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

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

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

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

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

在阿里有不少大的业务部门但愿基于咱们标准的日志平台进行二次开发，来知足他们部门的一些特殊需求，例如：

• 经过各种规则以及接口限制规范数据接入。
• 经过TraceID将整个调用链串联，构建Trace平台。
• 部门内部多用户的权限细化管理。
• 部门内部各个子部门的成本结算。
• 与一内部些管控、运维系统打通。

这些需求能够基于咱们提供的OpenAPI以及各语言的SDK快速的实现，同时为了减小前端的工做量，平台还提供Iframe嵌入的功能，支持直接将部分界面（例如查询框、Dashboard）直接嵌入到业务部门本身的系统中。

将来工做展望

目前阿里Kubernetes日志平台在内外部已经有很是多的应用，将来咱们还将继续打磨平台，为应用方/用户提供更加完美的方案，后续工做主要集中在如下几点：

1. 数据采集进一步精细化，持续优化可靠性和资源消耗，作到极致化的多租户隔离，争取在PAAS平台使用DaemonSet采集全部应用的日志。
2. 提供更加便捷、智能的数据清洗服务，在平台内部就能够完成异构数据的清洗、规整等工做。
3. 构建面向Ops领域的、可自动更新的、支持异构数据的知识图谱，让问题排查的经验能够积累在知识库中，实现异常搜索与推理。
4. 提供交互式的训练平台，构建更加智能的Automation能力，真正实现Ops的闭环。

相关工做与参考

• 阿里云日志服务 https://www.aliyun.com/product/sls
• 阿里云Kubernetes : https://www.aliyun.com/product/kubernetes
• Kubernetes 审计日志方案 : https://yq.aliyun.com/articles/686982
• Kubernetes Ingress日志方案 : https://yq.aliyun.com/articles/693600
• 数据采集全球加速 : https://yq.aliyun.com/articles/620453
• 日志采集CRD配置： https://yq.aliyun.com/articles/596310

 

 

本文做者：元乙

原文连接

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