Abstract:
Several aspects for providing historical information to an event based image include a method, an apparatus and an article. One or more of the aspects includes receiving a trigger associated with a rule, determining if the rule requires that historical information be provided to an event-based analysis engine, filtering out events not needed by the rule if the rule requires historical information and providing the event-based analysis engine with historical information based on the filtering.

Description:
BACKGROUND 
     An event-based analysis engine reacts to one or more events. For example, if an event occurs, the event-based analysis engine performs an action based on a rule. In one particular example, the event may be based on historical information. 
     SUMMARY 
     In one aspect, a method includes receiving a trigger associated with a rule, determining if the rule requires that historical information be provided to an event-based analysis engine, filtering out events not needed by the rule if the rule requires historical information and providing the event-based analysis engine with historical information based on the filtering. 
     In another aspect, an article includes a non-transitory machine-readable medium that stores executable instructions to provide data to an event-based analysis engine. The instructions cause a machine to receive a trigger associated with a rule, determine if the rule requires that historical information be provided to an event-based analysis engine, filter out events not needed by the rule if the rule requires historical information and provide the event-based analysis engine with historical information based on the filtering. 
     In a further aspect, an apparatus includes circuitry to provide data to an event-based analysis engine and configured to receive a trigger associated with a rule, determine if the rule requires that historical information be provided to an event-based analysis engine, filter out events not needed by the rule if the rule requires historical information and provide the event-based analysis engine with historical information based on the filtering. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of an example of a system to provide historical data to an event-based analysis engine. 
         FIG. 2  is a flowchart of an example of a process to provide historical data to an event-based analysis engine. 
         FIG. 3  is a block diagram of a computer on which the process of  FIG. 2  may be implemented. 
         FIG. 4  is a block diagram of another example of a system to provide historical data to an event-based analysis engine. 
     
    
    
     DETAILED DESCRIPTION 
     Described herein are techniques to provide historical data to an event-based analysis engine. For example, the historical data is provided automatically (without user intervention). In one particular example, the historical data is provided using a generic and/or rule-specific loading mechanism. In one example, the techniques described herein work even if the rules and events that are stored in a memory of the event-based analysis engine are lost, for example, due to a restart of the event-based analysis engine. 
     Referring to  FIG. 1 , a system  100  includes an event-based analysis engine  102 , a module  106  and a database  108 . The rules are stored in a database  108 . The event-based analysis engine  102  compiles the rules and includes a memory  114  configured to store the rules and historical data. In one example, the module  106  reads the rules from the database  108  (e.g., after the module  106  receives an event to load a rule into the event-based analysis engine  102 ) and whenever a new event is reached for loading a rule to the event-based analysis engine  102 , the module  106  receives this rule as well. 
     The module  106  includes a parser  122 , filter  132  and a query component  142 . The parser  122  parses a rule and identifies whether a rule requires historical data. For example, the parser  122  is configured to recognize a rule that requires historical data if at least one of the following conditions are true: (1) the rule includes a statistical operator, (2) the rule includes a change management operator; and (3) the rule correlates between two or more event types. The statistical operator is used to run a calculation of a metric over a time period requiring all the events or the aggregation of the events for the time period. The change management operator determines if data has changed so that historical data is required to determine whether the data has changed from one point in time to another point in time. The rule correlating between two or more event types means that the rule is required to store an event associated with a required event type so that whenever a new event (one of the required event types) is received, the rule can be executed. 
     The rules are evaluated when an event is sent to the event-based analysis engine  102 . The event-based analysis engine is configured to recognize which rules to evaluate based on the event that is received. In an example where the rule is required to check a condition for more than one event (which are not received at the same time), the event-based analysis engine  102  keeps the events for both types in memory  114  so whenever it receives both events event-based analysis engine  102  can start evaluating the rule condition. 
     If historical data is required, the parser  122  provides the required objects (e.g., a host, disk and so forth), event types (e.g., a backup job, CPU utilization, disk status and so forth) and a time period to the filter  132 . 
     The filter  132  filters out any event that is not required by the rule and returns the results back to the parser  122 . For example, if a rule requires that a backup state of a backup job be successful, then any backup that is not successful is filtered out. The information that will be sent in this example are the backup jobs events that are needed for the enabled rules (i.e., just for the backup servers that the rule is enabled on, the backup jobs for the required time period and just the backup jobs whose state is exactly what is required by the rule). 
     The parser  122  provides the filtered results from the input filter  132  to the query component  142 . The query component  142  receives the filtered results from the parser  122  and queries the database  108  to retrieve the historical data and provides the historical information to the event-based engine  102 . 
     Referring to  FIG. 2 , an example of a process to provide automatically historical data to the event-based analysis engine  102  is a process  200 . Process  200  receives a trigger associated with a rule ( 202 ). For example, whenever the event-based analysis engine  102  loads/reloads a rule, the module  106  is triggered. In another example, the module  106  may be triggered if the event-based analysis engine  102  restarts (and then all the enabled rules are reloaded). In a further example, the module  106  is triggered whenever a rule is enabled, whenever a rule is assigned to a new node, whenever a rule is modified and so forth. 
     Process  200  determines if the rule will require that historical data be provided to an event-based analysis engine ( 208 ). For example, the rule contains at least one of a statistical operator, a change management operator or a correlation between two or more event types. 
     If the rule will require historical data be provided to the event-based analysis engine, then process  200  filters out events that are not required ( 212 ). 
     Process  200  provides event-based analysis engine with the required information ( 218 ). For example, the query component  142  searches the database  108  and provides the memory  114  of the event-based analysis engine  102  with the historical data. 
     Referring to  FIG. 3 , an example of the module  106  is a computer  300 . The computer  300  includes a processor  302 , a volatile memory  304 , a non-volatile memory  306  (e.g., hard disk) and a user interface (UI)  308  (e.g., a mouse, a keyboard, a display, touch screen and so forth). The non-volatile memory  306  stores computer instructions  312 , an operating system  316  and data  318 . In one example, the computer instructions  312  are executed by the processor  302  out of volatile memory  304  to perform all or part of the processes described herein (e.g., the process  200 ). 
     The processes described herein (e.g., the process  200 ) are not limited to use with the hardware and software of  FIG. 3 ; they may find applicability in any computing or processing environment and with any type of machine or set of machines that is capable of running a computer program. The processes described herein may be implemented in hardware, software, or a combination of the two. The processes described herein may be implemented in computer programs executed on programmable computers/machines that each includes a processor, a storage medium or other article of manufacture that is readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and one or more output devices. Program code may be applied to data entered using an input device to perform any of the processes described herein and to generate output information. 
     The system may be implemented, at least in part, via a computer program product, (e.g., in a machine-readable storage device), for execution by, or to control the operation of, data processing apparatus (e.g., a programmable processor, a computer, or multiple computers)). Each such program may be implemented in a high level procedural or object-oriented programming language to communicate with a computer system. However, the programs may be implemented in assembly or machine language. The language may be a compiled or an interpreted language and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program may be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network. A computer program may be stored on a storage medium or device (e.g., CD-ROM, hard disk, or magnetic diskette) that is readable by a general or special purpose programmable computer for configuring and operating the computer when the storage medium or device is read by the computer to perform the processes described herein. The processes described herein may also be implemented as a machine-readable storage medium, configured with a computer program, where upon execution, instructions in the computer program cause the computer to operate in accordance with the processes. A non-transitory machine-readable medium may include but is not limited to a hard drive, compact disc, flash memory, non-volatile memory, volatile memory, magnetic diskette and so forth but does not include a transitory signal per se. 
     The system and processes described herein are not limited to the specific examples described. 
     For example, referring to  FIG. 4 , the module  106 , the parser  122  and the filter  132  of  FIG. 3  may be replaced by a module  106 ′, a parser  122 ′ and a filter  132 ′ respectively, to form a system  100 ′. In this configuration, the filter  132 ′ filters the data from the parser  122 ′ and supplies the filtered data directly to the query component  142  without, as shown in  FIG. 3 , sending the information back to the parser  122 ′. 
     In another example, the process  200  is not limited to the specific processing order of  FIG. 2 . Rather, any of the processing blocks of  FIG. 2  may be re-ordered, combined or removed, performed in parallel or in serial, as necessary, to achieve the results set forth above. 
     The processing blocks (for example, in the process  200  of  FIG. 2 ) associated with implementing the system may be performed by one or more programmable processors executing one or more computer programs to perform the functions of the system. All or part of the system may be implemented as, special purpose logic circuitry (e.g., an FPGA (field-programmable gate array) and/or an ASIC (application-specific integrated circuit)). 
     Elements of different embodiments described herein may be combined to form other embodiments not specifically set forth above. Other embodiments not specifically described herein are also within the scope of the following claims.