监控系统 (一) : 设计

截止目前,我已经学习了很多技术,包括消息队列,logstash,Redis, Sharding-Jdbc,Elasticsearch, zipkin, hadoop生态圈。但是都只限于学,以至于很多时候在学习完之后不久就忘掉了。为了解决这个问题,我决定用当前所学习的知识去搭建一套消息监控系统,在复习自己的知识的同时,也给同事带来一点便捷。

系统要解决什么问题

当线上系统出现故障的时候主动通知对应系统负责人,以第一时间拿到错误信息进行修复。
故障包含但不限于:

  1. 业务异常 : 由我们定义的日志,例如请求超时。
  2. 技术异常 : error级别的日志,不在我们定义中的非业务异常,例如数组越界,空指针等。

通知的途径

  1. 钉钉通知 @负责人,已达到消息提示的目的。
  2. 邮件通知。
  3. 短信通知,但是短信不易过多,应当整合之后发送,否则在大批量出错的时候会让我们的短信比较杂乱。

系统设计

思路一

在一开始我的想法是,写一个Starter工具包,由各个小组依赖,在打印warn级别日志的时候,调用方法去通知。
缺点很明显:

  1. 与业务代码高度耦合,侵入性非常高。
  2. 如果想要监听新的异常需要修改代码,重新发布,不灵活。
  3. 需要思考如何编写才能对业务系统所在服务器的性能影响达到最低。
    这个方案在思考之后直接被pass。

    思路二

    专门开发一个监控系统。 架构如图:
    系统架构.png

  4. 由logstash去监听各个系统的日志,经过filter转换之后丢到消息队列中去。

  5. 监控系统监听指定topic,对消息进行消费。
  6. 发送到不同的监控工具中。

这个思路感觉还可以,

  1. 首先做到了无侵入。
  2. 因为使用了消息队列进行解耦,可以水平扩容。
  3. 监控规则可以由各个系统的开发人员自行定义。

问题

思路二带来的一些问题

  1. 规则在哪里进行配置,是通过logstash配置,还是在监控系统配置?
  2. 如何动态增加监控的系统?
  3. 当监控规则发生变化如何让监控系统做到实时感知?
  4. 钉钉的消息发送因为有20/m的限制,我们代码如何处理。
  5. 消息消费使用广播模式还是集群模式?
  6. topic与tag如何设计?