WEB監控體系之設備負載監控（來自深空老大）

第一次寫和工做密切相關的文章，卻無從下手，胡亂寫起，純當總結。

設備負載監控屬於硬件級的基礎監控，比設備基礎監控粒度要粗一些，屬於設備基礎監控上一層的硬件監控，適合於數量較大、具備集羣特性的硬件綜合指標監控。固然，其監控數據來源仍爲單機設備基礎信息。

單機基礎硬件指標大概包括CPU使用率、內存使用率、磁盤I/O、磁盤空間使用率、網卡出入包量、網卡出入流量、平均負載等。那麼各類業務邏輯可能對這些指標都會有所側重，例如WEB服務器比較側重CPU、包量、流量，而DB比較側重磁盤I/O、CPU使用率，CACHE則更關注內存使用率、CPU使用率等。對於數量龐大、類型不一的服務器，不可能關注到這麼細緻的數據信息，因此必須在幾個維度進行彙總以便更好實現服務器管理。

那麼設備負載監控系統的設計目標是什麼呢？大概總結有如下幾點：
一、減小管理單元，提升維護效率；
二、方便查看業務整體負載情況；
三、儘快發現高負載設備以便及時增長設備緩解業務壓力；
四、減小空閒設備量，提升設備複用率，下降設備成本；
五、發現負載均衡方面的問題

要實現以上幾個目標，首先須要將服務器分門別類。如WEB、DB、CACHE、業務邏輯等。上面提到，這些設備應該具有集羣特性，其大概形式以下：

集羣示意圖

如上圖所示，除灰色部分外，該集羣擁有4臺同樣的設備，每臺設備上均安裝有一、二、3三種軟件，這樣這些設備的正常運行情況應該基本一致。當該集羣呈現負載較繁忙的情況的時候，能夠比較容易複製1-4號設備以增長一臺同樣的5號設備來下降業務負載。而當該集羣負載較空閒的時候，能夠將第4號軟件部署於該集羣下以充分利用設備性能。

在該集羣負載均衡的情況下，單機的負載情況表現出來的特徵，應該就是該集羣的負載特徵，經過管理集羣便可映射到管理單機設備，假設有1000臺設備，每一個集羣50臺，那麼只須要管理20個集羣便可，管理單元明顯減小。

在現實狀況下，其實沒法達到百分百負載均衡，因此仍是須要一些算法計算集羣的指標。最基本的算法就是MAX、MIN、AVG了。這三個基本能夠處理90%以上狀況。我曾經設計過比較複雜的公式支持，後來發現基本上用不上。固然算法越粗暴偏差越大。如使用MAX計算CPU使用率，那麼假如該集羣下某臺設備因爲特殊緣由CPU一直佔用較高，那麼表如今集羣上的CPU使用率也會較高，而實際狀況可能這個集羣相對空閒。而使用AVG求平均數值，那麼一些異常設備將會被淹沒不能及時發現，因此這裏須要根據業務特性作一些權衡和取捨。固然不建議使用更復雜的算法，由於配置維護成本比較高，並且數值計算結果不直觀。

爲了修正個別設備引發集羣高負載的問題，引入了高負載設備數的指標。假如該集羣負載較高且高負載設備數也高於某個比例（如50%）則認爲該負載值準確描述集羣壓力情況。

接下來看看實際指標的計算方法。

首先是負載值的定義。考慮到單機指標太多，業務複雜，因此一概是用百分比來反映負載情況。如10%負載、80%負載、200%負載等。這樣單位統一直觀。而不須要去考慮具體單位和具體數值。以CPU使用率爲例，假設當CPU使用率爲80%的時候，負載爲100%，那麼將80定義爲CPU使用率的基準值，當CPU使用率爲40%的時候，計算出來的負載爲50%，而當CPU使用率爲100%時，計算出來的負載爲125%。一樣其餘指標須要定義一些基準值作爲負載100%的值。例如百M網卡定義80M爲100%負載等。

這樣單機全部基礎指標都可以使用百分比表示，CPU使用率、內存使用率、磁盤I/O、磁盤空間使用率、網卡出入包量、網卡出入流量等均換算成負載比例，根據設備所屬類型（WEB、DB、CACHE、邏輯等）設計權重結合計算公式獲得單機負載值，如：

單機負載 = AVG(CPU使用率*權重/CPU使用率基準,出流量*權重/出流量基準…);

實際上單機負載的做用只在於計算高負載設備數。由於這樣的計算方式累加到集羣中的負載值偏差會偏大。爲了修正這一問題，引入集羣指標負載的概念，即：集羣的CPU使用率負載、集羣流量負載等，因爲同一集羣的各項指標較相近，這樣將同類型指標進行疊加，減小偏差，其公式以下：

集羣CPU使用率負載 = AVG(設備1CPU使用率/CPU使用率基準,設備2CPU使用率/CPU使用率基準,…);

從業務結構上看，會有以下關係圖：

邏輯結構示意圖

以上爲現階段使用的計算關係圖，還有另一種偏差較大的關係圖以下：

單機管理關係圖

上圖設備負載計算主要用於單機負載管理上，實際從單機負載直接計算集羣負載的偏差會較大，因此通常會採用前一種計算邏輯。不過視圖2還能較爲直觀反映某一集羣的負載均衡問題。

實際上負載監控的做用遠遠高於其起初設計目標。隨着業務的增加，能夠看到集羣負載也隨之增加，雖然有波動，可是經過計算後仍會隨着業務增加表現出增加趨勢，那麼系統就能夠根據近一段時間內的負載增加情況，結合業務實際增加情況，預測出將來該集羣所要達到的負載值，當超過一個臨界值的時候（如80%負載），能夠有計劃的實行擴容操做（增長設備），而不是等到業務忽然呈現高負荷、穩定性下降的時候，才緊急進行設備擴充。

關於負載預測，我在以前有提到過，我是使用線性迴歸方法計算的，其中最小二乘法計算公式以下：

最小二乘法公式

下面代碼簡單枚舉歷史10個點來計算該設備負載增加率：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

//Y座標值表示設備歷史負載 $y = array (52.09, 52.4, 53.29, 54.22, 55.15, 55.83, 56.89, 56.98, 57.55, 57.8);    //X座標值表示順序天數 $x = array (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);    //計算X和Y均值 $ax = array_sum ( $x )/ count ( $x ); $ay = array_sum ( $y )/ count ( $y );    //計算斜率公式中的分母(em)和分子(ez) $em = 0; $ez = 0; for ( $i = 0; $i < count ( $x ); $i ++) {      //分母求和      $em += (( $x [ $i ] - $ax ) * ( $y [ $i ] - $ay ));      //分子求和      $ez += pow(( $x [ $i ] - $ax ), 2); }    //斜率0.69 echo $em / $ez ;    //第十一個點預測負載值58.34 echo $em / $ez * 10 + $ay - ( $em / $ez )* $ax ;

理想情況下，將負載維持到一個穩定的值，使得設備使用率達到最高，且業務穩定正常，是一個長期的調整過程，經過不斷的增減設備--增長設備以下降負載，減小設備以提升設備使用率，下降設備成本。這是一個多方面的協調工做，不是一個負載監控系統能解決的，可是負載監控提供基礎的數據支持，可大大提升業務穩定性，減小突發故障，從而提升業務可用性。這裏基本須要一些輔助功能的支持：
一、經過每日高、低負載設備數累計季度總高、低負載設備數來考覈運維人員，以便及時處理高、低負載設備，將集羣負載維持在一個相對穩定的範圍，並消除明顯的負載不均衡情況；
二、每日處理重點業務高負載設備，或者負載異常設備，提升業務穩定性。一般負載異常每每能反應軟件故障，如CPU使用率一直100%而流量很是低，則多是軟件BUG致使，及時推進開發人員處理軟件BUG或者優化軟件以提升設備使用率和增長業務可用性；
三、定時、有計劃的（如一個月一次）對高負載集羣進行設備擴充，能大大下降臨時擴充設備的維護成本，並減小臨時資源池設備量以下降設備成本；
四、定時對低負載集羣進行合併、下線，減小集羣數從而減小管理單元，並增長設備利用率以下降設備成本；
五、系統建設初期還會涉及到覆蓋率問題，及時分享業務的負載監控覆蓋率，推進業務運維接入，以便能實現100%覆蓋，以提升監控能力。

那麼，在系統建設過程當中還會碰到哪些問題呢？可能基礎數據準確性是個比較重要的問題。因爲單機設備硬件基礎指標在一天內波動可能會比較大，因此須要對一天所採集到的基礎數據進行處理，如消峯、去毛刺，將一些明顯異常點去除，取一個較高點作爲採集結果數據，以避免獲得一些高得恐怖的負載值。負載監控在實時性要求上並無特別的高，對於長期優化目標來看，只須要按天粒度便可，固然因爲其計算的合理性，逐漸提升其監控及時性，如按小時監控粒度，以便能更及時的瞭解到業務運行情況，這種狀況通常用在業務放量、新業務上線、設備擴充後的負載實時監控上，以便做出更快的反應。

另外在集羣的劃分、歸屬、分類、合併、共享上，也就是基礎配置、關係數據上須要比較細緻的維護，目標是作到儘量的標準化，各個集羣既要功能單一獨立，在橫向上具備強的可擴充性（圖1橫向），又要可以提供公用以提升設備複用率，如多個集羣的合併（圖1縱向）。這個涉及到各個業務邏輯的設計，推進業務邏輯按照這種方向進行部署，這樣在自動擴容上能達到更好的效果。當集羣負載達到必定的數值，會自動調度設備緩衝池裏的設備，根據已有的集羣內設備的軟件配置，自動初始化並接入業務運營，以達到設備自動調度擴充的能力。

負載監控做爲一個長期性和及時性兼顧的監控系統，不只在提升業務長期穩定性上發揮重要做用，更在預算、成本優化上提供了很是有力的數據支持，並且在將來自動調度擴容的可行性上給出了明朗的答案，是一個銜接業務監控和基礎硬件監控的重要基礎監控系統。