饿了么监控体系的演进 黄杰

2020-03-01 482浏览

  • 1.饿了么监控体系的演进 黄杰
  • 2.自我介绍
  • 3.自我介绍 • 近期加入了字节跳动 • 2015 年加入饿了么，负责饿了么监控平台构建及周边工具链建设 • 曾在携程框架部，负责 Logging/Tracing/Metrics
  • 4.目录 1. 背景 2. 遇到的问题 3. 场景化 4. 系统设计
  • 5.背景 1.0 2.0 3.0 1. Statsd/Graphite/Grafana 1. Statsd/Graphite/Grafana 1. EMonitor/LinDB 2. ETrace 2. ETrace/LinDB 2. SLS 3. Zabbix 3. ESM/InfluxDB/Grafana 4. ELog 4. ELK 单IDC 异地多活
  • 6.现状 1. 覆盖了饿了么所有的监控 （业务监控，全链路监控，PaaS，IaaS等） 2. 覆盖所有应用及服务器 3. 每天采集原始数据 800T 4. 高峰计算事件 7000W/s
  • 7.目录 1. 背景 2. 遇到的问题 3. 场景化 4. 系统设计
  • 8.遇到的问题 1. 多套监控系统，包括收集，可视化及报警等 2. 各种上下文切换 3. 适合熟练工，不适合新同学 核心问题 1. 快速发现问题 2. 快速定位问题 E-Monitor 核心用户 1. GOC 2. 开发人员
  • 9.如何解决 业务 (订单/运单) 1. 各层面向的用户及其视角是不一样的 2. 做好业务侧监控，并能联动 3. 标准化应用/PaaS/IaaS各层监控 应用 Tracing/Logging (Exception/SOA/DB/Redis/Q) 4. 需要一个纽带来把各层串联起来 5. 端对端监控 6. 充分与周边系统集成 PaaS 中间件 (ES/DAL/Redis/Q/Job/SLB) IaaS (CPU/MEM/Network/TCP)
  • 10.如何解决 业务 IaaS Tracing PaaS 应用
  • 11.如何解决 一套系统覆盖所有监控，支持多平台
  • 12.目录 1. 背景 2. 遇到的问题 3. 场景化 4. 系统设计
  • 13.业务大盘 VS Grafana 1. 与业务更贴合 2. Dashboard App 3. Chart Repo 4. 自动的关联及Drill Down 5. 小工具
  • 14.业务大盘
  • 15.应用监控
  • 16.应用监控 - Exception
  • 17.应用监控 - SOA
  • 18.应用监控 - SOA
  • 19.基础设施 - DAL
  • 20.Tracing 所有的 Metrics 曲线上都可以点击查看 10S 窗口内有问题的采样数据
  • 21.Tracing
  • 22.服务器监控
  • 23.一键搜索
  • 24.场景的好处 1. SLS 集成，可以很方便通过 Trace ID 关联查询到相关的日志 2. 开发发现异常，通过 Trace 定位到某个机器，直接可以通过机器信息关联到 Docker Container， 直接集成 AppOS 3. 开发发现基础设施问题，可以通过 Runtime Dependency 看到所有的依赖，从而可以看到自己 使用的那些基础设施有没有问题 4. 同时的基础设施的同学发现了问题，也可以及时的反馈给业务方 5. 千人千面 1. 报警发现问题 2. EMonitor 定位问题 3. 快速恢复问题，快带定位问题
  • 25.目录 1. 背景 2. 遇到的问题 3. 场景化 4. 系统设计
  • 26.整体架构 1. Pipeline -> Lambda 2. 支持多IDC 3. 全量日志，通过指标+采样的方式 4. 支持 Java/Golang/Python/PHP/C++/Node.js 5. 所有监控数据计算窗口为 10S 6. 自研 + 开源组件构建了整套系统
  • 27.整体架构
  • 28.遇到的坑 1. Kafka broker 某一节点 IO Hang 住，导致所有 Producer 线程全部 Hang 住，流量掉底 2. HBase 上构建了索引，导致 HBase 热点严重 3. 系统稳定性 4. 生产效率 1. 基于 Kafka Client 封装了一个 Broker 与 Thread 绑定的版本，即一个线程负责某一 Broker 的写入，当 某一节点写入有问题，数据自动 Balance 到别的节点 2. 不支持全文检索，有时看起很用的功能，其实不一定是用户真正需要的 3. 从 Pipeline 处理所有数据流，到计算和写存储分离类似 Lambda，计算采用类 SQL 4. 所有的数据都转换成 Metrics， 外加自定义的可视化组件，阶段性的前进，每个阶段只做 1-2 件重要 的事情
  • 29.计算 - Shaka 1. 随着数据量不断增加，系统开始出现不稳定的情况，有时出问题之后需要较长时间来恢复 2. 计算是整系统的资源大户，也是整个系统最核心的组件之一 做好数据的 Sharding 对一个计算类组件非常重要，越早做 Sharding 效果越好 1. 写 Kafka 之前就按一定的数据特性来 Sharding，不同类型的数据写不同的 Topic/Partition 2. Shaka 内部又按不同 Event 类型 Sharding 到不同的 SQL Engine 1. 基于 CEP(Esper) 实现类 SQL 的计算 2. 非结构化的数据转换成结构化数据 3. UDF 处理异常数据分析及采样
  • 30.计算 - Shaka 采样计算
  • 31.存储 - Data 1. HDFS + HBase 存储所有的 Raw Data，HDFS 存储所有的 Raw Data，HBase 存储简单的 索引 (Request ID + RPC ID => file + block offset + message Offset) 2. 64 KB Block + Snappy 3. Metrics Sampling (Metric Name + Tags + Timestamp) => Request ID/RPC ID)
  • 32.Metrics - LinDB 1. 采用 Metric + Tags + Fields 方式 2. 基于 Series Sharding，支持水平扩展 1.0 3. 自动的 Rollup，s->m->h->d 4. 高可靠性，支持多副本，支持跨机房 2.0 5. 自监控，数据治理 6. 列式存储，具有时序特性的 LSM 存储结构 7. 倒排索引 1. 抓住时序特性 2. 利用好这些数值 3. 系统是慢慢演进出来的 3.0 社区版 • RocksDB • 扩展 RocksDB • 自研存储 类LSM • 自研索引
  • 33.Metric - LinDB
  • 34.Metric - LinDB 时序数据特性（根据其时间特性可以分为不随时间变化和随时间变化的数据） 1. Time Series => Metric + Tags：这部分数据基本都是字符串，而且该数据占数据包的大头，但是不会随时间变化而变化， 尽量把字符串变换成数值来存储，以降低存储成本 2. Fields：这部分数据基本都是数值，并且随着时间变化而变化，但是数值类型容易做压缩 1. 36台服务器，分不同集群 2. 每天增量写入 140T 3. 高峰TPS:750 DPS/s 4. 10S 存 30天，历史可查2年以上 5. 磁盘占用 50T (压缩率在60倍左右) 6. 查询P99：500ms ~ 1s
  • 35.社区 参考 1.https://github.com/dianping/cat2.https://github.com/influxdata/influxdb3. Facebook gorilla 开源 1.https://github.com/lindb/lindb2.https://zhuanlan.zhihu.com/p/35998778
  • 36.
  • 37.