ASP.NET Core使用Jaeger实现分布式追踪

时间  2019-11-13 标签 asp.net asp core 使用 jaeger 实现 分布式 追踪

前言

最近咱们公司的部分.NET Core的项目接入了Jaeger，也算是稍微完善了一下.NET团队的技术栈。git

至于为何选择Jaeger而不是Skywalking，这个问题我只能回答，大佬们说了算。github

前段时间也在CSharpCorner写过一篇相似的介绍
Exploring Distributed Tracing Using ASP.NET Core And Jaeger。sql

下面回到正题，咱们先看一下Jaeger的简介docker

Jaeger的简单介绍

Jaeger是Uber开源的一个分布式追踪的工具，主要为基于微服务的分布式系统提供监测和故障诊断。包含了下面的内容数据库

  • Distributed context propagation
  • Distributed transaction monitoring
  • Root cause analysis
  • Service dependency analysis
  • Performance / latency optimization

下面就经过一个简单的例子来体验一下。api

示例

在这个示例的话，咱们只用了jaegertracing/all-in-one这个docker的镜像来搭建，由于是本地的开发测试环境，不须要搭建额外的存储，这个感受仍是比较贴心的。缓存

咱们会用到两个主要的nuget包async

  1. Jaeger 这个是官方的client
  2. OpenTracing.Contrib.NetCore.Unofficial 这个是对.NET Core探针的处理，从opentracing-contrib/csharp-netcore这个项目移植过来的(这个项目并不活跃，只能本身作扩展)

而后咱们会建两个API的项目，一个是AService，一个是BService。分布式

其中BService会提供一个接口，从缓存中读数据，若是读不到就经过EF Core去从sqlite中读，而后写入缓存，最后再返回结果。ide

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来解决上面的问题。

最后是本文的示例代码

JaegerDemo

联系我们 沪ICP备13005482号-10