江苏龙网

  1. 首页 > 人文 > >

监控系统的选型建议，这是一款灵活( 三 )


较强的扩展性： 支持Proxy分布式监控 ， 有agent自动发现功能 ， 插件式架构支持用户自定义数据采集脚本 。
配置方便： 能通过Web界面进行监控和告警配置 ， 操作方便 ， 上手简单 。
下面是 Zabbix 的劣势：
性能瓶颈： 机器量或者业务量大了后 ， 关系型数据库的写入一定是瓶颈 ， 给出的单机上限是5000台 ， 个人感觉达不到 ， 尤其现在应用层的指标越来越多 。 虽然最新版已经开始支持时序数据库 ， 不过成熟度还不高 。
应用层监控支持有限： 如果想对应用程序做侵入式的埋点和采集（比如监控线程池或者接口性能）zabbix没有对应的sdk ， 通过插件式的脚本也能曲线实现此功能 ， 个人感觉zabbix就不是做这个事的 。
数据模型不强大： 不支持tag ， 因此没法按度进行聚合统计和告警配置 ， 使用起来不灵活 。
2. Open-Falcon（小米出品 ， 国内流行）
监控系统的选型建议，这是一款灵活
文章图片
Open-falcon 是小米2015年开源的企业级监控工具 ， 采用Go和Python语言 ， 这是一款灵活、高性能且易扩展的新一代监控方案 ， 目前小米、美团、滴滴等超过200家公司在使用它 。
小米初期也使用的Zabbix进行监控 ， 但是机器量和业务量上来后 ， Zabbix就有些力不从心了 。 因此 ， 后来自主研发了Open-Falcon ， 在架构设计上吸取了Zabbix的经验 ， 同时很好地解决了Zabbix的诸多痛点 。
先来了解下Open-Falcon的架构设计：
监控系统的选型建议，这是一款灵活
文章图片
Open-Falcon架构图 ， 来自网络
Transfer： 数据分发组件 ， 接收客户端发送的数据 ， 分别发送给数据存储组件Graph和告警判定组件Judge ， Graph和Judge均采用一致性hash做数据分片 ， 以提高横向扩展能力 。 同时Transfer还支持将数据分发到OpenTSDB ， 用于历史归档 。
Graph： 数据存储组件 ， 底层使用RRDTool（时序数据库）做单个指标的存储 ， 并通过缓存、分批写入磁盘等方式进行了优化 。 据说一个graph实例能够处理8W+每秒的写入速率 。
Judge和Alarm： 告警组件 ， Judge对Transfer组件上报的数据进行实时计算 ， 判断是否要产生告警事件 ， Alarm组件对告警事件进行收敛处理后 ， 将告警推送给各个通道 。
API： 面向终端用户 ， 收到查询请求后会去Graph中查询指标数据 ， 汇总结果后统一返回给用户 ， 屏蔽了存储集群的分片细节 。
下面是Open-Falcon的优势：
自动采集能力： Falcon-agent 能自动采集的200多个基础指标（比如CPU、内存等）无需在server上做任何配置 ， 这一点可以秒杀Zabbix.
强大的存储能力： 底层采用RRDTool ， 并且通过一致性hash进行数据分片 ， 构建了一个分布式的时序数据存储 ， 可扩展性强 。
灵活的数据模型： 借鉴OpenTSDB ， 数据模型中引入了tag ， 这样能支持度的聚合统计以及告警规则设置 ， 大大提高了使用效率 。
插件统一： Open-Falcon的插件机制实现了对用户自定义脚本的统一化 ， 可通过HeartBeat Server分发给agent ， 减轻了使用者自主维护脚本的成本 。
个性化监控支持： 基于Proxy-gateway ， 很容易通过自主埋点实现应用层的监控（比如监控接口的访问量和耗时）和其他个性化监控需求 ， 集成方便 。
下面是Open-Falcon的劣势：
UI不够友好： 对于业务线的研发来说 ， 可能只想便捷地完成告警配置和业务监控 ， 但是它把机器分组、策略模板、模板继承等概念全部暴露在UI上 ， 感觉在围绕这几个概念设计UI ， 理解有点费劲 。


推荐阅读


上一篇：机器人理发，这位机器人理发师还会附赠聊天服务

下一篇：直播带货，用户的时间是有限的，拼多多直播，超级观点