歡迎光臨
每天分享高質量文章

.NET Core 中使用 DiagnosticSource 記錄跟蹤信息

來自:Savorboard

鏈接:https://www.cnblogs.com/savorboard/p/8853734.html

前言

今天給大家講一下在 .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物件,IObservable接口大家應該都不陌生了吧,然後通過其Subscribe方法進行OnNext“回呼”關心的事件資料。

示例代碼:

static IDisposable networkSubscription = null;

// 使用 AllListeners 來獲取所有的DiagnosticListeners物件,傳入一個IObserver 回呼

static IDisposable listenerSubscription = DiagnosticListener.AllListeners.Subscribe(delegate (DiagnosticListener listener)

{

    // 當 DiagnosticsListener 激活的時候,這裡將獲得一個回呼用

    if (listener.Name == “System.Net.Http”)

    {

        // 訂閱者監聽消費代碼

        lock(allListeners)

        {

            if (networkSubscription != null)

                networkSubscription.Dispose();

            

            //回呼業務代碼

            Action> callback = (KeyValuePair evnt) =>

                Console.WriteLine(“From Listener {0} Received Event {1} with payload {2}”, networkListener.Name, evnt.Key, evnt.Value);

           

            //創建一個匿名Observer物件

            Observer> observer = new AnonymousObserver>(callback);

            

            //篩選你感興趣的事件

            Predicate 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# 的 客戶端驅動專案(https://github.com/OpenSkywalking/skywalking-csharp) ,這是一項非常具有挑戰性的工作,感興趣的同學可以 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事件。


●編號143,輸入編號直達本文

●輸入m獲取文章目錄

推薦↓↓↓

Web開發

更多推薦18個技術類公眾微信

涵蓋:程式人生、演算法與資料結構、黑客技術與網絡安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。

赞(0)

分享創造快樂