|
|
|
|
|
|
|
网络监测功能一般是通过将网络探测器设备（如运行探测器软件的PC或专用设备）安装在网络的某一网段上采集数据实现的。探测器常常被插入到局域网交换机上的镜像端口中，即被配置为复制来自交换机上另一个端口的传输流的端口。探测器将只能够从镜像端口采集传输流数据。
|
|
|
|
|
|
在系统试运行之后，需要及时准确地了解网络上正在发生什么事情；什么应用在运行，如何运行；多少PC正在访问LAN或WAN；哪些应用程序导致系统瓶颈或资源竞争，定位问题的根源是在客户端、服务器、应用程序还是网络。在大多数情况下，用户较关心的问题还有，哪些应用程序占用大量带宽，哪些用户产生了最大的网络流量等。
|
|
|
|
|
|
对于使用集线器连接的网络而言，以太网协议的工作方式使网络内源主机发送的，写有目的主机IP地址的数据包，发往同一集线器上的所有主机。但是，这种数据包并不能在协议栈的高层直接发送出去。要发送的数据包必须从TCP/IP协议的IP层交给网络接口。数字信号到达一台主机的网络接口时，在正常情况下，网络接口读入数据帧后进行检查，如果数据帧中携带的物理地址是自己的，或者物理地址是广播地址，则将数据帧交给上层协议软件，也就是IP层软件，否则就将这个帧丢弃。对于每一个到达网络接口的数据帧，都要进行这个过程。换言之，用集线器连接的网络，网内任何一台机器都能够“听到”其他机器的通信，当然也能够将这些通信包抓取下来，这正是网络监控能够实现的前提。所以，在集线器网络中，任何一台机器上如果布署了网络监控软件，则无论数据帧的地址是什么，都不会将帧丢弃，而是将所有的数据帧都交给上层协议软件，对数据包进行分析处理，达到监控的目的。
|
|
|
|
而对于采用交换机、路由器等网络设备的网络而言，由于交换机与集线器最大的不同是通信数据包不再复制到其他所有端口，而是“精确”地发往目标机器所在的那个端口，所以，其他机器就无法“听到”这种目的性较强的通信，也就无法实现数据包的抓取了。要想在基于交换机的网络中部署网络监控，必须采取一些其他手段，在网络的“关口”处设岗，即指所有机器的通信都会流经的端口设置监控。如：通过代理服务器上网的网络需要在代理服务器上部署监控；如果局域网的网关是计算机，则在网关计算机上部署；如果网络的网关是路由器的话，则在交换机和路由器之间加装一个集线器，从而实现监控；其他方法还包括交换机端口镜像等。
|
|
|
|
|
|
Network Vantage是一个全面应用监控和报告产品，它帮助发现和优化网络上的应用性能。Network Vantage采用成熟的软件探针技术，采用被动监听技术监控网络，Network Vantage自动发现应用，追踪通过LAN/WAN结构的应用流量，收集详细的性能列表数据。Network Vantage关联这些信息，并输出到一个用户图形接口——交互式用户界面，它自动识别应用性能是如何在网络上表现的。通过这个交互式用户界面可以找到每个受到影响的工作站、服务器、网段和当日的时间段。这种方式可以确定关键信息如：什么工作站引起最多流量、哪些混合流量（应用和时间段）在关键的WAN网络链路上造成过载、应用或服务器的网络响应时间趋势等。Network Vantage提供的信息有助于分析问题根源，快速决定受影响的服务器数量和用户数。
|
|
|
|
Sniffer是另一种网络监控工具，它可以实现如下功能：
|
|
|
|
|
|
|
|
|
|
. 针对网络上单独的工作站、会话以及部分网络，搜集详细的使用和错误信息；
|
|
|
|
|
|
|
|
. 利用工具在网络上打探针，模拟流量、测量响应时间、计算跳转以及定位问题。
|
|
|
|
|
|
|
|
网络故障以某种症状表现出来，故障症状包括一般性的（如用户不能接入某个服务器）和较特殊的（如路由器不在路由表中）。对每一个症状使用特定的故障诊断工具和方法都能查找出一个或多个故障原因。一般故障诊断模式如下。
|
|
|
|
. 当分析网络故障时，首先要清楚故障现象。应该详细说明故障的症候和潜在的原因。为此，要确定故障的具体现象，然后确定造成这种故障现象的原因和类型。例如，主机不响应客户请求服务。可能的故障原因是主机配置问题、网卡故障或路由器配置命令丢失等。
|
|
|
|
. 收集需要的用于帮助隔离可能故障原因的信息。向用户、网络管理员、管理者和其他关键人物提一些和故障有关的问题。广泛地从网络管理系统、协议分析跟踪、路由器诊断命令的输出报告或软件说明书中收集有用的信息。
|
|
|
|
. 根据收集到的情况考虑可能的故障原因。可以根据有关情况排除某些故障原因。例如，根据某些资料可以排除硬件故障，把注意力放在软件原因上。对于任何机会都应该设法减少可能的故障原因，以便尽快策划出有效的故障诊断计划。
|
|
|
|
. 根据最后的可能的故障原因，建立一个诊断计划。开始仅用一个最可能的故障原因进行诊断活动，这样可以容易恢复到故障的原始状态。如果一次同时考虑一个以上的故障原因，试图返回故障原始状态就困难多了。
|
|
|
|
. 执行诊断计划，认真做好每一步测试和观察，直到故障症状消失。
|
|
|
|
. 每改变一个参数都要确认其结果。分析结果确定问题是否解决，如果没有解决，继续下去，直到解决。
|
|
|
|
|
|
|
|
目前测试需要面对的大多数系统是复杂的分布式多层应用，这些应用的特点是：网络是应用中的一个组件，应用对网络产生影响，同时网络对应用也会产生影响，这样的特点造成应用在网络上的容量需求很难估计，失败的风险较大。如何针对分布式多层应用进行网络故障定位，以及在应用线程级分析中的应用是迫切需要解决的问题。网络应用分析可以发现多种问题，例如，客户端是否对数据库服务器运行了不必要的请求；当服务器从客户端接受了一个查询，应用服务器是否花费了不可接受的时间与数据库服务器通信等。借助于网络应用分析工具，可以在投产前调整应用在网络上的性能。
|
|
|
|
目前成熟的网络应用分析工具很少，并且从事网络故障分析的成本很高。为了实现分布式应用分析，规避应用实施风险，可以重点考虑以下几个方面的测试：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
网络应用分析的关键因素包括：会话信息、包信息、响应时间信息、负载信息、高峰信息、线程信息等。同时还可以采用一些网络应用分析技术，例如，响应时间预测技术与带宽模拟技术等。
|
|
|
|
. 会话信息。指应用程序节点之间的会话信息，会话信息主要包括会话往返行程和会话流量信息。
|
|
|
|
①往返行程。一个往返行程是一对节点之间的一系列帧请求/回应。如下图所示的会话中，往返行程个数是2。一个应用程序如果具有较少的往返行程次数，那么它受网络品质的影响，例如网络延迟的影响较小，反之则较大。
|
|
|
|
|
|
|
|
②流量信息。会话的流量信息包括节点之间传输的字节数或者帧数目，如下图所示表示的是节点之间传输的字节数。
|
|
|
|
|
|
|
|
当捕捉到的节点很多，并且流量纷繁交织时，可以设定某种条件过滤流量。如下图一和如下图二所示，表示的是过滤前和过滤后的流量显示状态。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
可以先对包信息进行解码，然后分析包的详细信息，还可以分析包与包之间的关系、一个时间段内包的数量和包尺寸平均大小，以及包与线程的关系等。如下图所示为利用工具监控与应用相关的包大小及传输方向。大量的红色表示不充足的流量，传输线之间的间隔表示存在延迟问题。
|
|
|
|
|
|
|
|
|
|
如下图所示，分解出客户端响应时间、网络传输时间以及服务器（包括Web服务器、应用服务器、数据库服务器等）的处理时间，为分段定位故障提供依据。
|
|
|
|
|
|
|
|
|
|
如下图所示显示了有效负载与其他负载的比例，来评估与业务相关的流量效率。
|
|
|
|
|
|
|
|
|
|
需要明确高峰发生的时刻以及高峰期的流量，以确定广域网的容量需求，如下图所示表示了一个应用的平均流量和高峰流量。
|
|
|
|
|
|
|
|
|
|
可以对某个线程进行分析，也可对线程之间的关系进行分析。如下图所示，每个线程中都包含了一组包信息，所以可以分析线程和包之间的关联。线程也可以解析为协议信息进行分析。在线程分析时还可以将有关联的线程设置为线程组来分析。
|
|
|
|
|
|
可以利用工具为实验室中得到的测试数据进行响应时间预测。要完成这项工作需要定义三类参数，分别是带宽、背景负载（利用率）以及延迟，例如可以模拟在与服务器通信的带宽、负载、延迟参数下预测某个会话的响应时间。
|
|
|
|
|
|
|
|
如下图一、如下图二和如下图三所示，可以看出随着带宽的逐渐递增，数据传输时间以及网络通信时间的变化趋势。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
带宽模拟的目的是为系统传输选择一个合适的带宽，使得系统的峰值流量可以接受。这些测试数据为选择带宽提供了依据。
|
|
|
|
|
|
|
|
. 第一个例子命名为Taskl，访问一个网页，例如www.cnn.com，速度较慢，问题出在哪里？为了实现故障定位，需要关注的问题如下。
|
|
|
|
|
|
如下图所示，在初始的DNS请求之后有一个8秒的间隔，也就是服务器为了响应DNS请求花费了8秒钟时间。
|
|
|
|
|
|
|
|
如下图一和下图二所示，线程4、5、6所关联的数据包之间有10秒的时间间隔。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这个应用涉及一个DNS服务器和一个Web服务器“www..CNN.com”。如下图所示为应用会话图。
|
|
|
|
|
|
|
|
|
|
从下图所示可知有效负载达到90.9%，应用流量效率较高。
|
|
|
|
|
|
|
|
|
|
从下图可以看到，25～30秒之间应用产生了持续流量高峰，可以将这个高峰与相关执行的线程关联起来。
|
|
|
|
|
|
|
|
. 第二个例子是一个对比测试，我们来看如下图所示的Task1与Task2的测试数据。
|
|
|
|
Task1的执行时间是3.43秒，Task2的执行时间是5.71秒。为什么Task2的流量小于Task1，而执行时间却长于Task1？是否存在性能问题？
|
|
|
|
|
|
|
|
首先我们发现在应用执行的开始存在一个1秒的时间间隔，在2～5秒之间有一个超过2秒的时间间隔。如下图所示为应用Bounce图。
|
|
|
|
|
|
|
|
|
|
客户端发出一个请求，Web服务器响应，在1秒之后又发出了同样的HTTP/GET请求，说明第一个请求失败。如下图所示为HTTP线程与Bounce关联图。
|
|
|
|
|
|
|
|
最后一个Oracle SQL请求在物理时刻1.65秒时发生，而下一个HTTP/GET请求直到物理时刻4.88秒时才发生，说明在请求之间存在较长时间间隔，服务器空闲。
|
|
|
|
从如下图所示的Oracle线程与Bounce关联图可知，每个时间间隔之后，系统都在等待客户端，可以初步将故障定位在客户端，下面可以进一步验证。
|
|
|
|
|
|
|
|
从下图可以看出，响应时间分析显示客户端响应时间为4.6秒，总的响应时间为5.7秒，客户端响应时间占总响应时间的80%左右，客户端的响应时间较长。下面从线程代码级再做进一步验证。
|
|
|
|
|
|
|
|
从下图所示的线程分析可以看到，发生延迟的HTTP请求都发生在客户端。
|
|
|
|
|
|
|
|
|
|
|
|
物理层是OSI分层结构体系中最基础的一层，它建立在通信媒体的基础上，实现系统和通信媒体的物理接口，为数据链路实体之间进行透明传输，为建立、保持和断开计算机和网络之间的物理连接提供服务。
|
|
|
|
物理层的故障主要表现在设备的物理连接方式是否恰当、连接电缆是否正确、MODEM或CSU/DSU等设备的配置及操作是否正确等方面。
|
|
|
|
确定路由器端口物理连接是否完好的最佳方法是，使用show interface命令，检查每个端口的状态，解释屏幕输出信息，查看端口状态、协议建立状态和EIA状态。
|
|
|
|
|
|
数据链路层的主要任务是，使网络层无须了解物理层的特征而获得可靠的传输。数据链路层为通过链路层的数据进行打包和解包、差错检测，并具有一定的校正能力，协调共享介质。在数据链路层交换数据之前，协议关注的是形成帧和同步设备。
|
|
|
|
查找和排除数据链路层的故障，需要查看路由器的配置，检查连接端口的共享同一数据链路层的封装情况。每对接口要和与其通信的其他设备有相同的封装。通过查看路由器的配置检查其封装，或者使用show命令查看相应接口的封装情况。
|
|
|
|
|
|
网络层提供建立、保持和释放网络层连接的手段，包括路由选择、流量控制、传输确认、中断、差错及故障恢复等。
|
|
|
|
排除网络层故障的基本方法是：沿着从源到目标的路径，查看路由器路由表，同时检查路由器接口的IP地址。如果路由没有在路由表中出现，应该通过检查来确定是否已经输入适当的静态路由、默认路由或者动态路由。然后手工配置一些丢失的路由，或者排除一些动态路由选择过程的故障，包括RIP或者IGRP路由协议出现的故障。
|
|
|
