微信运维监控 —— 海量监控数据上报及存储设计实践

2020-02-27 189浏览

  • 1.微信运维监控 —— 海量监控数据上报及存储设计实践 微信运维中心 陈晓鹏
  • 2.如果运维监控数据处理太慢…
  • 3.微信后台系统现状 60000 40000 20000 0 2011 2012 2013 2014 2015 2016 2015 2016 服务器 6000 4000 2000 0 2011 2012 2013 2014 模块
  • 4.微信监控日志上报量 —— 1万亿/min 14000 12000 10000 8000 6000 4000 2000 0 2011 2012 2013 2014 亿/min 2015 2016
  • 5.l 存储容量不够 l 统计延迟严重 每分钟万亿级监控数据，如何上报、汇总？
  • 6.微信监控数据存储量 —— 2亿/min 2.5 2 1.5 1 0.5 0 2011 2012 2013 2014 亿/min 2015 2016
  • 7.l 如何进一步提高TSDB的读性能？ 每分钟亿级时间序列数据，如何实现存储， 如何保证N年跨度的数据读取性能？
  • 8.微信轻量监控数据上报框架
  • 9.常见监控数据上报/汇总方案 日志上报 网络压力 hdfs 存储空间 分布式计算 统计延迟
  • 10.常见监控数据上报/汇总方案 日志上报 hdfs 本地统计 日志格式多样 统计消耗 放弃日志这种上报形式！ 分布式计算
  • 11.微信后台轻量数据上报框架 l 数据分类 业务数据 —— 复杂、高延迟 监控数据 —— 简单、低延迟 l 简化监控数据 统一数据格式 简化计算规则 —— 累加、平均
  • 12.统一数据格式 l ID  Key  Value： • ID： 0  ~  128k-1 • Key： 0  ~  127 • Value： uint32_t
  • 13.轻量上报/汇总框架 共享内存 • type  __sync_fetch_and_add (type  *ptr,  type  value)   • bool __sync_bool_compare_and_swap (type  *ptr,  type  oldval,  type  newval) • 支持计算规则：累加、设置新值、设置最大值
  • 14.轻量上报/汇总框架 l CPU消耗极小 l 可实现秒级、实时数据采集 l 可简化数据存储、汇总
  • 15.微信高性能监控数据存储
  • 16.监控数据（时间序列）特点 l 数据格式： Key  +  Time  +  Value l 数据量大： 1天 =  1440min， 2亿/min  =  2880亿/天 l 大量读取历史数据
  • 17.时序数据库设计思路 原始数据 （分钟级） 内存缓存 小时级/天 级数据 Key映射 关系数据库 历史数据 缓存 KV存储 l 历史数据查询性能不足 l 数据缓存命中率不高 l 复杂关系数据查询效率低
  • 18.多维度Key的作用 1 4 6 5 7 2 3 l 当4失败总数上升时，如何定位故障机器、接口？ 调用数 A模块 A1机器 à B模块 B2机器 X1接口 失败数 耗时
  • 19.提高历史数据查询性能 l 定制能快速查找历史数据的index： • 分表、按时间分区 • 每个分区独立生成index
  • 20.旧版微信监控数据存储 CREATE  TABLE  `idkey_0`  ( 分表 `time`  int(10)  unsigned  NOT  NULL, `key1`  int(10)  unsigned  NOT  NULL, Key  *  n `key2`  int(10)  unsigned  NOT  NULL, `key3`  int(10)  unsigned  NOT  NULL, `v0`  bigint(20)  unsigned  DEFAULT  '0', `v1`  bigint(20)  unsigned  DEFAULT  '0', Value  *  720 ... `v718`  bigint(20)  unsigned  DEFAULT  '0', `v719`  bigint(20)  unsigned  DEFAULT  '0', PRIMARY  K EY  (`key1`,`key2`,`key3`,`time`), KEY  (`key3`,`key2`,`key1`,`time`) )  ENGINE=MyISAM 多index，支持全匹 配、前置匹配 PARTITION  BY  RANGE  (time) 分区 (PARTITION  P20150327  VALUES  LESS  THAN  (1427414400)  ENGINE   =  MyISAM, PARTITION  P20150330  VALUES  LESS  THAN  (1427673600)  ENGINE  =  MyISAM, ... );   写200w/min，读100w/min
  • 21.微信新版存储方案 原始数据 实时写入 小时分区 (mmap) 优化写入结构 每小时批量flush 日分区index 日分区data 每天离线压缩 压缩日分区index 压缩日分区data 定制简化的index  +  data文件结构， 提供高性能的全匹配、前置匹配查询
  • 22.小时分区（mmap）结构 l 1个meta文件 +  N个data文件组成 l 每个data文件大小固定，使用mmap映射 不同key同一分钟 的数据相邻，减少 单次flush数据量。
  • 23.日分区（压缩/未压缩）文件结构 l 1个meta  +  1个index  +  1个data文件 index文件 Index  1 Index  .. Index  N Key都是整形， 可以简化index 处理 data文件 Key  1  +  Data  1 Key  2  +  Data  2 Key  N  +  Data  N 简化读写处理
  • 24.index算法 —— 折中查找 l 全匹配查询： 11 12 13 21 22 23 31 32 33 2* 2* 3* 3* 3* l 前置匹配查询： 1* 1* 1* 2*
  • 25.原始数据 实时写入 小时分区 (mmap) 每分钟更新 每小时批量flush 日分区index 日分区data 每天离线压缩 压缩日分区index 压缩日分区data
  • 26.数据读取流程 data缓存 index缓存 读请求 压缩/未压缩日分区 index 压缩/未压缩日分区 data 小时分区 (mmap) sum/group 计算
  • 27.单机性能 l 写性能： 小时分区(mmap)： 1kw/s    (6亿/min) 未压缩日分区： 35w/s    (12.6亿/hour) l 读性能（单分区100w条记录）： 未压缩data性能： 30w/s 压缩data性能： 110w/s
  • 28.