前言
最近我們公司的部分.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這個是官方的clientOpenTracing.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來解決上面的問題。
最后是本文的示例代碼