Abstract:
Apparatus and method of managing conditions in a network of network devices. A management system identifies conditions on the network by periodically polling the network devices or in response to a message from a network device. The management system maintains an event list that keeps track of the network conditions. The event list is automatically updated (entries added or removed) by the management system as conditions appear or become resolved.

Description:
BACKGROUND 
     The invention relates to managing conditions in a network. 
     In a computer network, problems or other conditions associated with one or more network devices frequently pop up. To manage and maintain such problems in the network, an event log is typically stored on a selected network management system. To notify the management system of predetermined conditions, a network device sends a message (e.g., trap) to the management system. If the management server is on and it recognizes the trap condition, then an entry is added to the event log. However, if the management system is off when the message is transmitted, the message is missed and the event log is not updated. 
     As the number of devices connected to the network increases, the size of the event log also increases. To maintain the event log at a manageable size, a network administrator must manually remove entries as conditions are resolved. 
     SUMMARY 
     In general, in one aspect, the invention features a network system having a network device and a management system configured to identify a condition associated with the network device and to automatically update an event list in response to the condition being resolved. 
     Implementations of the invention may include one or more of the following features. The management system polls the network device to determine the status of the condition. The network device is configured to transmit a message to the management system in connection with an occurrence of the condition. The management system automatically updates the event list by determining if a condition on the event list has been resolved, and if so, removing a corresponding entry from the event list. 
     The invention may have one or more of the following advantages. Problems and other conditions kept in a log are automatically removed without user intervention. As a result, the log reflects the current state of all monitored network devices since it only keeps information for conditions that have not been resolved. Because a management system can poll devices for conditions in the network, the likelihood that conditions are missed by the management system is reduced. 
     Implementations of the invention may further include the following features. The management system includes a storage device for storing a description database identifying information associated with the condition. The description database can be updated to add more conditions. The description database includes an MIB variable associated with the condition. 
     In general, in another aspect, the invention features a computer system for connection to a network. The computer system includes a processor, a management program executed by the processor to identify a condition on the network, and a storage device on which an event list is stored. The management program updates the event list in response to the condition being resolved. 
     In general, in another aspect, the invention features a method of managing conditions in a network of network devices. A condition on the network is identified, and a computer system on the network automatically updates an event list in response to the condition being resolved. 
     In general, in another aspect, the invention features a computer program implemented in a computer for causing the computer to identify a condition in a network, and to automatically update an event list in response to the condition being resolved. 
     In general, in another aspect, the invention features a computer-implemented graphical user interface method that displays an event list containing an entry associated with an identified condition in a network, and automatically updating the event list in response to the condition being resolved. 
     In general, in another aspect, the invention features a display that is displayable by a management program on a computer monitor. The display has a first screen listing conditions associated with devices in a network. The first screen is updated in response to the conditions being resolved. 
     Other features and advantages will become apparent from the following description and from the claims. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a block diagram of a computer network. 
     FIG. 2 is a block diagram of a management console system in the computer network. 
     FIG. 3 is a flow diagram illustrating the steps of a network management application running on the management console system. 
     FIG. 4 is a table listing recognized conditions. 
     FIG. 5 is a table of information and steps associated with the conditions. 
     FIG. 6 shows an action list and device list maintained by the network management application. 
     FIG. 7 shows an action detail screen describing the specific help for an action. 
     FIG. 8 shows an action list log screen listing the complete history of the action list. 
     FIGS. 9A and 9B are a table listing the conditions identified by data type and fault type. 
     FIG. 10 is a block diagram of a computer system such as that used to implement the management console system. 
    
    
     DETAILED DESCRIPTION 
     Referring to FIG. 1, an exemplary network  8  (including a local area network  10 ) includes computing devices  20 ,  22 ,  24 ,  26 ,  28 ,  30 ,  32  and  34 . The devices can include desktop, laptop, hub, and gateway systems. The network  8  can be a TCP/IP (transmission control protocol/internet protocol), an IPX/SPX (a Novell Netware protocol), or other type protocol network. 
     A management console system  26  in the network  10  runs a network management application  100  (FIG. 2) that maintains an action list of identified problems and other conditions of network devices. The management application  100  can automatically detect when a condition has been resolved, in which case the condition is automatically removed from the action list. As a result, the action list maintains only conditions that currently exist, which provides a manageable list that a network administrator can quickly look through. A further advantage is that the action list does not need to be manually updated continually. 
     In addition, the management application  100  maintains a description database  116  to identify information associated with a condition. Using the description database, the application can identify the status of a particular condition and determine the appropriate tasks to perform to resolve a particular condition. 
     Referring to FIG. 2, a network message passed over the network  8  and addressed to the management application  100  is received by a network interface  118  (including a network interface controller and its associated firmware) through the network connector  120  of the management console system  26 . The message is passed to a network protocol layer  114  (such as a TCP/IP layer), which converts the network message to a format understood by the operating system  112  and the network management application  100 . The description database  116  and action list  117  are stored on a storage device in the management console system  26 . In addition, the action list  117  is displayable on a computer display  102  through a video device driver  110  and video interface  108 . 
     Referring to FIG. 3, to perform an automated network maintenance process, the management application  100  at step  700  first creates the description database  116  (including tables shown in FIGS.  4  and  5 ). The description database  116  stores the types of problems or conditions that are recognizable by the management application  100 , information to be accessed and processed to determine the status of a condition, and tasks to be performed by a user to resolve the condition. The description database  116  can be easily updated by a network administrator to add new types of problems and conditions that the management application  100  can handle. 
     Next, the management application at step  702  waits for receipt of an event, which can be either a network device message or a timeout event. The network message can include a notification (in the form of a trap, for example) that a problem or other condition has occurred. The message identifies the particular condition or conditions of the sending device. A periodic timeout event can also be generated in the management application so that it can periodically poll the network devices for problems and other conditions. 
     The management application at step  704  then accesses the description database  116  to determine the types of information to request. If a specific network device trap is received, then the management application accesses the description database  116  to determine the information associated with the trap condition to request from the sending network device. 
     If the event is a timeout, then items identified in the description database  116  as requiring periodic updates are addressed. Query messages are sent to the network devices to request the required information. By using the polling feature, the management application  100  can identify when a condition has been resolved so that information associated with that condition can be removed from the action list  117 . 
     Next, at step  706 , the management application transmits requests to the appropriate network device or devices to request information relating to the relevant problems or conditions. When the requested information is received from the network device or devices, the management application at step  708  checks the information. Next, at step  710 , the action list  117  is updated, by either adding entries (if new problems or conditions are found) or deleting entries (if the problems or conditions have been resolved). 
     Referring to FIGS. 4 and 5, the description database  116  includes two tables. The first table is the ACTINFO table, which lists action numbers (in column  300 ) and associated descriptions (in column  312 ). For example, action number  5000  corresponds to a Replace Processor action; action number  10004  corresponds to a Check System Temperature action; action number  11001  corresponds to a Degraded Drives action; and so forth. Other supported actions include threshold levels (e.g., fan speed exceeds a predetermined rate); utilization levels (e.g., CPU utilization 80%); and software version control, in which the management application monitors software versions on network devices, reports out of date software on the action list, and informs the user that a software upgrade is available or that a software upgrade must be performed to prevent a critical bug. 
     The ACTINFO table also includes an Enabled column  302  to indicate whether the particular action is enabled or disabled (Y for enabled and N for disabled). If an action is disabled, then that particular action is not acted upon by the management application  100 . An Action Type column  304  categorizes the fault type of the action (e.g., a mass storage fault, a system board fault, network interface card fault, a software version control fault, etc.). 
     An Update Type column  306  indicates the type of updates requested for the particular action—whether updates are timed (periodic polling) or performed in response to a trap from a network device. If the latter, then the management application  100  updates the action list  117  only when it receives a trap from a network device and does not periodically issue queries for the particular action. A Severity column  308  indicates the severity of the particular action, with the value  1  indicating the most severe condition and higher values indicating less severe conditions. A Bitmap ID column  310  identifies a graphical user interface (GUI) element (e.g., an icon) associated with an action that is displayed. Thus, the Replace Processor action can be associated with a specific icon displayed by the computer to the user. 
     In FIG. 5, an ACT_PROC table includes an action number column  400  listing the same action numbers as in the ACTINFO table in FIG.  4 . In addition, the ACT_PROC table includes an Item Name column  404 , which lists variables, (e.g., Management Information Base or MIB variables according to the SNMP or Simple Network Management Protocol), which are checked by the management application  100  to determine the status of the particular action. A Data Source column  406  specifies the particular source of the action, e.g., an SNMP source or other protocol source. A Check Type column  408  indicates the type of checking required of the condition listed in column  404  for a particular action. For example, a value of 1 indicates an “index scan” while a value of 2 indicates a “full scan”. A full scan checks all drives and produces a true result if any combination of the devices contains the conditions to be checked. Thus, for example, if an action is associated with three conditions and all three must be true (AND operation), then the full scan produces a true result if condition  1  is found on device X, condition  2  is found on device Y, and condition  3  is found on device Z, where X, Y, and Z can be the same or different devices. 
     An index scan, on the other hand, requires that the conditions to be checked must all be located on one device. In the example above, conditions 1, 2, and 3 must all be on one device for the index scan to be true. 
     A Comp Type column  410  has a number of different values, e.g., 10, 11, 12, 20, 21, 22, or 23, to indicate the type of comparison to be performed on the variables listed in column  404 . The different Comp Type values and what they represent are listed below in Table 1. 
     
       
         
               
               
               
             
           
               
                   
                 TABLE 1 
               
               
                   
                   
               
               
                   
                 Comp Type Number 
                 Comparison 
               
               
                   
                   
               
             
             
               
                   
                 10 
                 Num = 
               
               
                   
                 11 
                 Num &gt; 
               
               
                   
                 12 
                 Num &lt; 
               
               
                   
                 20 
                 String = 
               
               
                   
                 21 
                 String &gt; 
               
               
                   
                 22 
                 String &lt; 
               
               
                   
                 23 
                 In String 
               
               
                   
                   
               
             
          
         
       
     
     The comparison is performed between the variable in column  404  and the data field in column  412 . For example, if the Comp Type value is 10, then the management application  100  determines if the particular variable contains a number equal to the corresponding value in column  412 . As another example, a Comp Type Number of 21 would cause the management application to determine if the particular variable contains a string greater than the corresponding specified value. A Comp Type Number of 23 would cause the application to determine if a specified value is contained in the string in the variable. 
     A Not column  414  specifies whether the result of the comparison should be inverted; a value of 0 indicates no inversion while a value of 1 indicates inversion. An Operator column  416  indicates the type of operation to be performed with another variable associated with the same action number. For example, for action number  11000 , three variables are specified, including cpqDaPhyDrvStatus, cpqScsiPhyDrvStatus, and cpqDaSpareCondition. The value in the Def Count column  402  indicates the sequence of the three variables associated with an action (e.g., 1, 2, 3). A value of 2 in the Operator column  416  indicates that an OR operation is performed between the variable in the corresponding row and the variable in the next row associated with the same action. A value of 1 would indicate an AND operation and a value of 0 indicates a NOP or no operation. 
     Thus, the ACT_PROC table specifies the relevant parameters associated with an action and how the parameters are to be processed to determine the status of a condition. 
     Referring to FIG. 6, an Action List screen  500  displays information from the action list  117 . The screen  500  shows conditions associated with network devices, which are listed in a Device List window  502 . Exemplary network devices are identified as Accounting, Human 13  Factors, Human_Resources, Marketing, Sales, Dave_Smith, Kevin, and Mike. In this example, Dave_Smith, Kevin, and Mike are desktop units while Accounting, Human_Factors, Human_Resources, Marketing and Sales are servers. 
     There are two different ways of displaying the action list screen  500 , which are to display by action or to display by server (as shown by  504 ). The action list screen provides a convenient means of displaying information associated with network device conditions to a network administrator. If a condition is resolved, the corresponding item is removed from the action list. Each action has a priority, as indicated by the value in the Severity column  308  in FIG. 4, and actions with higher priorities are displayed toward the top of the list. 
     Referring to FIG. 7, an Action Detail screen  506  provides specific help to the user for each action. The purpose of this screen is to tell the user exactly what happened, and the steps that must be performed to resolve the problem. The action details include a description of the problem, specific details about the problem, and a list of steps to correct the problem. Double clicking on an action in the Action List screen  500  opens the Action Detail screen. 
     FIG. 8 shows an Action List Log screen  508 , which contains a complete history of the action list. As items are added or removed from the list, they are recorded in the log. As actions come and go, a user who is not constantly watching the screen may miss an important event. The user can conveniently refer to the log to determine events that have occurred. For example, if the user sets a threshold on CPU utilization for 85%, the CPU utilization action will be entered into the log as the utilization varies. 
     The conditions are divided according to three data types: action data, status data, and utilization data. Action data refers to an action that needs to be taken by the administrator to correct a system fault or degraded condition. Status data refers to the status of a system component. Utilization data displays performance or utilization information. In addition, as noted above, the conditions are also grouped according to fault types: rapid recovery faults, mass storage faults, system board faults, network interface card faults, and software version control faults. Table 2 (in FIGS. 9A and 9B) lists exemplary conditions by data type and fault type. 
     Referring to FIG. 10, the physical components of the management system  26  are illustrated. The system  26  includes a central processing unit (CPU)  200  connected by a CPU-PCI bridge  202  to a Peripheral Component Interconnect (PCI) bus  206 . A main memory  204  is connected to the CPU  200  and CPU-PCI bridge  202 . A mass storage device  208 , in the form of hard disk drives, for example, is connected to a SCSI controller  210 , which is in turn connected to the PCI bus  206 . A network controller card  212 , which is part of the network interface  102  or  114  described in FIG. 2, is also connected to the PCI bus  206 . A video controller  216  controls signals transmitted between the PCI bus  206  and a video display  214 . 
     An expansion bus  220 , such as the Extended Industry Standard Architecture (EISA) or the Industry Standard Architecture (ISA) bus, is connected to the PCI bus  206  through a PCI-expansion bus bridge  218 . The expansion bus  220  is connected to an input/output (I/O) controller  222 , which provides interface ports to a keyboard  224 , a pointer device  226  (such as a mouse), and a parallel port  228 . The I/O controller  222  also controls access to a non-volatile random access memory (NVRAM)  230 , which can be implemented with a flash memory or an EEPROM. The NVRAM is used to store the system BIOS for performing the power up sequence in the computer system  26 . Expansion slots  232  are connected to the expansion bus  220  to provide further expansion capabilities. 
     Other embodiments are within the scope of the following claims. For example, a modified version of the management application can be loaded on network devices other than the management console system  26 . In this alternative network system, the local management application in each network device can obtain and process the information as indicated in a locally loaded description database and send that information to the management console system in place of a trap message.