在 .NET Core 中使用 Diagnostics (Diagnostic Source) 記錄跟蹤信息

前言

最新一直在忙著項目上的事情，很久沒有寫博客瞭，在這裡對關註我的粉絲們說聲抱歉，後面我可能更多的分享我們在微服務落地的過程中的一些經驗。那麼今天給大傢講一下在 .NET Core 2 中引入的全新 DiagnosticSource 事件機制，為什麼說是全新呢？ 在以前的 .NET Framework 有心的同學應該知道也有 Diagnostics，那麼新的 .NET Core 中有什麼變化呢？ 讓我們一起來看看吧。

Diagnostics

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

Diagnostics 是什麼呢？

讓我們把時間往前拉回到 2013 年 8 月，微軟在 NuGet 發佈瞭一個新的關於 Diagnostics 的包叫做 Microsoft.Diagnostics.Tracing.TraceEvent，這個包用來為 Windows 事件追蹤（ETW）提供一個強大的支持，使用這個包可以很容易的為我們在雲環境和生產環境來提供端到端的監控日志事件記錄，它輕量級，高效，並且可以和系統日志進行交互。

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

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

有同學可能會說瞭，這不就是 APM(Application Performance Management) 麼，嗯，從宏觀的角度來說這屬於APM的一部分，但 APM 不僅僅隻有這些。

.NET Framework 之 EventSource

在上面我們瞭解到瞭 Microsoft.Diagnostics.Tracing.TraceEvent，那麼相關搭配使用的還有兩個 NuGet 包就是 Microsoft.Diagnostics.Tracing.EventSource 這個包，那我就簡單講一下，我不準備在這個部分講述太多，畢竟已經被替換掉瞭，我們來看下 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 中我們就可以看到相關的事件信息瞭：

註意，在 .NET Framework 4.5 以及更高版本，EventSource 已經被集成到瞭 System 命名空間。

學習，也是一個總結的過程，對此，我們也許可以總結出來一個比較重要的信息就是：通過 Diagnostics 的命名空間變化，由 Microsoft 變為瞭 System， 我們可以看到 Diagnostics 對於我們的應用程序來說變得更加重要瞭。

由於 EventSource 隻支持 Windows，所以在全新的 .NET Core 中，它已經被悄悄的取代瞭，下面我們來看一下全新的 DiagnosticSource。

.NET Core 之 全新 DiagnosticSource

在 .NET Core 中 .NET 團隊設計瞭一個全新的 DiagnosticSource，新的 DiagnosticSource 非常的簡單，它允許你在生產環境記錄豐富的 payload 數據，然後你可以在另外一個消費者可以消費感興趣的記錄，是不是聽著有點懵逼？沒關系，等會我再詳細說。

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

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

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

好瞭，現在我們來看一下如何使用吧。

生成 Diagnostic 日志記錄

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

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

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

DiagnosticSource 其核心隻包含瞭兩個方法，分別是 ：

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

那麼然後我們可以這樣來調用：

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

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

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

監聽 Diagnostic 日志記錄

在監聽 Diagnostic 日志記錄之前你需要知道你要關心的事件數據名稱，那麼如果僅僅是在代碼中把 DiagnosticListeners 都寫死到監聽的消費者代碼中的話，這樣就太不靈活瞭，所以這裡設計瞭一個機制用來發現中那些在運行時被激活的DiagnosticListeners。

你可以使用 DiagnosticListener.AllListeners 來獲取一個 IObservable<DiagnosticListener>對象，IObservable接口大傢應該都不陌生瞭吧（不太清楚的可以看這裡），然後通過其Subscribe方法進行OnNext“回調”關心的事件數據。

示例代碼：

static IDisposable networkSubscription = null;

// 使用 AllListeners 來獲取所有的DiagnosticListeners對象，傳入一個IObserver<DiagnosticListener> 回調
static IDisposable listenerSubscription = DiagnosticListener.AllListeners.Subscribe(delegate (DiagnosticListener listener)
{
    // 當 DiagnosticsListener 激活的時候，這裡將獲得一個回調用
    if (listener.Name == "System.Net.Http")
    {
        // 訂閱者監聽消費代碼
        lock(allListeners)
        {
            if (networkSubscription != null)
                networkSubscription.Dispose();
            
            //回調業務代碼
            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);
           
            //創建一個匿名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 始終處於激活狀態，
// 如果你像取消回調，你可以調用 listenerSubscription.Dispose() 來取消訂閱者

通過這種方式，我們就可以在觸發回調的之後做一些我們想要的操作瞭。

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

現在我們已經可以拿到數據瞭，有同學可能會說在生產環境數據這麼多，這些數據我存到哪裡，又怎麼樣來處理呢，我不可能一條一條的來找性能在哪裡吧，OK，我們接著往下看。

為你的框架支持 Diagnostics

隨著微服務的流行，服務的鏈路追蹤以及應用程序的性能問題變得越來越重要，而 APM 也成為瞭整個微服務架構中很重要的一個中間件，它可以協助我們快速查找生產環境中所遇到的問題，以及在應用程序發生異常的時候收集異常運行時的上下文信息來快速排查問題。

對 Google 的 Dapper 或者 OpenTracing 協議有瞭解的同學應該已經想到瞭，我們可以利用上面的那些數據按照這些協議的約定進行包裝，然後發送到支持這些協議的 APM 的服務端，剩下的工作是不是可以由這些服務端來幫助我們處理瞭，包括圖形化展示，性能查看，調用鏈查看等。

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

相信閱讀本篇文章也有不少的架構師，開源項目作者，框架開發者，甚至應用程序開發者，那麼我建議可以從現在開始對你的項目提供 Diagnostics 支持，目前 .NET Core 中 CoreFx , ASP.NET Core, EntityFramework Core 都已經對 Diagnostics 提供瞭支持。

CAP 在 2.2 版本中已經對 Diagnostics 提供瞭支持。

CAP 中的 Diagnostics

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

CAP 是我的一個開源項目，用來處理在微服務或者SOA架構中分佈式事務的一個解決方案，你可以在這篇文章中看到更多關於 CAP 的介紹，喜歡的同學可以給個 Star ，也是我繼續做的更好的動力，謝謝。

CAP 對外提供的事件監聽者名稱為： CapDiagnosticListener

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

• 消息持久化之前
• 消息持久化之後
• 消息持久化異常
• 消息向MQ發送之前
• 消息向MQ發送之後
• 消息向MQ發送異常
• 消息從MQ消費保存之前
• 消息從MQ消費保存之後
• 訂閱者方法執行之前
• 訂閱者方法執行之後
• 訂閱者方法執行異常

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

基於這些對外的事件數據，我們可以來對接APM，下面這個是我對接的 ZipKin 的一個圖：

總結

通過本篇文章我們知道瞭 .NET Core 中為我們提供的一個新的事件數據記錄對象DiagnosticSource ，通過這個對象，我們可以對外提供一些診斷信息，以便於在生產環境中對我們的應用程序進行性能問題排查和調用鏈跟蹤，然後我們知道瞭一下CAP對外提供的一些Diagnostics事件。

以上就是在 .NET Core 中使用 Diagnostics (Diagnostic Source) 記錄跟蹤信息的詳細內容，更多關於.NET Core 記錄跟蹤信息的資料請關註WalkonNet其它相關文章！

推薦閱讀：

• .NET Core使用CZGL.SystemInfo庫獲取主機運行資源
• .NET Core、Xamarin、.NET Standard和.NET Framework四者之間的區別介紹
• 在.Net Framework應用中請求HTTP2站點的問題解析
• .Net Core讀取文件時中文亂碼問題的解決方法分享
• RxJava實戰之訂閱流基本原理示例解析