Today, large numbers of personal computers and workstations are being interconnected with devices such as file servers, print servers, modems and hubs to form local area networks, metropolitan area networks and wide area networks. These networks allow the personal computers and workstations to share information and valuable resources among each other. Now more than ever, individuals and companies depend on networks to conduct business and to communicate with people around the world. Indeed, the network has become the computer.
Most networks use a network manager and some type of network management protocol such as Simple Network Management Protocol (SNMP). Among its management tasks, the network manager automatically monitors the health of the devices on the network. This can be done by sending an event request to an agent of the device. Each event request directs one or more agents to monitor a device attribute against error conditions. If the error conditions are satisfied, an event is generated. In addition, an event report is generated that returns the value of the device attribute to the network manager. For example, the network manager sends an SNMP event request to a workstation. The event request specifies the attribute sysUpTime (which indicates the length of time a device has been running), the relational "Less Than" and a threshold (e.g., 1). Such an event request might be sent to determine if the workstation is operational. If sysUpTime is greater than the threshold, the workstation is deemed operational. However, if sysUpTime is less than the threshold, an event is generated. In response, the network manager sounds an alarm, sends an e-mail message, displays visual effects or takes some other action indicating that the workstation is down.
However, these actions are all signaling actions. They reveal nothing about why the workstation was not operational. Did a port test fail? Was disk availability above a threshold? Was the CPU usage too high? A general event request for an attribute such as sysUpTime does not give the exact details. Thus, the network administrator must take the time to request data from the device and/or visually inspect the device.
Not only can the event requests and reports be unrevealing, but they can be problematic as well. For example, an event request can require sysUpTime to be monitored at regular intervals of 60 seconds. If the workstation is down for a lengthy period of time, the attribute will be polled a total of 60.times.24 times each day, and 1440 event reports will be returned from the device each day. This results in unnecessary network management traffic and an unnecessary source of distraction for the network administrator.
It is an object of the present invention to provide a method and system that efficiently monitors a network of computing devices.
It is another object of the present invention to provide a method and system that efficiently monitors a network of computing devices through the use of event requests.
It is an object of the present invention to provide a network management method and system that ascertains the nature of an event through the generation of one of more additional event requests.
It is a further object of the present invention to provide a network management method and system that stops the generation and transmission of redundant events.
It is another object of the present invention to provide a method and system that provides an alternate route for transmitting event requests to one or more network devices.
It is a further object of the present invention to provide a method and system as described above that minimizes network traffic.
Other general and specific objects of this invention will be apparent and evident from the accompanying drawings and the following description.
USPTO Backgrounds
USPTO Backgrounds