曬一下我的監控系統

背景

     一般情況下，由于伺服器環境或者程式漏洞的問題，現行的系統多多少少會發生一些預料以外的異常或者bug，給使用者體驗甚至利益造成影響。而現在的第三方監控工具大多是關于伺服器硬體資料監控。對于業務方面、例如每日訂單的資料量、Mq中的要求退款的隊列長度...還是比較薄弱。這套系統的作用就是在第一時間捕獲工程師可以考慮到的系統風險異常。

結構草圖

　　監控系統的結構整體分為4塊：1.監控web應用站點為背景主要程式負責各個監控邏輯的政策配置、監控跟蹤、報表履曆以及使用者、權限等等傳統的資訊流管理；2.監控webservice提供監控系統的采集以及政策配置的更新标志；3.報警win服務，根據各個政策規則對采樣進行比對分析，并進行郵件或手機報警；4.用戶端監控代理，負責用戶端的實際采集動作。     系統的難點在于設計、性能、并行、瓶頸等方面，例如用戶端與伺服器端時間不比對的場合，報警的準确性、報警的人性化配置、采樣程式的性能、監控與代理的銜接等等。或許系統可以優化的地方還有很多吧。

DEMO概要流程

 step1.選擇監控設定 目前系統支援資料庫、MQ、記憶體、Cpu、檔案監控

<a href="http://pic002.cnblogs.com/images/2011/87114/2011111313235115.jpg" target="_blank">檢視原圖</a>

step2.添加監控，根據類别 我們以資料庫為例

<a href="http://pic002.cnblogs.com/images/2011/87114/2011111313415367.jpg" target="_blank">檢視原圖</a>

step3.添加sql配置政策 不同的監控類型配置不同的政策規則 資料庫類型0為MSSQL, MSSQL支援sql語句和存儲過程，監控類型1為sql語句

<a href="http://pic002.cnblogs.com/images/2011/87114/2011111314010362.jpg" target="_blank">檢視原圖</a>

step 4.配置完監控政策規則 設定報警政策 監控标準值為參考基準 例如設定大于5 當我們sql語句采集的值大于5時觸發報警政策

報警方式目前支援郵件和手機短信。報警時間根據業務場景設定，這裡模糊的意思是忽略、有時候波峰或者谷底的值比較離譜根據實際場景設計模糊次數

step5.添加聯系人

step6.在應用端安裝監控代理

step7.檢查服務

step8.服務端安裝監控服務

step9.啟動服務檢視報表 以及報警相關 因為蟲子本機沒有手機服務引擎也沒郵件服務 是以就拿以前的截圖充數一下

step

 概要設計以及問題點

 1.報警服務需要考慮一下幾個問題。報警的執行是設定在用戶端還是伺服器端？如果是用戶端，那麼用戶端伺服器直接當掉了怎麼辦？如果是伺服器端，如何能比對及時的資訊，監控主程的采集接受用戶端的資料，時間不比對怎麼辦？如果時間作為參數傳給web服務，伺服器端的監控check如何保證即時？對于以上問題，demo中的處理方法不一定好，大家有空一起交流下。Demo的處理方法是報警執行在伺服器端，web伺服器采集資料時忽略用戶端時間以伺服器端時間為準。即時監控的問題比較頭痛。目前demo中在服務啟動時加載所有監控配置，并且根據加載的資訊對每一條監控配置設定一個異步線程。監控的主要邏輯在存儲過程中完成。因為監控采集的時間與監控check的時間存在時間差，是以我将check範圍設定為1分鐘之内的最新值。 隻要能保證check端的更新頻率比采集端的快，就能保證到每一條資料都能被check

2.報警資訊的人性化處理人為可控的設計報警的時間間隔與次數。目前demo的處理時有bug的，暫時先不調整了。Demo的處理時在每次發生監控異常時，在伺服器端加載2個緩存項，一個是發現異常的時間，一個是系統設定的發送總次數。每次進入報警流程，判斷目前時間與緩存時間的差，如果在設定的間隔時間内忽略。第二層是發送總次數，先判斷緩存值，如果為空，加載系統配置最大發送次數，沒發送一次-1，如果超過總次數忽略。緩存時間24小時。bug點： 每次進入報警流程比較是發現異常，如果采集的資料第一條為異常，第二條為正常，那麼就不進入報警流程，就隻發一次了。現在的想法：報警流程與監控check流程分開獨立，報警的流程方式可以使用類似站内信的方法，報警資訊全部存入mq，異步處理。

3.監控采集的性能方案demo中的處理方法是按監控配置類别分線程，現在提供cpu和記憶體監控，那麼就是2個線程在跑。demo的循環采集并未使用計時器，全部使用while（true）死循環，有同學有好的方法可以提議下。而且cpu監控和記憶體的方式差異比較大，記憶體的監控每次循環都可以用新的執行個體，cpu監控每一次新的執行個體初始值都是0，在不使用單例的情況下，cpu的監控使用計時器肯定是不行的

4.監控配置的方案

Demo中每個用戶端每個大類隻能有1種監控配置，例如隻有1個cpu監控，一個sql監控等。Sql監控中可以可以配置多個下級監控配置，例如監控a監控Q1資料庫，監控b監控Q2資料庫。Cpu和記憶體監控沒有下級監控配置。直接進入報警政策配置。

也就是   用戶端(1)&lt;----&gt;(N)監控配置(1)&lt;----&gt;(N cpu和記憶體是1)監控政策(N cpu和記憶體是1)&lt;----&gt;(1)報警政策(1)&lt;----&gt;(1)聯系人資訊

5.監控與代理的銜接

Demo中，監控主程将代理類MonitorC序列化，通過http方式由代理端請求獲得。還有就是同步問題，因為監控主程的配置其實是很少改動的，是以代理端長期都是保持一個相同的資源配置，但是如何使代理端在不影響性能的情況下同步最新的主程配置。目前demo中式定期更新緩存。

現在的想法是另開一個線程，然後用一個全局變量來控制是否讀取最新的主程資源

6.監控采集

通過webservice處理代理端的請求，入庫。根據類型分表，View_Cpu、View_Mem、View_Sql、View_File等 表結構都一樣。根據背景配置另開服務定期清理資料庫資料

以上是demo開發過程中遇到的部分問題和臨時個人的解決方法。大家交流一下可以發現好的方案，一起學習。

本文轉自 熬夜的蟲子  51CTO部落格，原文連結:http://blog.51cto.com/dubing/713263