Highlighted
Established Member.. CharlesWu
Established Member..
418 views

Where can we see the tree in OMW services map in OMi views

Jump to solution

We have DBSPI Monitors on OMW integrated to BSM 9.23 where I can see DBSPI events in the event browser in the OMi Event Perspective.  We wonder in which view we can see the tree similar to the services map in OMW that gives the relationship like this services > Applications > SPI_for_Databases > DBSPI Oracle > nodename Oracle Unix > Orace instance name > tablespace.  Currently, all of DBSPI events shown in OMi event browser are all tied to server name, so we wonder if we can have such view that can pinpoint the problem to the db instance/tablespace level? Any contect packs we need to apply or customization is needed to achieve this? Please give me a direction. Thanks.

0 Likes
1 Solution

Accepted Solutions
Contributor.. sigi_1 Contributor..
Contributor..

Re: Where can we see the tree in OMW services map in OMi views

Jump to solution

Hello Charles,

adding to Dave's response:

In your given example with OMW and DB-SPI for Oracle

- Topology sync would allow you bring the OMW hierarchy into RTSM:
   Configure topology sync to include sync-package HPOprOra
   The default sync-package includes DB instances, not tablespaces.
   If you want to sync more details, sync-packages can be customized, see BSM Extensibility Guide.

- The BSM content pack for Oracle brings out-of-box Health Indicators, ETIs, Views, correlations rules, graphs ...
   for Oracle CIs. Make sure it is loaded. One view to see your Oracle topology is e.g. "ORA_deployment"

- Please make sure to use the latest DB-SPI version. This will include policies with relatedCIHints that allow events to
  resolve to Oracle CIs, e.g. down to individual DB instances

What's the advantage of mapping events to individual DB instances instead to a node?
Dave already lined this out as the "CI-centric approach".
Example: One Oracle server hosts multiple database instances that serve different business processes. By resolving events to individual instances, you get the correct impact of one DB problem to the affected business service.
By "just" resolving to the node that runs all these Oracle instances, you could not propagate to the "right" business service.

2 Replies
Dave Trout Absent Member.
Absent Member.

Re: Where can we see the tree in OMW services map in OMi views

Jump to solution

Hi,

Here are some brief comments that will hopely help.  If this is too basic, my apologies.

 

First we need to understand how OM and OMi are different in terms of how we track and visualize the health of elements in a service heirarchy.

 

In OM, your Oracle Service Map as created by the DBSPI is based only on events.  Each "Service" in the map gets its severity typically by taking the serverity of the "most critical" event which is pointing to that service (via the "ServiceID" attribute in the event) and/or from propagation of severities from elements lower in the hierarchy.

 

In BSM/OMi, things work a bit differently.  There are basically two ways to visualize health in your case, where you are coming from OM and using the DBSPI.  Initially, you might want to continue with the approach of basing health solely on events and their severities.  In this case, you could make use of the Event Dashboard in OMi.  The Event Dashboard would allow you to design and create widgets for visualizing the "most critical" status of groups of events.  These widgets can be organized and positioned very easily into your MyBSM dashboard pages using the Event Dashboard Designer within OMi.  The key thing to remember is that with the Event Dashboard you are still looking at "health" in terms of events only.

 

To get more value out of OMi, potentially later in your deployement, you would probably want to consider moving to the CI-centric approach for tracking and representing health.  For this approach,  each element of the hierarchy is discovered and populated into the Run-Time Service Model (RTSM) as Configuration Items (CIs).  These elements can be discovered in various ways, including forwarding the OM Service Map topology into RTSM via topology synchronization.  The CIs could also be discovered and brought into RTSM from an external UCMDB.  So we would have an Oracle CI, a Node CI (for the node which Oracle runs on), an Oracle Tablespace CI, etc.

 

Now with the CIs (and associated relationships) in the RTSM topology, our arriving events into OMi can be "resolved" to each of the appropriate CIs.  For example, an event representing a problem with an Oracle Tablespace would resolve (be associated with) the Oracle TableSpace CI, NOT the node on which Oracle is running.  To summarize the remaining steps at this point:  The events can start in motion the ultimate calculation of CI status for each of the Oracle-related CIs in our topology.

 

Now coming to the answer I think you are looking for:  To see a hierarchy of Oracle health which is based on the CI status, we would then use one of the available Oracle views, or perhaps create one if needed.  But the important thing here is that the views are visualizing health based on CI status (which is being calculated on a system of Health Indicators and Key Performance Indicators) not just on events.

 

Does this help?

Contributor.. sigi_1 Contributor..
Contributor..

Re: Where can we see the tree in OMW services map in OMi views

Jump to solution

Hello Charles,

adding to Dave's response:

In your given example with OMW and DB-SPI for Oracle

- Topology sync would allow you bring the OMW hierarchy into RTSM:
   Configure topology sync to include sync-package HPOprOra
   The default sync-package includes DB instances, not tablespaces.
   If you want to sync more details, sync-packages can be customized, see BSM Extensibility Guide.

- The BSM content pack for Oracle brings out-of-box Health Indicators, ETIs, Views, correlations rules, graphs ...
   for Oracle CIs. Make sure it is loaded. One view to see your Oracle topology is e.g. "ORA_deployment"

- Please make sure to use the latest DB-SPI version. This will include policies with relatedCIHints that allow events to
  resolve to Oracle CIs, e.g. down to individual DB instances

What's the advantage of mapping events to individual DB instances instead to a node?
Dave already lined this out as the "CI-centric approach".
Example: One Oracle server hosts multiple database instances that serve different business processes. By resolving events to individual instances, you get the correct impact of one DB problem to the affected business service.
By "just" resolving to the node that runs all these Oracle instances, you could not propagate to the "right" business service.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.