System events are instances of indications in a system that something has gone wrong, is about to go wrong, or simply a notification of an interesting event in the system. Event instances may be solicited (e.g., requested) or unsolicited (e.g., pre-configured). There are a variety of management systems that deal with system events in very different ways. Some simply log them to a file in order to preserve an archive. Others keep accurate and up to date records that help administrators identify problems related to the system with a single glance by viewing historical information.
In a conventional approach to managing system events, an administrator of a system often goes through multiple event frameworks/views in order to witness and analyze the state of the system or history of events that may have occurred. Events are defined herein to include alerts. Due to the configuration of conventional event management frameworks, the administrator (often unknowingly) utilizes multiple event frameworks/views in order to witness such state of the system or history of events. The reason for this situation of going through multiple event frameworks/views is that each of these event frameworks typically has its own data store that is managed independently. Undesirably, these multiple event data stores increase the required storage (e.g., at least one per framework) and complexity of an entire software stack of the system. Furthermore, conventional event management frameworks implement a method of managing event data stores that require the respective event management frameworks itself to copy and/or store event information into a respective event data store (i.e., a private event data store), which is inefficient from a resource utilization standpoint and system efficiency standpoint.
System event indications are delivered by any number of event indication output means. Examples of such event indication output means include, but are not limited to, event log entries, web console queries, command line event queries, operating panel fault indicators, Simple Network management Protocol (SNMP) traps, Intelligent Platform Management Interface (IPMI) System Event Log (SEL) entries, IPMI Platform Event Trap (PET) and Simple Main Transfer Protocol (SMTP) email. Delivery via such event indication output means may be performed in any automatic (i.e., pre-configured) manner or upon request.
The various event indication output means implemented in conventional event management frameworks lead to a number of drawbacks with respect to management of system event data. One drawback is that inter-framework communication is limited such that not all system event data is accessible through each interface. Another drawback is that each interface typically has its own data store that is managed separately. Because there are separately managed data stores, the views of these data stores will be disparate and the management of these stores will be disparate. Still another drawback is that this disparate and non-integrated management of data store information limits, if not precludes, efficient and effective unification of event framework views.
Therefore, implementation of event management frameworks and event data stores in a manner that overcomes drawbacks associated with conventional approaches for implementing event management frameworks and event data stores would be useful and advantageous.