6 个 K8s 日志系统建设中的典型问题，你遇到过几个？

做者 |  元乙  阿里云日志服务数据采集客户端负责人，目前采集客户端 logtail 在集团百万规模部署，天天采集上万应用数 PB 数据，经历屡次双 十一、双 12 考验。

**导读：**随着 K8s 不断更新迭代，使用 K8s 日志系统建设的开发者，逐渐遇到了各类复杂的问题和挑战。本篇文章中，做者结合本身多年经验，分析 K8s 日志系统建设难点，期待为读者提供有益参考。

在 Logging 这块作了几年，最近 1 年来愈来愈多的同窗来咨询如何为 Kubernetes 构建一个日志系统，或者是来求助在这过程当中遇到一系列问题如何解决，授人以鱼不如授人以渔，因而想把咱们这些年积累的经验以文章的形式发出来，让看到这篇文章的同窗能少走弯路。这个系列文章定位为长篇连载，内容偏向落地实操以及经验分享，且内容会随着技术的迭代而不按期更新。

前言

第一次听到 Kubernetes 的名字是在 2016 年，那个时候 Kubernetes 还处于和 Docker Swarm、Mesos 方案的“三国鼎立时代”，Kubernetes 因为一系列优点（可扩展、声明式接口、云友好）在这一竞争中崭露头角，最终得到统治地位。

Kubernetes 做为 CNCF 最核心的项目（没有之一），是 Cloud Native（云原生）落地的底座，目前阿里已经全面基于 Kubernetes 在开展全站的云原生改造，在 1-2 年内，阿里巴巴 100% 的业务都将跑在公有云上。

CloudNative 在 CNCF 的定义的核心是：在公有云、私有云、混合云等环境中，经过 Containers、Service Meshes、 MicroServices、Immutable Infrastructure、Declarative APIs 构建和运行可弹性扩展的且具备高容错性、易于管理、可观察、松耦合的应用系统。可观察性是应用系统必不可少的一个部分，云原生的设计理念中就有一条：面向诊断性设计（Diagnosability），包括集群级别的日志、Metric 和 Trace。

为什么咱们须要日志系统

一般一个线上问题的定位流程是：经过 Metric 发现问题，根据 Trace 定位到问题模块，根据模块具体的日志定位问题缘由。在日志中包括了错误、关键变量、代码运行路径等信息，这些是问题排查的核心，所以日志永远是线上问题排查的必经路径。

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

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

可观察性的终极解读

在 CNCF 中，可观察性的主要做用是问题的诊断，上升到公司总体层面，可观察性（Observability）不只仅包括 DevOps 领域，还包括业务、运营、BI、审计、安全等领域，可观察性的最终的目标是实现公司各个方面的数字化、智能化。

在阿里，几乎全部的业务角色都会涉及到各式各样的日志数据，为了支撑各种应用场景，咱们开发了很是多的工具和功能：日志实时分析、链路追踪、监控、数据加工、流计算、离线计算、BI 系统、审计系统等等。日志系统主要专一于数据的实时采集、清洗、智能分析与监控以及对接各种各样的流计算、离线系统。

Kubernetes 日志系统建设难点

单纯日志系统的解决方案很是多，相对也比较成熟，这里就再也不去赘述，咱们这次只针对 Kubernetes 上的日志系统建设而论。Kubernetes 上的日志方案相比咱们以前基于物理机、虚拟机场景的日志方案有很大不一样，例如：

1. 日志的形式变得更加复杂，不只有物理机/虚拟机上的日志，还有容器的标准输出、容器内的文件、容器事件、Kubernetes 事件等等信息须要采集；
2. 环境的动态性变强，在 Kubernetes 中，机器的宕机、下线、上线、Pod销毁、扩容/缩容等都是常态，这种状况下日志的存在是瞬时的（例如若是 Pod 销毁后该 Pod 日志就不可见了），因此日志数据必须实时采集到服务端。同时还须要保证日志的采集可以适应这种动态性极强的场景；
3. 日志的种类变多，上图是一个典型的 Kubernetes 架构，一个请求从客户端须要通过 CDN、Ingress、Service Mesh、Pod 等多个组件，涉及多种基础设施，其中的日志种类增长了不少，例如 K8s 各类系统组件日志、审计日志、ServiceMesh 日志、Ingress 等；
4. 业务架构变化，如今愈来愈多的公司开始在 Kubernetes 上落地微服务架构，在微服务体系中，服务的开发更加复杂，服务之间的依赖以及服务底层产品的依赖愈来愈多，这时的问题排查将更加复杂，若是关联各个维度的日志将是一个困难的问题；
5. 日志方案集成困难，一般咱们都会在 Kubernetes 上搭建一套 CICD 系统，这套 CICD 系统须要尽量的自动化的完成业务的集成和部署，其中日志的采集、存储、清洗等也须要集成到这套系统中，并和 K8s 的声明式部署方式尽量一致。而现有的日志系统一般都是较独立的系统，集成到 CICD 中代价极大；
6. 日志规模问题，一般在系统初期的时候咱们会选择自建开源的日志系统，这种方式在测试验证阶段或公司发展初期是没有什么问题的，但当业务逐渐增加，日志量增加到必定规模时，自建的开源系统不少时候都会遇到各类各样的问题，例如租户隔离、查询延迟、数据可靠性、系统可用性等。日志系统虽不是 IT 中最核心的路径，但一旦关键时刻出现这些问题都将是很是可怕的影响，例如大促的时候出现紧急问题，排查时多个工程师并发查询把日志系统打爆，致使故障恢复时间变长，大促收到影响。

相信在搞 K8s 日志系统建设的同窗看到上面的难点分析都会深有感触，后面咱们会从落地角度出发，详细介绍在阿里咱们如何去搭建 K8s 的日志系统，敬请关注。

“ 阿里巴巴云原生微信公众号（ID：Alicloudnative）关注微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的技术公众号。”