手把手教你學Dapr - 9. 可觀測性

MASA技術團隊發表於2022-01-20

目錄

手把手教你學Dapr - 1. .Net開發者的大時代

手把手教你學Dapr - 2. 必須知道的概念

手把手教你學Dapr - 3. 使用Dapr執行第一個.Net程式

手把手教你學Dapr - 4. 服務呼叫

手把手教你學Dapr - 5. 狀態管理

手把手教你學Dapr - 6. 釋出訂閱

手把手教你學Dapr - 7. Actors

手把手教你學Dapr - 8. 繫結

手把手教你學Dapr - 9. 可觀測性

介紹

通過Tracing(跟蹤)、Metrics(指標)、Logs(日誌)和Health(執行狀況)監控應用程式。

分散式跟蹤

Dapr 使用 Zipkin 協議進行分散式跟蹤 和 Metrics 收集。由於 Zipkin 協議的普遍性，許多後端都是開箱即用的，例如 Stackdriver、Zipkin、New Relic 等。結合 OpenTelemetry Collector，Dapr 可以將跟蹤匯出到許多其他後端，包括但不限於 Azure Monitor、Datadog、Instana、Jaeger 和 SignalFX。

Tracing設計

Dapr 在 Dapr Sidecar 中新增了一個 HTTP/gRPC 中介軟體。中介軟體攔截所有 Dapr 和應用程式流量，並自動注入關聯 ID 以跟蹤分散式事務。這種設計有幾個好處：

  • 無需程式碼檢測。使用可配置的跟蹤級別自動跟蹤所有流量。
  • 跨微服務的一致性跟蹤行為。跟蹤是在 Dapr Sidecar 上配置和管理的，因此它在由不同團隊製作並可能用不同程式語言編寫的服務之間保持一致。
  • 可配置和可擴充套件。利用 Zipkin API 和 OpenTelemetry Collector，Dapr 跟蹤可以配置為與流行的跟蹤後端一起使用，包括客戶可能擁有的自定義後端。
  • 您可以同時定義和啟用多個匯出器。

W3C 關聯 ID

Dapr 使用標準的 W3C 跟蹤上下文標頭。對於 HTTP 請求，Dapr 使用 traceparent 標頭。對於 gRPC 請求，Dapr 使用 grpc-trace-bin 標頭。當一個沒有跟蹤 ID 的請求到達時，Dapr 會建立一個新的。否則，它會沿著呼叫鏈傳遞跟蹤 ID。

配置

Dapr 使用概率抽樣。取樣率定義了對跟蹤跨度進行取樣的概率，其值可以介於 0 和 1（含）之間。預設取樣率為 0.0001（即取樣 10,000 個跨度中的 1 個）。

要更改預設跟蹤行為，請使用配置檔案。例如，以下配置物件將取樣率更改為 1（即每個跨度都被取樣），並使用 Zipkin 協議將跟蹤傳送到位於 http://zipkin.default.svc.cluster.local 的 Zipkin 伺服器

yaml檔案路徑：%UserProfile%\.dapr\config.yaml

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: tracing
  namespace: default
spec:
  tracing:
    samplingRate: "1"
    zipkin:
      endpointAddress: "http://zipkin.default.svc.cluster.local:9411/api/v2/spans"

注：將取樣率更改為 0 會完全禁用跟蹤。

W3C 跟蹤上下文

Dapr 使用 W3C 跟蹤上下文對服務呼叫和釋出/訂閱訊息進行分散式跟蹤。Dapr 完成了生成和傳播跟蹤上下文資訊的所有繁重工作，僅在極少數情況下，您需要傳播或建立跟蹤上下文。

W3C trace context有以下優勢：

  • 為單個跟蹤和請求提供唯一識別符號，允許將多個提供程式的跟蹤資料連結在一起。
  • 提供轉發特定於供應商的跟蹤資料的商定機制，並避免跟蹤在多個工具參與單個事務時中斷。
  • 提供中間商、平臺和硬體提供商可以支援的行業標準。

有兩種情況需要了解如何使用跟蹤：

  1. Dapr 在服務之間生成並傳播跟蹤上下文。
  2. Dapr 生成跟蹤上下文，您需要將跟蹤上下文傳播到另一個服務，或者您生成跟蹤上下文，Dapr 將跟蹤上下文傳播到服務。

Dapr 在服務之間生成並傳播跟蹤上下文

在某些情況下，Dapr 會為您完成所有工作。您不需要建立和傳播任何跟蹤標頭。 Dapr 負責建立所有跟蹤標頭並傳播它們。讓我們通過示例來了解場景；

  1. 單個服務呼叫（服務 A -> 服務 B）

    Dapr 在服務 A 中生成跟蹤標頭，這些跟蹤標頭從服務 A 傳播到服務 B。

  2. 多個順序服務呼叫（服務 A -> 服務 B -> 服務 C）

    Dapr 在服務 A 中的請求開始時生成跟蹤標頭，這些跟蹤標頭從服務 A-> 服務 B -> 服務 C 等傳播到進一步啟用 Dapr 的服務。

  3. 請求是來自外部endpoint（例如從閘道器服務到啟用 Dapr 的服務 A）

Dapr Sidecar 健康檢查

Dapr 提供了一種使用 HTTP /healthz endpoint來確定其健康狀況的方法。有了這個endpoint，可以探測 Dapr 程式或邊車的健康狀況，從而確定其準備情況和活躍度。

在將 Dapr 部署到託管平臺（例如 Kubernetes）時，會自動為您配置 Dapr health endpoint。您無需進行任何配置。

Health endpoint: 與 Kubernetes 整合

Kubernetes 使用 readiness 和 liveness 探測來確定容器的健康狀況。

kubelet使用活動探針來知道何時重新啟動容器。 例如，活動探測可以捕獲死鎖，即應用程式正在執行，但無法取得進展。在這種狀態下重新啟動容器有助於使應用程式更可用，儘管存在缺陷。

kubelet 使用就緒探針來了解容器何時準備好開始接受流量。當 pod 的所有容器都準備就緒時，它就被認為是準備好了的。這種準備訊號的一個用途是控制哪些Pods被用作Kubernetes服務的後端。 當 Pod 未準備好時，它將從Kubernetes服務負載均衡器中刪除。

當與 Kubernetes 整合時，Dapr Sidecar 被注入了一個 Kubernetes 探針配置，告訴它使用 Dapr healthz endpoint。這是由 Sidecar Injector 系統服務完成的。與 kubelet 的整合如下圖所示。

20211117182319.jpg

如何在 Kubernetes 中配置活性探針

在 pod 配置檔案中，在容器規範部分新增了 liveness 探針，如下所示：

livenessProbe:
     httpGet:
       path: /healthz
       port: 8080
     initialDelaySeconds: 3
     periodSeconds: 3

在上面的例子中， periodSeconds 欄位指定 kubelet 應該每 3 秒執行一次活性探測。 initialDelaySeconds 欄位告訴 kubelet 在執行第一次探測之前應該等待 3 秒。

注：任何大於或等於 200 且小於 400 的程式碼都表示成功。其他程式碼表示失敗。

如何在 Kubernetes 中配置就緒探針

就緒探針的配置類似於活性探針。唯一的區別是您使用 readinessProbe 欄位而不是 livenessProbe 欄位。

readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3

如何使用 Kubernetes 配置 Dapr Sidecar health endpoint

此配置由 Sidecar Injector 服務自動完成。Dapr 在埠 3500 上有它的 HTTP health endpint /v1.0/healthz，這可以與 Kubernetes 一起使用以進行就緒和活躍度探測。當注入 Dapr sidecar 時，readiness 和 liveness 探針在 pod 配置檔案中配置為以下值。

livenessProbe:
      httpGet:
        path: v1.0/healthz
        port: 3500
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds : 5
      failureThreshold : 3
readinessProbe:
      httpGet:
        path: v1.0/healthz
        port: 3500
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds : 5
      failureThreshold: 3

.Net中使用可觀測性

建立Assignment.Server

建立類庫專案，並新增Dapr.AspNetCore, OpenTelemetry, OpenTelemetry.Instrumentation.AspNetCore, OpenTelemetry.Instrumentation.Http,OpenTelemetry.Extensions.Hosting和OpenTelemetry.Exporter.ZipkinNuGet包引用，最後修改程式埠為5000。

!!!注：版本很重要，NuGet要開啟包含預發行版，並且使用指定版本

OpenTelemetry-1.2.0-beta1

OpenTelemetry.Instrumentation.AspNetCore-1.0.0-rc8

OpenTelemetry.Instrumentation.Http-1.0.0-rc8

OpenTelemetry.Exporter.Zipkin-1.2.0-beta1

OpenTelemetry.Extensions.Hosting-1.0.0-rc8

修改program.cs

using OpenTelemetry.Resources;
using OpenTelemetry.Trace;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddOpenTelemetryTracing((tracerProviderBuilder) =>
    tracerProviderBuilder
        .SetResourceBuilder(ResourceBuilder.CreateDefault().AddService("testobservability"))
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddZipkinExporter(zipkinOptions =>
        {
            zipkinOptions.Endpoint = new Uri("http://localhost:9411/api/v2/spans");
        }
    )
);
var app = builder.Build();

app.Map("/Amazing", async (HttpContext context) =>
{
    if (context.Request.Headers.TryGetValue("traceparent", out var traceparent))
    {
        Console.WriteLine($"TraceParent: {traceparent}");
    }
    if (context.Request.Headers.TryGetValue("tracestate", out var tracestate))
    {
        Console.WriteLine($"TraceState: {tracestate}");
    }

    System.Diagnostics.Activity.Current?.SetParentId(traceparent.ToString());
    _ = await new HttpClient().GetStringAsync("https://www.baidu.com");
    Console.WriteLine($"Invoke succeed: traceID:{traceparent}");
});

app.Run();

可以看到我們直接演示了一個好玩的用法，就是開啟.Net的OpenTelemetry，然後修改Diagnostics.Activity的ParentId，讓當前的Tracing跟Dapr Sidecar傳來的TraceId一致。

執行Assignment.Server

使用Dapr CLI來啟動，先使用命令列工具跳轉到目錄 dapr-study-room\Assignment07\Assignment.Server，然後執行下面命令

dapr run --app-id testobservability --app-port 5000 --dapr-http-port 3500 --dapr-grpc-port 50001 dotnet run

使用Dapr CLI發個命令看看

dapr invoke --app-id testobservability --method /Amazing

開啟Zipkin，地址：http://localhost:9411/, 來看一下Zipkin的Tracing，不單有Dapr Sidecar的請求記錄進來了，還跟HttpClient的捆綁在了起來，是的，有趣的就在這裡。

除了可以跟蹤HttpClient以外，還有EF Core等都整合了。

16371523682162.png

至於Metrics和Logs整合也是非常簡單，需要搭配不同的後端如Prometheus, Fluentd等。甚至可以通過自定義Exporter自行對接一些雲廠商的雲服務。

本章原始碼

Assignment09

https://github.com/doddgu/dapr-study-room

我們正在行動，新的框架、新的生態

我們的目標是自由的、易用的、可塑性強的、功能豐富的、健壯的。

所以我們借鑑Building blocks的設計理念，正在做一個新的框架MASA Framework，它有哪些特點呢？

  • 原生支援Dapr，且允許將Dapr替換成傳統通訊方式
  • 架構不限，單體應用、SOA、微服務都支援
  • 支援.Net原生框架，降低學習負擔，除特定領域必須引入的概念，堅持不造新輪子
  • 豐富的生態支援，除了框架以外還有元件庫、許可權中心、配置中心、故障排查中心、報警中心等一系列產品
  • 核心程式碼庫的單元測試覆蓋率90%+
  • 開源、免費、社群驅動
  • 還有什麼？我們在等你，一起來討論

經過幾個月的生產專案實踐，已完成POC，目前正在把之前的積累重構到新的開源專案中

目前原始碼已開始同步到Github（文件站點在規劃中，會慢慢完善起來）：

MASA.BuildingBlocks

MASA.Contrib

MASA.Utils

MASA.EShop

BlazorComponent

MASA.Blazor

QQ群：7424099

微信群：加技術運營微信（MasaStackTechOps），備註來意，邀請進群

masa_stack_tech_ops.png

相關文章