Hangfire使用ApplicationInsigts监控
2018-04-09

起因

我司目前使用清真的ApplicationInsights来做程序级监控。(ApplicationInsights相关文档: https://azure.microsoft.com/zh-cn/services/application-insights/ )

其实一切都蛮好的,但是我们基于Hangfire的Job系统却无法被Ai所监控到,因为Ai它监控的原理是基于HttpModule对请求进行监控,而Hangfire则是通过轮询Storage(如Sql或者队列)来实现对Job的处理。

也就是说Hangfire理论上是没有任何对Hangfire站点本身的请求,它类似于自己一个while(true)死循环不断地轮询Storage拿到Job任务就执行。

关于Hangfire的系列可以参考官方的说明 http://docs.hangfire.io/en/latest/

虽说Hangfire自己有个Dashboard可以对Hangfire执行的任务进行监控,如下

但是一众的其他站点我全部在Azure的Portal里一目了然,就你一个Hangfire的要我跑到你自己家的Dashboard来看终归不爽,而且也容易忘,导致Hangfire站点常年处于被遗忘的角落。

最近发生了一个Hangfire站点因为某些外部原因没起来(宕掉)的事件之后更加速了要将Hangfire的监控统一到Ai里。

 

搜索

首先去github上找下有没相关解决方案,老实说觉得基于ApplicationInsights的第三方扩展还是蛮多的,在github搜ApplicationInsights相关的还是能搜索出好几页(https://github.com/topics/application-insights),但并没有找到我需要的。

然后google一下找到有人在hangfire论坛里问跟我类似的问题,然而也没有解决方案(https://discuss.hangfire.io/t/integrating-application-insights-appinsights-into-hangfire/3009)。

既然找不到,那干脆自己撸起袖子干。

 

开撸

首先我们回顾下ApplicationInsights默认自己监控的原理:

前文说了它有个HttpModule会在请求进来的创建一个RequestTelemetry,

并且会在线程上下文内创建个OperationId,然后在该Request的作用于内所有其他数据(如异常/Http请求/Sql请求)都会跟这个Id关联,

这个Id甚至会在你发送Http请求的时候附加在你的Http Header里,然后接收到该Http请求的站点假如也用了Ai的话会根据这个Header里的Id再进行二次关联(调用链路关联)。

 

先解决ApplicationInsights需要的相关基础知识

我们要自己在Hangfire里弄AI监控的话,其实重点就是怎么能让Request里的Id能传递到Hangfire里,然后在Hangfire一个操作的作用域里保持该Id一致(串联所有操作)。

那问题重点就清楚了,就是如何解决这个Id的问题。

 

那Ai自己是如何产生或者获取这个Id的呢,在Ai的2.4版本后引入了对System.Diagnostics.DiagnosticSource这个包的依赖。

所有的Id关联它都基于由此包提供的Activity这个类来事现,详情可以参考 http://apmtips.com/blog/2018/01/23/diagnosticssource-design-principles/ 

如果需要在自己系统里设置一个Id关联的系统的话也强烈推荐使用Activity这个类来进行处理。

别人实现的比自己弄的科学多了,之前我也自己用AsyncLocal来做过,但是后续也都替换成了Activity,

通过Activity.Current可以获取到当前的Activity实例,通过new Activity然后调用其Start方法也能快速启动一个Activity,

到此Ai相关所需要的知识就都准备妥当了。

 

然后解决Hangfire需要的相关基础知识

从Hangfire的角度来说,它只要提供2个功能支持就可以了。

在任务入队的时候,在数据里面要塞入在当前Request操作的Id,因为我要将Hangfire的操作能够跟Request里相关联起来。

在任务执行的时候,拿到任务数据的时候,要能取出这个Id,然后将这个Id通过Activity进行Start,然后再任务执行完之后要Stop掉这个Activity并释放掉。

(画的图”有点”丑,但大概就这个意思)

 

为了解决这个问题查找了下Hangfire全局过滤器相关的资料找到它有IServerFilter和IClientFilter这2个东西:

IServerFilter:服务端处理的过滤器,就是Hangfire Server在执行一个Job的时候要进行处理的过滤器,可在此位置给Hangfire的Job设置Ai的Id到上下文。

IClientFilter:客户端处理的过滤器,就是Hangfire Client在一个Job入队的时候要进行处理的过滤器,可在此位置将Request里的Id赋值给Job Data。

 

那在Client的时候如何解决每次都能自动塞个Id进去呢?

我的解决思路是定义个JobDtoBase,所有Hangfire任务的数据都要继承自这个类,里面就一个Id,然后通过IClientFilter在每次入队的时候都将当前Activity.Current.Id扔进去

(需要考虑Acitivity.Current为null的情况)

 

然后如何在Server端自动将这个Id来启动一个Activity并完成监控呢?

我是想着通过IServerFilter里通过PerformingContext里获取Job的参数然后用is来判断如果是JobDtoBase就取它的Id出来然后启动Activity并创建RequestTelemetry。

重点是在Server这边执行结束之后需要将RequestTelemetry和Activity释放掉,所以通过ThreadStatic的静态变量来对其保持引用。

 

效果

效果如何这个问题暂时我只能呵呵哒,因为也是刚折腾出来还没投入线上运行。

不过从测试环境来看,确实能抓到我hangfire的请求并在Ai里作为Request进行展示:

而且还能抓到依赖项跟”Request”的关联:

所以至少测试的情况来说应该是达到目的了,等之后投入线上后在看下最终具体效果。

原文地址 https://www.cnblogs.com/leolaw/p/8734822.html