对监控系统的思考

监控期望的目标

• 及时发现

需要的是即时监控并报警

• 及时定位

定位问题要分开讲

• 运维层面 是机器硬件问题还是上面运行的基础服务的问题，或者是新上线代码的问题，需要回滚。
• 代码层面 在发生问题的时候，优先解决问题。定位代码问题提交hotfix 可以在解决问题之后做。
• 及时处理
• 提前预测（尽量减少问题的发生）

提前预测可以做的事情有很多，数据挖掘/分析之类的。当然有个更简单的方法，就是先小范围上线，进行监控。如果发现出问题了，就停止上线，进行回滚。（我们现在就是这样做的，虽然原因并不是这个 2333

监控遇到的主要问题

• 监控指标多

服务器CPU,内存，网络等的指标，基础服务Redis, MongoDB等的运行指标，对外服务的API是否正常工作，还有数据是否正确等。

• 监控报警多

监控指标多的时候，自然报警也会相应增加，但是报警的分组与轻重缓急也是一个很麻烦的问题。还有就是部署着不同服务的机器，触发报警时候的指标也不好确定。

• 报警多而且有关联，如何查找原因

可能同时会有多个指标触发了报警，但是要定位问题的时候，如何可以快速的定位问题。

多维度数据监控

这个话题太大(要感谢Baidu的颜大大的指点）

• 数据监控符合二八原则,重要数据需要多角度进行观察，需要有meta管理，需要动态简单配置。选择 好的，合理的数据模型可以有效的进行处理。
• 数据采集部分，在单机器做聚合;命名上使用正则格式化;完善的配置功能，支持数据流自定义维度。
• 对开源系统的使用，需要按照自己的实际情况进行适配。保证高可用性

先写这些吧，之后有时间再写，还有QCon上对运维监控上的一些分享也非常值得思考