歡迎光臨
每天分享高質量文章

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)
{
    
    
    
    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請求到BServiceBService則是先透過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

已同步到看一看
贊(0)

分享創造快樂