这篇文章将为大家详细讲解有关DBA怎样驾驭Open-Falcon，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
一个运转良好的公司离不开运维，运维离不开监控工具。君子善假于物也，一款优秀的监控工具可以让运维事半功倍。
源自小米的Open-Falcon便是这样一款优秀的监控工具，拥有zabbix、nagios等其他监控工具所没有的特性：
1.部署灵活、接口灵活、报警设置灵活
1）部署灵活，各个部件都可扩展，并提供全系统高可用；
2）接口灵活，可自定义开发collect端；
3）报警设置灵活，支持callback，支持人性化告警；支持Screen，多指标聚合显示，支持Dashboard，历史数据查询效率高。
2. 单机利用率高，可支持每秒200万的存储、上报，可支持超大规模的监控。
从这些特性来看，Open-Falcon非常适合我们公司使用。
当然，在我们确认使用Open-Falcon前，线下的实践和测试是必不可少的。
DBA团队在测试Open-Falcon的时候，发现其对于DB监控项的采集有下面几点不足：
1. 不支持对Oracle的监控项采集。
2. 采集返回的数据必须为数字型，不可以是文本，所以在监控日志时，告警信息无法反馈具体告警内容。
3. Mysql单机部署多实例支持性较差，在实例迁移后需要对监控做后期维护。
本人在韩锋老师的指导下，使用python编写了针对DB的采集工具collector，这也是本人学习python以来，在敏感信息检测工具和无用表检测工具之后，编写的第三个工具。它可以实现：
1. 支持Oracle&Mysql的监控项采集。
2. 利用tag返回日志ERROR信息。
3. 分别采集本机所有实例的各项指标，在发生实例迁移或者角色转换后可以做到一键维护。
4 集中配置采集项，易批量维护。
通过该工具，完全满足了对DB监控项采集的要求，不过在后续测试报警的过程中又踩了几个坑，在这只说其中一个：因为Open-Falcon采集项不支持返回文本结果，所以想到利用tag返回日志ERROR信息。但此方法会导致解决告警后，告警项在告警列表中无法自动清除的问题。
当然，最终这个问题也解决了：使用tornado框架配置了一个独立的外置服务，并修改了Open-Falcon中alarm组件，在其web页面中添加了一个set0按钮，点击该按钮就会将采集项信息传递到tornado外置服务，外置服务再将该告警判断置否，告警项在告警列表中就这样清除掉了。
关于DBA怎样驾驭Open-Falcon就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
