第4章某供電局營銷應用服務中斷問題分析案例4.1故障描述4.2問題分析過程4.3分析結論

4.1.1故障現象

某供電局隨著業務的拓展，信息水平不斷提升，信息化應用越發突顯其關鍵價值。盡管經過嚴格測試，各業務用戶在上線后還是會遇到許多無法預測的問題。網絡帶寬、網元健康狀況、網絡策略、終端性能、用戶使用習慣、服務器性能、程序設計等眾多相互關聯的因素，都會影響到業務的質量，任何一種環境的改變都可能造成業務質量的下降。4.1故障描述某供電局作為供電企業最關鍵業務應用之一的營銷應用出現了多次偶發性死機現象，對該局電網業務造成極大影響。信息部門希望通過這次分析服務，排查故障期間訪問過營銷系統服務器的主機行為，協助對異常現象進行分析定位，并為網絡與應用的運行管理提供優化依據。

下面結合科來網絡產品，對該供電局信息部門的網絡應用系統的故障問題進行詳細分析。4.1.2網絡拓撲

用戶的網絡環境示意圖如圖4-1所示。

圖4-1本案例中部署科來回溯分析系統的目的是對網絡進行全面的監控和分析，并不是單純為了解決營銷服務器的問題，因此采用的是核心交換全端口鏡像的方式。如果單純為解決營銷服務器的問題，只需要鏡像服務器區接口的雙向流量就可以實現。

2013年某日下午17時00分左右，營銷系統服務器無法訪問。通過FTP登錄到服務器，發現磁盤空間已經被兩個heapdump文件占滿。刪除heapdump文件，重啟營銷weblogicserver，服務于17時20分恢復正常。4.2問題分析過程4.2.1服務器流量分析

我們獲取營銷服務器的訪問流量并進行分析(如圖4-2所示)，發現從16時48分開始流量持續下降，至17時10分流量達到最低值，接近于0。

圖4-2

圖4-3這段時間共有251個客戶端訪問了營銷服務器，其中流量最大的是客服中心的兩臺客戶端10.XXX.XXX.165和10.XXX.XXX.157，流量分別達到408.77MB和269.25MB；流量第三的是服務器10.XXX.XXX.121，達到184MB；需要注意的是，流量使用前15名的主機中，多是屬于客服中心網段的客戶端，大多數流量均超過100MB；大部分訪問營銷服務器的用戶流量不會太高，在8MB左右，如圖4-4所示。

圖4-44.2.2客戶端流量分析

故障發生期間，流量最大的客戶端是10.XXX.XXX.165和10.XXX.XXX.157，我們針對其流量作了進一步的分析。

客戶端10.XXX.XXX.165使用流量情況如圖4-5所示。

圖4-5如上圖所示，在異常發生期間，客戶端10.XXX.XXX.165和營銷服務器10.XXX.XXX.11共產生了3591個會話，會話流量從數十KB至數百KB不等，按會話產生的流量進行排序，如圖4-6所示。

圖4-6流量最大的客戶端通過4530端口訪問服務器7001端口的會話，共產生了2665個數據報文，流量為2.259MB，對其進行解碼時發現了異常情況，如圖4-7所示。

圖4-7如圖4-7所示，該會話過程持續了25秒，會話開始客戶端與營銷服務器10.XXX.XXX.11建立連接后，客戶端在0.017秒后發送了GET請求，請求內容為

GET/j2yd/_assembleLib/systim/fmGrid/lookAndFell/image/btn.jpg

服務器在0.001秒內進行了應答，并開始傳輸數據，數據內容在0.03秒內傳輸完畢，客戶端又發起了相同的請求，如圖4-8所示。

圖4-8如圖4-8的①處所示，對比上一次的發送時間可知，每隔0.03秒客戶端會向服務器發起一個重復的GET請求，請求的對象是“btn.jpg”文件。

我們對相關的會話過程進行了排查整理，發現3591個會話過程中，有3330個會話都一直在請求該文件，剩余261個會話都是故障發生期間客戶端發起的TCP連接請求。如此大量的請求數據，客戶端是在做什么呢？

“jpg”是以24位顏色存儲單個光柵圖像的一種圖片格式，同時我們發現某些客戶端請求相同的文件，卻并沒有同樣的異常行為，見圖4-9。

圖4-9如圖4-9所示，該客戶端請求相同的對象，但是僅重復了3次，會話過程沒有出現前文所述的異常。

如果不了解應用特征，則很有可能找錯方向。供電局負責營銷應用的工程師為我們講述了該文件的作用：從某供電局營銷系統應用的角度來看，這些請求的發出，代表的是營銷應用客戶端模擬點擊按鈕的操作，我們知道請求了“btn.jpg”文件，要找到其關聯的“.do”或者“.js(p)”文件。通過數據解碼，如圖4-10中②處所示，我們發現該請求是

referer：“1:7001/j2yd/dfScatterRecomShouldAction.do?actionType=GENSHOULD”。也就是說該動作導致了客戶端發起“GET…btn.jpg”指令。

圖4-10為了得到更直觀的指向，我們針對所有會話進行了排查，發現在某些會話過程中(如圖4-11所示)，開始期間客戶端與服務器的數十次的請求應答，雙方行為都較為正常可是到第33次請求的時候，客戶端向服務器發送“POSTj2yd/dfScatterRecomShouldAction.do”的請求，收到服務器200OK應答后，就開始了不斷地請求btn.jpg文件。

圖4-11因此我們認為，這些大量的異常重復的“GET…btn.jpg”的請求，與j2yd/dfScatterRecomShouldAction.do有關。

另外，客戶端10.XXX.XXX.157和10.XXX.XXX.149與服務器的會話情況分別如圖4-12、圖4-13所示。

圖4-12

圖4-13我們發現，只要“GET…btn.jpg”是referer：“http://10.XXX.XXX.11:7001/j2yd/dfScatterRecomShouldAction.do”的操作，均會出現前文所述的不斷密集重復請求的異常。

大量的異常請求，很有可能導致應用系統的異常，建議管理員對該操作進行排查。

(從英文字符的意思來看，df表示電費，Scatter表示分散，Recom含義不詳)4.2.3營銷應用其他服務器的排查

相同的異常在營銷應用的其他服務器上也有體現。如圖4-14所示，某些客戶端流量遠高于與這臺服務器相連接的兩臺數據庫服務器10.XXX.XXX.14和10.XXX.XXX.16的流量。

圖4-14這些客戶端也是在向服務器大量重復請求“btn.jpg”文件，見圖4-15。

圖4-15

4.3.1故障說明

經過排查，定位出錯的程序為“電費管理系統”的“分散復核明細查詢”功能模塊。4.3分析結論4.3.2優化后監測

我們在監測后期看到各客戶端訪問營銷服務器的流量持續下降，異常流量的減少，很有可能與故障發生后系統管理員對營銷應用進行了一系列的優化調整有關，如圖4-16所示。

圖4-16發生故障時，