作者介紹
kun：鳳凰網運維開發，負責公司運維自動化平臺設計開發，InfluxDB contributer、open-falcon contributer 、golang愛好者。
一、傳統監控系統的困擾
說到監控，大家肯定能列舉不少，zabbix、nagios、open-falcon、Prometheus等。鳳凰網和其他大多數互聯網公司一樣，一開始選擇了開源的zabbix來做為公司的監控系統。就這樣，相安無事，多年過去了。隨著公司服務器的不斷增長，我們遇到了一些難題：
當服務器量級達到3000左右時，監控數據存儲和查詢遇到瓶頸。
業務上報監控系統不方便，沒有相應的接口或SDK。
zabbix中的組概念沒有層次和依賴關係，不利於服務治理。
一些定製化的監控需求難以滿足（集群監控等）。
相信第一個問題很多體量稍大的公司都遇到過，大家用得最多的一個解決方案是拆分zabbix，部署多套來分擔壓力。但是後端查詢過慢的問題沒有從根本上解決，而且增加了維護成本，考慮到zabbix後端是c語言寫的，二次開發有一定難度，於是我們打算自己造個輪子。
二、自建監控系統需求分析
2.1關於服務樹
先簡單介紹下幾個概念：
服務樹：某些公司為了方便管理服務集群，利用樹形結構建立起了一種服務組織關係，方便集群 服務治理，以服務集群節點為管理單元，而不是某臺機器。
Open-Falcon：是小米開源的一套分佈式高性能監控系統，支持服務樹管理。
有人可能會問，你們為什麼不直接用開源的 open-falcon ，不得不承認， open-falcon 的某些設計還是非常不錯的，我們也從中學習了很多思路。但是由於小米公司當時沒有開源出結合監控的服務樹，我們不得不自己設計一套適合自己，也可能適合你的服務樹。
基於服務樹，我們可以更方便的管理自己的服務, 服務樹是整個監控系統的基礎服務，後來我們開發的發佈系統也是基於服務樹實現的。基於 golang 的運維友好性和高性能，整個服務樹是用 golang 實現的，對於新手來說，上手難度也不高。服務樹架構圖如下：
服務樹架構圖
2.2關於高可用
考慮到服務樹（service registry）組件的重要性，架構上一定是高可用的，於是我們底層數據存儲 store 層多實例是基於 raft 算法保證數據一致性的，最底層是用了 boltDB 來存儲服務樹的數據，另外為了提高服務樹的讀性能我們還為 store 層添加了支持 lru 算法的 cache 模塊， cache 結構體如下：
// Cache implements a non-thread safe fixed size LRU cache. type Cache struct { mu sync.RWMutex count int evictList *list.List items map[string]map[string]*list.Element size uint64 maxSize uint64 enable bool logger *log.Logger }在啟動服務樹的時候，我們可以指定服務樹開啟的內存大小，現在我們開啟了 50M , 效果還是非常不錯的。
2.3關於擴展性
如果你啟動了 3 個實例，正常情況下 raft 底層是有一個 leader 和兩個 follower 的，寫操作必須落在 leader 上才能成功，很多開源軟件也都是這樣的，但是這樣服務樹就有狀態了，對於用戶提交數據不是特別友好。
於是我們在 cluster 這一層會做判斷，如果進來一個寫操作，直接嘗試本機，如果失敗了，再把請求轉發到 leader 上，底層幫助用戶做數據轉發，這樣用戶不用關心那個是 leader ，3臺對他來說是一樣的，前端加個負載均衡可以隨便接受請求了。
在這裡我們底層還做了一些工作，就是把 cluster 監聽的 TCP 端口和 raft 數據同步的端口複用，這樣，用戶的配置也就精簡了。
另外服務器可以根據一定策略自動註冊到服務樹上的某個服務節點當中，機器，報警，權限在服務中都是一種資源，這種資源都有增刪改查的操作，對於服務樹來說這些沒有什麼區別，只是人定義了它，服務樹中一切皆資源，後期擴展極為方便。
2.4關於性能
zabbix 很大的一個問題就是用結構型數據庫來存儲了時序性數據。考慮到整個監控系統的配置數據和監控指標數據是有不同特點的：
配置數據：量小、讀取頻繁、可用性要求高
監控數據：量大、讀取冷熱分明、可用性要求高
可以考慮把監控配置數據抽象城資源存儲到服務樹中，保證數據可用性，而對於監控指標數據可以存儲到時序性數據庫當中，開源的有 OpenTSDB、InfluxDB、Prometheus等。
2.5關於業務數據上報
業務上有越來越多上報打點需求，我們可以考慮從 agent 端開放出接口，把業務上報的數據作為普通數據一起打包入庫，這樣也複用了監控系統數據傳遞的整條鏈路，同時降低了系統維護難度。對於一些標準的基礎服務採集，我們採用插件的方式來實現，在 zabbix 中叫模板，比如 nginx 的一些指標， mysql 的一些指標等。
三、自建監控系統構建
設計需求分析完了，關於鳳凰網的監控架構，我們先上架構圖：
3.1系統數據流
服務器通過拉取服務樹的用戶配置採集策略，通過部署的agent進行監控數據採集上報，每個IDC內部會有一個消息隊列防止公網傳輸延遲或丟數據，數據會進入消息隊列，然後會有router模塊負責把數據寫入到InfluxDB中。
由於InfluxDB已經閉源了集群功能，為了保證後端數據的高可用，我們通過router進行多寫。受限於大量的寫入請求，我們通過router對後端InfluxDB做了分片，這樣當後端某個db出問題時，不至於影響其他服務數據寫入和報警。
報警我們用了開源的kapacitor，為了提高用戶易用性，我們圍繞它做了一些改進，也在支持了監控指標的無值監控。
3.2各模塊功能
agent：採集服務器上的各種資源監控指標
registry：服務樹，管理各種採集，報警策略
MQ：消息隊列，負責數據緩衝和容錯
router：後端數據的讀寫入口，負責數據分片和多寫
InfluxDB：開源的時序數據庫
Alarm：報警組件，負責向各渠道下發報警消息，報警屏蔽和報警收斂等
3.3為什麼選擇InfluxDB
InfluxDB是一個時序數據庫，為時序數據而生，它新版的TSM存儲引擎性能非常好，數據壓縮做的非常好。
舉個例子，2000臺左右服務器，100天數據佔用400G空間。面對10s級別的上報採集頻率，這個成績是非常不錯的。
目前，監控系統大部分監控項是10秒級的上報粒度，InfluxDB的每秒寫入5w。每天入庫的數據點10億。
四、Highlight
agent原生支持Windows，開源社區支持linux做的比較好，但是我們公司有些微軟的服務（exchange）是windows服務器，於是我們做了很多工作來原生支持win系統，
支持windows的相關源文件
支持第三方打點上報，方便開發接入監控系統，我認為這個已經是現在監控系統的標配了。
監控上報
插件庫支持豐富，得益於開源社區，支持插件監控，擁有完善的插件庫
相關插件
更優化的圖像展示速度，在長時間跨度查詢的時候能夠做到快速展示, 支持grafana展示 （原生支持）
儀表板顯示
支持自動註冊，服務器根據主機名自動註冊到服務樹相應節點，根據節點的配置自動採集和報警
新節點註冊
更優化的agnet，agnet的安全性和性能是我們非常關注的問題，我們儘可能降低agent的資源消耗(mem.used<30MB cpu.used<1%)，為此我們還砍了一些採集項。
內存佔用率
CPU佔用率
支持分級報警，方便值班人員看到正在發生的報警，每個報警持續的時長，以及是否恢復。
報警DashBord
靈活的機器管理，你可以看到當前機器有無報警，機器狀態是否online，如果機器維護可以隨時設置為維護狀態，屏蔽這臺機器的所有報警，專注於處理問題。
機器管理
五、展望
回到文章開頭遇到的問題，我們藉助於現有的開源時序數據庫，大量監控數據的寫入和讀取已經不是問題了。
服務樹的出現可以更好的幫助運維人員管理自己的服務集群，同時我們在 agent 端開啟了一個 unix domain socket 用於本機的業務上報，這是一個異步接口，不會阻塞請求，甚至可以把監控平臺看成是一個開放的消息總線，通過這個上報接口，給了自己和他人一個無限可能。
未來的監控系統肯定會更加智能，這也是最近比較火的“AIOPS”的一部分，運維監控系統擁有大量的監控原始數據卻沒能發揮它的價值，通過分析這部分數據我們可以挖掘很多潛在的有價值的信息，從而降低運維成本，提高運維效率，這部分數據甚至可以通過人工標註後進行機器學習，這樣監控系統就可以不用設置報警策略來進行報警了。
機器學習、人工智能的盛行給運維工作帶來更多暢想和變革，這也是我們正在努力的方向。
近期好文：
第八屆全球運維大會
即 GOPS2017·上海站將於2017年11月17日-18日在上海舉行
各種精彩等您發掘。
點擊閱讀原文關注活動官網