ASP.NET Core利用Jaeger实现分布式追踪详解
前言
最近我们公司的部分.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来解决上面的问题。
最后是本文的示例代码
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对的支持。