服务监控Zabbix和Nagios的继任者

本文转载自：https://blog.csdn.net/moonpure/article/details/78633668

为了调研市场，从而做出更好的监控工具，David Gildeh 曾采访了超过60家欧美在线服务提供厂商，大到英国广播公司(BBC)这类在线服务巨擘，小到伦敦和美国的小型创业公司。发现大多数服务都是运行在公共云基础设施之上(像 AWS)，并且采取 DevOps 实践方案。

越来越多的企业使用云服务，和尝试建立 DevOps 环境，云监控已经成为一种刚需。

想开发出更好的监控工具，我们必须先回答俩个问题：

1. 企业目前在用的监控工具是什么，他们有多少服务器；

2. 这些监控工具为他们解决了什么问题，与服务器数量和部署环境有何关系。

在 David Gildeh 的调查结果中，我们了解到两件事。

• 首先，在某些方面，监测仍然很糟糕，这一点将在下文进行更详细的解释。

• 第二个方面，由于越来越多的公司开始转向微服务（microservices），监控仍然是个难题。

企业正在使用哪些监控工具？

虽然自 2011 年以来，市场上也涌现了很多新工具，但是很多「老牌」的开源工具，比如 Nagios、Zabbix 等仍然在市场中占据主导地位。采访发现，70%的公司仍在使用这些传统工具进行核心系统监控和告警(见图1)。来自 DZone 的数据显示，该网站的企业级开发用户中，43%都使用过 Nagios、Zabbix 或者 Ichinga。此外，Nagios 是最受欢迎的监控工具之一，甚至占据了29%的市场份额[1]。

数据统计，大约 70% 的公司会同时使用多个监控工具，很多公司都是使用两个或两个以上的产品。当然，在欧美市场中，Nagios 和 Graphite 配置是最常见的。据小编了解，国内拥有大量使用 Zabbix+Grafana 的用户。而对于一些付费的性能监控工具，如 New Relic，出于价格因素考虑，大多数用户都不愿意从免费版升级到付费版本。

不过，市场上还存在很多「新潮」的监控工具 ，面向的用户主要是创业公司，这类工具包括一些较新的 SaaS 监控工具，比如 Cloud Insight(系统监控平台)、Application Insight（应用性能监控平台） 和 Browser Insight（前端性能监控平台）。老式的开源工具，例如 Cacti 和 Munin，也这个群体的杰出代表。这类工具成本更低，例如免费版本基本可以满足要求的 Cloud Insight，对于创业公司和中小型团队来说十分适用，可以极大地节省运维的人力和时间成本，因为部署和学习容易，相较 Zabbix 来说更灵活，又因为可视化效果出众，在 10-40 台服务器的中小型团队中很受欢迎。

上图为 Cloud Insight Hostmap 功能的效果图。

企业有多少服务器被监控？

如果查看工具使用情况和公司管理的服务器数量(规模从少于20台服务器的初创公司的服务，到多于1000台服务器的大型在线服务)，会发现老式的开源工具（比如 Nagios）以及付费的本地化工具，往往在服务规模较大的公司占据较大比重，而服务规模较小的公司则更愿意使用以开发为重点的工具，例如 Graphite，LogStash 和 OneAPM 等。

另一方面，小型团队往往没有践行 DevOps，公司也没有专门的运维人员，所以开发者倾向于使用简单、安装方便的 SaaS 监视工具或在开发者社区较为流行的工具，例如 Cloud Insight 等。当公司的服务器数量达到 50 到 100 之间的某个临界点时，他们往往会有能力引进 DevOps/运维人员或团队，继而开始使用历经时间考验、拥有广泛用户基础的监视工具，像 Nagios 和 Zabbix。

主要趋势

基于接受采访的60多个在线服务公司对监控策略的意见，David Gildeh 总结了如下四个主要趋势。

1. 构建和扩张

78%的在线服务运行着自己的开源监控解决方案，许多公司会花4到6个月时间，使用开源的组件构建监控解决方案，然后调优到相应的工作环境。关键问题是许多工具最初是在10到15年前设计的，远远早于云架构、DevOps 和微服务（microservices）的出现。所以，企业需要耗费大量的时间调整这些老式工具，使它们兼容于当今的动态环境(十分累人)。

企业完成构建并优化监测体系之后，随着业务的增长，他们需要更多的时间来修改监测系统，以使其处理日益增长的数据量。例如，一个大型的在线服务，在 AWS 上有超过1000个实例，后台 MySQL 数据库 2Tb 的数据填满后，Zabbix 服务器不幸宕机。最终，他们只是不断重启数据库，却不尝试为 Zabbix 扩容。

2. 垃圾警报

接受采访的公司都在抱怨同一个问题——过度的告警提醒。很明显，所有工具，即便是声称具备先进的机器学习算法的监控工具，却无法解决告警疲劳问题。由于企业不断增加服务器，在持续变化的云环境上运行微服务，该问题只会进一步恶化。尽管许多企业在营销时大放厥词，但在实践中，这些用于异常检测或告警预测的机器学习算法并没有真的如人们所愿。这意味着，想要这些工具在监测中自动过滤掉告警噪声，还有很长的路要走。

在某个公司，他们每天会收到大约5000封邮件提醒。这样庞大的邮件数量使得告警逐渐沦为噪音，大多数团队只会把这些告警过滤到一个文件夹中或者干脆自动删除告警。

3. 数据孤岛

我们采访的很多公司都在收集实时数据。这些数据源包括业务指标，如注册、付款的数量，或收入数据，团队用这些数据来进一步了解公司的服务情况。然而，他们所使用的大多数监视工具，都有可用性差、UI 过时等问题，所以所收集的数据是孤立的，不能为运营团队所用。所以对其他利益相关者来说，也不太容易了解这些实时数据的价值。

但也有一些服务通过建立自定义仪表板，在办公室的电视中进行展示或通过 URL 进行共享，来解决数据孤岛问题。比如 Cloud Insight，采取「DevOps +协作」的理念，拥有 API 和 SDK 功能，可以自定义仪表盘上传包括性能数据、业务数据、运营数据在内的种种数据，通过多种形式（折现图、柱图、饼图…）进行一体化实时展示。而即将推出的仪表盘分享功能将支持仪表盘实时共享。这几乎是一个共识，如果公司里的监测数据很容易共享，在不同团队的协作过程中，监控工具就能体现其价值，譬如确定亟待改进的区域，实现跨业务间的实时性能可见性等。

这会不会是系统监控的下一个趋势？我们拭目以待。

4. 微服务

在线服务的关键趋势是微服务部署模型，其中包括独立的跨职能的开发团队在生产过程中部署并支持自己的服务。这一战略使一个大型的复杂应用程序具备高度的可伸缩性。然而，这大大增加了 DevOps/运维团队需要支持的服务器和服务数量，所以只有在出现问题时，开发团队即变为一线支持，这种部署模型才管用。

在本模型中，运维人员成为一个「平台」团队，为开发团队提供通用的工具和流程。这一运维提供的平台包括自助监测，即开发者必须能够自主添加监测，并创建自己的仪表板和告警。

对于那些易于共享监测数据的公司，监控工具变成了更具价值的工具。

跟上微服务模型中的高速部署以及瞬息万变的实例，对于老式的监视工具来说是一项巨大的挑战。同时，对 Zabbix 和 Nagios 本身来说，实现各种服务间复杂任务流的可视化并处理高度动态的扩展，也非易事。雪上加霜的是，显然，目前的监控工具并不是围绕微服务模型设计的，并且大多数的可用性都比较差，在运维团队之外的采用率也较低。

因此，新的监控模式和工具成为需求，需要新的专门针对微服务的监控工具，以便运维和开发团队围绕同一性能数据源开展合作，而不是开发人员使用自己的工具(比如 New Relic 或 OneAPM)，而运维也用自己的工具(比如 Nagios 和 Zabbix)，互为孤岛。

结论

在「#monitoringsucks」事件之后的这四年，出现了种类繁多的监视工具。但 David Gildeh 的研究和我们自己的调研通通表明，许多公司仍在监控领域苦苦挣扎。我们认为，主要原因在于很多新的监控工具往往只重视技术方面的监控，还不足以推动在运维团队以外的采用。而我们相信，连接开发、运维甚至其他部门，通过可靠的监控让企业中的每个人都可以基于数据做出决策，是未来 IT 团队选择监控产品的趋势。