Infrastructure Technology Infrastructure Library (ITIL) promises to improve staff productivity, shorten the time needed to resolve problems, and more closely align IT operations with business goals. But in order
Most monitoring tools depend on mapping tools to gather information about network devices and links; then they measure and display the aggregate usage levels of each link and device. But monitoring tools designed to support ITIL go beyond aggregate throughput measurements to display network usage levels and end-user visible performance for each application.
That means ITIL monitoring tools would also work at Layer 7 and provide information on how long it takes for users to get a response after hitting "Enter." These tools measure the time it takes data to transit the network, how long it takes for the application to process the input, and then how long it takes for the response to transit the network on the way back to the end user. That way, for example, if a user ought to get a response in one second but must wait 10 seconds, the networking team can tell whether the problem is with the network or the application itself.
ITIL monitoring tools are offered by a host of vendors, including CA Technologies, EMC and HP, as well as smaller vendors such as Infoblox and Ipswitch.
ITIL monitoring tools: What to consider when buying
Network configuration information must be kept up to date and accessible by ITIL monitoring tools. This means creating configuration databases, but the approach to doing this has changed in ITIL v3. ITIL v2 called for a single Configuration Management Data Base (CMDB) containing configuration information for every aspect of the network. This included detailed information on network devices, servers, OS software and application software. The CMDB included all of the information normally described as configuration information but also included information on software version level, support contract status and so on. But a single CMDB proved to be unwieldy in practice. ITIL v3 suggests creating multiple databases such as one for network devices, one for server hardware, one for applications and so on.
1. Understand how ITIL tools interface before making your selection. Interfaces must exist among the specified ITIL databases. For example, monitoring tools update the performance-specific database throughout the day to record information about changing network usage levels. An interface must exist to the network configuration database to inform monitoring tools if a device or link is reconfigured or fails.
Compatibility should not be an issue when purchasing a full set of tools from a single vendor but can be an issue when integrating tools from multiple vendors. To address the compatibility question, some vendors have created supported interfaces to widely used products from other vendors or added open APIs to their products.
2. Select ITIL tools that enable you to zero in on what is causing performance slowdowns. Reacting to slow performance in a vital application requires speedy determination of the cause. Low-cost monitoring tools may show all of the activity in the network but make it difficult to focus on the critical flows. Since there is so much going on in the network, it can be difficult to get all the extraneous information off the screen to focus on your specific needs. Tools must have the ability to be tailored to monitor critical applications.
3. Select an ITIL monitoring tool that can measure the duration of individual transactions. Throughput rates are important, but end users care how long the transaction takes after hitting "Enter." If transaction times are acceptable for key applications, there is little need to worry about the underlying transaction details.
How to map the network for ITIL
The first step in using these tools is to map the network. The initial network scan often identifies devices that can be removed. If switches have unused ports, eliminate a switch by consolidating active links onto fewer switches. The scan may also detect illegal devices, such as when employees buy their own Wi-Fi access points and connect them to the network, creating a serious security vulnerability.
Rescan the network at regular intervals. Changes to the network should be recorded in the configuration database, but not all will be. Determine how often to rescan based on your past experience with undocumented changes.
ITIL network monitoring: Choosing which applications to watch
It is common to begin the process of analyzing network applications by making a detailed analysis of the performance of network devices. That is useful information; but, instead, begin analyzing by choosing just one application, ideally the one that causes the most calls to the help desk. Use the mapping and monitoring tools to understand which servers are used, the paths between them, expected data rates, and required latency. Identify what aspect of the overall application is causing problems -- it may be an issue in a server or contention for disk or network congestion. Focus on the problem and solve it. The result will be an immediate end-user-visible improvement. The positive feedback will create confidence that the time and effort devoted to ITIL has been worthwhile.
After thoroughly reviewing the initial application, continue the process to other applications. Use the understanding gained from each analysis to continue to monitor application performance, detect problems, and anticipate future capacity issues as business requirements cause traffic levels to change.
Virtualization: A major challenge
Understanding applications and network traffic is difficult enough when components remain in place and the number of ports on a device is fixed. But monitoring network health becomes an order of magnitude more difficult after the introduction of virtual servers that can move from one physical server to another, plus virtual network interfaces that can be created or destroyed in real time. Interfaces between system and network management tools must allow changes in the virtual environment to be quickly communicated.
Where previously the description of a server would include information about its physical aspects, OS, database and applications, with virtualization there must also be a constantly updated record of virtualization software, as well as the number of VMs that run on it and the set of applications that run on them.
Most importantly in all of this, the network and system staff must work together to understand the range of possible physical servers for each application and configure both servers and the network to provide solid performance wherever applications are executed.
About the author: David B. Jacobs of The Jacobs Group has more than 20 years of
networking industry experience. He has managed leading-edge software development projects and
consulted to Fortune 500 companies as well as software startups.
This was first published in June 2010