Patent Description:
Management and control of computer networks is difficult to achieve efficiently and with flexibility. A similar problem arises in management and control of data centers. Often metrics are monitored and are available, but it is difficult to use those metrics to effectively manage and control the computer network, data centre or other computing entity. Analyzing metrics related to an operation of a computer application can be difficult to achieve given the millions of data point entries and the lack of context of computed metrics. Furthermore, the effectiveness and accuracy of human-driven analysis of large sets of data is increasingly low compared to machine-driven analysis. For example, if an organization needs a time sensitive analysis of a data set that has millions of entries across hundreds of variables, no human could perform such an analysis by hand or mentally. Furthermore, any such analysis may be out-of-date almost immediately, should an update be required. <CIT> describes an apparatus, computer-readable medium, and computer-implemented method for detecting anomalous user behavior, including collecting user activity data over an observation interval, the user activity data comprising a plurality of data objects and corresponding to a plurality of users, grouping a plurality of data objects into a plurality of clusters, calculating one or more outlier metrics corresponding to each cluster, calculating an irregularity score for each data object in the plurality of data objects, generating a plurality of object postures for the plurality of data objects, comparing each object posture in the plurality of object postures with one or more previous object postures corresponding to a same user as the object posture to identify anomalous activity of one or more users in the plurality of users. <CIT> describes a computer-implemented system and method for detecting anomalies using sample-based rule identification is provided. Data for data is maintained analytics in a database. A set of anomaly rules is defined. A rare pattern in the data is statistically identified. The identified rare pattern is labeled as at least one of anomaly and non-anomaly based on verification by a domain expert. The set of anomaly rules is adjusted based on the labeled anomaly. Other anomalies in the data are detected and classified by applying the adjusted set of anomaly rules to the data.

The description that follows describes systems, methods, techniques, instruction sequences, and computing machine program products that illustrate example embodiments of the present subject matter. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the present subject matter. It will be evident, however, to those skilled in the art, that embodiments of the present subject matter may be practiced without some or other of these specific details. Examples merely typify possible variations. Unless explicitly stated otherwise, structures (e.g., structural components, such as modules) are optional and may be combined or subdivided, and operations (e.g., in a procedure, algorithm, or other function) may vary in sequence or be combined or subdivided.

The term "metric vectors" is used herein to refer to the value of a metric measured at equidistant time intervals.

The term "operating thresholds" is used herein to refer to a range of values that a metric measure under "normal" operating conditions. The "normal" operating conditions may be defined by a user or may be based on a statistical analysis of the metric data.

The term "anomalous point" is used herein to refer to a metric value that lies outside the operating thresholds.

The term "steady state" is used herein to refer to a metric vector that is under operating thresholds.

The term "anomalous state" is used herein to refer to metric vectors that contain anomalous points that need alerting.

The term "pattern matrix" is used herein to refer to anomalous states of metric vector(s) that needs alerting.

The present application describes a method for detecting anomalous patterns of multivariate time series metrics measured from a computing entity such as an individual computing device, a network of computing devices, a data centre or other computing entity. As the number of data points increase, the need for efficiently analyzing the data becomes increasingly important, both in order to be able to obtain tractable results and in order to be able to use the results to control or manage the computing entity in a practical manner. In particular, the present application describes a method for discriminating anomalous patterns of multivariable time series metrics from non-anomalous patterns of multivariable time series metrics by first generating a model that identifies operating thresholds and second detecting anomalous patterns based on a "steady state distance" of an anomalous pattern matrix derived from the model. By using patterns as opposed to individual statistics robustness is achieved since with individual statistics anomalies are more likely to be identified in error due to natural outliers of a metric, as opposed to the situation where a pattern is detected. Once an anomalous pattern is discriminated information about the anomalous pattern is useable to manage and control the computing entity such as by taking action to adjust load balancing between components of the computing entity, by shutting down or disabling one or more components of the computing entity such as where the anomaly indicates a security breach, by triggering an automated maintenance operation on one or more components of the computing entity, or in other ways.

In one example embodiment, a system for detecting anomalies in a data stream is described. The system receives data stream that comprises values of metrics derived from observations of operation of a computing entity over a time window. The system forms a model comprising variances of the data over the time window. The model identifies operating thresholds for each metric based on the variances of the data for each metric in the data stream. The system uses the model to compute a steady state distance matrix of the data stream. The system determines that the steady state distance matrix exceeds a steady state threshold that is determined based on the operating thresholds of the model and metric vectors of the incoming data stream. In response to determining that the steady state distance matrix exceeds the steady state threshold, the system computes a pattern distance matrix based on the steady state distance matrix. The system detects an anomaly in the data stream based on the pattern distance matrix, and generating an alert indicating the anomaly.

Since the steady state distance matrix is efficient to compute for the data stream it provides an extremely scalable and effective way of analyzing the data stream. The steady state distance matrix can be thought of as carrying out a high-level analysis. When the steady state distance matrix exceeds a steady state threshold as described above, a more detailed analysis is done using the pattern distance matrix. The pattern distance matrix gives an extremely accurate and robust result as it uses a pattern rather than an individual statistic. Thus, by using the combination of a steady state distance matrix and a pattern distance matrix it is possible to achieve accuracy and scalability. As a result, control of the computing entity from which the metrics are observed or measured or derived is possible in a practical manner. The control is achieved in real-time in some embodiments.

As a result, one or more of the methodologies described herein facilitate solving the technical problem of facilitating control of a computing entity to save resources and/or improve performance. In an example the computing entity is a data center comprising one or more application servers as illustrated in <FIG>. By efficient, accurate detection of anomalies in metrics observed from the data centre it is possible to adjust, manage or control the data centre in real time. In an example where the data centre comprises application servers which provide a cloud service to client devices, an end user has improved performance of the application and optimized user operations of the application. As such, one or more of the methodologies described herein may obviate a need for certain efforts or computing resources. Examples of such computing resources include processor cycles, network traffic, memory usage, data storage capacity, power consumption, network bandwidth, and cooling capacity.

<FIG> is a diagrammatic representation of a network environment <NUM> in which some example embodiments of the present disclosure may be implemented or deployed. One or more application servers <NUM> provide server-side functionality via a network <NUM> to a networked user device, in the form of a client device <NUM>. A user <NUM> operates the client device <NUM>. The client device <NUM> includes a web client <NUM> (e.g., a browser), a programmatic client <NUM> (e.g., an email/calendar application such as Microsoft Outlook (TM), an instant message application, a document writing application, a shared document storage application) that is hosted and executed on the client device <NUM>.

An Application Program Interface (API) server <NUM> and a web server <NUM> provide respective programmatic and web interfaces to application servers <NUM>. A specific application server <NUM> hosts the service application <NUM> and an anomaly detection engine <NUM>. The service application <NUM> and the anomaly detection engine <NUM> each include components, modules and/or applications.

The service application <NUM> includes a server side email/calendar enterprise application, a server side instant message enterprise application, a document authoring enterprise application, or a shared document storage enterprise application. The service application <NUM> enables users of an enterprise to collaborate and share document, messages, and other data (e.g., meeting information, common projects) with each other. For example, the user <NUM> at the client device <NUM> accesses and uses the service application <NUM> to edit documents that are shared with other users of the same enterprise. In another example, the client device <NUM> accesses and uses the service application <NUM> to retrieve or send messages or emails to and from other peer users of the enterprise. Other examples of service application <NUM> includes enterprise systems, content management systems, and knowledge management systems.

In one example embodiment, the anomaly detection engine <NUM> communicates with the service application <NUM> and accesses metrics related to the user operation data of the service application <NUM>. The user operation data includes data points that measure the frequency, dates, times of users operating the enterprise application, types of documents being accessed or shared by users of the enterprise application, users calendar data from the enterprise application, communication data between users of the enterprise application, and enterprise organization data (e.g., hierarchy of users within an enterprise).

In another example embodiment, the anomaly detection engine <NUM> communicates with the programmatic client <NUM> and accesses operation data (or interaction data with other users of the enterprise) from the user <NUM> with the programmatic client <NUM> or web client <NUM>. In one example, the web client <NUM> communicates with the anomaly detection engine <NUM> and service application <NUM> via the programmatic interface provided by the Application Program Interface (API) server <NUM>.

The anomaly detection engine <NUM> determines time-series metrics (e.g., metrics with variables that change over time) based on operation data of the service application <NUM> and interaction data between users of the enterprise. The operation data and interaction data is collected by a combination of the service application <NUM>, the web client <NUM>, or the programmatic client <NUM>. Examples of metrics include operation metrics that are associated with an enterprise or a group of user accounts within the enterprise. In one example, the anomaly detection engine <NUM> measures operation metrics based on operation data of the service application <NUM> by a group of user accounts of the enterprise. In another example, the anomaly detection engine <NUM> measures interaction metrics based on interaction data of the group of user accounts using the service application <NUM>. In another example, the anomaly detection engine <NUM> measures operation metrics based on other filter criteria (group department, group size, group hierarchy - managers, supervisors, team leader, user physical location, office location, time, seasonality).

In one example embodiment, the anomaly detection engine <NUM> detects anomalous patterns based on the metrics and generates an alert to the service application <NUM> or the client device <NUM>. The alert indicates an anomalous activity as indicated by the pattern of the metrics. In another example, the alert indicates that the metrics corresponding to a predefined anomalous pattern (e.g., anomalous pattern X detected). The system uses the alert as a feedback mechanism in adjusting the operating thresholds of the model (e.g., increase or decrease upper/lower thresholds based on identified anomalous pattern).

In another example embodiment, the anomaly detection engine <NUM> provides a (user-interactive) portion of a GUI that identifies the anomalous activity and prompt modifications to settings or operations of the service application <NUM> or the client device <NUM>. For example, the anomaly detection engine <NUM> generates a configuration setting (e.g., disable operation of service application <NUM> during user-defined period of times) for the service application <NUM> based on the operation/interaction metrics. The anomaly detection engine <NUM> applies the configuration setting to the service application <NUM>. As such, the service application <NUM> that is modified by the configuration setting now operates in a different manner (e.g., generating more frequent or less different alerts, modifying a setting of a communication application to automatically generate alert that indicate a particular pattern, setting a limit to the number of users of the service application <NUM>).

Examples of configuration settings include changes to how the service application <NUM> operates at different times. For example, the service application <NUM> may be configured to be disabled during a preset amount of time during the day. In another example, the service application <NUM> may be configured to generate and display only certain types of alert. In another example, the service application <NUM> may be configured to generate a dialog box pre-populated with information based on the recommended action (e.g., pre-filled with parameters of a feature of the service application <NUM>). The user <NUM> only has to click on one button to configure the anomaly detection engine <NUM> with the new parameters. For example, the pre-filled parameters configure the model generation of the anomaly detection engine <NUM> to exclude certain metrics. Such configuration results in an efficient operation of the anomaly detection engine <NUM> to further identify relevant anomalous states from the metrics.

In one example embodiment, the anomaly detection engine <NUM> automatically calculates the operating thresholds of metric vectors and generates a model based on the operating threshold for each metric. The anomaly detection engine <NUM> uses the model to detect an anomalous state for an incoming data stream (e.g., time-series metrics). The anomaly detection engine <NUM> determines anomalous points and calculates a steady state distance. If the steady state distance exceeds a threshold, the anomaly detection engine <NUM> then calculates a pattern similarity distance. Example components and operations of the anomaly detection engine <NUM> are further described below with respect to <FIG> and <FIG>.

The application server <NUM> is shown to be communicatively coupled to database servers <NUM> that facilitates access to an information storage repository or databases <NUM>. In an example embodiment, the databases <NUM> includes storage devices that store information to be processed by the service application <NUM> and the anomaly detection engine <NUM>.

Additionally, a third-party application <NUM> may, for example, store another part of the service application <NUM>, or include a cloud storage system. For example, the third-party application <NUM> stores additional metrics. The third-party application <NUM> executing on a third-party server <NUM>, is shown as having programmatic access to the application server <NUM> via the programmatic interface provided by the Application Program Interface (API) server <NUM>. For example, the third-party application <NUM>, using information retrieved from the application server <NUM>, may supports one or more features or functions on a website hosted by the third party.

<FIG> is a block diagram illustrating the anomaly detection engine <NUM> in accordance with one example embodiment. The anomaly detection engine <NUM> includes a metrics generator <NUM>, a data extractor <NUM>, a model generator <NUM>, a model and data extractor <NUM>, an anomalous pattern detection module <NUM>, and a model enhancer module <NUM>, and a GUI module <NUM>.

The metrics generator <NUM> communicates with client devices of the service application <NUM>. In one example embodiment, the metrics generator <NUM> implements queries to access raw metrics data <NUM> from the databases <NUM>. In one example, the raw metrics data <NUM> include a data stream points (e.g., operation of the <NUM>, user operation/interaction data from devices with access to the service application <NUM>). The user operation data indicate user activities with the service application <NUM> (e.g., when and how often the user is using the service application <NUM>). The user interaction data indicate interactions (e.g., types, frequency, dates, recipient's identification) between users of the service application <NUM>.

In another example embodiment, other data points include user activities associated with other applications. Other examples of data points include frequency, dates, times of users operating the enterprise application, types of documents being accessed or shared by users of the enterprise application, users calendar data from the enterprise application, communication data between users of the enterprise application, and enterprise organization data. Examples of other applications include email applications, document editing applications, document sharing applications, and other types of applications used by enterprises.

The metrics generator <NUM> determines metrics vector based on the data points (e.g., operation/interaction data of the service application <NUM>) over a window of time. In one example embodiment, the metric vector measures a metric at equidistant time intervals over the window of time. Examples of metrics vectors include communication metrics vectors, collaboration metrics vectors, operation metrics vectors.

The data extractor <NUM> extracts metrics data from the metrics generator <NUM>. In another example, the data extractor <NUM> retrieves the metrics vector data from the metrics generator <NUM>. In yet another example, the data extractor <NUM> computes the metrics vector based on the metrics data extracted from the metrics generator <NUM>.

The following represents an example of a metric vector (as a function of time): <MAT> <MAT> <MAT>.

In another example, the data extractor <NUM> extracts metrics vector data for the identified metric vector in such a way that seasonality is captured. For example, if the number of operation of the service application <NUM> ramps up during a first quarter, peaks during second and third quarters and dips during the fourth quarter, a year's worth of metrics data may be desired to produce an effective model. These models would be refreshed based on the periodicity of usage of the service application <NUM>.

Frequency of metrics data collection depends on the desire for precision. For example, the alert is to be generated based on the changes to the usage of the service application <NUM> between hours, then a <NUM> hour sample of metrics data per day would be sufficient.

The model generator <NUM> forms a model that captures all operating thresholds based on the metrics data. In one example embodiment, the model generator <NUM> determines operating thresholds for each metric by calculating a second order differential of the metric vector.

These operating thresholds are stored as a part of the model. Because these metric vectors can be represented as time series, generating operating thresholds for lowest level of periodicity improves the performance of detections. For example, if the number of accesses to the service application <NUM> stays higher on weekdays than the accesses placed during weekends, the model generator <NUM> capture operating thresholds for weekday and weekends separately.

The following represents an example of rates of change of metric vectors by obtaining their differentials and second order differential is used to characterize the metric vector: <MAT>.

As such, the acceleration vector can be decomposed into <NUM> vectors:
X<NUM>t where µ(X<NUM>t) → <NUM>, where range X1t defines pass band constants.

X<NUM>t where µ(X<NUM>t) → ∞, where range X2t defines the high pass filter constants.

X<NUM>t where µ(X<NUM>t) → ∞, wherein range X3t defines the low pass filter constants.

Ranges of X2t and X3t define the higher and lower bounds of the threshold where the variable is anomalous.

These operating thresholds are stored as a part of the model. As these metric vectors can be represented as time series, generating operating thresholds for lowest level of periodicity improves the performance of detections. For example, If the number of calls placed for a customer stays higher than the calls placed during weekends, it would be advised to capture operating thresholds for weekday and weekends separately.

The model and data extractor <NUM> combines metric data (of an incoming data stream) with the model from the model generator <NUM> to enable filtering.

The anomalous pattern detection module <NUM> detects whether the metric data matches (or is close to) an anomalous pattern. In one example, the anomalous pattern detection module <NUM> generates an alert indicating the anomalous state and feedback loop to the model generator <NUM> to revise the operating thresholds. The components and operation of the anomalous pattern detection module <NUM> is described in more detail below with respect to <FIG>.

The model enhancer module <NUM> learns new filter constants based on the output from a signal filter applied to the output of the model and data extractor <NUM>. The signal filter may be a combination of high pass, low pass, and stop band filters.

The GUI module <NUM> generates a GUI that indicates the metrics vectors and the alert. For example, the GUI module <NUM> causes a notification of the alert indicating an anomalous pattern. The GUI module <NUM> further provides an interactive pane for a user of the anomaly detection engine <NUM> to adjust a configuration/operation setting of the service application <NUM>. The settings may be provided by the model enhancer module <NUM>. For example, the settings may be for disabling a feature of the service application <NUM> during specific times.

<FIG> is a block diagram illustrating an anomalous pattern detection module <NUM> in accordance with one example embodiment. The anomalous pattern detection module <NUM> includes an anomalous points discovery module <NUM>, a steady state distance module <NUM>, a pattern similarity distance module <NUM>, and an alert module <NUM>.

The anomalous points discovery module <NUM> determines anomalous points in the metric vector data from the data extractor <NUM>. For example, the anomalous points discovery module <NUM> compares each point on the metric vector against the operating thresholds of the metric. The anomalous points discovery module <NUM> assigns a "zero" point where the value of the metric vector is within the operating thresholds, and a "one" point wherein the value of the metric vector is outside the operating thresholds. This step is repeated for all the identified metric vectors to produce a matrix, also referred to as an anomalous pattern matrix.

The following illustrates an example anomalous pattern matrix that represents n contiguous samples of a metric X: <MAT>.

Similarly, m metrics can be represented as follows: <MAT>.

The steady state distance module <NUM> accesses the anomalous pattern matrix generated at anomalous points discovery module <NUM> and computes a Hamming distance from a steady state. The Hamming distance refers an algorithm named after the mathematician Richard Hamming. In information theory, the Hamming distance between two strings of equal length is the number of positions at which the corresponding symbols are different. In other words, it measures the minimum number of substitutions required to change one string into the other, or the minimum number of errors that could have transformed one string into the other. In a more general context, the Hamming distance is one of several string metrics for measuring the edit distance between two sequences. In another example embodiment, other algorithms can be used to measure a distance/similarity between two sequences/matrices.

If the Hamming distance is greater than a given threshold (that is calculated by the pattern matrix), the process moves on to the pattern similarity distance module <NUM>.

The steady state (also referred to as non-anomalous state) can be represented as a null matrix of order m*n as follows: <MAT>.

The metric value ranges between <NUM> and <NUM> and indicates a score of how anomalous a state is. The hamming distance of the anomalous pattern matrix from the steady state (also referred to as steady state distance) can be represented as follows: <MAT>.

The pattern similarity distance module <NUM> calculates a pattern similarity distance in response to the steady state distance exceeding a predefined threshold (e.g., <NUM>). The pattern similarity distance module <NUM> accesses the anomalous pattern matrix from the anomalous points discovery module <NUM> and computes the Hamming distance between the anomalous pattern matrix (or other predefined anomalous pattern matrices) and the metric matrix (from incoming data stream).

The alert module <NUM> generates an alert to the service application <NUM> if the Hamming distance between the metric matrix is close to the anomalous pattern matrix (or to any of predefined anomalous pattern matrices).

<FIG> is a flow diagram illustrating a method for generating a model in accordance with one example embodiment. Operations in the method <NUM> may be performed by the anomaly detection engine <NUM>, using components (e.g., modules, engines) described above with respect to <FIG> and <FIG>. Accordingly, the method <NUM> is described by way of example with reference to the anomaly detection engine <NUM>. However, it shall be appreciated that at least some of the operations of the method <NUM> may be deployed on various other hardware configurations or be performed by similar components residing elsewhere. For example, some of the operations may be performed at the client device <NUM> or at the third-party server <NUM>.

At block <NUM>, the metrics generator <NUM> accesses raw metrics data <NUM> (e.g., time-series data) from the databases <NUM> or from the service application <NUM>. At block <NUM>, the data extractor <NUM> extracts metric vectors from the raw metrics data <NUM>. At block <NUM>, the model generator <NUM> identifies operating thresholds for each metric. For example, the model generator <NUM> identifies an upper threshold and a lower threshold for a metric. The region between the lower and upper threshold indicates a non-anomalous region. At block <NUM>, the model generator <NUM> generates a model each metric based on the corresponding operating thresholds.

<FIG> is a flow diagram illustrating a method <NUM> for calculating a pattern similarity distance in accordance with one example embodiment. Operations in the method <NUM> may be performed by the anomaly detection engine <NUM>, using components (e.g., modules, engines) described above with respect to <FIG> and <FIG>. Accordingly, the method <NUM> is described by way of example with reference to the anomaly detection engine <NUM>. However, it shall be appreciated that at least some of the operations of the method <NUM> may be deployed on various other hardware configurations or be performed by similar components residing elsewhere. For example, some of the operations may be performed at the client device <NUM> or at the third-party server <NUM>.

At block <NUM>, the anomalous points discovery module <NUM> detect anomalous points in the raw metrics data <NUM> by forming an anomalous pattern matrix based on the raw metrics data <NUM> as described above. At block <NUM>, the steady state distance module <NUM> calculates a steady state distance (based on Hamming distance algorithm) of the anomalous pattern matrix relative to a steady state matrix (e.g., a non-anomalous matrix). If the steady state distance exceeds a threshold, the process moves to block <NUM>. At block <NUM>, the pattern similarity distance module <NUM> calculates a pattern similarity distance between a metric matrix from an incoming data stream (e.g., new metric data) and a predefined anomalous pattern (e.g., anomalous pattern matrix X, anomalous pattern matrix Y) to identify which predefined anomalous pattern the metric matrix is closest to. For example, the pattern similarity distance module <NUM> determines that the metric matrix matches anomalous pattern matrix X. In response to the matching, the alert module <NUM> generates an alert at block <NUM>.

<FIG> is a diagrammatic representation of the machine <NUM> within which instructions <NUM> (e.g., software, a program, an application, an applet, an app, or other executable code) for causing the machine <NUM> to perform any one or more of the methodologies discussed herein may be executed. For example, the instructions <NUM> may cause the machine <NUM> to execute any one or more of the methods described herein. The instructions <NUM> transform the general, non-programmed machine <NUM> into a particular machine <NUM> programmed to carry out the described and illustrated functions in the manner described. The machine <NUM> may operate as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, the machine <NUM> may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine <NUM> may comprise, but not be limited to, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a PDA, an entertainment media system, a cellular telephone, a smart phone, a mobile device, a wearable device (e.g., a smart watch), a smart home device (e.g., a smart appliance), other smart devices, a web appliance, a network router, a network switch, a network bridge, or any machine capable of executing the instructions <NUM>, sequentially or otherwise, that specify actions to be taken by the machine <NUM>. Further, while only a single machine <NUM> is illustrated, the term "machine" shall also be taken to include a collection of machines that individually or jointly execute the instructions <NUM> to perform any one or more of the methodologies discussed herein.

The machine <NUM> may include processors <NUM>, memory <NUM>, and I/O components <NUM>, which may be configured to communicate with each other via a bus <NUM>. In an example embodiment, the processors <NUM> (e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) Processor, a Complex Instruction Set Computing (CISC) Processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an ASIC, a Radio-Frequency Integrated Circuit (RFIC), another Processor, or any suitable combination thereof) may include, for example, a Processor <NUM> and a Processor <NUM> that execute the instructions <NUM>. The term "Processor" is intended to include multi-core processors that may comprise two or more independent processors (sometimes referred to as "cores") that may execute instructions contemporaneously. Although <FIG> shows multiple processors <NUM>, the machine <NUM> may include a single Processor with a single core, a single Processor with multiple cores (e.g., a multi-core Processor), multiple processors with a single core, multiple processors with multiples cores, or any combination thereof.

The I/O components <NUM> may include a wide variety of components to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on. The specific I/O components <NUM> that are included in a particular machine will depend on the type of machine. For example, portable machines such as mobile phones may include a touch input device or other such input mechanisms, while a headless server machine will likely not include such a touch input device. It will be appreciated that the I/O components <NUM> may include many other components that are not shown in <FIG>. In various example embodiments, the I/O components <NUM> may include output components <NUM> and input components <NUM>. The output components <NUM> may include visual components (e.g., a display such as a plasma display panel (PDP), a light emitting diode (LED) display, a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)), acoustic components (e.g., speakers), haptic components (e.g., a vibratory motor, resistance mechanisms), other signal generators, and so forth. The input components <NUM> may include alphanumeric input components (e.g., a keyboard, a touch screen configured to receive alphanumeric input, a photo-optical keyboard, or other alphanumeric input components), point-based input components (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or another pointing instrument), tactile input components (e.g., a physical button, a touch screen that provides location and/or force of touches or touch gestures, or other tactile input components), audio input components (e.g., a microphone), and the like.

In further example embodiments, the I/O components <NUM> may include biometric components <NUM>, motion components <NUM>, environmental components <NUM>, or position components <NUM>, among a wide array of other components. For example, the biometric components <NUM> include components to detect expressions (e.g., hand expressions, facial expressions, vocal expressions, body gestures, or eye tracking), measure biosignals (e.g., blood pressure, heart rate, body temperature, perspiration, or brain waves), identify a person (e.g., voice identification, retinal identification, facial identification, fingerprint identification, or electroencephalogram-based identification), and the like. The motion components <NUM> include acceleration sensor components (e.g., accelerometer), gravitation sensor components, rotation sensor components (e.g., gyroscope), and so forth. The environmental components <NUM> include, for example, illumination sensor components (e.g., photometer), temperature sensor components (e.g., one or more thermometers that detect ambient temperature), humidity sensor components, pressure sensor components (e.g., barometer), acoustic sensor components (e.g., one or more microphones that detect background noise), proximity sensor components (e.g., infrared sensors that detect nearby objects), gas sensors (e.g., gas detection sensors to detection concentrations of hazardous gases for safety or to measure pollutants in the atmosphere), or other components that may provide indications, measurements, or signals corresponding to a surrounding physical environment. The position components <NUM> include location sensor components (e.g., a GPS receiver Component), altitude sensor components (e.g., altimeters or barometers that detect air pressure from which altitude may be derived), orientation sensor components (e.g., magnetometers), and the like.

Communication may be implemented using a wide variety of technologies. The I/O components <NUM> further include communication components <NUM> operable to couple the machine <NUM> to a network <NUM> or devices <NUM> via a coupling <NUM> and a coupling <NUM>, respectively. For example, the communication components <NUM> may include a network interface Component or another suitable device to interface with the network <NUM>. In further examples, the communication components <NUM> may include wired communication components, wireless communication components, cellular communication components, Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components to provide communication via other modalities. The devices <NUM> may be another machine or any of a wide variety of peripheral devices (e.g., a peripheral device coupled via a USB).

The various memories (e.g., memory <NUM>, main memory <NUM>, static memory <NUM>, and/or memory of the processors <NUM>) and/or storage unit <NUM> may store one or more sets of instructions and data structures (e.g., software) embodying or used by any one or more of the methodologies or functions described herein. These instructions (e.g., the instructions <NUM>), when executed by processors <NUM>, cause various operations to implement the disclosed embodiments.

The instructions <NUM> may be transmitted or received over the network <NUM>, using a transmission medium, via a network interface device (e.g., a network interface Component included in the communication components <NUM>) and using any one of a number of well-known transfer protocols (e.g., hypertext transfer protocol (HTTP)). Similarly, the instructions <NUM> may be transmitted or received using a transmission medium via the coupling <NUM> (e.g., a peer-to-peer coupling) to the devices <NUM>.

Although an overview of the present subject matter has been described with reference to specific example embodiments, various modifications and changes may be made to these embodiments without departing from the broader scope of embodiments of the present invention. For example, various embodiments or features thereof may be mixed and matched or made optional by a person of ordinary skill in the art. Such embodiments of the present subject matter may be referred to herein, individually or collectively, by the term "invention" merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or present concept if more than one is, in fact, disclosed.

The embodiments illustrated herein are believed to be described in sufficient detail to enable those skilled in the art to practice the teachings disclosed. The Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

Claim 1:
A computer-implemented method for detecting anomalies in an incoming data stream comprising:
receiving a data stream that comprises values of metrics derived from observations of operation of a computing entity over a time window;
forming a model comprising variances of the data over the time window, the model identifying operating thresholds for each metric based on the variances of the data for each metric in the data stream;
accessing a value of a metric vector for each metric from the incoming data stream;
comparing the value of the metric vector for each metric with operating thresholds of the corresponding metric from the model;
assigning a first matrix point value in response to the value of the metric vector being within the operating thresholds or a second matrix point value in response to the value of the metric vector being outside the operating thresholds;
forming an anomalous pattern matrix based on the first or second matrix point value of each metric from the incoming data stream;
using the model to compute a steady state distance of the incoming data stream, by calculating the steady state distance between the anomalous pattern matrix and a steady state matrix, the steady state matrix representing a non-anomalous state;
determining that the steady state distance exceeds a steady state threshold that is determined based on the operating thresholds of the model and metric vectors of the incoming data stream;
in response to the steady state distance exceeding the steady state threshold, computing a Hamming distance between the anomalous pattern matrix and a metric matrix of metric vectors from the incoming data stream;
detecting an anomaly in the incoming data stream based on the Hamming distance; and
generating, at a computer, an alert indicating the anomaly.