DIV CSS 佈局教程網

正文

1、 監控系統架構

經歷了許多公司，監控系統大概都是從無到有，該經歷的也都經歷了。所謂監控系統，大概的架構如下：

◆在服務器布置一個Agent，它負責采集數據；

◆由網上轉發到一個分布式管道再轉接，就像搭積木一樣；

◆進行匯總；之後把監控數據分兩個部分

●一是數據庫存儲，主要做監控數據展示和後續排查問題。

●二是制定很多的監控的報警項。

做一些簡單的，像CPU超過90%就會報警；還有一些復雜的，像60秒之內超過兩次。後來也會支持一些集群類的報警監控。這個模塊也是很簡單，它主要就是在若干的文件的公式，然後進行監控數據的判斷，判斷之後發現了異常，就會產生一些消息，然後上一個模塊。我們只是進行判斷，不進行報警。之後會有一個模塊進行各種後端的報警，像現在一些公司 有微信報警、短信報警等等的，都在這部分支持。

◆存儲部分

豆瓣、百度、360等等，後端瑣碎的事比較多，但是也有用MySQL的。實際上這部分也很簡單，可以認為是一個分布式的Linux，就是把一些數據往文件數據庫裡傳，上面是一個WEB端。以上是大概架構。

2、 設計思路

◆每一個模塊就干一件事，把這件事干得精細和優秀。

●之後會細化一下模塊裡的具體內容。

●要scalable，flexible，可以任意橫向擴展，適應各種防火牆ACL。

●在360的時候機房比較多，各種防火牆的ACL非常多，360下還有很多子公司，會出現各種訪問的現象。要適應各種系統，就會通過一些模塊來適應。

◆注重代碼復用。

一套系統除去網絡框架，每個模塊的代碼都在100行，而且是C語言寫的。我們最後把這個網絡框架都做在了一個網絡庫，這個是多線程的。

3、 這個系統面臨什麼難點？

技術量。

就藝龍而言現在系統規模較小，每天產生160GB，360是500GB/天，百度離開太久了就不清楚了。這個數據量還是稍微比較大的，就是這個系統是人為造的DDoS系統，每個監控端采集項目，我們在藝龍比較少，這種比較少，每個服務器上監控項大概二百多個，默認的頻率是5秒鐘一次的采集點。可以說每秒鐘大概有40多條數據的采集。

這個系統基本上不能做Cache，必須實時運算。因為服務器監控系統，我們做服務端應該都知道，延遲報警，還不如不報。報警一旦出了問題，就要盡可能快的把這個東西報出來。除非是一些不可控的因素，如短信網關，或者運營商短信發送延遲等。結論是，90%都要在15秒之內保證大家手機能收到。這對我們在各種環節下盡量減少各種各樣的延遲什麼的提出較高的要求，換言之，高可用。這種監測系統作為一種服務器的基礎架構存在，可用性必須比線上高，因為它發揮最大作用的時候都是公司出了大問題的時候，這個時候必須要扛的住各種各樣的網絡情況，把真實的情況反饋過來。對於這種線上的可用性要求高於線上服務至少一個數量級。像CPU連續5次90%不報警，如果我們這個數據裡有任何丟點，可能會導致報警報不出來。因而對於數據的完整性要求也是比較高的。就是在任何一個模塊宕機或者網絡隔離，這種情況下也不允許出現任何的丟失。

高吞吐。

因為這個系統是典型的寫的比較多，讀非常非常隨機的過程。讀取決於大家對數據項的查看，匯總，畫圖的需求。所以基本上一個月之內的數據需要隨時的調出來。高吞吐也是我們面臨的主要問題。

多平台。

百度用的是Linux，Windows用的比較少。百度的挑戰在於機器比較多，像千分之一的情況在百度基本每天能出個一百台。之前我們同事做過一個分享，就是說一些經驗。在服務器吞吐量特別大的時候，千分之一的情況也要考慮。360是FreeBSD。藝龍是Windows，大約占服務器的一半。

4、解決方案