Reverse Integration between OMI -- NNMi

Reverse Integration between OMI -- NNMi

Description:

We require reverse integration between NNM and OMI for Node Down but as observed on enabling reverse integration once the Node down alert gets reset , it reset all the other incidents also along with node down.

Hence, it re triggers all the incidents again . Hence we require that only node down incident gets closed not all other associated incident of the device.

 

Benefits / Value:

It will not retrigger bulk incident which gets closed once and gets retriggered again.

 

Design details:

The reverse integration is resetting all the components status, while it working for Node Down.

 

/opt/OV/support/nnmtwiddle.ovpl invoke com.hp.ov.nms.apa:service=NmsApa clearConclusionsAndStatusOnAllObjectsInNodeThenStatusPoll $sln

 

For eg: If we are having 10 incidents already in registered state, it is closing all the 10 incidents and re-triggering it again as per the above command which is running.

 

Hence, we would like to get solution to this scenario, as we need this reverse integration to work only for Node Down, so can it reset the Node Down event only without affecting the other registered incidents.

8 Comments
Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

Dear Submitter,

Thanks for the idea. However, I need some clarity before we move forward on this idea.

The incident which gets closed here, are they child incidents for node down in this example OR separate incidents? Please clarify.

If they are not child incidents, can you provide example incidents which are getting closed with Node Down incident closure?

Trusted Contributor.. Monojit Kundu Trusted Contributor..
Trusted Contributor..
Hi Team,
The incidents which gets closed are not child incidents those are separate incidents.
For eg: Previously few interface down , chassis down events are generated then node down event got generated . In which for all this events incidents got logged.
In Reverse sync, we have only node down configured hence if the node down incident got closed which trigger the event closure at NNM end also in that case it resets the node status as a result all the previous incidents which were still in registered state gets closed and again on next poll regeneration of all those events along with node down happens if the components are actually down. Which causes repetition of those events other than node down event.
Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

Hi!

If they are not child incidents, then this is not expected behavior and shall be treated as a defect. Please raise a support case for the same so support can investigate and find the root cause of the issue in your environment.

Micro Focus Frequent Contributor
Micro Focus Frequent Contributor
Status changed to: Already Offered

As suggested, please work with support to identify the root cause of the same

Super Contributor.. hiteshkumar Super Contributor..
Super Contributor..

Hi @Monojit Kundu 

You can correlate Node down event with other.i.e if you have 10 events in console and in next 3 hours there is one parent node event getting trigger then child all 10 events will be closed and it will remains only one as major one.

I think you was asking for a parent CI where multiple events depending on that CI only and you need correlation. 

Frequent Visitor.. asish
Frequent Visitor..

I think, we are mixing different scenarios here. Trying to clarify .

Scenario :   There are 10 active event on Device and Device Went down on different time, so Node down Event appeared also on the device and Floated to OMI.

Current Status  :  1 Node Down event and 10 Active incidents for other components.

Action on Reverse Integration : Someone Close the Event on OMI , and as a back sync functionality , OMI send a force closure for Node Down event to NNMi as well.

New Status : Node Down Event gets closed at NNMI . 10 Event still active at NNMI for different components . As an action property configured under Node Down closure for back sync, a command being configured to reset the status of Node in casual engine in order to Node down again , if still device is down.  Everything seems to be fine here. So we have new Node down event again and 10 Active event as well.

Resolve action :  As the node status has been reset for all rest of components in Casual engine under last action , irrespective of 10 event still active for the device and as soon as Node down evet get auto closed after an outage get fixed , Status poll for devices will trigger 10 more new events for the same components. So now we will have Duplicate Events in active state for Same components in NNMi.

 

Updated Status :  Node is healthy , 20 active events at NNMI (Duplicate events).

 

Let me know , incase this need to be discussed in detail. We can connect over a call or webex to explain.

Super Contributor.. hiteshkumar Super Contributor..
Super Contributor..

Hello

Seems you have to try below correlation. If still having the same then there is second solution we can approach at a time :  https://docs.microfocus.com/NNMi/10.30/Content/Administer/nmAdminHelp/nmAdmConfCausalRules0195SubIntEx.htm

On the OMi site, you have to define SBEC based the CI, Time (if required) and Nature what you have mentioned as per your environment. Once the user will force close the node down event on OMi side, correlated 10 events will also get closed. Same will be sync in backward as you mentioned.

I hope it would be helpful 🙂 

Trusted Contributor.. Monojit Kundu Trusted Contributor..
Trusted Contributor..

Hi ,

We would like to understand how the SBEC or NNM correlation feature we can make use for this scenario.

1. Device gets onboarded (Normal status).

2. 5 Interface down event got triggered , 2 chassis down event got triggered, 1 Memory high event triggered in span of 15 days.

3. On 25th day, the device went down and all its previous events were still in registered state.

4. On 30th day if it gets auto closed or someone closes the event from OMi and backsync takes place which closes/resets all the events which were standing earlier i.e. (5 interface down, 2 chassis down, 1 memory high event, 1 node down).

5. On next poll in genuine auto closure case, all the events gets triggered again (5 interface down, 2 chassis down, 1 memory high event) which is increasing the event count for the device.

And we already consulted with the support team and they asked to take it with ER. 

For this above scenario , we need suggestion how can we use correlation or SBEC rule of OMI.. Please set up a call or webex and loop us. monojit.kundu@accenture..com  and ashish.banyal@accenture.com to understand.

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.