容量管理系統設計方案

版權聲明：本文由謝海林原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/218

來源：騰雲閣 https://www.qcloud.com/community

 

容量管理從本質來說，主要須要解決的問題是系統「亞健康（有病，但還不影響生活和工做）」的狀況下，咱們可以及時知道，並作出對應策略，確保系統恢復到正常順暢；本方案主要是講的第一部分，「咱們如何及時知道、並告警/預警」，不涉及到「容量處理策略」；

一.主要問題場景：

實時系統：

能提供服務，可是速度較慢；

隨着業務的逐漸發展，一路上升都提供良好，可是離懸崖慢慢靠近（用一個舉重運動員的話說，在壓一塊金牌在槓鈴上，就倒了）；

業務突發增加，致使短期內，系統資源耗盡，服務質量嚴重降低；

離線系統：

隨着業務的發展，在約定時間內逐漸沒法完成任務（例如：1個小時跑一次的數據統計，隨着業務增加，沒法在1個小時內完成）；

依據以上問題場景，數據容量系統定義如下目標，並以此目標爲驗收標準；

二.數據容量系統的目標：

核心目標：

容量實時監控；

容量按天日報，瞭解到目前系統在資源和業務方面的容量百分比，處理取於高負載的設備或者是模塊；

附加目標：

成本控制，經過對低負載模塊的展示，整合機器利用率，有效控制成本；

三.容量管理方案

針對實時系統，主要採用一下三種方式來達到要求：

自動化測試監控添加測速和時耗告警；（知足場景1、告警時間2分鐘）

針對外網服務，自動化測試監控平臺提供模擬用戶角度從外網IP訪問網頁（目前主要是針對pay、積分、support、service四個外部網站），而且對時耗作了收集和告警；

針對後臺服務，自動化測試監控平臺提供模擬客戶端從內網IP訪問服務端，針對全部實時系統都添加了核心功能的自動化測試，而且對時耗也作了收集和告警；

針對基礎資源的實時告警（知足場景3、告警時間5分鐘）

針對基礎資源的實時監控，主要有如下幾種：

1. 部門默認在tnm2平臺上統一配置的告警策略
   單機cpu使用率：使用率大於等於95%，連續20分鐘，短信告警

   單機cpu負載： 負載大於等於4，連續20分鐘，短信告警

   單機應用內存使用率：使用率>85%,連續20分鐘，短信告警

   單機外網流量告警：
   當前流量>=200%*上週同天同點，連續出現30分鐘，則短信告警
   當前流量<20%*上週同天同點,連續出現30分鐘，則短信告警

   單機硬盤使用率：
   使用率>95%，直接上報noc
   使用率>90%, 預警發短信

2. 針對OS層面，自行腳本資源配置

   fd使用量：
   單個進程，超過"ulimit -n"最大限定值的90%，則短信郵件告警機器負責人；

   內存使用量：
   單個進程，物理內存使用量超過 /bin/free | grep Mem | awk '{print $2}' 的90%，則短信郵件告警機器負責人；

   swap使用量：
   一臺設備，若swap使用率超過1/2,則短信郵件告警機器負責人；

   共享內存使用量：
   一臺設備，若共享內存個數使用超過/usr/bin/ipcs -m -l | grep "number of segments"最大限定的90%，則短信郵件告警機器負責人；

   信號量使用量：
   一臺設備，若信號量使用超過/usr/bin/ipcs -s -l | grep "number of arrays"最大限定的90%，則短信郵件告警機器負責人；

   消息隊列使用量：
   一臺設備，若消息隊列使用超過/usr/bin/ipcs -q -l | grep "max queues system"最大限定的90%，則短信郵件告警機器負責人；

   消息隊列未處理量：
   一個消息隊列，若未處理消息數>50個，則短信郵件告警機器負責人；

   tcp鏈接數數（close_wait狀態）
   一臺機器tcp鏈接數（close_wait狀態）數量超過ulimit -n的最大限定值的60%，則短信郵件告警機器負責人；

採集容量數據，按天計算容量百分比，並預警已經取於高負載的模塊和設備（知足場景二，預警時間1天）

1. 容量採集數據以及方式：

   硬件相關的基礎資源：都可經過網管後臺獲取採樣值。
   關鍵指標：CPU使用率、CPU負載、外網入流量，外網出流量、應用內存使用率、磁盤利用率

   OS相關的基礎資源:設備從本機做爲特性上報到公司網管，容量從網管後臺取得采樣值；
   關鍵指標：FD、TCP鏈接數、mysql鏈接數

   業務特性：設備從本機做爲特性上報到公司網管，容量從網管後臺取得采樣值；
   關鍵指標：請求量數、平均時耗、佔用計算資源、失敗率

2. 計算每日負載值：
   

3. 輸出物：
   設備負載日報(高負載管理、低負載管理)
   業務模塊負載日報

針對離線系統，主要採用如下方式要求：

離線任務執行時耗超過最大值，直接告警（知足場景5、告警時間2分鐘；預警時間1天）

採用service收集離線任務開始時間、結束時間、執行時間標準

採用公共工具部署在每臺服務器上，各自任務自行上報開始時間點，結束時間點

四.結束語

本方案僅僅涉及到「容量問題告警、預警」的內容，部門在這一塊纔剛剛起步，特別是問題出現以後的"定位、處理"尚未定論和統一解決方案，另外，容量管理系統的client端很是多，如何簡單有效的管理這些client端也是個挑戰。還但願你們可以有好的想法、建議，能夠和hairy這邊交流，讓容量管理在「減小故障發生、下降故障影響」等方面發揮大做用。