集群监控系统的设计方案

2019独角兽企业重金招聘Python工程师标准>>>

    背景

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

 

    一些原则   

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

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

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

 

    方案一

    

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

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

    

    方案二

       

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

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

 

    选择和原因

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

转载于:https://my.oschina.net/GameKing/blog/731852