近期在做运维监控方面的事情，也研究了一下其他人是如何做的。把自己的想法做个总结记录一下吧。
监控期望的目标
- 及时发现
需要的是即时监控并报警
- 及时定位
定位问题要分开讲
- 运维层面
是机器硬件问题还是上面运行的基础服务的问题，或者是新上线代码的问题，需要回滚。
- 代码层面
在发生问题的时候，优先解决问题。定位代码问题提交hotfix 可以在解决问题之后做。
- 及时处理
- 提前预测（尽量减少问题的发生）
提前预测可以做的事情有很多，数据挖掘/分析之类的。当然有个更简单的方法，就是先小范围上线，进行监控。如果发现出问题了，就停止上线，进行回滚。（我们现在就是这样做的，虽然原因并不是这个 2333
监控遇到的主要问题
- 监控指标多
服务器CPU,内存，网络等的指标，基础服务Redis, MongoDB等的运行指标，对外服务的API是否正常工作，还有数据是否正确等。
- 监控报警多
监控指标多的时候，自然报警也会相应增加，但是报警的分组与轻重缓急也是一个很麻烦的问题。还有就是部署着不同服务的机器，触发报警时候的指标也不好确定。
- 报警多而且有关联，如何查找原因
可能同时会有多个指标触发了报警，但是要定位问题的时候，如何可以快速的定位问题。
多维度数据监控
这个话题太大(要感谢Baidu的颜大大的指点）
- 数据监控符合二八原则,重要数据需要多角度进行观察，需要有meta管理，需要动态简单配置。选择 好的，合理的数据模型可以有效的进行处理。
- 数据采集部分，在单机器做聚合;命名上使用正则格式化;完善的配置功能，支持数据流自定义维度。
- 对开源系统的使用，需要按照自己的实际情况进行适配。保证高可用性
先写这些吧，之后有时间再写，还有QCon上对运维监控上的一些分享也非常值得思考