新專案採用的abp vnext的微服務模組化架構,所以把應用的服務拆成了很多獨立模組
在初期,我們通過紀錄檔還能跟蹤到問題,
後期服務越來越多(大約擴充到了十幾個),隨著呼叫鏈路越來越深
,問題也越來越難排查了.
往往入口報錯之後,要跟好幾個服務的紀錄檔 才能找到最終節點.
所以考慮引入Skywalking鏈路跟蹤服務,來監聽整個應用
以下內容為照葫蘆畫瓢,覺得寫的不錯,所以就CV了~
Skywalking是一款分散式鏈路追蹤元件
那麼什麼是鏈路追蹤?
隨著微服務架構的流行,服務按照不同的維度進行拆分,一次請求往往需要涉及到多個服務。網際網路應用構建在不同的軟體模組集上,這些軟體模組,有可能是由不同的團隊開發、可能使用不同的程式語言來實現、有可能布在了幾千臺伺服器,橫跨多個不同的資料中心。
所以微服務面臨了這些問題:
某個核心服務掛了,導致大量報錯,如何快速確定哪裡出了問題?
使用者請求響應延遲高,怎麼確定是哪些服務導致的?
應用程式有效能瓶頸,怎樣確定瓶頸在哪裡?
如何準實時的瞭解應用部署環境(CPU、記憶體、程序、執行緒、網路、頻寬)情況,以便快速擴容/縮容、流量控制、業務遷移
如何統計各個呼叫的效能指標,比如:吞吐量(TPS)、響應時間及錯誤記錄等
分散式鏈路跟蹤系統就是為了解決這些問題應運而生。
Skywalking有哪些功能?
1. 多種監控手段。可以通過語言探針和 service mesh 獲得監控資料。
2.多個語言自動探針。包括 Java,.NET Core 和 Node.JS。
3.輕量高效。無需巨量資料平臺,和大量的伺服器資源。
4.模組化。UI、儲存、叢集管理都有多種機制可選。
5.支援告警。
6.優秀的視覺化解決方案。
Skywalking的整體架構圖
這裡說明一下.Skywalking容器裡本身是自帶H2資料庫的並支援持久化的,如果想簡化部署,可以直接使用
這裡ES推薦使用7.10版本,因為7.11以上的版本 授權協定變更了 可能有法律風險
docker run -d -p 9200:9200 -p 9300:9300 --name es -e "discovery.type=single-node" -e ES_JAVA_OPTS="-Xms128m -Xmx256m" -v /home/elasticsearch/data:/usr/share/elasticsearch/data elasticsearch:7.10.1
上面的命令是執行一個基礎的ES資料庫,並將資料持久化到宿主機 /home/elasticsearch/data,各位可以根據自己情況 自行更改
docker run --name skywalking-oap --restart always -p 11800:11800 -p 12800:12800 -d -e TZ=Asia/Shanghai -e SW_ES_USER= -e SW_ES_PASSWORD= -e SW_STORAGE=elasticsearch -e SW_STORAGE_ES_CLUSTER_NODES=ES資料庫地址:9200 -v /etc/localtime:/etc/localtime:ro apache/skywalking-oap-server:9.6.0
docker run -d --name skywalking-ui --restart always -p 8080:8080 -e TZ=Asia/Shanghai -e SW_OAP_ADDRESS=http://這裡填寫skywalking-oap的地址:12800 -v /etc/localtime:/etc/localtime:ro apache/skywalking-ui:9.6.0
這樣,我們就完成了基本的skywalking服務的搭建
在.NET中接入Skywalking,主要使用 SkyAPM.Agent.AspNetCore 這個開源代理
SkyAPM.Agent.AspNetCore採用了IHostingStartup介面通過探針的形式進行接入
所以對應用的入侵性很小,幾乎為0.所以接入資料很簡單
我們只需要三步即可
1.給服務的宿主層新增參照:
SkyAPM.Agent.AspNetCore
2.然後新增環境變數:
ASPNETCORE_HOSTINGSTARTUPASSEMBLIES=SkyAPM.Agent.AspNetCore (PS:如果有其他的攔截,這裡的環境變數可以設定多個,通過逗號分隔)
3.新增Skywalking設定項,建立skyapm.json檔案:
(PS:這裡不一定要建立skyapm.json檔案,也可以把設定寫在appsettings.json裡,研究過代理工具的原始碼,他也讀取了appsettings的設定)
類似如下:
{ "SkyWalking": { "ServiceName": "asp-net-core-backend", //服務名 "Namespace": "", "HeaderVersions": [ "sw8" ], "Sampling": { "SamplePer3Secs": -1, "Percentage": -1.0, "LogSqlParameterValue": false }, "Logging": { "Level": "Information", "FilePath": "logs/skyapm-{Date}.log" }, "Transport": { "Interval": 3000, "ProtocolVersion": "v8", "QueueSize": 30000, "BatchSize": 3000, "gRPC": { "Servers": "localhost:11800", //指向SkywalkingOAP的地址 "Timeout": 100000, "ConnectTimeout": 100000, "ReportTimeout": 600000 } } } }
由於可能線上的資料量很大,所以除了代理類自行監聽的紀錄檔以外
我們還可以通過程式碼自行新增Tag和Log,方便跟蹤查詢
可以通過依賴注入的形式,拿到IEntrySegmentContextAccessor物件,進行標記和紀錄檔記錄
程式碼如下:
private readonly IEntrySegmentContextAccessor _segContext; public Test(IEntrySegmentContextAccessor segContext = null) { _segContext = segContext; } public void Doing() { _segContext.Context.Span.AddLog(LogEvent.Message(""));//記錄紀錄檔 _segContext.Context.Span.AddTag("lowsql", "lowsql");//記錄標籤 }
可以在此基礎上自行擴充套件,比如加到ActionFilterAttribute攔截裡面進行跟蹤攔截
最後,我們來看看效果:
鏈路情況:
這樣,我們就能很方便的知道哪個服務呼叫了哪些服務,執行了哪些SQL操作了..