Scenario


Consider that you have an online store that sells widgets A, B, and C. Each type of widget is served by distinct WebServer pools, as well as by different application servers or databases behind the Webservers or both.

  1. Online Store A consists of one pool of Web servers (WebServer Pool A) dedicated to selling widget A items but also depends on a pool of application servers (Appserver Pool A) and on database A. 
  2. Online Store B consists of another pool of Web servers (Webserver Pool B) dedicated to selling widget B items but also depends on a pool of application servers (Appserver Pool B) and on database B. 
  3. Online Store C consists of a similar third configuration set up for selling widget C items.
     

    In this scenario, you want to convey this information into the BMC ProactiveNet system so that it can be leveraged by Probable Cause Analysis algorithms. Using the Relationships folder located in the Administration Console, you can input this relationship information into the system so that it can be used whenever a problem crops up with a transaction on any of the three online stores. This information is known as domain knowledge.

    After these relationships have been established, if there is a problem with any of these online stores and an event is triggered, as you drill down on the event through the Probable Cause pages, BMC ProactiveNet guides you to the most accurate Probable Cause event that is related to the event, thus taking advantage of the domain knowledge injected into the system via the relationship mechanism. Without this information, the Probable Cause algorithm must rely strictly on out-of-the-box relationships, thus limiting the conclusions it can draw about the potential causes of an event.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

BMC ProactiveNet 9.6