前言

最新一直在忙著項目上的事情，很久沒有寫博客了，在這里對關(guān)注我的粉絲們說聲抱歉，后面我可能更多的分享我們在微服務(wù)落地的過程中的一些經(jīng)驗。那么今天給大家講一下在 .NET Core 2 中引入的全新 DiagnosticSource 事件機制，為什么說是全新呢？ 在以前的 .NET Framework 有心的同學(xué)應(yīng)該知道也有 Diagnostics，那么新的 .NET Core 中有什么變化呢？ 讓我們一起來看看吧。

Diagnostics

Diagnostics 一直是一個被大多數(shù)開發(fā)者忽視的東西，我猜測很多同學(xué)看到這里的時候可能還是第一次聽說 Diagnostics 這個東西，為什么會被忽視呢？ 我們等會說，我們先來看一下 Diagnostics 是用來做什么的。

Diagnostics 是什么呢？

讓我們把時間往前拉回到 2013 年 8 月，微軟在 NuGet 發(fā)布了一個新的關(guān)于 Diagnostics 的包叫做 Microsoft.Diagnostics.Tracing.TraceEvent，這個包用來為 Windows 事件追蹤（ETW）提供一個強大的支持，使用這個包可以很容易的為我們在云環(huán)境和生產(chǎn)環(huán)境來提供端到端的監(jiān)控日志事件記錄，它輕量級，高效，并且可以和系統(tǒng)日志進行交互。

PS：通過這個包我們可以獲取到 CLR 運行的一些細節(jié)信息，由于本篇主題，對此不介紹過多了。

看到這個包提供的功能，那么博主就自己總結(jié)一下，對 Diagnostics 下個定義 ：在應(yīng)用程序出現(xiàn)問題的時候，特別是出現(xiàn)可用性或者性能問題的時候，開發(fā)人員或者IT人員經(jīng)常會對這些問題花費大量的時間來進行診斷，很多時候生產(chǎn)環(huán)境的問題都無法復(fù)現(xiàn)，這可能會對業(yè)務(wù)造成很大的影響，Diagnostics 就是提供一組功能使我們能夠很方便的可以記錄在應(yīng)用程序運行期間發(fā)生的關(guān)鍵性操作以及他們的執(zhí)行時間等，使管理員可以查找特別是生產(chǎn)環(huán)境中出現(xiàn)問題所在的根本原因。

有同學(xué)可能會說了，這不就是 APM(Application Performance Management) 么，嗯，從宏觀的角度來說這屬于APM的一部分，但 APM 不僅僅只有這些。

.NET Framework 之 EventSource

在上面我們了解到了 Microsoft.Diagnostics.Tracing.TraceEvent，那么相關(guān)搭配使用的還有兩個 NuGet 包就是 Microsoft.Diagnostics.Tracing.EventSource 這個包，那我就簡單講一下，我不準備在這個部分講述太多，畢竟已經(jīng)被替換掉了，我們來看下 EventSource。

EventSource

在 .NET Framework 中 EventSource 通過 Windows ETW 提供的 ETW Channels 與其進行集成，下面給出一個示例代碼：

[EventSource(Name = "Samples-EventSourceDemos-Minimal")]
public sealed class MinimalEventSource : EventSource
{
    // Define singleton instance
    public static MinimalEventSource Log = new MinimalEventSource();

    // Define Event methods
    public void Load(long baseAddress, string imageName)
    {
        WriteEvent(1, baseAddress, imageName);
    }
}

那么在 ETW 中我們就可以看到相關(guān)的事件信息了：

注意，在 .NET Framework 4.5 以及更高版本，EventSource 已經(jīng)被集成到了 System 命名空間。

學(xué)習，也是一個總結(jié)的過程，對此，我們也許可以總結(jié)出來一個比較重要的信息就是：通過 Diagnostics 的命名空間變化，由 Microsoft 變?yōu)榱?System， 我們可以看到 Diagnostics 對于我們的應(yīng)用程序來說變得更加重要了。

由于 EventSource 只支持 Windows，所以在全新的 .NET Core 中，它已經(jīng)被悄悄的取代了，下面我們來看一下全新的 DiagnosticSource。

.NET Core 之 全新 DiagnosticSource

在 .NET Core 中 .NET 團隊設(shè)計了一個全新的 DiagnosticSource，新的 DiagnosticSource 非常的簡單，它允許你在生產(chǎn)環(huán)境記錄豐富的 payload 數(shù)據(jù)，然后你可以在另外一個消費者可以消費感興趣的記錄，是不是聽著有點懵逼？沒關(guān)系，等會我再詳細說。

我們先來說說 DiagnosticSource 和上面的 EventSource 的區(qū)別，他們的架構(gòu)設(shè)計有點類似，主要區(qū)別是 EventSource 它記錄的數(shù)據(jù)是可序列化的數(shù)據(jù)，會被在進程外消費，所以要求記錄的對象必須是可以被序列化的。而 DiagnosticSource 被設(shè)計為在進程內(nèi)處理數(shù)據(jù)，所以通過它可以拿到更加豐富的一些數(shù)據(jù)信息，它支持非序列化的對象，比如 HttpContext , HttpResponseMessage 等。如果你想在 EventSource 中獲取 DiagnosticSource 中的事件數(shù)據(jù)，你可以通過 DiagnosticSourceEventSource 這個對象來進行數(shù)據(jù)橋接。

下面我們來看一下在代碼中如何使用 DiagnosticSource對象。

在這之前我們需要了解另外一個對象 DiagnosticListener，DiagnosticListener 從命名上來看它是一個監(jiān)聽診斷信息的對象，它確實是一個用來接收事件的類，在 .NET Core 中 DiagnosticSource 它其實是一個抽象類，定義了記錄事件日志所需要的方法，那么我們在使用的時候就需要使用具體的對象，DiagnosticListener 就是 DiagnosticSource 的默認實現(xiàn)，明白了吧。

好了，現(xiàn)在我們來看一下如何使用吧。

生成 Diagnostic 日志記錄

如何生成 Diagnostic 日志記錄呢？首先，我們需要創(chuàng)建一個 DiagnosticListener 對象，比如：

private static DiagnosticSource httpLogger = new  DiagnosticListener("System.Net.Http");

DiagnosticListener 參數(shù)中的名稱即為需要監(jiān)聽的事件（組件）名稱，這個名稱在以后會被用來被它的消費者所訂閱使用。

DiagnosticSource 其核心只包含了兩個方法，分別是 ：

bool IsEnabled(string name)
void Write(string name, object value);

那么然后我們可以這樣來調(diào)用：

if (httpLogger.IsEnabled("RequestStart")){
    httpLogger.Write("RequestStart", new { Url="http://clr", Request=aRequest });
}

IsEnabled(string param1) 這個方法用來判斷是否有消費者注冊了當前的事件（組件）名稱監(jiān)聽，通常有消費者關(guān)心了相關(guān)數(shù)據(jù)，我們才會進行事件記錄。
Write(string param1,object param2) 這個方法用來向 DiagnosticSource 中寫入日志記錄，param1 和上面一樣用來指定名稱的，也就是所向指定名稱中寫入數(shù)據(jù)，param2 即為寫入的 payloads 數(shù)據(jù)，你可以使用 匿名類型來向 param2 中寫入數(shù)據(jù)，這樣會方便很多。

這樣，我們就已經(jīng)把 Diagnostic 事件日志寫入到 DiagnosticSource中了，是不是很簡單？ 我們再看一下如何進行消費（監(jiān)聽）這些事件信息。

監(jiān)聽 Diagnostic 日志記錄

在監(jiān)聽 Diagnostic 日志記錄之前你需要知道你要關(guān)心的事件數(shù)據(jù)名稱，那么如果僅僅是在代碼中把 DiagnosticListeners 都寫死到監(jiān)聽的消費者代碼中的話，這樣就太不靈活了，所以這里設(shè)計了一個機制用來發(fā)現(xiàn)中那些在運行時被激活的DiagnosticListeners。

你可以使用 DiagnosticListener.AllListeners 來獲取一個 IObservable<DiagnosticListener>對象，IObservable接口大家應(yīng)該都不陌生了吧（不太清楚的可以看這里），然后通過其Subscribe方法進行OnNext“回調(diào)”關(guān)心的事件數(shù)據(jù)。

示例代碼：

static IDisposable networkSubscription = null;

// 使用 AllListeners 來獲取所有的DiagnosticListeners對象，傳入一個IObserver<DiagnosticListener> 回調(diào)
static IDisposable listenerSubscription = DiagnosticListener.AllListeners.Subscribe(delegate (DiagnosticListener listener)
{
    // 當 DiagnosticsListener 激活的時候，這里將獲得一個回調(diào)用
    if (listener.Name == "System.Net.Http")
    {
        // 訂閱者監(jiān)聽消費代碼
        lock(allListeners)
        {
            if (networkSubscription != null)
                networkSubscription.Dispose();
            
            //回調(diào)業(yè)務(wù)代碼
            Action<KeyValuePair<string, object>> callback = (KeyValuePair<string, object> evnt) =>
                Console.WriteLine("From Listener {0} Received Event {1} with payload {2}", networkListener.Name, evnt.Key, evnt.Value);
           
            //創(chuàng)建一個匿名Observer對象
            Observer<KeyValuePair<string, object>> observer = new AnonymousObserver<KeyValuePair<string, object>>(callback);
            
            //篩選你感興趣的事件
            Predicate<string> predicate = (string eventName) => eventName == "RequestStart";
            
            networkSubscription = listener.Subscribe(observer, predicate);
        }
    }
});

// 通常情況下，這里你需要保持 listenerSubscription 始終處于激活狀態(tài)，
// 如果你像取消回調(diào)，你可以調(diào)用 listenerSubscription.Dispose() 來取消訂閱者

通過這種方式，我們就可以在觸發(fā)回調(diào)的之后做一些我們想要的操作了。

是不是發(fā)現(xiàn)上面的那種寫法有點麻煩和丑陋，ASP.NET 團隊考慮到了，所以為我們封裝了一個適配器的庫來方便我們進行監(jiān)聽的一些操作，你可以通過打 attribute 標記的方式來進行相關(guān)事件的訂閱，有興趣的同學(xué)可以看下這個（Microsoft.Extensions.DiagnosticAdapte） NuGet 包。

現(xiàn)在我們已經(jīng)可以拿到數(shù)據(jù)了，有同學(xué)可能會說在生產(chǎn)環(huán)境數(shù)據(jù)這么多，這些數(shù)據(jù)我存到哪里，又怎么樣來處理呢，我不可能一條一條的來找性能在哪里吧，OK，我們接著往下看。

為你的框架支持 Diagnostics

隨著微服務(wù)的流行，服務(wù)的鏈路追蹤以及應(yīng)用程序的性能問題變得越來越重要，而 APM 也成為了整個微服務(wù)架構(gòu)中很重要的一個中間件，它可以協(xié)助我們快速查找生產(chǎn)環(huán)境中所遇到的問題，以及在應(yīng)用程序發(fā)生異常的時候收集異常運行時的上下文信息來快速排查問題。

對 Google 的 Dapper 或者 OpenTracing 協(xié)議有了解的同學(xué)應(yīng)該已經(jīng)想到了，我們可以利用上面的那些數(shù)據(jù)按照這些協(xié)議的約定進行包裝，然后發(fā)送到支持這些協(xié)議的 APM 的服務(wù)端，剩下的工作是不是可以由這些服務(wù)端來幫助我們處理了，包括圖形化展示，性能查看，調(diào)用鏈查看等。

大多數(shù)的開源APM項目都支持 Dapper 或者 OpenTracing 協(xié)議，如 Apache SkyWalking , ZipKin，pinpoint 等。 順便說一句，我們 NCC開源項目組 的 Lemon 同學(xué)正在給 SkyWalking 寫 C# 的 客戶端驅(qū)動項目 ，這是一項非常具有挑戰(zhàn)性的工作，感興趣的同學(xué)可以 Star 一下。

相信閱讀本篇文章也有不少的架構(gòu)師，開源項目作者，框架開發(fā)者，甚至應(yīng)用程序開發(fā)者，那么我建議可以從現(xiàn)在開始對你的項目提供 Diagnostics 支持，目前 .NET Core 中 CoreFx , ASP.NET Core, EntityFramework Core 都已經(jīng)對 Diagnostics 提供了支持。

CAP 在 2.2 版本中已經(jīng)對 Diagnostics 提供了支持。

CAP 中的 Diagnostics

CAP: https://github.com/dotnetcore/CAP

CAP 是我的一個開源項目，用來處理在微服務(wù)或者SOA架構(gòu)中分布式事務(wù)的一個解決方案，你可以在這篇文章中看到更多關(guān)于 CAP 的介紹，喜歡的同學(xué)可以給個 Star ，也是我繼續(xù)做的更好的動力，謝謝。

CAP 對外提供的事件監(jiān)聽者名稱為： CapDiagnosticListener

CAP 中的 Diagnostics 提供對外提供的事件信息有：

• 消息持久化之前
• 消息持久化之后
• 消息持久化異常
• 消息向MQ發(fā)送之前
• 消息向MQ發(fā)送之后
• 消息向MQ發(fā)送異常
• 消息從MQ消費保存之前
• 消息從MQ消費保存之后
• 訂閱者方法執(zhí)行之前
• 訂閱者方法執(zhí)行之后
• 訂閱者方法執(zhí)行異常

相關(guān)涉及到的對象，你可以在 DotNetCore.CAP.Diagnostics 命名空間下看到。

基于這些對外的事件數(shù)據(jù)，我們可以來對接APM，下面這個是我對接的 ZipKin 的一個圖：

總結(jié)

通過本篇文章我們知道了 .NET Core 中為我們提供的一個新的事件數(shù)據(jù)記錄對象DiagnosticSource ，通過這個對象，我們可以對外提供一些診斷信息，以便于在生產(chǎn)環(huán)境中對我們的應(yīng)用程序進行性能問題排查和調(diào)用鏈跟蹤，然后我們知道了一下CAP對外提供的一些Diagnostics事件。

以上就是在 .NET Core 中使用 Diagnostics (Diagnostic Source) 記錄跟蹤信息的詳細內(nèi)容，更多關(guān)于.NET Core 記錄跟蹤信息的資料請關(guān)注腳本之家其它相關(guān)文章！