Fifteen years ago when HP Operations Manager (or OpenView Operations as it used to be called) was released, event management was really “infrastructure event management”. The concepts of middleware, of customer experience, of SOA, and of automated business process didn’t exist. But now they do, and we need a consolidated management solution that does full “consolidated business service management” rather than simply “consolidated infrastructure management” so that all events can come into one place where the operators are highly empowered to deal with quickly and accurately.

 

This is the aim of the Operations Manager i (OMi) product we announced at Vienna Universe on December 9th.

 

OMi and a shared service dependency model

OMi shares the same discovered service model as BAC. The service dependency model holds information on business transactions, customer experience, applications, middleware, infrastructure and now, network information discovered by our network management product, NNMi.

 

Using a common service dependency model means you can look upwards in the model (if the event comes below) and understand what services, user experiences and transactions are affected. The SLAs are in the model - so you can see how they are affected, and how close to jeopardy this problem brings you.

 

The model also tells you changes that have been made under a CI; what changes are planned; and what incidents are outstanding in Service Manager. Also the HP Server Automation product puts the compliance state of servers into the same model, so you can see if anything under a CI is out of compliance.

 

OMi  and root event analysis using a discovered model
The perennial problem with any event management system, whether it be infrastructure or network management, is event noise. A problem with one object can cause a whole array of dependent objects to fire off events too.  For example:

 

• the SAN has a problem and fires off an event ...
• the Active Directory using that SAN fires off an event...
• the Exchange Server using that Active Directory has just lost its directory and fires off an event ...
• and the proxy server that is driving the web UI to Exchange fires off an event too.

 

Four events  - but one “root event” – one “actionable condition”.

 

Typically, event management systems have created “event correlation languages” so you can program up rules to eliminate these noise events, but such rules are simply not robust to change (and we all know how fast IT systems change). Also, the number of events that can be generated is so large that it’s impossible to write all the rules you need.

 

What we do with OMi is use the service dependency map to get to the root event when a series of events are generated. The actual technology used is the causal engine we released as part of NNMi, but it's using our discovered service dependency map rather than NNMi's discovered network topology.

 

OMi's health views

With OMi you can create health KPIs against the things (CIs) that you are managing. These can be combinations of attributes --  like CPU utilization and free memory on a server so that you can see at a glance the health of the Cis under your management, rather than having to achieve the same thing through wading thru a ton of events.  In other words, OMi is mapping the events onto Cis and building up a health picture for you.

 

OMi and existing HP Operations Manager installations

OMi actually sits on top of existing HP Operations Manager installations. It acts like a manager of mangers for them. It can also take events from other event management systems like SCOM.

---

Posted 12-11-2008 3:36 PM by adsey007