ASP.NET Core使用Jaeger实现分布式追踪
前言
最近我們公司的部分.NET Core的項(xiàng)目接入了Jaeger,也算是稍微完善了一下.NET團(tuán)隊(duì)的技術(shù)棧。
至于為什么選擇Jaeger而不是Skywalking,這個(gè)問題我只能回答,大佬們說了算。
前段時(shí)間也在CSharpCorner寫過一篇類似的介紹
Exploring Distributed Tracing Using ASP.NET Core And Jaeger。
下面回到正題,我們先看一下Jaeger的簡(jiǎn)介
Jaeger的簡(jiǎn)單介紹
Jaeger是Uber開源的一個(gè)分布式追蹤的工具,主要為基于微服務(wù)的分布式系統(tǒng)提供監(jiān)測(cè)和故障診斷。包含了下面的內(nèi)容
Distributed context propagation
Distributed transaction monitoring
Root cause analysis
Service dependency analysis
Performance / latency optimization
下面就通過一個(gè)簡(jiǎn)單的例子來體驗(yàn)一下。
示例
在這個(gè)示例的話,我們只用了jaegertracing/all-in-one這個(gè)docker的鏡像來搭建,因?yàn)槭潜镜氐拈_發(fā)測(cè)試環(huán)境,不需要搭建額外的存儲(chǔ),這個(gè)感覺還是比較貼心的。
我們會(huì)用到兩個(gè)主要的nuget包
Jaeger?這個(gè)是官方的client
OpenTracing.Contrib.NetCore.Unofficial?這個(gè)是對(duì).NET Core探針的處理,從opentracing-contrib/csharp-netcore這個(gè)項(xiàng)目移植過來的(這個(gè)項(xiàng)目并不活躍,只能自己做擴(kuò)展)
然后我們會(huì)建兩個(gè)API的項(xiàng)目,一個(gè)是AService,一個(gè)是BService。
其中BService會(huì)提供一個(gè)接口,從緩存中讀數(shù)據(jù),如果讀不到就通過EF Core去從sqlite中讀,然后寫入緩存,最后再返回結(jié)果。
AService?會(huì)通過HttpClient去調(diào)用BService的接口,從而會(huì)形成調(diào)用鏈。
開始之前,我們先把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
然后就在兩個(gè)項(xiàng)目的Startup加入下面的一些配置,主要是和Jaeger相關(guān)的。
public void ConfigureServices(IServiceCollection services){
services.AddOpenTracing();
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;
});
}
這里需要注意的是我們要根據(jù)情況來選擇sampler,演示這里用了最簡(jiǎn)單的ConstSampler。
回到BService這個(gè)項(xiàng)目,我們添加SQLite和EasyCaching的相關(guān)支持。
public void ConfigureServices(IServiceCollection services){
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);
});
services.AddEasyCaching(options =>
{
options.UseInMemory("m1");
});
}
然后控制器上面就比較簡(jiǎn)單了。
[]
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去調(diào)用上面的這個(gè)接口即可。
[]
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
大概能得到一個(gè)這樣的結(jié)果
然后去Jaeger的界面上我們可以看到,兩個(gè)服務(wù)已經(jīng)注冊(cè)上來了。
選A,B其中一個(gè)去搜索,就可以看到下面的結(jié)果
這個(gè)就最外層,能看到這些請(qǐng)求一些宏觀的信息。
我們選界面上最后一個(gè),也就是第一個(gè)請(qǐng)求,進(jìn)去看看細(xì)節(jié)
從上面這個(gè)圖大概也能看出來,做了一些什么操作,請(qǐng)求來到AService,它就發(fā)起了HTTP請(qǐng)求到BService,BService則是先通過EasyCaching去取緩存,顯然緩存中沒數(shù)據(jù),它就去讀數(shù)據(jù)庫(kù)了。
和另外的請(qǐng)求對(duì)比一下,可以發(fā)現(xiàn)是少了查數(shù)據(jù)庫(kù)這一步操作的。這也是為什么上面的是10個(gè)span,而下面的才8個(gè)。
再來看看兩個(gè)請(qǐng)求的對(duì)比圖。
上圖中那些紅色和綠色的塊就是兩個(gè)請(qǐng)求的差異點(diǎn)了。
回去看看其他細(xì)節(jié),可以發(fā)現(xiàn)類似下面的內(nèi)容
有很多日志相關(guān)的東西,這些東西在這里可能沒有太多實(shí)際的作用,我們可以通過調(diào)整日志的級(jí)別來不讓它寫入到Jaeger中。
或者是通過下面的方法來過濾
services.AddOpenTracing(new System.Collections.Generic.Dictionary<string,LogLevel>{
{"AService", LogLevel.Information}
});
最后就是依賴圖了。
寫在最后
雖說Jaeger用起來挺簡(jiǎn)單的,但是也是有點(diǎn)美中不足的,不過這個(gè)鍋不應(yīng)該是Jaeger來背的,主要還是很多我們常用的庫(kù)沒有直接的支持Diagnostic,所以能監(jiān)控到的東西還是略少。
不過在github發(fā)現(xiàn)了ClrProfiler.Trace這個(gè)項(xiàng)目,可以通過clrprofiler來解決上面的問題。
最后是本文的示例代碼?https://github.com/catcherwong-archive/2019/tree/master/04/JaegerDemo?
原文地址:https://www.cnblogs.com/catcher1994/p/10662999.html
.NET社區(qū)新聞,深度好文,歡迎訪問公眾號(hào)文章匯總 http://www.csharpkit.com
總結(jié)
以上是生活随笔為你收集整理的ASP.NET Core使用Jaeger实现分布式追踪的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: .net core webapi 前后端
- 下一篇: ASP.NET Core 进程内(InP