分佈式監控開發 01 需求

 

爲何要作監控？ 

zabbix已經這麼強大了，爲何要寫一個監控

首先來講說zabbix的痛。

1. 性能瓶頸。zabbix是使用MySQL來存放監控歷史數據的。一臺機器假設有100個監控項，2000臺機器，就是20w監控項，監控系統的數據採集沒有高峯低谷，是持續性的，週期性的，通常是一分鐘採集一次。機器量愈來愈大，數據量就愈來愈大，MySQL的寫入逐漸成爲瓶頸，業界有一些proxy的方案，也只是治標不治本。zabbix有些數據採集是經過pull的方式，也就是server端主動探測的方式，當目標機器量大了以後，這些pull任務也常常出現積壓。
2. zabbix有些易用性問題。好比zabbix的模板是不支持繼承的，機器分組也是扁平化的，監控策略不容易複用。zabbix要採集哪些數據，是須要在server端作手工配置的。
3. 有些公司還須要業務的監控，好比某個thrift rpc接口，每分鐘調用的cps，latency，某些url的5xx、4xx咱們也但願作監控，某個開源軟件，比redis、openstack、mysql的一些狀態統計數據
4. zabbix的大屏是個問題。雖然有些二次開發的界面很是棒

說了這麼多很差的地方，只是在某些big的時候很差而已，咱們本身寫的話，短時間內也是不可能超越zabbix的。那麼爲何要手寫一套監控呢？

 

一、熟悉IT監控系統的設計原理

本身寫的時候確定有不少事更zabbix相匹配的。

 

二、開發一個簡版的類Zabbix監控系統。

爲之後團隊寫監控作準備.zabbix在2K以上數量機器的時候，明顯會吃力。小米也正是因爲這個本身寫了open-falcon。那麼若是之後咱們遇到大數量的服務器的時候，徹底也會基於公司的業務去寫一個監控。

那麼如今練練手也是徹底OK的。

 

 三、掌握自動化開發項目的程序設計思路及架構解藕原則。

    

 

監控系統需求討論

1.可監控經常使用系統服務、應用、網絡設備等

2.一臺主機上可監控多個不一樣服務、不一樣服務的監控間隔可不一樣

3.同一個服務在不一樣主機上的監控間隔、報警閾值可不一樣

4.能夠批量的給一批主機添加、刪除、修改要監控的服務

5.告警級別：

• 不一樣的服務 由於業務重要程度不一樣，若是出了問題能夠設置不一樣的報警級別
• 能夠指定特定的服務或告警級別的事件通知給特定的用戶
• 告警的升級設定

6.歷史數據 的存儲和優化

• 實現用最少的空間佔用量存儲最多的有效數據
• 作到1s中以內取出一臺主機上全部服務的5年的監控數據（採用redis存取模糊點的方式）

7. 數據可視化，作出簡潔美觀的用戶界面

8.實現單機支持5000+機器監控需求

 

9.實現主動以及被動監控方式

 

10.實現監控服務器的水平擴展

 

 

採用什麼架構？

1. Mysql存儲主機配置項對應關係
2. redis存儲歷史數據
3. 支持服務端主動的監控方式（SNMP/PING)以及客戶端被動的發送數據
4. 採用HTPP的通訊方式

 

採用HTTP好處

1.接口設計簡單

2.容易水平擴展作分佈式

3.Socket穩定成熟，省去較多的通訊維護精力。不用本身從socket底層寫起

 

Http特性：

1.短鏈接

2.無狀態

3.安全認證

4.被動通訊