案例藝龍十萬級服務器監控系統開發的架構和心得

正文

1、 監控系統架構

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

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

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

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

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

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

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

◆存儲部分

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

2、 設計思路

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

●之后會細化一下模塊里的具體內容。

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

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

◆注重代碼復用。

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

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

技術量。

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

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

高吞吐。

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

多平臺。

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

4、解決方案

針對數據量，HBase，自定義協議減少Overhead。數據量這個問題不大，用的技術在于說，監控數據的傳輸，根據一些私有的協議，也是一些歷史原因，當時用Json很多。也嘗試過用別的，但是對監控系統有時候，比如出丟點，像追的時候Json可以，用別的就追不上了。

高實時。對等多線程異步非阻塞、實時計算、長連接。我們這個系統不能用一些很高延遲的東西，比如說卡羅普你想都不用想了，還有像現在比較火的流式系統，所以也沒有采用。

高可用。我們這個系統不能有單點，而且有一個要求，你是同一個機房，不能降級。就是如果這個機房停電了，這個機房不監控也罷，但是你得知道它停電了。但是剩下的機房必須保證監控沒有受到任何影響，而且還要保證15秒這個事。這是我發明的詞，“惰性智能選路”這個其實也很簡單，什么叫惰性呢？像網絡掛了，連不上了，我們Agent可以連到別的上，這個很簡單，就是我們想辦法讓Agent讓它知道有這個的存在，我們不用DS傳統方式。我們啟動的時候，或者哪兒出了問題，我們拿到另外一個連，這個策略非常簡單，但是這個東西作為一個接口，以前的Agent，由于網絡斷了會試下一個，就是最終會遷移到離它最近的，網絡狀況最好的，就是很默契的達到智能，而不用考慮它跟誰連接。同樣的，下游往上游發的時候也是用的相應策略。還有高可用，我們要保證這個數據不能丟。就是有一點必須要保證，就是這個監控數據由于第一手拿到的都是本機的一些Agent，這個Agent必須保證數據到了讓報警的那個模塊拿到。我們這個就是Agent拿到這個數據之后，翻譯的這個模塊只會進行轉發，上面的收到確認之后傳過去，最后再給。保證這個數據一定到了上游。由于這種東西的強保證，所以說也會導致性能上的困境，就是說我們要保證數據不丟，又要保證高性能，這后面我們再說這個是怎么做的。

高吞吐。cache，還是cache。沒有什么好說的，覺得一般cache能解決的高并發都不是難點。

多平臺。當時我們做這個的時候golang還沒出來，所以都是用的C++。時間計數器一出問題什么都出了問題，時鐘不好了，定時器到計算性能全都完蛋，Windows是一個非常坑的平臺，后來幸虧有了golang，避免了Agent只能找非常厲害的人寫的局限。

5、 如何優化性能？

◆zlib流式壓縮

這個寫起來沒那么好弄，但是聽起來挺簡單的。

◆pipeline滑動窗口

●之前說從Agent采集到數據，經過層層模塊轉發，這樣就會導致請求和回應的延遲會非常大，在大延遲的情況下怎么保證高吞吐量，于是發數據的時候，比如在翻譯模塊都是進行批量轉發，那邊回一個Ok。工程師說，在應用層又造了一個TTP，這個東西比較無聊。

◆協議改造，Protobuf

◆數據合并

◆function-filter優化，當時優化也走了很多彎路：

●profiler，現在CPU行為不是教科書里說的那些東西，現在CPU的架構體系不是常人能理解的了。我們的想法是各種都去嘗試，最終選擇好用的。

●分布式改造，這個容易降低速度，最終沒有再嘗試。

6、走過彎路的感想

所謂簡潔即可靠，我們曾經做這種東西的時候，就是關于數據轉發和怎么弄曾經做了一些版本，也走了一些彎路，慢慢發現搞的越復雜坑越多，特別是在限制要求特別高的情況下，最后返璞歸真，不斷優化，出來的就是每個模塊極其簡單，感覺就是分布式管道，都可以在linux系統里找到影子。做到簡潔，因為有的模塊，我們寫代碼都知道，從產品來看，就是從這兒到那兒。寫代碼如果在設計上復雜化，很多東西都繞，加班加點也不一定能搞明白。因此現在藝龍考慮的就是從簡潔出發，不要搞復雜的東西。

結語：十萬級服務器監控系統開發架構尚可繼續完善，愿來日更上一層樓。

關于作者：

王鵬程藝龍技術架構總監曾于實習期間加入豆瓣，后在Baidu從事自動化運維開發，參與了Baidu運維自動化從無到有的過程。后加入360，負責過360運維自動化平臺的架構設計及框架開發，從零開始負責構建了360天機、360流量衛士等移動端產品。擅長服務端、Android底層、分布式系統開發。

(編輯：小酷)