神荼

神荼是中國民間傳說中能制伏惡鬼的神人。最開始出現在上古神話中。傳說神荼和鬱壘同為魑魅魍魎之首，歸於蚩尤，在涿鹿之戰中被擒，降於黃帝軒轅氏。一般位於左邊門扇上，身著斑斕戰甲，面容威嚴，姿態神武，手執金色戰戢。故中國民間稱他為門神。表達了古代人民一種消災免禍、趨吉避凶的美好願望。

作為網際網路企業，我們也需要自己的神荼，於是我們的監控系統就借用了這個名字，期望著這套系統能夠如神荼一般守護公司的平臺架構和業務產品！

部署策略

監控系統是整個運維環節，乃至整個產品生命週期中最重要的一環，要求事前能及時預警發現故障，事後能提供詳細的資料用於追查定位問題，這也是對於想構建一套監控系統的基本要求。

穩：要求平臺架構設計成熟；

準：要求能準確及時預警，準確定位故障；

狠：要求滿足多業務多維度，大資料監控物件資料採集效能；

選擇一款開源的監控系統，是一個省時省力，效率最高的方案。監控系統業界有很多傑出的開源監控系統，小夥伴們最容易想到的就是大名鼎鼎的zabbix, 不過隨著業務的快速發展，以及網際網路公司特有的一些需，如針對docker容器的監控。zabbix監控系統在效能、擴充套件性和使用者的使用效率方面，已經無法支撐了。

為了滿足大型企業多維度監控需求選擇自行開發一套監控系統是一種很好的方法。但是自行開發在人力、時間成本投入過大很容易讓產品夭折。站在前人的肩膀上，利用優秀的開源專案快速構建現代化監控系統才是合理的選擇。於是，我們嘗試了，獲得了一些經驗和體會，在此分享給大家。

我們需要的監控系統

基本的監控系統系統元件：

採集器

儲存資料

顯示資料

報警通知

依照監控系統功需求劃分為：

系統基礎監控

應用服務監控

業務狀態監控

日誌分析監控

根據業務的需求，慎重比較和選擇開源專案後，我們定義出下面的系統架構：

基於Zabbix構建報警平臺

Zabbix 無疑是開源專案中最成熟的監控解決方案。是一個可高自由度定製，視覺化的報警監控系統。 功能十分的強大，可輕鬆實現探針的自動化註冊，也支援基於角色的監控物件自動發現。可定製各種模板（template），通過SNMP、SSH、Telnet、IPMI、JMX監控，可自由定製視覺化的螢幕（screen）等等。

在多維度的生產應用環境中單臺主機監控採集器需要完成約400多項監控指標，這些指標包括以下幾個方面：

CPU info

Disk info

IO

System uptime

Memory info

Network info

埠存活、程式存活

單個程式資源消耗（nginx 、tomcat、mysql）

TCP/UDP （established、time_close 、time_waite ）相關統計

伺服器硬體相關IPMI(溫度、電源、風扇轉速、raid)

核心配置引數

zabbix使用關係型資料庫mysql作為資料儲存。不過隨著業務的發展及複雜度的增加Zabbix探針在監控物件上執行的指令碼也會變多，需要更多的程式，可能會對正常業務產生影響。

cAdvisor 監控docker

Google的cAdvisor（Container Advisor）“為容器使用者提供了了解執行時容器資源使用和效能特徵的方法”。cAdvisor的容器抽象基於Google的lmctfy容器棧，因此原生支援Docker容器並能夠“開箱即用”地支援其他的容器型別。cAdvisor部署為一個執行中的daemon，它會收集、聚集、處理並匯出執行中容器的資訊。這些資訊能夠包含容器級別的資源隔離引數、資源的歷史使用狀況、反映資源使用和網路統計資料完整歷史狀況的柱狀圖。選擇使用cadvisor 是因為前期監控docker。 使用zabbix 自定義python指令碼方式呼叫docker API ,發現當單臺宿主機Container數量超過200個例項。Zabbix效能將急劇下降。Cadvisor可分裝為container配合Influxdb 時間序列資料庫可輕鬆突破監控效能的限制。

一句命令就可以啟動cAdvisor容器，訪問8080埠即可看到效能指標資料。cAdvisor可以通過storage_driver引數將資料存到influxdb

sudo docker run \

--volume=/:/rootfs:ro \

--volume=/var/run:/var/run:rw \

--volume=/sys:/sys:ro \

--volume=/var/lib/docker/:/var/lib/docker:ro \

--publish=8080:8080 \

--detach=true \

--name=cadvisor \

google/cadvisor

Grafanan應用

Javascript 開發的前端工具，支援多資料庫例項訪問 InfluxDB、Graphite、Elasticsearch、CloudWatch、OpenTSDB、KairosDB、Prometheus。自定義報表函式、多格式圖表顯示（柱狀圖、曲線圖、餅圖、塊狀圖）。想在你的Boss面前炫耀一把grafana絕對能滿足你。

官方線上演示地址：http://play.grafana.org/

如何有效處理報警資訊

在監控系統應用之中最煩惱的就是每天會受到監控系統傳送來的上百封告警郵件。特別是在業務應用高峰時期，由於系統的波動將在單一時間多次觸發監控系統的告警伐值。這樣的情況會給Devops 管理造成一種新的困難。 如何有效filter告警資訊，將是判定監控系統有效應用的核心之處。

我們建議分級別、分型別傳送告警。

告警級別分類：

Waring：

Error：

告警方式型別：

郵件告警

電話告警

告警策略

類似系統CPU、 load avage 、網路、磁碟IO等在業務系統高峰期易產生波動的監控項設定為waring級別告警，告警方式採用郵件傳送。同時應針對當日所傳送的告警郵件綜合取樣分析並且能自動傳送每日、每週、每月Top報表，報表包含以下幾項：

消耗系統資源TOP10主機

智慧排列統計(TOP10)CPU使用率、CPU負載、記憶體使用率、系統程式數

業務訪問效率TOP10

智慧排列統計專案平均可用率、總平均響應時間。

可用性統計

智慧排列統計各個節點

響應時間統計

智慧統計單個專案不同地區、不同線路響應時間

故障策略

系統磁碟空間、程式存活狀態，能直接影響使用者功能使用及業務健康狀態的監控項應設定error告警。同時採用電話語音方式告警。要求能快速準確的告警故障原因，並且能讓Devops人員做到第一時間快速解決系統故障。

最新告警訊息(TOP10) ：

儲存應用

對於監控系統來講，歷史資料的儲存和高效率查詢，永遠是個很難的問題！

資料量大

目前我們監控系統，每個週期，大概有2000萬次資料上報（上報週期為1分鐘和5分鐘兩種，各佔50%），一天24小時裡，從來不會有業務低峰，不管是白天和黑夜，每個週期，總會有那麼多的資料要更新。

寫操作多

一般的業務系統，通常都是讀多寫少，可以方便的使用各種快取技術，再者各類資料庫，對於查詢操作的處理效率遠遠高於寫操作。而監控系統恰恰相反，寫操作遠遠高於讀。每個週期幾千萬次的更新操作，對於常用資料庫（MySQL、postgresql、mongodb）都是無法完成的。

高效率的查

我們說監控系統讀操作少，是說相對寫入來講。監控系統本身對於讀的要求很高，使用者經常會有查詢上百個meitric，在過去一天、一週、一月、一年的資料。如何在1秒內返回給使用者並繪圖，這是一個不小的挑戰。

綜合以上幾點的監控系統對儲存系統的要求，我們更推薦使用Influxdb、Elasticsearch類似的時間序列資料庫系統。公開的資料顯示，influxdb可每秒完成50萬寫請求。

Influxdb VS Elasticsearch

以下是influxdb 與Elasticsearch讀寫效能及資料壓縮比的對比測試效能報表，可以很明確的得知時間序列資料庫influxdb 更為適合作為監控系統的儲存系統應用。

後記

神荼已經誕生，他已經擁有了力量去守護我們的產品和服務。正如每一個新生兒一樣，他成長的道路仍然漫長。我們期待著他的神力完全發揮的一天，也相信這一天會到來。也許，他的力量可以幫助的不僅僅是我們，也有千千萬萬跟我們相似的網際網路公司！

本文作者：胡毅（點融黑幫），紅帽RHCA架構師 ，2016年5月加入點融Devops 團隊參與監控系統的研發與維護。多年網際網路公司從業經驗，熟悉DDOS、CC 網路攻擊防禦及業務應用系統優化。