元乙 2019-05-29 21:01:18 浏览 170 评论 0
日志
配置
集群
容器
Image
cdn
数据采集
kubernetes
k8s
日志分析
摘要: 将在 QCon 上分享的《阿里 PB 级 Kubernetes 日志平台建设实践》整理出来, 分享给大家.
QCon 是由 InfoQ 主办的综合性技术盛会, 每年在伦敦, 北京, 纽约, 圣保罗, 上海, 旧金山召开. 有幸参加这次 QCon10 周年大会, 作为分享嘉宾在刘宇老师的运维专场发表了《阿里 PB 级 Kubernetes 日志平台建设实践》, 现将 PPT 和文字稿整理下来, 希望和更多的爱好者分享.
计算形态的发展与日志系统的演进
在阿里的十多年中, 日志系统伴随着计算形态的发展在不断演进, 大致分为 3 个主要阶段:
在单机时代, 几乎所有的应用都是单机部署, 当服务压力增大时, 只能切换更高规格的 IBM 小型机. 日志作为应用系统的一部分, 主要用作程序 Debug, 通常结合 grep 等 Linux 常见的文本命令进行分析.
随着单机系统成为制约阿里业务发展的瓶颈, 为了真正的 Scale out, 飞天项目启动: 2009 年开始了飞天的第一行代码, 2013 年飞天 5K 项目正式上线. 在这个阶段各个业务开始了分布式改造, 服务之间的调用也从本地变为分布式, 为了更好的管理, 调试, 分析分布式应用, 我们开发了 Trace(分布式链路追踪)系统, 各式各样的监控系统, 这些系统的统一特点是将所有的日志 (包括 Metric 等) 进行集中化的存储.
为了支持更快的开发, 迭代效率, 近年来我们开始了容器化改造, 并开始了拥抱 Kubernetes 生态, 业务全量上云, Serverless 等工作. 要实现这些改造, 一个非常重要的部分是可观察性的工作, 而日志是作为分析系统运行过程的最佳方式. 在这阶段, 日志无论从规模, 种类都呈现爆炸式的增长, 对日志进行数字化, 智能化分析的需求也越来越高, 因此统一的日志平台应运而生.
日志平台的重要性与建设目标
日志不仅仅是服务器, 容器, 应用的 Debug 日志, 也包括各类访问日志, 中间件日志, 用户点击, IoT / 移动端日志, 数据库 Binlog 等等. 这些日志随着时效性的不同而应用在不同的场景:
准实时级别: 这类日志主要用于准实时 (秒级延迟) 的线上监控, 日志查看, 运维数据支撑, 问题诊断等场景, 最近两年也出现了准实时的业务洞察, 也是基于这类准实时的日志实现.
小时 / 天级别: 当数据积累到小时 / 天级别的时候, 这时一些 T+1 的分析工作就可以开始了, 例如用户留存分析, 广告投放效果分析, 反欺诈, 运营监测, 用户行为分析等.
季度 / 年级别: 在阿里, 数据是我们最重要的资产, 因此非常多的日志都是保存一年以上或永久保存, 这类日志主要用于归档, 审计, 攻击溯源, 业务走势分析, 数据挖掘等.
在阿里, 几乎所有的业务角色都会涉及到各式各样的日志数据, 为了支撑各类应用场景, 我们开发了非常多的工具和功能: 日志实时分析, 链路追踪, 监控, 数据清洗, 流计算, 离线计算, BI 系统, 审计系统等等. 其中很多系统都非常成熟, 日志平台主要专注于智能分析, 监控等实时的场景, 其他功能通常打通的形式支持.
阿里日志平台现状
目前阿里的日志平台覆盖几乎所有的产品线和产品, 同时我们的产品也在云上对外提供服务, 已经服务了上万家的企业. 每天写入流量 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 场景中, 更需要一套高性能, 智能分析的功能来帮助用户快速定位问题, 同时提供一系列简单有效的可视化手段进行辅助.
来源: https://yq.aliyun.com/articles/704058