Workaround on 5min-delay of creation of AddressNotResponding incident at NNMi 9.23.004
Has anyone found workaround for the following "problem":
AddressNotResponding incident is created after 5-6min, because the root cause analysis creates two episodes:
- InterfaceDown (which is described at the NNMi administration manual), which lasts 1min
- NodeUnmanagable (which is missed at the NNMi administration manual), which lasts 5min.
That means NNMi ALWAYS delays this specific incident for at least 5min, ingoring the setting of the monitoring polling intervals of the node and interface where the IP address is hosted on. This interval at my NNMi is 1min, and NNMi sets the duration of NodeUnamangeble to 300sec (>60s).
Has anyone faced the same problem with me?
Can I configure anywhere the duration of the NodeUnmanagable episode?
Can I configure anywhere which episodes can occur for AddressNotResponding?
Could you please suggest me a workaround?
Thank you in advance!
This 5 minute delay is part of the original design philosophy for NNMi which was to reduce the number of incidents reported to the user with a goal to issueing just 1 that indicates the primary cause of the failure. In order to do this and avoid initial floods of incidents before the primary cause is identified there is this 5 minute delay which is covering the period while all the analysis of the situation is being performed.
At this time this is not configurable. However the scenario has been recently raised by a couple of users, and I believe the feature is under constant review to see if it can be improved and the time delay shortened but with still keeping the original goal in mind.
All the best
Viewed the Support tips? Search for "(NNMi) Support Tips" and order by Date to get the list
The views expressed in my contributions are my own and do not necessarily reflect the views and strategy of MicroFocus
If you find this or any post resolves your issue, please be sure to mark it as an accepted solution.
Hello Anna Blessed
In case you need it, there is an ER already submitted related to faster response time for AddressNotResponding incidents.
You may want to check the following URL:
The views expressed in my contributions are my own and do not necessarily reflect the views and strategy of HP.
If you find this or any post resolves your issue, please be sure to mark it as an accepted solution, If you are satisfied with anyone’s response please remember to give them a KUDOS and show your appreciation.
this ER has been created, because I opened a case to HP Support. When they regarded this malfunction as an ER instead of bug, without providing me with a workaround, I thought that forum could help me on this problem.
To my view, it is a common sense to report a malfunction as a bug, when NNMi does not follow what manual describes. Specifically, NNMi manual describes only one episode which lasts 1min. It does NOT describe an episode which lasts 5mins. Thus, since NNMi running code does not follow manual, then NNMi has a bug.
Furthermore, I have told to HP support that this is not just another bug.
On the contrary, it is a CRITICAL bug because that means the following:
******** NNMi DOES NOT SUPPORT MONITORTING POLLING INTERVAL LESS THAN 5min *******
The above statement is a big disadvantage/limitation for a monitoring tool.
Due to my software engineering background, for me it is totally unacceptable the duration of an episode (which is 300s) to be an absolute value inside the code.
NO ABSOLUTE VALUES SHOULD BE PERMITTED IN A CODE.
On the contrary, the duration should be read from a configuration file.
Finally, the duration SHOULD NOT be greater than the monitoring polling interval!
At the next polling interval (in 1min), Node is manageable, but the episode is still sleeping. It is waiting for 5min.
Thank you for your time.