現狀

•小公司/ 創業團隊?< 500臺服務器規模?

開源方案：Zabbix、Nagios、Cacti…?

雲服務提供商：監控寶、oneAlert等

•BAT級別?> 10萬臺服務器?

投入大量的人力，內部自研，與業務嚴重耦合?沒法作為產品推出

•中間階層

無從可選

早期，選用Zabbix

•Zabbix是一款開源的企業級監控系統

•對其進行二次開發、封裝、調優...

•為什麽選擇Zabbix

•Cacti

•Collectd

•RRDtool

•Nagios

•openTSDB

Zabbix實踐思路

•測試ZabbixNode

•Zabbix代碼優化

•使用模式優化

•獨立部署多套Zabbix，通過API整合

Zabbix遇到的問題

•隨著公司業務規模的快速發展

•用戶“使用效率”低下，學習成本很高

•不具備水平擴展能力，無法支撐業務需求

•告警策略的維護、變更代價太大，導致運維人員深陷其中，無法自拔

•不利於自動化，不利於與運維平臺等基礎設施整合

------------------------------------------------------------------------------------------------

Open-Falcon

Open-Falcon是小米運維團隊設計開發的一款互聯網企業級監控系統

•提供最好用、最人性化的互聯網企業級監控解決方案

•項目主頁：http://open-falcon.com

•Github: https://github.com/xiaomi/open-falcon

•QQ討論組：373249123

•微信公眾號：OpenFalcon

社區貢獻

•交換機監控

•https://github.com/gaochao1/swcollector

•Windows監控

https://github.com/freedomkk-qfeng/falcon-scripts/tree/master/windows_collect

•Agent宕機監控

https://github.com/freedomkk-qfeng/falcon-scripts/tree/master/agent_monitor

•Redis/memcached/rabbitmq監控

https://github.com/iambocai/falcon-monit-scripts

•MySQL 監控方案

https://github.com/open-falcon/mymon

典型案例

美團

•生產環境廣泛應用，1萬+agent

•集成服務樹、支持ping監控、多機房架構支持、報警第二接收人支持

•正在開發openTSDB接口、query增加正則功能

趕集

•深度定制，用於大數據部門平臺服務監控與自動運維，生產環境已上線

京東金融

•深度調研open-falcon

•正在開發測試drrs（一種分布式的time series data 存儲組件）並適配falcon

內部

agent
•負責機器數據采集
•自發現各項監控指標
•發送數據給transfer
•發送心跳信息給hbs
•執行自定義插件
•業務數據不要用插件采集！
•數據收集采用推還是拉的方式？

transfer
•對接收到的數據做合法性校驗
•轉發數據給graph和judge
•為什麽要做這個統一的接入端？
•為什麽要對數據做分片？
•數據分片方案，用一致性hash還是路由表？

judge
•對接收到的數據按照閾值進行判定
•達到閾值的數據產生相應的event
•觸發式判定or 輪詢？
•為什麽要使用內存？

graph
•操作rrd文件，對數據進行存儲和查詢
•將多次操作合並後再flush磁盤
•將要flush到磁盤的數據，打散到每個時間片，降低IO消耗
•為什麽用rrd而不是opentsdb之類的？

hbs
•提供接口給agent查詢機器所需監控的端口、進程、要執行的插件列表等信息
•接收agent匯報的狀態信息並寫入數據庫
•緩存用戶配置的告警策略
•為什麽要用hbs緩存策略列表？

query

•利用一致性hash算法，查詢多個graph的數據並匯聚
•需要使用與transfer相同的hash算法及配置

各web端
•Dashboard負責繪圖、展示、儀表盤等
•Uic負責管理組合人的對應關系
•Alarm-dashboard負責展示當前未恢復的告警
•用戶在portal中配置告警策略
•Portal中的hostgroup一般是從CMDB中同步過來的！

Aggregator
目標：集群監控
•針對某個hostgroup的多個counter進行計算
•分子：$(c1) + $(c2) -$(c3)
•分母：可以是$# 或者數字或者$(d1) + $(d2) -$(d3)
計算結果
•封裝成一個metricItem，再次push回open-falcon
為什麽這麽實現
•歸一化的問題解決方案
•復用整個open-falcon的繪圖展現、告警邏輯

Gateway——跨數據中心

接駁服務樹（CMDB）
•開源服務器管理組件（服務樹）
•監控對象通過服務樹來管理
•服務器進出節點、監控自動變更

歷史數據高可用
rrd-on-hbase
•繪圖數據存儲在hbase中，解決高可用的問題
•歷史數據提供更詳細粒度的查看
drrs（@京東金融）
•Distributed Round Robin Server
•面向中心公司，輕量級的歷史數據存儲方案，解決數據擴容的問題

智能告警
同比、環比
•Dashboard數據展示支持同比、環比
•告警判定引入同比、環比作為參考
動態閾值
•通過對歷史數據的學習，生成動態的告警閾值
關聯分析
•精準告警
•故障定位

SDK
七層
•Nginx
•統計cps、200、5xx、4xx、latency、availability、throughput
語言支持Java/C++/PHP/Python
•內置統計每個接口的cps、latency
•內置統計業務關註的指標的能力
框架支持
•resin、spring、flask…
統計類型
•Gauge/ Meter / Timer / Counter / Histogram

雲監控
•服務端Host在公有雲上
•無需客戶安裝、運維服務端
•支持namespace隔離、quota限額
•從根本上對不同用戶的數據進行隔離
•優化監控的添加、管理、查看流程
•提升用戶體驗、提高用戶使用效率

其他
•Callback功能增強，推進故障自動處理
•插件的管理支持多種方式（不僅限於git）
•Dashboard 增加用戶登錄認證
•告警排班/ 告警升級（@金山雲）

Open-Falcon部署實踐
•初始階段
•所有的組件部署在一臺物理機上即可
機器量級~ 500
•graph、judge、transfer三個組件拆分出來部署在1臺服務器上
機器量級~ 1000
•graph、judge、transfer 增加到2~3個實例
•query拆分出來，部署2個實例
•dashboard 拆分出來部署
機器量級~ 10K
•graph、judge、transfer 增加到20個實例，graph盡量使用ssd磁盤
•query增加到5個實例
•dashboard 拆分出來，增加到3個實例

希望對您運維管理有幫助。

IT運維監控解決方案介紹