Prometheus + Grafana 應用級監控方案(1)-概述
主流監控方案比較
比較項 | Prometheus+Grafana | Zabbix | BKCE |
---|---|---|---|
整體方案 | Prometheus更像一個“監控引擎”,文本配置,UI極簡,适用于應用級監控,配合Grafana配置界面,UI夠漂亮 | 傳統監控,以IP為監控主目标,更适合于主機、網絡監控,對SNMP支援很好,帶PHP界面,可自行擴充但整體界面不夠“靓” | 騰訊藍鲸社群版,運維及CMDB功能非常強大,PaaS,DevOps,社群版的監控是PaaS之上的APP,專業性、擴充性均一般(據說企業版很強大),開源生态較一般 |
監控目标 | exporter-Pull模型,更安全,性能影響小 | Agent-Push方式,部署複雜 | Agent-重點在于下發指令及檔案傳輸(BT),監控隻是順帶功能,支援自動遠端部署 |
支援 | 資料庫/中間件/應用/硬體,開源生态圈豐富 | 對SNMP支援特别好,偏硬體、網絡、伺服器,對應用級監控支援一般 | 支援常用的監控項,要擴充不是一般的麻煩 |
存貯 | 自帶TDB及外部資料庫,建議使用外部InfluxDB | Mysql/PostgreSQL,對時序類的支援不好 | InfluxDB+Mysql |
UI | 建議使用Grafana配置方式 | PHP,自定義擴充,界面一般 | 有限幾種展示,擴充就别想了(社群版) |
性能 | 10萬資料/秒,GO語言的程式,性能值得信賴 | 一般,個人認為Mysql不适合用于存監控資料 | BKCE自身較占資源,必竟它的使用場景是“上萬台伺服器下的自動運維、監控”,小場景下無優勢 |
告警 | 類SQL方式腳本化配置,建議将告警放到Grafana,告警時能帶圖檔+連結,很友好 | 事件+條件+操作,較完整的告警體系 | 告警規則較死闆,通過BKCE的消息通道推送,支援微信、短信等(自家産品) |
其它方案
- Elastic stack
- 以ElasticSearch為核心件,Beats為其監控擴充插件,Kibana為UI展示端的“全家桶”方案
- Filebeat + ES + Kibana 組成的日志分析型監控,無出其右者!
- 支援常用的OS、資料庫、中間件等多種Beat,UI界面友好
- 擴充性一般、第三方擴充資源較少
- 企業級應用需要用到權限、遠端同步等安全及進階功能,則需要購買xpack許可,可不便宜
Prometheus + Grafana 方案小結
- 引擎 + UI ,較好地展現了“Unix哲學”之一: 讓程式隻做一件事并把它做好,Unix最偉大的功能之一”管道“就是這個展現," ls |grep | sort |wc " 這種操作,相信作為運維人員是很熟悉的
- yml配置檔案而非界面配置:開發人員寫文檔更喜歡 markdown而非Word/Notepad,編輯配置同理
- export設計簡潔:Don't call me,I will call you!
- TDB及RDB-InfluxDB: 非時序型資料庫的監控方案不應該被采用,除非資料量很小
- Prometheus 這個名字太美,就像Eclipse的名字一樣美妙--自行體會吧
方案不足之處
- Prometheus自身的擴充不友善,Go語言寫的代碼,到處是協程、管道,要讀懂處理過程還是比較麻煩的
- 吐槽一下:Golang由于衆所周知的原因,編譯時下載下傳依賴包及編譯環境初始化有些障礙,這不是事,我從沒見過一個程式編譯需要8CPU全跑滿,幾分鐘後告訴你”XX變量申明但沒有使用,編譯失敗!“這種體驗!
- 關于告警:Prometheus的告警方案體驗一般,Grafana的告警方案不夠靈活,兩者都不太理想,能結合一下就完美
- 自動部署:BKCE的監控子產品有一大優點是能通過它自己的NodeMan遠端自動部署,”能讓機器完成的事,不浪費程式員一秒鐘“,在本方案中均需要手工配置完成監控系統、exports、view、Alert等工作
智慧運維之監控系統
- 增加自動部署子系統,完成大部分監控對象的批量自動化部署,極大提升監控開發、部署的效率
- 修改自動化部署配置檔案 --> 一鍵部署,完成監控資料采集、監控展示界面、監控告警輸出等過程
- 擴充Prometheus 的 UI部分,內建自動部署工具及Grafana的擴充界面(如:交換機狀态圖、運維視窗設定等)
- 擴充Grafana,增加幾個有用的顯示插件
- 通過Grafana的 webhook增加告警輸出處理(如優化釘釘推送,告警資訊反向推送至Granfna界面等)
自動化部署方案

自動化部署示例
監控及告警示例
如對我們的産品有興趣,請聯系: [email protected]