谁会是 Zabbix 和 Nagios 的继任者？（如果北京不是首都,那么谁会是）

谁会是 Zabbix 和 Nagios 的继任者？（如果北京不是首都,那么谁会是）

【编者按】本文根据 Dataloop.IO 的创始人兼 CEO David Gildeh 对监控工具市场的现状分析以及对未来发展趋势的展望，展开拓展讨论。

为什么监控还是一塌糊涂？

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

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

企业目前在用的监控工具是什么，他们有多少服务器；这些监控工具为他们解决了什么问题，与服务器数量和部署环境有何关系。

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

首先，在某些方面，监测仍然很糟糕，这一点将在下文进行更详细的解释。第二个方面，由于越来越多的公司开始转向微服务（microservices），监控仍然是个难题。

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

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

主要趋势

基于接受采访的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/运维团队需要支持的服务器和服务数量，所以只有在出现问题时，开发团队即变为一线支持，这种部署模型才管用。

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

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

结论

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

[1] 2015 DZone Performance & Monitoring Survey