Auto adjustment of baseline on configuration change

[0001] This Application claims priority to U.S. Provisional Application Ser. No. 61/318,137 entitled “Auto Adjustment of Baseline on Configuration Change” filed Mar. 26, 2010, which is hereby incorporated by reference in its entirety. This application is also related to U.S. patent application Ser. No. 12/750,347, entitled “Method to Optimize Prediction of Threshold Violations Using Baselines,” filed Mar. 30, 2010 and which is hereby incorporated by reference.

[0002] This disclosure relates generally to the field of computer systems. More particularly, but not by way of limitation, it relates to a technique for improving performance monitoring systems.

[0003] In a performance monitoring system, a baseline is generally used to compare a metric's current behavior to past normal behavior in order to detect abnormal behavior. A metric's current behavior is considered abnormal if it is outside the normal range defined by the baseline.

[0004] Often a configuration change is necessary for an information technology system. A change in configuration may potentially cause a change in behavior in the system which may result in a performance problem. When a configuration change occurs, if a metric goes outside its baseline, an abnormality event is generally generated to alert the system administrator. Some configuration changes may cause other metrics to behave differently as well. However, these behavior changes may not be due to any real change in behavior of the system or the application being monitored. In some circumstances, false positive alerts may be generated in these metrics. In other circumstances, real problems may be obscured and no alert is generated.

[0005] Thus, it would be beneficial to provide a mechanism to capture the real problem caused by the configuration change and eliminate the false alarms.

[0006] Various embodiments provide a mechanism to automatically adjust the baseline of one or more metrics in an information technology system resulting from a configuration change.

[0007] In one embodiment, a method is disclosed to automatically adjust at least one metric's baseline when there is a configuration change. The method comprises detecting a change in a configuration parameter; identifying at least one linkage between the changed configuration parameter and at least one metric of the computer system; and adjusting a baseline for at least one metric based on at least one baseline adjusting algorithm.

[0008] In another embodiment, a performance management system is disclosed. The performance management system comprises a processor; an operator display, coupled to the processor; a storage subsystem, coupled to the processor; and a software, stored in the storage subsystem, comprising instructions that when executed by the processor cause the processor to perform the method described above.

[0009] In yet another embodiment, a non-transitory computer readable medium is disclosed. The non-transitory computer readable medium has instructions for a programmable control device stored thereon wherein the instructions cause the programmable control device to perform the method described above.

[0010] In yet another embodiment, a networked computer system is disclosed. The networked computer system comprises a plurality of computers communicatively coupled, at least one of the plurality of computers programmed to perform at least a portion of the method described above wherein the entire method described above is performed collectively by the plurality of computers.

[0017] Various embodiments provide a mechanism to automatically adjust one or more metric baselines in an information technology (IT) system based on a change in a configuration parameter. Illustrative configuration parameters include, but are not limited to: the number of CPUs, the amount of system memory, disk capacity, etc. The IT system may be either a physical system or a virtual system. According to one embodiment, a performance management system determines whether there is a change in the monitored system's configuration parameters. If a change is detected, the performance management system next determines from a knowledgebase whether there exists a linkage between the changed configuration parameter and one or more system metrics. Illustrative linkages include, but not limited to: metric “CPU utilization” is linked to configuration parameter “the number of CPUs”, metric “memory free” is linked to configuration parameter “the amount of system memory”, etc. In one embodiment, an expert system provides a knowledgebase populated with linkages between configuration parameters and system metrics. Each linkage ties a configuration parameter to one or more system metrics and can include a baseline adjusting algorithm for one or more system metrics. Where a “baseline adjusting algorithm” defines an algorithm for adjusting the baseline of the corresponding metric. If a linkage is found to exist, the system retrieves a baseline adjusting algorithm provided in the linkage and adjusts the metric's baseline using the baseline adjusting algorithm. Automatic adjustment of baselines captures the change in the metric's behavior caused by the configuration change and eliminates possible false alarms.

[0018] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be apparent to one skilled in the art, however, that the invention may be practiced without these specific details. In other instances, structure and devices are shown in block diagram form in order to avoid obscuring the invention. It will be appreciated that in the development of any actual implementation (as in any development project), numerous decisions must be made to achieve the developers' specific goals (e.g., compliance with system- and business-related constraints), and that these goals will vary from one implementation to another. It will also be appreciated that such development effort might be complex and time-consuming, but would nevertheless be a routine undertaking for those of ordinary skill in the art having the benefit of this disclosure. Moreover, the language used in this disclosure has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. Reference in the specification to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least one embodiment of the invention, and multiple references to “one embodiment” or “an embodiment” should not be understood as necessarily all referring to the same embodiment.

[0019] FIG. 1 is a block diagram illustrating example IT system 100 that employs performance monitoring in accordance with techniques described herein. An application executing in computer 110 may collect and monitor performance data from a number of IT system elements, including mainframe 140 and application 145 running thereon, data storage system 150 such as a storage area network, server 160 and application 165 running thereon, workstation 170 and application 175 running thereon, and router 180. As shown, system 100 uses network 190 for communication of monitoring data to monitoring computer 110. In some embodiments, however, some or all of the monitored devices may be directly connected to monitoring computer 110. These system elements are illustrative and by way of example only, and other system elements may be monitored. For example, instead of being standalone elements as illustrated in FIG. 1, some or all of the elements of IT system 100 monitored by the computer 110, as well as the computer 110, may be rack-mounted equipment. Although illustrated in FIG. 1 as a single computer 110, multiple computers may provide the performance monitoring functionality herein. Finally, while network 190 is represented as a single entity it may, in fact, comprise a number of different networks.

[0020] In some embodiments, operator 130 uses workstation 120 for viewing displays generated by monitoring computer 110, and for providing functionality for operator 130 to take corrective actions when an alarm is triggered. In some embodiments, operator 130 may use computer 110, instead of separate workstation 120.

[0021] A baseline is generally defined as the range of normal behavior for a system or application metric with a lower bound and an upper bound. Illustrative metrics include, but are not limited to, CPU utilization, memory free (MB), etc. According to one embodiment, the lower and upper bounds of a baseline are defined as the 5% and 95% percentile lines based on the metric's operating range for a specified time period (e.g., one day, one week or one month). Often times, the resolution of the baseline may not match the resolution of the metric's data points. For example, the metric data may be collected at 1 minute intervals, while the baseline is calculated every hour. The baseline may be continuously reshaped by factoring in the current data. The exact formula used to recalculate the baseline will determine how quickly it adjusts based on the metric's movements. FIG. 2 is an example baseline for one instance of a processing unit or CPU utilization metric. A metric's current behavior is generally considered abnormal if it is outside the normal range defined by the baseline's upper and lower bounds.

[0022] System configuration changes may occur frequently. Some configuration changes may be necessary and planned by an administrator, such as adding or removing a new CPU to the system. Other changes may occur inadvertently, such as when a CPU stops working. Sometimes, a change in a configuration parameter may cause a change in system behavior. When a configuration change occurs, if a metric goes outside its baseline, the performance management system will generate an alert for an abnormality event. If the service/application experiences significant performance degradation, these abnormal metrics can help pinpoint the problem. Some configuration changes may also cause other metrics to behave differently. Changes in behavior of these metrics may not be due to any real change in the behavior of the system or the application being monitored.

[0023] In one embodiment, a performance management system monitors resource metrics which are scaled based on a configuration parameter, such as CPU, memory, disk, etc. For example, metrics “% memory free”, “% memory available”, and “% memory used” are scaled based on the amount of memory in the system. However, if the amount of memory increases (decreases), these %-memory metrics will record proportionally lower (higher) values, even if there is no real change in the system's behavior. Such a change in the metric's measured performance could lead to a system alert.

[0024] In another embodiment, a virtual machine (VM) is moved from one physical host to another. Even if the application running on the VM behaves the same as before the move, some metrics (usually system metrics monitoring the virtual resources) can behave differently, especially, if the new host does not have the same configuration as the old host.

[0025] In yet another embodiment, an existing system is repurposed, e.g., an application is uninstalled and a new application is deployed; or the system was idle, and now it is added into a server pool for an application. Either situation can result in a metric straying from its “pre-change” baseline.

[0026] There are two kinds of problems that can result from the metric values collected post-configuration change being compared to a baseline which was shaped based on pre-configuration change data.

[0027] (1) False positives alerts. FIG. 3A illustrates one exemplary false alarm situation. As shown in FIG. 3A, prior to a change in the number of CPUs, an illustrative virtual machine's total system CPU utilization averages around 25%, and the baseline ranges from approximately 10% to approximately 40% (depending on the hour of the day). At time A the number of virtual CPUs is reduced from four to two. The reduction of the number of CPUs causes the measured CPU utilization to double. As a result, the measured CPU utilization jumps to over 50%. Since the established baseline is based on the past behavior when there were four CPUs, the performance management system would flag the CPU utilization as abnormal because the metric goes outside its baseline. As shown in FIG. 3A, the metric is flagged as having an abnormality at point B.
(2) Obscuring real changes. FIG. 4A illustrates one exemplary situation where real changes are obscured. As shown in FIG. 4A, a virtual machine having two CPUs was running around 25% CPU utilization with a baseline that ranged between approximately 10% and approximately 40%. At point C, the number of CPUs is increased from two to four. This increase in the number of CPUs causes the CPU utilization to drop from around 25% to around 12.5%. Since the baseline is based on past behavior when there were only two CPUs, the baseline would remain between 10% and 40%, when it should have been halved to approximately 5% and 20% due to the doubling of CPUs. As shown in FIG. 4A, the CPU utilization initially falls to the bottom of the baseline after the configuration change, but then a few hours later at point D, a surge in CPU usage is detected. The surge is still considered normal behavior by the performance management system because it is still within the metric's baseline.

[0028] According to one embodiment, at the time the configuration change occurs, metrics linked to that configuration parameter may have their baselines rescaled based on the old and new values of the configuration parameter. Adjustment of the baseline may eliminate the problem of metric data values collected after the configuration change being out-of-sync with the baseline which was shaped before the configuration change. Referring now to FIG. 3B, the system has the number of CPUs changed from four to two at time A just as in FIG. 3A. As shown in FIG. 3B, however, the baseline for CPU total utilization % is rescaled proportionally higher to compensate for the decreased number of CPUs. After adjustment of the baseline, the false positive seen in FIG. 3A is eliminated. Also as shown in FIG. 4B, the system has the number of CPUs changed from two to four at time C just as in FIG. 4A. As in FIG. 3B, the baseline is rescaled proportionally lower to compensate for the increase in the number of CPUs. After adjustment of the baseline, the performance management system is capable of detecting an abnormal behavior at point D that happens several hours later, unlike before in FIG. 4A. Accordingly, real problems that occur after the configuration change are now captured.

[0029] According to another embodiment, the baselines for all metrics may temporarily adapt faster to the current metric behavior. For example, when a virtual machine is moved to another physical host, the change in behavior usually cannot be defined by a simple mathematic formula. Some metrics will behave the same, but some may behave differently. One embodiment of the invention temporarily speeds up the learning of the behavior on the new host by folding in the current metric behavior into the metric's baseline at a faster rate.

[0030] Referring now to FIG. 5, one embodiment of a method for automatically adjusting baselines to a metric due to a configuration change is illustrated. The process 500 is typically initiated when a performance management system detects a change in one or more configuration parameters, step 510. In one embodiment, the performance management system performs the functionality of detecting a configuration change itself. In another embodiment, a software application (Agent) may be setup and running to detect a configuration change.

[0031] In step 520, the performance management system indentifies whether there is a linkage between the changed configuration parameter and the system's metrics. According to one embodiment, an expert system provides a knowledgebase populated with linkages between configuration parameters and metrics. The linkage information may be sourced directly from the data collection metadata which self-describes the relationships between the configuration parameters and metrics. A system developer may also provide the linkage information during the development stage of the performance management system. Each linkage specifies a baseline adjusting algorithm to be used to adjust the metric's baseline based on the old and new values of the configuration parameter. In one embodiment, there are several types of predefined baseline adjusting algorithms. By way of example, predefined baseline adjusting algorithms include these types:

• • [0032] RESCALE_BASELINE. This type of baseline adjusting algorithm comprises a mathematical formula. The performance management system recalculates the new baseline for the metric based on the mathematical formula provided in the linkage. One exemplary RESCALE_BASELINE formula is: new baseline value=old baseline value*(old configuration parameter value/new configuration parameter value).
  • [0033] ADAPT_BASELINE. In this type of baseline adjusting algorithm, the performance management system will temporarily speed up calculating a metric's baseline if the configuration parameter's metric linkage has a baseline adjusting algorithm of ADAPT_BASELINE. For example, if the performance management system calculates a metric's baseline every hour before a configuration change, after the configuration change, the baseline may be recalculated every 5 minutes in the next six hours.
  • [0034] RESET_BASELINE. In this type of baseline adjusting algorithm, the performance management system will discard baseline values collected before the configuration change, and calculate the baseline using only the data collected after the configuration change.
  • [0035] Other baseline adjusting algorithm may include custom formulas, e.g., the baseline for free memory (in MB) may be recalculated by shifting it higher (lower) based on the increase (decrease) in the maximum memory.

[0036] Table 1 illustrates some example linkages between configuration parameters and metrics. As shown in Table 1, a change in a configuration parameter could impact one or more system metrics. The performance management system identifies all existing linkages between each changed configuration parameter and the various system metrics.

[0037]

TABLE 1
Example Configuration Parameter - Metric Linkages
Configuration		Baseline Adjusting
Parameter	Linked Metric	Algorithm
Number of CPUs	CPU Utilization (%)	New CPU % Baseline = Old
		CPU % Baseline * (Old Number
		of CPUs/New Number of CPUs)
System Memory	Memory Free (%)	New Memory Free % Baseline =
		Old Baseline * (Old System
		Memory/New System Memory)
System Memory	Memory Free (MB)	New Memory Free Baseline
		(MB) = Old Baseline + (New
		System Memory − Old System
		Memory)
Virtual System's	* (All Metrics)	ADAPT_BASELINE
Physical Host		(see above)

[0038] In one embodiment, there exist multiple linkages between a changed configuration parameter and a system metric in the knowledgebase, each linkage has a baseline adjusting algorithm. In another embodiment, multiple metrics use one baseline adjusting algorithm.

[0039] In step 530, the performance management system retrieves the baseline for each of the metrics identified in step 520. In step 540, the performance management system retrieves a baseline adjusting algorithm for each of the metric baselines retrieved in step 530. As shown in Table 1, each linkage in Table 1 has a baseline adjusting algorithm corresponding to the linked metric. In step 550, the performance management system adjusts the baseline by applying the baseline adjusting algorithm retrieved in step 540.

[0040] In one embodiment, the baseline adjusting algorithm retrieved is a mathematical formula. The performance management system adjusts the metric's baseline by applying the identified formula. For example, as shown in FIG. 3B, the new baseline is calculated using the formula:
New CPU % Baseline=Old CPU % Baseline*(Old # of CPUs−New # of CPUs).
As a result, the adjusted baseline in the situation where the number of CPUs was reduced from four to two, is rescaled higher than the original baseline. Similarly, as shown in FIG. 4B, where the number of CPUs changed from two to four, the adjusted baseline is rescaled lower to compensate the increase of CPUs.

[0041] In another embodiment, the baseline adjusting algorithm retrieved is ADAPT_BASELINE. According to this embodiment, the performance management system will temporarily increase the speed at which the baseline is reshaped to reflect the metric's current behavior. For example, the metric data may be collected at 1 minute intervals, while the baseline may be calculated at 1 hour intervals. After receiving the baseline and the baseline adjusting algorithm (which is ADAPT_BASELINE in this case), the performance management system may recalculate the baseline every 5 minutes instead of every hour. Because of the increased update rate, more current data are taken into account when calculating the baseline.

[0042] In yet another embodiment, the baseline adjusting algorithm is in some form of custom formulas developed by a user, such as, the system administrator of the performance management system. The performance management system adjusts the baseline using the baseline adjusting algorithm. By way of example, in a situation where more memory is added to the system, the baseline for metric “Memory Free (MB)” may be adjusted using a custom formula:
New Memory Free Baseline (MB)=Old Baseline+(New System Memory−Old System Memory).
The adjusted baseline shifts higher to reflect the increase of system memory. Other forms of custom formulas may also be used. In one embodiment, the system allows an administrator of a performance management system to change the baseline adjusting algorithm for each metric.

[0043] In still another embodiment, the baseline adjusting algorithm retrieved is RESET_BASELINE. According to this embodiment, the performance management system will reset the baseline. The old baseline values before the configuration change will be discarded. The performance management system recalculates the baseline using only the data collected after the configuration change.

[0044] In general, only the metric's baseline for the future is adjusted. The historic data of the metric's baseline prior to the configuration change is not modified.

[0045] Referring now to FIG. 6, example computer 600 for use in adjusting metric baselines is illustrated in block diagram form. Example computer 600 comprises system unit 610 which may be optionally connected to an input device or system 660 (e.g., keyboard, mouse, touch screen, etc.) and display 670. Program storage device (PSD) 680 is included with system unit 610. Also included with system unit 610 is network interface 640 for communication via a network with other computing and corporate infrastructure devices (not shown). Network interface 640 may be included within system unit 610 or be external to system unit 610. In either case, system unit 610 may be communicatively coupled to network interface 640. Program storage device 680 represents any form of non-volatile storage including, but not limited to, all forms of optical and magnetic storage, including solid-state, storage elements and removable media. Program storage device 680 may be used for storage of software to control system unit 610 in, data for use by the computer 600, or both.

[0046] System unit 610 may be programmed to perform methods in accordance with this disclosure (an example of which is shown in FIG. 5). System unit 610 comprises processor unit (PU) 620, input-output (I/O) interface 650 and memory 630. Processing unit 620 may include any programmable controller device including, for example, one or more members of the Intel Atom®, Core®, Pentium® and Celeron® processor families from the Intel, Sun SPARC® processor families from Sun and the Cortex and ARM processor families from ARM. (INTEL, INTEL ATOM, CORE, PENTIUM, and CELERON are registered trademarks of the Intel Corporation. CORTEX is a registered trademark of the ARM Limited Corporation. ARM is a registered trademark of the ARM Limited Company. SPARC is a registered trademark of the SPARC International, Inc.) Memory 630 may include one or more memory modules and comprise random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), programmable read-write memory, and solid-state memory. One of ordinary skill in the art will also recognize that PU 620 may also include some internal memory including, for example, cache memory.

[0047] Various changes in the components as well as in the details of the illustrated operational method are possible without departing from the scope of the following claims. For instance, the illustrative system of FIG. 6 may be comprised of more than one computer communicatively coupled via a communication network, wherein the computers may be mainframe computers, minicomputers, workstations or any combination of these. Further, monitored applications may execute on multiple hardware platforms. Such a network may be composed of one or more local area networks, one or more wide area networks, or a combination of local and wide-area networks. In addition, the networks may employ any desired communication protocol and further may be “wired” or “wireless.” In addition, acts in accordance with FIG. 5 may be performed by a programmable control device executing instructions organized into one or more program modules. A programmable control device may be a single computer processor, a special purpose processor (e.g., a digital signal processor, “DSP”), a plurality of processors coupled by a communications link or a custom designed state machine. Custom designed state machines may be embodied in a hardware device such as an integrated circuit including, but not limited to, application specific integrated circuits (“ASICs”) or field programmable gate array (“FPGAs”). Storage devices suitable for tangibly embodying program instructions include, but are not limited to: magnetic disks (fixed, floppy, and removable) and tape; optical media such as CD-ROMs and digital video disks (“DVDs”); and semiconductor memory devices such as Electrically Programmable Read-Only Memory (“EPROM”), Electrically Erasable Programmable Read-Only Memory (“EEPROM”), Programmable Gate Arrays and flash devices.

[0048] It is to be understood that the above description is intended to be illustrative, and not restrictive. For example, the above-described embodiments may be used in combination with each other. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention therefore should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.”