盲目的故障排除 — 依旧是 IT 领域一些问题未能解决的主要原因

by Chris Greer

用几分钟尝试本项操作练习。拿起一个 100 块拼图,戴上眼罩,将这些图块倒在桌上,然后把它们拼起来。

您做得到吗?是的,如果要拼凑这些图块,我们可以用技巧将它们拼在一起,但是一旦戴上眼罩再来拼图,事情看起来有些麻烦。

这恰好说明了目前 IT 工程师可能的处境。网络和应用程序问题的范围和复杂性日益增加,解决这些问题需要完整客户端到后端数据库的可视性。为什么?为此,让我们看一看从客户端按键到服务器响应过程的客户端请求时间,以了解整个过程需要多少设备的支持。然后,我们可以确定在我们自己的 IT 环境中是否存在可视性方面的差异。

客户端按键到应用交付

首先,将客户端连接至应用服务器。假设它们位于我们控制的数据中心,而不是在公共环境或托管式云环境中。同时,假设工作人员正用笔记本电脑通过无线网与会议室保持通信。如要进行连接,客户端必须首先连接至 WiFi 环境,确保数据传输速率以及信号足够清晰,以支持应用吞吐量。验证域后,客户端会向 DNS 服务器请求应用服务器 IP,然后使其连接至应用服务器。在连接至服务器环境的过程中,客户端的数据包可能会横穿任意数量的物理和虚拟网络设备,其中可能包括 MPLS 或服务提供商提供的其他 WAN 环境。

一旦到达数据中心,负荷量平衡器可能会首先处理请求,然后将其转发至可用的前端服务器。此时,应用程序可能会要求将后端事务传送至应用或数据库服务器,这种情况也可能出现在相同或相邻的虚拟环境中。形成响应后,最终它会发回至相似网络路径上的客户端,但愿不会出现拥塞或丢包。数据包生命周期中的所有这些组件(在某些环境中可能更多)中,我们可有效监控的有多少?这不仅包括对当前问题的实时秒监控,还包括反复出现的间歇性问题的回溯式数据。在考虑高性能应用程序所需的所有组件后可以发现,我们的可视性存在巨大差异,这使我们在排除这些领域的故障时存在盲目的行为。

The OptiView XG and TruView provide the comprehensive tools necessary for complete end-to-end visibility of application delivery.OptiView XG 为无线和有线网络环境提供实时和回溯式数据,其中包括详细的可视性路径分析功能,它可以查出数据包路径中的网络问题。In the application environment, the TruView leverages stream-to-disk packet storage, application response time, transaction analysis, and flow data to isolate problems to a single link, server, or transaction.
利用这两个产品,实现网络和应用中的盲点可视性便不在话下。它使 IT 工程师可以快速清晰地发现影响性能的问题根源。

 

相关的 IT 网络资源
 

Continue to our Network Insider Blog for more on network monitoring, analysis and troubleshooting

 
 
Powered By OneLink