The main role of this feature is to allow users to have the same correlation views in the console than they got in the notifications.

From now, users won’t get notified if there was a dependency problem or example (a host in DOWN make the service notifications to not be send for example). But in the console, we still got some green and red indicators : the scheduler waited for actual checks to put the elements in a UNKNOWN or UNREACHABLE state when he already know that there was a dependency problem.

Now it’s smart enough to put such states to elements that we know the check will fail. An example?

Imagine such a parent relations between hosts :

If gw is DOWN, all checks for others elements will put UNREACHABLE state. But if the fw and servers are checks 5 minutes later, during this period, the console will still have green indicators for them. And are they really green? No. We know that future checks will put them in errors. That why the problems/impacts feature do : when the gateway is set in HARD/DOWN, it apply a UNREACHABLE (and UNKNOWN for services) states for others elements below. So the administrators in front of his desk saw directly that there is a problem, and what are the elements impacted.

It’s important to see that such state change do not interfere with the HARD/SOFT logic : it’s just a state change for console, but it’s not taken into account as a checks attempt.

Here is a picture of what it looks like (Ninja interface here) :

Here gateway is already in DOWN/HARD. We can see that all servers do not have an output : they are not already checked, but we already set the UNREACHABLE state. When they will be checks, there will be an output and they will keep this state.

It's quite easy, all you need is to enable the parameter

enable_problem_impacts_states_change=1

See the page configuringshinken-configmain-advanced for more information about it.

There is a good thing about problem/impacts when you mis it with the criticity flagging : your problem will dynamicaly inherit the maximum criticity of its current impacts!

Let take an example : you have a switch with different childs, one is a devel environnement with a low criticity (0 or 1) and one with a huge criticity (4 or 5). The network administrator has set SMS notification at night but only for HUGE criticities impacts (min_criticity=4 in the contact definition for example).

It's important to say that the switch DO NOT HAVE A OWN CRITICITY! A switch is here to server applications, the only criticity it got is the one of the applications on it!

There are 2 nights :

• the first one, the switch got a problem, and only the devel environnement is impacted. The switch will inherit the maximum criticity of its impacts (or it own value if it's higer, it's 3 by default for all elements). Here the devel criticity is 0, the switch one is 3, so its criticity will stay at 3. It's slower than the contact value, so the notification will not be send, the admin will be able to sleep :)
• the second night, the switch got a problem, but this time it impacts the production environment! This time, the computed criticity is set at 5 (the one of the max impact, here the production application), so it's higher than the min_criticity of the contact, so the notification is send. The admin is awaken, and can solve this problem before too many users are impacted :)