CA2548795A1 - Method for multidimensional visual correlation of systems management data - Google Patents

Abstract

A method, apparatus, and computer program product for monitoring the performance of a system. The mechanism of the present invention provides an interface in the form of a graphical user interface (GUI) to communicate multiple layers of system performance data to an operator. An operator monitors this display of infoiirrition and uses it to determine how to adjust the system to optimize system perfoiiuance. This mechanism of the present invention provides immediate feedback to an operator by displaying a trail of metric points, wherein the metric points indicate the status of system performance over a period of time. In this rrnnner, the display mechanism of the present invention immediately conveys to an operator whether the system is operating within predefined margins, the results of performance adjustments crude to the system, as well as predictions or trends for the system.

Description

Description METHOD FOR MULTIDIMENSIONAL VISUAL
CORRELATION OF SYSTEMS MANAGEMENT DATA
Technical Field [001] The present invention relates to computer and data processing systems, and, more particularly, to the field of network computing. Even more particularly, the present invention relates to monitoring system performance and communicating detailed system performance data via an enhanced graphical user interface.
Background Art [002] Computers have increasingly become a necessity of modern life, both for in-dividuals as well as businesses. With the emergence of the Internet and with ever increasing competition in the marketplace, stand alone computers no longer provide the necessary services and capabilities users require. Many, if not most, companies need to share information between multiple groups, often located in different cities or even different countries. Networked computers provide for the transfer of information between computers, possibly dissimilar, joined together by means of gateways that handle data transfer and the conversion of messages from the sending computer to the protocols used by the receiving comp>zter (with packets if necessary).

[003] Consequently, networks have become cultural fixtures as sources of inforrr~ation have continued to enlarge and grow. However, as systems have continued to expand, their complexity has increased, malting management of the networks difficult.
For example, many companies employ networks that contain not several computers and devices, but hundreds of thousands of devices. Systems may comprise interrelated components, such as hardware, software, networks, data, connections, databases, processes, and procedures. Processes troy use multiple technologies of disparate types.
To manage these systems, an operator pray monitor system performance in order to know where to update, configure, and adjust the system to increase customer sat-isfaction.

[004] Current methods of monitoring and displaying system performance information consist of providing a static-type interface to an operator. The information is typically presented to the operator in a "stop light" or "speedometer" type of representation.
However, these static interfaces merely provide a quick overview of the current status of the system. To obtain more detailed information re~.rding a potential problem, the operator must access reports or printouts containing the additional information.

[005] Therefore, it would be advantageous to have a method, apparatus, and computer program product for providing an enhanced display for communicating system performance data, whereby multiple layers of system performance information may be communicated to an operator in a quick and efficient rmnner.
Disclosure of Invention [006] The present invention provides a method, apparatus, and computer program product for monitoring the performance of a system. The mechanism of the present invention provides an interface in the form of a graphical user interface (GUI) to communicate multiple layers of system performance data, to an operator. An operator monitors this display of information and uses it to determine how to adjust the system to optimize system performance. This mechanism of the present invention provides immediate feedback to an operator by displaying a trail of metric points, wherein the metric points indicate the status of system performance over a period of time. In this manner, the display mechanism of the present invention immediately conveys to an operator whether the system is operating within predefined margins, the results of performance adjustments made to the system, as well as predictions or trends for the system. As a result, multiple layers of system performance information may be communicated to an operator in a quick and efficient manner.
Brief Description of the Drawings [007] The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

[008] Figure 1 is a representation of a network of data processing systems in which the present invention rmy be implemented;

[009] Figure 2 is a block diagram of a data processing system that rmy be implemented as a server in accor~nce with a preferred embodiment of the present invention;
[O10] Figure 3 is a block diagram of a data processing system in which the present invention may be implemented;
[O11] Figure 4 is an illustration of a known systems management graphical user interface;
[012] Figure 5 is an exemplary diagram illustrating a graphical user interface for monitoring system performance according to a preferred embodiment of the present invention;
[013] Figure 6 is a flowchart of a process for presenting multiple layers of system perforrmnce data in accordance with a preferred embodiment of the present invention;
[014] Figure 7 is an exemplary diagram illustrating a graphical user interface for displaying acceptable parameters of system operation based on service level agreements and/or orchestration action thresholds in accordance with a preferred embodiment of the present invention; and [O15] Figure 8 is a flowchart of a process for displaying acceptable parameters of system operation based on service level agreements and/or orchestration action thresholds in accordance with a preferred embodiment of the present invention.
Mode for the Invention [016] With reference now to the figures, Figure 1 depicts a pictorial representation of a network of data processing systems in which the present invention rmy be im-plemented. Network data processing system 100 is a network of computers in which the present invention may be implemented. Network data processing system 100 contains a network 102, which is the medium used to provide communications links between various devices and computers connected together within network data processing system 100. Network 102 n-~ay include connections, such as wire, wireless communication links, or fiber optic cables.
[017] In the depicted example, server 104 is connected to network 102 along with storage unit 106. In addition, clients 108,110, and 112 are connected to network 102.
These clients 108, 110, and 112 may be, for example, personal computers, transactional systems, or network computers. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to clients 108-112.
Clients 108,110, and 112 are clients to server 104, or application to application such as in transactional systems. Network data processing system 100 nay include additional servers, clients, and other devices not shown. In the depicted example, network data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that for example, use the Transmission Control Protocolllnternet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data com-munication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages. Of course, network data, processing system 100 also may be implemented as a number of different types of networks, such as for example, an intxanet, a local area network (LAN), or a wide area network (WAN). Figure 1 is intended as an example, and not as an architectural limitation for the present invention.
[018] A system may span a single or multiple networks, such as for example, network data processing system 100. Also, a system naay contain multiple client-server, client-to-client, and stand-alone data processing systems.
[019] Referring to Figure 2, a block diagram of a data processing system that may be im-plemented as a server, such as server 104 in Figure 1, is depicted in accordance with a preferred embodiment of the present invention. Data processing system 200 preferably includes a graphical user interface (GLII) that may be implemented by means of systems software residing in computer readable media in operation within data processing system 200. Data processing system 200 n~ty be a symmetric multi processor (SMP) system including a plurality of processors 202 and 204 connected to system bus 206. Alternatively, a single processor system rnay be employed.
Also connected to system bus 206 is memory controllerlcache 208, which provides an interface to local memory 209. I/O bus bridge 210 is connected to system bus 206 and provides an interface to I/O bus 212. Memory contxollerlrache 208 and I/O bus bridge 210 rrmy be integrated as depicted.
[020] Peripheral component interconnect (PCI) bus bridge 214 connected to I/O
bus 212 provides an interface to' PCI local bus 216. A number of modems rn~y be connected to PCI local bus 216. Typical PCI bus implementations will support four PCI
expansion slots or add-in connectors. Communications links to clients 108-112 in Figure 1 may be provided through modem 218 and network adapter 220 connected to PCI local bus 216 through add-in boards.
[021] Additional PCI bus bridges 222 and 224 provide interfaces for additional PCI local buses 226 and 228, from which additional modems or network adapters rmy be supported. In this manner, data processing system 200 allows connections to multiple network computers. A memory-mapped graphics adapter 230 and hard disk 232 nay also be connected to I/O bus 212 as depicted, either directly or indirectly.
[022] Those of ordinary skill in the art will appreciate that the hardware depicted in Figure 2 may vary. For example, other peripheral devices, such as optical disk drives and the like, also may be used in addition to or in place of the hardware depicted. The depicted example is not meant to imply architectural limitations with respect to the pre sent invention.
[023] The data processing system depicted in Figure 2 rrr~y be, for example, an IBM
eServer pSeries system, a product of International Business Machines Corporation in Armonk, New York, running the Advanced Interactive Executive (AIX) operating system or LINL>X operating system.
[024] With reference now to Figure 3, a block diagram illustrating a data processing system is depicted in which the present invention rruy be implemented. Data processing system 300 is an example of a client computer. Data processing system 300 preferably includes a graphical user interface (GUI) that rr~ay be implemented by means of systems software residing in computer readable media in operation within data processing system 300. Data processing system 300 employs a peripheral component interconnect (PCI) local bus architecture. Although the depicted example employs a PCI bus, other bus architectures such as Accelerated Graphics Port (AGP) and Industry Standard Architecture (ISA) rnay be used. Processor 302 and main memory 304 are connected to PCI local bus 306 through PCI bridge 308. PCI
bridge 308 also rnay include an integrated memory controller and cache memory for processor 302. Additional connections to PCI local bus 306 rmy be made through direct component interconnection or through add-in boards. In the depicted example, local area network (LAN) adapter 310, SCSI host bus adapter 312, and expansion bus interface 314 are connected to PCI local bus 306 by direct component connection. In contrast, audio adapter 316, graphics adapter 318, and audiolvideo adapter 319 are connected to PCI local bus 306 by add-in boards inserted into: e~cpansion slots.
Expansion bus interface 314 provides a connection for a keyboard and mouse adapter 320, modem 322, and additional memory 324. Srrnll computer system interface (SCSI) host bus adapter 312 provides a connection for hard disk drive 326, tape drive 328, and CD-ROM drive 330. Typical PCI local bus implementations will support three or four PCI expansion slots or add-in connectors.
[025] An operating system runs on processor 302 and is used to coordinate and provide control of various components within data processing system 300 in Figure 3.
The operating system rrny be a commercially available operating system, such as "Windows XP", which is a trademark of Microsoft Corporation. An object oriented programming system such as Java rmy run in conjunction with the operating system and provide calls to the operating system from Java programs or applications executing on data processing system 300. "Java" is a trademark of Sun Microsystems, Inc.
In-structions for the operating system, the object-oriented operating system, and ap-plications or programs are located on storage devices, such as hard disk drive 326, and rnay be loaded into rrnin memory 304 for execution by processor 302.
[026] Those of ordinary skill in the art will appreciate that the hardware in Figure 3 rrmy vary depending on the implementation. Other internal hardware or peripheral devices, such as flash read-only memory (ROM), equivalent nonvolatile memory, or optical disk drives and the like, rmy be used in addition to or in place of the hardware depicted in Figure 3. Also, the processes of the present invention rnay be applied to a multiprocessor data processing system.
[027] As another example, data processing system 300 may be a stand-alone system configured to be booiable without relying on some type of network communication interfaces. In a further example, data processing system 300 may be a personal digital assistant (PDA) device, which is configured with ROM and/or flash ROM in order to provide non-volatile memory for storing operating system files and/or user-generated data.
[028] The depicted example in Figure 3 and above-described examples are not meant to imply architectural limitations. For example, data processing system 300 also may be a notebook computer or hand held computer in addition to caking the form of a PDA.
[029] The present invention provides a method, apparatus, and instructions for monitoring system performance by providing an enhanced display of system performance data.
This enhanced display provides a quick and efficient presentation of multiple layers of system performance information to an operator.
[030] In known system management systems, perforrmnce data is displayed to operators using static representations of the system performance. Although current systems management interfaces provide a quick overview of the current status of a system, to obtain more detailed information regarding a potential problem, the operator must access reports or printouts containing this additional information.
[031] For example, a typical systems performance dada display uses a "stoplight" display for communicating system information to an operator. The stoplight consists of green, yellow, and red lights, wherein green indicates "satisfactory" performance, yellow indicates "improvement required", and red indicates "unacceptable"
perforrrnnce.
These colored lights are used to indicate the current status of the system, and whether or not the system is working within set rmrgins. For instance, if the stoplight for a particular performance indicator in the display is green, no action is required from the operator, since the green light indicates that system perforrrnnce is within satisfactory boundaries for the particular indicator.
[032] If the stoplight for a performance indicator in the display is yellow, there nay be need for concern since the system is deviating from predefined target goals.
Each change in the display is typically associated with an event or problem, as well as associated with a severity level and action to perform to remedy the event.
The action to remedy the event may be automatically triggered, or the action may be made manually by the operator in order to get the system back on track in order to meet the target goals. Examples of possible actions include no action, warning messages, emails, or pages informing the operator of the event, and an autorrntic system response, such as initiating a program to remedy the event autonomically.
[033] If the stoplight for a performance indicator is red, there rmy be a need for immediate action since the system has deviated from predefined target goals.
Immediate adjustment is required, since the service provider rrny have to pay a penalty to the customer due to unacceptable performance.
[034] However, the known stoplight representation as shown below in Figure 4 merely conveys whether or not the system is operating within defined margins. If the operator wants to obtain more detailed information re~rding a problem identified from the stoplight criterion, the operator must access a report or printout to obtain this additional information.
[035] With reference now to Figure 4, a block diagram of a known systems management graphical user interface is shown. In particular, Figure 4 illustrates a graphical user interface of Produce Plus, a business performance management software product available~from GOLEM Integrated Microelectronics Solutions GmbH, locatedw in Vienna Austria. Graphical user interface 400 array be implemented in data processing system 200 in Figure 2 andlor data processing system 300 shown in Figure 3. In this example interface, various systems performance information is displayed in graphical. user interface 400.
[036] Performance information nay include performance indictors for assessment areas such as work production 402, quality 404, overall effective efficiency 406, performancelefficiency 408, costs 410, labor performance 412, and the like.
Indicators are typically selected to focus on the most important assessment areas that an operator needs to optimize the system. The operator rnay view this performance information in the form of a "stoplight" representation, such as stoplight displays 414, to determine if there is a problem with system performance. If the operator has identified a problem, the operator rrny view corresponding reports and printouts containing more detailed information to determine adjustments to be node to system operation to correct the identified problem. The operator rr~ay determine how to adjust system operation by comparing detailed current systems information with previously defined target in-formation.

[037] As mentioned previously, the present invention provides a graphical user interface through which multiple layers of system performance information may be com-municated to an operator. A display mechanism is provided that conveys a detailed representation of current system performance. This mechanism provides immediate feedback to an operator by displaying a trail of metric points, wherein the metric points indicate the status of system performance over a period of time. In this manner, the display mechanism of the present invention immediately conveys to an operator whether the system is operating within predefined margins, the results of performance adjustments made to the system, as well as predictions or trends for the system. As a result, multiple layers of system performance infornntion may be communicated to an operator in a quick and efficient manner.
[038] Turning next to Figure 5, an exemplary diagram illustrating a graphical user interface for monitoring system performance is depicted in accordance with a preferred embodiment of the present invention. Graphical user interface 500 may be im-plemented in data processing system 200 in Figure 2 and/or data processing system 300 shown in Figure 3.
[039] As shown in Figure 5, a graphical user interface provides multiple layers of system performance data quickly and efficiently in the form of a target-type management vector display. Management vector display 500 is shown as a target rep-resentation, having a vertical and horizontal axis. Vertical 502 and horizontal axis 504 depict attributes set by the operator, such as, for example, database response time, server connect time, proxy connect time, number of requestslresponse headers delivered, and number of transactions per second. Industry baseline metrics n-~ay be used in setting the attributes. The ideal or target operational state of a monitored area of the system is the point where vertieal 502 and horizontal 504 axis meet on management vector display 500.
[040] Management vector display 500 also comprises three regions which indicate the s4tus of system operation at a particular time. Each region may be depicted using a distinct color, such as green, yellow, and red. Region 506 may indicate "satisfactory"
system performance, while region 508 rruy indicate "improvement required" and region 510 may indicate "unacceptable" system performance.
[041] Region 506, or green region, contains the target operational state. The performance status of a particular area of the system at a particular time is indicated by a single dot or metric point on management vector display 500. When the metric point, such as metric points 512, is located within green region 506, the system is deemed to be working within acceptable margins of operation. No action is required by the operator in this situation.
[042] If the metric point, such as metric points 514, is located within region 508, or yellow region, the system is determined to be outside of acceptable operation.
Ad-justments to the system operation rruy be recommended in order to steer system performance back into satisfactory margins of operation, and into green region 506. If the metric point, such as metric point 516, is located within red region 510, the system is determined to be outside of acceptable operation. Immediate adjustments to the system operation is required in this situation, since having system operation fall within red region 510 may result in a penalty for this "unacceptable" system performance.
[043] Metric points 512, 514, 516 are used to indicate the current status of system performance at a particular time. As is shown in Figure 5, metric points 512, 514, 516 depict a trail of status information determined at fixed periods of time.
This trail of status information may be used to observe system performance trends.
Management vector display 500 displays these trends in such a concise manner that many metrics rrmy be simultaneously shown on management vector display 500, each metric having its own status trail, or history.
[044] For example, each metric point in management display 500 rmy represent system performance status periodically determined every hour. In the first hour, system performance, as indicated by metric point 516, falls within red region 510.
The operator rmy then make adjustments to the system operation in an attempt to move the slate of the system from red region 510 towards the target operational state.
Subsequent metric points determined at regular intervals, such as metric points 514 within yellow region 508, indicate that system performance has improved since metric point 516 was plotted. Metric points 514 show that although the status of system performance has improved, since metric points 514 still fall within yellow region 508, additional adjustments are still needed to move the state of the system into acceptable margins. Metric points 512, which fall within green region 506, illustrate the "acceptable" system performance over several fixed intervals of time.
[045] Management vector display 500 also provides information re~rding the results of performance adjustments made to the system. For example, metric points 512, 514, 516 also illustrate the state of the system over a period of time. The operator n-iay use the metric trail to quickly view changes made to the system operation, as well as determine the effect these changes have on system performance.
[046] As shown in Figure 5, the closer a metric point is to the previous metric point, the slower the system changes over the fixed period of time. Conversely, the further apart a metric point is from the previous metric point, the faster the metric points change in value. For example, metric points 512 in green region 506 are closely spaced together.
Although metric points 512 are indicated as having acceptable performance, the operator rnay make adjustments to the system operation in order to move the metric points closer towards the target operational state in the center of green region 506. The small effects of these adjustments made over a fixed period of time are conveyed via metric points 512, which show a slow rate of change since metric points 512 are plotted close together. In contrast, the distance between metric points 516 and 514 il-lustrates a large change in system performance over the same fixed period of time.
[047] In some situations, as an operator adjusts system operation parameters to improve performance and move towards the target operational state, these adjustments may have some unintended consequence, such as drifting away from the target operational state. The mechanism of the present invention provides the operator with multiple layers of system performance data, including the current state of system performance, the results of previous performance adjustments, and a prediction/trend of future system performance in a quick and efficient manner.
[048] Furthermore, vertical axis 502 and horizontal axis 504 are not necessarily to scale.
~2i~Ianagement vector display 500 may take any shape, including the rtiund target form as shown in Figure 5. In addition, the regions within management vector display 500 such as green region 506, yellow region 508, and red region 510, naay be any size or shape. For example, it r~ty be advantageous to have more space devoted to those regions having parameters where actions should be taken by the operator.
[049] Although management vector display 500 is shown in Figure 5 as a single system rmnagement display, management vector display 500 may be presented on a panel display together with additional management vector displays, each representing system perforrrnxice and txends for a different set of variables. In this mnner, the graphical user interface presented to an operator troy comprise multiple target rr~anagement vector displays on the same panel, each monitoring a different area of system performance.
[050] Turning now to Figure 6, a flowchart of a process for presenting multiple layers of system performance data is shown in accordance with a preferred embodiment of the present invention. The process illustrated in Figure 6 rrmy be implemented in a data processing system, such as data processing system 200 in Figure Z and/or data processing system 300 shown in Figure.

[051] The process begins by querying the current configuration for monitoring the system (step 602). The system configuration may be obtained from a BIOS call, a con-figuration file, or from a console or database. Configuration data troy provide in-formation such as which items to monitor, data polling intervals, location to send data, the threshold for an action, and which action to lake. Next, system data is monitored using the instructions obtained from the BIOS call, configuration file, console, or ~tabase (step 604). System data nay then be polled at set intervals according to the system configuration (step 606) or alternatively system data rnay be sent as events. A
determination is then made as to whether the retrieved data is reportable (step 608).
Whether data is reportable rnay depend on a number of criteria, such as, for example, if the e>ata is a duplicate or if the user configuration indicates that the user is uninterested in the data, the data is not reportable and should be discarded. If the data is reportable, a determination is made as to which report to use to convey the data, and which in-for~tion to include in the report (step 610). Turning back to step 608, if the data is not reportable, the process proceeds directly to step 612, wherein the data is formatted and sent for display on the graphical user interface. An alert rr~ay be raised if the data I
nearing or crossing one of the displayed thresholds. Each of the previously represented data points are then de-emphasized using either color or intensity, the oldest point being de-emphasized the greatest. The ri~irnber of previous representations maintained and "faded" depends upon the configuration of the display and the frequency of the updated data point. For more frequently updated data points, fewer points should be displayed to prevent clutter and enhance the understandability of the trending direction of the data points. A determination is then made as to whether additional data is received (step 614). If additional data is received, the process loops back to step 606. If no additional data is received, the process terminates.
[052] The mechanism of the present invention may also be enhanced to include additional system management parameters to the operator. These parameters include boundaries derived from a service level agreement (SLA) and an orchestration action threshold. A
service level agreement is an informal contract between a service provider and a customer that defines the terms of the service provider's responsibility to the customer.
The service level agreement also includes the type and extent of remuneration if those responsibilities are not met. Orchestration defines a set of rules for a process flow, wherein processes are executed according to these defined rules in order to achieve a common goal between participants in the process. These rules rnay be used by the system to "orchestrate the response" to changes in the system.

[053] Turning now to Figure 7, an exemplary diagram illustrating a graphical user interface for displaying acceptable parameters of system operation based on service level agreements and/or orchestration action thresholds is depicted in accordance with a preferred embodiment of the present invention. Graphical user interface 700 may be implemented in data processing system 200 in Figure 2 and/or dais processing system 300 shown in Figure 3.
[054] As shown in Figure 7, a graphical user interface provides additional layers of system management data, including service level agreements and/or orchestration action thresholds. Service level agreements and/or orchestration action thresholds are defined in management vector display 700. As also described in Figure 5, management vector display 700 comprises three regions that indicate the status of system operation at a particular time. Each region may be depicted using a distinct color, such as green, yellow, and red. Region 706 nmy indicate "satisfactory"
system performance, while region 708 rrny indicate "improvement required" and region rmy indicate "unacceptable" system performance.
[055] SLA boundary 718, presented within management vector display 700, represents the metric boundary of a service level agreement at the current time. Although SLA
boundary 718 is shown in a particular location on management vector display 700, SLA boundar~~ 718 n~.y change according to according to predefined time periods::-For example, an operator may monitor the load on a CAT and response time using a service level agreement as represented by SLA boundary 718. As CPU load and response time rrmy vary according to customer usage, the boundaries of a service level agreement ~y be altered according to predefined time periods. For instance, the boundaries of a service level agreement during an anticipated period of heavy customer usage, such as during a typical work day, rnay be different than the boundaries set for an anticipated period of light customer usage, such as around 12 o'clock midnight.
[056] As mentioned previously, the performance status of a particular area of the system at a particular time is indicted by a single dot or metric point, such as metric point 716 . SLA boundary 718, representing the metric boundary of the service level agreement at the current time, allows the operator to monitor and measure service level perfor~nce. As a metric point, such as metric point 716, is plotted on management vector display 700, the operator rruy determine whether system performance is in adherence with the service level agreement. If the metric point is plotted outside of SLA boundary 718, the system is not performing within defined parameters of operation. As a result, the operator must make adjustments to system operation to get the system back on track in order to adhere to the parameters of operation defined in the service level agreement. A penalty for not meeting the parameters of the agreement nay also have to be paid due to the unacceptable performance.
[057] If the metric point is plotted within SLA boundary 718, the system is performing within defined parameters of operation at the current time, and no penalty will result.
For example, metric point 716 is plotted within red region 710. Typically, if system perforn~ance falls within red region 710, the operator will determine that current system performance is unacceptable and a penalty will result. However, using the additional layer of system information in SLA boundary 718, the operator rmy determine that, although metric point 716 falls within red region 710, system performance is still within acceptable limits, since metric point 716 is plotted within the current service level agreement boundary 700. Thus, even though system performance appears to be unacceptable from the plotting of metric point 716 in red region 710, the operator may quickly and efficiently determine that system performance is within acceptable limits according to the parameters in the service level agreement.
[058] Orchestration action boundary 720, presented within management vector display 700, represents the metric boundary of an orchestratio~'action threshold boundary at the current time. Although orchestration action boundary 720 is shown in a particular location on management vector display 700, orchestration action boundary 720 may change according to the demand on system resources. Orchestration allows users to manipulate their IT environment in real time, according to defined policies, to achieve desired goals. Orchestration "senses" an increase in the demand for resources and auto-rrptically takes action to reallocate those resources accordingly, and provisions them throughout the entire system. Thus, the system "orchestrates" the activities necessary to automatically meet required service levels.
[059] Orchestration boundary 720 defines whether an autormtic workflow correction will be invoked to adjust system performance, or whether a manual correction is required.
For example, when metric point 716 is plotted on rrunagement vector display 700, the operator may determine that immediate adjustment is required since metric point falls within "unacceptable" red region 710. However, since metric point 716 also falls outside of orchestration boundary 720, the adjustment to the system will be made auto-matically, without operator intervention. A workflow correction is aztomatically invoked to reallocate system resources accordingly.

[060] In contrast, when metric point 714 is plotted on rrrunagement vector display 700, the operator may determine that an adjustment should be nude since metric point falls within "improvement required" yellow region 708. However, since metric point also falls within orchestration boundary 720, the operator must manually make the necessary adjustments to the system to improve system performance. Thus, as or-chestration allows the system to autonomically correct itself, orchestration boundary 720 provides an operator with an additional layer of quick and efficient feedback re~rding system performance.
[061] Turning now to Figure 8, a flowchart of a process for displaying acceptable parameters of system operation based on service level agreements and/or orchestration action thresholds is shown in accordance with a preferred embodiment of the present invention. The process illustrated in Figure 8 may be implemented in a data processing system, such as data processing system 200 in Figure 2 and/or data processing system 300 shown in Figure.
[062] The process begins by using a real time monitoring agent to monitor the polled data (step 802). System performance data troy be obtained by polling system data, such as polled data obtained in step 606 in Figure 6, although other methods of obtaining system performance data nay be used. The poll monitor may be a push or pull monitor (i.e., polling or messagir!g). The polled data nay include information such as the response time data from the server. Referring to the terms and rules in the SLA data, the polled data rnay be averaged if the number of transactions is high and the transactions are le~l under the SLA terms, or the polled data rmy be used as a best case/worst case scenario. Next, the SLA boun~ries for the type of display graphic (e.g., server response time) are calculated (step 804). The SLA boundaries rrrry be calculated using the contractual data (rules) in the SLA agreement. The contractual data in the SLA agreement rusty be stored as XML (extensible markup language), for example, and may be a standard XML, such as OASIS (Or~nization for the Ad-vancement of Structured Inforrrution Standards) eb~L,. The status markers indicating system performance are then updated based on the current status (step 806).
For example, the status markers rr~ay be updated like a fading of a radar return, although other updating schemes are possible to indicate the current status of the system, such as using colors fading using a rainbow scale. In the radar return example, the current system perforrrunce marker may be highlighted, while the other previous markers are faded by at least one increment. A determination is then made as to whether real time monitor is still receiving polled data (step 808). If so, the process loops back to step 802 and the process continues. Turning back to step 808, if is it determined that real time monitor is no longer receiving polled data, then the process terminates.
[063] Thus, the present invention provides an improved method, apparatus, and computer instructions for monitoring system performance and communicating detailed system perforrmnce daia via an enhanced graphical user interface. The mechanism of the present invention rr~ay assist system operators in monitoring and managing the performance of the system, which ultimately rruy result in more satisfied customers.
The mechanism of the present invention provides an interface in the form of a graphical user interface (GUI) to communicate multiple layers of system performance data to an operator. An operator monitors this display of information and uses it to determine how to adjust the system to optimize system performance.
[064] The present invention offers advantages over the known systems rmnagement systems since current methods of monitoring and displaying system performance in-formation consist of providing a static-type interface to an operator. Known system performance displays, such as the "stoplight" representation, are static, and merely provide a quick overview of the current status of a system. The present invention improves upon current systems management displays by providing an enhanced graphical user interface for communicating system performance dad; whereby multiple layers of system performance information rruy be communicated to an operator in a quick and efficient manner.
[065] It is important to note that while the present invention has been described in the context of a fully functioning daha processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally re~rdless of the particular type of signal bearing media actually used to c~Ty out the distribution. Examples of computer readable media include recordable-type media, such as a floppy disk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and transmission-type media, such as digital and analog communications links, wired or wireless communications links using transmission forms, such as, for example, radio frequency and light wave transmissions. The computer readable media nay take the form of coded formats that are decoded for actual use in a particular data processing system.
[066] The description of the present invention has been presented for purposes of il-lustxation and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
[067] CLAUSES
[068] 1. A method for monitoring system performance and communicating acceptable parameters of system operation via an enhanced graphical user interface, comprising:
obtaining system performance data to determine the current status of the system; de-termining a display graphic; calculating boundaries of acceptable system operation for the display graphic; updating system performance status markers, which indicate system performance at particular points in time, based on the current status of the system; and displaying the updated system performance status n~rkers and the acceptable boundaries of system operation within a target-type management vector display, wherein the display includes regions representing levels of system performance.
[069] 2. The method of clazse 1, wherein the boundaries are calculated using the contractual data in a service level agreement.
[070] 3. The method of clazse 2, wherein the contractual data is stored in an XML format.
[071] 4. The method of clazse 2, wherein the boundaries represent the service level agreement at a current time.
[072] 5. The method of claise 2, wherein the boundaries of the service level agreement are changed according to predefined time periods.
[073] 6. The method of clazse 2, wherein the position of a system performance status marker in relation to the service level agreement boundaries indicate whether system perforrrnnce adheres to the service level agreement.
[074] 7. The method of clazse 1, wherein the system performance status markers indicated the status of a particular area of the system at a particular time.
[075] 8. The method of clazse 1, wherein updating the status markers includes highlighting a current system performance status marker and fading the remaining system performance status markers by at least one increment.
[076] 9. The method of clazse l, wherein the boundaries of system operation are based on orchestration action thresholds.
[077] 10. The method of claxse 9, wherein the orchestration action threshold boundaries change according to system resource demand.

[078] 11. The method of chose 9, wherein an auton>atic workflow correction is invoked to adjust system performance if the current system performance status marker is located outside of the orchestration action threshold boundaries.
[079] 12. The method of clazse 1, wherein obtaining system performance data includes polling system data.
[080] 13. A system for monitoring system performance and communicating acceptable parameters of system operation via an enhanced graphical user interface, comprising: a graphical user interface; a target-type management vector display within the graphical user interface, wherein the display includes regions representing levels of system performance, boundaries indicting acceptable system operation parameters, and system performance status markers identifying the status of system performance at a particular point in time.
[081] 14. A data processing system for monitoring system performance and com-municating acceptable parameters of system operation via an enhanced graphical user interface, comprising: obtaining means for obtaining system performance data to determine the current status of the system; determining means for determining a display graphic; calculating means for calculating boundaries of acceptable system operation for the display graphic; updating means for updating system perforn~nce status markers, whicl~.indicate system performance at particular points in time, based on the current status of the system; and displaying means for displaying the updated system performance status markers and the acceptable boundaries of system operation within a target-type management vector display, wherein the display includes regions representing levels of system perfornnnce.
[082] 15. The data processing system of claise 14, wherein the boundaries are calculated using the contractual data in a service level agreement.
[083] 16. The data processing system of claxse 15, wherein the contractual data is stored in an XML format.
[084] 17. The dais processing system of clause 15, wherein the boundaries represent the service level agreement at a current time.
[085] 18. The data processing system of clazse 15, wherein the boundaries of the service level agreement are changed according to predefined time periods.
[086] 19. The data processing system of clazse 15, wherein the position of a system performance status marker in relation to the service level agreement boundaries indicate whether system performance adheres to the service level agreement.
[087] 20. The data processing system of claise 14, wherein the system performance status nnrkers indicated the status of a particular area of the system at a particular time.
[088] 21. The data processing system of claise 14, wherein updating the status markers includes highlighting a current system performance status rrnrker and fading the remaining system performance status markers by at least one increment.
[089] 22. The dad processing system of clazse 14, wherein the boundaries of system operation are based on orchestration action thresholds.
[090] 23. The data processing system of clazse 22, wherein the orchestration action threshold boundaries change according to system resource demand.
[091] 24. The data processing system of clazse 22, wherein an automatic workflow correction is invoked to adjust system performance if the current system performance status marker is located outside of the orchestration action threshold boundaries.
[092] 25. The data processing system of claise 14, wherein obtaining system performance data includes polling system data.
[093] 26. A computer program product in a computer readable medium for monitoring system performance and communicating acceptable parameters of system operation via an enhanced graphical user interface, comprising program code for executing the steps of any of clazses 1 to 12.

Claims

Claims [001] A method for monitoring system performance and communicating detailed system performance data via an enhanced graphical user interface, comprising:
querying a current monitoring configuration; monitoring system performance using instructions obtained from the current monitoring configuration; polling system data according to the current monitoring configuration; and displaying the polled system data on a graphical user interface, wherein the graphical user interface comprises a target-type management vector display including regions representing levels of system performance and a metric point within the display identifying the current status of system performance at a particular point in time.

[002] The method of claim 1, further comprising: determining whether the polled system data is reportable; selecting a report to display the polled system data;
and identifying information in the polled system data to display in the report.

[003] The method of claim 1, wherein the metric point within the target-type management vector display provides the performance status of a particular area of the system at a particular time.

[004] The method of claim 1, wherein the management vector display provides in-formation regarding results of performance adjustments to the system.

[005] The method of claim 1, wherein multiple metric points are used in the display to identify a trail of system status information determined at fixed periods of time.

[006] The method of claim 5, wherein the metric trail is used to determine the effect adjustments to system operation have on system performance.

[007] The method of claim 5, wherein the distance between consecutive metric points indicates the rate of change of system performance over a fixed period of time.

[008] The method of claim 1, wherein the target-type management vector display includes a vertical axis and horizontal axis representing user-defined attributes.

[009] The method of claim 8, wherein the user-defined attributes include transactions over time.

[010] The method of claim 8, wherein industry baseline metrics are used to set the attributes.

[011] The method of claim 8, wherein a target operational state of a particular area of the system is a point where the vertical axis and horizontal axis meet on the management vector display.

[012] The method of claim 1, wherein the target-type management vector display comprises three regions, wherein a first region indicates satisfactory performance, a second region indicates improvement required performance, and a third region indicates unacceptable performance.

[013] The method of claim 1, wherein the graphical user interface includes multiple target-type management vector displays, each display representing system performance for a different set of variables.

[014] A system for monitoring system performance and communicating detailed system performance data via an enhanced graphical user interface, comprising:
a graphical user interface; and a target-type management vector display within the graphical user interface, wherein the display includes regions representing levels of system performance, a metric point within the display identifying the current status of system performance at a particular point in time.

[015] A data processing system for monitoring system performance and com-municating detailed system performance data via an enhanced graphical user interface, comprising: querying means for querying a current monitoring con-figuration; monitoring means for monitoring system performance using in-structions obtained from the current monitoring configuration; polling means for polling system data according to the current monitoring configuration; and displaying means for displaying the polled system data on a graphical user interface, wherein the graphical user interface comprises a target-type rrunagement vector display including regions representing levels of system performance and a metric point within the display identifying the current status of system performance at a particular point in time.

[016] The data processing system of claim 15, further comprising: determining whether the polled system data is reportable; selecting a report to display the polled system data; and identifying information in the polled system data to display in the report.

[017] The data processing system of claim 15, wherein the metric point within the target-type management vector display provides the performance status of a particular area of the system at a particular time.

[018] The data processing system of claim 15, wherein the management vector display provides information regarding results of performance adjustments to the system.

[019] The data processing system of claim 15, wherein multiple metric points are used in the display to identify a trail of system status information determined at fixed periods of time.

[020] The data processing system of claim 19, wherein the metric trail is used to determine the effect adjustments to system operation have on system performance.

[021] The data processing system of claim 19, wherein the distance between consecutive metric points indicates the rate of change of system performance over a fixed period of time.

[022] The data processing system of claim 15, wherein the target-type management vector display includes a vertical axis and horizontal axis representing user-defined attributes.

[023] The data processing system of claim 22, wherein the user-defined attributes include transactions over time.

[024] The data processing system of claim 22, wherein industry baseline metrics are used to set the attributes.

[025] The data processing system of claim 22, wherein a target operational state of a particular area of the system is a point where the vertical axis and horizontal axis meet on the management vector display.

[026] The data processing system of claim 15, wherein the target-type management vector display comprises three regions, wherein a first region indicates sat-isfactory performance, a second region indicates improvement required performance, and a third region indicates unacceptable performance.

[027] The data processing system of claim 15, wherein the graphical user interface includes multiple target-type management vector displays, each display rep-resenting system performance for a different set of variables.

[028] A computer program product in a computer readable medium for monitoring system performance and communicating detailed system performance data via an enhanced graphical user interface, comprising program code for executing the steps of any of claims 1 to 13.