前言 最新一直在忙著項目上的事情，很久沒有寫博客了，在這裡對關註我的粉絲們說聲抱歉，後面我可能更多的分享我們在微服務落地的過程中的一些經驗。那麼今天給大家講一下在 .NET Core 2 中引入的全新 DiagnosticSource 事件機制，為什麼說是全新呢？ 在以前的 .NET Framewo ...
前言
最新一直在忙著項目上的事情，很久沒有寫博客了，在這裡對關註我的粉絲們說聲抱歉，後面我可能更多的分享我們在微服務落地的過程中的一些經驗。那麼今天給大家講一下在 .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 有興趣的話可以關註我，我會定期的在博客分享我的學習心得。
本文地址：http://www.cnblogs.com/savorboard/p/diagnostics.html
作者博客：Savorboard
歡迎轉載，請在明顯位置給出出處及鏈接
