Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
icinga-migration opened this issue Sep 28, 2015 · 13 comments

Comments

@icinga-migration
Copy link
Member

@icinga-migration icinga-migration commented Sep 28, 2015

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:

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Nov 2, 2015

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
Copy link
Member Author

@icinga-migration icinga-migration commented Feb 24, 2016

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
Copy link
Member Author

@icinga-migration icinga-migration commented Feb 24, 2016

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
Copy link
Member Author

@icinga-migration icinga-migration commented Feb 25, 2016

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

  • Relates set to 11226
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 4, 2016

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

  • Parent Id set to 11311
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 9, 2016

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

  • Priority changed from Normal to High
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 9, 2016

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

  • Relates set to 11339
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 10, 2016

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
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 11, 2016

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
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 11, 2016

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
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 11, 2016

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
Copy link
Member Author

@icinga-migration icinga-migration commented Mar 11, 2016

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

  • Backport? changed from Not yet backported to Already backported
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented May 3, 2016

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

  • Parent Id deleted 11311
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.