Another (deep) tech dive in NNMi event configuration, following up on this post. NNM consultants read on.
In my previous post I’ve described a way to create an incident (and affect node status) whenever a certain condition is detected on the node, like an interface coming up. This was done by creating a custom poller and works fine, as long as you need to monitor only one status change on the managed node. But, what happens if you need to detect two or more status changes on the same node occuring on different entities, like detecting the case when on a branch router both the main and backup lines are up?
In the NNMi world this is a “causal rule”. A causal rule is fulfilled whenever a certain number of “child incidents” are detected by NNMi. In our case, one child incident is “main line up” and the other “backup line up”. Whenever these incidents are detected for the same managed node, a causal correlation is fulfilled and a custom event is shown in the operator incident browser.
The procedure is (not so) simple. First, make sure you have created the custom pollers for the incidents you are interested in. Then, you need to create a causal correlation rule in NNMi:
- Go to Configuration tab -> Custom correlation configuration. Click on the “Causal rules” tab on the right pane.
- Create a new rule. Type a rule name and in the “Parent Incident” drop down entry select “New”. This will be the event that will be generated in NNMi when your causal correlation kicks in. Type a description and set its criticality.
- Now we need to define the conditions that must occur to produce the event described above. Back in the “Causal rule” form, select as correlation nature “Root Cause” and in the “Common Child Incident Attribute” type:
This is the primary key in correlating the children incidents: If they occur in the same node, then they are correlated.
- In the “correlation window” box below set a threshold time value to a meaningful time window. NNMi will create the correlation if the desired children incidents for the same node occur within this time window.
- Now it’s time to define the children incident subrules that, when fulfilled, will generate our custom event. In the “Causal rule” form, create a new “child incident”. Set a proper name and in the “Child Incident” drop down, select the right incident. In our example in my previous post, this would be a “CustomPollWarning” or “CustomPollMinor” event. It is important to designate this correctly and match your custom poller type.
- Make sure you check the “Use Child Incident’s Source Object for Parent” and “Use Child Incident’s Source Node for Parent” check boxes. Leave the “Optional Child Incident” unchecked.
- If you have defined policies in your custom pollers, move to the pane on the right in the “Child Incident Filter” tab. Create a filter like this:
This will match your policy set in your custom poller.
- Repeat the same steps for the second child incident. The difference is that you have to leave the “Use Child Incident’s Source Object for Parent” and “Use Child Incident’s Source Node for Parent” check boxes unchecked. Again, leave the “Optional Child Incident” unchecked.
- Save everything and close the forms.