Two-tier “alert” and “event” model supports Regulatory Compliance
When designing the RiverMuse architecture, we were fully cognizant of the constraints of other system management solutions that use only a single tier ‘alert’ model with no historical archival of ‘events’. By adopting an architecture that supports a two-tier ‘event’ and ‘alert’ model at the basic level, freed RiverMuse from many of these past constraints.
For clarity, we describe an ’event’ as an infrastructure occurrence communicated as a message (e.g. trap or syslog), polling result (reachable/not reachable) or a rule (threshold below ‘x’ for a service). An ‘alert’ is generated based on how an event (and its related occurrences) is processed based on specified business rules. In essence, events are the raw incoming data stream; alerts are processed and de-duplicated events.
Legacy system management platforms for instance – only manage “alerts”; and therefore risk losing data. For example, in the case of de-duplication, the individual occurrences of the duplicate alert are discarded.
In contrast, with RiverMuse’s two-tier alert and event model means that you can select from the database all the events that have occurred for any given alert. Each alert has a unique “alert_id” (integer) and each event references an “alert_id”.
Through the desktop console you can retrieve all events relevant to a specific “alert_id”, thus providing an audit trail of every occurrence that has happened to a specific alert. For example, you can find out: create time, time of every duplicate, assignment time, acknowledgement time, how long it took to close the alert and so on.
Being able to detect every change to an alert creates a fully compliant system for regulations such as Sarbanes Oxley and Basel II, as no information is ever discarded. Consequently, in relation to ‘alert management’ RiverMuse offers the best solution for compliance sensitive environments.
The two level event and alert model is a key component of RiverMuse’s lightweight platform for event acquisition, correlation, alert generation and processing in dynamic IT environments.
Filed Under: Product • Technology • blog
[...] Two-tier “alert” and “event” model supports Regulatory Compliance – how having fully auditable alerts helps with regulatory compliance [...]
I like this. It is a start down the road of solving the age old conundrum where Events != Situations and the Severity issues where a Critical on an event did not equal a Critical on the business logic associated with the workflow.
Now that you’re capturing all of the steps that happen, you probably need to look at outputting the steps in a BPEL type format and display timings and resources to help users optimize their incident, problem, and change processes.
On another thought, I have been studying and working through the details of behaviors and Situation Awareness. Event presentation systems provide an excellent Single Heads up Display sort of thing, if you think through the behavioral science behind SA.
SA is going to get ever so much more important in organizations supporting cloud infrastructures. As clouds are somewhat simplistic and static with a bit of movement today, when they evolve toward intelligent application delivery to maximize the user experience, achieving individual and team SA will be imperative toward understanding and supporting a cloud infrastructure that spans the globe and morphs to provide the best user experience. Think about memcached, portable web services, and CEP in an environment where resources can be brought to bear in an instant responding to customer behavior. What if you could DYNAMICALLY adjust your infrastructure to minimize latency for ANY customer ANY WHERE in the world?