孙廷韬 阿里10PB天日志系统设计和实现

文字内容
1. 阿⾥里里10PB+/天⽇日志系统设计和 实现 孙廷韬(⻰龙悟) 阿⾥里里云 ⾼高级技术专家
4. ⾃自我介绍 孙廷韬(花名:龙悟) 阿里云日志服务高级技术专家 • 飞天系统监控模块(5K台集群Metric、Tracing等) • 阿里日志服务架构设计、实现 • 关注分布式系统、高性能索引查询、DevOps、AIOps
5. • 日志系统由来和演进 • 核心挑战和技术选择 • 日志场景功能介绍 • 阿里内部实际应用场景
6. • 日志系统由来和演进 • 核心挑战和技术选择 • 日志场景功能介绍 • 阿里内部实际应用场景
7. 为什什么要做⽇日志系统 环境复杂 • 模块多、团队多 • 链路复杂 • 信息散落 分布式系统问题调查太困难! 内容分发 网络服务 Oss Table Store … Max Compute 盘古 分布式存储 夸父 远程过程调用 安全服务 Stream Compute 伏羲 分布式应用调度 安全 管理 数据服务 数据计算 海量存储 弹性计算 ECS 中间件服务 女娲 分布式协同 Linux 服务器集群 飞天平台架构 伏羲 资源管理 … 神农 分布式监控 •
8. ⽇日志系统需求和技术选型 实时消费 集中采集 需求 开源方案 • • • • • 百万级机器 资源占用 易用 运维、管理 监控 • Fluentd • Filebeat • • • • • 毫秒延时 高吞吐 可扩展 稳定 生态兼容 • Kafka 离线需求 分析&可视化 • • • • • 百亿级查询 秒级响应 Adhoc query 快速分析 Dev/AI Ops • ElasticSearch • Solr • • • • • 海量 复杂分析 机器学习 归档 审计 • Hadoop • Spark 挑战:百万级机器、10PB+/天、万级应用、数千工程师 方案:软件->服务,聚焦实时,产生 -> 查询分析(秒级)
9. ⽇日志系统及上下游 Mobile & Web Mobile Web Massive Structured, Unstructured & Semistructured Data MaxCompute PAI OSS Batch Processing Text & Logs Log Service/ Logtail Big Data Analytics Visualization Pig Hybrid Storage Array HIVE EMR SQL、NoSQL Interactive Analytics Services & Languages Log Service / LogShipper IoT & Devices Camera Real-time Data Stream Log Service / LogHub IoT 采集 Hadoop QuickBI DataV DLA Log Service / Analytics Stream Processing Log Service / Dashboard SparkStreaming Flink Storm Function Compute 存储&消费 查询&分析 可视化
10. • 日志系统由来和演进 • 核心挑战和技术选择 • 日志场景功能介绍 • 阿里内部实际应用场景
11. 当前规模 日写入 : 16PB+, 40万亿行+ 用户:阿里所有BU、公有云用户 日索引:6.5PB 应用:数十万 日查询:10亿+、读取: 10PB+(压缩后) Region:全球30+集群 客户端: 200W+ 单集群:日写入6PB,索引2PB (10万亿行)
12. 核⼼心挑战和⽅方案选择 取舍权衡 成本 HDD vs SSD 集群划 性能 分 规模 百亿规模 访问不可预期 追求: • • 快,低成本 • 放弃: • • 强一致性(99%,<1秒) • • 完全精确 • 高QPS查询 共享 vs 独占 规模 稳定性 资源竞争 相互影响 理 • • 数十万应用 百万级Agent Append Only 时间有序(99%) 越旧数据,越少访问 写多查少 我们的选择: • 运维管 日志特点 • • HDD(主)、SSD(辅) 大集群部署 多租户共享 内部、公有云无差别服务 靠技术解决问题
13. HDD vs 百亿级查询 • 秒级百亿行日志 • 多条件组合 • 迭代查询
14. HDD⽀支持百亿级查询 • IOPS低(百级) 策略 优势 劣势 • • 大集群,总量高 写多查少,资源复用 • • • 原始日志:降IOPS • • • • • IO分散(单机2K分区) 低延时、高qps 合并小IO写SSD SSD 转 HDD Hub数据源 查询:减量、加速 索引:降流量 • • • • • • Succinct Tree 字典(40~70%) BKD-Tree 压缩优化(50%) 自适应Bitmap 优化 Index Data only Erasure Coding(3拷贝->1.4) 根据查询,动态Compaction 扩大单次查询资源 迭代查询,快速返回 Cache复用 • • • • • • • 按时间过滤 多层Cache,数据复用 节点间低交互 高并发(上千) Bitmap间直接运算 协程, IO/计算分离 SIMD 指令加速
15. 有没有遇到过这些问题? • 单个超⼤大查询,搞挂集群 • ⼤大⽤用户写⼊入,影响其他⽤用户 • 凌晨3点报警电话不不断
16. 多租户下的稳定性 在线服务要求 遇到过的问题 解决方案 • 永远在线7*24 • 单机热点,流量打爆 • 自动反馈,系统自愈 • QoS有保证 • 机器异常,vip 未自动摘除 • 制定标准,划清边界 • 性能有预期 • 内核Bug,系统异常 • 隔离可控,该限则限 • 狂刷Meta,数据库瓶颈 • 心跳异常,集群全部重启 • TCMalloc 内存分配瓶颈 • Vip网络设备被打爆 • … • … • 持续迭代,完善架构 • 监控报警,防患未然
17. 单机异常影响有多⼤大 前端 Nginx VIP Nginx 后端(A~F数据分片) A A B D C E 100台机,1台异常,延时从 20ms->5sec(timeout),对用 户影响多大? 可能没影响 也可能影响很大 F 延时变化: 20ms * 99% + 5000 * 1% = 69.8ms Nginx B C D E 最大吞吐:下降71.4% 并发够: 无影响 分布式模型 并发不够:影响很大
18. ⾃自动消除热点 调度决策 • 资源多维度定义 CPU:'>CPU:'>CPU:'>CPU: 75% Net:'>Net:'>Net:'>Net: 65% E D • 实时监控汇报 调度器 实时汇报资源使用 CPU:'>CPU:'>CPU:'>CPU: 35% Net:'>Net:'>Net:'>Net: 45% • 自动优化组合 CPU:'>CPU:'>CPU:'>CPU: 45% Net:'>Net:'>Net:'>Net: 30% E C B B A A 自动负载均衡 D C C E E B B C A A A 自动分裂
19. 主动防御--全局秒级流控 后端(分片X成热点) 前端 A Nginx B C E • 无法分裂 • 后端拒绝请求,网络仍可能被打爆 • 迁移不解决问题,引起雪崩 VIP Nginx A D E F • 定义服务标准 Nginx B C D X • 超过后,尽力服务(Qos前提下) • 后端拒绝服务,同步流控中心 秒级同步所有前端 上报热点分片X 流控中心 • 秒级同步到上千前端,前端拦截 • 穿透到后端流量为正常流量1~3%
20. 多租户资源隔离 操作类型 资源划分 隔离原则 • 实时写入 • CPU • 最低保障 • 流式读取 • 线程、协程 • 弹性上调 • 查询分析 • 内存 • 实时监控 • 网络 • 及时中止
21. • 日志系统由来和演进 • 核心挑战和技术选择 • 日志场景功能介绍 • 阿里内部实际应用场景
22. ⽇日志场景:交互式分析 查询: • • • • 文本、数值、json 上下文、LiveTail 智能聚类 百亿级查询 分析: • • • • • SQL 92 语法,JDBC 时序分析、机器学习 OSS、Mysql 外表 同比、环比、IP地理函数 10亿级分析 可视化: • • • • 所见即所得、DrillDown 定义画布(Canvas) 报告自动发送 可内嵌,免密码登陆
23. 问题调查通⽤用⼿手段 看 • • • • 问题调查三大数据源 ssh + grep + awk 上下文(tail) 黄金指标 Tracing 比 • • • • 数量、比例 抖动、断裂 环比、同比 个体和群体 猜 • 维度组合 • Drilldown/Rollup • 特征、规律 问题: 低效、重复、信息爆炸、遗漏 思路:手动->自动 、高维 -> 低维、杂乱->有序
24. 智能分析:⽇日志聚类 500台的集群,多模块报错,5分钟1亿条日志,怎么查? • 实时聚类(秒级) • 生产可用 • 任意条件过滤 • 和历史对比 • 一眼看尽上亿日志
25. 智能分析:时序场景 时序函数 • 异常检查:变点、折点 • 周期检测、层次聚类 • 时序预测:账单、资源、流量 模式分析 定位频繁集 : • 90%的错误由某ID导致 A 集合最大支持因素: • 某个维度组合 • 在异常集合(A)中比例高 • 在正常集合(B)中比例低 B A In A Ratio ID=1002 95 90% ID=1002 Method=Get 80 76% ID=1002 Method=Get IP=120343 40 38% ID=1003 10 9% In A Ratio In B Ratio ID=1002 95 90% 100 3% ID=1002 Method=Get 80 76% 100 3% ID=1002 Method=Get IP=120343 40 38% 250 7.5% ID=1003 20 9% 500 15%
26. ⽇日志系统设计总结 • “快”是核心 • 功能有所取舍 • 技术降成本 • 自愈保稳定
27. • 日志系统由来和演进 • 核心挑战和技术选择 • 日志场景功能介绍 • 阿里内部实际应用场景
28. 银泰混合云架构监控系统 应用告警 问题排查 大盘 上下文 DataV 大盘 故障处理系统 livetail 告警详情 关键词查询 数据清洗 聚合 查询 流式消费、SQL 责任人 告警规则 日志服务 JSON 正则表达式 监控日志 DS SQL Spring 异常 HSF JVM IDC环境 告警知 识库 Trace ID SQL、告警 分隔符 中间件日志 业务日志 Hsf 一般业务 mtop 核心打点 云上EDAS 阿里内部 Logtail + 自定义机器分组 告警数据 降级