背 景

隨著微服務(wù)架構(gòu)的普及，現(xiàn)代企業(yè)的IT基礎(chǔ)設(shè)施已經(jīng)變得越來(lái)越復(fù)雜。單一的服務(wù)可能有多個(gè)下游依賴(lài)，而這些依賴(lài)又可能有自己的子依賴(lài)，和主機(jī)資源的依賴(lài)。在這樣的環(huán)境中，當(dāng)某個(gè)服務(wù)發(fā)生故障，確定具體的原因變得尤為困難。傳統(tǒng)的故障排查方法，如手動(dòng)檢查日志或詢問(wèn)開(kāi)發(fā)團(tuán)隊(duì)，既耗時(shí)又不一定能找到真正的根源。

此外，隨著DevOps和持續(xù)集成/持續(xù)部署（CI/CD）的普及，應(yīng)用的發(fā)布頻率大大增加，這使得發(fā)布引起的服務(wù)中斷變得更為常見(jiàn)。同時(shí)，資源和基礎(chǔ)設(shè)施的動(dòng)態(tài)性也為故障診斷帶來(lái)了挑戰(zhàn)。

為了應(yīng)對(duì)這些挑戰(zhàn)，優(yōu)維設(shè)計(jì)了“Easy分析”服務(wù)故障根因分析工具，旨在為技術(shù)團(tuán)隊(duì)提供一個(gè)集成、自動(dòng)化的解決方案，幫助其迅速、準(zhǔn)確地定位服務(wù)故障時(shí)的原因。

下面，從具體場(chǎng)景出發(fā)，詳細(xì)介紹服務(wù)故障根因分析工具。

1

應(yīng)用發(fā)布導(dǎo)致的服務(wù)故障

1.1 概述

應(yīng)用發(fā)布可能導(dǎo)致服務(wù)運(yùn)行出現(xiàn)不穩(wěn)定或其他未預(yù)期的影響。當(dāng)服務(wù)發(fā)出告警時(shí)，本功能將自動(dòng)分析告警指標(biāo)，檢測(cè)服務(wù)或其下游服務(wù)在最近是否發(fā)生過(guò)變更。

1.2 核心功能

• 變更檢測(cè)：當(dāng)服務(wù)告警時(shí)，系統(tǒng)會(huì)自動(dòng)檢測(cè)與告警相關(guān)的服務(wù)是否近期有變更事件，如啟動(dòng)、關(guān)閉、升級(jí)或重啟等。
• 雙態(tài)部署事件聯(lián)動(dòng)：與雙態(tài)部署系統(tǒng)緊密集成，獲取最新的部署和變更事件信息。
• 告警與變更關(guān)聯(lián)：為告警事件提供直接與變更事件的關(guān)聯(lián)，幫助團(tuán)隊(duì)快速確定是否有發(fā)布活動(dòng)導(dǎo)致的故障。
• 消費(fèi)CMDB數(shù)據(jù)：根據(jù)cmdb的服務(wù)相關(guān)的模型，自動(dòng)關(guān)聯(lián)下游服務(wù)的變更事件

1.3 場(chǎng)景說(shuō)明及配置

假設(shè)微服務(wù)集群中，提供了一個(gè)名為flounder_metric的服務(wù)。服務(wù)的請(qǐng)求一般是從api_gateway接入到集群中，并且基于url路由至具體的應(yīng)用組件來(lái)處理請(qǐng)求。因此，在這個(gè)場(chǎng)景中，存在這樣一個(gè)調(diào)用關(guān)系：api_gateway -> flounder_metric

在服務(wù)監(jiān)控中，我們會(huì)對(duì)flounder_metric的接口進(jìn)行撥測(cè)。配置的步驟如下：

• 建立內(nèi)網(wǎng)撥測(cè)策略，指定監(jiān)控的應(yīng)用是「http-logic.api_gateway」，它是api_gateway應(yīng)用的服務(wù)標(biāo)識(shí)；
• 配置關(guān)于flounder_metric服務(wù)的接口，在變量定義中，通過(guò)$.subservices.ip會(huì)自動(dòng)獲取到服務(wù)下子服務(wù)的IP地址。

保存后即可。

此時(shí)配置基于detect_code的告警規(guī)則，即可完成對(duì)該接口的監(jiān)控。

1.4 故障觸發(fā)和根因分析

我們?nèi)藶橛|發(fā)一個(gè)服務(wù)告警，通過(guò)雙態(tài)部署，關(guān)閉flounder_metric服務(wù)。

稍后，將觸發(fā)一個(gè)撥測(cè)告警：

我們通過(guò)事件詳情，點(diǎn)擊故障分析：

此時(shí)將看到故障分析頁(yè)面，讓我們來(lái)解釋一下：

上方是告警事件的告警對(duì)象和告警指標(biāo)持續(xù)的時(shí)間，可以看到告警持續(xù)時(shí)間范圍是 11:55~12:04。

接下來(lái)就是根因分析的結(jié)論，一共發(fā)現(xiàn)1個(gè)結(jié)論，和應(yīng)用發(fā)布的變更相關(guān)。具體來(lái)說(shuō)，有兩個(gè)分析：

• http-logic.api_gateway有告警事件，沒(méi)有變更事件，說(shuō)明不是api_gatewaya變更導(dǎo)致；
• 由于api_gateway的下游是flounder_metric服務(wù)，而該服務(wù)在12:00分發(fā)生了停止操作，進(jìn)而觸發(fā)了告警，因此分析為：下游HTTP服務(wù)http-logic.flounder_metric的變更導(dǎo)致的故障（這也是此次故障的真正原因）。

1.5 結(jié)論

在微服務(wù)架構(gòu)中，服務(wù)間的相互依賴(lài)和頻繁的應(yīng)用發(fā)布行為可能會(huì)導(dǎo)致復(fù)雜的故障情況。在本場(chǎng)景中，通過(guò)"服務(wù)故障根因分析"工具，我們成功地自動(dòng)檢測(cè)到flounder_metric服務(wù)的停止操作是導(dǎo)致api_gateway服務(wù)撥測(cè)告警的直接原因。該工具能夠智能地關(guān)聯(lián)告警事件與近期的應(yīng)用變更，準(zhǔn)確快速地定位到真實(shí)的故障原因。

此次案例展示了"服務(wù)故障根因分析"工具的核心功能，即自動(dòng)識(shí)別與故障相關(guān)的變更，并為技術(shù)團(tuán)隊(duì)提供明確的、數(shù)據(jù)驅(qū)動(dòng)的根因分析。此功能大大減少了故障診斷時(shí)間，并提高了故障恢復(fù)的效率。

2

依賴(lài)資源高負(fù)載導(dǎo)致的服務(wù)故障

2.1 概述

服務(wù)的性能和穩(wěn)定性可能受到其運(yùn)行環(huán)境的影響，特別是當(dāng)它依賴(lài)的資源或子服務(wù)處于高負(fù)載狀態(tài)時(shí)。本功能提供了與資源負(fù)載告警的自動(dòng)關(guān)聯(lián)能力，幫助識(shí)別故障的根本原因。

2.2 核心功能

• 資源負(fù)載告警關(guān)聯(lián)：當(dāng)服務(wù)延遲或其他性能指標(biāo)出現(xiàn)問(wèn)題時(shí)，系統(tǒng)會(huì)自動(dòng)檢測(cè)與該服務(wù)關(guān)聯(lián)的子服務(wù)部署實(shí)例主機(jī)是否有高負(fù)載告警。
• 直觀的負(fù)載影響分析：為用戶提供一個(gè)清晰的視圖，展示服務(wù)與其依賴(lài)資源之間的關(guān)系，以及哪些資源的高負(fù)載可能影響了服務(wù)的性能。
• 資源性能指標(biāo)對(duì)比：允許用戶對(duì)比服務(wù)性能指標(biāo)與資源負(fù)載指標(biāo)，例如，當(dāng)服務(wù)延遲增加時(shí)，可以立即查看其所在主機(jī)的CPU或內(nèi)存使用情況。

2.3 場(chǎng)景說(shuō)明及配置

假設(shè)微服務(wù)集群中，提供了一個(gè)名為cmdb_service的服務(wù)，并且對(duì)它的延遲做監(jiān)控。我們?cè)O(shè)定SLO是10ms，并且手動(dòng)觸發(fā)系統(tǒng)高負(fù)載，來(lái)審視根因分析的準(zhǔn)確性。

為了實(shí)現(xiàn)這個(gè)場(chǎng)景，我們?nèi)藶樵O(shè)定當(dāng)「磁盤(pán)IO的使用率」過(guò)高并觸發(fā)告警后，再觸發(fā)延遲告警。

當(dāng)告警發(fā)生后，我們點(diǎn)擊故障分析，進(jìn)入分析頁(yè)：

分析頁(yè)面如上所示，讓我們解釋一下。

• 由于alert_service的下游是tool.sandbox，并且這兩個(gè)服務(wù)都在主機(jī)：prod-host-10-36-enterprise-7-logic，并且該主機(jī)發(fā)生磁盤(pán)IO操作的CPU使用率過(guò)高的告警。因此根因分析就會(huì)把這些關(guān)系和告警聯(lián)系起來(lái)，并告知給用戶。

除了「磁盤(pán)IO操作的CPU使用率」，還有「5分鐘單核負(fù)載」，「網(wǎng)絡(luò)流量」等指標(biāo)均可觸發(fā)高負(fù)載場(chǎng)景的分析。

2.4 結(jié)論

在微服務(wù)架構(gòu)中，單一服務(wù)的性能往往與其所依賴(lài)的其他服務(wù)和資源緊密相關(guān)。我們?cè)谶@次的模擬場(chǎng)景中成功地展示了如何通過(guò)“服務(wù)故障根因分析”工具來(lái)識(shí)別和關(guān)聯(lián)服務(wù)延遲增加與其所在主機(jī)的資源高負(fù)載之間的因果關(guān)系。

這種自動(dòng)化的、綜合的分析方法大大簡(jiǎn)化了故障診斷過(guò)程，確保了更快速、更準(zhǔn)確的問(wèn)題定位和解決，進(jìn)一步提高了服務(wù)的穩(wěn)定性和可用性。

3

支持按拓?fù)湫问椒治龉收涎葑兦闆r

故障根因分析的分析視圖改版，支持按拓?fù)湫问椒治龉收涎葑兦闆r。在舊版本中，盡管可以關(guān)聯(lián)并分析出所有可能導(dǎo)致故障的原因，但是分析視圖所攜帶的信息過(guò)于繁瑣和冗余，不利于高效分析的目的。在新版故障分析視圖中，支持以故障拓?fù)涞男问饺ブ悄芊治龉收涎莼窂?。如下所示?/span>

如上圖所示：紅色為底色的方框代表服務(wù)產(chǎn)生的告警，比如端口撥測(cè)失敗。

而后展示了和此服務(wù)關(guān)聯(lián)的其他服務(wù)的變更情況，由圖可知，是17*.3*.**.**上的scheduler_service發(fā)生了變更導(dǎo)致服務(wù)告警。

如此可以幫助用戶快速排除服務(wù)故障的原因是否由于變更產(chǎn)生。