夜莺 默认支持的存储是从 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，会罗列改动的内容和影响的模块，具体请诸君参考