集群监控系统的设计方案

原创
2016/08/12 16:31
阅读数 614

    背景

     一个项目发展了一段时间以后,总会分成为数众多的子应用,各自以集群的形式部署在不同的服务器上。当部署的应用多了以后,整个集群的异常监控就成为一个比较麻烦的事情。最近接到的需求便是开发一个监控系统,监控所有子应用的抛出的异常信息,以及各种定时线程的执行情况等。

 

    一些原则   

    因为项目已经比较庞大了,所以这套监控系统对原有的各应用不能有太大的侵入性,代码的改动量不能太大。

    项目的子应用众多,设计监控方案时,要考虑通用性,尽量减少边际成本。

    整个项目的子应用分布在上百台服务器上,所以设计时应考虑到部署实施的简便性。

 

    方案一

    

    最开始考虑的方案,开发一个web服务器 monitor 和 触手 agent,把 agent 部署到所有的服务器上,通过分析指定目录下的日志文件获取该服务器上的所有应用运转情况。而相对应的,所有需要监控的子应用需要输出自身的错误日志 和 定时线程的执行日志到指定目录,配合监控。

    这个方案的好处是通过 agent 不单可以监控应用,还能做很多额外的事情,比如服务器内存负载监控,应用异常时的自动重启等等,还一个优点是跨语言,不局限于java;不足之处也很明显:部署和更新繁琐,代码侵入性略大,每个应用都需要新增大量的日志输出代码;而且agent多了以后,可能需要专门的运维来负责维护。

    

    方案二

       

    第二套方案仍然需要开发web服务器 monitor,但不再提供agent,转而提供一个监控注入组件 injectComponet。该组件提供一个扫描器,一个类修改器和几个注解,在java程序启动之初对所有类进行扫描,对配置了指定注解的类代码进行修改,添加自身的监控逻辑,从而跟踪应用的运行状况。同时修改 log4j 框架的日志基类,拷贝所有 error 级别日志,传回monitor进行分析。需要监控的子应用则需要添加相应的配置 和 注解以配合监控。

    这套方案的好处是侵入性小,边际成本低,不需要额外的运维操作。而不足之处则是功能薄弱,同时只支持java语言编写的应用程序。

 

    选择和原因

    综合考虑后采用了方案二,主要原因是服务器级别的监控已经有其它的运维系统负责,而且项目没有跨语言需求,这种情况下方案一的优点并不突出,而开销略大。

展开阅读全文
打赏
0
3 收藏
分享
加载中
GameKing博主

引用来自“老猫124”的评论

我觉得正好相反,方案一的侵入性低,方案二的侵入性高。
使用方案一,子应用基本不用改动,配置日志输出很简单,而且一般也是需要单独输出错误日志的。
而方案二,一是需要修改log4j,而log4j.jar是侵入子应用的,log4j会向monitor发送日志,试想如果monitor服务的地址变了,或者想在子应用和monitor中间加一个消息中间件,是不是需要子应用重新部署。而使用注解的方式更是侵入了子应用代码,倒是可以更准确的监控一些业务指标,但单轮侵入性来说,肯定是高了。
代码侵入性主要体现在 各种定时线程的执行情况 和 方法的调用频率 的监控上,方案一制定了统一的规范,需要在 监控的线程 和 方法 内部修改或新增 相应的日志,引起了不少强迫症的吐槽..方案二只需要加一行注解,侵入性会低点......
log4j 是在 编译时 或者 类加载之前 才被动态修改,子应用无感知....monitor的地址是域名....至于消息中间件,真要搞的话,无感知切换方案也不少啊
2016/11/16 16:49
回复
举报
我觉得正好相反,方案一的侵入性低,方案二的侵入性高。
使用方案一,子应用基本不用改动,配置日志输出很简单,而且一般也是需要单独输出错误日志的。
而方案二,一是需要修改log4j,而log4j.jar是侵入子应用的,log4j会向monitor发送日志,试想如果monitor服务的地址变了,或者想在子应用和monitor中间加一个消息中间件,是不是需要子应用重新部署。而使用注解的方式更是侵入了子应用代码,倒是可以更准确的监控一些业务指标,但单轮侵入性来说,肯定是高了。
2016/11/16 10:21
回复
举报
更多评论
打赏
2 评论
3 收藏
0
分享
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部