自定义监控系统实现的初步思考

Posted by AlstonWilliams on February 17, 2019

前一段时间做了一个App,出于完整性的考虑,打算做一个完整的平台,包括监控等.所以,现在重点就在做监控方面.

我们对监控系统的初步需求是:

  • 能够获取到网络延时较大的接口,包括调用时间,网络延时的大小,调用的接口名称
  • 能够显示出现错误的接口,包括接口的名称,传入的参数,调用时间等

为了实现这个监控系统,我们初步的打算是:

通过类Unix系统上提供的Logrotate工具,对服务器端日志进行切割,切割成log_{YY}{MM}{DD}.log的形式,然后通过Flume收集服务器端日志,发送给Storm,然后通过Storm进行数据的统计,然后让Storm通过WebSocket发送给前端WebUI.

然而,在实现时,遇到了几个问题.

首先,Flume的Source中,没有一个支持日志切换的Source.Flume中和我们的需求比较相似的有TailDirSource,它能够根据你配置的文件的过滤规则,实现当文件被修改了之后,发送那些添加的内容.而我们要求的Source,不仅需要具有当有日志追加到日志文件之后,将追加的日志发送出去的功能,还需要具有能够切换读取的日志的功能.比如说,今天是2017年08月04号,那么今天读取的日志就是log_2017_08_04.log,而到了明天,就要读取log_2017_08_05.log这个日志.

为了实现这个功能,我们在TailDirSource的基础上,进行了扩展,加上了切换读取的日志的功能.

另外,通过研究TailDirSource的实现,我们发现它是采用的IO的方式,每隔一秒便按照预先设定的批次尺寸读取特定数目的追加的文本.这样便会有一些问题.比如说,我们设定了读取的间隔是1s,然后每次读取的时候,是读取10w行文本.如果在这一秒中,增加了100w行文本,那么剩下的90w行文本,就得在下一次读取时才能被读取到.这样,随着时间的增长,积累的没有被读到的文本会越来越多.就达不到实时分析的目的了.

意识到这一点之后,我们对这部分的实现进行了改写,通过使用NIO的方式,使得每次有日志追加到日志文件时,触发读取操作,将追加的日志发送出去.

在将日志发送出去的时候,我们本来并没有打算加上Kafka这样一个消息队列,本来打算直接通过Flume的Thrift Sink直接连接到Storm的Thrift Spout,后来查看Flume的文档时,发现Flume的Thrift Sink好像只能发送数据给Flume的Thrift Source,这就很尴尬了.不得已,只好寻找其他的途径.发现Flume中有一个Kafka Sink,Storm中正好也有一个Kafka Spout,就打算这样来做.

后来,在阅读Kafka的日志的时候,发现Kafka中,提供了流处理的功能,是Kafka Stream API.论强大程度的话,我觉得肯定还是比不上Storm的,但是,对于我们这种很简单的用例,也能满足我们的需求了.于是,就将项目结构改成了下面的这种形式:

通过类Unix系统上提供的Logrotate工具,对服务器端日志进行切割,切割成log_{YY}{MM}{DD}.log的形式,然后通过Flume收集服务器端日志,发送给Kafka进行统计,然后通过WebSocket发送给前端WebUI.

这时,一个最大的问题摆在我们面前,就是Kafka并没有提供WebSocket的功能.Google之后,发现了一个方案是通过Reactive Steams + Akka Streams来实现,看了半天没看懂.就只能另避蹊径了.

最终结构图如下:

在上图中,我们可以看到,我们是把Kafka Consumer放到一个WebApplication中了.

这个结构图是我在参考了网络上一位朋友的代码之后,得出来的.在此之前,我一直一位写的跟Kafka相关的代码需要通过Kafka提供的kafka-run-class.sh脚本来运行,后来发现并不是这样.

这部分的具体实现,我会在后面的一篇文章中进行介绍.