运维监控技术选型
文章目录
- 运维监控技术选型
- ZABBIX
- InfluxDB/M3/OpenTSDB
- Open-Falcon
- Prometheus
- Nightingale
运维监控技术选型
运维监控系统 - 选型篇
参考URL: https://baijiahao.baidu.com/s?id=1665018709160710115&wfr=spider&for=pc
ZABBIX
国内使用ZABBIX非常广泛，移动互联网没有发展起来之前，这基本就是唯一的选择，对机器的监控非常全面，也非常灵活，各类监控插件，各类教程，在网上应有尽有。软件本身经过多年的发展，bug基本不会遇到了，相对比较稳定。
另外最重要的，ZABBIX既有监控能力，又有告警能力，是一套体系化的解决方案。
缺点有几个：
- 产品易用性比较差，管理监控策略、服务器分组都不是太方便
- 容量有限，ZABBIX的监控数据使用MySQL存储，MySQL没法良好的扩展，这导致ZABBIX监控的机器量有限，如果1分钟采集一次监控指标，大约可以监控2000台设备，如果10秒采集一次，大约可以监控400台设备
- 对业务模块监控能力较差，监控指标描述的数据格式比较死板，与最新的监控领域的推荐做法相比，还是差了一个时代
总结：如果只是对机器做监控，不需要做业务监控，设备量也不多，可以使用；如果设备量较大，而且对业务监控有需求，比如监控业务模块各个接口的QPS、延迟、成功率等等，ZABBIX就不太合适了。
InfluxDB/M3/OpenTSDB
随着移动互联网的发展，大家对网站稳定性的要求越来越高，而监控作为提升稳定性的重要抓手，对它的要求也不止是要监控机器、交换机了，还有非常多的模块、业务的监控诉求，这导致监控指标呈爆炸式增长。
监控系统的难点，实际是大容量高性能的时序数据的存储和查询，于是涌现了非常多的时序数据库，专门来解决这个问题，比如InfluxDB、OpenTSDB、M3DB等。所以，这些工具，不算是监控系统，只能算是监控系统的一个存储库。
如果我们具备自研能力，能够自己编写告警引擎，那就可以基于这些时序数据库构建自己的监控告警系统，但是这需要非常多的开发工作，也不是特别建议。
Open-Falcon
官网： http://open-falcon.org/
Open-Falcon是小米开源的一款监控系统，用来解决大容量监控场景，小米刚开始使用ZABBIX，但是ZABBIX容量有限，所以他们搭建了三套ZABBIX，这样一来，要做一些全局的统计、看图，就会非常麻烦了。
另外，小米是随着移动互联网发展起来的，公司有非常多的业务指标需要监控，ZABBIX难以胜任，于是，他们开发了一个内部的大一统监控系统，就是Falcon，后来开源了，名字就是Open-Falcon。
Open-Falcon被很多公司使用，除了小米，还有美团、滴滴、金山云、七牛、360、京东金融，等等，超过200家商业公司在用，现在来看，已经非常稳定了。既能解决机器监控的场景，也能解决业务监控的场景。
但是，Open-Falcon的易用性较差，页面是后台研发人员写的，比较糙，阉割掉了小米内部的服务树功能，真正落地的时候一般都是要二次开发，和自己公司的系统打通，但是Open-Falcon的存储组件、告警引擎的设计，都可圈可点，这也是为什么都是大公司使用，并且都做了二次开发。
Prometheus
在当下，2020年，聊监控肯定要聊Prometheus，Prometheus的作者，都是从Google跳槽出来的，基本就是Google内部的Borgmon的开源版本，和Kubernetes整合的很好，随着Kubernetes的火爆，Prometheus也建立了非常强大的影响力。
Prometheus的优点很明显，和Kubernetes有良好的整合，这是最大的优势，毕业于CNCF，一提到云原生，就会提到Prometheus。
Prometheus的查询引擎也非常厉害，支持PromQL，非常灵活，可以对数据做各种实时计算。
但是，Prometheus也有一些自己的问题，最大的问题是单点，虽然查询引擎有PromQL很灵活，但是单点问题削弱了这种灵活性的价值，告警策略是基于配置文件的不太方便，学习成本较高，告警事件的处理缺少了一些生产级的灵活性。不过近年来出现了Thanos，号称是大规模Prometheus解决方案，大家可以调研尝试一下。
Nightingale
官网：http://n9e.didiyun.com/
Nightingale，中文是夜莺，是近来滴滴开源的一款监控系统，核心研发人员就是Open-Falcon的研发人员，可以看做是Open-Falcon的升级版本。
Nightingale融入了滴滴内部的监控实践，据说监控指标达到7亿，这个数据量是非常吓人的。他们有一个商业版本的运维平台，Nightingale就是从那个商业版本的运维平台里摘出来的。
夜莺有服务树，弥补了Open-Falcon长期以来被诟病的点，易用性大为提升，看官方介绍，相比Open-Falcon也有很多性能提升架构优化。看图告警策略配置都有页面，这点比Prometheus要好一点，策略非常灵活，支持告警升级、告警收敛、告警时段、与条件告警等等，看起来确实是生产级的灵活性。
另外他们融入了日志监控，可以从日志里抽取业务指标，比如接口的QPS、延迟、成功率等，这点比较适合国内环境，因为国内IT界，大都不愿意用SDK埋点的方式采集监控指标，读取日志，相对更接地气一些。
看这个架势，Open-Falcon估计是不会维护了，毕竟Open-Falcon的主力研发都去搞Nightingale了，大家选型的时候要注意。