Method and system for automatic discovery of network services

Abstract

A method for identifying services, service elements and dependencies among the services and service elements includes executing first and second phases of discovery. In the first phase, the services and service elements are detected, as well as a first set of dependencies. The second phase is based on results of the first phase and is focused upon detecting inter-service dependencies, i.e., conditions in which proper operation of one service relies upon at least one other service. Various techniques may be used in executing the first phase, including accessing information in a domain name service (DNS) of the network to identify dependencies, as well as services and service elements. Discovery within the first phase may also be based upon recognizing naming conventions. Regarding the second phase, one approach to discovering inter-service dependencies is to deploy discovery agents implemented in computer software to access content of configuration files of applications detected in the first phase. Discovery agents may also be used to monitor connections completed via specified service elements detected in the first phase, such that other inter-service dependencies are identified. As an alternative or additional approach, network probes may be deployed to access information of data packets transmitted ted between service elements detected in the first phase, with the accessed packet information being used to detect inter-service dependencies. When information of the DNS is accessed in the first phase, the information is used as a basis for determining at least some of (1) groups of service elements that are generally equivalent with respect to executing a particular service within the network, (2) hosts supporting virtual hosting, (3) hosts supporting virtual servers, and (4) name servers.

Claims

What is claimed is:

1. A method of identifying elements, services and dependencies among said elements and services of a network comprising steps of:

executing a first phase of discovery such that a plurality of services and service elements that are cooperative in performing said services within said network are detected, including discovering a first set of dependencies among said services and service elements, where said services are functionalities offered by said network to perform specific tasks;

executing a second phase of discovery using discovery results of said first phase such that inter-service dependencies among said services detected in said first phase are identified, each said identified inter-service dependency being related to a reliance of one of said services upon at least one other of said services; and

forming a network model that is specific to at least one said specified service detected in said first phase such that said network model maps said first set of dependencies and said inter-service dependencies that are relevant to said at least one specified service.

2. The method of claim 1 wherein said step of executing said second phase to identify said inter-service dependencies is an automated process that is based on said detection of said services and service elements in said first phase of discovery.

3. The method of claim 1 wherein said step of executing said second phase includes deploying discovery agents implemented in computer software, including enabling said discovery agents to access content of configuration files of applications that are detected in said first phase of discovery, such that accessing said content is specific to determining said inter-service dependencies.

4. The method of claim 1 wherein said step of executing said second phase includes deploying discovery agents implemented in computer software, including enabling said discovery agents to monitor connections completed via specified service elements detected in said first phase of discovery, such that said inter-service dependencies are identified.

5. The method of claim 4 wherein said step that includes deploying said discovery agents includes enabling said discovery agents to identify Transmission Control Protocol (TCP) connections of at least one host that is detected in said first phase.

6. The method of claim 1 wherein said step of executing said second phase includes deploying network probes to access information embedded within data packets transmitted between said service elements detected in said first phase, said second phase further including utilizing said accessed information of said data packets to detect said inter-service dependencies.

7. The method of claim 1 wherein said step of executing said first phase includes accessing information of a domain name service (DNS) of said network, including identifying at least two of (1) internal and external name servers, (2) round-robin service groups of said network, and (3) virtual servers and virtual hosts of said network.

8. The method of claim 1 wherein said step of executing said first phase includes recognizing naming conventions within said network, including recognizing and utilizing naming conventions relating to terminal servers of said network, said step of executing said first phase further including identifying execution dependencies relating directly to an application server being executed on a host machine and including identifying component dependencies that ensure redundancy of said services.

9. The method of claim 8 wherein said step of recognizing said naming conventions includes recognizing and utilizing patterns of host names to identify World Wide Web (WWW) sites that are stored on a common host machine of said network.

10. The method of claim 1 further comprising a step of selecting a particular core service of said network, said steps of executing said first and second phases and forming said network model being implemented in a manner specific to modeling said core service, said step of forming said network model thereby providing a representation of nodes and node-to-node connections which link all of said services, service elements and dependencies that are relevant to said core service.

11. A method of identifying elements, services and dependencies among said elements and services comprising steps of:

accessing information of a domain name service (DNS) of a network; and

utilizing said information of said DNS as a basis for determining a plurality of:

(a) a group of service elements that are generally equivalent with respect to executing a particular service within said network;

(b) a host supporting virtual hosting;

(c) a host supporting virtual servers; and

(d) name servers that are authoritative for a domain.

12. The method of claim 11 further comprising a step of selecting a core service of said network, said step of utilizing said information of said DNS being executed to model said core service, including modeling said core service such that said network components that are used to perform said core service are represented as nodes and network dependencies among said network components are represented as edges among said nodes.

13. The method of claim 12 wherein said step of selecting said core service includes identifying a service of an Internet Service Provider (ISP) and said step of modeling is executed to represent the cooperation within said ISP to perform said core service.

14. The method of claim 13 wherein said step of utilizing said information further includes determining SMTP servers that correspond to hosts which run POP3 servers.

15. The method of claim 14 wherein said step of utilizing said information further includes determining external mail gateways for the ISP.

16. A system for identifying service elements, services and dependencies among said service elements and services of a network comprising:

a discovery engine means for driving first and second phases of discovering said service elements, services and dependencies, where said services are functionalities offered by said network to perform specific tasks and where said service elements are cooperative in performing said services;

first discovery tools, responsive to said first phase of said discovery engine means, for accessing first information indicative of said service elements, services and a first set of dependencies among said service elements and services, including first information indicative of applications and first information indicative of dependencies among said service elements;

second discovery tools, responsive to said second phase of said discovery engine means and based on said first information, for accessing second information indicative of a second set of dependencies among said service elements and services, said second discovery tools including discovery agents executed in computer software that is configured to detect inter-service dependencies among said services; and

means for generating a discovered instance of at least a preselected portion of said network based on said first and second information from said first and second discovery tools thereby generating a network model which maps said first and second information as interconnected nodes in said discovered instance of said preselected portion.

17. The system of claim 16 wherein said discovery agents are configured to access configuration files of said applications and detect said inter-service dependencies based on said configuration files.

18. The system of claim 16 wherein said discovery agents are configured to monitor connections completed via specified service elements detected by said first discovery tools, said connections including TCP connections completed via a specified host machine.

19. The system of claim 16 wherein said first discovery tools include software configured to access a DNS of said network and to retrieve information indicative of at least two of (1) name servers, (2) round-robin service groups, and (3) virtual servers and virtual hosts.

20. The system of claim 16 wherein said first discovery tools include means for recognizing naming conventions of said service elements of said network, thereby enabling classification of said service elements at least partially based on type and geographic location.

Description

TECHNICAL FIELD

The invention relates generally to methods and systems for discovering service elements that enable services available via a network, as well as for discovering inter-relationships among the services. Such information may be used for constructing models of services, permitting network personnel to assess the health of the service and to diagnose problems associated with the service.

BACKGROUND ART

Originally, computer networks were designed to have a centralized, network topology. In such a topology, a centralized mainframe computer is accessed by users at computer terminals via network connections. Applications and data are stored at the mainframe computer, but may be accessed by different users. However, a current trend in network design is to provide a topology that enables distributed processing and peer-to-peer communications. Under this topology, network processing power is distributed among a number of network sites that communicate on a peer-to-peer level. Often, there are a number of servers within the network and each server is accessible by a number of clients. Each server may be dedicated to a particular service, but this is not critical. Servers may communicate with one another in providing a service to a client.

Networks vary significantly in scope. A local area network (LAN) is limited to network connectivity among computers that are in close proximity, typically less than one mile. A metropolitan area network (MAN) provides regional connectivity, such as within a major metropolitan area. A wide area network (WAN) links computers located in different geographical areas, such as the computers of a corporation having business campuses in a number of different cities. A global area network (GAN) provides connectivity among computers in various nations. The most popular GAN is the network commonly referred to as the Internet.

The decentralization of computer networks has increased the complexity of tracking network topology. The network components (i.e., "nodes") may be linked in any one of a variety of schemes. The nodes may include servers, hubs, routers, bridges, and the hardware for linking the various components. Systems for determining and graphically displaying the topology of a computer network are known. U.S. Pat. Nos. 5,276,789 to Besaw et al. and 5,185,860 to Wu, both of which are assigned to the assignee of the present invention, describe such systems. As described in Besaw et al., the system retrieves a list of nodes and their interconnections from a database which can be manually built by a network administrator or automatically constructed using computer software. The system can be configured to provide any one of three views. An internet view shows nodes and interconnections of different networks. A network view shows the nodes and interconnections of a single network within the internet view. A segment view displays nodes connected within one segment of one of the networks. Selected nodes on the network, called discovery agents, can convey knowledge of the existence of other nodes. The network discovery system queries these discovery agents and obtains the information necessary to form a graphical display of the topology. The discovery agents can be periodically queried to determine if nodes have been added to the network. In a Transmission Controller Protocol/Internet Protocol (TCP/IP) network, the discovery agents are nodes that respond to queries for an address translation table which translates Internet Protocol (IP) addresses to physical addresses.

The Besaw et al. and Wu systems operate well for graphically displaying hardware components and hardware connections within a network. From this information, a number of conclusions can be drawn regarding the present capabilities and future needs of the network. However, these systems do not discover services, their elements and interdependencies. Moreover, the interdependencies of the components in providing a particular service are not apparent from the graphical display that is presented by the system. The complexities of such interdependencies continue to increase in all networks, particularly the Internet. Moreover, these systems are designed in a monolithic manner. This does not allow the management system to be extended to discover and manage new service elements or new services.

Another approach is described by J. L. Hellerstein in an article entitled "A Comparison of Techniques for Diagnosing Performance Problems in Information Systems: Case Study and Analytic Models," IBM Technical Report, September, 1994. Hellerstein proposes a measurement navigation graph (MNG) in which network measurements are represented by nodes and the relationships between the measurements are indicated by directed arcs. The relationships among measurements are used to diagnose problems. However, the approach has limitations, since MNGs only represent relationships among measurements. An ISP operator must understand the details of the measurements (when, where, and how each measurement is performed) and their relationships to the different service elements. This understanding is not readily available using the MNG approach. Automatic discovery capabilities do not exist in this system to discover relationships among measurements.

The emergence of a variety of new services, such as World Wide Web (WWW) access, electronic commerce, multimedia conferencing, telecommuting, and virtual private network services, has contributed to the growing interest in network-based services. However, the increasing complexity of the services offered by a particular network causes a reduction in the number of experts having the domain knowledge necessary to diagnose and fix problems rapidly. Within the Internet, Internet Service Providers (ISPs) offer their subscribers a number of complex services. An ISP must handle services that involve multiple complex relationships, not only among their service components (e.g., application servers, hosts, and network links), but also within other services. One example is the web service. This service will be described with reference to FIG. 1. Although it may appear to a subscriber of the ISP 10 that the web service is being exclusively provided by a web application server 12, there are various other services and service elements that contribute to the web service. For instance, to access the web server 12, a Domain Name Service (DNS) server 14 is accessed to provide the subscriber with the IP address of the web site. The access route includes one of the Points of Presence (POP) 16, a hub 18, and a router 20. Each POP houses modem banks, telco connections, and terminal servers. A subscriber request is forwarded to and handled by a web server application. The web page or pages being accessed may be stored on a back-end Network File System (NFS) 22, from which it is delivered to the web server on demand. When the subscriber perceives a degradation in the Quality of Service (QoS), the problem may be due to any of the web service components (e.g., the web application server 12, the host machine on which the web application server is executing, or the network links interconnecting the subscriber to the web server), or may be due to the other infrastructure services on which the web service depends (e.g., DNS or NFS). The ISP system 10 of FIG. 1 is also shown to include an authentication server 24 for performing a subscriber authentication service, a mail server 26 for enabling email service (for login and email access), and front-end and back-end servers 28, 30 and 32 for allowing Usenet access.

Subscribers demand that ISPs offer reliable, predictable services. To meet the expectations of subscribers and to attract new subscribers, ISPs must measure and manage the QoS of their service offerings. This requires a variety of tools that monitor and report on service-level metrics, such as availability and performance of the services, and that provide health reports on the individual service components. Unfortunately, the majority of management systems have not kept pace with the service evolution. Available management systems lack the capability to capture and exploit the inter-relationships that exist among services available in a network environment, such as the Internet. Typically, these management systems discover and manage service elements in isolation. Moreover, these systems are implemented in a monolithic manner and are not easily extensible to discovering and managing new network services and service elements. Adding new discovery and management capabilities to these systems requires extensive redesign and modification of the management system.

Each network is unique in various respects, such as the configuration of servers, the types of application servers, the service offerings, the organizational topology, and the inter-service dependencies. Therefore, in order to accurately understand the operations of the network, specific models must be crafted for the services provided within the network. However, handcrafting models of network services requires an enormous effort on the part of a human expert or group of experts.

What is needed is a comprehensive method and system that discovers services and service elements of a network, and discovers the dependencies among the services and service elements. This information can then be used to automatically generate models of the discovered services.

SUMMARY OF THE INVENTION

A method of identifying service elements, services and dependencies among the elements and services of a network includes executing a two-phase discovery process. In the first phase of discovery, the services and service elements are detected, as well as a first set of dependencies. The second phase of discovery is focused upon the dependencies, specifically inter-service dependencies in which one discovered service is reliant upon one or more other discovered services.

The term "service" is defined herein as "a functionality offered by a network to a user to perform a specific set of tasks." Performance of the service involves a number of cooperating service elements, such as network routers, servers, applications and the like. Services include application services (such as web and email access) and network services (such as a Virtual Private Network).

The first phase of discovery may be considered as a "black-box approach." At the beginning of the phase, the system is likely to have no information regarding the services and service elements that exist in a network, such as an Internet Service Provider (ISP). Using a variety of techniques, this first phase obtains information relating to the services and service elements in the network. Execution, component, organizational and some inter-service dependencies are discovered during the first phase. Since a black-box approach is adopted, this first phase of discovery can be executed from a management station that is separate from elements of the network being discovered. For example, in an ISP environment, subject to the availability of a network connection from the management station to the server farm of the ISP, this first phase can be executed when the management station is outside of the server farm. Thus, this first phase may be referred to as "external discovery." However, it should be understood that the first phase can be executed exclusively within the network of interest.

The second phase of discovery is targeted at identifying inter-service dependencies. This phase uses the knowledge of the services and service elements obtained in the first phase, and targets the discovered services to obtain dependency information relating to the services. This dependency information likely requires direct access to the elements of the network. Therefore, the second phase may be considered to be "internal discovery." The step of executing the second phase to identify the dependencies is a software-based automated process. The discovery system may include discovery agents that are configured to access the content of configuration files of applications that were detected in the first phase of discovery. As an example of processing the content of a configuration file to discover inter-service dependencies, a configuration file of a web server may be accessed to discover whether the web server has a dependency on an NFS service. Discovery agents may also be deployed to monitor connections completed via service elements that were detected in the first phase of discovery. Information received during the monitoring may be utilized to identify inter-service dependencies. For example, discovery agents may be deployed by a discovery engine of the system to identify Transmission Control Protocol (TCP) connections of at least one host that was detected in the first phase. This technique exploits the fact that most TCP implementations enforce a three-minute delay for connections in a TIME_WAIT state of TCP, so that a connection persists for approximately three minutes after it is no longer in use.

As an additional or alternative source of information for the second phase, network probes may be deployed by the discovery engine to access information embedded within data packets transmitted by service elements detected in the first phase. Since most TCP/IP communication is based on source/destiny port numbers, by processing the headers of captured packets, a software probe can deduce many of the relationships that exist among services.

Returning to the first phase of identifying services and service elements, the domain name service (DNS) may be accessed to obtain information that specifies services, service elements, component dependencies, organizational dependencies, and some inter-service dependencies. The DNS of the network may be used to identify some, and preferably all, of: (1) any external name servers (organizational dependency); (2) round-robin service groups that are utilized to provide scalability and redundancy for the network (component dependency); (3) naming conventions that are employed by the network (organizational dependencies); (4) any external mail gateways of the network (organizational dependencies); and (5) any SMTP servers corresponding to hosts that run POP3 servers (inter-service dependencies).

The recognition of the naming conventions used by the network provides evidence of any virtual hosts or virtual servers. For example, an ISP may use a single host machine to support multiple customer web sites. While each customer web site may be associated with a unique IP address, there will be a naming pattern that identifies the common host machine. Naming conventions may also be used to recognize associations between terminal servers of an ISP and POP sites.

An advantage of the invention is that the discovery process may be used to automatically detect services, service elements and dependencies with regard to a selected core service of a network (e.g., Read Mail Service of an ISP). That is, the method and system may be used to model the selected core service, permitting network personnel to assess the health of the service and to diagnose problems associated with the service.

Another advantage is that the system is extensible to discover services or service elements that are added to a network. When a new service or service element is introduced, a user can add a new discovery module (e.g., a discovery agent) for the service or service element. The discovery engine is then able to discover instances of the added service or service element without any changes or enhancements to the discovery engine. This approach permits third-party discovery modules to be introduced into the system.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic view of an exemplary prior art Internet Service Provider (ISP) system.

FIG. 2 is a schematic view of a process for modeling a selected service available via a network.

FIG. 3 is a block diagram of components of a system for modeling a selected service available via a network, such as the ISP of FIG. 1.

FIG. 4 is a block diagram of a management system having components of FIG. 3.

FIG. 5 is an exemplary layout of components for utilizing the Read Mail service of the ISP of FIG. 1.

FIG. 6 is a graph of nodes of a Read Mail service model configured using the system of FIG. 3.

FIG. 7 is an alternative Read Mail service model graph.

FIG. 8 is a schematic view of first phase internal discovery processing using the system of FIG. 3.

FIG. 9 is a schematic view of second phase external discovery processing using the system of FIG. 3.

FIG. 10 is a process flow of steps of the first phase discovery of FIG. 8.

FIG. 11 is a process flow of steps of the second phase discovery of FIG. 9.

FIG. 12 is a block diagram of the operation of the discovery engine of FIG. 4.

FIG. 13 is a block diagram of the discovery engine of FIG. 12.

BEST MODE FOR CARRYING OUT THE INVENTION

The invention relates to the discovery process for enabling automated detection of service elements and/or services that are utilized by a specific network to provide a particular service. One application of the invention is to model the particular service, so that dependencies among services and service elements (e.g., servers, hosts and network links) may be readily determined by network personnel. While the discovery process will be described primarily with reference to application to an ISP system, the process has other applications. That is, the process may be used in other network environments (e.g., a corporation's network).

FIG. 2 is an overview of the auto-discovery process for generating a service model instance 200 for a particular network 202. In FIG. 2, the rectangles represent data stores and the ellipses represent processing elements. A service-specific discovery template 204 is accessed upon initiation of the auto-discovery process. The discovery template defines the services and service elements that are anticipated as cooperating to provide the core service. Moreover, the discovery template identifies particular discovery tools (i.e., discovery modules and/or agents) that are to be used for each service and service element, as well as any dependencies that a particular discovery tool may have on outputs from other discovery tools. The template preferably includes instructions for configuring the outputs of the discovery tools. A more thorough description of the discovery template will follow, particularly with reference to Table 2, which is an example of a discovery template specification. A more thorough description of the discovery tools 206 will also be provided below, with reference to FIGS. 12 and 13.

The auto-discovery approach is dividable into two phases. In the first phase auto-discovery procedure 208, a "black-box approach" is adopted. Initially, no information about the services or service elements may be immediately available. Using a variety of techniques, information is obtained for the purpose of identifying relevant services, service elements, component dependencies, execution dependencies, organizational dependencies and some inter-service dependencies. In one of these techniques, the information that is available in the domain name system of an ISP is used to discover the existence and the relationships among different services and service elements. In order to allow subscribers to access a host using its host name, rather than requiring specification of an IP address that is more difficult to remember, DNS is used to map the host names of the IP addresses for all hosts in the ISP system. Moreover, the exchange of email messages across hosts occurs using the mail exchange records (MX records) maintained by the DNS. In summary, the domain name system stores a wealth of information that is used in the first phase of the auto-discovery process to discover Internet services and relationships among the services. Other techniques may be used in this first phase to supplement the information acquired from the domain name system. Since these techniques may be exploited separately from the servers of the network 202, this first phase may be referred to as "external discovery." However, the process may occur entirely within the network environment.

Instance information 210 is acquired in the first phase procedure 208. In addition to the identification of services and service elements, the instance information 210 identifies dependencies. There are a number of inter-dependencies of concern to the auto-discovery process. These inter-dependencies include execution dependencies, component dependencies, inter-service dependencies, and organizational dependencies. An execution dependency relates directly to an application server process being executed on a host machine. The types of application servers that are executed on host machines include web, email, news, DNS and NFS. A component dependency occurs in order to ensure scalability and redundancy of a service. For example, a web service may be provided collectively by a number of "front-end servers" (FESs), with round-robin DNS scheduling being used to provide subscribers with a domain name that maps to one of the FESs. ISPs often replicate web, email and news content across a number of servers. The round-robin scheduling balances the load among the servers. The servers are grouped together and assigned a single domain name in the DNS database. When the DNS server receives a request for the domain name, the IP address of one of the servers is acquired in the round-robin scheme.

An inter-service dependency occurs when one service accesses another service for its proper operation. For example, a web service depends on a DNS service to allow the subscriber to connect the web server host using its IP address, and an NFS service is used to access the web content. As another example, a Read Mail service depends on an authentication service to verify the identity of the subscriber, uses a DNS service to log the subscriber's IP address, and uses an NFS service to access the mail content.

Finally, an organization dependency occurs when there are different ISP operations personnel (e.g., subject matter experts) who are responsible for different services and service elements. For example, an ISP may have a first supervisor managing the web service, a second supervisor managing DNS, and a third supervisor managing NFS. Operational responsibilities may be delegated based upon the geographical location of the service elements. Since the precise organization structure may vary from one ISP to another, the auto-discovery mechanism provides a means by which it can be quickly customized for a particular ISP system.

The first phase auto-discovery procedure 208 provides discovered instance information 210 that identifies most of the execution, component and organization dependencies, as well as some of the inter-service dependencies. A partial service model instance generator 212 is then used to provide a partial service model instance 214. Optionally, configuration data 216 may be used to allow an operator to customize a service model instance 200. Using a configuration interface which will be described with reference to FIG. 4, the operator can specify categorization criteria for services and service elements. Thus, the service model instance 200 can be configured to meet the specific needs of the operator.

In a second phase auto-discovery procedure 218, an "internal" view of the network 202 is acquired. The internal discovery of the second phase is intended to fill any "holes" in the partial service model 214, and particularly focuses on identifying inter-service dependencies. There are two basic approaches to the internal discovery of the second phase. One approach is the use of network probes, which are implemented in software and are installed at strategic locations on the network to acquire information from headers of packet transmissions. By processing the headers of packets, a software probe can deduce many of the relationships that exist among servers. The second basic approach is to use special-purpose discovery agents that are installed on the ISP hosts to discover relationships among services. Rather than examining headers of packet transmissions, the special-purpose agents use a number of operating systems and application-specific mechanisms (such as processing service configuration information and application-dependent monitoring tables) to discover inter-service dependencies.

The inter-service dependency information 220 from the second phase auto-discovery procedure 218 is combined with the partial service model instance 214 using a second service model instance generator 222. The output of the second service model instance generator is the completed service model instance 200.

The invention will be described primarily in its preferred embodiment of using the discovery template to detect both services and service elements to form a service model. However, the discovery process may be used without the discovery template and without restricting the process to identifying only the services, service elements and dependencies relevant to a single core service.

One Embodiment for Using the Instance Information

As previously noted, the use of the discovery template 204 is optionally combined with a service model template in the process of generating the service model instance 200. An overview of the template-driven procedure is illustrated in FIG. 3. The service model template is a generic specification of the service topology and measurement topology for the service of interest (e.g., Read Mail service). Depending on the service being modeled and the service elements that are likely to be involved, the template defines nodes of various types (e.g., hosts, servers, network links, and services) and their associated measurements. Moreover, the template indicates the dependencies among the nodes, such as the dependency of the service on other services (e.g., the Read Mail service which refers to a subscriber accessing his/her mailbox depends on the authentication and NFS services). In the preferred embodiment, the template also includes default state computation rules for specified nodes, so that the state (i.e., "health") of a node can be computed based upon measurements associated with the node and upon states of dependencies of the node.

The service model template 34 is not specific to any ISP system in the sense that it does not specifically reference any hosts, servers, network links, service groups, or other services or service elements in the ISP system. The template may be considered as a "lifeless tree." There is no association between nodes in the service model template and running elements, such as hosts and servers. However, the information contained in the service template for a node may include the element type, the element dependencies, the measurement definitions (e.g., agent to run, the format of the run string, the number and type of parameters, and the format of the output), default state computation rules, default thresholds, default baselines, and default alarm generation and correlation rules.

In database terminology, the service model template 34 is the schema. On the other hand, an instance defines the records in the database and the values of the static information. In FIG. 3, the discovered instance 36 is determined using auto-discovery, as will be explained fully below. Information regarding the services and service elements (e.g., servers, hosts and links) that exist in the ISP system or other service provider systems may be auto-discovered. The store representing auto-discovered information shall be referred to as the auto-discovered instance 36.

The service model creation engine 38 of FIG. 3 is used to generate a service model instance 40 based on the service model template 34 and auto-discovered instance 36. Ideally, all of the discovered information is available prior to instantiation. However, in many cases, discovery has to be performed in multiple phases, such as the two outlined above. In such cases, instantiation may occur partially after each phase of discovery. The main advantage of providing a partial service model instance is that the partially completed service model can provide a guide to identify the additional information needed in subsequent phases of discovery. The service model creation engine 38 encompasses the functions of the partial service model instance generator 212 and the second service model instance generator 222 of FIG. 2. Since new elements and services may be added to the ISP system over time, the service model instantiation process has to be repeated periodically to augment the initially created service model instance.

Unlike the service model template 34, the service model instance 40 is specific to an ISP system. The process of constructing the service model instance using the service model template and the auto-discovered instance 36 is referred to as the "instantiation" of the service model. As previously noted, the relationship between the service model template and the auto-discovered instance is analogous to the relationship between the schema and records in a database.

The service model instance 40 maps services and service elements that exist in a particular ISP system with nodes in the service model template. In doing so, the service model instance also specifies a set of measurements that must be made against each of the services and service elements in the specific ISP system.

The service model instance 40 may be used by a view generator 42. In the preferred embodiment, the service model instance is represented as a graph of the nodes and edges that identify dependencies of the nodes. Different management functions of an ISP will benefit from viewing different subsets of nodes and edges of the service model instance 40. Thus, the view generator 42 may be used by operations personnel to provide an "operations view" of only the services and service elements that fall in a particular domain of control of the personnel. On the other hand, a "customer support view" may provide an end-to-end view for the customer support personnel of the ISP. A "planning view" may be used to graphically present information about usage and performance trends, so that future requirements can be ascertained.

Even when different management functions are interested in the same subset of nodes and edges of the service model instance 40, there may be different interests with regard to rules to be used for state computations. For instances, a management application that visually depicts a color-coded hierarchical representation of the service model instance to operations personnel may require that hierarchical state propagation rules be employed in the service model instance. In this manner, viewing the state of the top-level nodes of the service model, an ISP operator can determine whether any problem has been detected in the ISP system. In contrast, an application that is responsible for automatically detecting, diagnosing and reporting the root-causes of problems in the ISP system may prefer not to use a hierarchical state propagation rule, since it is interested in the state of each node of the service model independently of the state of other nodes.

The view generator 42 may be used to define the subset of nodes of a service model instance that are of interest to a management application, as well as the method for evaluating the states of the nodes of interest. The measurements that are associated with the nodes in the service model instance are common across the different views. However, the rules that apply to computing the state of a particular node based upon relevant measurements and the states of dependent nodes may be different for the different views.

A measurement agent configurator 44 may be used to extract information from the service model instance 40, when the information is relevant to scheduling tests and retrieving test results. At the completion of the service model instance 40, static configuration information as to how the tests of various elements are to be run may be merged with default algorithm descriptions into a service model instance file. State computation rules, thresholds and alarm correlation rules defaults may be overridden using the measurement agent configurator. Specific measurements may be enabled or disabled. A final measurement agent specification 46 is generated by the configurator for the specific ISP. The measurements that are identified in the specification 46 are executed using software agents 45. The results of the measurements are analyzed and used by a service model manager 47 to compute the states of different nodes in the service model.

Overview of Instantation

FIG. 4 represents an overview of the process for generating the discovered instance that is used to form the service model instance 40 of FIG. 3. As previously noted, a requirement of the instantiation of a service model is the generation of the service model template for the particular service or services of interest. The template may be handcrafted, preferably by a domain expert of the service. The template includes a specification of the elements involved in providing the service, such as servers and network links, and the dependencies of the service on other services, such as the dependency of Read Mail service on the authentication and NFS services. As will be explained more fully below, the discovery process includes designation of a discovery template 48. The discovery template specifies the types of services and the service elements to be discovered. The discovery template also includes specifications of discovery modules 50, 52 and 54 to be invoked in the discovery of the specified services and service elements.

The service model template 34, the discovery template 48, and the discovery modules 50, 52 and 54 are utilized within a management system 56 for forming the service model instance 40. Another key component of the management system is a discovery engine 58 that processes information contained within the discovery template 48. The discovery engine invokes the appropriate discovery modules 50-54, interprets the outputs of the invoked modules, and stores the outputs in memory (or in a database) as the discovered instance 36, which is made accessible to the service model creation engine 38. The discovery engine 58 supports a configuration interface 60 that allows ISP operations personnel to control and customize the discovery process. Through the configuration interface 60, an ISP operator can restrict the discovery to specified IP address ranges or host name patterns. Furthermore, the operator can specify naming conventions used by the ISP (e.g., for naming terminal servers and POP sites), which are used by some of the discovery modules 50-54.

The configuration interface 60 serves as a way for an ISP operator to quickly customize the service model instance 40 that is generated by the process. Using the configuration interface, the operator can also specify categorization criteria for services and service elements. For instance, all the mail services could fall in one category, while the DNS servers could fall in another. The categories assigned to services and service elements can represent the organizational structure of the ISP, the geographical location of the servers offering the services (e.g., servers in San Francisco fall in one category, while servers in New York fall in another), or differences in business functions of the service (e.g., web servers that an ISP is hosting on behalf of business customers, as opposed to local web servers that the ISP offers for providing access to the dial-up subscribers).

In the preferred embodiment, the configuration interface 60 is implemented using a graphical user interface (GUI) at an operator computing station. An example of a configuration specification that is entered using the interface 60 is shown in Table 1.

    TABLE 1
    Hosts       exclude  ip   10.1.204.1-10.1.205.1
    # exclude all hosts with IP addresses in this range. These hosts represent
     subscriber
    #   home PCs
    WebServers  category name *.com.fakeisp.net WebHost
    # servers with names of the form *.com.fakeisp.net are Web hosting servers
    TerminalServers  extract  name  max[0-9]{3}<PopSite>[0-9]t.fakeisp.net
    #Terminal servers must match the naming pattern above. Extract the POP site
     name
    #     from the terminal server's name

    TABLE 2
    [ExternalNameServers]
    discovery-module=DiscoverExternalNameServers.class
    discovery-arguments=-url http://ism-pc2/scripts/discEngineAPI.pI
    discovery-outputs=ipAddress, hostName, domainName, category
    discovery-instanceKey=<ipAddress>:DNS
    discovery-dependencies=
    [Hosts]
    discovery-module=DiscoverHosts.class
    discovery-arguments=-url http://ism-pc2/scripts/discEngineAPI.pI
    discovery-outputs=ipAddress, hostName, state, category
    discovery-instanceKey=<ipAddress>:Host
    discovery-dependencies=ExternalNameServers
    [SMTPServers]
    discovery-module=DiscoverSmtpServers.class
    discovery-arguments=-url http://ism-pc2/scripts/discEngineApI.pI
    discovery-outputs=ipAddress, hostName, category
    discovery-instanceKey=<ipAddress>:Smtp_Mail
    discovery-dependencies=Hosts, ExternalNameServers
    [POP3Servers]
    discovery-module=DiscoverPop3Servers.class
    discovery-arguments=-url http://ism-pc2/scripts/discEngineAPI.pI
    discovery-outputs=ipAddress, hostName, relatedSmtpServer, category
    discovery-instanceKey=<ipAddress>:Pop3_Mail
    discovery-dependencies=Hosts, ExternalNameServers
    [HTTPServers]
    discovery-module=DiscoverHttpServers.class
    discovery-arguments=-url http://ism-pc2/scripts/discEngineApI.pI
    discovery-outputs=ipAddress, hostName, serverType, category
    discovery-instanceKey=<ipAddress>:Web
    discovery-dependencies=Hosts
    [NFSServers]
    discovery-module=DiscoverNFSServers.class
    discovery-arguments=-url http://ism-pc2/scripts/discEngineApI.pI
    discovery-outputs=ipAddress, hostName, category
    discovery-instanceKey=<ipAddress>:NFS
    discovery-depenendencies=Hosts
    [Host-Groups]
    discovery-module=DiscoverHostGroups.class
    discovery-arguments=-url http://ism-pc2/scripts/discEngineApI.pI
    discovery-outputs=groupName, groupComponentsList, category
    discovery-instanceKey=<groupName>:HostGroup
    discovery-dependencies=ExternalNameServers
    [WebServiceGroups]
    hostName=mailfes21.fakeisp.net
    relatedSmtpServer=smtp.fakeisp.net
    category=
    [10.137.196.54:Pop3_Mail]
    ipAddress=10.137.196.54
    hostName=mailfes22.fakeisp.net
    relatedSmtpServer=smtp.fakeisp.net
    category=
    [10.137.196.56:Pop3_Mail]
    ipAddress=10.137.196.56
    hostName=mailfes23.fakeisp.net
    relatedSmtpServer=smtp.fakeisp.net
    category=
    [10.137.196.58:Web]
    ipAddress=10.137.196.58
    hostName=www.fakeisp.net
    serverType=NCSA/1.5
    category=InternalWeb
    [10.137.196.69:Web]
    ipAddress=10.137.196.69
    hostName=www.xyz.com.fakeisp.net
    serverType=Apache/1.2
    category=WebHost
    [10.137.196.70:Web]
    ipAddress=10.137.196.70
    hostName=www.abc.com.fakeisp.net
    serverType=Apache/1.2
    category=WebHost
    [10.174.173.23:NFS]
    ipAddress=10.174.173.23
    hostName=dns1.fakeisp.net
    [pop3.fakeisp.net:HostGroup]
    groupName=pop3.fakeisp.net
    groupComponentsList=10.137.196.52:10.137.196.54:10.137.196.56
    [pop3.fakeisp.net:Pop3_MailServiceGroup]
    serviceGrpName=pop3.fakeisp.net
    serviceGrpComponentsList=10.137.196.52:10.137.196.54:10.137.196.56
    [ExternalDnsServer:Category]
    categoryName=ExternalDnsServer
    [InternalWebServer:Category]
    categoryName=InternalWeb
    [WebHostedServer:Category]
    categoryName=WebHost

    TABLE 3
    [10.174.173.23:DNS]
    ipAddress=10.174.173.23
    hostName=dns1.fakeisp.net
    domainName=fakeisp.net
    category=ExternalDnsServer
    [10.174.173.23:Host]
    ipAddress=10.174.173.23
    hostName=dns1.fakeisp.net
    state=Alive
    category=
    [10.137.196.52:Host]
    ipAddress=10.137.196.52
    hostName=mailfes21.fakeisp.net:smtp.fakeisp.net
    state=Alive
    category=
    [10.137.196.54:Host]
    ipAddress=10.137.196.54
    hostName=mailfes22.fakeisp.net
    state=Alive
    category=
    [10.137.196.56:Host]
    ipAddress=10.137.196.56
    hostName=mailfes23,fakeisp.net
    state=Alive
    category=
    [10.137.196.58:Host]
    ipAddress=10.137.196.58
    hostName=www.fakeisp.net
    state=Alive
    category=
    [10.137.196.69:Host]
    ipAddress=10.137.196.69
    hostName=www.xyz.com.fakeisp.net
    state=Alive
    category=
    [10.137.196.70:Host]
    ipAddress=10.137.196.70
    hostName=www.abc.com.fakeisp.net
    state=Alive
    category=
    [10.137.196.52:Smtp_Mail]
    ipAddress=10.137.196.52
    hostName=mailfes21.fakeisp.net:smtp.fakeisp.net
    category=ExternalSmtpServer
    [10.137.196.52:Pop3_Mail]
    ipAddress=10.137.196.52
    hostName=mailfes21.fakeisp.net
    relatedSmtpServer=smtp.fakeisp.net
    category=
    [10.137.196.54:Pop3_Mail]
    ipAddress=10.137.196.54
    hostName=mailfes22.fakeisp.net
    relatedSmtpServer=smtp.fakeisp.net
    category=
    [10.137.196.56:Pop3_Mail]
    ipAddress=10.137.196.56
    hostName=mailfes23.fakeisp.net
    relatedSmtpServer=smtp.fakeisp.net
    category=

    TABLE 4
    [SM-Host]
    ; Host Node in the service model
    match=[*:Host]
    ; for each discovered Host
    instanceKey=<ipAddress>:SM-Host
    measurements=TCP-ConnectionRate(<ipAddress>),
          VMstat(<ipAddress>), IFstat(<ipAddress>)
    ; these are measurements of the host
    ; next copy its attributes to the SM node
    hostname=<hostName>
    ipAddress=<ipAddress>
    state=<state>
    category=<category>
    [SM-Web]
    ; SM node for a web server
    match=[*:Web]
    ; match all discovered Web server instances
    instanceKey=<ipAddress>:SM-Web
    components=<ipAddress>:SM-Host, <ipAddress>-msIP:SM-Link
    measurements=HTTP-TCPConnectionTime(<ipAddress>)
    ; next copy all the attributes from the server discovered instance
    stateComputationRule=measurementsOnly
    serverType=<serverType>
    hostName=<hostName>
    ipAddress=<ipAddress>
    category=append(<category>,<ipAddress>:SM-Host?<category>)
    [SM-WebService]
    ; a web service node
    match=[*:SM-Web]
    ; there is a web service node corresponding to each web server node
    instanceKey=<ipAddress>:SM-WebService
    measurements=HTTP-Availability (<ipAddress>), HTTP-Total
     ResponseTime(<ipAddress>),
          HTTP-DnsTime (<ipAddress>)
    components=<ipAddress>:SM-Web, <<ipAddress>,Web>:SM-NFS, <<ipAddress>,
          Web>:SM-DNS
    ; NFS and DNS service dependencies will be determined by phase 2 discovery
    category=<category>
    [SM-WebServiceGroup]
    match=[*:WebServiceGroup]
    instanceKey=<serviceGrpName>:SM-WebServiceGroup
    components=list(<serviceGrpComponentsList>) :SM-WebService
    category=<category>
    category=append(list(<serviceGrpComponentsList>) :SM-WebService?<category>)
    [SM-TopLevel-Web]
    instancekey=Web:SM-TopLevelWeb
    components=*:SM-WebService, *:SM-WebServiceGroup
    ; components are all web services and all web service groups
    [SM-DNS]
    match=[*:DNS]
    instanceKey=<ipAddress>:SM-DNS
    components=<ipAddress>-msIP:SM-Link
    measurements=DNS-Availability(<ipAddress>),
          DNS-CacheHitResponseTime(<ipAddress>)
    stateComputationRule=measurementsOnly
    ipAddress=<ipAddress>
    hostName=<hostName>
    domainName=<domainName>
    category=<category>
    [SM-NFS]
    match=[*:NFS]
    instanceKey=<ipAddress>:SM-NFS
    components=<ipAddress>:SM-Host
    measurements=NFS-TotalCalls(<ipAddress>), NFS-DupReqs(<ipAddress>),
          NFS-TimeOutPercent(<ipAddress>)
    stateComputationRule=measurementsOnly
    ipAddress=<ipAddress>
    hostName=<hostName>
    [SM-Pop3_Mail]
    match=[*:Pop3_Mail]
    instanceKey=<ipAddress>:SM-POP3_Mail
    components=<ipAddress>:SM-Host
    measurements=POP3-TCPConnectionTime(<ipAddress>)
    hostName=<hostName>
    category=<category>
    relatedSmtpServer=<relatedSmtpServer>
    ipAddress=<ipAddress>
    [SM-ReadMailService]
    match=[*:SM-Pop3_Mail]
    instanceKey=<ipAddress>:SM-ReadMailService
    measurements=POP3-Availability (<ipAddress>),
          POP3-TotalResponseTime(<ipAddress>),
          POP3-AuthenticationTime (<ipAddress>)
    stateComputationRule=default
    components=<ipAddress>:SM-Pop3_Mail, <<ipAddress>,Pop3_Mail:SM-NFS>,
          <<ipAddress>,Pop3_Mail:SM-Auth>
    category=<category>
    [SM-ReadMailServiceGroup]
    match=[*:Pop3MailServiceGroup]
    instanceKey=<serviceGrpName>:SM-ReadMailServiceGroup
    components=list(<serviceGrpComponentsList>) :SM-ReadMailService
    category=<category>
    [SM-TopLevel-ReadMail]
    instanceKey=ReadMail:SM-TopLevel-ReadMail
    components=*:SM-ReadMailService, *:SM-ReadMailServiceGroup
    [SM-Category]
    match=[*:Category]
    instanceKey=<categoryName>:SM-Category
    components=*:SM-*?category=<categoryName>

    TABLE 5
    [10.174.173.23-fakeisp.net:DNS]
    ipAddress=10.174.173.23
    hostName=dns1.fakeisp.net
    domainName=fakeisp.net
    category=ExternalDnsServer
    [10.174.173.23:SM-Host]
    measurements=TCP-Connection-Rate (10.174.173.23), VMstat (10.174.173.23),
          IFstat (10.174.173.23)
    ipAddress=10.174.173.23
    hostName=dns1.fakeisp.net
    state=Alive
    category=
    [10.137.196.52:SM-Host]
    measurements=TCP-Connection-Rate (10.137.196.52), VMstat (10.137.196.52),
          IFstat (10.137.196.52)
    ipAddress=10.137.196.52
    hostName-mailfes21.fakeisp.net
    state-Alive
    category=
    [10.137.196.54:SM-Host]
    measurements=TCP-Connection-Rate(10.137.196.54), VMstat(10.137.196.54),
          IFstat(10.137.196.54)
    ipAddress=10.137.196.54
    hostName=mailfes22.fakeisp.net
    state=Alive
    category=
    [10.137.196.56:SM-Host]
    measurements=TCP-Connection-Rate(10.137.196.56), VMstat(10.137.196.56),
    IFstat(10.137.196.56)
    ipAddress=10.137.196.56
    hostName=mailfes23.fakeisp.net
    state=Alive
    category=
    [10.137.196.58:SM-Host]
    measurements=TCP-Connection-Rate(10.137.196.58), VMstat(10.137.196.58),
          IFstat(10.137.196.58)
    ipAddress=10.137.196.58
    hostName=www.fakeisp.net
    state=Alive
    category=
    [10.137.196.69:SM-Host]
    measurements=TCP-Connection-Rate(10.137.196.69), VMstat(10.137.196.69),
          IFstat(10.137.196.69)
    ipAddress=10.137.196.69
    hostName=www.xyz.com.fakeisp.net
    state=Alive
    category=
    [10.137.196.70:SM-Host]
    measurements=TCP-Connection-Rate(10.137.196.70), VMstat(10.137.196.70),
          IFstat(10.137.196.70)
    ipAddress=10.137.196.70
    hostName=www.abc.com.fakeisp.net
    state=Alive
    category=

• Inventors
  Ramanathan, Srinivas; Caswell, Deborah L.;
• Assignee
  Hewlett-Packard Company (Palo Alto, CA)
• Published
  Sep-4-2001
• Current US Classes:
  345/733
  370/229
  370/254
  706/51
  709/202
  709/217
  709/224
  709/226