背 景
隨著微服務架構的普及，現代企業的IT基礎設施已經變得越來越復雜。單一的服務可能有多個下游依賴，而這些依賴又可能有自己的子依賴，和主機資源的依賴。在這樣的環境中，當某個服務發生故障，確定具體的原因變得尤為困難。傳統的故障排查方法，如手動檢查日志或詢問開發團隊，既耗時又不一定能找到真正的根源。
此外，隨著DevOps和持續集成/持續部署（CI/CD）的普及，應用的發布頻率大大增加，這使得發布引起的服務中斷變得更為常見。同時，資源和基礎設施的動態性也為故障診斷帶來了挑戰。
為了應對這些挑戰，優維設計了“Easy分析”服務故障根因分析工具，旨在為技術團隊提供一個集成、自動化的解決方案，幫助其迅速、準確地定位服務故障時的原因。
下面，從具體場景出發，詳細介紹服務故障根因分析工具。
1
應用發布導致的服務故障
1.1 概述
應用發布可能導致服務運行出現不穩定或其他未預期的影響。當服務發出告警時，本功能將自動分析告警指標，檢測服務或其下游服務在最近是否發生過變更。
1.2 核心功能
- 變更檢測：當服務告警時，系統會自動檢測與告警相關的服務是否近期有變更事件，如啟動、關閉、升級或重啟等。
- 雙態部署事件聯動：與雙態部署系統緊密集成，獲取最新的部署和變更事件信息。
- 告警與變更關聯：為告警事件提供直接與變更事件的關聯，幫助團隊快速確定是否有發布活動導致的故障。
- 消費CMDB數據：根據cmdb的服務相關的模型，自動關聯下游服務的變更事件
1.3 場景說明及配置
假設微服務集群中，提供了一個名為flounder_metric的服務。服務的請求一般是從api_gateway接入到集群中，并且基于url路由至具體的應用組件來處理請求。因此，在這個場景中，存在這樣一個調用關系：api_gateway -> flounder_metric
在服務監控中，我們會對flounder_metric的接口進行撥測。配置的步驟如下：
- 建立內網撥測策略，指定監控的應用是「http-logic.api_gateway」，它是api_gateway應用的服務標識；
- 配置關于flounder_metric服務的接口，在變量定義中，通過$.subservices.ip會自動獲取到服務下子服務的IP地址。
保存后即可。
此時配置基于detect_code的告警規則，即可完成對該接口的監控。
1.4 故障觸發和根因分析
我們人為觸發一個服務告警，通過雙態部署，關閉flounder_metric服務。
稍后，將觸發一個撥測告警：
我們通過事件詳情，點擊故障分析：
此時將看到故障分析頁面，讓我們來解釋一下：
上方是告警事件的告警對象和告警指標持續的時間，可以看到告警持續時間范圍是 11:55~12:04。
接下來就是根因分析的結論，一共發現1個結論，和應用發布的變更相關。具體來說，有兩個分析：
- http-logic.api_gateway有告警事件，沒有變更事件，說明不是api_gatewaya變更導致；
- 由于api_gateway的下游是flounder_metric服務，而該服務在12:00分發生了停止操作，進而觸發了告警，因此分析為：下游HTTP服務http-logic.flounder_metric的變更導致的故障（這也是此次故障的真正原因）。
1.5 結論
在微服務架構中，服務間的相互依賴和頻繁的應用發布行為可能會導致復雜的故障情況。在本場景中，通過"服務故障根因分析"工具，我們成功地自動檢測到flounder_metric服務的停止操作是導致api_gateway服務撥測告警的直接原因。該工具能夠智能地關聯告警事件與近期的應用變更，準確快速地定位到真實的故障原因。
此次案例展示了"服務故障根因分析"工具的核心功能，即自動識別與故障相關的變更，并為技術團隊提供明確的、數據驅動的根因分析。此功能大大減少了故障診斷時間，并提高了故障恢復的效率。
2
依賴資源高負載導致的服務故障
2.1 概述
服務的性能和穩定性可能受到其運行環境的影響，特別是當它依賴的資源或子服務處于高負載狀態時。本功能提供了與資源負載告警的自動關聯能力，幫助識別故障的根本原因。
2.2 核心功能
- 資源負載告警關聯：當服務延遲或其他性能指標出現問題時，系統會自動檢測與該服務關聯的子服務部署實例主機是否有高負載告警。
- 直觀的負載影響分析：為用戶提供一個清晰的視圖，展示服務與其依賴資源之間的關系，以及哪些資源的高負載可能影響了服務的性能。
- 資源性能指標對比：允許用戶對比服務性能指標與資源負載指標，例如，當服務延遲增加時，可以立即查看其所在主機的CPU或內存使用情況。
2.3 場景說明及配置
假設微服務集群中，提供了一個名為cmdb_service的服務，并且對它的延遲做監控。我們設定SLO是10ms，并且手動觸發系統高負載，來審視根因分析的準確性。
為了實現這個場景，我們人為設定當「磁盤IO的使用率」過高并觸發告警后，再觸發延遲告警。
當告警發生后，我們點擊故障分析，進入分析頁：
分析頁面如上所示，讓我們解釋一下。
- 由于alert_service的下游是tool.sandbox，并且這兩個服務都在主機：prod-host-10-36-enterprise-7-logic，并且該主機發生磁盤IO操作的CPU使用率過高的告警。因此根因分析就會把這些關系和告警聯系起來，并告知給用戶。
除了「磁盤IO操作的CPU使用率」，還有「5分鐘單核負載」，「網絡流量」等指標均可觸發高負載場景的分析。
2.4 結論
在微服務架構中，單一服務的性能往往與其所依賴的其他服務和資源緊密相關。我們在這次的模擬場景中成功地展示了如何通過“服務故障根因分析”工具來識別和關聯服務延遲增加與其所在主機的資源高負載之間的因果關系。
這種自動化的、綜合的分析方法大大簡化了故障診斷過程，確保了更快速、更準確的問題定位和解決，進一步提高了服務的穩定性和可用性。
3
支持按拓撲形式分析故障演變情況
故障根因分析的分析視圖改版，支持按拓撲形式分析故障演變情況。在舊版本中，盡管可以關聯并分析出所有可能導致故障的原因，但是分析視圖所攜帶的信息過于繁瑣和冗余，不利于高效分析的目的。在新版故障分析視圖中，支持以故障拓撲的形式去智能分析故障演化路徑。如下所示：
如上圖所示：紅色為底色的方框代表服務產生的告警，比如端口撥測失敗。
而后展示了和此服務關聯的其他服務的變更情況，由圖可知，是17*.3*.**.**上的scheduler_service發生了變更導致服務告警。
如此可以幫助用戶快速排除服務故障的原因是否由于變更產生。
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。
