[dev.icinga.com #10225] Host notification type is PROBLEM but should be RECOVERY

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/10225

Created by mwaldmueller on 2015-09-28 07:46:44 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2016-03-11 08:35:05 +00:00)
Target Version: 2.4.4
Last Update: 2016-05-03 13:17:56 +00:00 (in Redmine)

Icinga Version: 2.3.10
Backport?: Already backported
Include in Changelog: 1

---

When a host or service recovers from a warning/critical state the notification.type should be RECOVERY. Instead of the notification type has the value PROBLEM.

Here's an output of a default email notification with the subject: "PROBLEM - testhost is UP"

***** Icinga  *****

Notification Type: PROBLEM

Host: testhost
Address: 127.0.0.1
State: UP

Date/Time: 2015-09-25 14:52:35 +0200

Additional Info: PING WARNING - DUPLICATES FOUND! Packet loss = 0%, RTA = 0.33 ms

Comment: [] 

Changesets

2016-03-10 13:32:57 +00:00 by mfriedrich c0e175d

Fix host recovery notifications for warning states

refs #10225

2016-03-11 08:29:07 +00:00 by mfriedrich 5b6a6f8

Fix host recovery notifications for warning states

fixes  #10225

2016-03-11 14:58:13 +00:00 by mfriedrich ee7af88

Fix host recovery notifications for warning states

fixes  #10225

2016-03-15 08:47:59 +00:00 by mfriedrich 3bd6848

Refactor patch for host recovery notifications

refs #10225

2016-03-15 12:11:01 +00:00 by mfriedrich f386920

Refactor patch for host recovery notifications

refs #10225

---

Relations:

• relates #10225
• relates #11339

[icinga-migration]

Updated by nichols356 on 2015-11-02 14:20:17 +00:00

The PROBLEM is that you have PING WARNING - DUPLICATES FOUND. This is typically due to a load-balanced NIC bond.

[icinga-migration]

Updated by mfriedrich on 2016-02-24 23:02:25 +00:00

• Status changed from New to Assigned
• Assigned to set to mfriedrich

Service exit states 0 and 1 (OK and Warning) are treated as Up, while 2 (Critical) is equivalent to Down. I believe that somewhere when triggering notifications, it is not taken into account that the notification type is NotificationProblem but not NotificationRecovery.

                        OnNotificationsRequested(this, recovery ? NotificationRecovery : NotificationProblem, cr, "", "");

recovery needs to be adjusted for host checks.

        } else if (cr->GetState() == ServiceOK) {
                if (old_state == ServiceOK && old_stateType == StateTypeSoft) {
                        SetStateType(StateTypeHard); // SOFT OK -> HARD OK
                        recovery = true;
                }

                if (old_state != ServiceOK)
                        recovery = true; // NOT OK -> SOFT/HARD OK

                ResetNotificationNumbers();
                SaveLastState(ServiceOK, Utility::GetTime());

                /* update reachability for child objects in OK state */
                if (!children.empty())
                        OnReachabilityChanged(this, cr, children, origin);
        } else {

[icinga-migration]

Updated by mfriedrich on 2016-02-24 23:09:57 +00:00

• Subject changed from Notification type is PROBLEM but should be RECOVERY to Host notification type is PROBLEM but should be RECOVERY

[icinga-migration]

Updated by mfriedrich on 2016-02-25 01:01:26 +00:00

• Relates set to 11226

[icinga-migration]

Updated by mfriedrich on 2016-03-04 15:35:51 +00:00

• Parent Id set to 11311

[icinga-migration]

Updated by mfriedrich on 2016-03-09 11:41:33 +00:00

• Priority changed from Normal to High

[icinga-migration]

Updated by mfriedrich on 2016-03-09 15:33:01 +00:00

• Relates set to 11339

[icinga-migration]

Updated by mfriedrich on 2016-03-10 13:33:25 +00:00

The problem is that you cannot simply pass the state WARNING to a host check result. Using a dummy check which is executed on-demand solves the simulation issue.

Steps to reproduce:

• Passively set the state to UP in Icinga Web 2
• Passively set the state to DOWN in Icinga Web 2
• Manually force the check execution returning WARNING - will change to UP in Web 2 and populate the notification log

unpatched:
'10225-host' has type 'PROBLEM'
'10225-host' has type 'PROBLEM'
'10225-host' has type 'PROBLEM'

patched:
'10225-host' has type 'RECOVERY'
1457615925: Host '10225-host' has type 'RECOVERY'

object Host "10225-host" {
  check_command = "dummy"
  vars.dummy_state = 1
  vars.dummy_text = "warning"
  check_interval = 24h
  retry_interval = 24h
  max_check_attempts = 1
}

object Notification "10225-host-notification" {
  host_name = "10225-host"

  users = [ "10225-user" ]
  command = "10225-notify-command"
}

object NotificationCommand "10225-notify-command" {
  import "plugin-notification-command"

  command = "echo \"`date +%s`: Host $host.name$ has type $notification.type$\" >> /tmp/i2.notify"
}

object User "10225-user" {
  email = "foo@foo.com"
}

Requires more tests.

[icinga-migration]

Updated by mfriedrich on 2016-03-11 08:31:08 +00:00

• Target Version set to 2.5.0

This bug only triggers if there is RECOVERY condition from DOWN -> UP whereas the check result was WARNING.

[icinga-migration]

Updated by mfriedrich on 2016-03-11 08:35:06 +00:00

• Status changed from Assigned to Resolved
• Done % changed from 0 to 100

Applied in changeset 5b6a6f8.

[icinga-migration]

Updated by mfriedrich on 2016-03-11 13:27:19 +00:00

• Target Version changed from 2.5.0 to 2.4.4

[icinga-migration]

Updated by mfriedrich on 2016-03-11 14:58:21 +00:00

• Backport? changed from Not yet backported to Already backported

[icinga-migration]

Updated by mfriedrich on 2016-05-03 13:17:57 +00:00

• Parent Id deleted 11311