基于Metrics+Flume+Kafka+ES实现服务监控

背景

因为公司的RPC框架不支持HTTP的服务端,所以无法在服务管理平台实现基于HTTP的RPC调用的服务可视化治理,所以楼主基于现有的框架实现了一套自己的服务集群监控,因为本身框架不一定适应业务,所以楼主重写了框架里的个别类,具体后面会讲.

技术引进:

Metrics(vertx的开源子项目的一个分支,是天然的监控框架,本文核心也围绕这个展开)

Flume(日志采集工具,将日志落服务器,然后通过flume采集)

Kafka(现主流的消息中间件,这里不作复述,这里用到消费flume里面的日志)

ElasticSearch(基于Lucene的搜索服务器,因为楼主不是主要做索引,只是入门级别,基于es做了一个可视化的平台)

整体架构组成 :Metrics+Flume+kafka+ElasticSearch

Metrics

引用官网的介绍:作为一款监控指标的度量类库,它提供了很多模块可以为第三方库或者应用提供辅助统计信息, Metrics提供了Gauge、Counter、Meter、Histogram、Timer等度量工具类以及Health Check功能。(楼主本次因为业务的适应,本次用Meter和Timer)

Metrics提供了多种类型的

Meter:

用来计算事件的速率。 例如 request per second。 还可以提供1分钟,5分钟,15分钟不断更新的平均速率(具体打什么时间,可以重写,楼主自己就重写了),因为这里meter已经提供了统计次数的,所以如果统计一额接口的统计成功数,可以直接用这个,而不需要用counter那个度量类.

下图是官方的Demo:

基于Metrics+Flume+Kafka+ES实现服务监控_第1张图片

通俗的讲:

举个的例子,我想统计请求的次数,我只需要在调用方法后,调用meter的mark方法即可埋点.这个时候,就会在这次调用,使用后计数器加一,有些人说,我自己每次调用打一行日志也可以啊,但是!因为你如果是同步实时的打日志,在qps上万的情况下,你会发现你打日志的线程也占用了你资源,而且这样每次请求打一次,你会发现,你的磁盘也会出现瓶颈,当然,你也会说,我可以用log4j2采用异步打日志,如果你用过异步日志的时候,你会发现日志是隔一段时间打一次,而且当你清空日志的时候,还是会出现磁盘的阻塞.而Metics的打日志的时候,你可以完全自己设置打印时间,譬如30秒一次或者几分钟一次一样可以记录这时间段的服务情况.

现在是楼主自己的demo:


可以看出来,只要抛出一次,我在这调用这个mark方法,这个时候,metrics会自动统计你的失败次数,并在你设置的时间内打出来,因为楼主重写了他的log方式,方便es可视化,所以这里的日志是我的格式:


可以看出这个接口的名字,以及一天的总失败数,下图是一个失败次数的可视化展示,另外楼主还对一次RPC调用返回的结果集合也做了统计,这里就不截图了.

最后将服务器上的日志,flume进行日志采集,通过kafka配置topic消费到ES中,可视化后的结果如下:


基于Metrics+Flume+Kafka+ES实现服务监控_第2张图片

Timer 计时器

Timer是一个Meter和Histogram的组合。这个度量单位可以比较方便地统计请求的速率和处理时间。对于接口中调用的延迟等信息的统计就比较方便了。如果发现一个方法的RPS(请求速率)很低,而且平均的处理时间很长,那么这个方法八成出问题了。

同样,通这是里官方的一个Demo:


基于Metrics+Flume+Kafka+ES实现服务监控_第3张图片

上图中注释的地方就是你自己写的逻辑,譬如一次方法调用:

这里是楼主的自己业务的调用Demo:


基于Metrics+Flume+Kafka+ES实现服务监控_第4张图片

可以看到我每一次http的调用后,通过Timer的context进行埋点统计,这个就会记录,下图的数据,这里用网上的图,因为我自己重写了图2;


基于Metrics+Flume+Kafka+ES实现服务监控_第5张图片
图1

可以看到这里统计了调用次数,最大,最小的次数,以及平均数,中位数,以及TP75-TP99的时间.因为需要基于elasticSearch消费日志,所以楼主重写了那个report的类,如下:

下面是楼主重写的的上报类,里面可以支持传参数,以及你自己想要格式:

基于Metrics+Flume+Kafka+ES实现服务监控_第6张图片
图二

在日志中的表示如下:


最后同样把日志落FLume,通过kafka配置topic消费,如ES,可是化后的如下图:


基于Metrics+Flume+Kafka+ES实现服务监控_第7张图片

可以看到这里是可视化的监控,可以看服务的tp98的实时情况,当然可以根据自己的喜欢配置TP99,TP95的情况.



基于其他类型,楼主没有做过多的研究,直接引用官方的Demo:


基于Metrics+Flume+Kafka+ES实现服务监控_第8张图片

这个Gaugets最简单的度量指标,只有一个简单的返回值.比如,我们类型为Gauge的计数器来记录某个服务目前开通的城市个数

Metric.Gauge("Service Cities Count", () => Cities.Count, new Unit("个"));

Histogram 


基于Metrics+Flume+Kafka+ES实现服务监控_第9张图片

Histogram直方图是一种非常常见的统计图表,Metrics通过这个Histogram这个度量类型提供了一些方便实时绘制直方图.因为Timer已经集成了Histogram,而且两者的输出结果基本一致,而且Timer能返回一定的时间段,所以这里不作复述,个人可以根据喜好使用,为了形象,这里引用一个网上一个被copy了无数次的列子(也不知道真正的作者是谁)

基于Metrics+Flume+Kafka+ES实现服务监控_第10张图片
网上图

最后是初始化Meterics的Demo,这里的LmAsReport就是楼主自己重写的那个上报的类


基于Metrics+Flume+Kafka+ES实现服务监控_第11张图片

另外下面是官方的Demo:


基于Metrics+Flume+Kafka+ES实现服务监控_第12张图片

另外该框架还支持了其他类型的上报,譬如控制台,因为实际中我们大多数都是通过日志,所以这里不做其他类型的演示了.

附:对于框架的上报方法,可以自己进行重写,可以加上自己想要传递的参数,可以自行实现,因为本来框架源码就不多,所以可以进行自己修改重写.(楼主自己重写的类后续会传到gitbub)


因为也是第一次接触,所以后续会继续改进,另外也会进行自己的重写一些框架里的类目.相比这个框架也不陌生,如果上述有说错的地方,欢迎指正,一起学习.

你可能感兴趣的:(基于Metrics+Flume+Kafka+ES实现服务监控)