运维监控工具选择

2019独角兽企业重金招聘Python工程师标准>>>

1. 参考资料

• 详解十三款运维监控工具 (2017年08月17日)
• 开源IT监控系统对比 (2014年9月15日)

2. 选择结果-- open-falcon

• 理由
  • 国内开源(小米)
  • 文档完整
  • 插件扩展
  • 开源背景决定其更考虑互联网特殊需求
  • 自定义push/插件
  • 足够开放
• 基本介绍
  • falcon /'fælkən/, 猎鹰/隼
  • open-falcon.org
  • github
  • book.open-falcon
• 特性
  • 强大灵活的数据采集：自动发现，支持falcon-agent、snmp、支持用户主动push、用户自定义插件支持、opentsdb data model like（timestamp、endpoint、metric、key-value tags）
  • 水平扩展能力：支持每个周期上亿次的数据采集、告警判定、历史数据存储和查询
  • 高效率的告警策略管理：高效的portal、支持策略模板、模板继承和覆盖、多种告警方式、支持callback调用
  • 人性化的告警设置：最大告警次数、告警级别、告警恢复通知、告警暂停、不同时段不同阈值、支持维护周期
  • 高效率的graph组件：单机支撑200万metric的上报、归档、存储（周期为1分钟）
  • 高效的历史数据query组件：采用rrdtool的数据归档策略，秒级返回上百个metric一年的历史数据
  • dashboard：多维度的数据展示，用户自定义Screen
  • 高可用：整个系统无核心单点，易运维，易部署，可水平扩展
  • 开发语言： 整个系统的后端，全部golang编写，portal和dashboard使用python编写。

3. Open-falcon 组件

• Agent: 采集服务器负载监控指标, 部署到所有的机器上
• Transfer: 是数据转发服务。它接收agent上报的数据，然后按照哈希规则进行数据分片、并将分片后的数据分别push给graph&judge等组件
• Graph: 是存储绘图数据的组件。graph组件 接收transfer组件推送上来的监控数据，同时处理api组件的查询请求、返回绘图数据
• Api: 提供统一的restAPI操作接口。比如：api组件接收查询请求，根据一致性哈希算法去相应的graph实例查询不同metric的数据，然后汇总拿到的数据，最后统一返回给用户
• HBS(Heartbeat Server): 心跳服务器，公司所有agent都会连到HBS，每分钟发一次心跳请求
• Judge: 用于告警判断，agent将数据push给Transfer，Transfer不但会转发给Graph组件来绘图，还会转发给Judge用于判断是否触发告警
• Alarm: 模块是处理报警event的，judge产生的报警event写入redis，alarm从redis读取处理，并进行不同渠道的发送
• Task: 监控系统的一个必要的辅助模块. 定时任务实现.
• Nodata: 用于检测监控数据的上报异常。nodata和实时报警judge模块协同工作，过程为: 配置了nodata的采集项超时未上报数据，nodata生成一条默认的模拟数据；用户配置相应的报警策略，收到mock数据就产生报警。采集项上报异常检测，作为judge模块的一个必要补充，能够使judge的实时报警功能更加可靠、完善
• Aggregator: 集群聚合模块。聚合某集群下的所有机器的某个指标的值，提供一种集群视角的监控体验
• Agent-updater: 每台机器都要部署falcon-agent，如果公司机器量比较少，用pssh、ansible、fabric之类的工具手工安装问题也不大。但是公司机器量多了之后，手工安装、升级、回滚falcon-agent将成为噩梦

4. 部署演进

Open-Falon的部署情况，会随着机器量(监控对象)的增加而逐渐演进，描述如下，

初始阶段，机器量很小(<100量级)。几乎无高可用的考虑，所有子服务可以混合部署在1台服务器上。此时，1台中高配的服务器就能满足性能要求。

机器量增加，到500量级。graph可能是第一个扛不住的，拿出来单独部署；接着judge也扛不住了，拿出来单独部署；transfer居然扛不住了，拿出来吧。这是系统的三个大件，把它们拆出来后devops可以安心一段时间了。

机器数量再增加，到1K量级。graph、judge、transfer单实例扛不住了，于是开始考虑增加到2+个实例、并考虑混合部署。开始有明确的高可用要求？除了alarm，都能搞成2+个实例的高可用结构。再往后，机器继续不停的增加，性能问题频现。好吧，见招拆招，Open-Falcon支持水平扩展、表示毫无压力。

机器量达到了10K量级，这正是我们现在的情况。系统已经有3000+万个采集项。transfer部署了20个实例，graph部署了20个实例，judge扩到了60个实例(三大件混合部署在20台高配服务器上,judge单机多实例)。query有5个实例、平时很闲；hbs也有5个实例、很闲的样子；dashborad、portal、uic都有2个实例；alarm、sender、links仍然是bug般的单实例部署(这几个子服务部署在10左右台低配服务器上，资源消耗很小)。graph的db已经和portal、uic的db实例分开了，因为graph的索引已经达到了5000万量级、混用会危及到其他子系统。redis仍然是共享、单实例。这是我们的使用方式，有不合理的地方、正在持续改进。

机器上100K量级了。不好意思、木有经历过。目测graph索引、hbs将成为系统较为头疼的地方，Open-Falcon的系统运维可能需要1个劳动力来完成。

转载于:https://my.oschina.net/jimmywa/blog/2992383