Highlighted
Absent Member.. Absent Member..
Absent Member..
435 views
 
Labels (1)
0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

As you are finding out, OMi10 is not exactly the same as BSM 9.x.  BSM 9.x has an event channel (eg for OMi event driven use cases) and a metric channel.  In BSM 9.x, service health can be driven by events or metrics for a given HI/CI combination.

OMi10 doesn't have a metric channel and doesn't import/store metrics on the OMi server.  Instead, OMi's Performance Grapher queries the metrics directly from the data source (eg, BSMC metric store).  As for service health, in OMi10 it is event driven only.

Event driven service health means you can set the EtiHint event attribute.  You can specify it as name:state[:value].  Eg, CPULoad:Bottlenecked:100 or CPULoad:Normal:55.  Each one will update indicator state and value in the GUI.

In BSM 9.x, this also worked.  But with a metric channel the samples (metrics) were being sent to BSM for BSM to calculate if a threshold was exceeded to set service health.

Event driven means that we work with exceptions.  Ie generate an event when something bad happens or when a status changes (eg, good to not good to bad to worse to good etc).  This means that if an object stays in the same state for a period of time, then the value you would see in the GUI shows what it was at the time of the status change (ie when the last event was received to set the name:state:value for the HI).

So to see current/historical/trending data for metrics, it is best to use the performance grapher.  Eg, add it as a component to the workspace or cross-launch.  This is the more scalable approach.

CP.

 

View solution in original post

3 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

As you are finding out, OMi10 is not exactly the same as BSM 9.x.  BSM 9.x has an event channel (eg for OMi event driven use cases) and a metric channel.  In BSM 9.x, service health can be driven by events or metrics for a given HI/CI combination.

OMi10 doesn't have a metric channel and doesn't import/store metrics on the OMi server.  Instead, OMi's Performance Grapher queries the metrics directly from the data source (eg, BSMC metric store).  As for service health, in OMi10 it is event driven only.

Event driven service health means you can set the EtiHint event attribute.  You can specify it as name:state[:value].  Eg, CPULoad:Bottlenecked:100 or CPULoad:Normal:55.  Each one will update indicator state and value in the GUI.

In BSM 9.x, this also worked.  But with a metric channel the samples (metrics) were being sent to BSM for BSM to calculate if a threshold was exceeded to set service health.

Event driven means that we work with exceptions.  Ie generate an event when something bad happens or when a status changes (eg, good to not good to bad to worse to good etc).  This means that if an object stays in the same state for a period of time, then the value you would see in the GUI shows what it was at the time of the status change (ie when the last event was received to set the name:state:value for the HI).

So to see current/historical/trending data for metrics, it is best to use the performance grapher.  Eg, add it as a component to the workspace or cross-launch.  This is the more scalable approach.

CP.

 

View solution in original post

Highlighted
Absent Member.. Absent Member..
Absent Member..
 
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

It will set a new value if the state doesn't change, but that requires an event to do it.  So, if you have lots of HIs, this means lots of events.  This is the drawback.

CP.

0 Likes
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.