這篇文章主要給大家介紹了關於ASP.NET Core利用Jaeger實現分佈式追蹤的相關資料,文中通過示例代碼介紹的非常詳細,對大家學習或者使用ASP.NET Core具有一定的參考學習價值,需要的朋友們下面來一起學習學習吧
前言
最近我們公司的部分.NET Core的項目接入了Jaeger,也算是稍微完善了一下.NET團隊的技術棧。
至於爲什麼選擇Jaeger而不是Skywalking,這個問題我只能回答,大佬們說了算。
前段時間也在CSharpCorner寫過一篇類似的介紹
Exploring Distributed Tracing Using ASP.NET Core And Jaeger。
下面回到正題,我們先看一下Jaeger的簡介
Jaeger的簡單介紹
Jaeger是Uber開源的一個分佈式追蹤的工具,主要爲基於微服務的分佈式系統提供監測和故障診斷。包含了下面的內容
- Distributed context propagation
- Distributed transaction monitoring
- Root cause analysis
- Service dependency analysis
- Performance / latency optimization
下面就通過一個簡單的例子來體驗一下。
示例
在這個示例的話,我們只用了jaegertracing/all-in-one這個docker的鏡像來搭建,因爲是本地的開發測試環境,不需要搭建額外的存儲,這個感覺還是比較貼心的。
我們會用到兩個主要的nuget包
- Jaeger 這個是官方的client
- OpenTracing.Contrib.NetCore.Unofficial 這個是對.NET Core探針的處理,從opentracing-contrib/csharp-netcore這個項目移植過來的(這個項目並不活躍,只能自己做擴展)
然後我們會建兩個API的項目,一個是AService,一個是BService。
其中BService會提供一個接口,從緩存中讀數據,如果讀不到就通過EF Core去從sqlite中讀,然後寫入緩存,最後再返回結果。
AService 會通過HttpClient去調用BService的接口,從而會形成調用鏈。
開始之前,我們先把docker-compose.yml配置一下
version: '3.4' services: aservice: image: ${DOCKER_REGISTRY-}aservice build: context: . dockerfile: AService/Dockerfile ports: - "9898:80" depends_on: - jagerservice - bservice networks: backend: bservice: image: ${DOCKER_REGISTRY-}bservice build: context: . dockerfile: BService/Dockerfile ports: - "9899:80" depends_on: - jagerservice networks: backend: jagerservice: image: jaegertracing/all-in-one:latest environment: - COLLECTOR_ZIPKIN_HTTP_PORT=9411 ports: - "5775:5775/udp" - "6831:6831/udp" - "6832:6832/udp" - "5778:5778" - "16686:16686" - "14268:14268" - "9411:9411" networks: backend: networks: backend: driver: bridge
然後就在兩個項目的Startup加入下面的一些配置,主要是和Jaeger相關的。
public void ConfigureServices(IServiceCollection services) { // others .... // Adds opentracing services.AddOpenTracing(); // Adds the Jaeger Tracer. services.AddSingleton<ITracer>(serviceProvider => { string serviceName = serviceProvider.GetRequiredService<IHostingEnvironment>().ApplicationName; var loggerFactory = serviceProvider.GetRequiredService<ILoggerFactory>(); var sampler = new ConstSampler(sample: true); var reporter = new RemoteReporter.Builder() .WithLoggerFactory(loggerFactory) .WithSender(new UdpSender("jagerservice", 6831, 0)) .Build(); var tracer = new Tracer.Builder(serviceName) .WithLoggerFactory(loggerFactory) .WithSampler(sampler) .WithReporter(reporter) .Build(); GlobalTracer.Register(tracer); return tracer; }); }
這裏需要注意的是我們要根據情況來選擇sampler,演示這裏用了最簡單的ConstSampler。
回到BService這個項目,我們添加SQLite和EasyCaching的相關支持。
public void ConfigureServices(IServiceCollection services) { // Adds an InMemory-Sqlite DB to show EFCore traces. services .AddEntityFrameworkSqlite() .AddDbContext<BDbContext>(options => { var connectionStringBuilder = new SqliteConnectionStringBuilder { DataSource = ":memory:", Mode = SqliteOpenMode.Memory, Cache = SqliteCacheMode.Shared }; var connection = new SqliteConnection(connectionStringBuilder.ConnectionString); connection.Open(); connection.EnableExtensions(true); options.UseSqlite(connection); }); // Add EasyCaching Inmemory provider. services.AddEasyCaching(options => { options.UseInMemory("m1"); }); }
然後控制器上面就比較簡單了。
// GET api/values [HttpGet] public async Task<IActionResult> GetAsync() { var provider = _providerFactory.GetCachingProvider("m1"); var obj = await provider.GetAsync("mykey", async () => await _dbContext.DemoObjs.ToListAsync(), TimeSpan.FromSeconds(30)); return Ok(obj); }
AService就是通過HttpClient去調用上面的這個接口即可。
// GET api/values [HttpGet] public async Task<string> GetAsync() { var res = await GetDemoAsync(); return res; } private async Task<string> GetDemoAsync() { var client = _clientFactory.CreateClient(); var request = new HttpRequestMessage { Method = HttpMethod.Get, RequestUri = new Uri($"http://bservice/api/values") }; var response = await client.SendAsync(request); response.EnsureSuccessStatusCode(); var body = await response.Content.ReadAsStringAsync(); return body; }
到這裏的話,代碼這塊是ok了,下面就來看看效果。
先通過http://localhost:9898/api/values/訪問幾次AService
大概能得到一個這樣的結果
然後去Jaeger的界面上我們可以看到,兩個服務已經註冊上來了。
選A,B其中一個去搜索,就可以看到下面的結果
這個就最外層,能看到這些請求一些宏觀的信息。
我們選界面上最後一個,也就是第一個請求,進去看看細節
從上面這個圖大概也能看出來,做了一些什麼操作,請求來到AService,它就發起了HTTP請求到BService,BService則是先通過EasyCaching去取緩存,顯然緩存中沒數據,它就去讀數據庫了。
和另外的請求對比一下,可以發現是少了查數據庫這一步操作的。這也是爲什麼上面的是10個span,而下面的才8個。
再來看看兩個請求的對比圖。
上圖中那些紅色和綠色的塊就是兩個請求的差異點了。
回去看看其他細節,可以發現類似下面的內容
有很多日誌相關的東西,這些東西在這裏可能沒有太多實際的作用,我們可以通過調整日誌的級別來不讓它寫入到Jaeger中。
或者是通過下面的方法來過濾
services.AddOpenTracing(new System.Collections.Generic.Dictionary<string,LogLevel> { {"AService", LogLevel.Information} });
最後就是依賴圖了。
寫在最後
雖說Jaeger用起來挺簡單的,但是也是有點美中不足的,不過這個鍋不應該是Jaeger來背的,主要還是很多我們常用的庫沒有直接的支持Diagnostic,所以能監控到的東西還是略少。
不過在github發現了ClrProfiler.Trace這個項目,可以通過clrprofiler來解決上面的問題。
最後是本文的示例代碼
總結
以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,謝謝大家對神馬文庫的支持。