Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #4430] External command to disable/enable freshness checking for specific hosts services #1314

Closed
icinga-migration opened this issue Jul 19, 2013 · 8 comments

Comments

@icinga-migration
Copy link

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

Created by fruminator on 2013-07-19 12:47:33 +00:00

Assignee: (none)
Status: Resolved (closed on 2014-03-03 21:35:42 +00:00)
Target Version: 1.11
Last Update: 2014-03-03 21:35:42 +00:00 (in Redmine)


vis a vis: http://docs.icinga.org/latest/en/extcommands2.html

{DISABLE,ENABLE}_{HOST,SERVICE}_FRESHNESS_CHECKS already exist, but the disable/enable freshness checking at the entire system level.

Would be good to support disabling/enabling freshness checks for particular hosts services. Thus, propose adding the following commands, in the same vein as the commands to disable/enable passive checks for particular hosts/services.

DISABLE_FRESHNESS_HOST_CHECKS;<host_name>
ENABLE_FRESHNESS_HOST_CHECKS;<host_name>

DISABLE_FRESHNESS_SVC_CHECKS;<host_name>;<service_description>
ENABLE_FRESHNESS_SVC_CHECKS;<host_name>;<service_description>

Attachments

Changesets

2014-03-03 20:47:51 +00:00 by philmatu 62c72ea

External command to {en.dis}able freshness checks for hosts/services.

This patch enables commands to control freshness checking at both the
host and service level. Sometimes, it is necessary to implement
delayed notifications. In our case, passive notifications are being
sent from vehicles that leave the range of our wireless network coverage
area. When the vehicle leaves, we get a notification that the vehicle is
no longer reachable, but it should return within X hours. We wanted to
implement a delayed failure on only specific vehicles. By using freshness
checking, we wait for a passive check to come in saying the vehicle is gone,
then we enable a freshness check on that specific vehicle service and
change the current state to warning. If the vehicle is gone for more than
X hours, the freshness check will run automatically and change the state
to Critical. Hence, a delayed notification is now available. Furthermore,
this is useful with SNMP traps, where the trap may be sent several times,
but we want the first to be a warning, and the second trap to be a failure.

Refs #5422
Refs #4430

Signed-off-by: Michael Friedrich <Michael.Friedrich@netways.de>

2014-03-03 21:32:38 +00:00 by (unknown) 150e3db

Update Changelog/AUTHORS.

Refs #5422
Refs #4430

2014-03-03 21:33:23 +00:00 by (unknown) 90423a4

Merge branch 'feature/ext-cmd-freshness-5422' into next

Fixes #5422
Fixes #4430

Relations:

@icinga-migration
Copy link
Author

Updated by fruminator on 2013-07-19 12:49:53 +00:00

This should be pretty straightforward. Just a matter of editing the commands.c file; practically a copy/paste job mimicking the way {DISABLE,ENABLE}_PASSIVE_{HOST,SVC}_CHECKS is implemented.

@icinga-migration
Copy link
Author

Updated by fruminator on 2013-07-19 12:52:21 +00:00

from some inspection of checks.c and events.c it does seem that all that needs to happen is changing the value of the check_freshness member of the relevant host/host_struct variable.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-07-20 10:41:03 +00:00

patches welcome.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-07-27 17:36:22 +00:00

  • Status changed from New to Feedback

@icinga-migration
Copy link
Author

Updated by philmatu on 2013-12-19 16:01:37 +00:00

Fruminator and I work for the same company. We have solved this problem with a workaround solution, that allows for the delayed response of passive checks (e.g. allowing for multiple SNMP traps, the first resulting in a warning, the second resulting in a critical state).

I created the patch as described but ran into a strange occurrence, freshness checking isn't a defined host or service field for the CGI status file or retention file, yet the web interface notified me of a modified freshness checking attribute in the core. After further digging, there is a modified attributes field, and an external command that allows the modification of this.

Although not as clear cut as I'd like, this is a much cleaner solution that doesn't require further development, since my patch would have required further reworking the status output files to maintain consistency in the source code across the core like the passive checking command maintains.

Therefore, the workaround is as follows (modeled on http://docs.icinga.org/latest/en/modified\_attr.html):

Enable Freshness checking:
Host: CHANGE_HOST_MODATTR;{HOST};8192
Service:CHANGE_SVC_MODATTR;{HOST};{SVC};8192

Disable Freshness checking:
Host: CHANGE_HOST_MODATTR;{HOST};0
Service:CHANGE_SVC_MODATTR;{HOST};{SVC};0

It is wise to obtain the previous value of the modification attribute (by parsing the status.dat file), then subtract or add 8192, since in our case, Passive checking (4) is also modified, so the value that we need to set and unset is 8196.

@icinga-migration
Copy link
Author

Updated by philmatu on 2014-01-08 21:18:14 +00:00

  • File added freshnesspatch.git

After further investigation, The MODATTR hack outlined above would only if the core was restarted every time this command was issues. Obviously, this won't work for our needs, so I've moved ahead with a patch that enables the following commands:

DISABLE_FRESHNESS_HOST_CHECKS;<host_name>
ENABLE_FRESHNESS_HOST_CHECKS;<host_name>

DISABLE_FRESHNESS_SVC_CHECKS;<host_name>;<service_description>
ENABLE_FRESHNESS_SVC_CHECKS;<host_name>;<service_description>

The commands are persisted across restarts using the MODATTR values, as outlined above, which are stored in the status.dat file, making no major modifications necessary to either this output/retention file, internal Icinga datastructures, nor the web interface (CGI). The patch allows for the existing global freshness checking functionality, meaning if ";<host_name>" is null, the global freshness checking will be altered (as it currently behaves in the master).

Attached is the patch that I have thoroughly tested against the master of Icinga-core. I'm hopeful that this can be integrated into the master.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2014-03-03 21:33:48 +00:00

  • Target Version set to 1.11

@icinga-migration
Copy link
Author

Updated by Anonymous on 2014-03-03 21:35:42 +00:00

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

Applied in changeset 90423a4.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant