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包

1. Jaeger 這個是官方的client
2. 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來解決上面的問題。

最後是本文的示例代碼

JaegerDemo