- 论坛徽章:
- 28
|
看到子萌在群里的链接,正好前一阵子在做监控系统的转换,就来参与下~
1、你所用过的监控软件有哪些?感觉有什么优缺点?
Zabbix:
优点:
应用比较成熟,不需要做太多的二次开发
server-proxy-agent部署结构比较清晰
支持插件
自动注册的判断规则和后续动作的组合很多进而可以支持基于主机名或其他的各种主机管理减少人工干预
逆天的discovery支持在各个地方使用变量,除了各种name标识外,甚至还包括trigger判断的阈值,报警信息等.
监控种类比较齐全,如windows,交换机,虚机等...
缺点:
不友好的视图组合支持.screen太难用.
存储不支持水平扩展.
性能有瓶颈,主要出现在server的数据库上.机器数量3000+,nvps在4000左右出现瓶颈,这个数值貌似是不包含zabbix_sender通过文件方式传回的value的,在规划监控项的interval的时候往往要迁就性能,不能支持更细时间粒度的监控,就是省着使用
监控配置复杂度太高.简单的监控还好,配一个变量比较多的discovery往往要调试很久,要更新脚本,conf,调试sender文件内容
主机名修改后要重启agent才能生效...不然一直往老的host上吐数据...
不支持主机组和模板之间的绑定,只能用自动注册的动作来山寨的绑定.
所有监控项的收集都需要提前配置
Falcon:
优点:
部署模块拆分的更细,结构更清晰.portal,dashboard,transfer,agent,judge,sender,alert,graph等等.
各个模块均支持水平扩展.扩容相当容易.
支持多种监控数据的展示方式,比zabbix的graph,screen好用1W倍.
监控策略配置简单,更容易面向用户.
支持插件,类似zabbix的脚本,这里值得一提的是这个插件自带时间调度,命名类似10_scriptname.sh的脚本名的时候,会每10秒执行一次.一些简单的模块监控可以放到这里面.
judge和graph分离,报警判断和绘图是2个模块,互不影响.
http协议的自定义监控项数据收集.并且收集的监控项不需要提前配置.大大减小了自定义监控项收集的复杂程度.
缺点:
需要大量的二次开发,最好能对接一套内部的管理平台来进行主机管理.
插件生效需要配置,这个配置只能和主机组绑定,而不是主机组配置的模板绑定.
报警内容不支持自定义变量
监控项的interval从小改大的时候,图像会有断点,还没看过源码,估计是只有在第一次注册监控项的时候才写interval的值,后面判断有这个监控项的时候interval就不再判断了.但是不敢肯定哈,求大神指正.
2、你认为在监控软件的使用过程中,有哪些难点?
我认为在使用监控软件的使用过程中,并没有难点…各种功能的实现总是最简单的.
关键是怎么用好工具.
最难的其实还是掌控业务.
域名监控,语义监控,模块监控,结构体监控,日志监控,这些的规划和实现都有方法可循,可怎么通过这些监控100%覆盖自己的业务,并且精确定位到故障,这个才是最难的.其中还涉及一个在后端分析报警内容的事情…也是我后面主要的精力投入点.
说一个不算难点的地方,就是其实这两套监控系统都要上额外的配置管理,其他的就没了.
3、在监控软件使用过程中,有哪些收获?
收获还是比较多,一开始参与的时候可能只是底层脚本的编写,然后提升到部署级别,更好的了解ha,容灾,在架构思想上有进益,然后监控软件选型,知道不同监控的优劣所在,学会思考,培养大局观.
然后在这个过程中,对自己的服务的掌控能力也会越来越强. |
|