快速隔离基于云的应用程序问题

问题：远程办公室的用户使用云托管的应用程序，应用性能体验不佳。

主张：IT组织认为服务器资源不足。服务器提供商说问题出再客户的网络上。双方都没有证据。

解决问题所需信息

服务器ping往返时间看起来似乎还可以，至少当工程师在中央办公室偶尔进行测试时看起来还不错。但是此测试仅验证了客户端网络和云环境之间的网络路径。当问题发生时，他们需要数据包级别的详细信息。之所以很难做到这一点，是因为问题并不总是在工程师在现场时就发生的。他们需要一种方法来简单、持续地从客户端捕获信息，以便问题得以解决。

最近很多应用程序都迁到云中，因此网络工程团队不再有权访问服务器端进行捕获。

一旦在问题期内正确捕获了问题，就可以测量诸如网络往返时间、服务器响应时间、TCP重传频率和其他TCP离群值之类的统计信息，以隔离真正的问题域（无论是客户端、网络还是云服务器）。

问题解决方案

在客户端网络和边缘路由器之间串联IOTA，这样IT工程师能够在远程站点上实现安装。这个优势使他们能够看到多个客户的活动，而不仅仅是一个。他们可以将问题时期和时间之内的客户活动与良好的性能进行对比。

当再次遇到性能问题时，工程师们可以从中央办公室使用基于Web的界面立即访问IOTA，并开始进行故障排除。几分钟之内，他们就可以访问隔离问题域所需的核心细节。

第1步——确定正确的时间周期

首先，工程师需要过滤问题发生的时间。从主页仪表板的开始屏幕中，他们可以跨越问题发生的时间范围，并查看该时间段内的IP对话。他们观察到了问题客户机和服务器的地址。

第2步——检查服务器响应时间

现在他们有了正确的时间周期，他们需要查看服务器与客户端之间的对话的运行状况。使用UserExperience – Application Latency 仪表板，他们可以测量服务器的应用程序响应时间，无论流量是否加密。他们注意到服务器响应时间的最大延迟为206毫秒。将其与正常的性能时段进行比较，此度量没有显着变化。服务器即使在出现问题期间，也能像往常一样做出响应。

第3步——对TCP进行故障排除

接下来，工程师可以使用“TCP Troubleshoot”仪表板查看流量流本身的运行状况，并设置往返于服务器IP的流量过滤器。

这就是问题所在。在某些时候，客户端和服务器之间的网络往返时间将飙升至超过两整秒！重传统计数据还显示，在此问题期间大量丢失了数据包。

将这些数据与正常性能期间的数据包统计数据进行比较，工程师可以看到，当客户端拥有良好的体验时，网络往返时间很短，并且没有重传。

这有助于他们发现，在性能问题期间网络流量下降，并且延迟很高。通常，这是由网络拥塞或错误的链接引起的。

他们还能做些什么来找出根本原因呢？

第4步——检查应用程序带宽

在问题期间，工程师们能够全面调查网络站点的使用情况。通过将带宽仪表板设置为与性能问题相同的时间范围，工程师们能够看到特定应用程序（Microsoft 365）的利用率出现峰值。同样的情况也发生在上一次问题中。

只需单击几下，他们就可以看到哪个用户正在将如此多的数据传输到365，以及多久执行一次。他们发现，每一个客户抱怨表现缓慢时，都会出现这种效果的高峰。

结论

使用这些仪表板可以使工程师指出问题的主要症状（数据包丢失和高延迟，是由网络拥塞引起的），从而将其引导到根本原因（有人不小心将其计算机配置为每小时对Microsoft 365进行一次完全备份！）

IOTA提供了正确的数据，正确的时间，与一个简单的工作流程，让工程师可以简单和远程访问的数据，解决网络问题。