几年前，我有一个具有交通警报服务的车载 GPS 导航系统。每月只需几十元，您就可以订阅一项服务，该服务会在前方有交通时向您发出警告。更典型的是，当我已经在 101 上停了下来时，导航系统会脱口而出“前方有交通事故”。它告诉你有交通事故，但不告诉你为什么，并且从未提供替代路线。它也无法提前预测问题。但在当时，这比在广播中收听零星的交通报告要好得多。

网络性能监控 (NPM) 也有一些类似的挑战。它在报告和跟踪网络可用性、响应时间、延迟和上传/下载速度方面做得非常出色。最初开发时，网络性能监控在包含、易于理解和受控的数据中心的单体架构中运行良好。

十年或二十年前，性能问题几乎总是与网络相关。任何从事网络工作的人都可以告诉你：当事情破裂时，当网络管理员并不好玩。今天，存储或应用程序本身更有可能成为罪魁祸首。虽然曾经是管理最终用户体验的主要工具，但 NPM 的功能被日益复杂的数据中心架构所削弱。NPM 通常部署在边缘，因此它忽略了数据中心中的内容。

网络性能监控仍然是网络和 IT 运营经理必不可少的工具，但对于现代 IT 基础设施来说已经不够了。这些工具随着时间的推移而发展，通常具有深度数据包检测 (DPI) 功能，可以扫描和识别应用程序流量，但仍然存在差距。应用程序性能管理 (APM) 工具填补了一些漏洞，但正如我之前在明辰智航官方网站中上所写的那样，它们也缺乏对基础架构的可见性。我职业生涯的大部分时间都在从事网络工作，所以我列出了 NPM 没有给你的六件事：

1. 计算资源可见性。网络性能监控使用数据包检查作为分析问题的主要基础。NPM 工具无法查看计算资源，例如内存、CPU 或主机或虚拟机的等待时间。 

2. 存储资源可见性。同样，网络性能监控也无法看到存储层发生了什么。它可能能够监控进出存储阵列的流量，但实际上无法测量虚拟机或阵列上的磁盘延迟、吞吐量或其他关键指标。 

3. 应用服务器健康可见性。NPM 工具无法与应用程序服务器通信，因此它们无法告诉您应用程序的启动/关闭状态。他们也看不到可能影响应用程序性能的操作系统和进程级别信息。例如，如果应用程序响应时间很慢，并且由于应用程序服务器内部备份进程消耗了大部分 CPU 或内存资源。 

4.应用事务仿真。验证问题的一种方法是模拟应用程序事务。由于 NPM 工具被动地通过交换机运行，因此它们无法做到这一点。NPM 工具是被动的。他们分析网络数据包。但是如果没有数据包怎么办？您无法判断服务器是否死机、应用程序崩溃或发生了其他事情。在客户端模拟事务可以识别 NPM 工具看不到的潜在问题。

5. 网络的完整视图。现代网络是复杂和动态的。NPM 探针不能到处部署。虽然“监听器”可以看到大部分流量，但这仍然让 NPM 工具对虚拟机之间的东西向流量视而不见。VMware NSX 等软件定义网络具有完全软件定义的组件——软件定义的防火墙和路由器、vLAN 等。网络生态系统现在正在进入虚拟化层，因此在软件定义的数据中心中，您需要深度集成与虚拟化平台。 
6. 如果不是网络，则能够识别根本原因。即使网络性能监控报告了延迟，它通常也无法确定根本原因。网络性能监控工具非常擅长检测网络问题，并且可以通过检查数据包来发现特定应用程序的问题，但 NPM 通常不会告诉您是什么导致了问题。这些可能是与基础设施相关的问题，例如服务器上的内存或 CPU 利用率、存储响应时间，或内部应用程序问题，例如代码效率低下、内存泄漏、事务线程同步失败。由于 NPM 工具无法查看 CPU、内存、存储、应用程序服务器或其他问题指标，因此无法可靠地诊断源自基础架构中其他地方的问题。

自从网络性能监控首次进入市场以来，发生了很多变化。网络曾经是应用程序性能问题的罪魁祸首。现在存储系统和多层应用程序的复杂性已经接管。现代数据中心需要提供应用服务。虽然各个部分很重要，但真正重要的是它们如何协同工作以及它如何影响应用程序性能。

“如果根据 云安 对您的数据中心基础设施指标的介绍，该应用程序确实很慢，您可以找出确切的原因。”

在 云安，我们相信任何影响应用程序性能的事情都应该针对环境进行管理、监控和优化。一旦检测到问题，网络性能监控将诊断网络问题，但您需要更高级别的数据中心视图才能有效监控一切。

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。