Monitoring several distributed resource elements as a resource pool

[0001] The present application is related to and claims priority from the co-pending India Patent Application entitled, “Monitoring Several Distributed Resource Elements as a Resource Pool”, Serial Number: 599/CHE/2005, Filed: 19 May 2005, naming the same inventors as in the subject patent application, and is incorporated in its entirety herewith.

[0002] The present application is also related to co-pending U.S. application Ser. No. 10/452,134; Filed: Jun. 3, 2003, entitled, “Network Management System to Monitor Managed Elements”, which is incorporated in its entirety herewith.

[0003] 1. Field of the Invention

[0004] The present invention relates to network management systems, and more specifically to a method and apparatus for facilitating a user/administrator to monitor several distributed resource elements as a resource pool.

[0005] 2. Related Art

[0006] A resource element generally refers to an entity which is used in computation or communication. Examples of resource elements include memories, processors, processes, etc. Management systems are often provided to monitor the usage and status of such resource elements.

[0007] Multiple resource elements are often used as resource pools in networked systems. For example, a front end machine may distribute web page requests to multiple web servers, and the web servers could together be viewed as a resource pool since each web page request can be served potentially by any of the web servers.

[0008] Similarly, virtual computing environments (such as in utility computing and grid computing) are evolving which view several distributed resource elements (provided in physically different units) as a resource pool in performing a desired computation or providing a desired service.

[0009] There is a general need to simplify management of such resource pools in network management systems.

[0023] In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.

1. Overview

[0024] A network management system according to an aspect of the present invention enables an administrator (or user) to specify several distributed resource elements as a resource pool and various attributes of interest for the resource pool. The network management system monitors the individual resource elements periodically to determine the values corresponding to the specified attributes and displays the aggregated information for each attribute of interest. The user may specify the specific aggregate information (e.g., mean, median) to display as well.

[0025] The management of several applications that operate by using resource pools may be simplified as a result.

[0026] Several aspects of the invention are described below with reference to examples for illustration. It should be understood that numerous specific details, relationships, and methods are set forth to provide a full understanding of the invention. One skilled in the relevant art, however, will readily recognize that the invention can be practiced without one or more of the specific details, or with other methods, etc. In other instances, well known structures or operations are not shown in detail to avoid obscuring the invention.

2. Example Environment

[0027] FIG. 1 is a block diagram illustrating an example environment in which various aspects of the present invention can be implemented. The environment is shown containing monitoring system 110, database 130, inter-network 150A, intra-network 150B, and servers 190-A through 190-X. It should be appreciated that only a few representative systems and components are shown in FIG. 1 for illustration. However, typical environments contain several more (types) systems. Each system of FIG. 1 is described below in further detail.

[0028] Servers 190A-190X represent example resource elements which are physically distributed, and sought to be monitored as a resource pool according to various aspects of the present invention. All the servers are shown connected to intra-network 150B. Front-end 180 receives various requests (e.g., HTTP requests) from inter-network 150A, and distributes the requests to one of servers 190A-190X, for example, according to a known approach. Accordingly, servers 190A-190X together may be viewed as a resource pool.

[0029] Monitoring system 110 enables a user to monitor the group of servers 190A-190X as a single managed element (i.e., a resource pool) according to various aspects of the present invention. Monitoring system 110 may monitor individual resource elements and store the monitored values in database 130. The manner in which monitoring system 110 may provide such features are described below in further detail.

3. Monitoring Resource Pool

[0030] FIG. 2 is a flowchart illustrating the manner in which a monitoring system may enable multiple resources to be monitored as a single resource pool according to various aspects of the present invention. The flowchart is described below with respect to FIG. 1 for illustration. However, the features can be implemented in other environments also, as will be apparent to one skilled in the relevant arts by reading the disclosure provided herein. The flowchart begins in step 201, in which control passes to step 210.

[0031] In step 210, monitoring system 110 enables a user to specify a resource pool containing several resource elements, and the attributes of interest related to the resource pool. Various approaches may be used in seeking the related inputs from the user. An example implementation is described below.

[0032] In step 230, monitoring system 110 monitors the individual resource elements to determine the values corresponding to the attributes of interest at different time intervals. The intervals can be different for different attributes and at least some of the intervals can be specified by the user.

[0033] In step 250, monitoring system 110 displays the aggregated information for each attribute of interest. The information may also be displayed using one of various approaches, and an example approach is illustrated in sections below. Examples of the aggregated information include statistical parameters such as mean, median, and variance. The user may be provided the option of specifying the specific aggregated information of interest as well. The method ends in step 299.

[0034] Thus, by using approaches according to FIG. 2, several resource elements can be monitored together as a resource pool. Monitoring system 110 can be implemented using different approaches to provide the features of FIG. 2. An example implementation of monitoring system 110 is described below with reference to FIGS. 3 And 4.

4. Monitoring System

[0035] FIG. 3 is a block diagram illustrating the details of monitoring system 110 in one embodiment. Monitoring system 110 is shown containing network management station (NMS) 310, client 320, agent module 340, administrator tool 360, and monitor instance 370. Each block is described below in further detail.

[0036] Monitor instance 370 represents an entity (e.g., a process executing on a system) which actively samples the status values of various attributes of interest earlier specified by the user. The sampled values may be sent via network 150A to database 130. Monitor instance 370 may be instantiated/created by using agent module 340, as described below.

[0037] NMS 310 enables a user to define various monitor types. As relevant to the features of the present invention, a user may specify the type of resource (e.g., CPUs, processes, servers, etc.) and the type of aggregate information that would be of interest when the elements of the resource type are viewed as a resource pool. NMS 310 may receive sampled values from monitor instance 370 and store the same in database 130. In addition, NMS 310 enables a user to view aggregate information related to various resource pools configured earlier.

[0038] Agent module 340 facilitates the instantiation of monitor instances using the monitor types defined using NMS 310. In addition, agent module 340 may facilitate tasks such as changing of control parameters (e.g., polling frequency), forwarding the data points polled for various attributes, etc. To provide the above features, each agent module is provided the ability (compatible network protocol, medium interface, etc.) to communicate with NMS 310.

[0039] Administrator tool 360 is used by an administrator/user to configure and instantiate various monitor instances. Administrator tool 360 may be integrated into NMS 310 as one unit. However, for ease of administration, administration tool may be provided from various client systems (320). The manner in which a user may define monitor types and instantiate new monitor instances according to various aspects of the present invention, is described below in further detail.

[0040] Client 320 provides a suitable user interface using which users may view the aggregate information related to resource pools monitored according to various aspects of the present invention. NMS 310 may provide the corresponding information using a suitable user interface. The description is continued with respect to an architecture view of an example embodiment of NMS 310.

5. Network Management Station (NMS)

[0041] FIG. 4 is a block diagram illustrating the details of NMS 310 in one embodiment. NMS 310 is shown containing web server 410, aggregate information generator 420, administrator module 430, database interface 450, agent controller 470, data points module 480, and agent interface 490. Each component described below in further detail.

[0042] Web server 410 provides interface to client 320 and administrator tool 360 to interact with other modules in NMS 310. In an embodiment, a request for a web page is received in the form of a URL and associated parameters, and web server 410 communicates with an application server (not shown) to provide the appropriate interface for client 320 and administrator tool 360. The application server may be implemented to contain aggregate information generator 420 and administrator module 430. Web server 410 and the application server may be implemented using products available in the market-place as will be apparent to one skilled in the relevant arts.

[0043] Administrator module 430 provides appropriate interface for administrator tool 360 to enable an administrator to define, configure and instantiate monitor instances according to various aspects of the present invention. Administrator module 430 generates the appropriate database schemas, and configures database 130 corresponding to any monitor types/instances defined according to various aspects of the present invention. In general, administrator module 430 may be used to specify the manner in which data points related to an attribute need to be displayed, and aggregate information generator 420 displays the data points accordingly.

[0044] Aggregate information generator 420 retrieves from database 130 (by interfacing through database interface 450) various data points (sampled values) corresponding to attributes sought to be monitored, and displays the corresponding aggregate information. The aggregate information is first computed using the sampled values, data representing the requested graphs and reports (of the aggregate information) may be generated, and provided to web server 410 for display in the form of web pages. The operation of aggregate information generator 420 and administrator module 430 is described with reference to example(s) below.

[0045] Data points module 480 receives various sampled values related to attributes (of individual monitored elements) being monitored by the corresponding monitor instances, and determines the manner in which the data points need to be processed. At least some of the data points may be stored in database 130 by communicating with database interface 450. The number of data points stored may be reduced and/or alarms logged, for example, as described in U.S. Pat. No. 6,453,346 issued to Garg et al, which is incorporated in its entirety into the present application.

[0046] Agent controller 470 operates under the control of administrator tool 360 (via administrator module 430) to instantiate various monitor instances, and to provide the appropriate configuration parameters. In general, each monitor instance may be provided information indicating the specific attributes to be monitored, polling frequency, timeout value for each poll, etc., in addition to the program logic enabling the monitor instance to poll the device for the data point. Agent interface 490 enables communication with each of the monitor instances according to the specific medium/protocol using which the monitor instance can be contacted.

[0047] The description is continued with reference to the manner in which several aspects of the present invention may be implemented in the embodiment(s) described above. In particular, the description is continued with respect to the manner in which a user may specify information of interest related to multiple resource elements according to an aspect of the present invention.

6. Specifying Information of Interest Related to Resource Elements

[0048] FIG. 5 is a flowchart illustrating the manner in which a user may specify multiple resource elements as forming a resource pool and also the specific attributes of interest with respect to the resource pool. The flowchart is described with respect to the Figures described above merely for illustration. However, the features can be implemented in other environments as well. The flowchart begins in step 501 in which control transfers to step 510.

[0049] In step 510, administrator module 430 receives data indicating attributes for a resource element type of interest. In an embodiment, the user is provided a list of the resource element types supported by the monitoring system, and the user may select the specific resource element type of interest. Monitoring system 110 then displays the attributes that can be monitored for the indicated resource element type (in the context of a resource pool).

[0050] In step 520, administrator module 430 enables a user to select attributes of interest (for the resource element type of interest) and the aggregate information types for each selected attribute. A convenient graphical user interface (GUI) may be provided for such a selection.

[0051] In step 540, agent module 340 enables a user to specify a group of resource elements of interest to be monitored. NMS 310 (or administrator module 430 therein) may also be notified of the user specification, which then causes instantiation of the corresponding monitor instance, as well as display of the requested aggregate information. The flowchart ends in step 599.

[0052] Accordingly, the approaches described above enable effective monitoring of resource pools. The description is continued with respect to the manner in which the steps/approaches noted above are implemented in an example embodiment.

[0053] In that embodiment, the attributes that can be monitored are specified in an element monitor type for each resource element type. A pool monitor type is then conveniently created for the resource pool type, such that different groups of resource elements can be defined as different resource types (as would be desired by administrators or users). According the manner in which a pool monitor type can be defined from a element monitor type, is described below first.

7. Defining a Pool Monitor Type

[0054] FIGS. 6A-6C together represent the content of a text file depicting the attributes associated with an element monitor type for a Solaris CPU (available from Sun Microsystems, Sun Microsystems Inc, 4150 Network Circle, Santa Clara, Calif. 95054 Phone: (800) 801-7869). The contents there are used to illustrate the manner in which a pool monitor type can be defined for several such CPUs together.

[0055] It should be understood that the element monitor type could contain several more lines, but only lines relevant to implementation of various aspects of the present invention are described for conciseness. In addition, some of the labels are self-explanatory and are also not described for conciseness.

[0056] Line 601 includes a unique identifier (which would be useful in various programming contexts, as would be apparent to one skilled in the relevant arts) for the element monitor type of FIGS. 6A-6C. Line 602 indicates that the type of the element monitor as ‘SOLCpuMon’ (i.e., related to Solaris CPU monitor), while line 603 indicates the display name for the monitor type as ‘Solaris CPU Monitor’.

[0057] Lines 604-609 indicate some of the attributes that need to be configured for a Solaris CPU resource element before monitoring some of the attributes of lines 610-621. Lines 610 to 621 indicate some of the attributes which can be monitored for a Solaris CPU. Line 610 provides a unique attribute identifier (29301004) for the attribute (which may be constructed from MOtypeid and the UsrAttrId), a display name (displayed in user interface) of ‘User Time’, unit of measurement (UOM) as percentage usage, etc.

[0058] With reference to line 610, variable entitled ‘AttrID’ (29301004) is unique across all attributes of all monitor types within NMS 310, and is obtained by concatenating the value of a second variable ‘UsrAttrID’ (4 this case) with MOTypeid value (29301) from line 601. The values may be assigned using some simple scheme (e.g., lowest unassigned value in a certain range of numbers). NMS 310 uses AttrID as a unique identifier for the attribute within the system.

[0059] Variable entitled ‘DisplayName’ contains display string for the attribute (‘User Time’ in this case). Variable entitled ‘UniqueName’ contains a unique name value for the attribute (‘USR_CPU’ in this case). The display name is not necessarily unique, so either the AttrID value or the unique name value may be used to distinguish one attribute from another. Unique name value is intended to be in human readable form, whereas AttrID is not easily comprehensible since it is intended for computation purposes (e.g., as a key in Database 130). Variable entitled ‘AttrType’ specifies type of this attribute (statistical type in this case). This is set to stats since it is an output attribute used to record the counter value obtained in a monitor poll.

[0060] Variable entitled ‘UOM’ specifies the units of measurement for this attribute (‘%’ in this case). Variable entitled ‘IsDefaultStats’ specifies if this is a default counter for which data is collected (yes in this case). Variable entitled ‘TableName’ gives the database table name for this attribute (‘SOLCPU’ in this case). The database table name is derived from the unique name for this monitor type (line 602). Variable entitled ‘ColumnName’ gives the column name for this attribute (‘USRTIME’ in this case). The remaining lines 611-621 may also be described similarly for other attributes monitored by the Solaris CPU Monitor.

[0061] FIGS. 7A-7C illustrate the manner in which attributes of interest can be selected while defining a pool monitor. The list of attributes defined for the Solaris CPU monitor (lines 610-621) are used for illustration. Each of the FIGS. 7A-7C is described briefly below.

[0062] FIG. 7A illustrates the manner in which an administrator initiates definition of a pool monitor type. In general, new monitor types are added using administrator tool 360 (via administrator module 430). As can be observed at 701, group 701 is shown for all pool monitor types defined. By appropriate user action (e.g., right click, double click), the screen of FIG. 7B is displayed to enable/facilitate definition of a new pool monitor type.

[0063] FIG. 7B is shown containing a form which is used to create a pool monitor for resource elements of type Solaris CPU. List box 730 (which generally lists all available choices, and enables selection of one of the choices) indicates that the user has chosen to create a new pool monitor for the resource elements of type Solaris CPU.

[0064] Entry 731 indicates that the display name specified (by user) for the new pool monitor type is ‘Patent Test’, while the value entered (by administrator or user) in entry 732 indicates that the name of the new monitor type is ‘SOLCPU1’.

[0065] List box 733 displays the attributes corresponding to the monitor type selected in list box 730. Thus, list box 733 contains attributes of the Solaris CPU monitor (as defined in lines 610-621). The user selects an attribute of interest using list box 733, an aggregation information of interest (at list box 737), and presses add button 738 to cause the corresponding information to be added to the table below (shown containing rows 734 and 735, described below).

[0066] Rows 734 and 735 indicate that attributes System Time and System Calls are to be monitored in each resource element, and the corresponding aggregation information of interest for the attributes is ‘SUM’ and ‘AVERAGE’ respectively.

[0067] Selecting ‘Create Monitor’ (736) creates the pool monitor type entitled SOLCPU1, consistent with the definitions above of FIG. 7B. The administrator may verify whether the monitor type ‘Patent Test’ has been created by verifying the list of monitors in list 748 of FIG. 7C.

[0068] In an embodiment, a pool monitor type is also represented similar to the convention of FIG. 6A-6C (corresponding to element monitor type). The corresponding text created is described below with reference to FIGS. 8A-8C.

8. Content Representing a Pool Monitor Type

[0069] FIGS. 8A-8C together depict the contents of a (portion of) text file indicating the attributes of interest associated with a pool monitor type. The pool monitor type corresponds to the one created with respect to the description of FIGS. 6A-6C and 7A-7C. The contents of FIGS. 8A-8C are described below in further detail.

[0070] Line 801 indicates that the unique identifier for the pool monitor type defined from the element monitor type for ‘Solaris CPU’ as 501016. Lines 802 and 803 respectively indicate that the name of the pool monitor is ‘SOLCPU1’ and display name is ‘Patent Test’ (consistent with the values entered in entries 732 and 731 respectively).

[0071] Lines 810-816 contain definitions of some pre-defined input attributes that are used in creating an actual instance of this pool monitor type (‘PatentTest’, as seen in line 748 of FIG. 7C). Line 810 corresponds to attribute ‘Instance_Name’ that is displayed as field 1011 in FIG. 10A. Variable entitled ‘AttrID’ (501017999 in this case) has a unique value across all attributes of all monitor types within NMS 310, and is obtained by concatenating the value of a second variable ‘UsrAttrID’ (999 in this case) with MOTypeid value (501017) from line 801. The values may be assigned using some simple scheme (e.g., lowest unassigned value in a certain range of numbers). NMS 310 may use AttrID as a unique identifier for the attribute within the system.

[0072] Variable entitled ‘DisplayName’ contains display string for the attribute (‘Instance Name’ in this case). Variable entitled ‘UniqueName’ contains a unique name value for the attribute (‘INSTANCE_NAME’ in this case). The display name is not necessarily unique, so either the AttrID value or the unique name value may be used to distinguish one attribute from another. Unique name value is intended to be in human readable form, whereas AttrID is not easily comprehensible since it is intended for computation purposes (e.g., as a key in Database 130).

[0073] Variable entitled ‘DataType’ specifies data type of this attribute (character string in this case). Variable entitled ‘AttrType’ specifies type of this attribute (input in this case). Variable entitled ‘Label’ specifies if this attribute will be displayed as a label (yes in this case). Variable entitled ‘Default’ specifies the default value to be displayed in input field 1011 of FIG. 10A (no default value in this case). Variable entitled ‘DisplaySeqNo’ specifies the order in which this attribute is displayed (first in this case, which is the position of field 1011 in FIG. 10A). Variable entitled ‘RequiredOnCreate’ specifies if this is a required or optional input to create the monitor instance (no in this case). Note that if user/administrator does not provide an instance name, NMS 310 may internally assign an instance name based on other available attributes, such as Monitor Display Name (line 731) or Monitor Name (line 732).

[0074] Lines 834 and 835 contain definition of (the two) attributes of interest which are

[0075] monitored in each resource element contained in a resource pool. It may be appreciated

[0076] that the attributes of interest are ‘SUM_System Time’ and ‘AVERAGE_System Calls’

[0077] in accordance with the attributes selected while creating the pool monitor type (indicated

[0078] by lines 734 and 735) respectively.

[0079] Line 834 is used as an example to describe the significant variables for a typical attribute which is selected by the user/administrator for each resource element contained in a resource pool. Variable entitled ‘AttrID’ (501017020 in this case) is unique across all attributes of all monitor types within NMS 310, and is obtained by concatenating the value of a second variable ‘UsrAttrID’ (020 in this case) with MOTypeid value (501017) from line 801. The values may be assigned using some simple scheme (e.g., lowest unassigned value in a certain range of numbers). NMS 310 uses AttrID as a unique identifier for the attribute within the system.

[0080] Variable entitled ‘DisplayName’ contains display string for the attribute (‘SUM_System Time’ in this case). Variable entitled ‘UniqueName’ contains unique name value for the attribute (‘STATS_ATTRIB01’ in this case). The display name is not necessarily unique, and thus either the AttrID value or the unique name value may be used to distinguish one attribute from another. Unique name value is intended to be in human readable form, whereas AttrID is not easily comprehensible since it is intended for computation purposes (e.g., as a key in Database 130).

[0081] Variable entitled ‘DataType’ specifies data type for this attribute (character in this case). Variable entitled ‘AttrType’ specifies type of this attribute (hidden in this case). This is set to hidden since it is an input used to only define the attribute; it does not output the value obtained in a monitor poll—the value is actually output using a corresponding output attribute described later (lines 851-852 in FIG. 8B). Variable entitled ‘Default’ stores a composite value to indicate all the properties of this attribute as selected in line 734 of FIG. 7B (‘+SUM+System Time; %; true; true; 1.0’ in this case).

[0082] With reference to line 734, the value indicates that the attribute has ‘Function Type’ property (second column) equal to ‘SUM’, ‘Attribute Names’ property (first column) equal to ‘System Time’, unit of measure equal to ‘%’ (third column), default graph option set to ‘true’ (sixth column), normal data distribution option set to ‘true’ (seventh column), and scale factor equal to ‘1.0’ (fifth column).

[0083] Lines 841-842 contain definitions of some pre-defined configuration attributes used to display aggregate information related to the resource pools being monitored. Line 841 corresponds to column ‘Monitor Version’ that is displayed in row 1190 of FIG. 11B. Variable entitled ‘AttrID’ (501017993 in this case) has a unique value across all attributes of all monitor types within NMS 310, and is obtained by concatenating the value of a second variable ‘UsrAttrID’ (993 in this case) with the MOTypeid value (501017) in line 801. The values may be assigned using some simple scheme (e.g., lowest unassigned value in a certain range of numbers). NMS 310 may use AttrID as a unique identifier for the attribute within the system.

[0084] Variable entitled ‘DisplayName’ contains display string for the attribute (‘Monitor Version’ in this case). Variable entitled ‘UniqueName’ contains a unique name value for the attribute (‘PW_MON_VER’ in this case). The display name is not necessarily unique, so either the AttrID value or the unique name value may be used to distinguish one attribute from another. Unique name value is intended to be in human readable form, whereas AttrID is not easily comprehensible since it is intended for computation purposes (e.g., as a key in Database 130).

[0085] Variable entitled ‘DataType’ specifies the data type of this attribute (character string in this case). Variable entitled ‘AttrType’ specifies type of this attribute (configuration in this case). Variable entitled ‘Label’ specifies if this attribute will be displayed as a label (yes in this case). Note that row 1190 of FIG. 11B also displays other information related to the resource pools being monitored, such as Total Instances (line 842 in FIG. 8B), Instance Name (line 1011 in FIG. 10A), Group (line 1012 in FIG. 10A), and Collect Data (line 862 in FIG. 8C).

[0086] Lines 851-852 indicate the manner in which aggregate information relating to the attributes of interest can be displayed (as seen in row 1180 of FIG. 11B). Line 851 corresponds to attribute “Sum System Time” selected by the user/administrator in row 734 of FIG. 7B. Variable entitled ‘AttrID’ (501017072 in this case) is obtained by concatenating the value of a second variable ‘UsrAttrID’ (072 in this case) with MOTypeid value (501017) from line 801. The values may be assigned using some simple scheme (e.g., lowest unassigned value in a certain range of numbers). NMS 310 uses AttrID as a unique identifier for the attribute within the system.

[0087] Variable entitled ‘DisplayName’ contains display string value for the attribute (‘SUM_System Time’ in this case). Variable entitled ‘UniqueName’ contains unique name value for the attribute (‘STATS01’ in this case). The display name is not necessarily unique, so either the AttrID value or the unique name value may be used to distinguish one attribute from another. Unique name value is intended to be in human readable form, whereas AttrID is not easily comprehensible since it is intended for computation purposes (e.g., as a key in Database 130). Variable entitled ‘AttrType’ specifies type of this attribute (statistics in this case). This is set to stats since it is an output attribute used to record the value obtained in a monitor poll.

[0088] Variable entitled ‘UOM’ specifies the units of measurement for this attribute (‘%’ in this case). That is, the aggregate ‘System Time’ parameter for two or more Solaris CPU resource elements is computed and displayed as a percentage value. Variable entitled ‘IsDefaultStats’ specifies if this is a default attribute for which data is collected (yes in this case). Variable entitled ‘TableName’ gives the table name in Database 130 for this attribute (‘_SOLCPU1’ in this case).

[0089] The database table name is derived from the unique name for this monitor type (see field 732 in FIG. 7B and line 802 in FIG. 8A). Variable entitled ‘ColumnName’ gives the column name for this attribute (‘STATS01’ in this case). The column name is derived from the unique name for this attribute (STATS01 on line 851). Variable entitled ‘UseNormalDistribution’ specifies if the data for this attribute follows the statistical Normal Distribution form (yes in this case). Variable entitled ‘IsDisplayed’ specifies if this attribute is displayed (yes in this case) as seen in line/row 1180 and also graph 1170 in FIG. 11B.

[0090] Lines 861-868 contain definitions of pre-defined input control attributes used to control the data collection behavior of a monitor instance. Line 861 corresponds to drop-down list box 1018 in FIG. 10B and relates to the poll interval (frequency with which this monitor instance will poll to obtain values for attributes defined in the monitor type). Variable entitled ‘AttrID’ (501017998 in this case) is obtained by concatenating the value of a second variable ‘UsrAttrID’ (998 in this case) with MOTypeid value (501017) from line 801. The values may be assigned using some simple scheme (e.g., lowest unassigned value in a certain range of numbers). NMS 310 uses AttrID as a unique identifier for the attribute within the system.

[0091] Variable entitled ‘DisplayName’ contains display string for the attribute (‘Statistics Poll Interval’ in this case). Variable entitled ‘UniqueName’ contains unique name value for the attribute (‘STSPOLLPERIOD’ in this case). The display name is not necessarily unique, so either the AttrID value or the unique name value may be used to distinguish one attribute from another. Unique name value is intended to be in human readable form, whereas AttrID is not easily comprehensible since it is intended for computation purposes (e.g., as a key in Database 130).

[0092] Variable entitled ‘DisplayType’ specifies how the values for this attribute will be displayed (integer in this case). Variable entitled ‘AttrMetaType’ specifies the type of this attribute (control in this case). Variable entitled ‘InputOnCreate’ specifies if an input value must be provided at the time of monitor instance creation (yes in this case). Variable entitled ‘Editable’ specifies if the value input for this attribute may be edited and set to another value (yes in this case).

[0093] Variable entitled ‘RequiredOnCreate’ specifies if this is a required or optional input to create the monitor instance (yes in this case, shown with an asterisk * to indicate a required field for drop-down list box 1018 in FIG. 10B). Variable entitled ‘Default’ specifies the default value set for this attribute in case the user/administrator does not specify another value during monitor instance creation (900 seconds in this case, which equals the value of 15 minutes shown in drop-down list box 1018 in FIG. 10B).

[0094] The pool monitor type thus defined can be used to instantiate several monitor instances, with each monitor instance monitoring a corresponding resource pool. The description is continued with respect to the manner in which a monitor instance can be created.

9. Creating a Monitor Instance

[0095] Creating monitor instances entails indicating the resource elements to be monitored consistent with the pool monitor defined above. Broadly, FIG. 9A-9D contain display screens using which resource elements forming a resource pool can be defined, and FIGS. 10A-10C contain display screen which facilitate an administrator to associate the defined resource pool with a pool monitor type (also defined earlier). FIGS. 9A-9D and 10A-10C are described briefly below.

[0096] On selecting ‘Add Group’ control 911 (associated with ‘group’) of FIG. 9A, the administrator (or user) creating the resource pool is provided with the display screen of FIG. 9B. Input values in entries 912 and 913 respectively indicate that the name of the resource pool and the corresponding description as ‘CPUPool’ and ‘Pool of CPUs’. Control is then transferred to form of FIG. 9C when the user selects next button 916.

[0097] FIG. 9C depicts the resource elements selected. Portion 941 depicts the various resource elements grouped according to the corresponding (element) type. The administrator is assumed to have selected the two resource elements under type ‘Solaris CPU’, and accordingly portion 942 contains the two resource elements (in rows 914 and 915) and the corresponding type (in column 943). Successful creation of the resource pool could be verified (by the user/Administrator) by examining the list of values under ‘groups’ (951) of FIG. 9D.

[0098] FIG. 10A contains a display screen which is shown when an administrator uses the ‘Add’ option in FIG. 7C and requests that a monitor instance be created using the pool monitor type ‘Patent Test’. In FIG. 10A, the administrator is shown assigning a name TestSolCPU (Entry 1011) for the Resource Pool ‘CPUPool’ (selected using list box 1012).

[0099] In FIG. 10B, the administrator is shown assigning one or more control parameters for the TestSolCPU monitor instance defined in the configuration tab shown in FIG. 10A. The control parameters may be set at their default values, or changed depending on the administrator's need, and are used to control the behavior of the monitor instance during the data collection process. For example, ‘Statistics Poll Interval’ (entry 1018) determines the frequency of data collection, and ‘Statistics Poll Timeout’ (entry 1019) determines the duration of time after which a poll request will time out due to some reason such as the monitored object not being available.

[0100] Similarly, ‘Configuration Poll Interval’ (entry 1016) determines the frequency of polling to check for any configuration changes (e.g., if the CPU is upgraded), and ‘Configuration Poll Timeout’ (entry 1017) determines the duration of time after which a configuration poll request will timeout due to some reason such as the monitored object not being available. Successful creation of the monitor instance is verified using the display screen of FIG. 10C (as indicated by lines 1021 and 1022).

[0101] On completion of above steps, monitoring system 110 monitors attributes of interest defined in monitor type ‘PatentTest’ in each resource element of CPUPool (according to step 230). The aggregated information may then be displayed as described below.

10. Displaying Aggregated Information

[0102] FIGS. 11A and 11B contain display screen illustrating the manner in which aggregate information related to resource pools is displayed in one embodiment. The display screen of FIG. 11A is displayed when a user accesses a pre-specified URL (provided from NMS 310). The user may select ‘Group Matrix’ in portion 1110 to cause all the presently monitored (configured) resource pools to be displayed in portion 1120.

[0103] In portion 1120, group name (Column 1111) indicates the resource pools monitored. Row 1130 indicates that the monitored resource pools include CPUPool, which has been defined earlier with respect to FIGS. 9A-9D. When the user selects (clicks-on) monitors item in the same row, the display screen of FIG. 11B is generated.

[0104] FIG. 11B contains a graph (1170) for the aggregated value of the System Time (as a sum of the percentages of individual system times) for the Resource Pool CPUPool according to control parameter values specified by the administrator (in 1016 to 1019 of FIG. 10). Multiple aggregate information types (e.g., average, along with the sum) can be selected and viewed in parallel, if so desired by the user as shown in portion 1180.

[0105] Note that portion 1190 displays that the total number of monitor instances (‘Total Instances’ column) as being equal to 2. This corresponds to the two resource elements selected earlier in rows 914 and 915 of FIG. 9C.

[0106] Thus, by using the approaches of above, a user may view the aggregate information related to a resource pool formed from multiple resource elements.

[0107] While the description of above is provided with respect to resource elements which are in different physical systems, it should be appreciated that the resource elements can be present potentially in the same system. For example, different independent processes executing on a computer system, can be viewed as resource elements of a single pool. In addition, so long as the information attribute to be measured is the same for two resource elements, these two resource elements can be viewed as being of the same type, and modeled as a resource pool to measure that information attribute.

[0108] It should be understood that the different components of the network management system can be implemented in a combination of one or more of hardware, software and firmware. In general, when throughput performance is of primary consideration, the implementation is performed more in hardware (e.g., in the form of an application specific integrated circuit). When flexibility and/or cost are of primary consideration, the implementation is performed more in software (e.g., using a processor executing instructions provided in software/firmware). Cost and performance can be balanced by implementing with a desired mix of hardware, software and/or firmware. An embodiment implemented substantially in software is described below.

11. Software Implementation

[0109] FIG. 12 is a block diagram illustrating the details of system 1200 in one embodiment. System 1200 may correspond to NMS 310, administrator tool 360, and/or client 320. System 1200 is shown containing processing unit 1210, random access memory (RAM) 1220, secondary memory 1230, output interface 1260, network interface 1280 and input interface 1290. Each component is described in further detail below.

[0110] Input interface 1290 (e.g., interface with a key-board and/or mouse, not shown) enables a user/administrator to provide any necessary inputs to System 1200. Output interface 1260 provides output signals (e.g., display signals to a display unit, not shown), and the two interfaces together can form the basis for a suitable user interface for an administrator to interact with system 1200. For example, assuming an administrator (or user) interacts with NMS 310 using command line interface, the corresponding interface may be provided using input interface 1290 and output interface 1260.

[0111] Network interface 1280 may enable system 1200 to send/receive data packets to/from other systems on corresponding paths using protocols such as internet protocol (IP). The packets may form the basis for instantiating a monitor instance, to receive data points corresponding to various attributes, interface with client 320, etc. Network interface 1280, output interface 1260 and input interface 1290 can be implemented in a known way.

[0112] RAM 1220 receives instructions and data on path 1250 (which may represent several buses) from secondary memory 1230, and provides the instructions to processing unit 1210 for execution. Secondary memory 1230 may contain units such as hard drive 1235 and removable storage drive 1237. Secondary memory 1230 may store the software instructions and data, which enable System 1200 to provide several features in accordance with the present invention.

[0113] Some or all of the data and instructions may be provided on removable storage unit 1240 (or from a network using protocols such as Internet Protocol), and the data and instructions may be read and provided by removable storage drive 1237 to processing unit 1210. Floppy drive, magnetic tape drive, CD-ROM drive, DVD Drive, Flash memory, removable memory chip (PCMCIA Card, EPROM) are examples of such removable storage drive 1237.

[0114] Processing unit 1210 may contain one or more processors. Some of the processors can be general purpose processors which execute instructions provided from RAM 1220. Some can be special purpose processors adapted for specific tasks (e.g., for memory/queue management). The special purpose processors may also be provided instructions from RAM 1220.

[0115] In general, processing unit 1210 reads sequences of instructions from various types of memory medium (including RAM 1220, secondary memory 1230 and removable storage unit 1240), and executes the instructions to provide various features of the present invention described above. Thus, a medium providing such instructions/data may be referred to as a computer readable medium.

12. Conclusion

[0116] While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.