Abstract:
In a computer network system, a service monitoring and measurement system is described having a plurality of service transaction modules to enable a user to remotely or locally monitor and/or measure the availability of network services. The service measurement and monitor includes logic to monitor and manage network services by allowing a user to request service availability by periodically sending service packets from the transaction modules to the service server. The service measurement and monitor system advantageously ensures status state change in a particular service one hierarchy level of the host device being monitored is retained and communicated to other hierarchy levels as the user measures service availability on the network.

Description:
FIELD OF THE INVENTION  
         [0001]    The present claimed invention relates generally to the field of computer network systems. More particularly, embodiments of the present claimed invention relate to text based browser management of network systems.  
         BACKGROUND ART  
         [0002]    Information Technology organizations face difficult challenges in managing the availability of applications and computing resources within the enterprise. The growth of networks and distributed systems has led to an increasingly complex heterogeneous environment, encompassing a broad spectrum of hardware, software and operating systems. Today, systems range from PCs and technical workstations on user&#39;s desktops, to small and mid-size servers in departments, all the way up to large enterprise servers and mainframes in the corporate data-center. Computing resources may be geographically dispersed across a business campus or around the world to support global business operations. The proliferation of LANs and WANs means that users can access corporate information assets almost anywhere, any time of day or night.  
           [0003]    In recent trends in distributed corporate computing, the use of mission-critical applications has blossomed, helping companies to become more competitive and conduct business more effectively. The mission-critical nature of these applications, however, is aggravating an already difficult system management task. Users are demanding systems and applications that are continuously accessible and available with expectations for improved levels of service that are constantly on the rise.  
           [0004]    As the demands for acceptable service levels and the complexity of the computing environment have increased, administrators have responded by standardizing procedures and adopting network-aware tools. While limited in functionality, many of these tools have helped address the need for remote network management. Still other tools allow administrators to monitor individual systems and hardware components.  
           [0005]    To meet the rising demands for better levels of service, it is crucial both to manage and monitor the availability of applications and data, as well as the availability of individual systems and networks, and administrators still lack an integrated way of doing so. While the job of managing systems, applications and data is becoming increasingly complex, IT managers must still control costs and provide non-interrupting services to their clients on a 24/7 basis. This calls for the system administrator to not only monitor and manage the availability of systems, but also to ensure that when a system goes down, the recovery time is kept to a minimum.  
           [0006]    [0006]FIG. 1 is a prior art depiction of a network management system  100 . The prior art system illustrated in FIG. 1 comprises three layer component of a console layer, a server layer  110  and a host layer  120 A- 120 C.  
           [0007]    The console layer comprises multiple consoles  101 A- 101 B serving multiple users for the network management system  100 . The consoles  101 A- 101 B provide visual representations of managed objects (for example, hosts and networks) to users of the network management system  100 . The consoles  101 A- 101 B also provide users with the ability to manipulate attributes and properties associated with the managed objects and the ability to initiate management tasks (for example, dynamic reconfiguration of a host or a device).  
           [0008]    The server layer  110  accepts requests from users through the consoles  101 A- 101 B and passes these requests to the appropriate host. The server  110  then relays the response from the agent back to the user. For example, if a user wants information on the number of users accessing a host, the server  110  receives this request from any one of consoles  101 A- 101 , and sends the request to that particular host. The host finds the requested information and passes it back to the server which then transmits the information to the user via the console  101 A- 101 B. The server  110  also provides the consoles  101 A- 101 B with a secure entry point to interface with the hosts  120 A- 120 C.  
           [0009]    The hosts  120 A- 120 C perform the actual tasks of information gathering, monitoring and management of objects on the nodes managed by the network management system  100 . The server  110  interacts with the hosts  120 A- 120 C to gain access to managed objects on the network.  
           [0010]    Although the prior art system illustrated in FIG. 1 provides the user with the convenience of accessing network resource services, the prior art system does not provide the user with the ability to monitor and measure network—service availability or unavailability.  
         SUMMARY OF INVENTION  
         [0011]    Accordingly, there is provided a multi-host, network system comprising a network server having a network monitoring and measurement system for monitoring and measuring the availability of system resource services in the network.  
           [0012]    What is described herein is a computer network management system having a server with a software based system monitoring and measurement system for monitoring and measuring network service availability. Embodiments of the present invention allow users to measure and monitor the availability of network services by regularly contacting the services to determine the availability of the accessed service. The present invention allows users to monitor network resources to determine the status of the resources and when the resource are unavailable, the reason for the unavailability.  
           [0013]    Embodiments of the present invention also include a monitoring unit that enables the user to determine the mean time between failure when a network service becomes unavailability and when the service becomes available. The user checks for a particular service&#39;s availability by regularly sending dummy transactions to the service per the user&#39;s request and gathers data to determine the availability status of the service being monitored. The data gathered as a result of such periodic transmittals of dummy transactions enables the present invention to calculate the time it takes a service to fail.  
           [0014]    Embodiments of the present invention also include a monitoring unit that enables the user to determine the mean time to recover from a service failure when a service fails. The user checks for a particular service&#39;s availability by sending periodic monitoring transactions to the service. If the service does not respond to a monitoring transaction, the service is assumed to be unavailable. Data gathered from such a monitoring request is used to determine how quickly the service recovers from a failure.  
           [0015]    Embodiments of the network service monitoring and measurement system of the present invention also include a services scalar table generator provides the user with the ability to define the service variables (factors) that the user wishes to monitor. The scalar table generator also provides entries for the name of the service being monitored, the port number of the connecting server, the percentage time for the service, the availability of the service, the mean time between failure of the service and the mean time between recovery of a failed service.  
           [0016]    Embodiments of the network service monitoring and measurement system of the present invention further include a configuration data generation unit for storing configuration information data for each service being monitored and measured. The configuration file that the configuration unit generates is different and specific to each service request transaction the user generates to a particular service. The configuration file also includes any configuration parameters for each service request the user issues.  
           [0017]    Embodiments of the network services monitoring and measurement system of the present invention further include a services vector table generation unit that provides specific configuration service information pertaining to the service being monitored and measure and the service environment (server). The information generated by the vector table generator includes the server name and port number where the service is running, the last time a request was sent to the service, the availability of the service when the last request was sent.  
           [0018]    Embodiments of the network services monitoring and measurement system of the present invention include a protocol generation unit that provides the protocol information associated with each user service request to the service server. The protocol information allows user service requests to be transmitted to specified service servers with their native protocol packets.  
           [0019]    These and other objects and advantages of the present invention will no doubt become obvious to those of ordinary skill in the art after having read the following detailed description of the preferred embodiments which are illustrated in the various drawing figures.  
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0020]    The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention:  
         [0021]    [0021]FIG. 1 is a block diagram of a prior art computer network system;  
         [0022]    [0022]FIG. 2 is a block diagram of a computer network system in accordance with an embodiment of the present invention;  
         [0023]    [0023]FIG. 3 is block diagram illustration of one embodiment of a system availability measurement and monitoring system of an embodiment of the present invention;  
         [0024]    [0024]FIG. 4 is a block diagram illustration of an embodiment of the internal architecture of the system availability measurement and monitoring system of FIG. 3;  
         [0025]    [0025]FIG. 5 is a block diagram illustration of one embodiment of a data acquisition system for a network service of an embodiment of the present invention;  
         [0026]    [0026]FIG. 6 is a block diagram of an embodiment of a data acquisition system for a network service of another embodiment of the present invention; and  
         [0027]    [0027]FIG. 7 is a flow diagram of one embodiment of the system availability measurement and monitoring system of the present invention.  
     
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0028]    Reference will now be made in detail to the preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it will be understood that they are not intended to limit the invention to these embodiments.  
         [0029]    On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended Claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be obvious to one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention.  
         [0030]    The embodiments of the invention are directed to a system, an architecture, subsystem and method to process data in a computer network system. In accordance with an aspect of the invention, a system for measuring and monitoring the availability of network services in a network management system provides users the ability to conduct periodic monitoring and measurement of network service resources to determine the availability of these resources.  
         [0031]    [0031]FIG. 2 is a block diagram depiction of one embodiment of a network management system  200 . The network management system  200  illustrated in FIG. 2 comprises console layer  210 , server layer  220  and agent layer  230 . The agent layer comprises system availability measurement and monitoring system (SAMM)  240  of the present invention.  
         [0032]    The console layer  210  comprises multiple consoles serving multiple users for the network management system  200 . The consoles provide graphics visual representations of managed objects (for example, hosts and networks) to users of the network management system  200 . The consoles also provide users with the ability to manipulate data attributes and properties associated with the managed objects and the ability to initiate management tasks (for example, dynamic reconfiguration of a host or a network) with graphics interface tools.  
         [0033]    The server layer  220  comprises a server  221  that accepts requests from users through the consoles  210  and passes these requests to the appropriate agents in the agent layer  230 . The server provides a secure centralized point of access for all system management operations. All requests from the console layer  210  are funneled through the server  221 . The server  221  acts as a focal point that provides a number of core centralized service.  
         [0034]    First it receives and routes requests from multiple user console. The server  221  recognizes duplicate requests intelligently consolidating them for a higher network and system efficiency. Secondly, the server  221  enforces the security models, authenticating users and handling all user session management. The server  221  receives all system status information to all interested console clients. The server  221  then relays the response from the agents  230  back to the user.  
         [0035]    For example, if a user wants information on the number of users accessing services over the network, the server  221  receives this request from any one of consoles  210  in the console layer, and sends the request to that particular agent. The agent  230  finds the requested information and passes it back to the server  221  which then transmits the information to the user via the consoles. The server  221  provides the consoles with a secure entry point to interface with the agents.  
         [0036]    The agent layer  230  monitors managed objects in the network. Two types of components exist at the agent layer—agents and probe daemons. Both run as background processes on managed objects. The agents  230  perform management tasks through use of management modules that are easily extensible and customizable. The agent layer  230  includes default modules that provided the infrastructure for the network services.  
         [0037]    In one embodiment of the present invention, the agents  230  use rule-based technology to determine that status of the managed objects. The agents  230  store data and status of managed objects in a management information base (MIB). The MIB acts a repository for managed objects. The managed objects together represent a model of the system and its components being managed. The managed objects are arranged in a tree, showing a hierarchical relationship of the components. Within the MIB, managed objects are logically grouped into management modules that collectively implement management functions.  
         [0038]    The agent layer  230  further comprises a system availability measurement and monitoring (SAMM) system  240  of the present invention that allows users to specify network services they wish to measure and monitor. The SAMM  240  can be dynamically loaded into the agent layer  230  by a user to perform the data gathering for the user to determine whether specified network services are available or unavailable. The SAMM  240  provides service modules that are loadable by the agent  230  to monitor a particular network service.  
         [0039]    In one embodiment of the present invention, the SAMM  240  comprises a plurality of monitoring modules (see FIG. 3) with each module monitoring one service using one service specific protocol. Thus, there is a one-to-one correspondence between the number of service modules and the number of services being monitored. In one embodiment of the present invention, the monitor modules may be loaded locally at a service server site to perform local measurements and monitoring of a service locally on a server system. Similarly, a remote site module may be loaded on a remote user site to monitor a service remotely at a user site.  
         [0040]    In one embodiment of the present invention, the remote site modules are referred to as synthetic transaction modules. The synthetic transaction modules have the ability to monitor and measure service availability from a user site. The synthetic transaction modules simulate user service requests to the service server by periodically sending service requests to a particular service per a user&#39;s setting to monitor a service and also checks the availability of a service server.  
         [0041]    In one embodiment of the present invention, the user can access different services from the remote sites by issuing service requests based on user specific configurations. The configuration information is different for different services. For example, for DNS services, the request may have the names of the host servers to be resolved, domain names of the host server, etc. The configuration information may also be different for each server. For a service being monitored, the configuration data may be classified into two types:  
         [0042]    1) A common configuration data: such data may be common across all service requests of a service. All services have the type of data. For example, the port where services are running, username, etc. All service requests are sent to the service running at that port using the same username, etc.  
         [0043]    2) Specific configuration data: this data is different for each service request of a service. For example, for a specific FTP service being monitored, one request will be to do a get operation and another will be to do a port operation.  
         [0044]    [0044]FIG. 3 is a block diagram of one embodiment of the system availability measurement and monitoring system (SAMM)  240  of the present invention. As shown in FIG. 3, the SAMM  240  comprises a plurality of user loadable monitor modules  301 - 305 , and service element module  310 - 320 . In one embodiment of the present invention, the modules  301 - 305  are user loadable and they send periodic requests to the various services, which may be running locally or remotely, that a user wishes to monitor and measure in the network  200  and gather data. In the present invention, the modules  301 - 305  are referred to as synthetic modules. Each of these synthetic transaction modules  301 - 305  has the ability to monitor and measure the availability of specific services from a user site. There is a separate module for each service that the user wishes to monitor. For example, the user may wish to monitor and measure the availability of a web service (e.g., module  305 ) or a calendar service (e.g., module  304 ).  
         [0045]    Each of the service element modules  310 - 320  provides the network infrastructure that enables the user to measure the availability of the network services being monitored from the service site. There is a separate service element module  310 - 320  for each service being monitored. Typically, each of the service element module  310 - 320  determines the service availability of the service being monitored and retrieves information on the service using a service specific protocol (e.g., HTTP) on a service site.  
         [0046]    The service element modules  310 - 320  also measure the response time to connect to a requested service locally. The service element modules  310 - 320  further provide process monitoring statistics for the underlying service protocol daemon along with file monitoring capabilities. In one embodiment of the present invention, the service element module may parse a file access log statistics such as total errors encountered during a service access, total files transferred, etc.  
         [0047]    In the exemplary illustration of the SAMM  240  shown in FIG. 3, the NIS service element  310 , for example, determines NIS service availability and the ability of the NIS daemon to resolve a name. In one embodiment of the present invention, the name resolution of the following types: username; hostname; Unix group name; and Mail alias, are handled by the NIS service element module  310 . The module  310  also, in one embodiment, provide server response time locally to a user.  
         [0048]    Referring now to FIG. 4 is a block diagram illustration of an internal architecture of one embodiment of the system availability measurement and monitoring system (SAMM)  240  of the present invention. As shown in FIG. 4, the SAMM  240  comprises data acquisition unit module  410 , scalar table generator  420 , vector table generator  430 , protocol information generator  440 , time calculator  450  and configuration unit  460 .  
         [0049]    The data acquisition unit  410  provides a mechanism for the SAMM  240  to gather data about the service being monitored and the service requested. The data gathered may include status information of the service, protocol information, and availability information of the service. The data acquisition unit  410  may also gather uptime information of a service server. The uptime information enables the SAMM  240  to calculate the mean time between failure and the mean time between recovery of a service being monitored. The data acquisition unit  410  further gathers data such as the connection time for a request transaction, the total time for the transaction, the network time for the transaction and the server time for the transaction.  
         [0050]    The scalar table generator  420  provides the user with the ability to define the service variables (factors) that the user wishes to monitor. In one embodiment of the present invention, the scalar table generator comprises entries for the name of the service being monitored, the port number of the connecting server, the percentage time for the service, the availability of the service, the mean time between failure of the service and the mean time between recovery of a failed service. In one embodiment of the present invention, the user is able to populate a scalar table generated by the scalar table generator  420  by providing input information to the SAMM  240  that includes the name of a module instance, a description of a module instance, a host name and port number where a particular service is running, user passwords, etc.  
         [0051]    The vector table generator  430  provides the SAMM  240  specific configuration service information pertaining to the service being monitored and measure and the service environment (server). The information generated by the vector table generator  430  includes the server name and port number where the service is running, the last time a request was sent to the service, the availability of the service when the last request was sent. If the service is not available, the vector generator  430  generates the likely cause for the non-availability of services either due to a network fault or a host down time. The vector generator also generates any other common configuration parameters such as the username, etc.  
         [0052]    The protocol unit  440  provides the protocol information associated with each user service request to the service server. In one embodiment of the present invention, one synthetic modules monitors only one service using one protocol. In an exemplary service monitoring, the user provides the SAMM  240  with the port number where the service is running on a local system. If the user does not provide a port number, a default port number for the particular protocol is assumed to connect the user to the service server. When a user connects to a service server, the SAMM  240  send protocol specific packets to the server based on the service being requested. Exemplary protocols used by SAMM  240  include HTTP for web services requests, FTP for FTP service requests, SMTP for mail service requests, etc.  
         [0053]    The configuration unit  460  stores configuration information data for each service being monitored and measured. In one embodiment of the present invention, the configuration file that the configuration unit  460  generates is different and specific to each service request transaction the user generates to a particular service server. The configuration file also includes any configuration parameters for each service request the user issues. These may include common configuration parameters such as the username, etc. In one embodiment of the present invention, the configuration files are editable by the user.  
         [0054]    [0054]FIG. 5 is a block diagram illustration of one embodiment of an exemplary data acquisition module architecture of a calendar transaction module architecture  500  of one embodiment of the present invention. In the exemplary illustration shown in FIG. 5, if there is data in the calendar transaction table  520 , the module  304  sends a user configured request at each refresh interval to the calendar service running remotely and retrieve mail.  
         [0055]    In one embodiment of the present invention, each user calendar request comprises the following. First is resolving the server name  510  on which the calendar service is running. This gives the resolution time. Second is sending the request to the calendar server  530  to perform a lookup calendar.dtcm_lookup is used for this purpose. Third is setting the response, and this gives the calendar retrieval time. The sum taken for all the steps is the total transaction time. If the request is successful in retrieving the message, it populates the table with the various response times and indicate that the calendar service is available in the server details managed object. If the request is not successful, then an error is returned by the request and analyzed to find out the cause of failure. Based on the analysis, if it is determined that the server or service is unreachable, a refresh of the server details managed objects is performed to find out the likely cause of failure.  
         [0056]    [0056]FIG. 6 is block diagram illustration of another exemplary transaction flow  600  of a synthetic translation module of the present invention. The illustration in FIG. 6 is an exemplary NIS transaction module  620  architecture. In the example shown in FIG. 6, if there is data in the NIS transaction table  620 , the module sends a user configures request at each refresh interval to the NIS service running remotely to gather data. The module uses library routines provided as an interface to a NIS server  630  to send the requests and resolve the names. Each request consists of the following steps:  
         [0057]    1) Resolve the server name on which the NIS service is running. This gives the server name resolution time;  
         [0058]    2) Send a yp_bind request to the server and receive response. This gives the connect time;  
         [0059]    3) Send a search request to the server. This gives the name resolution time; and  
         [0060]    4) Send a yp_unbind request to free resources.  
         [0061]    The sum of the time taken for all the steps above is the total transaction time. If a request is successful in resolving the hostname, it populates the table with the various response times and indicates that the NIS service is available in the server details managed object.  
         [0062]    If the request is not successful, then the error returned by the request is analyzed to find out the cause of failure. Based on the analysis, it is determined that the server or service is unreachable, a refresh of the server details managed objects is performed to find out the likely cause of failure.  
         [0063]    [0063]FIG. 7 is a computer implemented flow diagram illustration  700  of one embodiment of the network service availability monitoring and measurement system of the present invention. The network service availability monitoring and measurement of network services is initiated at step  705  upon initiation of the measurement system (SAMM  230 ) initiating a management information base that stores the status of the managed objects on the network to which the SAMM  230  is connected.  
         [0064]    At step  715 , the SAMM  230  determines whether the required data transaction tables for a particular user and a particular service request is initiated to begin a monitoring and measurement operation. In one embodiment of the present invention, the SAMM  230  utilizes vector and scalar transaction tables to accomplish the processing of service requests to the service servers to determine the availability or unavailability of requested services. If the SAMM  230  determines that the requisite data has been acquired for further processing of a service request, processing continues at step  720 , else processing continues at step  765 .  
         [0065]    At step  720 , the SAMM  230  determines whether data acquired for further processing a service request is designated as scalar data. In making this determination, the SAMM  230  decides whether the input data is scalar based on the data provided by the user. In one embodiment of the present invention, a scalar data may include user password, a host name, a service connection port number, etc.  
         [0066]    At step  725 , the SAMM  230 , upon determining that a user input data is scalar, collects the data to generate a scalar table of the requested service information.  
         [0067]    At step  730 , the SAMM  230  utilizes the data gathered regarding a request service monitoring and measurement operation to calculate the mean time between recovery if the SAMM  230  encounters a service failure during an initial attempt to contact the service or during an access to the service. A recovery from an unavailable service enables the SAMM  230  to calculate the time between when the service was unavailable and when the service became available.  
         [0068]    At step  735 , the SAMM  230  gathers data from the contact service server in order to be able to calculate the meantime between failures for services being requested by the user.  
         [0069]    At step  740 , the SAMM  230  periodically refreshes the server details of managed objects utilized in processing a service request at small intervals. In one embodiment of the present invention, these small intervals may be in seconds when there is no data (rows) in a particular transaction table. In one embodiment of the present invention, as soon as there is data in a transaction table, the refresh interval is modified to be at larger intervals. This is because since the transaction table has data in it, the table is refreshed periodically to determine availability of a requested service.  
         [0070]    At step  745 , if the SAMM  230  determines that data acquired to generate the transaction tables is non-scalar, the SAMM  230  determines whether the transaction table is empty. If the transaction table is empty, the SAMM  230  ends the service request process at step  780 .  
         [0071]    At step  750 , if the transaction table is empty the SAMM  230  takes the underlying protocol to the incoming service request to generate the requisite protocol specific packets required to connect to the service server and to send the appropriate service packets. The SAMM  230  further receives response back from the service server and monitors and measures the time it takes to complete a transaction.  
         [0072]    At step  755 , the SAMM  230  calculates the transaction time for the available service. In one embodiment of the present invention, the transaction time also enables the SAMM  230  to calculate the total time it takes for the SAMM  230  to process a particular service request to the service server.  
         [0073]    At step  760 , the SAM  230  performs a transaction table refresh similar to that performed at step  740 . At step  765 , if the SAMM  230  is unable to acquire any data during a poll to a particular user&#39;s transaction table, the SAMM  230  waits for the next refresh time interval to perform a subsequent pool of the transaction table. The SAM  230  continues to poll the user&#39;s transaction tables until the SAMM  230  detects the availability of data in the transaction table, in the case of scalar table, to begin a service monitoring and measurement operation.  
         [0074]    At step  770 , the SAMM  230  queues a requesting agent during an on-going service request servicing process. In one embodiment of the present invention, the queuing agent includes a timer that enables the query of the transactions tables and processing terminates at step  780 .  
         [0075]    The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the Claims appended hereto and their equivalents.