现状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个实例
但愿对您运维管理有帮助。