在.NET中使用DiagnosticSource的方法

前言

diagnosticsource是一个非常有意思的且非常有用的api，对于这些api它们允许不同的库发送命名事件，并且它们也允许应用程序订阅这些事件并处理它们，它使我们的消费者可以在运行时动态发现数据源并且订阅与其相关的数据源。

diagnosticsource在aspnetcore、entityframeworkcore、httpclient、sqlclient中被使用，在我们实际的开发过程中他使我们能够进行拦截请求与响应的http请求、数据库查询、对httpcontext、dbconnection、dbcommand、httprequestmessageand等对象的访问，甚至说在需要的时候我们可以进行修改这些对象来处理我们的业务。

下面我们将通过如下的简单示例来了解它.

diagnosticsource和eventsource区别

diagnosticsource和eventsource在架构设计上很相似，他们的主要区别是eventsource它记录的数据是可序列化的数据，会被进程外消费，所以要求记录的对象必须是可以被序列化的。而diagnosticsource被设计为在进程内处理数据，所以我们通过它拿到的数据信息会比较丰富一些，它支持非序列化的对象，比如httpcontext、httpresponsemessage等。另外如果想在eventsource中获取diagnosticsource中的事件数据，可以通过diagnosticsourceeventsource这个对象来进行数据桥接。

需求来了

为了更好的理解diagnosticsource的工作方式，如下这个示例将拦截数据库请求，假设我们有一个简单的控制台应用程序，它向数据库发出请求并将结果输出到控制台。

我们再来思考一下，假设来了一个需求：我们需要获取到所有数据库查询的执行时间，或者说我们要进行获取执行的一些sql语句或者数据进行存储作为记录我们该如何处理？
好了下面我们将尝试使用diagnosticsource来实现该需求。

使用system.diagnostics.diagnosticsource

来吧，我们先来创建一个类作为该事件的处理程序或者说作为该事件的消费者。

下面我们将处理该事件，我们需要将这个类进行实例化，并且将它注册到静态对象中的观察器中diagnosticlistener.alllisteners，代码如下所示：

下面我们再来修改我们的examplediagnosticobserver类，其实如上代码片段中编译器已经提醒我们要实现接口iobserver<diagnosticslistener>，下面我们实现它

接下来我们运行该程序，结果将在控制台进行打印如下所示：

sqlclientdiagnosticlistener
sqlclientdiagnosticlistener
42

看如上结果，这意味着在我们当前这个应用程序中的某个地方注册了两个类型为diagnosticlistener的对象，名字为sqlclientdiagnosticlistener。

对于应用程序中创建的每个实例diagnosticslistener，在第一次使用时将调用iobserver<diagnosticlistener>.onnext方法一次，现在我们只是将实例的名称输出到了控制台中，但实际情况中我们想一下，我们应该对这个实例名称做什么？对，没错，我们要对这些实例名称做检查，那么我们如果要对这个实例中某些事件，我们只需要使用subscribe方法去订阅它。

下面我们来实现iobserver<diagnosticlistener>：

在如上代码片段中我们实现了接口iobserver<keyvaluepair<string, object>>的iobserver<keyvaluepair<string，object>>.onnext的方法，参数为keyvaluepair<string，object>，其中key是事件的名称，而value是一个匿名对象.

运行程序输出结果如下所示：

system.data.sqlclient.writeconnectionopenbefore
{ operationid = f5f4d4f0-7aa1-46e6-bd48-78acca3dac0a, operation = openasync, connection = system.data.sqlclient.sqlconnection, timestamp = 1755845041766 }

system.data.sqlclient.writecommandbefore
{ operationid = 3d8617d1-0317-4f75-bffd-5b0fddf5cc12, operation = executereaderasync, connectionid = 554f4ee4-47c3-44ff-a967-cc343d1d5019, command = system.data.sqlclient.sqlcommand }

system.data.sqlclient.writeconnectionopenafter
{ operationid = f5f4d4f0-7aa1-46e6-bd48-78acca3dac0a, operation = openasync, connectionid = 554f4ee4-47c3-44ff-a967-cc343d1d5019, connection = system.data.sqlclient.sqlconnection, statistics = system.data.sqlclient.sqlstatistics+statisticsdictionary, timestamp = 1755851869508 }

system.data.sqlclient.writecommandafter
{ operationid = 3d8617d1-0317-4f75-bffd-5b0fddf5cc12, operation = executereaderasync, connectionid = 554f4ee4-47c3-44ff-a967-cc343d1d5019, command = system.data.sqlclient.sqlcommand, statistics = system.data.sqlclient.sqlstatistics+statisticsdictionary, timestamp = 1755853467664 }

system.data.sqlclient.writeconnectionclosebefore
{ operationid = ed240163-c43a-4394-aa2d-3fede4b27488, operation = close, connectionid = 554f4ee4-47c3-44ff-a967-cc343d1d5019, connection = system.data.sqlclient.sqlconnection, statistics = system.data.sqlclient.sqlstatistics+statisticsdictionary, timestamp = 1755854169373 }

system.data.sqlclient.writeconnectioncloseafter
{ operationid = ed240163-c43a-4394-aa2d-3fede4b27488, operation = close, connectionid = 554f4ee4-47c3-44ff-a967-cc343d1d5019, connection = system.data.sqlclient.sqlconnection, statistics = system.data.sqlclient.sqlstatistics+statisticsdictionary, timestamp = 1755854291040 }

42

如上结果可以清楚的看到里面存在6个事件，我们可以看到两个是在打开数据库之前和之后执行的，两个是在执行命令之前和之后执行的，还有两个是在关闭数据库连接之前和之后执行的。

另外可以看到每个事件中都包含一组参数，如operationid、operation、connectionid等，这些参数通常作为匿名对象属性传输，我们可以通过反射来获取这些属性的类型化的值。

现在我们解决了我们最初的需求，获取数据库中所有查询的执行时间，并将其输出到控制台中，我们需要进行修改，代码如下所示：

在这我们将拦截数据库中查询的开始和结束事件，在执行之前我们创建并且启动stopwatch，将其存储在asynclocal<stopwatch>中，以后面将其返回，在执行完成后，我们获取之前启动的stopwatch，停止它，通过反射从参数值中获取执行命令，并将结果输出到控制台。

执行结果如下所示：

commandtext: select 42;
elapsed: 00:00:00.1509086

42

现在我们已经解决了我们的需求，但是目前还存在一个小的问题，当我们订阅事件diagnosticlistener时，我们从它里面将接收到所有的事件，包括我们不需要的事件，但是呢发送的每个事件都会创建一个带有参数的匿名对象，这会在gc上造成额外的压力。

我们需要解决如上的问题，避免我们去处理所有的事件，我们需要指定predicate<string>这个特殊的委托类型，我们声明isenabled方法，在此筛选对应名称的消费者。

下面我们修改一下方法iobserver<diagnosticlistener>.onnext

现在我们只会对事件system.data.sqlclient.writecommandbefore和system.data.sqlclient.writecommandafter调用write方法。

使用microsoft.extensions.diagnosticadapter

上面虽然我们实现了需求，但是我们也可以发现我们从diagnosticlistener接收到的事件参数通常作为匿名对象传递，因此通过反射去处理这些参数这样给我们造成了比较昂贵的消耗，不过开发团队也考虑到了该问题向我们提供了microsoft.extensions.diagnosticadapter来完成我们的操作。

下面我们需要将subscribe改为subscribewithadapter,另外在这种情况下我们不需要实现iobserver<keyvaluepair<string, object>>接口，相反的是我们需要为每个事件声明一个单独的方法，并且使用[diagnosticnameattribute]特性去标注

如下所示：

现在我们实现了对数据执行的监控或者说拦截功能，同时也能为我们的数据库执行时间做记录，并且特别注意的是我们并没有对应用程序本身做修改，这样也减轻了很多的冗余，同时节省了大量的编码时间。这是一个很不错的编程体验。

创建diagnosticlistener实例

在大多数情况下，我们对diagnosticsource都会去订阅已经存在的事件，基本我们都不需要去创建自己的diagnosticlistener去发送事件，当然去了解一下这一特性也是比较好的，请继续往下看

创建自己的实例

发送事件，我们将调用write进行写入事件

参考

https://github.com/dotnet/corefx/blob/master/src/system.diagnostics.diagnosticsource/src/diagnosticsourceusersguide.md

https://sudonull.com/post/3671-using-the-diagnosticsource-in-net-core-theory

https://github.com/hueifeng/blogsample/tree/master/src/diagnosticdemo

到此这篇关于在.net中使用diagnosticsource的方法的文章就介绍到这了,更多相关.net使用diagnosticsource内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！