.NET Core微服務之基於Exceptionless實現分散式日誌記錄
一、Exceptionless極簡介紹
Exceptionless 是一個開源的實時的日誌收集框架,它可以應用在基於 ASP.NET,ASP.NET Core,Web API,Web Forms,WPF,Console,ASP.NET MVC 等技術開發的應用程式中,並且提供了REST介面可以應用在 Javascript,Node.js 中。它將日誌收集變得簡單易用並且不需要了解太多的相關技術細節及配置,對於微服務架構的應用程式來說,統一的日誌收集系統的建立更是有必要。
二、Quick Start
2.1 官方建立一個賬號
2.2 建立專案
2.3 得到ApiKey
2.4 安裝Exceptionless.AspNetCore並進行配置
NuGet>Install-Package Exceptionless.AspNetCore
*.目前最新版本是4.3.2004
在你要進行Logging的專案(MVC,WebAPI等)中註冊APIKey,這裡以ASP.NET Core WebAPI專案為例:
public void Configure(IApplicationBuilder app, IHostingEnvironment env, IApplicationLifetime lifetime) { ...... app.UseMvc();// exceptionless app.UseExceptionless(Configuration["Exceptionless:ApiKey"]); // swagger ...... }
這裡我將ApiKey配置到了json配置檔案中:
"Exceptionless": { "ApiKey": "Your Api Key from Exceptionless server" }
2.5 簡單地封裝一個ExceptionlessLogger
(1)自定義一個ILogger介面
publicinterface ILogger { void Trace(string message, params string[] args); void Debug(string message, params string[] args); void Info(string message, params string[] args); void Warn(string message, params string[] args); void Error(string message, params string[] args); }
(2)實現ILogger介面:ExceptionlessLogger
public class ExceptionLessLogger : ILogger { /// <summary> /// Trace /// </summary> public void Trace(string message, params string[] tags) { ExceptionlessClient.Default.CreateLog(message, LogLevel.Trace).AddTags(tags).Submit(); } /// <summary> /// Debug /// </summary> public void Debug(string message, params string[] tags) { ExceptionlessClient.Default.CreateLog(message, LogLevel.Debug).AddTags(tags).Submit(); } /// <summary> /// Info /// </summary> public void Info(string message, params string[] tags) { ExceptionlessClient.Default.CreateLog(message, LogLevel.Info).AddTags(tags).Submit(); } /// <summary> /// Warn /// </summary> public void Warn(string message, params string[] tags) { ExceptionlessClient.Default.CreateLog(message, LogLevel.Warn).AddTags(tags).Submit(); } /// <summary> /// Error /// </summary> public void Error(string message, params string[] tags) { ExceptionlessClient.Default.CreateLog(message, LogLevel.Error).AddTags(tags).Submit(); } }
2.6 注入ExceptionlessLogger
public IServiceProvider ConfigureServices(IServiceCollection services) { // IoC - Logger services.AddSingleton<ILogger, ExceptionLessLogger>(); ...... }
2.7 在你想要Logging的地方呼叫
比如我們要記錄一個User登入的日誌:
public class LoginController : Controller { public ILogger Logger { get; } public LoginController(ILogger logger) { Logger = logger; } [HttpGet("{id}")] public string Get(int id) { Logger.Info($"User {id} Login Successfully. Time:{DateTime.Now.ToString()}", "Tag1", "Tag2"); return "Login Success."; } }
測試結果:
2.8 記錄你程式中的各種Exception
這裡模擬一個空指標的異常,這裡藉助Exceptionless針對Exception類的擴充套件方法去進行寫異常資訊。
[HttpGet] public string Get() { try { string str = null; str.ToString(); } catch (Exception ex) { ex.ToExceptionless().Submit(); } return "Unknown Error!"; }
測試結果:
2.9 Check你的日誌與異常記錄
(1)Check 日誌
在Log Messages 或 AllEvents選單中選擇Dashboard,即可看到當前專案所有的Log Message了。(如果選擇的是AllEvents,可能還會包含其他型別的資訊,比如Exception)
在最近的Log中可以看到我們剛剛的測試中記錄的一跳日誌:
點選超連結,即可進入詳細頁面:
Overview:可以看到一些專案和日誌的基本資訊,比如Event Type,Level以及標籤Tags
Environment:可以看到記錄日誌所在的專案所處的一些軟硬體環境資訊
下面是一些額外的資訊,比如Framework Version以及Runtime Framework
通過對這些日誌的檢視和分析,我們可以方便地在一個地方對所有服務中的日誌進行檢視和分析。But,線上版本對專案和日誌數量有限制,建議在生產環境使用本地部署版本,它是開源的。
(2)Check 異常
在Exception選單下選擇Dashboard:
在最近的異常資訊中找到剛剛記錄的:
同樣,通過超連結檢視詳細資訊:
Overview:可以看到這個異常的基本資訊,比如Error Type以及Stack Trace,這些都是可以幫準我們快速定位錯誤的資訊
Exception:如果基本資訊不夠,那就檢視詳情,你可能需要看看載入了哪些Modules
最後是Environment,跟Log的Environment差不多,這裡就不再貼圖了。
三、本地部署
我們說到Exceptionless是一款強大的開源框架,那麼我們可以下載下來根據需要進行獨立部署,可以不受一些使用者、專案、Event數量的限制。這裡我暫時不會去做其獨立部署的實踐,但是園子裡已經有很多的獨立部署實踐的分享了,有興趣的朋友可以看看下面幾篇:
以下是測試環境的要求:
以下是Production環境的要求,我們可以看到在Production環境中,強烈推薦使用ELK的ElasticSearch,如果有不知道ELK的朋友也可以百度/Google一下,ELK也是我後續的學習計劃。
四、小結
本篇主要簡單的介紹了一下開源的分散式日誌框架Exceptionless,並通過兩個小例子介紹瞭如何快速的在ASP.NET Core中進行使用,最後通過在Exceptionless平臺中Check我們在程式中記錄的日誌/異常資訊瞭解Exceptionless的強大。此外,通過引入園友和官方的Wiki文件介紹了Exceptionless的另一種使用模式:本地部署,有興趣的朋友可以去看看,這裡我就不再去實踐了(對我現階段而言,去做獨立部署的優先順序不高)。本篇沒有過多的語言介紹,更多的是貼code以及貼圖片,因此不能算是很好的介紹文章,不過結合列出的參考資料應該可以對Exceptionless做個快速入門。
一些朋友問我後續的分享計劃,這裡小小透漏一下:Ocelot+IdentityServer的結合做統一驗證和授權,Ocelot+Butterfly的結合(目前Ocelot已整合Butterfly)做分散式追蹤,基於AppMetrics+InfluxDB+Grafana的效能監控,資料一致性(可能會使用幾個EventBus框架)初探,基於Apollo做配置中心,ASP.NET Core on Docker與K8S結合等等。等到POC初步研究後,可能還會去看看微軟的微服務架構官方高階版大Demo-eShopOnContainers(微軟有一本pdf大家可以去下載,點我下載)。這些計劃可能需要花費我很多時間,不過我相信這樣的學習和實踐是值得的,也是值得分享的,如果你也有這樣的計劃,那就一起加油吧!
參考資料
作者:周旭龍
本文版權歸作者和部落格園共有,歡迎轉載,但未經作者同意必須保留此段宣告,且在文章頁面明顯位置給出原文連結。
相關推薦
.NET Core微服務之基於Exceptionless實現分散式日誌記錄
一、Exceptionless極簡介紹 Exceptionless 是一個開源的實時的日誌收集框架,它可以應用在基於 ASP.NET,ASP.NET Core,Web API,Web Forms,WPF,Console,ASP.NET MVC 等技術開發的應用程式中,並且提供了REST介面可以應
.NET Core微服務之基於Consul實現服務治理
請求轉發 1.0 asp.net AC port prefix 我們 tle nan 一、Consul基礎介紹 Consul是HashiCorp公司推出的開源工具,用於實現分布式系統的服務發現與配置。與其他分布式服務註冊與發現的方案,比如 Airbnb的Smart
.NET Core微服務之基於Consul實現服務治理(續)
shell pla code tst 分層 編輯 set req \n 上一篇發布之後,這一篇把上一篇沒有弄到的東西補一下,也算是給各位前來詢問的朋友的一些回復吧。一、Consul服務註冊之配置文件方式1.1 重溫Consul實驗集群 這裏我們有三個Consul Serv
基於Apollo實現.NET Core微服務統一配置(測試環境-單機) .NET Core微服務之基於Apollo實現統一配置中心
一、前言 注:此篇只是為測試環境下的快速入門。後續會給大家帶來生產環境下得實戰開發。 具體的大家可以去看官方推薦。非常的簡單明瞭。以下介紹引用官方內容: Apollo(阿波羅)是攜程框架部門研發的分散式配置中心,能夠集中化管理應用不同環境、不同叢集的配置,配置修改後能夠實時推送到應用端,並且具
.NET Core微服務之基於Apollo實現統一配置中心
一、關於統一配置中心與Apollo 在微服務架構環境中,專案中配置檔案比較繁雜,而且不同環境的不同配置修改相對頻繁,每次釋出都需要對應修改配置,如果配置出現錯誤,需要重新打包釋出,時間成本較高,因此需要做統一的配置中心,能做到自動更新配置檔案資訊,解決以上問題。 Apollo(阿波羅)是攜
.NET Core微服務之基於Ocelot實現API閘道器服務
一、啥是API閘道器? API 閘道器一般放到微服務的最前端,並且要讓API 閘道器變成由應用所發起的每個請求的入口。這樣就可以明顯的簡化客戶端實現和微服務應用程式之間的溝通方式。以前的話,客戶端不得不去請求微服務A(假設為Customers),然後再到微服務B(假設為Orders),然後是微服
.NET Core微服務之基於MassTransit實現資料最終一致性(Part 2)
一、案例結構與說明 在上一篇中,我們瞭解了MassTransit這個開源元件的基本用法,這一篇我們結合一個小案例來了解在ASP.NET Core中如何藉助MassTransit+Quartz.Net來實現資料的最終一致性。當然,實現資料的最終一致性有很多方案,這裡只是舉一種我所學到的比較簡單易於學習
.NET Core微服務之基於MassTransit實現資料最終一致性(Part 1)
一、預備知識:資料一致性 關於資料一致性的文章,園子裡已經有很多了,如果你還不瞭解,那麼可以通過以下的幾篇文章去快速地瞭解瞭解,有個感性認識即可。 必須要了解的點:ACID、CAP、BASE、強一致性、弱一致性、最終一致性。 CAP理論由加州大學伯克利分校的計算機
.NET Core微服務之基於Ocelot實現API閘道器服務(續)
一、負載均衡與請求快取 1.1 負載均衡 為了驗證負載均衡,這裡我們配置了兩個Consul Client節點,其中ClientService分別部署於這兩個節點內(192.168.80.70與192.168.80.71)。 為了更好的展示API Repsonse來自哪個節點,我們更改一下
.NET Core微服務之基於Steeltoe使用Eureka實現服務註冊與發現
一、關於Steeltoe與Spring Cloud Steeltoe is an open source project that enables .NET developers to implement industry standard best practices when b
.NET Core微服務之基於Steeltoe整合Zuul實現統一API閘道器
一、關於Spring Cloud Zuul API Gateway(API GW / API 閘道器),顧名思義,是出現在系統邊界上的一個面向API的、序列集中式的強管控服務,這裡的邊界是企業IT系統的邊界。 Zuul 是Netflix 提供的一個開源元件,致力於在雲平臺上提供動態路由,監
.NET Core微服務之基於Steeltoe使用Zipkin實現分散式追蹤
一、關於Spring Cloud Sleuth與Zipkin 在 SpringCloud 之中提供的 Sleuth 技術可以實現微服務的呼叫跟蹤,也就是說它可以自動的形成一個呼叫連線線,通過這個連線線使得開發者可以輕鬆的找到所有微服務間關係,同時也可以獲取微服務所耗費的時間, 這樣就可以進行微服
.NET Core微服務之基於Jenkins+Docker實現持續部署(Part 1)
一、CI, CD 與Jenkins 網際網路軟體的開發和釋出,已經形成了一套標準流程,最重要的組成部分就是持續整合(Continuous integration,簡稱 CI) => 持續整合指的是,頻繁地(一天多次)將程式碼整合到主幹。 它的好處主要有兩個: 快速發現錯
.NET Core微服務之基於App.Metrics+InfluxDB+Grafana實現統一效能監控
一、關於App.Metrics+InfluxDB+Grafana 1.1 App.Metrics App.Metrics是一款開源的支援.NET Core的監控外掛,它還可以支援跑在.NET Framework上的應用程式(版本 >= 4.5.2)。官方文件地址:https://ww
.NET Core微服務之基於Polly+AspectCore實現熔斷與降級機制
一、熔斷、降級與AOP 1.1 啥是熔斷? 在廣義的解釋中,熔斷主要是指為控制股票、期貨或其他金融衍生產品的交易風險,為其單日價格波動幅度規定區間限制,一旦成交價觸及區間上下限,交易則自動中斷一段時間(“熔即斷”),或就此“躺平”而不得超過上限或下限(“熔而不斷”)。 而對於微服務來說,
.NET Core微服務之基於Ocelot+Butterfly實現分散式追蹤
一、什麼是Tracing? 微服務的特點決定了功能模組的部署是分散式的,以往在單應用環境下,所有的業務都在同一個伺服器上,如果伺服器出現錯誤和異常,我們只要盯住一個點,就可以快速定位和處理問題,但是在微服務的架構下,大部分功能模組都是單獨部署執行的,彼此通過匯流排互動,都是無狀態的服務,這種架構下,
.NET Core微服務之基於Ocelot+IdentityServer實現統一驗證與授權
一、案例結構總覽 這裡,假設我們有兩個客戶端(一個Web網站,一個移動App),他們要使用系統
.NET Core微服務之基於Steeltoe使用Hystrix熔斷保護與監控
一、關於Spring Cloud Hystrix 在微服務架構中,我們將系統拆分為很多個服務,各個服務之間通過註冊與訂閱的方式相互依賴,由於各個服務都是在各自的程序中執行,就有可能由於網路原因或者服務自身的問題導致呼叫故障或延遲,隨著服務的積壓,可能會導致服務崩潰。為了解決這一系列的問題
.NET Core微服務之基於Steeltoe使用Spring Cloud Config統一管理配置
一、關於Spring Cloud Config 在分散式系統中,每一個功能模組都能拆分成一個獨立的服務,一次請求的完成,可能會呼叫很多個服務協調來完成,為了方便服務配置檔案統一管理,更易於部署、維護,所以就需要分散式配置中心元件了,在Spring Cloud中,就有這麼一個分散式配置中心元件 —
.NET Core微服務之基於IdentityServer建立授權與驗證服務(續)
上一篇我們基於IdentityServer4建立了一個AuthorizationServer,並且繼承了QuickStartUI,能夠成功獲取Token了。這一篇我們瞭解下如何整合API Service和MVC Web Application。 一、整合API Service 1.1 新增ASP.NE