Nightingale 滴滴夜莺运维监控与 M3DB 联姻发版 3.3.1,DiDi&Uber...

UlricQin · 2020年12月23日 · 725 次阅读
本帖已被设为精华帖!

夜莺 默认支持的存储是从 Open-Falcon 演化过来的,基于 rrdtool 做的一套分布式时序数据存储方案,在滴滴内部抗住了单集群 10 亿量级的监控指标。后来美菜的朋友做了改造,让夜莺同时支持了 influxdb 作为后端存储,现在,3.3.1 版本,夜莺引入了 m3db,m3db 是 uber 开源的时序库,go 开发,据说在 uber 内部抗住了 66 亿指标,不清楚是单集群还是多集群,看起来还是挺牛掰的。

m3 相比原来的 index+tsdb 的方案,优劣势是什么?

优点

  • 对硬盘 IO 要求没那么高了,普通机械硬盘也能抗比较大的量
  • 存原始数据,不降采样了,追问题的时候更方便,当然了,存储的数据时长就变短了,相同硬盘空间大小,比如原来 rrd 可以存 1 年的历史趋势数据,m3 可能只能存 1 个月
  • 扩容非常方便,直接加 m3dbnode 即可,index+tsdb 的方案使用 migrate 配置,扩容不易
  • 容灾更好了,可以设置 3 副本,如果集群部署了 3 台机器,挂掉一台机器完全没有影响
  • 索引避免了原来 index+tsdb 的单点容量问题,原来 index 虽然是可以部署为集群,但是集群里每个节点都是全量索引

劣势

  • 硬盘空间占用大,毕竟存储原始数据嘛,一般生产环境建议存 1 个月,再久也尽量不要超过 3 个月,当然了,要监控的设备比较少,部署 m3 的机器硬盘又比较大,那另当别论
  • 内存占用比较多,一般配置是最近两个小时的数据要缓存在内存里,所以比较吃内存,好在内存现在也便宜了,一台机器动不动 128G、256G 的

Nightingale v3.3.1 具体更新内容如下:

前端

  • fix: 修复 IE11 兼容问题,目前支持 IE >= 11,Chrome >= 70
  • fix(mon): 修复屏蔽策略无法选择屏蔽节点问题
  • fix(mon): 修复某些日志采集修改会导致名称被切割问题
  • feat: 各个系统间添加快捷跳转链接
  • feat(mon): 监控大盘支持缓存该大盘设置的显示列数
  • style: 更新了一个新的 logo 图片
  • style(mon): 监控系统菜单重新归类

后端

  • 增强安全性:密码复杂度提高、cookie 处理优化等
  • 支持 M3DB 作为存储后端,具体请查看 github 上面的 wiki 介绍
  • 修复告警引擎与条件串数的问题
  • 为主机设备增加自定义字段的能力

代码根目录下有个 changelog,会罗列改动的内容和影响的模块,具体请诸君参考

更多原创文章干货分享,请关注公众号
  • 加微信实战群请加微信(注明:实战群):gocnio
astaxie 将本帖设为了精华贴 12月23日 14:08
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册