夜莺 默认支持的存储是从 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