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