Patent Description:
In the realm of telemetry for monitoring health of network resources, a vast number (e.g., billions) of metrics are collected from or for resources over a period of time (e.g., each second) of a given network. Due to the number of metrics, it can become difficult to keep track of the metrics and/or related signals, health status of the network resources, etc. In addition, when services experience issues, engineers that maintain the services and/or corresponding resources may be notified by system alarms tens or hundreds of times, and the engineers do not always know which alarm is the most important to respond to, or may miss important alarms due to the sheer number of alarms. Issues can also be caused by downstream dependencies, and without the necessary domain knowledge, it can be difficult to understand what signals are affecting a given service, and/or how to locate/determine a dependency that may ultimately be causing the issue. <CIT> discloses embodiments contemplating a computer-implemented method of energy consumption and energy demand management in a building. In accordance with some embodiments, interval energy data of a specific building may be collected with a fixed time interval and paired with local historical weather data and other forms of operational data, as well as financial data including historical utility bills, utility rate structures and billing cycle dates. Paired energy interval data and the local historical weather data may be analyzed according to one or more analytic algorithms. <CIT> discloses a system, method and apparatus for data collection in an industrial production environment. The system may include, a data acquisition circuit structured to interpret a plurality of detection values, each of the plurality of detection values corresponding to input received from at least one of a plurality of input sensors which includes a detection package, each of the plurality of input sensors operatively coupled to at least one of a plurality of components of an industrial production process, a data analysis circuit structured to analyze a subset of the plurality of detection values to determine a sensor performance value of at least one of the plurality of input sensors, and an analysis response circuit structured to adjust at least one of a sensor scaling value or a sensor sampling frequency value, in response to the sensor performance value.

It is the object to the present invention to provide an improved computing device and method for seasonal performance metric alerts.

The object is achieved by the subject-matter of the independent claims.

The following presents a simplified summary of one or more examples in order to provide a basic understanding of such examples. This summary is not an extensive overview of all contemplated examples, and is intended to neither identify key or critical elements of all examples nor delineate the scope of any or all examples. Its sole purpose is to present some concepts of one or more examples in a simplified form as a prelude to the more detailed description that is presented later.

The disclosure provides an example computing device for managing seasonal performance metric alerts. The computer device may include a memory storing one or more parameters or instructions and at least one processor coupled to the memory. The at least one processor may be configured to collect a time series of an application performance metric for a period of less than two weeks. The at least one processor may be configured to determine daily distributions for each day within the time period. The at least one processor may be configured to apply a radial basis function (RBF) kernel-based change point detection to the time series to determine that the daily distributions include a weekend time period that has a different daily distribution than a time period before or after the weekend time period. The at least one processor may be configured to adjust a baseline prediction of the application performance metric for the weekend time period. The at least one processor may be configured to send an alert based on a deviation of a value of the application performance metric from the adjusted baseline prediction.

In another aspect, the disclosure provides a computer-implemented method for managing seasonal performance metric alerts. The method may include collecting a time series of an application performance metric for a period of less than two weeks. The method may include determining a daily distribution for each day within the period. The method may include applying a RBF kernel-based change point detection to the time series to determining that the daily distribution includes a weekend time period that has a different daily distribution than a time period before or after the weekend time period. The method may include adjusting a baseline prediction of the application performance metric for the weekend time period. The method may include sending an alert based on a deviation of a value of the application performance metric from the adjusted baseline prediction.

In another aspect, the disclosure provides an example non-transitory computer-readable medium, comprising code executable by one or more processors for managing seasonal performance metric alerts. The non-transitory computer-readable medium may include code for collecting a time series of an application performance metric for a period of less than two weeks. The non-transitory computer-readable medium may include code for determine daily distributions for each day of the time period. The non-transitory computer-readable medium may include code for applying RBF kernel-based change point detection to the time series to determine that the daily distribution includes a weekend time period that has a different daily distribution than a time period before or after the weekend time period. The non-transitory computer-readable medium may include code for adjusting a baseline prediction of the application performance metric for the weekend time period. The non-transitory computer-readable medium may include code for sending an alert based on a deviation of a value of the application performance metric from the adjusted baseline prediction.

To the accomplishment of the foregoing and related ends, the one or more examples comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more examples. These features are indicative, however, of but a few of the various ways in which the principles of various examples may be employed, and this description is intended to include all such examples and their equivalents.

Described herein are various examples related to detecting weekly seasonality of a metric of performance of a computer network. A computer network may provide a platform for hosting an application using various computing resources. The computer network may provide a monitoring service that provides information such as alerts to an operator of a hosted application. In an aspect, the monitoring service may be configured automatically, based on historical data, to detect deviations from an expected behavior. For instance, the monitoring service may employ dynamic thresholds to detect when a current metric deviates from an acceptable range for the metric. Such deviations may be related to a problem with the application. Accordingly, the monitoring service may provide alerts to trigger actions to remedy a problem in response to detecting a deviation.

For many metrics of a hosted application, the acceptable range for the metric is not constant. Instead, the normal values for the metric vary over time with a repeating pattern referred to as seasonality. Seasonality is defined to be the tendency of time-series data to exhibit behavior that repeats itself every fixed period of time. The term season is used to represent the period of time before behavior begins to repeat itself. For example, a daily seasonality may refer to a daily pattern of a metric. For instance, a number of requests for an application may be higher during business hours than in the middle of the night. A weekly seasonality may refer to a weekly pattern of the metric. Generally, metrics with a weekly seasonality have a different behavior on a weekend compared to other days of the week.

For a monitoring service with automatic dynamic thresholds, correctly determining the seasonality of a metric is important for accurate forecasting of expected values when setting the dynamic thresholds. In particular, a failure to identify weekly seasonality may lead to a large number of false alarms when weekend behavior differs from predicted behavior based on a daily seasonality. Automatically detecting weekend seasonality based on historical data, however, presents several difficulties. First, conventional techniques often involve correlating events over several periods to detect the seasonality. For example, a fast Fourier transform (FFT) may be applied to detect correlations over a time period. Such techniques, however, require at least two periods to correlate and accuracy is improved with a greater number of periods. In the context of an application monitoring service, multiple weeks of historical data may not be available for correlation. An application or configuration thereof may be less than several weeks old or may change such that older data not useful. In some cases, an application operator may not want to preserve historical metrics for the several weeks necessary to detect seasonality based on correlation.

Manual techniques for identifying weekly seasonality may be cumbersome and unreliable. For example, an application operator may not know how each metric is expected to behave on weekends or may not want to manually configure every metric. Assumptions about weekly seasonality, based on a calendar for example, may not be applicable in a global environment. In view of the foregoing, there is a need to determine seasonality of a time series based on shorter periods of time, e.g., based on data for a time period less than twice the seasonality of the time series.

Turning now to <FIG>, examples are depicted with reference to one or more components and one or more methods that may perform the actions or operations described herein, where components and/or actions/operations in dashed line may be optional. Although the operations described below in <FIG> are presented in a particular order and/or as being performed by an example component, the ordering of the actions and the components performing the actions may be varied, in some examples, depending on the implementation. Moreover, in some examples, one or more of the following actions, functions, and/or described components may be performed by a specially-programmed processor, a processor executing specially-programmed software or computer-readable media, or by any other combination of a hardware component and/or a software component capable of performing the described actions or functions.

<FIG> is a schematic diagram of an example of a computing system <NUM> that includes one or more networks, such as network <NUM>, having one or more time-series data loggers <NUM> for logging time-series data occurring on resources of the network <NUM>. For example, the resources of the network <NUM> may include various types of nodes, such as computing devices, databases, devices with a network-specific functionality, such as routers, bridges, firewalls, web servers, load balancers, and/or the like. Each resource may have an associated time-series data logger <NUM> to log time-series data in a time-series data repository <NUM>, where the time-series data logger <NUM> may operate on the resource or otherwise to detect communications from the resource for logging the time-series data. In an example, the service events in time-series data repository <NUM> may include various types of time-series data, such as processor or memory utilization on the resource, throughput of traffic on the resource, application-specific events that are definable by applications executing on the resource, etc..

A computing device <NUM> is provided for exposing a framework to obtain time-series data from time-series data repository <NUM>, determining weekly seasonality of the time-series data, and generating alerts for deviations from predicted behavior based on the weekly seasonality in accordance with aspects described herein. For example, computing device <NUM> can include or can otherwise be coupled with a processor <NUM> and/or memory <NUM>, where the processor <NUM> and/or memory <NUM> can be configured to execute or store instructions or other parameters related to determining daily distributions for each day within the time period; applying a radial basis function (RBF) kernel-based change point detection to the daily distributions to determine that the daily distributions include a weekend time period that is different from a mean distribution; adjusting a baseline prediction of the application performance metric for the weekend time period; and sending an alert based on a deviation of a value of the application performance metric from the adjusted baseline prediction, as described herein.

For example, processor <NUM> and memory <NUM> may be separate components communicatively coupled by a bus (e.g., on a motherboard or other portion of a computing device, on an integrated circuit, such as a system on a chip (SoC), etc.), components integrated within one another (e.g., processor <NUM> can include the memory <NUM> as an on-board component <NUM>), and/or the like. Memory <NUM> may store instructions, parameters, data structures, etc., for use/execution by processor <NUM> to perform functions described herein.

In an example, computing device <NUM> can execute an operating system <NUM> (e.g., via processor <NUM> and/or memory <NUM>) for providing an environment for executing one or more components, procedures, or applications. For example, operating system <NUM> may execute a monitoring component <NUM> for receiving time-series data from the time-series data repository <NUM>. In an aspect, the time series data may be an application performance metric. The time series data may be for a period of less than two weeks. The monitoring component <NUM> may include a distribution component <NUM> that determines daily distributions for each day within the time period, for example, by performing correlations using a FFT. The monitoring component <NUM> may include a RBF kernel component <NUM> that applies an RBF kernel-based change point detection to the time series to analyze the daily distributions. For example, the RBF kernel component <NUM> may compute a similarity measurement between two points in dimensions of infinite size and detect a mean shift value in an infinite-dimensional signal based on the similarity measurement. In an aspect, the RBF kernel component <NUM> may include an autoencoder that generates a plurality of low-dimensional vectors using temporal regularization. For instance, each of the plurality of low-dimensional vectors may correspond to a period in the time-series data. The monitoring component <NUM> may include a RBF kernel component <NUM> that determines whether the daily distribution includes a weekend time period that has a different daily distribution than a time period before or after the weekend time period. The monitoring component <NUM> may include an adjustment component <NUM> that adjusts a baseline prediction of the metric for the weekend time period. The monitoring component <NUM> may include an alerting component <NUM> that sends an alert <NUM> (e.g., to a user <NUM>) based on a deviation of a value of the metric from the adjusted baseline prediction.

<FIG> is a graphical diagram <NUM> of an example time series <NUM> having weekly seasonality. In an aspect, the distribution component <NUM> may analyze the time series <NUM> by determining a distribution for a <NUM> hour window <NUM>. The RBF kernel component <NUM> may compare the distributions to determine where a change in distributions occurs. For example, the RBF kernel component <NUM> may identify a first time period <NUM> having a first distribution with a first mean, a second time period <NUM> having a second distribution with a second mean, and a third time period <NUM> having a third distribution with a third mean. Further, the RBF kernel component <NUM> may determine that the first mean of the first time period <NUM> is similar to the third mean of the third time period <NUM>. For example, the means of two periods may be considered similar when a percent difference is less than a threshold such as <NUM>%. The RBF kernel component <NUM> may determine that the second time period <NUM> that has a different distribution and a different mean than the first time period <NUM> and the third time period <NUM> is a weekend time period.

The RBF kernel component <NUM> may detect the weekend time period based on a single occurrence. That is, since the detection of the weekend time period is based on the differences of daily distributions rather than correlations, the RBF kernel component <NUM> may detect a weekly seasonality with less than two weeks of data. For instance, the RBF kernel component <NUM> may detect a weekend time period in less than one week of data where the data includes one day before the weekend time period and one day after the weekend time period. Further, in addition to detecting a likely weekly seasonality, the RBF kernel component <NUM> detects the location of the weekend time period. As discussed in further detail below, detecting the weekly seasonality and the weekend time period may allow a forecasting system to predict a baseline behavior for a future weekend time period. Accordingly, a monitoring system may set dynamic thresholds based on the baseline behavior for the weekend time period and may avoid false alarms when the metric changes according to the weekend time period.

<FIG> is another graphical diagram <NUM> of an example time series <NUM> having a weekly seasonality. As discussed above with respect to <FIG>, the distribution component <NUM> may analyze the time series <NUM> by determining a distribution for a <NUM> hour window <NUM>. The RBF kernel component <NUM> may compare the distributions to determine where a change in distributions occurs. For example, the RBF kernel component <NUM> may identify a first time period <NUM> having a first distribution with a first mean, a second time period <NUM> having a second distribution with a second mean, and a third time period <NUM> having a third distribution with a third mean. The RBF kernel component <NUM> may identify the second time period <NUM> as a weekend time period based on a difference between the second mean of the second distribution from the first mean of the first distribution and the third mean of the third distribution. The RBF kernel component <NUM> may predict a fourth time period <NUM> will also be a weekend time period. Accordingly, when the time series <NUM> has a similar distribution during the fourth time period <NUM> as in the second time period <NUM>, the behavior may not trigger false alarms. The behavior of the time series <NUM> during the fourth time period <NUM> may be predicted based on the time periods <NUM>, <NUM>, and <NUM> before the fourth time period <NUM> begins.

<FIG> is a graphical diagram <NUM> of a time series <NUM> including dynamic thresholds <NUM>, <NUM> based on a daily seasonality of the time series <NUM>. That is, the lower dynamic threshold <NUM> and the upper dynamic threshold <NUM> may be set based on an assumption that the time series <NUM> has a daily seasonality, e.g., changes in a similar manner across a day. The time series <NUM>, however, may actually have a weekly seasonality. For example, the distribution component <NUM> and the RBF kernel component <NUM> may identify a first time period <NUM> having a first distribution, a second time period <NUM> that is a weekend time period having a second distribution, a third time period <NUM> that has a third distribution similar to the first distribution, and a fourth period <NUM> that is a weekend time period having a fourth distribution that is similar to the second distribution.

The lower dynamic threshold <NUM> may be set to a constant value of <NUM> due in part to the low values during the weekend time periods <NUM> and <NUM>. That is, because the time series has values close to <NUM> during the weekend time period <NUM> and <NUM>, it appears that a value of <NUM> may be expected at any time. The upper dynamic threshold <NUM> may be based on the range of values (e.g., a variance) of the time series <NUM> at each particular time of day. Because of the weekend time periods <NUM> and <NUM>, there are times of day when on one day (e.g., during time period <NUM>) the value of the time series <NUM> reaches a peak, while at the same time on other days (e.g., during time period <NUM>) the time series <NUM> is close to <NUM>. Accordingly, the upper dynamic threshold <NUM> may have peaks that far exceed the actual peaks of the time series <NUM> due to the apparent variance of the time series <NUM>. Accordingly, the dynamic thresholds <NUM> and <NUM> may not provide alerts even though a current metric value differs from the previously observed time series <NUM>. Additionally, a false positive scenario may occur when the behavior during the weekend period differs from the other time periods. For example, the lower dynamic threshold <NUM> may be set based on an average of daily minimums, and a minimum value on a weekend, where the values are generally lower, may fall below the lower dynamic threshold <NUM>.

<FIG> is a graphical diagram <NUM> of the time series <NUM> including dynamic thresholds <NUM>, <NUM> based on a weekly seasonality of the time series <NUM>, e.g., changes in a similar manner across a week. That is, the lower dynamic threshold <NUM> and the upper dynamic threshold <NUM> may be set based on detection of weekend time periods <NUM> and <NUM> by the distribution component <NUM> and the RBF kernel component <NUM> as discussed above.

The detection of the weekend time periods <NUM> and <NUM> may allow the adjustment component <NUM> to adjust a baseline prediction of the time series <NUM>. For example, the adjustment component <NUM> may determine separate predictions for the normal time periods <NUM> and <NUM> and the weekend time periods <NUM> and <NUM>. In another implementation, the adjustment component <NUM> may add a weekly seasonality component to the daily seasonality predictions discussed above with respect to <FIG>.

The lower dynamic threshold <NUM> may have a value of <NUM> during the weekend time periods <NUM> and <NUM>, but have an increased value in the middle of each regular day. Accordingly, the lower dynamic threshold <NUM> may generate alerts when the value of the metric remains close to <NUM> on a weekday. The upper dynamic threshold <NUM> may include peaks for each day during the normal time periods <NUM> and <NUM> and may have significantly lower values during the weekend time periods <NUM> and <NUM> that vary based on the low values observed during the weekend time periods <NUM> and <NUM>. The peaks of the upper dynamic threshold <NUM> fit the time series <NUM> more closely than the peaks of the dynamic threshold <NUM>. Due to the weekly seasonal component of the predictions, the shape of the peaks of the upper dynamic threshold <NUM> may have a shape corresponding to the time series <NUM> for the particular day. The upper dynamic threshold <NUM> includes high peaks due to the daily variation of the time series <NUM> on weekdays, but the peaks are not exaggerated due to variation between weekday and the weekend time periods <NUM> and <NUM>. Accordingly, the upper dynamic threshold <NUM> may be more likely than the upper dynamic threshold <NUM> to generate an alert when there is an unusually high spike in the value of the metric during a weekday.

<FIG> is a flowchart of an example of a method <NUM> for providing alerts based on a detected seasonality of a time series. For example, method <NUM> can be performed by the computing device <NUM>, and is accordingly described with reference to <FIG>, as a nonlimiting example of an environment for carrying out method <NUM>.

In block <NUM>, the method <NUM> may include collecting a time series of an application performance metric for a period of less than two weeks. In an aspect, for example, the computing device <NUM> and/or the processor <NUM> may execute the monitoring component <NUM> to collect a time series of an application performance metric for a period of less than two weeks. For instance, the monitoring component <NUM> may collect the time series from the time-series data logger <NUM> and/or the time-series data repository <NUM>. The time series may be for a period of less than two weeks. For example, the period may be <NUM> week. In an implementation, the period may be as little as <NUM> days when the weekend period is one day.

In block <NUM>, the method <NUM> may include determining a daily distribution for each day of the time series. In an aspect, for example, the computing device <NUM> and/or the processor <NUM> may execute the monitoring component <NUM> and/or the distribution component <NUM> to determine the daily distributions for each day of the time series. For instance, the distribution component <NUM> may utilize a sliding window of <NUM> hours to determine the daily distributions. For instance, the distribution component <NUM> may determine correlations using a fast Fourier transform (FFT).

In block <NUM>, the method <NUM> may include applying a RBF kernel-based change point detection to the time series to determine that the daily distributions include a weekend time period that has a different daily distribution than a time period before or after the weekend time period. In an aspect, for example, the computing device <NUM> and/or the processor <NUM> may execute the monitoring component <NUM> and/or the RBF kernel component <NUM> to apply the RBF kernel-based change point detection to the time series to determine that the daily distributions include a weekend time period <NUM>, <NUM>, <NUM>, <NUM> that has a different daily distribution than a time period before or after the weekend time period (e.g., time periods <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>). In an implementation, the RBF kernel-based change point detection may include computing a similarity measurement between two points in dimensions of infinite size, and detecting a mean shift value in an infinite-dimensional signal based on the similarity measurement. Further, the RBF kernel component <NUM> may determine the weekend time period based on a length of the different time periods. The RBF kernel component <NUM> may determine that a period that is different for one or two days is the weekend time period. The length may be defined by a number of hours (e.g., <NUM>-<NUM> hours, preferably <NUM>-<NUM> hours). The RBF kernel component <NUM> may additionally confirm the weekend time period based on comparison of different time periods. For example, at sub-block <NUM>, the block <NUM> may optionally include identifying a first time period before the weekend time period. For instance, the RBF kernel component <NUM> may identify the time period <NUM>, <NUM>, or <NUM>. At sub-block <NUM>, the RBF kernel component <NUM> may include identifying a second time period after the weekend time period. For instance, the RBF kernel component <NUM> may identify the time period <NUM>, <NUM>, or <NUM> as being a time period after the weekend time period. At sub-block <NUM>, the RBF kernel component <NUM> may optionally include determining that the daily distribution for the first time period is similar to the daily distribution of the second time period and different than the daily distribution of the weekend time period. For instance, the RBF kernel component <NUM> may determine that the daily distribution for the time period <NUM> is similar to the daily distribution of the time period <NUM> and different than the daily distribution for the weekend time period <NUM>. In an aspect, the RBF kernel component <NUM> may determine that the daily distribution of the first time period <NUM> is similar to the daily distribution of the third time period <NUM> by removing the weekend time period <NUM> and determining whether the RBF kernel-based change point detection detects a change between the first time period <NUM> and the third time period <NUM>.

In an implementation, the RBF kernel component <NUM> may utilize an autoencoder to generate a plurality of low-dimensional vectors using temporal regularization, wherein each of the plurality of low-dimensional vectors correspond to a period in the time series data (e.g., <NUM> hours). Additionally, the autoencoder may determine whether a change point occurs in a seasonal pattern of the time series data by determining whether the one or more change points occur in a seasonal pattern of the time series data based on the plurality of low-dimensional vectors. In a further example, generating the plurality of low-dimensional vectors using temporal regularization may include generating, by an encoder, an input vector for each period of the time series data, calculating a minimized summated difference between each period of the time-series data and a reconstructed version of the input vector, calculating a summated difference between two consecutive encoded periods of the time-series data, and generating, by a decoder, the plurality of low-dimensional vectors based on the minimized summated difference between each period of the time series data and the reconstructed version of the input vector and the summated difference between the two consecutive encoded periods of the time series data.

In a further example, generating the input vector for each period of the time series data further includes calculating an inner product between a weight matrix for a current period of the time-series data and an output of a previous weight matrix for a previous period of the time-series data, applying a non-linear function to the inner product, and determining corresponding parameters for the weight matrix based on a gradient descent using back-propagation.

In a further example, calculating the summated difference between the two consecutive encoded periods of the time-series data further includes applying regularization on one or more weights of a network, and applying a penalization a difference between a low-dimensional vector of two consecutive periods.

In a further example, determining whether the one or more change points occur in the seasonal pattern of the time-series data based on the plurality of low-dimensional vectors further includes determining a location for each of the plurality of low-dimensional vectors; and performing a hierarchical clustering procedure for the plurality of low-dimensional vectors based on the location for each of the plurality of low-dimensional vectors.

In a further example, performing the hierarchical clustering procedure for the plurality of low-dimensional vectors based on the location for each of the plurality of low-dimensional vectors may further include calculating a silhouette score based on a mean pairwise distance of the location for each of the plurality of low-dimensional vectors in a cluster and a mean distance of each location for each of the plurality of low-dimensional vectors in a neighboring cluster, determining whether the silhouette score satisfies a hyperparameter threshold, and selecting a partition based on a determination that the silhouette score satisfies the hyperparameter threshold.

In block <NUM>, the method <NUM> may include adjusting a baseline prediction of the application performance metric for the weekend time period. In an aspect, for example, the computing device <NUM> and/or the processor <NUM> may execute the monitoring component <NUM> and/or the adjustment component <NUM> to adjust the baseline prediction of the application performance metric for the weekend time period <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. For example, at sub-block <NUM>, the block <NUM> may include increasing a predicted range of the metric during the weekend time period. For instance, the adjustment component <NUM> may increase the predicted range by decreasing the lower dynamic threshold <NUM> or increasing the upper dynamic threshold <NUM> for a weekend time period. As another example, in sub-block <NUM>, the block <NUM> may include inferring a weekly seasonality based on the weekend time period. The baseline prediction may be based on the weekly seasonality. For instance, the adjustment component <NUM> may infer a weekly seasonality for the time series <NUM>. The adjustment component <NUM> may then determine the lower dynamic threshold <NUM> and the upper dynamic threshold <NUM> based on the weekly seasonality.

In block <NUM>, the method <NUM> may include sending an alert based on a deviation of a value of the application performance metric from the adjusted baseline prediction. In an aspect, for example, the computing device <NUM> and/or the processor <NUM> may execute the monitoring component <NUM> and/or alerting component <NUM> to send the alert <NUM> to a user <NUM> based on a deviation of a value of the application performance metric from the adjusted baseline prediction. For example, the alerting component <NUM> may send the alert <NUM> when a current value of the metric is outside of a range defined by the lower dynamic threshold <NUM> and the upper dynamic threshold <NUM>. In an aspect, for the weekend time period <NUM>, <NUM>, <NUM>, the alerting component <NUM> may silence alerts, for example, when the value of the metric during the weekend time period is unpredictable based on the available time series.

In block <NUM>, the method <NUM> may optionally include adjust computing resources for the application in response to sending the alert. In an aspect, for example, the computing device <NUM> and/or the processor <NUM> may execute the monitoring component <NUM> to adjust computing resources for the application in response to sending the alert <NUM>. For instance, the monitoring component <NUM> may request additional virtual machines for the application. As another example, the monitoring component <NUM> may rollback a deployment if the deployment is a cause of the problem. As another example, the monitoring component <NUM> may decide to restart a web role or a service. In an aspect, the alert <NUM> may indicate a suggested or default action and allow an operator to approve or reject the action.

In block <NUM>, the method <NUM> may optionally include confirming a seasonality by applying a FFT seasonality computation to the time series of the application performance metric after collecting the time series of the application performance metric for a period greater than two weeks. In an aspect, for example, the computing device <NUM> and/or the processor <NUM> may execute the monitoring component <NUM> to confirm the weekly seasonality of the time series <NUM>, <NUM>, or <NUM> by applying a FFT seasonality computation to the time series <NUM>, <NUM>, or <NUM> of the application performance metric after collecting the time series of the application performance metric for a period greater than two weeks. That is, once more than two weeks of data is available, the FFT seasonality computation may be able to correlate data for multiple periods to confirm a weekly seasonality.

<FIG> illustrates an example of computing device <NUM> including additional optional component details as those shown in <FIG>. In one example, computing device <NUM> may include processor <NUM> for carrying out processing functions associated with one or more of components and functions described herein. Processor <NUM> can include a single or multiple set of processors or multi-core processors. Moreover, processor <NUM> can be implemented as an integrated processing system and/or a distributed processing system.

Computing device <NUM> may further include memory <NUM>, such as for storing local versions of applications being executed by processor <NUM>, related instructions, parameters, etc. Memory <NUM> can include a type of memory usable by a computer, such as random access memory (RAM), read only memory (ROM), tapes, magnetic discs, optical discs, volatile memory, non-volatile memory, and any combination thereof. Additionally, processor <NUM> and memory <NUM> may include and execute an operating system executing on processor <NUM>, one or more applications, such as monitoring component <NUM>, distribution component <NUM>, RBF kernel component <NUM>, adjustment component <NUM>, alerting component <NUM> and/or components thereof, as described herein, and/or other components of the computing device <NUM>.

Further, computing device <NUM> may include a communications component <NUM> that provides for establishing and maintaining communications with one or more other devices, parties, entities, etc. utilizing hardware, software, and services as described herein. Communications component <NUM> may carry communications between components on computing device <NUM>, as well as between computing device <NUM> and external devices, such as devices located across a communications network and/or devices serially or locally connected to computing device <NUM>. For example, communications component <NUM> may include one or more buses, and may further include transmit chain components and receive chain components associated with a wireless or wired transmitter and receiver, respectively, operable for interfacing with external devices. For example, communications component <NUM> can carry communications between the monitoring component <NUM>, etc. executing on another device (or the same device), etc., as described in various examples herein.

Additionally, computing device <NUM> may include a data store <NUM>, which can be any suitable combination of hardware and/or software, that provides for mass storage of information, databases, and programs employed in connection with examples described herein. For example, data store <NUM> may be or may include a data repository for applications and/or related parameters not currently being executed by processor <NUM>, may include the time-series data repository <NUM>, etc. In addition, data store <NUM> may be a data repository for an operating system, application, such as the monitoring component <NUM>, and/or components thereof, etc. executing on the processor <NUM>, and/or one or more other components of the computing device <NUM>.

Computing device <NUM> may also include a user interface component <NUM> operable to receive inputs from a user of computing device <NUM> and further operable to generate outputs for presentation to the user (e.g., via a display interface to a display device). User interface component <NUM> may include one or more input devices, including but not limited to a keyboard, a number pad, a mouse, a touch-sensitive display, a navigation key, a function key, a microphone, a voice recognition component, a gesture recognition component, a depth sensor, a gaze tracking sensor, any other mechanism capable of receiving an input from a user, or any combination thereof. Further, user interface component <NUM> may include one or more output devices, including but not limited to a display interface, a speaker, a haptic feedback mechanism, a printer, any other mechanism capable of presenting an output to a user, or any combination thereof.

Computing device <NUM> can also include a monitoring component <NUM> for collecting a time series of an application performance metric for a period of less than two weeks, a distribution component <NUM> for determining a daily distribution for each day within the period, a RBF kernel component <NUM> for determining that the daily distribution includes a weekend time period that has a different daily distribution than a time period before or after the weekend time period, an adjustment component <NUM> for adjusting a baseline prediction of the application performance metric for the weekend time period, and an alerting component <NUM> for sending an alert based on a deviation of a value of the application performance metric from the adjusted baseline prediction, as described herein.

Accordingly, in one or more examples, one or more of the functions described may be implemented in hardware, software, firmware, or any combination thereof. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), and floppy disk where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.

Claim 1:
A computing device (<NUM>) for managing seasonal performance metric alerts, comprising:
a memory (<NUM>) storing one or more parameters or instructions; and
at least one processor (<NUM>) coupled to the memory (<NUM>), wherein the at least one processor (<NUM>) is configured to:
collect (<NUM>) a time series of an application performance metric for a period of less than two weeks;
determine (<NUM>) daily distributions of the time series for each day within the period;
apply (<NUM>) a radial basis function (RBF) kernel-based change point detection to each of the daily distributions to determine that the daily distributions include a weekend time period that has a different daily distribution than a time period before or after the weekend time period, wherein the determining comprises a detection of the weekend time period;
adjust (<NUM>) a baseline prediction of the application performance metric for a future weekend time period based on the detection of the weekend time period; and
send (<NUM>) an alert (<NUM>) based on a deviation of a value of the application performance metric from the adjusted baseline prediction.