前言

最近我們公司的部分.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)
{
    
    
    
    services.AddOpenTracing();

    
    services.AddSingleton(serviceProvider =>
    {
        string serviceName = serviceProvider.GetRequiredService().ApplicationName;
        
        var loggerFactory = serviceProvider.GetRequiredService();
        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)
{
    
    services
        .AddEntityFrameworkSqlite()
        .AddDbContext(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");
    });
}

然後控制器上面就比較簡單了。

[HttpGet]
public async Task 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去呼叫上面的這個介面即可。

[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來解決上面的問題。

最後是本文的示例程式碼 https://github.com/catcherwong-archive/2019/tree/master/04/JaegerDemo

原文地址：https://www.cnblogs.com/catcher1994/p/10662999.html