这段时间小迷监控，原来只是局限于数据库的运维上，并没有细细研究监控的指标，而指标的定义，从接触了监控以后，意义也变的更不一般，这正是运维自动化必须要吃透的一点。
最近几年，我所经手的数据库，已经不在是单纯的Oracle数据库，虽然还在维持着一家独大的局面，但我相信，这种现象不会一直持续下去。随着央行印发《金融科技（FinTech） 发展规划（2019—2021年）。其中提到一点是夯实金融科技基础支撑，持续完善金融科技产业生态。监控告警，一只为金融科技时时刻刻提供保驾护航的手，不但要保证基础支撑的稳定，还要做到精准定位，主动出击。
企业在最初选型产品时，主要还是以监控软件自身稳定性以及监控目标稳定性为主，且要确保有强大的软件支持团队来为问题善后，这样的产品才能入的了企业的法眼。随着时间推移，互联网科技的巨大进步，老牌的监控企业并不能使用这种趋势，已经无法满足各企业的需求，而开源产品却在这方面有着天然的优势：迭代数度快，使用人群广，功能强大，个性化定制（懂开发，自我二次开发），当然这种监控已经不在局限于系统层级，更深入的渗透到软件内部，似乎可以做到全覆盖。
在调研了市场中开源方案时，我参考了业界部分厂商的观点，及对几种产品的功能比对，结合我们环境自身情况，选择更优的prometheus作为最终的监控方案。以下三点着重说了我的体会
1、主流开源监控工具
[图片来自于网络，如有不适，请与我联系，谢谢]
告警方式上，zabbix，open-falcon是监控告警绑定一体的，prometheus是监控、告警二者分离。这一点如果站在运维可靠性的角度来看，分离的方式更好些，至少同时挂掉的概率小很多。
监控数据存储，zabbix在4.2版本也支持了时序数据库TimescaleDB，几个监控工具未来在数据存储上差距会越来越小。但目前来看，zabbix在这方面却显得“年轻”。而open-falcon用的多，想必也麻烦。
编程语言上，我个人更倾向与python和go，这也是未来的主流方向
缺点中要重点说一下里面的一个词，“告警收敛”。未来会在这方面着重测试，收敛的程度与自治愈有很大的关联关系。prometheus的告警收敛做的很出色。
这里贴出来百度百科的解释：
<!--告警收敛是指有时某个告警产生时，往往会伴随着其它告警。这时可以只对根本原因产生告警，其它告警收敛为子告警一并发送通知。如云服务器出现CPU负载告警时往往伴随其搭载的所有系统的可用性告警。-->
最重要的一点，场景应用上，prometheus是目前容器上使用的最好的监控工具
2、运维简单性
zabbix和prometheus部署都很简单，配置也都简单明了。open-falcon需要安装一堆工具，从存储可以看到有mysql，redis，opentsdb，没部署就已经开始退却了。
3、客户端支持范围
这一点主要跟社区的成熟度有关，目前zabbix和prometheus的社区都很壮大，open-falcon相对而就稍显逊色。但对于自定义监控支持上基相当，在prometheus中提供了pushgateway方式，通过http进行pull更简单灵活，只要按照prometheus提供的规则，进行标准推送。 这里提一点，对IBM AIX支持，都不是开箱即用，由于AIX 7.2以下版本不支持GOLANG，因此，open-falcon, prometheus都没有agent，prometheus可以采用pushgateway方式，但必须有curl的支持，而默认aix也不安装这个工具。zabbix agent需要在aix上编译，因此服务器需要安装gcc等相关包。 总体来说这几款工具AIX支持的并不好。
以上说的还是比较片面，但自从接触了prometheus+grafana的监控与展示，已经不再对其他的深入研究了。
