关于 New Relic 软件分析平台新特性的问答

最近，New Relic 公司为旗下的 New Relic 软件分析平台发布了一系列新的特性。考虑到微服务、PaaS、内存数据库和容器化等技术是目前软件架构中的关键趋势，他们希望通过这些新特性减少现代软件架构中的复杂性，

新的 Service Maps 工具能够创建一种可视的实时图，为开发团队与运维团队提供一种个性化的基础设施视图。 Docker 监控工具能够在应用程序的上下文中收集容器的性能指标。而在 New Relic 最近的发布中还包括两个新特性，其中数据库面板专注于NoSQL 数据库，而原有的警报系统也得到了改进。

InfoQ 有幸与 New Relic 的产品市场高级总监 AI Sargent 进行了一次对话，以更多地了解这些新特性。

InfoQ：对于已经在生产环境中使用现代架构的团队来说，在 Service Maps、Docker监控、数据库面板以及改进的警报系统之中，你认为哪一条特性与他们的工作最密切相关？

现代架构如今在许多方向上都在快速发展，如果现在还有谁仍然只关注于软件架构其中的一个风险，那么他注定要落后于当今由软件驱动的业务环境的发展需求。

这些发展方向包括：

1) 由一体性应用转向微服务

2) 由物理机和虚拟机转向容器

3) 由磁盘密集性数据库转向内存数据库

4) 由应用服务器转向 PaaS

这些方向上的发展能够提高开发者的生产力，以及应用程序的可伸缩性和弹性，但他们也同时产生了更高的复杂性。我们有一位客户在生产线上创建了大约 4000 个微服务，如果不能很好地对它们进行管理，很快就会失控。为了克服这种复杂性，我们推出了新的 Service Maps 与警报功能，以确保在技术转型过程中的易用性与灵活性，并且还能够应对软件架构未来的复杂性。

InfoQ：Service Maps看起来已成为监控工具的一个入口。那么在为微服务设计这种“对整个环境的某种独特视角”时，你是如何决定每个组件的重要性的？

为了决定 Service Maps 中各个组件的重要性与优先级，我们与客户进行了密切合作，以了解他们在每天的操作中是如何使用可视化工具的。我们所观察到的结果是：在实施微服务的组织中，开发并支持着某些服务的团队希望通过一种专注的视图，不仅聚焦于他们所支持的服务，同时也能够看到上游与下游的依赖服务。

这一观察结论的结果是，我们为自定义功能设置了很高的优先级，从而使得不同的团队能够创建一份对于他们来说最实用的可视图，以特定的视角展现出他们的环境，然后将这些可视图作为与其他团队进行讨论的基础，这一点已经得到了使用者的欢迎。

InfoQ：你是否能够深入地讲解一下 Service Maps中主要特性的细节？

Service Maps 为开发者、运维人员、网站工程团队和 DevOps 团队创建了一个可视化的实时图，呈现了他们对整体环境的一种特定视角，从而帮助他们更好地理解复杂的软件架构。Service Maps 不仅在 New Relic APM 自动地展示了整个架构，而且对于架构的任何更改都会反映到图上。在图中能够看到各个组件的实时健康状态，能够帮助使用者进行故障排查，包括对每个特定应用的输入与输出连接的健康状态进行分析。

InfoQ：在新开发的特性之中，其中之一与 Docker有着直接的关联。你对于容器技术的成熟度有什么看法，对于它在不久之后的将来的发展又有什么展望？

Docker 很显然还处于发展的早期阶段，但根据客户对它的兴趣，以及在我们的技术栈中对 Docker 的使用经验来看，人们在容器对应用程序的性能方面的作用还存在着盲点。虽然我们还难以断言 Docker 是否会广泛地用于生产环境中，或是它在这方面的发展会带来怎样的影响，但我们认为，现代软件将继续向模块化、灵活的云应用架构的方向前进，这些架构包括容器、PaaS 及微服务等等。

InfoQ：现在每个人都在谈论 Docker，这或许使你们决定将 Docker监控的实现作为一个高优先级的任务。你认为在你们为用户所提供的这方面的所有特性之中，哪些特性是最有价值的呢？

要说最重要的话，那就是应用上下文了。我们将 Docker 的性能指标放在一个应用的上下文中，乃至整个业务的需求中进行分析。有哪些容器的镜像在支持着这些应用？它们的负载有多大？这些指标能够带来有价值的深刻理解，它将来自于我们的应用程序代理以及 Linux 服务器监控代理的数据结合在一起。这一特性十分重要，因为如今在一个数据中心内可能会存在着几十个容器，不久的将来甚至可能会发展到几百甚至几千个。如果你的 Docker 指标缺乏对应的应用上下文，那么它的数据基本上也是没有价值的。

我们在这篇博客“新的 Docker 支持特性”中描述了更多的细节。

InfoQ：对于 NoSQL数据库来说，有哪些客户咨询的指标是最常见的？在新的数据库面板特性中，最有价值的功能有哪些？

无论你是使用 SQL 语句以访问数据（即关系型数据库的方式），或是通过 API 访问数据（即 NoSQL 数据库的方式），都要考虑以下这些核心的关注面：

1) 在我的应用与所连接的数据库之间的数据流量有多大？（吞吐）

2) 我的数据库是否响应很慢？（响应速度）

3) 我的应用是否向数据库进行了过多的调用？（调用次数）

4) 如果数据库运行缓慢，其原因何在？（缓慢查询的细节）

在数据库面板中，主要的指标已经对所有关系型数据库和 NoSQL 数据库实现了标准化，这样就能够更方便地比较不同类型的数据库之间的性能特征和行为。我们觉得，通过使用这些数据库的应用程序的角度实现这个数据库性能的统一视图，这对于展示应用程序如何使用这些数据库来说是一种非常有效的方式，尤其能够展现出数据库操作将对应用程序、乃至终端用户产生怎样的性能影响。为了补充这个视图的缺漏，可以在插件中心页面下载特定的数据库插件，以提供特定于该数据库的性能指标。将各种不同的观点进行综合考量是非常重要的。

InfoQ：在统一警报平台中，当警报来自不同的设备时，如何确定哪些警报应当被组合在一起？你能否简单地解释一下，是否可以通过不同的配置选项选择警报的组合？

由于我们能够对整个栈信息进行全盘监控，并且实现了一个非常灵活的警报策略模型，因此通过将这两者进行结合，就得到了一个简单而优雅的归纳机制，它能够利用配置本身创建警报组合的范围。通过这种方式，用户就能够控制将哪些警报组合在一起，以及将它们组合在一起的方式。

根据用户的需求，New Relic 警报能够以三种方式生成事件，可在此处查看详细的说明：

1) 每个策略对应一个事件 。（一个策略是一系列资源的条件组合，资源也称为目标（target），例如应用或服务器。）这种方式生成的警报数量是最少的。

2) 每种条件对应一个事件。当策略中的条件所关注的目标（即资源）进行相同的工作时，这种方式十分有用。例如所有的服务器都用于托管相同的应用程序。

3) 每个目标与条件对应一个事件。这种方式生成的警报数量最多，如果你希望能够收到每个意外情况的通知，或是希望将警报发送至某个外部系统，那么这种方式非常实用。

查看英文原文： Q&A on New Relic Software Analytics Improvement