前言：
前篇-Actor構建塊 文章對Dapr的Actor構建塊進行了解，本篇繼續對可觀測性 進行了解學習。
一、可觀測性
用於獲取可觀察性的系統資訊稱為遙測。 它可以分為四大類：
- 分散式跟蹤 提供有關分散式業務事務中所涉及服務之間的流量的見解。
- 度量值 可讓你深入瞭解服務的效能及其資源消耗情況。
- 日誌記錄 可提供程式碼的執行方式和錯誤發生的見解。
- 執行狀況 終結點可讓你深入瞭解服務的可用性。
Dapr 可觀察性構建基塊將可觀察性與應用程式分離。 它自動捕獲由 Dapr 分支和 Dapr 系統服務生成的、構成 Dapr 控制平面的流量。 塊將流量與跨多個服務的單個操作關聯起來。 它還公開了系統的效能指標、資源使用情況和執行狀況。 遙測以開放標準格式釋出，使資訊可以送入你選擇的監視後端。 在這裡，可以對資訊進行視覺化、查詢和分析。
由於 Dapr 抽象掉了該管道，因此應用程式不知道如何實現可觀察性。 無需引用庫或實現自定義檢測程式碼。 Dapr 使開發人員能夠專注於構建業務邏輯，而不是可觀察性管道。 可觀察性在 Dapr 系統級別配置，在服務之間保持一致，即使是由不同的團隊建立，並使用不同的技術堆疊構建。
二、工作原理
Dapr 的 Sidecar 啟用內建可觀察性功能。 服務通訊時，Dapr 分支會截獲流量並提取跟蹤、指標和日誌記錄資訊。 遙測以開放標準格式釋出。 預設情況下，Dapr 支援 OpenTelemetry 和 Zipkin。
Dapr 提供可將遙測釋出到不同後端監視工具的 收集 器。 這些工具提供了 Dapr 遙測用於分析和查詢。 下圖 顯示了 Dapr 可觀察性體系結構：
步驟：
- 服務 A 呼叫服務 B 上的操作。呼叫將從服務 A 的 Dapr 挎鬥路由到服務 B 的挎鬥。
- 當服務 B 完成操作時，響應將通過 Dapr 分支傳送回服務 A。 它們收集併發布每個請求和響應的所有可用遙測資料。
- 配置的收集器引入遙測資料，並將其傳送到監視後端。
三、特點
-
分散式跟蹤
分散式跟蹤提供了跨分散式應用程式中的服務的流量的見解。交換請求和響應訊息的日誌是用於解決問題的有用資訊的來源。 硬部分正在關聯屬於同一業務事務的訊息 。
Dapr 將 HTTP/GRPC Middleware 新增到 Dapr sidecar。 Middleware 攔截所有 Dapr 和應用程式流量，並自動注入關聯ID以跟蹤分散式事務。 此設計有如下優點：
-
- 無需程式碼檢測。 所有流量都會自動跟蹤可配置的跟蹤級別。
- 跨微服務的一致跟蹤行為。 跟蹤是在 Dapr sidecar 上進行配置和管理的，因此它可以在服務之間保持一致，這些服務由不同的團隊提供，並可能以不同的程式語言編寫。
- 可配置和可擴充套件。 通過利用 Zipkin API 和 OpenTelemetry 收集器，可以將 Dapr 追蹤配置為與流行的追蹤後端配合使用，包括客戶可能有的自定義後端。
- 可以同時定義和啟用多個Exporter
步驟：
- 服務 A 在服務 B 上呼叫操作。當服務 A 啟動呼叫時，Dapr 將建立一個唯一的跟蹤上下文並將其注入到請求中。
- 服務 B 接收請求，並對服務 C 呼叫操作。 Dapr 檢測傳入請求包含跟蹤上下文，並通過將其注入到服務 C 的傳出請求來傳播。
- 服務 C 接收請求並對其進行處理。 Dapr 檢測到傳入請求包含跟蹤上下文，並通過將其注入到服務 B 的傳出響應來傳播。
- 服務 B 接收響應並對其進行處理。 然後，它會建立新的響應，並通過將跟蹤上下文注入到服務 A 的傳出響應來傳播跟蹤上下文。
Zipkin 是開源分散式跟蹤系統。 它可以攝取和視覺化遙測資料。 Dapr 提供對 Zipkin 的預設支援。以下為預設支援的dapr設定
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: daprConfig
spec:
tracing:
##取樣率
samplingRate: "1"
zipkin:
##zipkin地址
endpointAddress: http://localhost:9411/api/v2/spans
-
指標
指標（Metrics）是在一段時間內收集和儲存的一系列度量值和計數。 Dapr 指標 提供監控功能，以瞭解 Dapr sidecar 和系統服務的行為。 例如，Dapr sidecar 和使用者應用之間的服務指標可以展示呼叫延遲、流量故障、請求的錯誤率等。 Dapr 的系統服務度量 則可以顯示 sidecar 注入失敗，系統服務的執行狀況 ( 包括 CPU 使用率，actor 位置數量等)
每個Sidecar和系統服務都公開一個在埠9090上偵聽的指標終結點。 Prometheus 指標 Scrapper 從每個終結點捕獲指標，並將資訊釋出到監視後端。
Dapr 為 Dapr 系統服務及其執行時生成一組大量指標。 示例包括：
| 指標 | 源 | 說明 |
|---|---|---|
| dapr_operator_service_created_total | 系統 | Dapr Operator service 建立的 Dapr 服務總數。 |
| dapr_injector_sidecar_injection/requests_total | 系統 | Dapr Sidecar-Injector 服務收到的挎鬥注入請求總數。 |
| dapr_placement_runtimes_total | 系統 | 向 Dapr 放置服務報告的主機總數。 |
| dapr_sentry_cert_sign_request_received_total | 系統 | Dapr Sentry 服務) (收到的證書籤名請求數。 |
| dapr_runtime_component_loaded | 執行時 | 已成功載入的 Dapr 元件數。 |
| dapr_grpc_io_server_completed_rpcs | 執行時 | 按方法和狀態的 gRPC 呼叫的計數。 |
| dapr_http_server_request_count | 執行時 | HTTP 伺服器中啟動的 HTTP 請求數。 |
| dapr_http/client/sent_bytes | 執行時 | 請求正文中傳送的總 (不包括 HTTP 客戶端) 標頭。 |
配置指標：
執行時，可以通過在 Dapr 命令中包含 引數來 --enable-metrics=false 禁用指標收集終結點。 或者，還可使用 引數更改終結點的預設 --metrics-port 9090 埠。
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: dapr-config
namespace: dapr-trafficcontrol
spec:
tracing:
samplingRate: "1"
metric:
enabled: false
Prometheus 抓取器將指標收集併發布到監視後端後，如何理解原始資料？ 用於分析指標的常用視覺化工具是 Grafana。 使用 Grafana，可以從可用指標建立儀表板。
-
日誌記錄
Dapr 生成 日誌，以提供 sidecar 操作的可見性，並幫助使用者識別問題並執行除錯。 日誌事件包含由 Dapr 系統服務生成的警告，錯誤，資訊和除錯訊息。
Dapr以純文字形式或JSON格式生成結構化日誌到標準輸出。 預設情況下，所有 Dapr 程式 (執行時和系統服務) 都以純文字寫入控制檯輸出。 要啟用 JSON 格式的日誌，您需要在執行 Dapr 程式時新增 --log-as-json 命令標誌。
Dapr 基於以下結構生成日誌：
| 欄位 | 說明 | 示例 |
|---|---|---|
| time | ISO8601 時間戳 | 2011-10-05T14:48:00.000Z |
| level | 日誌級別 (info/warn/debug/error) | info |
| type | 日誌型別 | log |
| msg | 日誌訊息 | hello dapr! |
| scope | 日誌記錄範圍 | dapr.runtime |
| instance | Dapr 執行位置的主機名 | dapr-pod-xxxxx |
| app_id | Dapr 應用 ID | dapr-app |
| ver | Dapr 執行時版本 | 1.0 |
-
執行情況
Dapr 提供了一種使用 HTTP /healthz 端點來確定其健康狀況的方法。 通過此端點，對Dapr 程式或 sidecar進行探測，可以確定其執行狀況，從而確定其就緒程度和活躍度。
GET http://localhost:3500/v1.0/healthz
在自承載模式下執行時，不會自動呼叫執行狀況 API。 不過，可以從應用程式程式碼或執行狀況監視工具呼叫 API。
在 Kubernetes 中執行時，Dapr sidecar-execut 會自動將 Kubernetes 配置為使用執行狀況 API 執行執行情況 探測 和 就緒情況探測。
Kubernetes 使用執行狀態探測來確定容器是否已啟動並正在執行。 如果執行情況探測返回失敗程式碼，Kubernetes 將假定容器已死並自動重啟。 此功能可提高應用程式的整體可用性。
Kubernetes 使用就緒情況探測來確定容器是否已準備好開始接受流量。 當 Pod 的所有容器都準備就緒時，它被視為已就緒。 就緒情況確定 Kubernetes 服務是否可以在負載均衡方案中將流量引導到 Pod。 未就緒的 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
以下引數可用於探測：
-
path指定 Dapr 執行狀況 API 終結點。- 指定
portDapr 執行狀況 API 埠。 - 指定 Kubernetes 在開始首次探測容器之前等待
initialDelaySeconds的秒數。 periodSeconds指定 Kubernetes 在每個探測之間等待的秒數。- 指定 Kubernetes 在超時之前等待來自 API 的響應
timeoutSeconds的秒數。超時被解釋為失敗。 - 指定 Kubernetes 在考慮容器未處於活動狀態或未就緒之前將接受的失敗
failureThreshold狀態程式碼數。
四、.Net Core 應用
1、新增以下Nuget包：
注：版本很重要，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
2、修改Startup檔案：新增監控
public class Startup { public Startup(IConfiguration configuration) { Configuration = configuration; } public IConfiguration Configuration { get; } // This method gets called by the runtime. Use this method to add services to the container. public void ConfigureServices(IServiceCollection services) { services.AddControllers(); services.AddActors(option => { option.Actors.RegisterActor<OrderStatusActor>(); }); //新增TelemetryTracing監控 services.AddOpenTelemetryTracing((tracerProviderBuilder) => tracerProviderBuilder .SetResourceBuilder(ResourceBuilder.CreateDefault().AddService("DaprBackEnd")) .AddAspNetCoreInstrumentation() .AddHttpClientInstrumentation()
//設定zipkin相關設定 .AddZipkinExporter(zipkinOptions => { zipkinOptions.Endpoint = new Uri("http://localhost:9411/api/v2/spans"); } )); } // This method gets called by the runtime. Use this method to configure the HTTP request pipeline. public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } app.UseRouting(); app.UseAuthorization(); app.UseEndpoints(endpoints => { //開啟.Net的OpenTelemetry，然後修改Diagnostics.Activity的ParentId，讓當前的Tracing跟Dapr Sidecar傳來的TraceId一致 endpoints.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}"); }); endpoints.MapControllers(); endpoints.MapActorsHandlers(); }); } }
3、啟動dapr應用：
dapr run --dapr-http-port 3511 --app-port 8220 --app-id DaprBackEnd dotnet .\DaprBackEnd.dl
4、使用Dapr CLI命令：
dapr invoke --app-id DaprBackEnd --method /Amazing
5、檢視檢測效果：
開啟Zipkin，地址：http://localhost:9411/, 來看一下Zipkin的Tracing
總結：
詳細的可觀察性在生產中執行分散式系統至關重要。
Dapr 提供不同型別的遙測，包括分散式跟蹤、日誌記錄、指標和執行狀況狀態。
Dapr 僅生成 Dapr 系統服務和分支的遙測。 不會自動包含應用程式程式碼中的遙測資料。 不過，可以使用特定的 SDK （如 OpenTelemetry SDK for .NET）從應用程式程式碼發出遙測資料。
Dapr 遙測採用基於開放標準的格式生成，因此可通過大量可用的監視工具來引入。 示例包括 Zipkin、Azure 應用程式 Insights、ELK Stack、New Relic 和 Grafana。 有關如何監視具有特定監視後端的 Dapr 應用程式的教程，請參閱 Dapr 文件中的 監視應用程式 Dapr 。
參考：
https://docs.microsoft.com/zh-cn/dotnet/architecture/dapr-for-net-developers/observability