献给开发运维人士的八大SaaS监控工具

作为一家软件即服务（SaaS）公司，我们经常尝试新的产品和工具，帮助自己做好开发运维（DevOps）工作。我们最近开始评估许多不同的SaaS监控工具，想与各位分享一下评估结果。各位会在本文中看到关于下列工具的一些评价。

• New Relic：市场主导者，拥有多个代理，甚至支持Ruby和Python。

• Ruxit：市场新来者，拥有成熟、集成的一体化监控解决方案，拥有智能化人工智能（AI）技术。

• Sumo Logic：基于云的工具可用于合并和分析日志文件。

• Elasticsearch：一种通用的全文搜索引擎，常常与Logstash和Kibana结合使用，组成ELK架构。

• OpsGenie：这款警报和通知管理工具可与数量众多的监控机制和工具整合。

• PagerDuty：这种警报聚合和调度服务可用于事件管理。

• 亚马逊CloudWatch：这种监控服务可用于监控AWS基础设施资源。

• Pingdom：这种简单的可用性和性能监控工具可用于监控网站。

New Relic

New Relic提供了监控应用程序、监控客户体验和分析受监控数据等功能。

就应用程序监控而言，有一大堆代理可供选择，你可以通过脚本来下载和部署，然后根据你针对特定技术的应用程序进行配置。比如说，有支持Java、.NET、PHP、Ruby以及Python等不同技术的代理。至于安装有代理的每个组件，你能获得额外的图形和可见性。

New Relic应用程序性能监控（APM）

它最近还开始提供一款综合监控产品，执行简单的HTTP ping测试，以监控可用性。另外，你可以为点击路径编写脚本，模拟用户活动。实际用户监控需要你将JavScript标记插入到应用程序的每一个网页。一旦你完成了这步，它在页面上提供了比谷歌分析工具（Google Analytics）还要深入详细的网站性能信息。这就是为什么应该将它添加到Web应用程序中。若想监控移动设备，只要将库添加到你的应用程序。借助该工具，你可以将额外的监控机制添加到应用程序的源代码中。

为了更准确地分析监控数据，New Relic开发了Insights产品，让你可以对受监控数据和第三方数据执行查询。比如说，这对计算转化率或进行地理分析来说很有用。

然而，New Relic最大的优点是，它免费提供了一款简化版产品。可以免费获得“简化”的应用程序监控、移动监控、浏览器监控和综合监控功能，数据可以保留24小时。所以，如果你没有太多钱，这是个不二的选择。

那么，为什么应该考虑New Relic？

• 免费增值定价模式－－应用程序监控、浏览器监控和综合监控。

• 支持Ruby和Python。

• 可以通过脚本实现综合监控。

• 单一服务器或独立服务器。

相关链接：http://newrelic.com/application-monitoring

ruxit

ruxit在New Relic眼里就是新的竞争对手。尽管推出才不久，但它采用了一种全然不同的监控方法，充分利用人工智能来支持其一体化解决方案，该解决方案针对现代开发运维操作和电子商务人士。用户界面也不一样，它开发了一种穿插信息图、触控操作优先的仪表板。

ruxit的一体化方法将应用程序监控与用户体验监控、网络监控、服务器监控、云监控和基础设施监控合并到单一解决方案，很快也会加入综合监控。这听起来很笨重，实则不然。由于你只要将一个代理安装到主机上，部署起来异常容易，而其他产品需要多种类型的代理。之后，它会自动发现拥有所有运行中组件的整个架构。一项很酷的功能是，它不仅会显示你环境的所有依赖关系，还使用所谓的“Smartscape”进行分析。这其实是最重要的组件，因为它有好几项本领。

ruxit监控工具

在典型的SaaS环境下，没有什么永远处于静态。实例启动又停掉，故障切换和负载均衡等方面也是如此。所以，一旦部署了不止一个Apache系统，想了解多个部件彼此如何进行联系、哪个最终用户受到了影响，简直如同恶梦。这时候，ruxit的Smartscape有了用武之地。它为你显示了实时图，列出了各层和整个架构之间的所有依赖关系，告诉你：如果你进行了变更或者停掉了某个实例，它们彼此是如何进行联系的、哪些最终用户会受到影响。

在我看来，它的重心始终放在客户身上。所以，我不是很在乎在新的亚马逊实例上获得速度较慢的输入输出，除非在影响最终用户。这就是我喜欢ruxit的地方。它总是告诉我给客户带来了什么影响。它能做到这一点，是由于能预测性分析监控度量指标，并且充分利用Smartscape，自动了解平常的依赖关系。因而，它知道慢速输入输出是不是在影响最终用户。

现在，要是有了问题――无论是输入输出、nodeJS、AWS、Web服务器、第三方（比如Facebook）、Java还是JavaScript执行，ruxit都能立马让你查明根源，一直深入到代码级和SQL/NoSQL数据库语句。你会觉得它重现初始问题的功能很有用，以便查看问题的整个演变过程。

为什么应该考虑ruxit？

• 一体化监控，而不是使用多种监控工具――可以监控实时用户、应用程序、云、服务器、网络和基础设施。

• 易于部署，可自动发现依赖关系。

• 采用了人工智能方法来分析根源，减少了警报（ruxit称之为“无警报”技术）。

• 支持基于WebUI、 Java、node.js和.NET的应用程序。

相关链接：https://ruxit.com/

Sumo Logic

Sumo Logic 是一款日志分析即服务。你可以将收集器部署到机子上，日志文件将你的日志发送到Sumo Logic以便分析。默认情况下有好多解析器，不过你也可以配置自己的日志文件解析器。收集器收集本地日志文件后，将压缩后的日志文件安全发送到云端。有一个选项，可以减少收集器端发送的日志数据，但是为了获得最佳效果，几乎所有的日志事件都被发送。

如果你将其连接至远程界面，比如AWS CloudTrail，就不需要部署收集器。有一系列广泛的适配件可用于各种情况。日志事件最后出现在Sumo Logic的云存储环境，以便分析，只有几分钟的延迟，不算长。

很显然，日志分析现在是令人关注的部分。自动总结（Auto-Summarize）功能很好，如果你刚开始使用这样一种日志分析工具，更是如此，因为它有助于将来自多个主机和系统的不同来源的日志文件合并到单一视图中，那样就能了解可以如何关联事件。查询语言可帮助你更准确地找到所需的信息，还能让搜索可重复使用。一项额外的日志精简（Log Reduce）功能可以压缩类似的日志条目，那样报告更简短、概况更明了。异常检测（Anomaly Detection）是另一项有助于日常审查过程的功能。

Sumologic日志分析

一旦你熟悉了用法，自动摘要可能不够用，你可以使用REST或Java API接口，能够支持高度自动化，涵盖更复杂的使用场合。分析过程相当快，从几秒到1分钟不等，快慢取决于数据量和查询类型。

为什么应该考虑Sumo Logic？

• 可以合并和关联审查日志文件，检测各种异常：崩溃以及来自多个机器和来源的应用程序错误行为。

• 可用于非技术审查，比如分析AWS CloudTrail审计日志，这在SaaS环境下很重要。

• 可以作为上述的ruxit或New Relic的补充监控方案，因为日志分析涵盖并非所有代理都处理得了的技术，包括窗口事件、系统日志（syslog）、自定义来源和负载均衡系统等。

• 上手快。

• 能够获得自动总结功能之外的功能，并使用REST接口，对Sumo Logic的所收集数据执行自定义分析。

相关链接：https://www.sumologic.com/

Elasticsearch

Elasticsearch是一种通用全文搜索引擎，常常与日志检索和预处理工具结合使用，用于分析日志。一种常见的实现方法是：Logstash用于读取/预处理，Redis用于缓存/缓冲，Kibana用于可视化显示。然而，它也用于其他用途，比如网店搜索功能和数据分析。

可通过Logstash与不同的数据提供商整合起来，这个工具可用于收集、解析和转发日志。还有大量的内置和附件工具可以实现与大多数常见格式集成，还可以自行定义收集规则。

Elasticsearch是一个工具，而不是一种托管解决方案，所以它需要传统的硬件购置和部署工作。不过它在云端可以顺畅运行，并且为分布式高可用性部署性环境而开发。另外，还有提供商提供了Elasticsearch托管环境。

Elasticsearch

你通常将文本连同JSON元数据一并发送到Elasticsearch，然后通过REST接口来执行搜索，因而它很合适整合到自定义的开发运维工作流程中。

数据分段和并行查询执行等各种方法有助于缩短响应时间，即使面对大量数据也是如此。

预计学用起来有点难度，因为这项工具能处理好多任务，因而也需要一番适应。

为什么应该考虑Elasticsearch？

• 你更喜欢有一种自主开发的数据分析方法，或者使用场合很特殊。

• 你需要处理的不仅仅是日志文件。

• 你想要创建自主开发的可视化方法。

• 成本低（如果你已经有了硬件）。

相关链接：https://www.elastic.co/

OpsGenie

OpsGenie提供了警报和通知管理即服务，包括随叫随到调度和逐级上报功能。虽然它比PagerDuty之类的知名工具来得便宜，但也不怯于来一番横向比较。

简单灵活的邮件集成功能以及充分利用REST的API，让几乎每个工具都可以与OpsGenie集成。另外，ruxit等新来者因而可以馈入通知信息，不过它还无法像New Relic、Nagios、Pingdom及其他产品那样提供正式的集成模块。

OpsGenie有个简单的用户界面，让你可以实施时间表、逐级上报策略和事件路径规划。功能类似PagerDuty提供的功能。你不仅可以定义几个时间表和众多逐级上报策略，还可以根据事件来源、内容和标记，规划事件路径，发送到运行OpsGenie应用程序的移动设备，或者就通过电子邮件、短信或自动呼叫来接收事件。

以开发人员为中心的开发运维团队会喜欢上OpsGenie，因为灵活的警报工作流程有助于减小对网络操作团队的依赖性。简单的用户界面让你可以定制复杂的警报规则，那样就能将几个收到的通知合并成一个有意义的、可付诸行动的警报。云用户会喜欢这项功能：定义延迟时间，以便在决定要不要逐级上报之前自动实现故障切换。

OpsGenie

你可以将定期的心跳（heartbeat）信息从监控工具发送到OpsGenie，确保没有因为监控工具掉线而错过警报。

在HipChat聊天室中将警报转发到Slack，或者只要在转发警报前留言，就可以让团队成员协作解决事件。内置的报告功能提供了一些基本的关键绩效指标（KPI），比如“平均解决时间”和一些大致的趋势。它还让你可以限制收到的报警数量。

为什么应该考虑OpsGenie？

• 规模较小的开发运维/无运维团队使用高度自动化。

• 功能复杂的警报工作流程。比如开始逐级上报之前检查故障切换自动化是否正常工作。

• 万一出现紧急情况就会警报。

相关链接：https://www.opsgenie.com

PagerDuty

PagerDuty是一款警报聚合和调度服务。它让你可以集成所有的监控系统、APM解决方案、API管理和客户支持系统。默认情况下就已经提供了与100多个系统集成的功能，电子邮件网关或充分利用REST的API让你不仅可以集成New Relic或ruxit之类的监控工具以及Elasticsearch或Sumo Logic之类的日志分析工具，还能发送电子邮件或开启REST调用。

有了PagerDuty，你就能定义逐级上报策略，规划事件路径，发送到运行PagerDuty应用程序的已注册移动设备。它支持不同的电话提供商（实现自动呼叫）、短信服务提供商和电子邮件提供商。它还让你可以根据警报来源和事件类型，规划警报路径。定义逐级上报和路径规划的功能使用简单，但很强大。只要你不需要工作流程决定是不是需要逐级上报，几乎一切都涵盖在其中。有诸多团队、时间表和逐级上报延迟，你可以轮换实施逐级上报策略，直至有人响应。还有一条退路：如果你忽视警报类型，照样有一种自动逐级上报机制能处理得了。

PagerDuty事件管理

它与HipChat、Slack、Flowdock和CampfireWork等许多常见的协作工具集成，以便团队高效工作。面向其他团队的自动化事件进度更新有助于消除不必要的电子邮件链。

PagerDuty安装很简单。工作流程和逐级上报定义不需要高深的技术技能。你可以通过Web或移动应用程序，访问事件管理和配置用户界面。这让你能够直接从移动设备响应报警。

最后但并非最不重要的是，有一个分析模块让你可以创建统计资料、报告事件频率、平均修复时间（MTTR）和类似的度量指标。这可以帮助你优化支持流程和事件管理。

为什么应该考虑PagerDuty？

• 如果你的逐级上报工作流程或策略要求不是太复杂。

• 你想要一种使用简单、功能强大的方法来合并来自各个监控系统的警报。

• 你的支持或操作团队分布于全球，需要通过电话、短信或电子邮件，可靠地向他们通知事件。

• 你想为现有的监控工具添加一个易于使用的事件管理系统。

• 你想分析及大体查看所有系统的运行状况。

• 你想拥有关于事件处理的报告机制，有助于缩短解决时间。

相关链接：http://www.pagerduty.com/incident-resolution/

亚马逊CloudWatch

亚马逊CloudWatch是一种监控服务，可监控托管在亚马逊云端的AWS资源和应用程序。

CloudWatch的一种常见使用场合是，确保服务顺畅高效地运行。这通过收集和跟踪针对众多AWS资源的度量指标来做到，比如EC2实例、弹性负载均衡系统、EBS卷、关系数据库实例及更多资源。此外，CloudWatch让你可以设置警报，并采取自动化行动，比如在自动扩展的组里面启动或删除EC2实例。

CloudWatch的定制性还不错；除了系统和应用程序的日志文件外，你可以发送和存储针对自定义应用程序的度量指标，以便更深入地了解应用程序和系统在如何运行。

CloudWatch AWS监控

众多第三方厂商将CloudWatch API视作为亚马逊客户提供更多价值的一种方法。集成厂商的数量越来越多，而且遍布不同地区。很常见的是集成了OpsGenie或PagerDuty之类的通知服务，CloudWatch警报因而被提升到下一个高度。其他经常集成的解决方案是监控工具。这一类按不同的市场地位对厂商作了分门别类。先是主要的APM厂商（比如New Relic），然后是新来者（比如ruxit），最后是AWS监控是其业务核心的公司，比如CopperEgg或Stackdriver。

监管工具补充了通过CloudWatch API收集的基础设施级计数器（counter）及应用程序性能数据。借助代理技术，它们能够提供宝贵的洞察力，深入了解系统进程和操作系统层面的度量指标，这些指标对基于云的部署环境来说极为重要，比如说处理器steal时间。

CloudWatch提供了对ruxit等一些监控解决方案来说很宝贵的基础设施计数器。计数器能够自动检测应用程序、服务和AWS基础设施部件之间的依赖关系。所有这些数据合并起来，结合准确表明最终用户的指标，执行智能化根源分析响。

CloudWatch提供了度量指标保留2周的功能，这个时间段对你来说可能够长了。不过，大多数监控工具保留数据的时间超过2周，一些客户可能很注重这一点。

为什么应该考虑CloudWatch？

• 对AWS服务实行基础设施级别的监控够用了。

• 如果保留2周的数据满足你的要求。

• 你在亚马逊云中运行所有工作负载，并没有考虑迁移到混合云。

相关链接：https://aws.amazon.com/cloudwatch/

Pingdom

Pingdom是一种简单的可用性和性能监控工具，专注于回答一个重要的问题：我的网站在正常运行吗？由于价格方案既面向小型博客写手，又面向大企业客户，所以其解决方案很适合许多企业组织。由于产品套件内置了综合监控解决方案和最终用户监控解决方案，它们提供了各个级别的Web应用程序监控。

Pingdom网站监控

Pingdom提供了监控网站的诸多方法。正常运行时间检查是最流行的监控方式，对任何特定的URL提供了预定的HTTP/HTTPS GET请求――要是北美或欧洲的任何一个地区出现了服务停运，就会发出警报。开发人员可以利用Pingdoms基于文本的脚本语言，该语言可使用CSS定位器构建事务检查机制。虽然这些多步骤事务在浏览器里面运行，但是缺少New Relic等竞争对手提供的详细的标题信息。可预定的ping、TCP、UDP、DNS和电子邮件服务器等各项检查满足所有网络要求。最后但并非最不重要的是，Pingdom还提供了JavaScript标记，提供了来自最终用户的度量指标。这些值有别于正常运行时间检查，但是提供了独一无二的洞察力，可了解最终用户的可用性和性能。

根据你的爱好配置检查只完成了一半。Pingdom还提供了使用外部监控数据的诸多方式。用户界面整洁新颖，可与更新颖的监控解决方案（比如ruxit）相媲美。实时仪表板显示了事件检查、正常运行时间检查和事务检查，提供了操作视图，让你密切关注监控状态。通过邮件发送的报告和可选的公共状态页面让你可以与同事和合作伙伴轻松共享你网站的健康状况。要是有问题，就会通过短信、推特、电子邮件或将通知推送到Pingdom的安卓或iOS应用程序，将每个事件通知你。

Pingdom还让你可以通过充分利用REST的API以及预制的WordPress插件，访问数据。Pingdom拥有众多监控选项，是一种低成本、高效率的方法，从而确保网站在正常运行。

为什么应该考虑Pingdom？

• 就快速轻松地监控外部可用性和性能而言，它再理想不过。

• 不同的价格方案给贵公司带来了灵活性。

• 将你的Pingdom度量指标整合到其他第三方解决方案（比如WordPress）

• 可以立即接到事件通知，可以与同事轻松共享你的结果。

相关链接：https://www.pingdom.com/

但愿你会觉得本文介绍的这几款SaaS监控工具大有用处。你想推荐另一款用过，又觉得挺有帮助的工具吗？欢迎留言交流！

新闻来源：usersnap.com｜云头条编译（未经授权谢绝转载）