公司网站开发文档,网络公司有哪些,广西建设网查证,写作教学网站作者 | 元乙 阿里云日志服务数据采集客户端负责人#xff0c;目前采集客户端 logtail 在集团百万规模部署#xff0c;每天采集上万应用数 PB 数据#xff0c;经历多次双 11、双 12 考验。 导读#xff1a;随着 K8s 不断更新迭代#xff0c;使用 K8s 日志系统建设的开发者… 作者 | 元乙 阿里云日志服务数据采集客户端负责人目前采集客户端 logtail 在集团百万规模部署每天采集上万应用数 PB 数据经历多次双 11、双 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 个主要阶段
在单机时代几乎所有的应用都是单机部署当服务压力增大时只能切换更高规格的 IBM 小型机。日志作为应用系统的一部分主要用作程序 Debug通常结合 grep 等 Linux 常见的文本命令进行分析随着单机系统成为制约阿里业务发展的瓶颈为了真正的 Scale out飞天项目启动2013 年飞天 5K 项目正式上线。在这个阶段各个业务开始了分布式改造服务之间的调用也从本地变为分布式为了更好的管理、调试、分析分布式应用我们开发了 Trace分布式链路追踪系统、各式各样的监控系统这些系统的统一特点是将所有的日志包括 Metric 等进行集中化的存储为了支持更快的开发、迭代效率近年来我们开始了容器化改造并开始了拥抱 Kubernetes 生态、业务全量上云、Serverless 等工作。在这阶段日志无论从规模、种类都呈现爆炸式的增长对日志进行数字化、智能化分析的需求也越来越高因此统一的日志平台应运而生。可观察性的终极解读 在 CNCF 中可观察性的主要作用是问题的诊断上升到公司整体层面可观察性Observability不仅仅包括 DevOps 领域还包括业务、运营、BI、审计、安全等领域可观察性的最终的目标是实现公司各个方面的数字化、智能化。 在阿里几乎所有的业务角色都会涉及到各式各样的日志数据为了支撑各类应用场景我们开发了非常多的工具和功能日志实时分析、链路追踪、监控、数据加工、流计算、离线计算、BI 系统、审计系统等等。日志系统主要专注于数据的实时采集、清洗、智能分析与监控以及对接各类各样的流计算、离线系统。
Kubernetes 日志系统建设难点 单纯日志系统的解决方案非常多相对也比较成熟这里就不再去赘述我们此次只针对 Kubernetes 上的日志系统建设而论。Kubernetes 上的日志方案相比我们之前基于物理机、虚拟机场景的日志方案有很大不同例如
日志的形式变得更加复杂不仅有物理机/虚拟机上的日志还有容器的标准输出、容器内的文件、容器事件、Kubernetes 事件等等信息需要采集环境的动态性变强在 Kubernetes 中机器的宕机、下线、上线、Pod销毁、扩容/缩容等都是常态这种情况下日志的存在是瞬时的例如如果 Pod 销毁后该 Pod 日志就不可见了所以日志数据必须实时采集到服务端。同时还需要保证日志的采集能够适应这种动态性极强的场景日志的种类变多上图是一个典型的 Kubernetes 架构一个请求从客户端需要经过 CDN、Ingress、Service Mesh、Pod 等多个组件涉及多种基础设施其中的日志种类增加了很多例如 K8s 各种系统组件日志、审计日志、ServiceMesh 日志、Ingress 等业务架构变化现在越来越多的公司开始在 Kubernetes 上落地微服务架构在微服务体系中服务的开发更加复杂服务之间的依赖以及服务底层产品的依赖越来越多这时的问题排查将更加复杂如果关联各个维度的日志将是一个困难的问题日志方案集成困难通常我们都会在 Kubernetes 上搭建一套 CICD 系统这套 CICD 系统需要尽可能的自动化的完成业务的集成和部署其中日志的采集、存储、清洗等也需要集成到这套系统中并和 K8s 的声明式部署方式尽可能一致。而现有的日志系统通常都是较独立的系统集成到 CICD 中代价极大日志规模问题通常在系统初期的时候我们会选择自建开源的日志系统这种方式在测试验证阶段或公司发展初期是没有什么问题的但当业务逐渐增长日志量增长到一定规模时自建的开源系统很多时候都会遇到各种各样的问题例如租户隔离、查询延迟、数据可靠性、系统可用性等。日志系统虽不是 IT 中最核心的路径但一旦关键时刻出现这些问题都将是非常可怕的影响例如大促的时候出现紧急问题排查时多个工程师并发查询把日志系统打爆导致故障恢复时间变长大促收到影响。
相信在搞 K8s 日志系统建设的同学看到上面的难点分析都会深有感触后面我们会从落地角度出发详细介绍在阿里我们如何去搭建 K8s 的日志系统敬请关注。
原文链接 本文为云栖社区原创内容未经允许不得转载。
