Every good network administrator knows that in order to achieve optimum operation, servers must be monitored to see that vital stats stay within acceptable limits. However, while it is common practice to monitor hardware components such as memory, processor and hard disk usage inside the server, network traffic monitoring tends is often overlooked. A server’s network interface is its connection to the outside world and shouldn’t be ignored. Even the most powerful server available will appear to drag its heels if the network interfaces are not up to par.
Some larger organizations invest a lot of money in network traffic monitoring applications. However, before you spend tens of thousands of dollars, you should investigate network monitoring functions provided by the tools included with Windows Server 2003.
That is not to say that there isn’t a place for third-party network management applications, but, depending on your needs, there is no reason why you can’t implement a solid network traffic monitoring policy with the tools you already have.
Why Network Management
Network monitoring allows you to answer three fundamental questions that are important elements of your network management strategy.
- It lets you determine how much traffic is traveling over the network interfaces, and whether this amount is easily accommodated.
- It allows you to see what kind of traffic is being sent to and from the server, and thus determine to what extent each traffic type is responsible for network interface load.
- It allows you to identify who is using the services of the server. This can allow you to more effectively plan server placement on the network.
Performance Monitoring at Work
Here’s a simple example of how traffic monitoring tools can help you in network planning. Imagine you have a server that is hosting both a Web server and an FTP server application. Your users are complaining that Web server response is sluggish, yet you know from monitoring the processor, memory and storage elements of the system, that the server, if anything, is underutilized.
By monitoring the network traffic, you determine that there is a very high volume of FTP traffic. As a result, traffic to the Web server is being delayed. You also determine that many of the FTP requests are coming from a small group of users in the publishing department, located some four hops away on the network. Armed with this information, you could look at either relocating the application to a server closer to the publishing department, or determine if physically moving the server nearer to the users is more practical.
Tools of the Network Trade
Windows Server 2003 features three basic tools for monitoring network traffic — Task Manager, Performance Console and Network Monitor. (In this article, we take a look at Task Manager and Performance Console. We’ll dig into Network Monitor in the next installment of our look at network monitoring tools.)
|For a complete look at your network, System Monitor lets you to view statistics on a range of components, software elements and protocols.|
Task Manager is by far the most basic of the three. It provides only real-time monitoring. There is no logging capability, making its usefulness as a proactive monitoring tool somewhat limited. The information provided in Task Manager is also basic. Only a network utilization figure, expressed in a percentage, is shown. From the perspective of designing a network monitoring strategy, this information is not detailed enough to be of much use.
The Performance Console, however, is much more powerful, and has the advantage of providing the capability to record information for later comparison. Collecting network traffic statistics with Performance Console allows you to build a history of network traffic statistics for your servers. These statistics can later be used for comparison.
You access the Performance Console on Windows Server 2003 via the Administrative Tools program group and has two distinct utilities within it — the System Monitor and Performance Logs and Alerts.
System Monitor is a real-time monitoring tool that allows you to view statistics on a range of components, software elements and protocols. Each of these is referred to as a Performance Object. Each Performance Object then has a set of counters associated with it, allowing you to monitor specific elements of that object.
|Counters allow you to monitor components, software elements and protocols.|
The sheer variety of counters allows you to break down your monitoring with a high degree of granularity. For example, you can monitor the total amount of data sent over all interfaces or the number of Internet Control Message Protocol ICMP source quench packets that have been received.
Many of the counters are ideally suited to tracking down network traffic issues, such as identifying how much DNS traffic is being sent or received by the server. In fact, the DNS Performance Object has more than 60 counters associated with it.
This dizzying array of counters includes the capability to measure traffic associated with incremental or full zone transfers, information on failed or successful recursive queries, and secure update failures. Other Performance Objects like Network, IPv4 (or IPv6 if you are an early bloomer), and the aforementioned ICMP offer similarly detailed counter lists.
It Pays to Keep a Steady Count
Each of the counters has an accompanying description that you can read to determine if the counter you are adding is going to yield the information you are looking for. It is worth spending a few moments reading the descriptions, which are generally informative. By understanding the range of available counters related to network traffic monitoring, you can fine-tune your network traffic monitoring, focusing on specific areas. That said, there are three counters that you may want to monitor on an ongoing basis. All three of the following counters are related to the Network Performance Object, and provide a good overview of the network related health of your server. These counters are the following:
Network Interface: Bytes Total/sec – This counter provides the number of bytes sent and received per second by the network interface adapter. A significant drop in performance could indicate a faulty network adapter. If you have more than one network adapter in your server, you can choose to monitor any or all of the adapters at one time.
Network Interface: Output Queue Length – This counter provides the number of packets waiting to be transmitted by the network interface. Ideally, this value should be zero, indicating that data is not having to wait before being sent to the network. However, on a busy server, values of two or less are acceptable. If the number is abnormally high on a consistent basis, you should look for a problem with a network card or some other piece of network hardware. Another possible cause of high output queue length is a corrupt or incorrect network card driver, though such a problem normally manifests itself in other ways than just an increased output queue length statistic.
Server: Bytes Total/Sec – This often-misunderstood counter provides the total number of bytes sent and received by the server over all of its network interfaces. In a typical environment, the value of this counter should be no more than 50 percent of the total bandwidth capacity of all the network interfaces combined. A value higher than 50 percent could indicate that network interfaces of the server simply can’t keep up with demand. You only have two options in this case. Install faster network interfaces, or move some applications or functions off that server.
Regardless of what or how many counters you choose to add to the graph of System Monitor, the information is updated every second. This makes for a 1-minute-and-40-second snapshot of the system performance on the screen at any one time. Increasing the update interval, or sample rate to give it its proper name, to every 5 seconds, will yield a display lasting 8 minutes and 20 seconds. This might seem better, but setting the sample rate at too much of an interval can cause you to miss spikes in utilization, as they may occur between sample points.
We’ll talk more about the appropriate setting for the sample rate in Part 2 of this article, and also look at how you can use the Performance Logs and Alerts feature of the Performance Console to record information for future reference. In addition, we’ll discuss some useful third-party network traffic monitoring tools.