QCon是由InfoQ主办的综合性技术盛会,每年在伦敦、北京、纽约、圣保罗、上海、旧金山召开。有幸参加这次QCon10周年大会,作为分享嘉宾在刘宇老师的运维专场发表了《阿里PB级Kubernetes日志平台建设实践》,现将PPT和文字稿整理下来,希望和更多的爱好者分享。
在阿里的十多年中,日志系统伴随著计算形态的发展在不断演进,大致分为3个主要阶段:
日志不仅仅是伺服器、容器、应用的Debug日志,也包括各类访问日志、中间件日志、用户点击、IoT/移动端日志、资料库Binlog等等。这些日志随著时效性的不同而应用在不同的场景:
在阿里,几乎所有的业务角色都会涉及到各式各样的日志数据,为了支撑各类应用场景,我们开发了非常多的工具和功能:日志实时分析、链路追踪、监控、数据清洗、流计算、离线计算、BI系统、审计系统等等。其中很多系统都非常成熟,日志平台主要专注于智能分析、监控等实时的场景,其他功能通常打通的形式支持。
日志系统存在了十多年,目前也有非常多的开源的方案,例如最典型的ELK(Elastic Search、Logstash、Kibana),通常一个日志系统具备以下功能:日志收集/解析、查询与检索、日志分析、可视化/告警等,这些功能通过开源软体的组合都可以实现,但最终我们选择自建,主要有几下几点考虑:
围绕著Kubernetes场景的需求,日志平台建设的难点主要有以下几点:
无论是在ITOM还是在未来的AIOps场景中,日志获取都是其中必不可少的一个部分,数据源直接决定了后续应用的形态和功能。在十多年中,我们积累了一套物理机、虚拟机的日志采集经验,但在Kubernetes中不能完全适用,这里我们以问题的形式展开:
每种采集方式都有其对应的优缺点,这里简单总结如下:
| | DaemonSet方式 | Sidecar方式 | | --- | --- | --- | | 采集日志类型 | 标准输出+部分文件 | 文件 | | 部署运维 | 一般,需维护DaemonSet | 较高,每个需要采集日志的POD都需要部署sidecar容器 | | 日志分类存储 | 一般,可通过容器/路径等映射 | 每个POD可单独配置,灵活性高 | | 多租户隔离 | 一般,只能通过配置间隔离 | 强,通过容器进行隔离,可单独分配资源 | | 支持集群规模 | 中小型规模,业务数最多支持百级别 | 无限制 | | 资源占用 | 较低,每个节点运行一个容器 | 较高,每个POD运行一个容器 | | 查询便捷性 | 较高,可进行自定义的查询、统计 | 高,可根据业务特点进行定制 | | 可定制性 | 低 | 高,每个POD单独配置 | | 适用场景 | 功能单一型的集群 | 大型、混合型、PAAS型集群 |
在阿里内部,对于大型的PAAS集群,主要使用Sidecar方式采集数据,相对隔离性、灵活性最好;而对与功能比较单一(部门内部/产品自建)的集群,基本都采用DaemonSet的方式,资源占用最低。
我们数据采集Agent使用的是自研的Logtail,Logtail用C++/Go编写,相对开源Agent在资源消耗上具有非常大的优势,但我们还一直在压榨数据采集的资源消耗,尤其在容器场景。通常,为了提高打日志和采集的性能,我们都使用本地SSD盘作为日志盘。这里我们可以做个简答的计算:假设每个容器挂载1GB的SSD盘,1个物理机运行40个容器,那每台物理机需要40GB的SSD作为日志存储,那5W物理机则会占用2PB的SSD盘。
下面我们从问题排查的角度来具体展开平台提供的核心功能。
排查问题的最佳手段是查日志,大部分人脑海中最先想到的是用 grep 命令查找日志中的一些关键错误信息, grep 是Linux程序员最受欢迎的命令之一,对于简单的问题排查场景也非常实用。如果应用部署在多台机器,那还会配合使用pgm、pssh等命令。然而这些命令对于Kubernetes这种动态、大规模的场景并不适用,主要问题有:
grep
我们在2009年开始在飞天平台研发过程中,为够解决大规模(例如5000台)下的研发效率、问题诊断等问题,开始研支持超大规模的日志查询平台,其中最主要的目标是「快」,对于几十亿的数据也能够轻松在秒级完成。
在Kubernetes的场景中,每个容器的标准输出(stdout)、文件都有对应的组合方式构成一个上下文分区,例如Namesapce+Pod+ContainerID+FileName/Stdout。
在日志平台上,应用方/用户可以通过日志接入、查询、分析、可视化、告警等功能可以完成异常监控、问题调查与定位。但随著计算形态、应用形态以及开发人员职责的不断演变,尤其在近两年Kubernetes、ServiceMesh、Serverless等技术的兴起,问题的复杂度不断上升,常规手段已经很难适用。于是我们开始尝试向AIOps领域发展,例如时序分析、根因分析、日志聚类等。
时序相关的函数主要用来发现问题,而查找问题根源还需要模式分析相关的方法(根因分析,Root Cause Analysis)。例如K8s集群整体Ingress错误率(5XX比例)突然上升时,如何排查是因为某个服务问题、某个用户引起、某个URL引起、某个浏览器引起、某些地域网路问题、某个节点异常还是整体性的问题?通常这种问题都需要人工从各个维度去排查,例如:
这种问题的排查在维度越多时复杂度越高,排查时间也越久,可能等到发现问题的时候影响面已经全面扩大了。因此我们开发了根因分析相关的函数,可以直接从多维数据中定位对目标(例如延迟、失败率等)影响最大的一组(几组)维度组合。
上面我们通过智能时序函数发现问题、通过根因分析定位到关键的维度组合,但涉及到最终的代码问题排查,还是离不开日志。当日志的数据量很大时,一次次的手动过滤太过耗时,我们希望可以通过智能聚类的方式,把相似的日志聚类到一起,最终可以通过聚类后的日志快速掌握系统的运行状态。
用户最终选择使用阿里云Kubernetes日志平台的方案,使用Logtail的方案解决采集可靠性问题,通过公网、专线、全球加速的配合解决网路问题,由系统管理员使用DaemonSet统一采集所有系统组件级别的日志,应用方只需使用CRD采集自己的业务日志。对于平台侧,系统管理员可以访问所有系统级别日志,并进行统一的监控和告警;对于应用侧,应用方不仅可以查到自己的业务日志,还能访问到和业务相关的中间件、Ingress、系统组件日志,进行全链路的分析。
这些需求可以基于我们提供的OpenAPI以及各语言的SDK快速的实现,同时为了减少前端的工作量,平台还提供Iframe嵌入的功能,支持直接将部分界面(例如查询框、Dashboard)直接嵌入到业务部门自己的系统中。
推荐阅读: