背景
一般情況下，由於服務器環境或者程序漏洞的問題，現行的系統多多少少會發生一些預料以外的異常或者bug，給用戶體驗甚至利益造成影響。而現在的第三方監控工具大多是關於服務器硬件數據監控。對於業務方面、例如每日訂單的數據量、Mq中的要求退款的隊列長度...還是比較薄弱。這套系統的作用就是在第一時間捕獲工程師可以考慮到的系統風險異常。
結構草圖
監控系統的結構整體分爲4塊：1.監控web應用站點爲後臺主控程序負責各個監控邏輯的策略配置、監控跟蹤、報表履歷以及用戶、權限等等傳統的信息流管理；2.監控webservice提供監控系統的採集以及策略配置的更新標誌；3.報警win服務，根據各個策略規則對採樣進行匹配分析，並進行郵件或手機報警；4.客戶端監控代理，負責客戶端的實際採集動作。 系統的難點在於設計、性能、並行、瓶頸等方面，例如客戶端與服務器端時間不匹配的場合，報警的準確性、報警的人性化配置、採樣程序的性能、監控與代理的銜接等等。或許系統可以優化的地方還有很多吧。
DEMO概要流程
step1.選擇監控設置 目前系統支持數據庫、MQ、內存、Cpu、文件監控
step2.添加監控，根據類別 我們以數據庫爲例
step3.添加sql配置策略 不同的監控類型配置不同的策略規則 數據庫類型0爲MSSQL, MSSQL支持sql語句和存儲過程，監控類型1爲sql語句
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)<---->(N)監控配置(1)<---->(N cpu和內存是1)監控策略(N cpu和內存是1)<---->(1)報警策略(1)<---->(1)聯繫人信息
5.監控與代理的銜接
Demo中，監控主程將代理類MonitorC序列化，通過http方式由代理端請求獲得。還有就是同步問題，因爲監控主程的配置其實是很少改動的，所以代理端長期都是保持一個相同的資源配置，但是如何使代理端在不影響性能的情況下同步最新的主程配置。目前demo中式定期更新緩存。
現在的想法是另開一個線程，然後用一個全局變量來控制是否讀取最新的主程資源
6.監控採集
通過webservice處理代理端的請求，入庫。根據類型分表，View_Cpu、View_Mem、View_Sql、View_File等 表結構都一樣。根據後臺配置另開服務定期清理數據庫數據
以上是demo開發過程中遇到的部分問題和臨時個人的解決方法。大家交流一下可以發現好的方案，一起學習。