1895年德国物理学家威尔海姆·伦琴 (Wilhelm Conrad Roentgen) 发现了 X 射线，因为在当时这是一种未知的射线，所以把它取名为 X 射线。下图中最左边的图片就是世界上第一张 X 光片，是伦琴教授为他的太太拍摄的。发展到今天，X 射线已经成为一项应用普遍的诊断技术，不仅广泛应用于医疗行业，也应用于结构探伤等工业领域。正是有了 X 光这种物理探测手段，才使我们可以确诊很多病例 (而不是靠猜测)；我们应该庆幸生活在现代社会，除了 X 射线之后还有很多其他的诊疗手段来帮助我们确诊病情，如 B 超、心电图等。
在软件领域，我们也迫切需要类似的探测技术来帮助我们确定应用运行的问题所在，而不是靠猜测来进行故障排除。传统的故障排除过程费时费力，往往花了很多时间还是不知道问题所在。尤其是在应用性能上，一旦出现了性能方面的问题，因为在其他环节上找不出原因，网络团队经常成为责任的承担者，他们也开玩笑戏称自己是“专业的背锅侠”。
NSX Advanced Load Balancer (原 Avi Networks，后面简称 NSX ALB) 在设计之初就考虑到了这些问题，它交付的不仅仅是一个软件的负载均衡器，它也提供了非常丰富的应用分析功能，来帮助用户更加深入地了解应用运行的情况，增加对于应用健康和性能的洞察，从而快速地定位原因和解决问题。NSX ALB 能够实时捕捉应用、用户、服务器和网络的运行数据，并且对收集的数据进行即时分析。它采用控制平面 (控制器 Controller) 和数据平面 (服务引擎 Service Engine) 分离的设计，能够从数据转发平面中收集上百万个数据点，为用户提供对于应用的深入洞察力。下面给大家看几个 NSX ALB 应用分析功能的例子。
端到端的计时
下图是 NSX ALB 对于应用服务请求一个端到端的计时分析，
- Client RTT (客户端网络延迟)：RTT 是 Round Trip Time 的缩写，表示客户端和 NSX ALB 服务引擎之间的平均网络延迟时间，这个时间代表了从客户端到 NSX ALB 建立 TCP 联接所需的时间，取决于两者之间的网络状况。
- Server RTT (服务器网络延迟)：从 NSX ALB 服务引擎到应用服务器之间的网络延迟。
- App Response (应用响应时间)：这个是指应用服务器接收到请求开始到响应之间所花的时间，包括服务器生成数据、到后台数据库查询、开始传输结果给 NSX ALB 服务引擎等操作，这个时间并不包括 NSX ALB 服务引擎和应用服务器之间的网络延迟，即 Server RTT 那部分时间。
- Data Transfer (数据传输时间)：是指 NSX ALB 服务引擎收到第一个字节开始，到客户端完全接收到所有数据为止所花的时间，即在网络上传输数据所花的时间。
- Total Time (服务总时间)：这个总时间是上述时间的总和，是指一个客户端发出服务请求开始到接收到服务响应为止所花费的总时间。
由这个例子可以看到，NSX ALB 把应用服务全过程的各个阶段所花的时间全部都记录了下来，这样有助于分析整个系统的性能瓶颈所在。
用户终端情况分析
下图是 NSX ALB 对于客户端的一个统计和分析，让我们清楚地了解到访问应用服务的客户端分别来自于哪些地区、访问最多的 URL、客户端的类型、以及客户端上的操作系统和浏览器组成。这些数据有助于我们对应用进行有目的的优化，例如访问最多的 URL 代表了用户使用最多的功能，针对这部分功能进行优化能够取得最大的效果。
应用分析功能是 NSX ALB 带给用户的额外惊喜，除了用户原本期望的负载均衡功能之外，还为用户提供了网络和应用运行的可见性。根据用户的统计，跟传统的解决方案相比，NSX ALB 的应用分析功能可以帮助用户在解决网络相关故障方面每个案子平均节省 4 个小时。总体上，NSX ALB 解决方案可以帮助用户节省 70% 的总体拥有成本，以 5 倍的速度来交付应用。
