現狀html
•小公司/ 創業團隊< 500臺服務器規模ios
開源方案：Zabbix、Nagios、Cacti…git
雲服務提供商：監控寶、oneAlert等github
•BAT級別> 10萬臺服務器web
投入大量的人力，內部自研，與業務嚴重耦合無法做爲產品推出算法
•中間階層spring
無從可選數據庫
早期，選用Zabbixflask
•Zabbix是一款開源的企業級監控系統windows
•對其進行二次開發、封裝、調優...
•爲何選擇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個實例
但願對您運維管理有幫助。