作者：鈺誠
可觀測性
可觀測性（Observability）是指系統、應用程序或服務的運行狀態、性能和行爲能夠被有效地監測、理解和調試的能力。
隨着系統架構從單體架構到集羣架構再到微服務架構的演進，業務越來越龐大，也越來越複雜。雲原生時代背景下，隨着微服務、Service Mesh、 Serverless 等新技術的出現，業務的複雜度很快就超過了個人的極限，可觀測性在現代分佈式系統的設計和運維中變得越來越重要。傳統的監控和告警方法往往只關注系統的一些基本指標，而忽略了更細粒度的信息和上下文。可觀測性的目標是通過全面的數據收集和分析，提供更深入和全面的洞察力，使運維和開發人員能夠更好地理解系統的行爲、排查問題、預測性能瓶頸和應對故障。
日誌、指標和分佈式追蹤被稱爲可觀測性的三大支柱：
- 日誌（Logging）： 日誌是記錄系統運行過程中產生的事件和信息的記錄。通過記錄應用程序的日誌，可以瞭解系統的運行狀態、錯誤和異常信息，方便故障排查和系統分析。常見的日誌系統包括 ELK（Elasticsearch、Logstash、Kibana）和 Splunk 等。
- 指標（Metrics）： 指標是用於衡量系統各個方面性能的度量標準。通過採集和記錄指標數據，可以實時監控系統的運行情況，包括 CPU 使用率、內存佔用、請求響應時間等。常用的指標系統有 Prometheus 和 InfluxDB 等。
- 分佈式追蹤（Distributed Tracing）： 分佈式追蹤是用於跟蹤和監控分佈式系統中請求的路徑和性能的技術。通過將請求在系統中的不同組件之間傳遞一個唯一標識符，可以追蹤請求的流程和耗時，幫助分析和優化系統性能。常見的分佈式追蹤系統有 Zipkin 和 Apache Skywalking 等。
通過提供全面且精確的可觀測性，系統的開發和運維人員可以更快速地發現問題、理解系統行爲，並做出相應的優化和決策，從而提高系統的性能、穩定性和可靠性。
雲原生網關可觀測體系
MSE 雲原生網關依託阿里雲現有的雲產品（日誌服務 SLS、應用實時監控服務 ARMS）以及對開源軟件的良好支持構建了豐富的可觀測體系，爲用戶提供了強大的日誌、監控、鏈路追蹤以及告警功能，功能大圖如下所示：
網關的可觀測性能力致力於幫助客戶構建產品的可靠性體驗，爲客戶提供故障發現與故障定位的能力，減少故障的發生以及降低故障的影響面。 基於網關的監控與告警管理功能，實現故障的及時發現與通知到客戶；基於監控與日誌，實現故障的快速定位；基於鏈路追蹤，實現請求調用的全鏈路故障根因排查。
雲原生網關可觀測實踐
過程概覽
本文將依據下圖中標註的功能模塊出發，幫助讀者體驗網關可觀測性在故障發現與故障定位中的能力。
整體流程如下圖所示：
- 用戶收到網關發出的告警
- 用戶查看 prometheus 監控找到出問題的路由、服務
- 用戶查看 SLS 日誌獲取更詳細的報錯信息
- 用戶通過鏈路追蹤排故障的根因
測試環境架構概覽
本文在 ACK 集羣中部署了一系列 Springboot 的服務，調用關係如上圖所示，其中 Spring SVC 4-2 發生了 crash。通過網關接入 ACK 集羣，創建路由如下：
測試過程中會通過以下三種請求去訪問網關：
- 正常的請求，網關路由到 httpbin
- 在網關處就返回錯誤的請求，本文使用無法命中路由的請求
- 在上游服務返回錯誤的請求，網關路由到 Spring SVC 1
此時網關的錯誤率會出現明顯上升。
故障發現與定位過程
通過告警策略及時發現故障
首先配置網關的告警策略，從網關實例粒度設置告警規則與通知策略，本文中採用了郵件通知的方式，除此之外還有電話、短信等方式。配置告警策略的示例如下圖所示：
通過以下郵件信息可以得知網關出現了故障：
通過 Arms Prometheus 監控初步定位問題
接下來，查看網關觀測分析->業務監控->全局看板的錯誤信息概覽板塊，當前監控信息如下：
根據圖中內容，可以得到以下信息：
- “網關粒度失敗率”看板中，網關整體失敗率是大於上游服務失敗率的，這意味着一部分請求在網關處返回了錯誤碼，一部分請求在上游服務處返回了錯誤碼
- “路由粒度失敗率”看板中，能夠看到只有路由名稱爲 “spring” 的路由失敗率不是 0
- “上游服務粒度失敗率”看板中，能夠看到只有服務名稱爲 “springboot-svc-1.app-system.svc.cluster.local” 的服務失敗率不是 0
點擊圖中“路由失敗請求數排行”或者“上游服務失敗請求數排行”中的路由名或者服務名可以查看路由或者服務的詳細信息。
路由名爲 “spring” 的路由監控信息如下圖所示：
服務名爲 “springboot-svc-1.app-system.svc.cluster.local” 的服務監控信息如下圖所示：
上圖中顯示出現錯誤的路由和服務返回的錯誤碼爲 5xx，至此，已經初步定位到問題所在：
路由 “spring” 指向的上游服務 “springboot-svc-1.app-system.svc.cluster.local” 出現了問題。
但是，目前還有兩個問題需要解決：
- 在網關處返回錯誤的請求是什麼原因？
- 服務 “springboot-svc-1.app-system.svc.cluster.local” 的錯誤是什麼原因造成的？
通過 SLS 網關日誌獲取詳細信息
接下來通過網關日誌中心的 SLS 日誌獲取更詳細的信息。
首先點擊 response_code，此時會自動生成查詢請求，可以看到這段時間內網關的響應碼只有三種：200，404，500。
在網關問題排查頁面，輸入響應碼，可以查看錯誤碼可能的原因：
可以看到返回 404 響應碼的原因是沒有命中路由導致。
類似的，當選擇響應碼爲 500 時，可以看到相應的路由名以及服務名，如下圖所示：
通過問題排查工具可以看到，錯誤是後端服務造成的：
到現在爲止，只剩下一個問題：
服務 “springboot-svc-1.app-system.svc.cluster.local” 的錯誤根因是什麼？
通過 Arms xtrace 鏈路追蹤分析調用鏈
藉助於鏈路追蹤技術，可以獲取更細粒度的錯誤信息。只需要簡單的配置，網關即可接入 Arms xtrace：
ACK 集羣上的 Java 應用按照以下文檔進行配置：爲容器服務 Kubernetes 版 Java 應用安裝探針 [ 1] 。
在 SLS 日誌中找到一條錯誤請求的 traceid，根據 traceid 在鏈路追蹤頁面搜索相應的調用鏈路分析調用鏈路錯誤的根因：
從鏈路追蹤結果看，故障根因是 springboot-svc-4-2 服務錯誤，至此，一次完整的故障發現與故障定位已經完成。
總結
本次通過雲原生網關可觀測性進行故障發現和故障定位的實踐過程中，首先通過網關的告警策略將故障通知到用戶，然後通過 arms 提供的 prometheus 監控服務初步定位到出現故障的路由以及服務，之後通過 SLS 日誌服務提供的網關的結構化日誌進行查詢分析，排查出部分錯誤是客戶端請求路徑錯誤導致，最後通過鏈路追蹤對服務調用鏈路進行分析，最終成功對故障根因進行定位。
相關鏈接：
[1] 爲容器服務 Kubernetes 版 Java 應用安裝探針****