对监控系统的思考

近期在做运维监控方面的事情,也研究了一下其他人是如何做的。把自己的想法做个总结记录一下吧。

监控期望的目标

  • 及时发现

需要的是即时监控并报警

  • 及时定位

定位问题要分开讲

  • 运维层面

    是机器硬件问题还是上面运行的基础服务的问题,或者是新上线代码的问题,需要回滚。

  • 代码层面

    在发生问题的时候,优先解决问题。定位代码问题提交hotfix 可以在解决问题之后做。

  • 及时处理
  • 提前预测(尽量减少问题的发生)

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

监控遇到的主要问题

  • 监控指标多

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

  • 监控报警多

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

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

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

多维度数据监控

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

  • 数据监控符合二八原则,重要数据需要多角度进行观察,需要有meta管理,需要动态简单配置。选择 好的,合理的数据模型可以有效的进行处理。

  • 数据采集部分,在单机器做聚合;命名上使用正则格式化;完善的配置功能,支持数据流自定义维度。

  • 对开源系统的使用,需要按照自己的实际情况进行适配。保证高可用性

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