鳳凰網：基於服務樹的監控系統實踐
作者介紹
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”的一部分，運維監控系統擁有大量的監控原始資料卻沒能發揮它的價值，通過分析這部分資料我們可以挖掘很多潛在的有價值的資訊，從而降低運維成本，提高運維效率，這部分資料甚至可以通過人工標註後進行機器學習，這樣監控系統就可以不用設定報警策略來進行報警了。
機器學習、人工智慧的盛行給運維工作帶來更多暢想和變革，這也是我們正在努力的方向。