US20080275985A1 - Systems, Methods and Computer Programs for Monitoring Distributed Resources in a Data Processing Environment - Google Patents

Systems, Methods and Computer Programs for Monitoring Distributed Resources in a Data Processing Environment Download PDF

Info

Publication number
US20080275985A1
US20080275985A1 US12/173,854 US17385408A US2008275985A1 US 20080275985 A1 US20080275985 A1 US 20080275985A1 US 17385408 A US17385408 A US 17385408A US 2008275985 A1 US2008275985 A1 US 2008275985A1
Authority
US
United States
Prior art keywords
monitoring
entities
consumer
entity
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US12/173,854
Inventor
Ashish Kundu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
PayPal Inc
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US12/173,854 priority Critical patent/US20080275985A1/en
Publication of US20080275985A1 publication Critical patent/US20080275985A1/en
Assigned to EBAY INC. reassignment EBAY INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: INTERNATIONAL BUSINESS MACHINES CORPORATION
Assigned to PAYPAL, INC. reassignment PAYPAL, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: EBAY INC.
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/30Profiles
    • H04L67/306User profiles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003Managing SLA; Interaction between SLA and QoS

Definitions

  • the present invention relates to systems, methods and computer programs for monitoring distributed resources.
  • a distributed data processing system typically includes a combination of hardware and software resources.
  • the hardware resources may include a processor, a data storage unit, an input/output device, a network router, network link, etc.
  • the software or ‘logical’ resources may include any computer program or program component, or a service provided by a hardware or software resource.
  • Monitoring of distributed systems is necessary for many purposes, including resource management, workload management (including load balancing and admission control), management of Quality of Service (QoS) and Service Level Agreements (SLAs), metering and accounting of system usage, fault detection and recovery and consistency management.
  • workload management including load balancing and admission control
  • QoS Quality of Service
  • SLAs Service Level Agreements
  • Monitoring of a distributed system typically comprises three steps: measurement of metrics and/or determination of the current state of a resource, collection of this data and reporting the collected data either as it is or in some processed manner to appropriate consumers.
  • two different types of monitoring metrics can be differentiated: externally measurable metrics and internally measurable metrics. Certain types of parameters can be measured by measurement components external of the system, whereas resource-specific internal parameters can only be measured internally or in some cases also by the underlying computing layer such as an operating system.
  • Externally measurable parameters are generally used for determining the state of resources such as their availability, measuring performance such as throughput or response time, measuring usage of external resources such as network bandwidth, and for evaluation of QoS parameters.
  • Internally measured parameters are used for determining resource utilization such as the number of threads used from a total number of available threads, identification of faults, and determination of resource usage at a given granularity level (per customer, request or process).
  • the faults detected by internal measurement/monitoring may not be directly visible from the behaviour of the resource or system or from the values of external parameters. However, such faults may lead to reduced performance without a complete resource or system failure.
  • Factors such as granularity of measurement and the period between measurements are associated with each metric.
  • the granularity of measurement may be per node, per container (containing one or more resource instances), per instance of the resource, per customer, or per request.
  • the interval between periodic measurement of a parameter can be uniform along a time axis or non-uniform.
  • the type of metric and factors such as granularity and period may determine where and how a metric should be measured—either by the resource internally, or by a separate computing layer or external measurement entity.
  • Collection and reporting of monitoring data may be dependent on the granularity and period of measurement. Monitoring entities may process the collected data to generate monitoring data in the form required by the consumers.
  • internal parameters may be essential for metering and accounting of resource usage. Therefore, monitoring of such metrics is important for grid computing and autonomic computing, in addition to other computing paradigms that perform accounting functions based on resource-usage.
  • internal parameters are very useful in optimizing QoS objective functions, in resource management, in workload management, in studying system behaviours and correlating internal resource usage to the externally measurable parameter values. For example, in order to reduce the response time of a customer, the resource manager might have to increase the number of threads of the component. This is possible only if the manager knows about the internal load of the component in terms of thread usage.
  • Monitoring entities can be selected, and a set of active monitoring functions can be modified, based on the requirements of consumers of monitored data.
  • a first embodiment of the invention provides a method for monitoring resources of a data processing network on behalf of consumer entities within the network.
  • the method includes determining the monitoring requirements of a consumer entity (such as by reference to a description of requirements published by the consumer entity).
  • the monitoring requirements of the consumer entity are compared with the monitoring capabilities of a plurality of monitoring entities, to identify at least one monitoring entity having monitoring capabilities matching (partially or completely) the monitoring requirements of the consumer entity.
  • One or more of the monitoring entities identified as having monitoring capabilities matching the monitoring requirements of the consumer entity is then selected, and a connection is established between the selected monitoring entity and the consumer entity.
  • the consumer entity is one of a computer program, a Web service provider, a logical representation (for example, instance of an object class) of an end user, or any physical or logical component of the data processing network which requires monitoring information.
  • Examples of consumer entities are programs implementing resource management functions, implementing load balancing functions, or implementing functions for metering and accounting of resource usage.
  • the monitoring entities are typically computer program components that perform monitoring functions, although monitoring entities may be implemented in hardware or ‘firmware’. Monitoring entities can establish connections to other components, receive and collect output data from a resource, and report the collected data to a consumer entity.
  • the compared capabilities of the monitoring entities may include one or more of the following: the set of resources currently being monitored by the monitoring entity; the set of resources which the monitoring entity is capable of monitoring; the monitoring metrics which the monitoring entity is currently monitoring; the monitoring metrics which the monitoring entity is capable of monitoring; the current granularity of monitoring; the granularity capability of the monitoring entity; the current monitoring period; the monitoring entity's monitoring period capability; and the data format capabilities of the monitoring entity.
  • selection of a monitoring entity may be based on currently active monitoring functions and attributes, and may involve comparing identifiers of the subset of resources and metrics currently being monitored by monitoring entities.
  • selection may be based on the super-set of monitoring capabilities comprising both active and currently inactive monitoring capabilities of the monitoring entities. Selection may involve consideration of the granularity and length of monitoring period desired by the consumer and provided by the monitoring entities.
  • Embodiments of the invention enable selection of monitoring entities for monitoring internal and external monitoring data.
  • the determining, comparing, selecting and binding may be performed at run-time in response to addition of a new consumer entity or a change of consumer requirements.
  • the comparison uses descriptions of each consumer entity's, monitoring entity's and resource's produced or required data and its data format.
  • the descriptions are published by the resources, monitoring entities and currently active consumer entities, and are held in one or more repositories.
  • the descriptions of the monitoring entities include which resource instances they are monitoring, which metrics they are monitoring and reporting, and the data format in which they report monitoring data.
  • the repositories also hold a description of the topology of the monitoring system. This topology information includes a list of bindings representing which resources are currently being monitored by which monitoring entities and which consumer entities are connected to receive data from which monitoring entities. When resource instances, monitoring entities or consumer entities change, the lists and descriptions within the repositories are updated dynamically.
  • a further embodiment of the invention provides a method for monitoring resources of a data processing system, which includes modifying a currently active set of monitoring functions.
  • the method includes identifying the monitoring requirements of a currently active set of consumer entities, and determining whether a currently active set of monitoring functions of monitoring entities are consistent with the monitoring requirements of the currently active set of consumer entities. If a determination is made that the currently active set of monitoring functions are inconsistent with the monitoring requirements of the currently active set of consumer entities, modifications are made to the active set of monitoring functions.
  • the modification of the currently active set of monitoring functions may involve: controlling a currently active monitoring entity to monitor additional monitoring metrics or to monitor metrics at a different granularity or interval periods; activating an inactive monitoring entity; or deactivating a monitoring function or monitoring entity which is monitoring metrics that are not required by the currently active set of consumers.
  • Such modifications enable dynamic response to the requirements of individual consumer entities. By enabling de-activation of inactive functions or entities, more efficient use of data processing resources is possible.
  • a further embodiment of the present invention provides a data processing system for monitoring resources of a data processing network.
  • the data processing system includes a data processing unit and a data storage unit for storing monitoring capabilities of each of a set of monitoring entities.
  • the system also includes a monitoring manager which is responsive to monitoring requirements of a data consumer entity.
  • the monitoring manager compares the monitoring requirements of the data consumer entity with monitoring capabilities of monitoring entities stored in the data storage unit.
  • the monitoring manager identifies and then selects a monitoring entity or a set of monitoring entities having monitoring capabilities matching the monitoring requirements of the data consumer entity.
  • a monitoring framework comprising a set of monitoring components may be provided at an intermediate layer of a data processing network, between consumers of monitoring data and monitored resources.
  • a monitoring system includes at least one gateway component which implements the monitoring manager functions such as handling registration and deregistration of components.
  • the gateway component may support authentication of consumers, and initiate selection of an appropriate monitoring entity (or set) for each consumer entity. The selection may include negotiation between consumers and monitoring entities regarding the monitoring data to be provided (such as when specific requirements cannot be met at a particular point in time).
  • the gateway also initiates binding of monitoring entities to consumer entities.
  • the gateway Upon successful binding between a consumer entity and a monitoring entity, the gateway publishes a description of the binding which is stored within a repository.
  • the matching or selection and binding could be implemented by the monitoring entities instead of the gateway, and functions such as authentication can be performed by additional support modules.
  • a negotiation between a consumer entity and monitoring entities may specify the action to take when a required metric cannot be monitored for a specific resource during a specific period.
  • Negotiation may involve determining whether a consumer entity's required monitoring QoS parameters can be satisfied by the currently active set of monitoring functions, or by the currently active set of monitoring entities, or by activating new monitoring entities.
  • Monitoring entities may be started at the consumer side to handle re-formatting or other transformation of monitoring data.
  • a monitoring control method can be used to determine optimal (minimized) computation to generate required data from raw measured data, and optimal transmission frequency, for efficient resource utilization while taking account of the requirements of the consumer entities. For example, de-registration of a consumer entity may result in a determination that certain monitored metrics are no longer required by any consumer entity such that their monitoring (measurement, collecting and reporting) can be stopped. Selection of a monitoring entity may take account of which of a plurality of monitoring entities can achieve a best match.
  • Embodiments of the invention may be implemented using computer programs to implement one or more components of the invention.
  • a selector for comparing monitoring requirements with monitoring capabilities to select a monitoring entity, or to modify the active monitoring functions or entities may be implemented in computer program code.
  • the above-described gateways, monitoring entities and support modules may be implemented in program code.
  • the program code may be made available as a computer program product in which the program code is recorded on a recording medium or is made available via a data transfer medium.
  • FIG. 1 is a schematic representation of a monitoring architecture according to an embodiment of the invention
  • FIG. 2 is a schematic representation of a data processing system including a monitoring subsystem according to an embodiment of the invention
  • FIG. 3 is a flow diagram showing steps of a monitoring method according to an embodiment of the invention.
  • FIG. 4 is an example of an XML monitoring description for a service, according to an embodiment of the invention
  • a number of resources 10 , consumer entities 20 and monitoring entities 30 within a network publish a description of the data they produce, the data they receive and the data formats they support.
  • the description comprises a set of monitoring requirements.
  • the description comprises a set of capabilities and an identification of the subset of currently active capabilities (monitoring functions and their configuration attributes).
  • the monitoring requirements and capabilities are compared by a monitoring gateway, or a negotiation between components, to select suitable monitoring entities to perform required monitoring functions on behalf of consumer entities.
  • a resource may be an instance of a computer program such as a Web service component, or an instance of a database.
  • a hardware resource may be a network link, data storage or system memory.
  • consumer entities may be running instances of computer programs or any logical or physical component which requires monitoring data. Monitoring entities and other components of the network are described in detail below.
  • the monitoring framework can be represented by a layered model, in which a set of data producing resources 10 form a first resource layer A, a set of monitoring entities 30 and cooperating components 40 , 50 , 60 , 80 form a second monitoring layer B and a set of final data consumers 20 form a third management layer C.
  • the monitoring framework implemented as a monitoring layer B is distributed across a number of data processing systems within the network. Each of the data processing systems which includes a resource to be monitored typically also includes one or more components of the monitoring framework. Remote monitors 40 may also be provided elsewhere in the network.
  • the descriptions of outputs, requirements and capabilities are sent by each of the resources 10 , consumer entities 20 and monitoring entities 30 to one or more monitoring gateways 50 which store the descriptions within repositories 60 within the monitoring layer.
  • a number of support modules 80 may be provided to implement support functions that are generic to a number of monitoring entities.
  • the present specification also discloses apparatus for performing the operations of the methods, including components of a monitoring subsystem and a distributed monitoring framework.
  • Apparatus for implementing the invention may be specially constructed for the required purposes, or may comprise one or more general purpose computers or other devices selectively activated or reconfigured by computer programs stored in the computers or devices.
  • the algorithms and methods described below are not inherently related to any particular computer hardware or other hardware apparatus.
  • Various general purpose machines may be used with programs in accordance with the teachings herein. Alternatively, the construction of more specialised apparatus to perform the required method steps may be appropriate.
  • the present specification discloses a computer readable medium for storing a computer program for performing the operations of the methods.
  • the computer readable medium is taken herein to include any transmission medium for communicating the computer program between a source and a destination.
  • the transmission medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a general purpose computer.
  • the transmission medium may also include a hard-wired medium such as exemplified by typical Internet-connected server computers, or a wireless medium such as exemplified in the GSM mobile telephone system.
  • FIG. 2 shows an example data processing system in which the present invention is implemented.
  • the system includes a number of resource instances 10 which can be monitored, and a monitoring subsystem 70 including a number of monitoring entities 30 .
  • Communication between the various components is implemented using sockets, and is synchronous.
  • a monitoring gateway 50 within the monitoring subsystem 70 is responsible for authentication, registration and deregistration of consumers, as well as updating the repository 60 .
  • the gateway 50 stores published requirements and capabilities information in the repository, including a list of resources being monitored, the monitoring descriptions of the resources, and monitoring descriptions of consumer entities and monitoring entities.
  • the monitoring descriptions of monitoring entities include an identification of resource instances being monitored, identification of the metrics being monitored and reported on, and the reporting data format.
  • the repository is updated.
  • repositories 60 There may be a plurality of repositories 60 storing different types of information within a single data processing system's monitoring subsystem 70 , and there may be a plurality of repositories distributed across a plurality of monitoring systems of a distributed monitoring framework.
  • individual consumer entities or gateways running on one of the systems within the network can collaborate to provide access to data within the distributed set of repositories. This enables identification of remote monitoring entities as well as monitoring entities which are local to the resource to be monitored.
  • References to ‘a repository’ hereafter are intended to include the possibility of multiple repositories.
  • the gateway 50 is responsible for matching the current monitoring requirements of consumer entities and the currently available monitoring data and/or monitoring capabilities of monitoring entities. In other embodiments, or when no perfect match is identified, the gateway serves as an intermediary enabling negotiation between consumer entities and monitoring entities based on Quality of Service (QoS) parameters of the consumer entities and monitoring entities to select monitoring entities that provide a best fit for the monitoring requirements of a consumer entity.
  • QoS Quality of Service
  • the gateway 50 also handles binding of consumer entities to monitoring entities.
  • the consumer entity When a new consumer entity joins the monitoring system, the consumer entity registers with a gateway and is then bound to a set of one or more monitoring entities.
  • the gateway receives the request from the consumer with its requirements document in XML.
  • the binding steps are:
  • the gateway carries out matching, selection and/or negotiation.
  • the gateway then sends messages to each selected monitoring agent.
  • the message contains the requirement document (or part of the information from the requirement document).
  • the selected monitoring agents then configure themselves to start monitoring and sending monitoring data to the consumer entities.
  • the gateway Upon receiving confirmations from all selected monitoring agents, the gateway creates an XML binding document for the consumer entity.
  • This binding document contains a list of resources being monitored, the monitoring entities and interconnections between them, and the data format which they use to monitor and report data.
  • the gateway then saves this binding document in the repository as part of a binding table.
  • the key for accessing a binding document within the binding table is the consumer name.
  • a system may include one or more monitoring entities 30 but access a monitoring gateway 50 and repository 60 running on a different system.
  • the comparison of monitoring requirements, currently available monitoring data and capabilities, and the selection of monitoring entities 30 based on this comparison is implemented within the monitoring entities 30 or within additional supporting modules 80 , and the gateway 50 can rely on separate service provider components for authentication and other functions.
  • start-up of the monitoring subsystem 70 initiates 100 monitoring of a number of resources based on current configuration settings of the monitoring subsystem.
  • a set of monitoring entities 30 are initially bound to the resources 10 in accordance with the configuration settings, and these monitoring entities collect data from appropriate addresses within the system and report the data to any consumer entities 20 that have been registered as having a requirement for the data.
  • the gateway 50 When a new consumer entity joins the monitoring system, the gateway 50 performs authentication of the consumer entity and the consumer entity publishes 110 its requirement description to the gateway 50 .
  • the gateway stores 120 the description in a repository 60 .
  • the gateway 50 enables selection 130 , 140 of monitoring entities 30 according to the specific, and possibly changing, monitoring requirements of consumer entities.
  • the gateway initiates a process of negotiation 140 between the consumer entity 20 and the monitoring entities 30 and resources 10 within the monitoring and resource layers of the network.
  • the gateway 50 typically serves as a selector—using a comparison process 130 to match monitoring requirements, monitoring capabilities and active functions and QoS parameters of consumer entities.
  • the gateway or a negotiation initiated by the gateway, identifies 140 the best set of monitoring entities to act as a set of sources of monitoring data for the consumer, and the gateway binds 140 the selected set of monitoring entities to the consumer entity.
  • the monitoring entities may respond 150 to instructions from the gateway to configure itself to commence monitoring of new metrics if they are not currently being monitored and are required by a consumer entity.
  • the gateway Upon successful binding between the monitoring entities and the consumer entity, the gateway publishes a binding document to the repository (as described above).
  • the gateway may invoke a monitoring entity on another system in the network. For example, a remote monitor may be required to receive the monitoring data and adapt the data to a required format.
  • the gateway (or in other embodiments the monitoring agents) handles selection of the bundling size, the frequency at which data is communicated to consumer entities, and determines the minimal computation model for the derived metrics.
  • the gateway unbinds the consumer's monitoring entities from the consumer entity to stop reporting of data by the monitoring entities, removes the binding document from the repository, and de-registers the consumer from the gateway. Additional actions may be taken at the monitoring subsystem level in response to this de-registration, including identifying those metrics output by a resource which are no longer required by any consumer entity. Monitoring of such metrics can then be stopped in order to improve resource utilization—reducing the total processing overhead associated with monitoring.
  • Each component in the monitoring framework has a description of its monitoring metrics and other details associated with producing and/or consuming a metric (such as the output format or required input format, methods by which the data can be collected, methods by which the data is reported, etc).
  • a component that is both a producer and consumer possesses separable descriptions relating to its production and consumption of data.
  • the description of requirements published by a consumer entity may be used to coordinate processing by one or more monitoring entities, to receive monitored data from other entities in the monitoring and resource layers of the system and to process the received data to produce an output in the format expected by the consumer entity.
  • the framework comprises a set of one or more monitoring gateways.
  • Each gateway has access to the monitoring description of resources and monitoring entities, and the requirement descriptions of currently active consumer entities.
  • a monitoring gateway may also use supporting modules for authentication, negotiation, matching of requirements to monitoring data availability, registration of consumers and de-registration. According to the present embodiment, all of these functions are either performed by the gateway or coordinated by the gateway.
  • a new consumer entity must register with the framework, by contacting one of the monitoring gateways.
  • the contacted monitoring gateway handles authentication of a consumer entity (or instructs another component to do so).
  • Known authentication algorithms can be used.
  • the gateway starts a selection process on behalf of the consumer entity and monitoring entities.
  • the monitoring gateway compares monitoring requirements of the consumer entity with capabilities of monitoring entities and selects a set of monitoring entities that are suitable to provide the required data.
  • the monitoring gateway then forwards the consumer entity's requirements and a description of a dynamic negotiation protocol to the selected monitoring entities.
  • the monitoring entities employ the described dynamic negotiation protocol to select monitoring attributes (such as metrics, granularity, period) to match the consumer entity's requirements. A specific implementation of negotiation is described in more detail below.
  • the negotiation protocol describes whether the consumer entity's requirements are essential or negotiable.
  • the protocol also describes whether the monitoring entity can respond to the gateway synchronously or asynchronously.
  • the protocol also describes whether the response from the monitoring entity/agent provides the final result of negotiation in response to the requirements.
  • the consumer entity When a new consumer entity registers with the monitoring framework, the consumer entity sends a message with its preferences to the gateway or a supporting component that implements a negotiation algorithm.
  • the component that implements the negotiation algorithm determines whether the specified preferences can be supported.
  • the preferences are represented in an XML format document.
  • the preferences include the data format required, the resources to be monitored, the time interval between periodic sending of the data, and the actions to be taken during the system failure of a resource.
  • the negotiation component then sends a message to the monitoring entities selected by the selection algorithm informing them of the actions to be taken when the monitoring data for a given resource instance is not available.
  • the monitoring entities implement part of the negotiation algorithm. This part allows the monitoring entities to decide whether they can support the requested action and then (based on this decision) to inform the negotiation supporting component. If the monitoring entities cannot support the requested actions, the monitoring entities suggest another set of actions or action parameters. They carry out this assessment by applying a rule set to received action requests.
  • This negotiation part of a monitoring entity is referred
  • the monitoring description of an entity is used to identify the type of data/metric it is monitoring and at what interval and in which format.
  • a requirement description of a consumer identifies the required data, the required monitoring interval and the required data format. Also the requirement description specifies whether the required data is a derived data and, if so, provides an expression regarding how to compute the derived data from the existing data or metrics.
  • the gateway takes all these descriptions and matches the data based on its type, description, the interval and the format. If there is a match, whether partial or full, the gateway can trigger a negotiation or can bind the monitoring entity to the consumer.
  • the binding leads to a change in the repository data. Whenever a new monitoring entity or a new resource or a new consumer arrives, a binding document is created. Whenever there is change in any of the descriptions of consumer, monitoring entity or resource, the corresponding binding documents are updated.
  • a monitoring entity is forwarding data to two customers, and that the data represents a response time per customer for a resource “r”, with results bundled at a reporting frequency of 5 seconds.
  • the required monitoring data is response time per customer for this resource but at a frequency of 15 seconds as one bundle.
  • the monitoring entity may suggest to the consumer entity that the consumer entity accepts data bundles representing 5-seconds of monitoring and then combines these bundles to build a 15 second bundle of data. If such a negotiation is successful, the gateway may decide to send a remote monitor to the consumer entity's local node. This remote monitor would be responsible to collect these 5-second data bundles and then combine them into larger bundles.
  • the monitoring gateway upon successful negotiation, registers the consumer entity if the consumer entity is not registered already. The registration process includes creating connection bindings between the agent(s) and the consumer and updating the repository with this data.
  • Systems implementing the proposed framework may include components supporting authentication, negotiation, registration, de-registration, matching of monitoring data requirements, generating common sub-expressions for derived metrics across different consumers and/or monitoring agents. Additionally, installed components may enable finding of extraneous metrics being measured. Since there are well-developed algorithms in existence for performing all of these tasks, separate support modules can be used to encapsulate program code implementing the algorithms—avoiding the need to include such functions within in-line code of the gateways and monitoring entities. Such additional support modules may communicate with the monitoring gateway, repositories, monitoring layer and resource layer.
  • Metric List Optimizer receives any change in the metric lists for a resource type. If a resource supports more metrics (as per its monitoring description), but the required metrics are a subset of the currently active metric set, the Metric List Optimizer directs the corresponding monitoring entities (or the resource instances, if the instances are measuring some metrics) to stop measuring and monitoring those metrics.
  • new monitoring entities are controlled to measure this metric.
  • the monitoring entities are notified and instructed to commence monitoring.
  • a second supporting module is a Common Sub-Expression Finder (CSEF).
  • the CSEF component implements algorithms for finding common bundles or sub-expressions that can be computed across multiple monitoring entities.
  • the CSEF uses the repositories to determine the current monitoring topology (resource-monitoring-consumer) and to find the descriptions of each node.
  • the CSEF module applies the algorithms to find the common computation part and the associated nodes, and returns these two values to the requestor.
  • a third supporting module is a Registration Module, that is used to carry out registration and de-registration of consumers, monitoring entities and resource instances.
  • a registration Module that is used to carry out registration and de-registration of consumers, monitoring entities and resource instances.
  • a dependency graph is built and stored in the repository.
  • de-registration the corresponding dependency graph/sub-graph is removed.
  • repositories There are one or multiple repositories in the monitoring system. Some of the repositories are publicly accessible whereas other repositories are accessible only within the local system.
  • the publicly accessible repositories handle descriptions of monitoring for one type of resource, requirement descriptions of consumers, etc.
  • the internally accessible repositories handle data that is more frequently modifiable. They include documents describing bindings between consumers and monitoring agents and descriptions of monitoring entities. The latter include metrics, resource types and resource instances being monitored, the data format in which a monitoring entity is publishing data, and the format in which data is being sent to consumer entities.
  • the repositories also store the topology of the monitoring framework at a given point of time (consumer-monitoring-resource layers).
  • UDDI Universal Description, Discovery and Integration
  • XML-based registry technology that can be used for implementing a public repository.
  • UDDI is known for use to enable access to Web services.
  • One example repository is implemented as a relational database using IBM Corporation's DB2 database management software.
  • DB2 is a registered trademark of International Business Machines Corporation in the US and/or other countries.
  • Each resource has an entry in a table within the repository.
  • the table entry includes the XML document describing the resource.
  • Each monitoring entity and consumer also has such an entry, but in separate tables belonging to the group of monitoring entities and consumers respectively.
  • the graph is stored as a table in the repository.
  • a column contains the list of consumers for a monitoring entity and for each resource.
  • the table also contains a column for a list of monitoring entities monitoring a given resource.
  • a row of the table for a consumer contains the corresponding monitoring entities from which the consumer will receive data.
  • the resource layer comprises resources (resource instances), which can be monitored for certain metrics, system behaviours and faults, etc.
  • a resource can be a software resource or a hardware resource.
  • Software resources include computer programs of any kind, logical constituents of programs such as data structures, threads, processes, procedures and objects.
  • Hardware resources include a processing unit (CPU), data storage units providing system memory, disk storage or tape storage, and resources such as network connections.
  • Each resource has a description of the metrics which can be used to monitor the resource.
  • An XML-based example of such a description is shown in FIG. 4 .
  • the description includes:
  • the description may also include other information.
  • a resource could measure some, all or none of the metrics and make the measured data available to the monitoring layer as specified in the description.
  • the monitoring description of a resource is accessible publicly and is also dynamically modifiable.
  • a deployment manager or coordinator (implemented by the gateway in response to information from a resource manager) notifies the appropriate entities in the monitoring layer to start monitoring the instance and its underlying computing layer, if any. Management entities within the consumer layer are also notified about the new instance and the corresponding monitoring entities. The entities within the consumer layer then register with the new monitoring entities to receive data for some or all of the output metrics of the resource, in the resource's output format or a derived format.
  • a resource manager Upon shut-down of a resource instance, a resource manager notifies the gateway which directs all corresponding monitoring entities not to monitor the data for this instance and notifies all management/consumer layer entities to stop receiving monitoring data for this instance. Some of the monitoring entities may also be shut down to cancel monitoring of data which is no longer required by any consumer. Dynamic responses to changes in the set of currently active resources and changes in requirements of consumer entities can avoid wasting system resources on monitoring activity which is no longer required.
  • the resource instance can cancel measuring, reporting or supporting measurement of some previously supported metrics. Such a cancellation may be due to a fault in one of the components of a resource.
  • the ability to respond to faults in this way is advantageous for autonomic computing.
  • the resource instance can also add new metrics to be supported for measurement and reporting (which also has potential advantages for autonomic computing). Dynamic changes can also be made to the monitoring attributes for a particular metric (such as granularity of measurement, mode of monitoring data collection, etc). Such modifications or additions may be made during the runtime execution for a resource. Similarly an existing metric can be removed from being measured dynamically.
  • a metric that is added might be a newly-defined metric, or an existing defined metric that was not being measured or whose measurement was stopped and is now to be resumed.
  • a new metric may be introduced or the granularity of an existing metric may be changed in response to a new consumer entity at the consumer layer.
  • the mechanism used for collecting monitoring data may be changed dynamically by resources in case of a failure or changes in a resource. For example, data for an internal metric may be pulled instead of being pushed to the monitoring layer in response to a fault at the thread level.
  • the resource or the monitoring entity that initiates such a change dynamically notifies the gateway (and other monitoring layer entities) of the need to update the stored descriptions.
  • the monitoring layer entities then notify appropriate consumer entities that are dependent on the metrics that have been changed, added or removed.
  • a measurement mechanism of an existing metric is dynamically changed (such as from external measurement to internal measurement, or vice versa)
  • the description of monitoring metrics is changed accordingly. This change of a measurement mechanism can occur for a specific instance of a resource.
  • the monitoring layer also comprises components that measure metrics (although this is optional because measurement may be implemented by the resources), and components that collect data and report the monitoring data from monitoring entities or from other components of the monitoring layer.
  • a monitoring entity can be implemented by a computer program, a hardware component or as ‘firmware’. Each monitoring entity has its own data format for each metric for a resource.
  • An example monitoring entity is implemented as a computer program (for example, written in JavaTM, C or C++programming language).
  • the monitoring entity is capable of establishing network connections and communicating with other programs, resources and consumer entities.
  • the connectivity function is implemented using sockets.
  • the input to a monitoring entity is a monitoring description of each of the resource it is going to monitor.
  • the monitoring description can be written in Extensible Markup Language (XML), implementing the World Wide Web Consortium's (W3C's) Document Object Model (DOM) standard.
  • XML Extensible Markup Language
  • W3C's World Wide Web Consortium's
  • DOM Document Object Model
  • Each monitoring entity is a producer and a consumer of data and has access to all the monitoring descriptions of the resources it monitors at any point of time. It also has a list of metrics it monitors for each resource. It has the description of requirements (list of metrics and associated monitoring attributes per resource) from each of its consumers.
  • Each monitoring entity publishes its descriptions by sending them to the repositories. It also knows of its consumer and resource instance bindings. Upon receiving a change in monitoring description of a resource instance, the monitoring entity starts monitoring new metrics or starts monitoring metrics using new parameters (granularities, periods, addresses, etc), or stops monitoring metrics removed from the resources description. Upon receiving a change in the requirements description of a consumer, the monitoring entity or gateway decides what metrics are to be monitored and what metrics need not be monitored. The Metric List Optimizer component is notified of a new metric being required or an existing metric not being required. If there is no such component in the system, the monitoring entity can implement this function.
  • a monitoring entity receives a directive from a consumer or gateway to monitor a derived metric
  • the monitoring entity decides how to compute the derived metric.
  • the current monitoring agent requests the registration module to register the current monitoring agent as a consumer of required data output by the other monitoring agents.
  • the monitoring entities also implement bundling algorithms. Bundling technique is used to create a maximal bundle of data that can be sent to consumer(s) such that resource consumption in transmitting monitoring data to consumers is reduced. Below we have discussed some possible algorithms. However, it might be possible that there are multiple agents that need to generate same bundles of same data. There might be agents that are generating bundles of data (for 5 seconds) and another agent has to create bigger bundles (for 20 seconds). The second kind of agents would register themselves at the Registration Module as a consumer of these bundles at the agent(s). However, in order to find out if such common computations can be carried out at minimum number of places, the monitoring entities can request the CSEF to find out this.
  • the monitoring agent(s) stop computing that derived metric. If this means that they need not remain as consumers to some of the monitoring entities, then they would request the Registration Module to de-register themselves from the consumer list of other agents.
  • Each monitoring entity is capable of processing the monitoring data according to the data processing instructions of a consumer.
  • the entity can perform common processing (such as common sub-expression in compilers) across all consumers and then do consumer specific processing on top of it.
  • a monitoring entity implements the following algorithms:
  • metric “M” if derived data is required by a consumer, then compute the derived data for the predefined period (for a current cycle or previous cycles).
  • Each monitoring entity is capable of bundling the data according to the cycle(s) of one or more of the consumers, and sending the bundled data to the consumers. This can reduce bandwidth requirements.
  • bundling of monitoring data for reporting to consumer entities significantly improves the throughput of the system. For example, if each consumer entity in the management layer (that is, each ultimate consumer) has one or more dedicated monitoring entities, then the monitoring data can be bundled and reported according to a different reporting period than the monitoring period specified by the original data producer(s).
  • the monitoring entities can aggregate the data for the particular reporting period desired by the consumer.
  • a monitoring entity also implements the following algorithms:
  • a monitoring entity supports encryption techniques for sending data over network to a remote monitor or a consumer. Existing encryption techniques can be used for this purpose.
  • a monitoring entity can be a composite agent that produces composite monitoring metric out of the metrics of some resources. This agent is also described in the repositories such that it can be matched for during the matching and selection process for a consumer.
  • the composite agent receives the monitoring data of various resources from resource instances and/or other monitoring entities. Then it uses them to compute data for the composite metric.
  • the agent can use CSEF module to detect common computations that it can share with other entities and how to use common computations. Upon getting result from CSEF, it can register through registration module for the dependant monitoring entities.
  • the monitoring entity starts monitoring according to the new description. If a consumer registers with a monitoring entity with its description of requirements, then the monitoring entity starts reporting data to the consumer according to the requirements description.
  • the monitoring entities For monitoring data of high priority pushed from the measurement entity, the monitoring entities forward such data as soon as possible to the appropriate consumer(s).
  • the modified description is partially or completely available with the monitoring entities. If an existing monitoring metric is not required by any of the consumers, then the monitoring entity directs the corresponding measurement entity and/or the resource to stop its measurement and reporting. This action on the part of resource may get reflected in its monitoring description; if an existing metric is removed dynamically from being measured, it also gets removed dynamically from the monitoring description of the resource. Such a modification initiates a chain of actions later.
  • the management or consumer layer consists of components that use the monitoring data to carry out management and scheduling tasks, such as monitoring of composite services, metering and accounting, system behaviour analysis, SLA and QoS management, and logging.
  • a management entity can be a software program or a hardware component or firmware.
  • Each entity (a consumer) in this layer has a description of the requirements (as described in the monitoring layer section).
  • the requirement description of a consumer would specify the resource types, the metrics (both primitive and derived), granularities, period, cycle of data collection (bundling size) etc.
  • the description might include
  • Data processing instructions average monitoring data over some period of time.
  • derived metrics For derived metrics, corresponding expression based on primitive or other well-defined derived metrics has to be defined as part of this description.
  • the cycle per metric could be based on time or on number of requests, etc. For example, report monitoring data for resource R 1 , metric ‘CpuUtilization’ per customer with a period of 1 millisecond for last 5 seconds or last 100 requests.
  • the consumer Upon registering for receipt of monitoring data from the monitoring layer, the consumer passes the set of requirements to the appropriate entities in that layer. If required, the consumer in the management layer can modify the set of requirements dynamically. Such a modification gets propagated in the same or a different form to all the layers down to the resource layer or to the measurement entities.
  • the consumer entities access the monitoring description of this resource and pass their requirement description with respect to this resource across to the monitoring layer. This is essentially a modification of the requirement description of the consumer.
  • a monitoring entity may be sent to the local system or network of the consumer.
  • This monitoring entity takes the requirement description of associated consumer(s) as input, and receives data from other monitoring entities (as prescribed by the supporting modules). Based on the received information, the monitoring entity computes required data from the incoming data and data bundles in a format required by the consumer.
  • a remote monitor can be an engine for that language.
  • the gateway or the supporting modules must be able to read and understand the format/language in which the document is written.
  • One embodiment provides a subcomponent that implements the reading and parsing mechanism for particular document formats. If the language is a standard one, then the monitoring subsystem can use a generic subcomponent that can parse and read documents written in this language. For example if the language is based on Extensible markup language (XML), then Distributed Object Model (DOM) processing tools can be used.
  • XML Extensible markup language
  • DOM Distributed Object Model
  • the monitoring entities and external measuring entities can be implemented as software programs/agents. Each of a set of measuring entities external of a resource can be collected together on the same physical machine containing the resource(s). Each monitoring agent could be on a different machine.
  • the monitoring agents, measurement entities and resources may communicate through a publish/subscribe system and also through normal network communication mechanisms.
  • the monitoring description of a resource can be specified using an XML schema (as shown in FIG. 4 ) and similarly for requirement specifications. The descriptions would be available in a public repository. As soon as a description is modified, the modifying agent, consumer entity or resource notifies other agents through the publish/subscribe system. This information is also updated in the repository, unless it is a temporary state.
  • the resource manager Upon introduction of a new resource, the resource manager activates the measurement entities on that node and registers that instance(s) for being monitored at specific agent(s).
  • Interested consumers of management layer register themselves with agents with their requirement descriptions.
  • the agent(s) in turn retrieve the monitoring description and configuration of the resource instance/measurement entities and build a memory model of it for collecting monitoring data.
  • the agents would subscribe to topics to which measurement entities, resources and other agents publish metric values and resource states. They would also use socket connections and RPC to pull monitoring data from components in both monitoring and resource layer.
  • the management layer would be listening to topics in the publish/subscribe system.
  • An agent can also connect to a consumer through TCP connection for control messages or immediate status reports.
  • the agent For computation of derived data, the agent would implement one of the algorithms mentioned earlier or any other algorithms. For bundling of data, the agent can use any of the algorithms specified earlier or any other suitable algorithm. Supporting modules could implement a software version of the existing algorithms for authentication, matching, negotiation, registration. For negotiation, the monitoring agents also implement the negotiation protocol(s).
  • Each monitoring agent is local to a data processing unit or node within the network.
  • the MA is responsible for collection of monitoring data and communication of monitoring data to monitoring services.
  • An agent collects data for each service instance deployed on its local node. It also collects monitoring data about the ‘health’ of a node.
  • the health of a node denotes the load generated by all processes running on that system at a given point of time, the resource usage of the node (memory usage, cpu load, etc), and the load of each container (underlying computing software layers or middleware), if any, on that node.
  • Each raw data received/pulled by the agent for a service is parsed according to the format specified in the monitoring specification of that service.
  • Monitoring agents are capable of sending out notifications (fault-related, behavioural, etc) to appropriate monitoring services.
  • Each agent knows the addresses of monitoring services associated with it.
  • a monitoring agent supports interfaces enabling pulling of data.
  • Monitoring agents also support interfaces for modification of granularity/interval of data bundles, by monitoring services.
  • a monitoring service can be implemented for each Web service, a monitoring service for each node, and another monitoring service for all containers on all nodes.
  • a monitoring service is responsible for providing monitored data to the consumers, SLA measurement service, metering/accounting service, resource manager, etc.
  • Each consumer entity is likely to have a different granularity and interval at which the consumer entity expects monitoring data for a specific service ‘S’.
  • the consumer entity has the responsibility to specify this information (statically or dynamically) to the monitoring service for web service ‘S’.
  • Each monitoring service (MS) maintains a list of agents that are monitoring the associated service instances.
  • the MS directs the monitoring agents in its list to bundle and send the monitoring data at a granularity g and interval I. Values of “g” and “I” are such that the monitoring service can derive the granularities and intervals required by consumers from g and I.
  • a monitoring service bundles the monitoring data (from agents) and communicates each of the bundles to the appropriate consumer at appropriate point of time (based on the interval).
  • Each MS supports interfaces for pull of data by consumers.
  • a data pull by a consumer is propagated to the agent(s), if monitoring data does not possess the data with it or else it is served by the monitoring service itself.
  • a monitoring service immediately notifies the resource and workload managers.
  • a consumer notifies associated monitoring service(s) for any change in granularity g and interval I; monitoring service(s) in turn, notify associated monitoring agents about the change.
  • a service-specific monitoring service is responsible for data of one service, node monitoring service is responsible for data of all nodes and container monitoring service is responsible for data of all containers on all nodes.
  • resource manager Whenever a new service instance is deployed, resource manager notifies the monitoring service about the address of the monitoring agent on that node. If the service is new, prior to the notification, resource manager deploys a new monitoring service. If the node is new, resource manager notifies the node manager about its address. If there is a new container deployed on the node, it notifies the container monitoring service. Each monitoring service that gets notified, directs the monitoring agent to monitor the service instance and/or node and/or container and send the data bundled over a granularity g and interval I. Similarly when a service instance is to be terminated, a resource manager notifies the monitoring service to stop monitoring the instance. Monitoring service in turn directs the agent associated to stop monitoring the instance. Upon receiving the directive to monitor an instance, a monitoring agent imports the monitoring specification of the service, instantiates the monitoring links, if not available already, as per the specification and directive parameters provided by resource manager through monitoring service and then starts monitoring.
  • the corresponding monitoring service Upon dynamic modification of monitoring description of a web service, the corresponding monitoring service is notified along with the agents and the monitors. This is just a publish in the pub/sub system being used on a topic. The message contains the service name and the new monitoring description. The monitor then checks if its requirement description R is a subset of the new monitoring description S. If not, then it removes the entries specific to R-S and also tunes the granularity and period of monitoring towards the higher granularity (opposite of fine granularity).
  • systems according to one embodiment of the invention enable dynamic registration of new consumers for monitoring data, or de-registration of old consumers to stop them receiving monitoring data.
  • Existing consumers may be able to dynamically modify their requirements of monitoring data. For example, a new SLA may be added due to dynamic SLA negotiation, which could lead the SLA to receive data for some new metrics or to receive data at a different granularity level.
  • some faults may prevent a sub-component of a resource from being able to measure and/or report the data to a consumer. If this state continues for a long period of time, then the consumers that are waiting for the data need to be informed of the non-availability of such data. In this case, there is dynamic change in the monitoring metrics being measured/monitored on a per-resource-instance basis. Similarly the requirements of a consumer might change dynamically based on the dynamic states of resources or external requirements.
  • Dynamic registration of consumers for monitoring data raises another issue: the need for matching of the requirements of the consumer with the available monitoring data from each agent, selection of a suitable monitoring agent(s) and binding the new consumer with the agent(s). Dynamic changes in the metrics being monitored or the granularity or period at which the metrics are being monitored for a resource adds another dimension, since such a change may lead to the changes in the requirements of the consumer or the bindings to the monitoring agents.
  • the present invention mitigates one or more of the problems or limitations of known systems, and in one embodiment provides a monitoring framework that facilitates monitoring of both external and internal metrics for a system or network comprising heterogeneous resources.
  • the framework supports static and dynamic registration and de-registration of resources and consumers of the monitoring data.
  • the framework also supports dynamic changes to the monitoring description of a resource and of a resource instance, enabling consumers to dynamically modify their requirements description.
  • the framework makes it possible to improve upon resource utilization, computation and communication of monitoring data while supporting multiple consumers for their desired metrics at the desired granularity and desired monitoring periods.

Abstract

Methods, apparatus and computer programs are described for monitoring resources within a data processing network. Monitoring entities can be selected, and a set of active monitoring functions can be modified, based on the requirements of consumers of monitored data. A first method involves monitoring resources on behalf of consumer entities within the network. A description of the consumer entity's monitoring requirements are published by the consumer entity and stored in a repository. The monitoring requirements of the consumer entity are compared with the monitoring capabilities of a plurality of monitoring entities, to identify a monitoring entity capable of satisfying the monitoring requirements of the consumer entity. An identified monitoring entity is selected, and a connection is established between the selected monitoring entity and the consumer entity. A second method involves modifying an active set of monitoring functions in response to changes to monitoring requirements of a currently active set of consumer entities.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • This application is a Division of U.S. Application Ser. No. 10/732,736 filed Dec. 10, 2003, the complete disclosure of which, in its entirety, is herein incorporated by reference.
  • FIELD OF THE INVENTION
  • The present invention relates to systems, methods and computer programs for monitoring distributed resources.
  • BACKGROUND
  • A distributed data processing system typically includes a combination of hardware and software resources. The hardware resources may include a processor, a data storage unit, an input/output device, a network router, network link, etc. The software or ‘logical’ resources may include any computer program or program component, or a service provided by a hardware or software resource.
  • Monitoring of distributed systems is necessary for many purposes, including resource management, workload management (including load balancing and admission control), management of Quality of Service (QoS) and Service Level Agreements (SLAs), metering and accounting of system usage, fault detection and recovery and consistency management.
  • Monitoring of a distributed system typically comprises three steps: measurement of metrics and/or determination of the current state of a resource, collection of this data and reporting the collected data either as it is or in some processed manner to appropriate consumers. Based on measurement techniques, two different types of monitoring metrics can be differentiated: externally measurable metrics and internally measurable metrics. Certain types of parameters can be measured by measurement components external of the system, whereas resource-specific internal parameters can only be measured internally or in some cases also by the underlying computing layer such as an operating system.
  • Externally measurable parameters are generally used for determining the state of resources such as their availability, measuring performance such as throughput or response time, measuring usage of external resources such as network bandwidth, and for evaluation of QoS parameters. Internally measured parameters are used for determining resource utilization such as the number of threads used from a total number of available threads, identification of faults, and determination of resource usage at a given granularity level (per customer, request or process). The faults detected by internal measurement/monitoring may not be directly visible from the behaviour of the resource or system or from the values of external parameters. However, such faults may lead to reduced performance without a complete resource or system failure.
  • Factors such as granularity of measurement and the period between measurements are associated with each metric. The granularity of measurement may be per node, per container (containing one or more resource instances), per instance of the resource, per customer, or per request. The interval between periodic measurement of a parameter can be uniform along a time axis or non-uniform. The type of metric and factors such as granularity and period may determine where and how a metric should be measured—either by the resource internally, or by a separate computing layer or external measurement entity. Collection and reporting of monitoring data may be dependent on the granularity and period of measurement. Monitoring entities may process the collected data to generate monitoring data in the form required by the consumers.
  • There is a need for systems and methods that enable monitoring of both internal and externally measurable parameters. For example, there is a need for autonomic systems which can measure internal parameters for self-diagnosis and self-healing. In some cases self-healing or self-diagnosing may be impossible and so there is a need to support reporting of such parameters to external managers.
  • In some systems, internal parameters may be essential for metering and accounting of resource usage. Therefore, monitoring of such metrics is important for grid computing and autonomic computing, in addition to other computing paradigms that perform accounting functions based on resource-usage. Apart from metering and accounting, internal parameters are very useful in optimizing QoS objective functions, in resource management, in workload management, in studying system behaviours and correlating internal resource usage to the externally measurable parameter values. For example, in order to reduce the response time of a customer, the resource manager might have to increase the number of threads of the component. This is possible only if the manager knows about the internal load of the component in terms of thread usage.
  • Similarly, there is a need for measurement and reporting of internal parameters at the desired granularity level and desired period between measurements, in order to measure the resource usage of a component and to account for and bill the customer for the usage, to derive usage statistics, and to deliver such usage statistics to resource managers and SLA or QoS managers.
  • Many existing systems do not have sufficient flexibility to enable monitoring of service-dependent and internal metrics at granularities and periods according to the requirements of different consumers.
  • SUMMARY
  • Aspects of the present invention provide methods, apparatus and computer programs for monitoring resources within a data processing network. Monitoring entities can be selected, and a set of active monitoring functions can be modified, based on the requirements of consumers of monitored data.
  • A first embodiment of the invention provides a method for monitoring resources of a data processing network on behalf of consumer entities within the network. The method includes determining the monitoring requirements of a consumer entity (such as by reference to a description of requirements published by the consumer entity). The monitoring requirements of the consumer entity are compared with the monitoring capabilities of a plurality of monitoring entities, to identify at least one monitoring entity having monitoring capabilities matching (partially or completely) the monitoring requirements of the consumer entity. One or more of the monitoring entities identified as having monitoring capabilities matching the monitoring requirements of the consumer entity is then selected, and a connection is established between the selected monitoring entity and the consumer entity.
  • The consumer entity is one of a computer program, a Web service provider, a logical representation (for example, instance of an object class) of an end user, or any physical or logical component of the data processing network which requires monitoring information. Examples of consumer entities are programs implementing resource management functions, implementing load balancing functions, or implementing functions for metering and accounting of resource usage.
  • The monitoring entities are typically computer program components that perform monitoring functions, although monitoring entities may be implemented in hardware or ‘firmware’. Monitoring entities can establish connections to other components, receive and collect output data from a resource, and report the collected data to a consumer entity.
  • The compared capabilities of the monitoring entities may include one or more of the following: the set of resources currently being monitored by the monitoring entity; the set of resources which the monitoring entity is capable of monitoring; the monitoring metrics which the monitoring entity is currently monitoring; the monitoring metrics which the monitoring entity is capable of monitoring; the current granularity of monitoring; the granularity capability of the monitoring entity; the current monitoring period; the monitoring entity's monitoring period capability; and the data format capabilities of the monitoring entity.
  • Thus, selection of a monitoring entity may be based on currently active monitoring functions and attributes, and may involve comparing identifiers of the subset of resources and metrics currently being monitored by monitoring entities. Alternatively, selection may be based on the super-set of monitoring capabilities comprising both active and currently inactive monitoring capabilities of the monitoring entities. Selection may involve consideration of the granularity and length of monitoring period desired by the consumer and provided by the monitoring entities. Embodiments of the invention enable selection of monitoring entities for monitoring internal and external monitoring data.
  • The determining, comparing, selecting and binding may be performed at run-time in response to addition of a new consumer entity or a change of consumer requirements.
  • According to one embodiment of the invention, the comparison uses descriptions of each consumer entity's, monitoring entity's and resource's produced or required data and its data format. The descriptions are published by the resources, monitoring entities and currently active consumer entities, and are held in one or more repositories. The descriptions of the monitoring entities include which resource instances they are monitoring, which metrics they are monitoring and reporting, and the data format in which they report monitoring data. The repositories also hold a description of the topology of the monitoring system. This topology information includes a list of bindings representing which resources are currently being monitored by which monitoring entities and which consumer entities are connected to receive data from which monitoring entities. When resource instances, monitoring entities or consumer entities change, the lists and descriptions within the repositories are updated dynamically.
  • A further embodiment of the invention provides a method for monitoring resources of a data processing system, which includes modifying a currently active set of monitoring functions. The method includes identifying the monitoring requirements of a currently active set of consumer entities, and determining whether a currently active set of monitoring functions of monitoring entities are consistent with the monitoring requirements of the currently active set of consumer entities. If a determination is made that the currently active set of monitoring functions are inconsistent with the monitoring requirements of the currently active set of consumer entities, modifications are made to the active set of monitoring functions.
  • The modification of the currently active set of monitoring functions may involve: controlling a currently active monitoring entity to monitor additional monitoring metrics or to monitor metrics at a different granularity or interval periods; activating an inactive monitoring entity; or deactivating a monitoring function or monitoring entity which is monitoring metrics that are not required by the currently active set of consumers. Such modifications enable dynamic response to the requirements of individual consumer entities. By enabling de-activation of inactive functions or entities, more efficient use of data processing resources is possible.
  • A further embodiment of the present invention provides a data processing system for monitoring resources of a data processing network. The data processing system includes a data processing unit and a data storage unit for storing monitoring capabilities of each of a set of monitoring entities. The system also includes a monitoring manager which is responsive to monitoring requirements of a data consumer entity. The monitoring manager compares the monitoring requirements of the data consumer entity with monitoring capabilities of monitoring entities stored in the data storage unit. The monitoring manager identifies and then selects a monitoring entity or a set of monitoring entities having monitoring capabilities matching the monitoring requirements of the data consumer entity.
  • A monitoring framework comprising a set of monitoring components may be provided at an intermediate layer of a data processing network, between consumers of monitoring data and monitored resources. A monitoring system according to one embodiment of the invention includes at least one gateway component which implements the monitoring manager functions such as handling registration and deregistration of components. The gateway component may support authentication of consumers, and initiate selection of an appropriate monitoring entity (or set) for each consumer entity. The selection may include negotiation between consumers and monitoring entities regarding the monitoring data to be provided (such as when specific requirements cannot be met at a particular point in time). The gateway also initiates binding of monitoring entities to consumer entities.
  • Upon successful binding between a consumer entity and a monitoring entity, the gateway publishes a description of the binding which is stored within a repository. In alternative embodiments, the matching or selection and binding could be implemented by the monitoring entities instead of the gateway, and functions such as authentication can be performed by additional support modules.
  • A negotiation between a consumer entity and monitoring entities may specify the action to take when a required metric cannot be monitored for a specific resource during a specific period. Negotiation may involve determining whether a consumer entity's required monitoring QoS parameters can be satisfied by the currently active set of monitoring functions, or by the currently active set of monitoring entities, or by activating new monitoring entities. Monitoring entities may be started at the consumer side to handle re-formatting or other transformation of monitoring data.
  • A monitoring control method can be used to determine optimal (minimized) computation to generate required data from raw measured data, and optimal transmission frequency, for efficient resource utilization while taking account of the requirements of the consumer entities. For example, de-registration of a consumer entity may result in a determination that certain monitored metrics are no longer required by any consumer entity such that their monitoring (measurement, collecting and reporting) can be stopped. Selection of a monitoring entity may take account of which of a plurality of monitoring entities can achieve a best match.
  • Embodiments of the invention may be implemented using computer programs to implement one or more components of the invention. For example, a selector for comparing monitoring requirements with monitoring capabilities to select a monitoring entity, or to modify the active monitoring functions or entities, may be implemented in computer program code. The above-described gateways, monitoring entities and support modules may be implemented in program code. The program code may be made available as a computer program product in which the program code is recorded on a recording medium or is made available via a data transfer medium.
  • BRIEF DESCRIPTION OF DRAWINGS
  • Embodiments of the present invention are described below in detail, by way of example, with reference to the accompanying drawings in which:
  • FIG. 1 is a schematic representation of a monitoring architecture according to an embodiment of the invention;
  • FIG. 2 is a schematic representation of a data processing system including a monitoring subsystem according to an embodiment of the invention;
  • FIG. 3 is a flow diagram showing steps of a monitoring method according to an embodiment of the invention; and
  • FIG. 4 is an example of an XML monitoring description for a service, according to an embodiment of the invention
  • DETAILED DESCRIPTION OF EMBODIMENTS
  • Described below with reference to FIG. 1 is an exemplary monitoring framework and method implementing the present invention. A number of resources 10, consumer entities 20 and monitoring entities 30 within a network publish a description of the data they produce, the data they receive and the data formats they support. In the case of a data consumer entity, the description comprises a set of monitoring requirements. In the case of a monitoring entity, the description comprises a set of capabilities and an identification of the subset of currently active capabilities (monitoring functions and their configuration attributes). The monitoring requirements and capabilities are compared by a monitoring gateway, or a negotiation between components, to select suitable monitoring entities to perform required monitoring functions on behalf of consumer entities.
  • A resource may be an instance of a computer program such as a Web service component, or an instance of a database. A hardware resource may be a network link, data storage or system memory. As described earlier, consumer entities may be running instances of computer programs or any logical or physical component which requires monitoring data. Monitoring entities and other components of the network are described in detail below.
  • Referring to FIG. 1, the monitoring framework can be represented by a layered model, in which a set of data producing resources 10 form a first resource layer A, a set of monitoring entities 30 and cooperating components 40, 50, 60, 80 form a second monitoring layer B and a set of final data consumers 20 form a third management layer C. The monitoring framework implemented as a monitoring layer B is distributed across a number of data processing systems within the network. Each of the data processing systems which includes a resource to be monitored typically also includes one or more components of the monitoring framework. Remote monitors 40 may also be provided elsewhere in the network.
  • The descriptions of outputs, requirements and capabilities are sent by each of the resources 10, consumer entities 20 and monitoring entities 30 to one or more monitoring gateways 50 which store the descriptions within repositories 60 within the monitoring layer. A number of support modules 80 may be provided to implement support functions that are generic to a number of monitoring entities.
  • It will be apparent to a person skilled in the art that individual steps of the methods described below can be performed under the control of computer program code and that a variety of programming languages and coding implementations may be used to implement the methods and components described herein. Such computer programs are not intended to be limited to the specific example control flows described below, and steps described as if performed sequentially may be performed in parallel (and vice versa). One or more of the operations described in the context of a computer-program-controlled implementation could alternatively be performed by a hardware electronics component.
  • Some portions of the following description refer to ‘algorithms’ for performing operations on data within a computer memory. An algorithm is conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is frequently convenient to refer to these signals as bits, values, elements, characters, numbers, or the like. It should be borne in mind, however, that the above and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, discussions within the present specification utilising terms such as “computing”, “calculating”, “determining”, “comparing”, “generating”, “selecting”, “outputting”, or the like, refer to the action and processes of a computer system, or similar electronic device, that manipulates and transforms data represented as physical (electronic) quantities within the registers and memories of the computer system into other data similarly represented as physical quantities within the computer system memories or registers, or other such information storage, transmission or display devices.
  • The present specification also discloses apparatus for performing the operations of the methods, including components of a monitoring subsystem and a distributed monitoring framework. Apparatus for implementing the invention may be specially constructed for the required purposes, or may comprise one or more general purpose computers or other devices selectively activated or reconfigured by computer programs stored in the computers or devices. The algorithms and methods described below are not inherently related to any particular computer hardware or other hardware apparatus. Various general purpose machines may be used with programs in accordance with the teachings herein. Alternatively, the construction of more specialised apparatus to perform the required method steps may be appropriate.
  • In addition, the present specification discloses a computer readable medium for storing a computer program for performing the operations of the methods. The computer readable medium is taken herein to include any transmission medium for communicating the computer program between a source and a destination. The transmission medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a general purpose computer. The transmission medium may also include a hard-wired medium such as exemplified by typical Internet-connected server computers, or a wireless medium such as exemplified in the GSM mobile telephone system.
  • Where steps or features in any of the accompanying drawings are referenced by the same reference numerals, those steps and/or features have the same or similar functions or operations in the context of the present description (unless the contrary intention appears).
  • FIG. 2 shows an example data processing system in which the present invention is implemented. The system includes a number of resource instances 10 which can be monitored, and a monitoring subsystem 70 including a number of monitoring entities 30. Communication between the various components is implemented using sockets, and is synchronous.
  • A monitoring gateway 50 within the monitoring subsystem 70 is responsible for authentication, registration and deregistration of consumers, as well as updating the repository 60. In particular, the gateway 50 stores published requirements and capabilities information in the repository, including a list of resources being monitored, the monitoring descriptions of the resources, and monitoring descriptions of consumer entities and monitoring entities. The monitoring descriptions of monitoring entities include an identification of resource instances being monitored, identification of the metrics being monitored and reported on, and the reporting data format. In response to a change in resource instances, monitoring entities or a consumer entity, the repository is updated.
  • There may be a plurality of repositories 60 storing different types of information within a single data processing system's monitoring subsystem 70, and there may be a plurality of repositories distributed across a plurality of monitoring systems of a distributed monitoring framework. In an embodiment providing remote access to the repositories, individual consumer entities or gateways running on one of the systems within the network can collaborate to provide access to data within the distributed set of repositories. This enables identification of remote monitoring entities as well as monitoring entities which are local to the resource to be monitored. References to ‘a repository’ hereafter are intended to include the possibility of multiple repositories.
  • In a first embodiment, the gateway 50 is responsible for matching the current monitoring requirements of consumer entities and the currently available monitoring data and/or monitoring capabilities of monitoring entities. In other embodiments, or when no perfect match is identified, the gateway serves as an intermediary enabling negotiation between consumer entities and monitoring entities based on Quality of Service (QoS) parameters of the consumer entities and monitoring entities to select monitoring entities that provide a best fit for the monitoring requirements of a consumer entity. The gateway 50 also handles binding of consumer entities to monitoring entities.
  • When a new consumer entity joins the monitoring system, the consumer entity registers with a gateway and is then bound to a set of one or more monitoring entities. The gateway receives the request from the consumer with its requirements document in XML. The binding steps are:
  • 1. The gateway carries out matching, selection and/or negotiation.
  • 2. The gateway then sends messages to each selected monitoring agent. The message contains the requirement document (or part of the information from the requirement document). The selected monitoring agents then configure themselves to start monitoring and sending monitoring data to the consumer entities.
  • 3. Upon receiving confirmations from all selected monitoring agents, the gateway creates an XML binding document for the consumer entity. This binding document contains a list of resources being monitored, the monitoring entities and interconnections between them, and the data format which they use to monitor and report data.
  • 4. The gateway then saves this binding document in the repository as part of a binding table. The key for accessing a binding document within the binding table is the consumer name.
  • Other systems within the network do not necessarily include all of the monitoring framework components shown in FIG. 2. For example, a system may include one or more monitoring entities 30 but access a monitoring gateway 50 and repository 60 running on a different system.
  • In alternative embodiments of the invention, the comparison of monitoring requirements, currently available monitoring data and capabilities, and the selection of monitoring entities 30 based on this comparison, is implemented within the monitoring entities 30 or within additional supporting modules 80, and the gateway 50 can rely on separate service provider components for authentication and other functions.
  • Monitoring steps according to a specific embodiment of the invention are described below with reference to FIG. 3.
  • In the present embodiment, start-up of the monitoring subsystem 70 initiates 100 monitoring of a number of resources based on current configuration settings of the monitoring subsystem. A set of monitoring entities 30 are initially bound to the resources 10 in accordance with the configuration settings, and these monitoring entities collect data from appropriate addresses within the system and report the data to any consumer entities 20 that have been registered as having a requirement for the data.
  • When a new consumer entity joins the monitoring system, the gateway 50 performs authentication of the consumer entity and the consumer entity publishes 110 its requirement description to the gateway 50. The gateway stores 120 the description in a repository 60.
  • As described above, the gateway 50 enables selection 130,140 of monitoring entities 30 according to the specific, and possibly changing, monitoring requirements of consumer entities. In embodiments in which negotiation is implemented, the gateway initiates a process of negotiation 140 between the consumer entity 20 and the monitoring entities 30 and resources 10 within the monitoring and resource layers of the network. In embodiments in which negotiation is not implemented, the gateway 50 typically serves as a selector—using a comparison process 130 to match monitoring requirements, monitoring capabilities and active functions and QoS parameters of consumer entities.
  • The gateway, or a negotiation initiated by the gateway, identifies 140 the best set of monitoring entities to act as a set of sources of monitoring data for the consumer, and the gateway binds 140 the selected set of monitoring entities to the consumer entity. The monitoring entities may respond 150 to instructions from the gateway to configure itself to commence monitoring of new metrics if they are not currently being monitored and are required by a consumer entity. Upon successful binding between the monitoring entities and the consumer entity, the gateway publishes a binding document to the repository (as described above).
  • If the gateway determines that appropriate monitoring entities are not locally available or that the consumer entity requires services provided by a specific remote monitoring entity, the gateway may invoke a monitoring entity on another system in the network. For example, a remote monitor may be required to receive the monitoring data and adapt the data to a required format. The gateway (or in other embodiments the monitoring agents) handles selection of the bundling size, the frequency at which data is communicated to consumer entities, and determines the minimal computation model for the derived metrics.
  • If an existing consumer decides to de-register, the gateway unbinds the consumer's monitoring entities from the consumer entity to stop reporting of data by the monitoring entities, removes the binding document from the repository, and de-registers the consumer from the gateway. Additional actions may be taken at the monitoring subsystem level in response to this de-registration, including identifying those metrics output by a resource which are no longer required by any consumer entity. Monitoring of such metrics can then be stopped in order to improve resource utilization—reducing the total processing overhead associated with monitoring.
  • Each component in the monitoring framework has a description of its monitoring metrics and other details associated with producing and/or consuming a metric (such as the output format or required input format, methods by which the data can be collected, methods by which the data is reported, etc). A component that is both a producer and consumer possesses separable descriptions relating to its production and consumption of data.
  • The description of requirements published by a consumer entity may be used to coordinate processing by one or more monitoring entities, to receive monitored data from other entities in the monitoring and resource layers of the system and to process the received data to produce an output in the format expected by the consumer entity.
  • The following description provides further details of the above-described components of the monitoring framework of FIGS. 1 and 2, and methods of working the components for monitoring distributed resources.
  • Monitoring Gateway
  • The framework comprises a set of one or more monitoring gateways. Each gateway has access to the monitoring description of resources and monitoring entities, and the requirement descriptions of currently active consumer entities. A monitoring gateway may also use supporting modules for authentication, negotiation, matching of requirements to monitoring data availability, registration of consumers and de-registration. According to the present embodiment, all of these functions are either performed by the gateway or coordinated by the gateway.
  • To use the monitoring framework, a new consumer entity must register with the framework, by contacting one of the monitoring gateways. The contacted monitoring gateway handles authentication of a consumer entity (or instructs another component to do so). Known authentication algorithms can be used. Once the consumer entity is authenticated, the gateway starts a selection process on behalf of the consumer entity and monitoring entities. The monitoring gateway compares monitoring requirements of the consumer entity with capabilities of monitoring entities and selects a set of monitoring entities that are suitable to provide the required data. The monitoring gateway then forwards the consumer entity's requirements and a description of a dynamic negotiation protocol to the selected monitoring entities. The monitoring entities employ the described dynamic negotiation protocol to select monitoring attributes (such as metrics, granularity, period) to match the consumer entity's requirements. A specific implementation of negotiation is described in more detail below. The negotiation protocol describes whether the consumer entity's requirements are essential or negotiable. The protocol also describes whether the monitoring entity can respond to the gateway synchronously or asynchronously. The protocol also describes whether the response from the monitoring entity/agent provides the final result of negotiation in response to the requirements.
  • When a new consumer entity registers with the monitoring framework, the consumer entity sends a message with its preferences to the gateway or a supporting component that implements a negotiation algorithm. The component that implements the negotiation algorithm then determines whether the specified preferences can be supported. The preferences are represented in an XML format document. The preferences include the data format required, the resources to be monitored, the time interval between periodic sending of the data, and the actions to be taken during the system failure of a resource. The negotiation component then sends a message to the monitoring entities selected by the selection algorithm informing them of the actions to be taken when the monitoring data for a given resource instance is not available. The monitoring entities implement part of the negotiation algorithm. This part allows the monitoring entities to decide whether they can support the requested action and then (based on this decision) to inform the negotiation supporting component. If the monitoring entities cannot support the requested actions, the monitoring entities suggest another set of actions or action parameters. They carry out this assessment by applying a rule set to received action requests. This negotiation part of a monitoring entity is referred to hereafter as a rules processing engine.
  • The monitoring description of an entity is used to identify the type of data/metric it is monitoring and at what interval and in which format. A requirement description of a consumer identifies the required data, the required monitoring interval and the required data format. Also the requirement description specifies whether the required data is a derived data and, if so, provides an expression regarding how to compute the derived data from the existing data or metrics. The gateway takes all these descriptions and matches the data based on its type, description, the interval and the format. If there is a match, whether partial or full, the gateway can trigger a negotiation or can bind the monitoring entity to the consumer. The binding leads to a change in the repository data. Whenever a new monitoring entity or a new resource or a new consumer arrives, a binding document is created. Whenever there is change in any of the descriptions of consumer, monitoring entity or resource, the corresponding binding documents are updated.
  • As an example, let us assume that a monitoring entity is forwarding data to two customers, and that the data represents a response time per customer for a resource “r”, with results bundled at a reporting frequency of 5 seconds. For a consumer entity “s”, the required monitoring data is response time per customer for this resource but at a frequency of 15 seconds as one bundle. As part of negotiation, the monitoring entity may suggest to the consumer entity that the consumer entity accepts data bundles representing 5-seconds of monitoring and then combines these bundles to build a 15 second bundle of data. If such a negotiation is successful, the gateway may decide to send a remote monitor to the consumer entity's local node. This remote monitor would be responsible to collect these 5-second data bundles and then combine them into larger bundles. The monitoring gateway, upon successful negotiation, registers the consumer entity if the consumer entity is not registered already. The registration process includes creating connection bindings between the agent(s) and the consumer and updating the repository with this data.
  • Supporting Modules
  • Systems implementing the proposed framework may include components supporting authentication, negotiation, registration, de-registration, matching of monitoring data requirements, generating common sub-expressions for derived metrics across different consumers and/or monitoring agents. Additionally, installed components may enable finding of extraneous metrics being measured. Since there are well-developed algorithms in existence for performing all of these tasks, separate support modules can be used to encapsulate program code implementing the algorithms—avoiding the need to include such functions within in-line code of the gateways and monitoring entities. Such additional support modules may communicate with the monitoring gateway, repositories, monitoring layer and resource layer.
  • One supporting module is a Metric List Optimizer. This component receives any change in the metric lists for a resource type. If a resource supports more metrics (as per its monitoring description), but the required metrics are a subset of the currently active metric set, the Metric List Optimizer directs the corresponding monitoring entities (or the resource instances, if the instances are measuring some metrics) to stop measuring and monitoring those metrics.
  • However, if a new metric is to be monitored for a resource type, new monitoring entities are controlled to measure this metric. The monitoring entities are notified and instructed to commence monitoring.
  • A second supporting module is a Common Sub-Expression Finder (CSEF). The CSEF component implements algorithms for finding common bundles or sub-expressions that can be computed across multiple monitoring entities. The CSEF uses the repositories to determine the current monitoring topology (resource-monitoring-consumer) and to find the descriptions of each node. The CSEF module applies the algorithms to find the common computation part and the associated nodes, and returns these two values to the requestor.
  • A third supporting module is a Registration Module, that is used to carry out registration and de-registration of consumers, monitoring entities and resource instances. In case of a new registration, a dependency graph is built and stored in the repository. In the case of de-registration, the corresponding dependency graph/sub-graph is removed.
  • Repository
  • There are one or multiple repositories in the monitoring system. Some of the repositories are publicly accessible whereas other repositories are accessible only within the local system. The publicly accessible repositories handle descriptions of monitoring for one type of resource, requirement descriptions of consumers, etc. The internally accessible repositories handle data that is more frequently modifiable. They include documents describing bindings between consumers and monitoring agents and descriptions of monitoring entities. The latter include metrics, resource types and resource instances being monitored, the data format in which a monitoring entity is publishing data, and the format in which data is being sent to consumer entities. The repositories also store the topology of the monitoring framework at a given point of time (consumer-monitoring-resource layers).
  • Database systems and indexing techniques can be used to implement the repositories. Universal Description, Discovery and Integration (UDDI) is an example XML-based registry technology that can be used for implementing a public repository. UDDI is known for use to enable access to Web services.
  • One example repository is implemented as a relational database using IBM Corporation's DB2 database management software. DB2 is a registered trademark of International Business Machines Corporation in the US and/or other countries. Each resource has an entry in a table within the repository. The table entry includes the XML document describing the resource. Each monitoring entity and consumer also has such an entry, but in separate tables belonging to the group of monitoring entities and consumers respectively. There is also a graph structure that represents the interconnection between monitoring agents (or entities), consumers and resources. This graph can be modified dynamically. The graph is stored as a table in the repository.
  • As a new consumer or resource or monitoring entity joins the system, a corresponding row is created in the table. A column contains the list of consumers for a monitoring entity and for each resource. The table also contains a column for a list of monitoring entities monitoring a given resource. A row of the table for a consumer contains the corresponding monitoring entities from which the consumer will receive data.
  • Resource
  • The resource layer comprises resources (resource instances), which can be monitored for certain metrics, system behaviours and faults, etc. A resource can be a software resource or a hardware resource. Software resources include computer programs of any kind, logical constituents of programs such as data structures, threads, processes, procedures and objects. Hardware resources include a processing unit (CPU), data storage units providing system memory, disk storage or tape storage, and resources such as network connections.
  • Each resource has a description of the metrics which can be used to monitor the resource. An XML-based example of such a description is shown in FIG. 4.
  • The description includes:
  • Metric being/to be measured;
  • Methods available to collect and report the metric values (such as push/pull mechanisms, and specific information regarding the push or pull address);
  • Granularity of metric measurement and reporting;
  • Period of metric measurement and reporting;
  • Data type or format (in which the monitored data can be made available for collection);
  • A mechanism or API for use to start, stop and control measurement and reporting activity, granularity, period, etc.
  • The description may also include other information.
  • A resource could measure some, all or none of the metrics and make the measured data available to the monitoring layer as specified in the description. The monitoring description of a resource is accessible publicly and is also dynamically modifiable.
  • If a new resource instance is deployed, the metric description of the resource instance is made accessible. A deployment manager or coordinator (implemented by the gateway in response to information from a resource manager) notifies the appropriate entities in the monitoring layer to start monitoring the instance and its underlying computing layer, if any. Management entities within the consumer layer are also notified about the new instance and the corresponding monitoring entities. The entities within the consumer layer then register with the new monitoring entities to receive data for some or all of the output metrics of the resource, in the resource's output format or a derived format.
  • Upon shut-down of a resource instance, a resource manager notifies the gateway which directs all corresponding monitoring entities not to monitor the data for this instance and notifies all management/consumer layer entities to stop receiving monitoring data for this instance. Some of the monitoring entities may also be shut down to cancel monitoring of data which is no longer required by any consumer. Dynamic responses to changes in the set of currently active resources and changes in requirements of consumer entities can avoid wasting system resources on monitoring activity which is no longer required.
  • During run-time of a resource instance, the resource instance can cancel measuring, reporting or supporting measurement of some previously supported metrics. Such a cancellation may be due to a fault in one of the components of a resource. The ability to respond to faults in this way is advantageous for autonomic computing. The resource instance can also add new metrics to be supported for measurement and reporting (which also has potential advantages for autonomic computing). Dynamic changes can also be made to the monitoring attributes for a particular metric (such as granularity of measurement, mode of monitoring data collection, etc). Such modifications or additions may be made during the runtime execution for a resource. Similarly an existing metric can be removed from being measured dynamically.
  • Following modifications to the monitoring description of a resource, communication among the appropriate entities in the three layers (resource layer, monitoring layer and consumer layer) is established in order to have consistent requirements descriptions for the consumer(s).
  • A metric that is added might be a newly-defined metric, or an existing defined metric that was not being measured or whose measurement was stopped and is now to be resumed. A new metric may be introduced or the granularity of an existing metric may be changed in response to a new consumer entity at the consumer layer. The mechanism used for collecting monitoring data may be changed dynamically by resources in case of a failure or changes in a resource. For example, data for an internal metric may be pulled instead of being pushed to the monitoring layer in response to a fault at the thread level.
  • The resource or the monitoring entity that initiates such a change dynamically notifies the gateway (and other monitoring layer entities) of the need to update the stored descriptions. The monitoring layer entities then notify appropriate consumer entities that are dependent on the metrics that have been changed, added or removed.
  • If a measurement mechanism of an existing metric is dynamically changed (such as from external measurement to internal measurement, or vice versa), the description of monitoring metrics is changed accordingly. This change of a measurement mechanism can occur for a specific instance of a resource.
  • Monitoring Entity/Agent
  • The monitoring layer also comprises components that measure metrics (although this is optional because measurement may be implemented by the resources), and components that collect data and report the monitoring data from monitoring entities or from other components of the monitoring layer. A monitoring entity can be implemented by a computer program, a hardware component or as ‘firmware’. Each monitoring entity has its own data format for each metric for a resource.
  • An example monitoring entity is implemented as a computer program (for example, written in Java™, C or C++programming language). The monitoring entity is capable of establishing network connections and communicating with other programs, resources and consumer entities. The connectivity function is implemented using sockets. The input to a monitoring entity is a monitoring description of each of the resource it is going to monitor. The monitoring description can be written in Extensible Markup Language (XML), implementing the World Wide Web Consortium's (W3C's) Document Object Model (DOM) standard. Upon receiving a new monitoring description, the entity creates a new thread to read the XML document and then starts monitoring the resource. The monitoring entity also creates another thread to take the monitored data for the resource, process the data, and send the processed data to the associated consumers in the required format.
  • Each monitoring entity is a producer and a consumer of data and has access to all the monitoring descriptions of the resources it monitors at any point of time. It also has a list of metrics it monitors for each resource. It has the description of requirements (list of metrics and associated monitoring attributes per resource) from each of its consumers.
  • Each monitoring entity publishes its descriptions by sending them to the repositories. It also knows of its consumer and resource instance bindings. Upon receiving a change in monitoring description of a resource instance, the monitoring entity starts monitoring new metrics or starts monitoring metrics using new parameters (granularities, periods, addresses, etc), or stops monitoring metrics removed from the resources description. Upon receiving a change in the requirements description of a consumer, the monitoring entity or gateway decides what metrics are to be monitored and what metrics need not be monitored. The Metric List Optimizer component is notified of a new metric being required or an existing metric not being required. If there is no such component in the system, the monitoring entity can implement this function.
  • If a monitoring entity receives a directive from a consumer or gateway to monitor a derived metric, then the monitoring entity (by itself or with the help of a Common Sub-Expression Finder (CSEF) component) decides how to compute the derived metric. As an outcome, if the monitoring entity has to receive some metrics from another set of monitoring agents, then the current monitoring agent requests the registration module to register the current monitoring agent as a consumer of required data output by the other monitoring agents.
  • The monitoring entities also implement bundling algorithms. Bundling technique is used to create a maximal bundle of data that can be sent to consumer(s) such that resource consumption in transmitting monitoring data to consumers is reduced. Below we have discussed some possible algorithms. However, it might be possible that there are multiple agents that need to generate same bundles of same data. There might be agents that are generating bundles of data (for 5 seconds) and another agent has to create bigger bundles (for 20 seconds). The second kind of agents would register themselves at the Registration Module as a consumer of these bundles at the agent(s). However, in order to find out if such common computations can be carried out at minimum number of places, the monitoring entities can request the CSEF to find out this.
  • If a derived-metric is not going to be required, then the monitoring agent(s) stop computing that derived metric. If this means that they need not remain as consumers to some of the monitoring entities, then they would request the Registration Module to de-register themselves from the consumer list of other agents.
  • Each monitoring entity is capable of processing the monitoring data according to the data processing instructions of a consumer. For efficient data processing, the entity can perform common processing (such as common sub-expression in compilers) across all consumers and then do consumer specific processing on top of it.
  • A monitoring entity implements the following algorithms:
  • Algorithm-1
  • 1. For each metric, receive data for a predefined period for each consumer.
  • 2. For metric “M”, if derived data is required by a consumer, then compute the derived data for the predefined period (for a current cycle or previous cycles).
  • 3. Repeat 2 for each metric.
  • 4. Repeat 2 and 3 for each consumer.
  • 5. Send the data to the respective consumer entity at the end of the monitoring period.
  • Algorithm-2
  • 1. For each metric of a resource being monitored, find out how many consumers require derived data.
  • 2. For all consumers, for a given metric such that the granularity of requirement is same, find the expression associated with the computation of the derived data.
  • 3. Apply a technique to find common sub-expressions among such expressions of a metric for the last or earlier periods.
  • 4. Compute such common sub-expressions once and use them to compute final expressions for the metric for the last or earlier cycles.
  • 5. Repeat 2-4 for each metric.
  • 6. Send the data at the end of the cycle.
  • Each monitoring entity is capable of bundling the data according to the cycle(s) of one or more of the consumers, and sending the bundled data to the consumers. This can reduce bandwidth requirements. Experimental analysis has shown that bundling of monitoring data for reporting to consumer entities significantly improves the throughput of the system. For example, if each consumer entity in the management layer (that is, each ultimate consumer) has one or more dedicated monitoring entities, then the monitoring data can be bundled and reported according to a different reporting period than the monitoring period specified by the original data producer(s). The monitoring entities can aggregate the data for the particular reporting period desired by the consumer.
  • A monitoring entity also implements the following algorithms:
  • Algorithm-3
  • 1. For each metric of each resource repeat the following:
  • 2. For all consumers, for a given metric such that the granularity of requirement is same, find the cycles over which the data is required.
  • 3. Find out the minimum cycle among them.
  • 4. Make bundles of this minimum cycle and send data to all such consumers for this metric.
  • Algorithm-4
  • 1. For each metric of each resource repeat the following:
  • 2. For all consumers, for a given metric such that the granularity of requirement is same, find the cycles over which the data is required.
  • 3. Find out the cycle “C” that occurs maximum number of times among them. (‘mean’ instead of ‘mode’ can be used).
  • 4. Make bundles of this cycle “C” and send data to all such consumers for this metric.
  • A monitoring entity supports encryption techniques for sending data over network to a remote monitor or a consumer. Existing encryption techniques can be used for this purpose.
  • A monitoring entity can be a composite agent that produces composite monitoring metric out of the metrics of some resources. This agent is also described in the repositories such that it can be matched for during the matching and selection process for a consumer. The composite agent receives the monitoring data of various resources from resource instances and/or other monitoring entities. Then it uses them to compute data for the composite metric. The agent can use CSEF module to detect common computations that it can share with other entities and how to use common computations. Upon getting result from CSEF, it can register through registration module for the dependant monitoring entities.
  • If a new monitoring description for an existing resource or a new resource instance is available at any given point of time, the monitoring entity starts monitoring according to the new description. If a consumer registers with a monitoring entity with its description of requirements, then the monitoring entity starts reporting data to the consumer according to the requirements description.
  • For monitoring data of high priority pushed from the measurement entity, the monitoring entities forward such data as soon as possible to the appropriate consumer(s).
  • If a consumer modifies its description of requirements on monitoring data, the modified description is partially or completely available with the monitoring entities. If an existing monitoring metric is not required by any of the consumers, then the monitoring entity directs the corresponding measurement entity and/or the resource to stop its measurement and reporting. This action on the part of resource may get reflected in its monitoring description; if an existing metric is removed dynamically from being measured, it also gets removed dynamically from the monitoring description of the resource. Such a modification initiates a chain of actions later.
  • Consumer Entity
  • The management or consumer layer consists of components that use the monitoring data to carry out management and scheduling tasks, such as monitoring of composite services, metering and accounting, system behaviour analysis, SLA and QoS management, and logging. A management entity can be a software program or a hardware component or firmware.
  • Each entity (a consumer) in this layer has a description of the requirements (as described in the monitoring layer section). The requirement description of a consumer would specify the resource types, the metrics (both primitive and derived), granularities, period, cycle of data collection (bundling size) etc. The description might include
  • Resource name/identifier
  • Metrics to be reported
  • Granularity of each of the metrics
  • Period (if synchronous) of each of the metrics
  • Cycle per metric for which the data to be collected and then reported
  • Data processing instructions: average monitoring data over some period of time.
  • For derived metrics, corresponding expression based on primitive or other well-defined derived metrics has to be defined as part of this description.
  • Mechanism in which data to be reported to the consumer, if it is different from the mechanism(s) employed by the producer.
  • The cycle per metric could be based on time or on number of requests, etc. For example, report monitoring data for resource R1, metric ‘CpuUtilization’ per customer with a period of 1 millisecond for last 5 seconds or last 100 requests.
  • Upon registering for receipt of monitoring data from the monitoring layer, the consumer passes the set of requirements to the appropriate entities in that layer. If required, the consumer in the management layer can modify the set of requirements dynamically. Such a modification gets propagated in the same or a different form to all the layers down to the resource layer or to the measurement entities.
  • If a new resource is introduced or an existing resource is removed, then the consumer entities access the monitoring description of this resource and pass their requirement description with respect to this resource across to the monitoring layer. This is essentially a modification of the requirement description of the consumer.
  • If there are modifications to the monitoring description of a resource, then communication among the appropriate entities in the three layers is established in order to have consistent requirements descriptions for the consumer(s).
  • Remote Monitor
  • In case, the supporting modules and other components in the monitoring system find that it will be costlier in terms of throughput and resource utilization to compute additional derived data (as compared with before the changes to the requirements for consumer “s”), then a monitoring entity may be sent to the local system or network of the consumer. This monitoring entity takes the requirement description of associated consumer(s) as input, and receives data from other monitoring entities (as prescribed by the supporting modules). Based on the received information, the monitoring entity computes required data from the incoming data and data bundles in a format required by the consumer. Thus, there may be a distributed network of cooperating monitoring entities.
  • If the requirement description for the consumers is based on a standard language, then a remote monitor can be an engine for that language. In order to process the requirement description of a consumer, the gateway or the supporting modules (or another complementary component) must be able to read and understand the format/language in which the document is written. One embodiment provides a subcomponent that implements the reading and parsing mechanism for particular document formats. If the language is a standard one, then the monitoring subsystem can use a generic subcomponent that can parse and read documents written in this language. For example if the language is based on Extensible markup language (XML), then Distributed Object Model (DOM) processing tools can be used.
  • Implementation of Components
  • The monitoring entities and external measuring entities can be implemented as software programs/agents. Each of a set of measuring entities external of a resource can be collected together on the same physical machine containing the resource(s). Each monitoring agent could be on a different machine.
  • The monitoring agents, measurement entities and resources may communicate through a publish/subscribe system and also through normal network communication mechanisms. The monitoring description of a resource can be specified using an XML schema (as shown in FIG. 4) and similarly for requirement specifications. The descriptions would be available in a public repository. As soon as a description is modified, the modifying agent, consumer entity or resource notifies other agents through the publish/subscribe system. This information is also updated in the repository, unless it is a temporary state.
  • Upon introduction of a new resource, the resource manager activates the measurement entities on that node and registers that instance(s) for being monitored at specific agent(s). Interested consumers of management layer register themselves with agents with their requirement descriptions. The agent(s) in turn retrieve the monitoring description and configuration of the resource instance/measurement entities and build a memory model of it for collecting monitoring data. The agents would subscribe to topics to which measurement entities, resources and other agents publish metric values and resource states. They would also use socket connections and RPC to pull monitoring data from components in both monitoring and resource layer. The management layer would be listening to topics in the publish/subscribe system. An agent can also connect to a consumer through TCP connection for control messages or immediate status reports.
  • For computation of derived data, the agent would implement one of the algorithms mentioned earlier or any other algorithms. For bundling of data, the agent can use any of the algorithms specified earlier or any other suitable algorithm. Supporting modules could implement a software version of the existing algorithms for authentication, matching, negotiation, registration. For negotiation, the monitoring agents also implement the negotiation protocol(s).
  • Web Services Monitoring Architecture Implementation
  • Each monitoring agent (MA) is local to a data processing unit or node within the network. The MA is responsible for collection of monitoring data and communication of monitoring data to monitoring services. An agent collects data for each service instance deployed on its local node. It also collects monitoring data about the ‘health’ of a node. The health of a node denotes the load generated by all processes running on that system at a given point of time, the resource usage of the node (memory usage, cpu load, etc), and the load of each container (underlying computing software layers or middleware), if any, on that node. Each raw data received/pulled by the agent for a service is parsed according to the format specified in the monitoring specification of that service. This raw data is bundled per service over granularity and an interval as specified by a monitoring service, and then communicated to appropriate monitoring services. Monitoring agents are capable of sending out notifications (fault-related, behavioural, etc) to appropriate monitoring services. Each agent knows the addresses of monitoring services associated with it. A monitoring agent supports interfaces enabling pulling of data. Monitoring agents also support interfaces for modification of granularity/interval of data bundles, by monitoring services.
  • A monitoring service can be implemented for each Web service, a monitoring service for each node, and another monitoring service for all containers on all nodes. A monitoring service is responsible for providing monitored data to the consumers, SLA measurement service, metering/accounting service, resource manager, etc. Each consumer entity is likely to have a different granularity and interval at which the consumer entity expects monitoring data for a specific service ‘S’. The consumer entity has the responsibility to specify this information (statically or dynamically) to the monitoring service for web service ‘S’. Each monitoring service (MS) maintains a list of agents that are monitoring the associated service instances.
  • The MS directs the monitoring agents in its list to bundle and send the monitoring data at a granularity g and interval I. Values of “g” and “I” are such that the monitoring service can derive the granularities and intervals required by consumers from g and I. During its runtime, a monitoring service bundles the monitoring data (from agents) and communicates each of the bundles to the appropriate consumer at appropriate point of time (based on the interval).
  • Each MS supports interfaces for pull of data by consumers. A data pull by a consumer is propagated to the agent(s), if monitoring data does not possess the data with it or else it is served by the monitoring service itself. For a service-specific notification from an agent, a monitoring service immediately notifies the resource and workload managers. A consumer notifies associated monitoring service(s) for any change in granularity g and interval I; monitoring service(s) in turn, notify associated monitoring agents about the change. A service-specific monitoring service is responsible for data of one service, node monitoring service is responsible for data of all nodes and container monitoring service is responsible for data of all containers on all nodes.
  • Whenever a new service instance is deployed, resource manager notifies the monitoring service about the address of the monitoring agent on that node. If the service is new, prior to the notification, resource manager deploys a new monitoring service. If the node is new, resource manager notifies the node manager about its address. If there is a new container deployed on the node, it notifies the container monitoring service. Each monitoring service that gets notified, directs the monitoring agent to monitor the service instance and/or node and/or container and send the data bundled over a granularity g and interval I. Similarly when a service instance is to be terminated, a resource manager notifies the monitoring service to stop monitoring the instance. Monitoring service in turn directs the agent associated to stop monitoring the instance. Upon receiving the directive to monitor an instance, a monitoring agent imports the monitoring specification of the service, instantiates the monitoring links, if not available already, as per the specification and directive parameters provided by resource manager through monitoring service and then starts monitoring.
  • Upon dynamic modification of monitoring description of a web service, the corresponding monitoring service is notified along with the agents and the monitors. This is just a publish in the pub/sub system being used on a topic. The message contains the service name and the new monitoring description. The monitor then checks if its requirement description R is a subset of the new monitoring description S. If not, then it removes the entries specific to R-S and also tunes the granularity and period of monitoring towards the higher granularity (opposite of fine granularity).
  • In addition, systems according to one embodiment of the invention enable dynamic registration of new consumers for monitoring data, or de-registration of old consumers to stop them receiving monitoring data. Existing consumers may be able to dynamically modify their requirements of monitoring data. For example, a new SLA may be added due to dynamic SLA negotiation, which could lead the SLA to receive data for some new metrics or to receive data at a different granularity level. Additionally, some faults may prevent a sub-component of a resource from being able to measure and/or report the data to a consumer. If this state continues for a long period of time, then the consumers that are waiting for the data need to be informed of the non-availability of such data. In this case, there is dynamic change in the monitoring metrics being measured/monitored on a per-resource-instance basis. Similarly the requirements of a consumer might change dynamically based on the dynamic states of resources or external requirements.
  • Dynamic registration of consumers for monitoring data raises another issue: the need for matching of the requirements of the consumer with the available monitoring data from each agent, selection of a suitable monitoring agent(s) and binding the new consumer with the agent(s). Dynamic changes in the metrics being monitored or the granularity or period at which the metrics are being monitored for a resource adds another dimension, since such a change may lead to the changes in the requirements of the consumer or the bindings to the monitoring agents.
  • Given that there could be multiple consumers for the monitoring data from a resource with differences in the granularity, monitoring period or reporting frequency, or at the level of derived parameters out of primitive metrics, there is also a need for optimized computation of the data as desired by multiple consumers and optimized transmission frequency of the data to consumers. Such optimization can improve resource utilization.
  • There has been a lot of work in monitoring of resources, but existing solutions typically do not consider dynamic changes to the metrics being monitored, to the requirements of consumers, nor to the set of consumers that are interested in the monitoring data. Existing solutions typically assume that the metrics that are being monitored are mostly externally measurable metrics. Resource-dependent metrics have rarely been taken into consideration in building monitoring frameworks and systems. Furthermore, existing solutions do not provide dynamic and automatic matching and selection of monitoring agents for a consumer or a set of consumers.
  • At least some of the problems described above have only arisen recently, because of the advent of resource usage based metering and accounting (which requires monitoring of internal metrics), autonomic computing and automatic SLA negotiations (for which metrics needed by various consumers may change over time, including at runtime).
  • Additionally, resource wastage due to monitoring of unnecessary metrics has to be controlled.
  • The present invention mitigates one or more of the problems or limitations of known systems, and in one embodiment provides a monitoring framework that facilitates monitoring of both external and internal metrics for a system or network comprising heterogeneous resources. The framework supports static and dynamic registration and de-registration of resources and consumers of the monitoring data. The framework also supports dynamic changes to the monitoring description of a resource and of a resource instance, enabling consumers to dynamically modify their requirements description. The framework makes it possible to improve upon resource utilization, computation and communication of monitoring data while supporting multiple consumers for their desired metrics at the desired granularity and desired monitoring periods.
  • Various alterations and modifications to the techniques and arrangements described in detail above can be made within the scope of the present invention, as will be apparent to a person skilled in the relevant art.

Claims (16)

1. A method for monitoring resources of a data processing system, comprising the steps of:
identifying the monitoring requirements of a currently active set of consumer entities;
determining whether a currently active set of monitoring functions of monitoring entities are consistent with the monitoring requirements of the currently active set of consumer entities; and
in response to determining that the currently active set of monitoring functions are inconsistent with the monitoring requirements of the currently active set of consumer entities, modifying the currently active set of monitoring functions.
2. The method of claim 1, wherein said determining step comprises comparing a set of monitoring descriptions of monitoring entities and consumer entities, which monitoring descriptions are stored in a repository, and wherein said step of determining is performed in response to change of a monitoring description in said repository.
3. The method of claim 1, wherein modifying the currently active set of monitoring functions comprises configuring a monitoring entity to commence monitoring a resource.
4. The method of claim 1, wherein modifying the currently active set of monitoring functions comprises configuring a monitoring entity to commence monitoring a metric.
5. The method of claim 1, wherein modifying the currently active set of monitoring functions comprises configuring a monitoring entity to change the granularity of monitoring for a monitored metric.
6. The method of claim 1, wherein modifying the currently active set of monitoring functions comprises configuring a monitoring entity to change the monitoring period for a monitored metric.
7. The method of claim 1, wherein modifying the currently active set of monitoring functions comprises terminating a monitoring entity.
8. The method of claim 1, wherein modifying the currently active set of monitoring functions comprises terminating monitoring of a metric for a monitored resource.
9. The method of claim 1, wherein modifying the currently active set of monitoring functions comprises terminating monitoring for a resource.
10. The method of claim 1, wherein modifying the currently active set of monitoring functions comprises terminating reporting of monitoring data to a consumer entity.
11. A data processing system for monitoring resources of a data processing network, comprising:
a data storage unit for storing monitoring capabilities of each of a set of monitoring entities;
a monitoring manager configured to respond to monitoring requirements of a data consumer entity by determining whether a currently active set of monitoring functions of monitoring entities are consistent with the monitoring requirements of the currently active set of consumer entities, and configured to respond to a determination that the currently active set of monitoring functions are inconsistent with the monitoring requirements of the currently active set of consumer entities by modifying the currently active set of monitoring functions.
12. The data processing system of claim 11, wherein the monitoring manager comprises:
a component for handling registration and de-registration of consumer entities and monitoring entities with a monitoring subsystem;
a selector for selecting at least one monitoring entity for a consumer entity; and
a connection manager for establishing a connection between the consumer entity and the selected monitoring entity.
13. The data processing system of claim 11, wherein the monitoring manager comprises a resource optimizer for determining a set of one or more monitoring entities capable of generating required monitoring data from data measured for a resource.
14. A computer program product, comprising program code recorded on a recording medium, for managing monitoring of resources within a data processing network on behalf of one or more data consumer entities within the network, the program code comprising:
a monitoring manager configured to respond to monitoring requirements of a data consumer entity by determining whether a currently active set of monitoring functions of monitoring entities are consistent with the monitoring requirements of the currently active set of consumer entities, and configured to respond to a determination that the currently active set of monitoring functions are inconsistent with the monitoring requirements of the currently active set of consumer entities by modifying the currently active set of monitoring functions.
15. The data processing system of claim 14, wherein the monitoring manager comprises:
a component for handling registration and de-registration of consumer entities and monitoring entities with a monitoring subsystem;
a selector for selecting at least one monitoring entity for a consumer entity; and
a connection manager for establishing a connection between the consumer entity and the selected monitoring entity.
16. The data processing system of claim 14, wherein the monitoring manager comprises a resource optimizer for determining a set of one or more monitoring entities capable of generating required monitoring data from data measured for a resource.
US12/173,854 2003-12-10 2008-07-16 Systems, Methods and Computer Programs for Monitoring Distributed Resources in a Data Processing Environment Abandoned US20080275985A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/173,854 US20080275985A1 (en) 2003-12-10 2008-07-16 Systems, Methods and Computer Programs for Monitoring Distributed Resources in a Data Processing Environment

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/732,736 US7454496B2 (en) 2003-12-10 2003-12-10 Method for monitoring data resources of a data processing network
US12/173,854 US20080275985A1 (en) 2003-12-10 2008-07-16 Systems, Methods and Computer Programs for Monitoring Distributed Resources in a Data Processing Environment

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/732,736 Division US7454496B2 (en) 2003-12-10 2003-12-10 Method for monitoring data resources of a data processing network

Publications (1)

Publication Number Publication Date
US20080275985A1 true US20080275985A1 (en) 2008-11-06

Family

ID=34652935

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/732,736 Active 2026-05-28 US7454496B2 (en) 2003-12-10 2003-12-10 Method for monitoring data resources of a data processing network
US12/173,854 Abandoned US20080275985A1 (en) 2003-12-10 2008-07-16 Systems, Methods and Computer Programs for Monitoring Distributed Resources in a Data Processing Environment

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US10/732,736 Active 2026-05-28 US7454496B2 (en) 2003-12-10 2003-12-10 Method for monitoring data resources of a data processing network

Country Status (1)

Country Link
US (2) US7454496B2 (en)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080168560A1 (en) * 2007-01-05 2008-07-10 Durie Anthony Robert Dynamic Provisioning of Protection Software in a Host Intrusion Prevention System
US20090106842A1 (en) * 2007-10-19 2009-04-23 Durie Anthony Robert System for Regulating Host Security Configuration
US20090262656A1 (en) * 2008-04-22 2009-10-22 International Business Machines Corporation Method for new resource to communicate and activate monitoring of best practice metrics and thresholds values
US20100138699A1 (en) * 2008-12-01 2010-06-03 Udo Klein Scheduling of checks in computing systems
US20100157822A1 (en) * 2008-12-22 2010-06-24 Sap Agdietmar-Hopp-Allee Service accounting method and apparatus for composite service
US20110179489A1 (en) * 2007-01-08 2011-07-21 Durie Anthony Robert Host intrusion prevention server
US20120023213A1 (en) * 2009-02-05 2012-01-26 Ipanema Technologies Method for management of data stream exchanges in an autonomic telecommunications network
US20120311138A1 (en) * 2011-06-03 2012-12-06 Oracle International Corporation System and method for using quality of service with workload management in an application server environment
US20140136689A1 (en) * 2012-11-14 2014-05-15 International Business Machines Corporation Secure metering and accounting for cloud services
US11586524B1 (en) * 2021-04-16 2023-02-21 Vignet Incorporated Assisting researchers to identify opportunities for new sub-studies in digital health research and decentralized clinical trials
US11645180B1 (en) 2021-04-16 2023-05-09 Vignet Incorporated Predicting and increasing engagement for participants in decentralized clinical trials
US11789837B1 (en) * 2021-02-03 2023-10-17 Vignet Incorporated Adaptive data collection in clinical trials to increase the likelihood of on-time completion of a trial

Families Citing this family (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7120694B2 (en) * 1999-10-22 2006-10-10 Verizon Laboratories Inc. Service level agreements and management thereof
US7814198B2 (en) 2007-10-26 2010-10-12 Microsoft Corporation Model-driven, repository-based application monitoring system
JP4123914B2 (en) * 2002-11-26 2008-07-23 株式会社日立製作所 Monitoring method and monitoring program for program operating state
JP3862652B2 (en) * 2002-12-10 2006-12-27 キヤノン株式会社 Printing control method and information processing apparatus
US7493418B2 (en) * 2003-12-18 2009-02-17 International Business Machines Corporation Generic method for resource monitoring configuration in provisioning systems
US7822826B1 (en) 2003-12-30 2010-10-26 Sap Ag Deployment of a web service
US7941521B1 (en) 2003-12-30 2011-05-10 Sap Ag Multi-service management architecture employed within a clustered node configuration
US7725572B1 (en) 2003-12-30 2010-05-25 Sap Ag Notification architecture and method employed within a clustered node configuration
US7756968B1 (en) * 2003-12-30 2010-07-13 Sap Ag Method and system for employing a hierarchical monitor tree for monitoring system resources in a data processing environment
US7562143B2 (en) 2004-01-13 2009-07-14 International Business Machines Corporation Managing escalating resource needs within a grid environment
US7406691B2 (en) 2004-01-13 2008-07-29 International Business Machines Corporation Minimizing complex decisions to allocate additional resources to a job submitted to a grid environment
US7464159B2 (en) * 2004-01-14 2008-12-09 International Business Machines Corporation Managing analysis of a degraded service in a grid environment
US7552437B2 (en) 2004-01-14 2009-06-23 International Business Machines Corporation Maintaining application operations within a suboptimal grid environment
US20050216510A1 (en) * 2004-03-26 2005-09-29 Reinhold Kautzleben System and method to provide a visual administrator in a network monitoring system
US7721266B2 (en) * 2004-03-26 2010-05-18 Sap Ag Unified logging service with a logging formatter
US7526550B2 (en) * 2004-03-26 2009-04-28 Sap Ag Unified logging service with a log viewer
US7266547B2 (en) 2004-06-10 2007-09-04 International Business Machines Corporation Query meaning determination through a grid service
US7702779B1 (en) * 2004-06-30 2010-04-20 Symantec Operating Corporation System and method for metering of application services in utility computing environments
US7712100B2 (en) * 2004-09-14 2010-05-04 International Business Machines Corporation Determining a capacity of a grid environment to handle a required workload for a virtual grid job request
US7590623B2 (en) * 2005-01-06 2009-09-15 International Business Machines Corporation Automated management of software images for efficient resource node building within a grid environment
US7533170B2 (en) * 2005-01-06 2009-05-12 International Business Machines Corporation Coordinating the monitoring, management, and prediction of unintended changes within a grid environment
US7761557B2 (en) * 2005-01-06 2010-07-20 International Business Machines Corporation Facilitating overall grid environment management by monitoring and distributing grid activity
US7502850B2 (en) * 2005-01-06 2009-03-10 International Business Machines Corporation Verifying resource functionality before use by a grid job submitted to a grid environment
US7707288B2 (en) * 2005-01-06 2010-04-27 International Business Machines Corporation Automatically building a locally managed virtual node grouping to handle a grid job requiring a degree of resource parallelism within a grid environment
US7793308B2 (en) * 2005-01-06 2010-09-07 International Business Machines Corporation Setting operation based resource utilization thresholds for resource use by a process
US7472079B2 (en) * 2005-01-12 2008-12-30 International Business Machines Corporation Computer implemented method for automatically controlling selection of a grid provider for a grid job
US7571120B2 (en) 2005-01-12 2009-08-04 International Business Machines Corporation Computer implemented method for estimating future grid job costs by classifying grid jobs and storing results of processing grid job microcosms
US7562035B2 (en) 2005-01-12 2009-07-14 International Business Machines Corporation Automating responses by grid providers to bid requests indicating criteria for a grid job
JP4313336B2 (en) * 2005-06-03 2009-08-12 株式会社日立製作所 Monitoring system and monitoring method
US7584276B2 (en) * 2005-09-27 2009-09-01 International Business Machines Corporation Adaptive orchestration of composite services
US8095641B2 (en) * 2005-10-27 2012-01-10 International Business Machines Corporation Method and system for virtualized health monitoring of resources
US7937690B2 (en) * 2006-05-23 2011-05-03 Hewlett-Packard Development Company, L.P. Evaluating performance of software application
US8185619B1 (en) * 2006-06-28 2012-05-22 Compuware Corporation Analytics system and method
US8955105B2 (en) * 2007-03-14 2015-02-10 Microsoft Corporation Endpoint enabled for enterprise security assessment sharing
US8959568B2 (en) * 2007-03-14 2015-02-17 Microsoft Corporation Enterprise security assessment sharing
US8413247B2 (en) * 2007-03-14 2013-04-02 Microsoft Corporation Adaptive data collection for root-cause analysis and intrusion detection
TW200838215A (en) * 2007-03-15 2008-09-16 Univ Nat Central System device utilizing policy to manage network service
US20080229419A1 (en) * 2007-03-16 2008-09-18 Microsoft Corporation Automated identification of firewall malware scanner deficiencies
US8024396B2 (en) * 2007-04-26 2011-09-20 Microsoft Corporation Distributed behavior controlled execution of modeled applications
US8176095B2 (en) * 2007-06-11 2012-05-08 Lucid Design Group, Llc Collecting, sharing, comparing, and displaying resource usage data
US7970892B2 (en) * 2007-06-29 2011-06-28 Microsoft Corporation Tuning and optimizing distributed systems with declarative models
US8239505B2 (en) * 2007-06-29 2012-08-07 Microsoft Corporation Progressively implementing declarative models in distributed systems
US8230386B2 (en) 2007-08-23 2012-07-24 Microsoft Corporation Monitoring distributed applications
KR20100080822A (en) * 2007-09-28 2010-07-12 엑세리온 악티에볼라그 Network operating system
US8135824B2 (en) * 2007-10-01 2012-03-13 Ebay Inc. Method and system to detect a network deficiency
US8375068B1 (en) 2007-10-04 2013-02-12 Lucid Design Group, Llc Extensible framework and graphical user interface for sharing, comparing, and displaying resource usage data
US7926070B2 (en) 2007-10-26 2011-04-12 Microsoft Corporation Performing requested commands for model-based applications
US8181151B2 (en) * 2007-10-26 2012-05-15 Microsoft Corporation Modeling and managing heterogeneous applications
US8225308B2 (en) * 2007-10-26 2012-07-17 Microsoft Corporation Managing software lifecycle
US8099720B2 (en) 2007-10-26 2012-01-17 Microsoft Corporation Translating declarative models
US7974939B2 (en) 2007-10-26 2011-07-05 Microsoft Corporation Processing model-based commands for distributed applications
US7856499B2 (en) * 2008-03-20 2010-12-21 Sap Ag Autonomic provisioning of hosted applications with level of isolation terms
US20090254355A1 (en) * 2008-04-02 2009-10-08 Li-Der Chou Service Level Agreement-Based Service Monitoring System using Agents
CN102037702B (en) * 2008-05-20 2015-08-12 艾利森电话股份有限公司 Composite services in communication network provide
CN105976258B (en) * 2010-04-08 2019-12-10 能源管理公司 Energy saving metering system and method
WO2011149558A2 (en) 2010-05-28 2011-12-01 Abelow Daniel H Reality alternate
US8990369B2 (en) * 2010-10-22 2015-03-24 At&T Intellectual Property I, L.P. Collaborative QoS for service oriented architectures
US10555145B1 (en) * 2012-06-05 2020-02-04 Amazon Technologies, Inc. Learned configuration of modification policies for program execution capacity
US9958291B1 (en) 2014-08-11 2018-05-01 Abl Ip Holding Llc Self-service connection, data collection, and automation of metering and building systems, controls, and devices
US10718632B1 (en) 2014-08-11 2020-07-21 Abl Ip Holding Llc Self-service discovery, refinement, and execution of automated multi-system insights
CN106533792A (en) * 2016-12-12 2017-03-22 北京锐安科技有限公司 Method and device for monitoring and configuring resources
US10592378B1 (en) * 2018-10-04 2020-03-17 Ca, Inc. Managing monitoring feature overhead
CN110784545B (en) * 2019-10-31 2022-02-11 上海埃威航空电子有限公司 Real-time data distribution system
JP7384523B2 (en) 2022-02-21 2023-11-21 Necプラットフォームズ株式会社 Request control system, request control method and program

Citations (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5465286A (en) * 1994-05-24 1995-11-07 Executone Information Systems, Inc. Apparatus for supervising an automatic call distribution telephone system
US5892754A (en) * 1996-06-07 1999-04-06 International Business Machines Corporation User controlled adaptive flow control for packet networks
US6041307A (en) * 1998-01-23 2000-03-21 Lucent Technologies Inc. Technique for effectively managing resources in a network
US6055307A (en) * 1996-06-28 2000-04-25 At&T Corp. System and method for selecting agent destinations and monitoring calls made to network customers
US6154778A (en) * 1998-05-19 2000-11-28 Hewlett-Packard Company Utility-based multi-category quality-of-service negotiation in distributed systems
US6158010A (en) * 1998-10-28 2000-12-05 Crosslogix, Inc. System and method for maintaining security in a distributed computer network
US20020029185A1 (en) * 2000-09-05 2002-03-07 Teruo Tanaka Method and apparatus for providing broker service to auctions
US20020040441A1 (en) * 1997-06-13 2002-04-04 See Michael E. Deterministic user authentication service for communication network
US20020055990A1 (en) * 1999-11-08 2002-05-09 Vaman Dhadesugoor R. Method and apparatus for providing end-to-end quality of service in multiple transport protocol environments using permanent or switched virtual circuit connection management
US20020065922A1 (en) * 2000-11-30 2002-05-30 Vijnan Shastri Method and apparatus for selection and redirection of an existing client-server connection to an alternate data server hosted on a data packet network (DPN) based on performance comparisons
US20020069279A1 (en) * 2000-12-29 2002-06-06 Romero Francisco J. Apparatus and method for routing a transaction based on a requested level of service
US20020095400A1 (en) * 2000-03-03 2002-07-18 Johnson Scott C Systems and methods for managing differentiated service in information management environments
US20020127074A1 (en) * 2001-03-09 2002-09-12 Lothar Gierth Inside broaching machine
US20020194350A1 (en) * 2001-06-18 2002-12-19 Lu Leonard L. Content-aware web switch without delayed binding and methods thereof
US20020194324A1 (en) * 2001-04-26 2002-12-19 Aloke Guha System for global and local data resource management for service guarantees
US20030009580A1 (en) * 2001-04-09 2003-01-09 Chen Xiaobao X. Providing quality of service in a telecommunications system such as a UMTS of other third generation system
US20030018769A1 (en) * 2000-07-26 2003-01-23 Davis Foulger Method of backtracing network performance
US20030023672A1 (en) * 2001-07-27 2003-01-30 Arthur Vaysman Voice over IP conferencing server system with resource selection based on quality of service
US20030123424A1 (en) * 2001-12-29 2003-07-03 Lg Electronics Inc. Mobile communication system and method of selecting server in mobile communication system
US20030126501A1 (en) * 2002-01-03 2003-07-03 Integrated Management Systems, Inc. System and method for using agent-based distributed case-based reasoning to manage a computer network
US20030167270A1 (en) * 2000-05-25 2003-09-04 Werme Paul V. Resource allocation decision function for resource management architecture and corresponding programs therefor
US6625643B1 (en) * 1998-11-13 2003-09-23 Akamai Technologies, Inc. System and method for resource management on a data network
US6629126B1 (en) * 1998-03-13 2003-09-30 Genuity Inc. Framework for providing quality of service requirements in a distributed object-oriented computer system
US6631122B1 (en) * 1999-06-11 2003-10-07 Nortel Networks Limited Method and system for wireless QOS agent for all-IP network
US6691148B1 (en) * 1998-03-13 2004-02-10 Verizon Corporate Services Group Inc. Framework for providing quality of service requirements in a distributed object-oriented computer system
US20040030777A1 (en) * 2001-09-07 2004-02-12 Reedy Dennis G. Systems and methods for providing dynamic quality of service for a distributed system
US20040039820A1 (en) * 1997-08-01 2004-02-26 Cisco Systems, Inc. Method and apparatus for directing a flow of packets based on request and server attributes
US20040117426A1 (en) * 2001-04-19 2004-06-17 Steven Rudkin Communications network
US6765873B1 (en) * 1999-07-13 2004-07-20 International Business Machines Corporation Connections bandwidth right sizing based on network resources occupancy monitoring
US6772202B2 (en) * 2001-11-28 2004-08-03 Gamespy Industries, Inc. Queuing system, method and computer program product for network data transfer
US6857020B1 (en) * 2000-11-20 2005-02-15 International Business Machines Corporation Apparatus, system, and method for managing quality-of-service-assured e-business service systems
US20050080873A1 (en) * 2003-10-14 2005-04-14 International Business Machine Corporation Method and apparatus for selecting a service binding protocol in a service-oriented architecture
US6965930B1 (en) * 2000-10-20 2005-11-15 International Business Machines Corporation Methods, systems and computer program products for workload distribution based on end-to-end quality of service
US6968323B1 (en) * 2000-10-05 2005-11-22 International Business Machines Corporation Dynamic allocation and pricing of resources of web server farm
US7146417B1 (en) * 1995-11-03 2006-12-05 Cisco Technology, Inc. System for distributing load over multiple servers at an internet site
US7177923B2 (en) * 2001-03-13 2007-02-13 Agere Systems Inc. Methods and devices for selecting internet servers
US7209437B1 (en) * 1998-10-15 2007-04-24 British Telecommunications Public Limited Company Computer communication providing quality of service
US7307954B1 (en) * 2000-06-23 2007-12-11 Nokia Corporation Differentiated service network and method of operating a differentiated service network

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06175944A (en) 1992-12-04 1994-06-24 Fujitsu Ltd Network monitoring method
JPH10164063A (en) 1996-12-04 1998-06-19 Fujitsu Ltd Distributed monitoring control system
KR20000070005A (en) * 1997-01-09 2000-11-25 코페이 스티븐 Monitoring of remote file access on a public computer network
US6943905B2 (en) * 2001-12-20 2005-09-13 Sharp Laboratories Of America, Inc. Virtual print driver system and method

Patent Citations (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5465286A (en) * 1994-05-24 1995-11-07 Executone Information Systems, Inc. Apparatus for supervising an automatic call distribution telephone system
US7146417B1 (en) * 1995-11-03 2006-12-05 Cisco Technology, Inc. System for distributing load over multiple servers at an internet site
US5892754A (en) * 1996-06-07 1999-04-06 International Business Machines Corporation User controlled adaptive flow control for packet networks
US6055307A (en) * 1996-06-28 2000-04-25 At&T Corp. System and method for selecting agent destinations and monitoring calls made to network customers
US20020040441A1 (en) * 1997-06-13 2002-04-04 See Michael E. Deterministic user authentication service for communication network
US20040039820A1 (en) * 1997-08-01 2004-02-26 Cisco Systems, Inc. Method and apparatus for directing a flow of packets based on request and server attributes
US6041307A (en) * 1998-01-23 2000-03-21 Lucent Technologies Inc. Technique for effectively managing resources in a network
US6691148B1 (en) * 1998-03-13 2004-02-10 Verizon Corporate Services Group Inc. Framework for providing quality of service requirements in a distributed object-oriented computer system
US6629126B1 (en) * 1998-03-13 2003-09-30 Genuity Inc. Framework for providing quality of service requirements in a distributed object-oriented computer system
US6154778A (en) * 1998-05-19 2000-11-28 Hewlett-Packard Company Utility-based multi-category quality-of-service negotiation in distributed systems
US7209437B1 (en) * 1998-10-15 2007-04-24 British Telecommunications Public Limited Company Computer communication providing quality of service
US6158010A (en) * 1998-10-28 2000-12-05 Crosslogix, Inc. System and method for maintaining security in a distributed computer network
US6625643B1 (en) * 1998-11-13 2003-09-23 Akamai Technologies, Inc. System and method for resource management on a data network
US6631122B1 (en) * 1999-06-11 2003-10-07 Nortel Networks Limited Method and system for wireless QOS agent for all-IP network
US6765873B1 (en) * 1999-07-13 2004-07-20 International Business Machines Corporation Connections bandwidth right sizing based on network resources occupancy monitoring
US20020055990A1 (en) * 1999-11-08 2002-05-09 Vaman Dhadesugoor R. Method and apparatus for providing end-to-end quality of service in multiple transport protocol environments using permanent or switched virtual circuit connection management
US20020091802A1 (en) * 1999-11-08 2002-07-11 Thanabalan Paul Generic quality of service protocol and architecture for user applications in multiple transport protocol environments
US7185070B2 (en) * 1999-11-08 2007-02-27 Boyle Phosphorus Llc Generic quality of service protocol and architecture for user applications in multiple transport protocol environments
US20020095400A1 (en) * 2000-03-03 2002-07-18 Johnson Scott C Systems and methods for managing differentiated service in information management environments
US20030167270A1 (en) * 2000-05-25 2003-09-04 Werme Paul V. Resource allocation decision function for resource management architecture and corresponding programs therefor
US20050055322A1 (en) * 2000-05-25 2005-03-10 Masters Michael W. Instrumentation for resource management architecture and corresponding programs therefor
US7051098B2 (en) * 2000-05-25 2006-05-23 United States Of America As Represented By The Secretary Of The Navy System for monitoring and reporting performance of hosts and applications and selectively configuring applications in a resource managed system
US7307954B1 (en) * 2000-06-23 2007-12-11 Nokia Corporation Differentiated service network and method of operating a differentiated service network
US20030018769A1 (en) * 2000-07-26 2003-01-23 Davis Foulger Method of backtracing network performance
US20020029185A1 (en) * 2000-09-05 2002-03-07 Teruo Tanaka Method and apparatus for providing broker service to auctions
US6968323B1 (en) * 2000-10-05 2005-11-22 International Business Machines Corporation Dynamic allocation and pricing of resources of web server farm
US6965930B1 (en) * 2000-10-20 2005-11-15 International Business Machines Corporation Methods, systems and computer program products for workload distribution based on end-to-end quality of service
US6857020B1 (en) * 2000-11-20 2005-02-15 International Business Machines Corporation Apparatus, system, and method for managing quality-of-service-assured e-business service systems
US20020065922A1 (en) * 2000-11-30 2002-05-30 Vijnan Shastri Method and apparatus for selection and redirection of an existing client-server connection to an alternate data server hosted on a data packet network (DPN) based on performance comparisons
US20020069279A1 (en) * 2000-12-29 2002-06-06 Romero Francisco J. Apparatus and method for routing a transaction based on a requested level of service
US20020127074A1 (en) * 2001-03-09 2002-09-12 Lothar Gierth Inside broaching machine
US7177923B2 (en) * 2001-03-13 2007-02-13 Agere Systems Inc. Methods and devices for selecting internet servers
US20030009580A1 (en) * 2001-04-09 2003-01-09 Chen Xiaobao X. Providing quality of service in a telecommunications system such as a UMTS of other third generation system
US20040117426A1 (en) * 2001-04-19 2004-06-17 Steven Rudkin Communications network
US20020194324A1 (en) * 2001-04-26 2002-12-19 Aloke Guha System for global and local data resource management for service guarantees
US6772211B2 (en) * 2001-06-18 2004-08-03 Transtech Networks Usa, Inc. Content-aware web switch without delayed binding and methods thereof
US20020194350A1 (en) * 2001-06-18 2002-12-19 Lu Leonard L. Content-aware web switch without delayed binding and methods thereof
US20030023672A1 (en) * 2001-07-27 2003-01-30 Arthur Vaysman Voice over IP conferencing server system with resource selection based on quality of service
US20040030777A1 (en) * 2001-09-07 2004-02-12 Reedy Dennis G. Systems and methods for providing dynamic quality of service for a distributed system
US6772202B2 (en) * 2001-11-28 2004-08-03 Gamespy Industries, Inc. Queuing system, method and computer program product for network data transfer
US20030123424A1 (en) * 2001-12-29 2003-07-03 Lg Electronics Inc. Mobile communication system and method of selecting server in mobile communication system
US20030126501A1 (en) * 2002-01-03 2003-07-03 Integrated Management Systems, Inc. System and method for using agent-based distributed case-based reasoning to manage a computer network
US20050080873A1 (en) * 2003-10-14 2005-04-14 International Business Machine Corporation Method and apparatus for selecting a service binding protocol in a service-oriented architecture

Cited By (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8505092B2 (en) 2007-01-05 2013-08-06 Trend Micro Incorporated Dynamic provisioning of protection software in a host intrusion prevention system
US8943593B2 (en) 2007-01-05 2015-01-27 Trend Micro Incorporated Dynamic provisioning of protection software in a host instrusion prevention system
US9231917B2 (en) 2007-01-05 2016-01-05 Trend Micro Incorporated Dynamic provisioning of protection software in a host intrusion prevention system
US9621589B2 (en) 2007-01-05 2017-04-11 Trend Micro Incorporated Dynamic provisioning of protection software in a host intrusion prevention system
US20080168560A1 (en) * 2007-01-05 2008-07-10 Durie Anthony Robert Dynamic Provisioning of Protection Software in a Host Intrusion Prevention System
US9813377B2 (en) 2007-01-05 2017-11-07 Trend Micro Incorporated Dynamic provisioning of protection software in a host intrusion prevention system
US20110179489A1 (en) * 2007-01-08 2011-07-21 Durie Anthony Robert Host intrusion prevention server
US8230508B2 (en) 2007-01-08 2012-07-24 Trend Micro Incorporated Host intrusion prevention server
US8453204B2 (en) 2007-10-19 2013-05-28 Trend Micro Incorporated Method and system for regulating host security configuration
US7996896B2 (en) * 2007-10-19 2011-08-09 Trend Micro Incorporated System for regulating host security configuration
US8225398B2 (en) 2007-10-19 2012-07-17 Trend Micro Incorporated System for regulating host security configuration
US20090106842A1 (en) * 2007-10-19 2009-04-23 Durie Anthony Robert System for Regulating Host Security Configuration
US8990937B2 (en) 2007-10-19 2015-03-24 Trend Micro Incorporated Method and system for regulating host security configuration
US20090262656A1 (en) * 2008-04-22 2009-10-22 International Business Machines Corporation Method for new resource to communicate and activate monitoring of best practice metrics and thresholds values
US20100138699A1 (en) * 2008-12-01 2010-06-03 Udo Klein Scheduling of checks in computing systems
US8103916B2 (en) * 2008-12-01 2012-01-24 Sap Ag Scheduling of checks in computing systems
US8019860B2 (en) * 2008-12-22 2011-09-13 Sap Ag Service accounting method and apparatus for composite service
US20100157822A1 (en) * 2008-12-22 2010-06-24 Sap Agdietmar-Hopp-Allee Service accounting method and apparatus for composite service
US20120023213A1 (en) * 2009-02-05 2012-01-26 Ipanema Technologies Method for management of data stream exchanges in an autonomic telecommunications network
US8949412B2 (en) * 2009-02-05 2015-02-03 Ipanema Technologies Method for management of data stream exchanges in an autonomic telecommunications network
US20120311138A1 (en) * 2011-06-03 2012-12-06 Oracle International Corporation System and method for using quality of service with workload management in an application server environment
US8849910B2 (en) * 2011-06-03 2014-09-30 Oracle International Corporation System and method for using quality of service with workload management in an application server environment
US20140136707A1 (en) * 2012-11-14 2014-05-15 International Business Machines Corporation Secure metering and accounting for cloud services
US9203709B2 (en) * 2012-11-14 2015-12-01 International Business Machines Corporation Secure metering and accounting for cloud services
US9210054B2 (en) * 2012-11-14 2015-12-08 International Business Machines Corporation Secure metering and accounting for cloud services
US20150381526A1 (en) * 2012-11-14 2015-12-31 International Business Machines Corporation Secure metering and accounting for cloud services
WO2014078227A3 (en) * 2012-11-14 2014-07-17 International Business Machines Corporation Secure metering and accounting for cloud services
US9571419B2 (en) * 2012-11-14 2017-02-14 International Business Machines Corporation Secure metering and accounting for cloud services
US9577952B2 (en) * 2012-11-14 2017-02-21 International Business Machines Corporation Secure metering and accounting for cloud services
WO2014078227A2 (en) * 2012-11-14 2014-05-22 International Business Machines Corporation Secure metering and accounting for cloud services
US20140136689A1 (en) * 2012-11-14 2014-05-15 International Business Machines Corporation Secure metering and accounting for cloud services
US11789837B1 (en) * 2021-02-03 2023-10-17 Vignet Incorporated Adaptive data collection in clinical trials to increase the likelihood of on-time completion of a trial
US11586524B1 (en) * 2021-04-16 2023-02-21 Vignet Incorporated Assisting researchers to identify opportunities for new sub-studies in digital health research and decentralized clinical trials
US11645180B1 (en) 2021-04-16 2023-05-09 Vignet Incorporated Predicting and increasing engagement for participants in decentralized clinical trials

Also Published As

Publication number Publication date
US20050132041A1 (en) 2005-06-16
US7454496B2 (en) 2008-11-18

Similar Documents

Publication Publication Date Title
US7454496B2 (en) Method for monitoring data resources of a data processing network
TWI224899B (en) Dynamic binding and fail-over of comparable web service instances in a services grid
US7701859B2 (en) Method and apparatus for identifying problem causes in a multi-node system
Debusmann et al. SLA-driven management of distributed systems using the common information model
US7200657B2 (en) Autonomic provisioning of network-accessible service behaviors within a federated grid infrastructure
US9088518B2 (en) Web services and telecom network management unification
Jacobsen et al. The PADRES publish/subscribe system
US7747730B1 (en) Managing computer network resources
US7533301B2 (en) High level operational support system
US8379538B2 (en) Model-driven monitoring architecture
US7769835B2 (en) Method and system for identifying and conducting inventory of computer assets on a network
Yu et al. QCWS: an implementation of QoS-capable multimedia web services
JP4507620B2 (en) System for routing a service request to a service instance of a service providing infrastructure that provides resources for hosting the execution of a distributed service, and method and computer program thereof
US20090319686A1 (en) Communication route selecting method and apparatus
US20040117452A1 (en) XML-based network management system and method for configuration management of heterogeneous network devices
US9317395B2 (en) Usage reporting from a cloud-hosted, distributed system
Al-Kasassbeh et al. Analysis of mobile agents in network fault management
Dianes et al. Using standards to integrate soft real-time components into dynamic distributed architectures
Rajendran et al. Analysis on the study of qos-aware web services discovery
JP2002196931A (en) Providing mechanism for service gateway
CN116346948A (en) Multi-protocol conversion method and system based on micro-service
Tian et al. Architecture for an Autonomic Web Services Environment.
US8631064B2 (en) Unified management of a hardware interface framework
Frischbier et al. Managing expectations: Runtime negotiation of information quality requirements in event-based systems
CN115658164A (en) Distributed serial arrangement service execution method and system

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: EBAY INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:029514/0177

Effective date: 20120928

AS Assignment

Owner name: PAYPAL, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EBAY INC.;REEL/FRAME:036170/0540

Effective date: 20150717