點擊藍字

關注我們

分布式應用程序很復雜，給開發人員調試和修復生產問題帶來了一系列挑戰。盡管微服務架構可幫助維持一支規模較小，可以自主工作并專注于獨立業務團隊，但由于其分布式性質，它帶來了新的挑戰。例如，在業務交易過程中出現問題的情況下，需要端到端跟蹤請求，該請求可能跨越多個服務和基礎架構。解決問題時可能遇到的挑戰有：

• 管理已知和未知故障

• 故障也是分布式的

• 傳統監控系統不適用

這是可監測性和可觀察性出現的地方。可監測性記錄應用程序的總體運行狀況，而可觀察性則可以幫助您更深入地了解上下文數據。在.NET大會上，我和Cecil 已經深入討論了云原生應用程序中的可監測性和可觀察性。

以上視頻中，我們著眼于可觀察性和可監測性的關鍵點，例如日志(Logging)，衡量指標(Metrics)，鏈路追蹤(Tracing)，并深入分析了運行狀況檢查(Health checks)。

以下是視頻中討論的一些基本概念：

運行狀況檢查(Health checks)

微服務實現了運行狀況檢查，最理想的情況是使用HTTP endpoints，以便各種實時監控系統可以查詢狀態。運行狀況檢查端點至少應做出以下響應：

• 系統正在運行嗎？

• 它可以執行任務嗎？

在Kubernetes世界中，這些分別直接轉換為liveness和readiness。它們定義在Kubernetes的YAML部署配置文件中。

• liveness路徑是Kubernetes定期查詢以檢查故障的端點。

  Kubernetes提供了liveness探針來監測失敗的應用程序，并在它們不返回成功代碼時重新啟動它們。

• readiness路徑是Kubernetes查詢以了解服務何時就緒，可以開始接受流量的終端。

  當所有注冊的檢查都成功時，它將返回HTTP狀態代碼200。

ASP.NET Core提供用于向可監測性系統報告運行狀況的中間件和庫，來提供運行狀況檢查。相關文檔請查閱ASP.NET Core中的運行狀況檢查。

ASP.NET Core中的運行狀況檢查

https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks

日志

無論您使用什么工具調查生產環境中的問題，最終都會是以日志的形式反應問題的根本原因。在分布式環境中，您需要確保日志記錄包含有助于調試的深入信息。可以從一個集中的地方查詢它們。每個日志記錄都需要有一個關聯ID，以便進行跟蹤以了解全局。

結構化日志

使用結構化日志，您可以將序列化的對象添加到日志中，日志監視系統可以高效地查詢這些對象。例如，您可以根據customerID或trasnsactionID查詢整個事務日志。在ASP.NET Core應用程序中，可以使用提供結構化日志記錄的Serilog。請查閱.NET Core和ASP.NET Core中的日志入門，以及Serilog了解結構化日志。

.NET Core和ASP.NET Core中的日志

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging/

Serilog

https://serilog.net/

集中式日志和關聯ID

在傳統應用程序中，日志文件存儲在本地計算機上。在分布式環境中，把日志記錄在某一臺計算機中的純文本文件中是沒有幫助的。生成日志的應用程序可能無法訪問本地磁盤，或者當容器在虛擬機中移動時，本地磁盤可能是高度瞬態的。由于在Cloud-native應用程序中使用基于文件的日志會遇到一些問題，因此首選集中式日志。日志由應用程序收集并傳送到一個集中的日志應用程序，該應用程序對日志進行索引和存儲。這類系統每天可以接收數十GB的日志。Serilog提供了向集中式系統（如Azure Application Insights，Azure Monitor的一項功能）寫入日志事件的接收器。在構建跨多個服務的日志記錄時，遵循一些標準做法也很有幫助。例如，在事務開始時生成一個關聯ID，然后將其記錄到與該事務相關的每條消息中，這樣可以更容易地從集中式日志系統中搜索所有相關消息。

接收器

https://github.com/serilog/serilog/wiki/Provided-Sinks

關聯ID

https://blog.rapid7.com/2016/12/23/the-value-of-correlation-ids/

分布式跟蹤

分布式跟蹤等效于現代云和微服務體系結構的調用堆棧，并添加了性能分析器。分布式跟蹤或分布式請求跟蹤有助于端到端查看請求，并使您能夠從整體上識別問題。跟蹤可以為您提供有關問題的詳細答案，例如事件發生在什么時候？它花了多少時間？為什么要花這么長時間？哪些微服務處理了它？等等，像?openzipkin/zipkin?之類的開源分布式跟蹤系統，在該領域非常流行。

為您的應用程序啟用分布式跟蹤就跟將相應的分布式跟蹤提供商的SDK添加到每個微服務中一樣簡單。例如，在您的應用中安裝并配置了Application Insights SDK后，SDK依賴關系自動收集器會自動收集流行框架，庫和技術的跟蹤信息。

在幾個不同的系統和工具之間，需要有一套標準以便于觀察。OpenTelemetry標準化了不同的應用程序和框架如何收集和發出可觀測性遙測。OpenTelemetry提供了一個與供應商無關的規范、一組api、sdk和工具以及用于可觀測性遙測（分布式跟蹤、度量等）的集成。查看博客文章OpenTelemetry .net reachs v1.0以獲取詳細信息。

openzipkin/zipkin

https://github.com/openzipkin/zipkin

Application Insights SDK

https://docs.microsoft.com/azure/azure-monitor/app/distributed-tracing

OpenTelemetry

https://opentelemetry.io

博客文章OpenTelemetry .net reachs v1.0

https://devblogs.microsoft.com/dotnet/opentelemetry-net-reaches-v1-0

動手模塊

我們已經構建了一系列模塊來幫助您學習構建.NET微服務和云原生技術。查看以下模塊，這些模塊將幫助您了解可監測性和可觀察性相關技術。

• 行運行狀況檢查：創建和部署.Net微服務和云原生技術

• 可監測性和可觀察性：測試cloud-native ASP.NET Core微服務

• 有關其他主題，請查看https://aka.ms/aspnet-microservices

創建和部署.Net微服務和云原生技術

https://docs.microsoft.com/learn/modules/microservices-aspnet-core/

測試cloud-native ASP.NET Core微服務

https://docs.microsoft.com/learn/modules/microservices-logging-aspnet-core/

總結

以上是生活随笔為你收集整理的云原生ASP.NET Core程序的可监测性和可观察性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。