本文是根據藝龍技術架構總監王鵬程在11月21日在麥思博（msup）****主辦的into100沙龍第14期《十萬級伺服器監控系統開發的架構和心得》演講中的分享內容整理而成，他認為一切應從簡潔出發，不要搞複雜的東西。經歷了許多公司，監控系統大概都是從無到有，該經歷的也都經歷了。所謂監控系統，大概的架構如下：
◆在伺服器布置乙個agent，它負責採集資料；
◆由網上**到乙個分布式管道再轉接，就像搭積木一樣；
◆進行彙總；之後把監控資料分兩個部分
●一是資料庫儲存，主要做監控資料展示和後續排查問題。
●二是制定很多的監控的報警項。
◆每乙個模組就幹一件事，把這件事幹得精細和優秀。
●之後會細化一下模組裡的具體內容。
●要scalable，flexible，可以任意橫向擴充套件，適應各種防火牆acl。
●在360的時候機房比較多，各種防火牆的acl非常多，360下還有很多子公司，會出現各種訪問的現象。要適應各種系統，就會通過一些模組來適應。
◆注重**復用。
一套系統除去網路框架，每個模組的**都在100行，而且是c語言寫的。我們最後把這個網路框架都做在了乙個網路庫，這個是多執行緒的。
這個系統基本上不能做cache，必須實時運算。因為伺服器監控系統，我們做服務端應該都知道，延遲報警，還不如不報。報警一旦出了問題，就要盡可能快的把這個東西報出來。除非是一些不可控的因素，如簡訊閘道器，或者運營商簡訊傳送延遲等。結論是，90%都要在15秒之內保證大家手機能收到。這對我們在各種環節下儘量減少各種各樣的延遲什麼的提出較高的要求，換言之，高可用。這種監測系統作為一種伺服器的基礎架構存在，可用性必須比線上高，因為它發揮最大作用的時候都是公司出了大問題的時候，這個時候必須要扛的住各種各樣的網路情況，把真實的情況反饋過來。對於這種線上的可用性要求高於線上服務至少乙個數量級。像cpu連續5次90%不報警，如果我們這個資料裡有任何丟點，可能會導致報警報不出來。因而對於資料的完整性要求也是比較高的。就是在任何乙個模組宕機或者網路隔離，這種情況下也不允許出現任何的丟失。
高吞吐。因為這個系統是典型的寫的比較多，讀非常非常隨機的過程。讀取決於大家對資料項的檢視，彙總，畫圖的需求。所以基本上乙個月之內的資料需要隨時的調出來。高吞吐也是我們面臨的主要問題。
針對資料量，hbase，自定義協議減少overhead。資料量這個問題不大，用的技術在於說，監控資料的傳輸，根據一些私有的協議，也是一些歷史原因，當時用json很多。也嘗試過用別的，但是對監控系統有時候，比如出丟點，像追的時候json可以，用別的就追不上了。
高實時。對等多執行緒非同步非阻塞、實時計算、長連線。我們這個系統不能用一些很高延遲的東西，比如說卡羅普你想都不用想了，還有像現在比較火的流式系統，所以也沒有採用。
高可用。我們這個系統不能有單點，而且有乙個要求，你是同乙個機房，不能降級。就是如果這個機房停電了，這個機房不監控也罷，但是你得知道它停電了。但是剩下的機房必須保證監控沒有受到任何影響，而且還要保證15秒這個事。這是我發明的詞，「惰性智慧型選路」這個其實也很簡單，什麼叫惰性呢？像網路掛了，連不上了，我們agent可以連到別的上，這個很簡單，就是我們想辦法讓agent讓它知道有這個的存在，我們不用ds傳統方式。我們啟動的時候，或者哪兒出了問題，我們拿到另外乙個連，這個策略非常簡單，但是這個東西作為乙個介面，以前的agent，由於網路斷了會試下乙個，就是最終會遷移到離它最近的，網路狀況最好的，就是很默契的達到智慧型，而不用考慮它跟誰連線。同樣的，下游往上游發的時候也是用的相應策略。還有高可用，我們要保證這個資料不能丟。就是有一點必須要保證，就是這個監控資料由於第一手拿到的都是本機的一些agent，這個agent必須保證資料到了讓報警的那個模組拿到。我們這個就是agent拿到這個資料之後，翻譯的這個模組只會進行**，上面的收到確認之後傳過去，最後再給。保證這個資料一定到了上游。由於這種東西的強保證，所以說也會導致效能上的困境，就是說我們要保證資料不丟，又要保證高效能，這後面我們再說這個是怎麼做的。
高吞吐。 cache，還是cache。沒有什麼好說的，覺得一般cache能解決的高併發都不是難點。
多平台。當時我們做這個的時候golang還沒出來，所以都是用的c++。時間計數器一出問題什麼都出了問題，時鐘不好了，定時器到計算效能全都完蛋，windows是乙個非常坑的平台，後來幸虧有了golang，避免了agent只能找非常厲害的人寫的侷限。
◆zlib流式壓縮
這個寫起來沒那麼好弄，但是聽起來挺簡單的。
◆pipeline滑動視窗
●之前說從agent採集到資料，經過層層模組**，這樣就會導致請求和回應的延遲會非常大，在大延遲的情況下怎麼保證高吞吐量，於是發資料的時候，比如在翻譯模組都是進行批量**，那邊回乙個ok。工程師說，在應用層又造了乙個ttp，這個東西比較無聊。
◆協議改造，protobuf
◆資料合併
◆function-filter優化，當時優化也走了很多彎路：
●profiler，現在cpu行為不是教科書裡說的那些東西，現在cpu的架構體系不是常人能理解的了。我們的想法是各種都去嘗試，最終選擇好用的。
●分布式改造，這個容易降低速度，最終沒有再嘗試。
所謂簡潔即可靠，我們曾經做這種東西的時候，就是關於資料**和怎麼弄曾經做了一些版本，也走了一些彎路，慢慢發現搞的越複雜坑越多，特別是在限制要求特別高的情況下，最後返璞歸真，不斷優化，出來的就是每個模組極其簡單，感覺就是分布式管道，都可以在linux系統裡找到影子。做到簡潔，因為有的模組，我們寫**都知道，從產品來看，就是從這兒到那兒。寫**如果在設計上複雜化，很多東西都繞，加班加點也不一定能搞明白。因此現在藝龍考慮的就是從簡潔出發，不要搞複雜的東西。
結語：十萬級伺服器監控系統開發架構尚可繼續完善，願來日更上一層樓。
伺服器監控系統 Cacti
主要監控流量和效能 1.搭建好lamp或者lnmp架構的網路伺服器架構 安裝httpd和php 安裝mariadb10.3版本 vim etc yum.repos.d mariadb10.3.repo mariadb name mariadb baseurl gpgkey gpgcheck 1 yu...
伺服器監控系統 Nagios
1.安裝lamp或者lnmp架構 2.建立nagios使用者和使用者組 useradd s sbin nologin nagios 3.安裝依賴包 yum y install gcc perl unzip openssl devel tar zxf nagios cn.4.3.4.tar.gz cd...
伺服器網路監控系統方案
關於監測伺服器的問題，我大概整理了一下。現在有三種方案可以使用。1 最徹底的方案，使用net snmp。這個包可以部署在任何平台，包括nix和winnt。然後通過snmp客戶端來訪問。這種方法的好處是可以封裝訪問介面成元件。缺點是所有監控的伺服器都需要安裝net snmp。linux是自帶的。win...