Icinga2: Override of custom variable not working since upgrade
Since an upgrade of Icinga2 from version 2.8.4.1 to 2.9.1-1 there is a strange behaviour with variable override in combination with the Director.
First I thought it might be Director related, because it is an add-on to Icinga2, but after some investigation it seems related to the upgrade of the Icinga2 core binaries.
For this reason I am filing this issue over here as well, because I am not sure which of the two causes this issue.
To see my initial report and investigation see issue number 1579 in the Director repository.
Expected Behavior
I expect to use override for variables.
Current Behavior
For some host checks the override is ignored and the default values are used which were defined in a host template.
Possible Solution
Temporary workaround to downgrade to Icinga2 version 2.8.4-1.
Steps to Reproduce (for bugs)
Seems that not everyone hits this issue, but I did this:
- Set some custom variables, apply them to hosts and set an override value on the host.
- Package upgrade Icinga2 (icinga2, icinga2-bin, icinga2-common, icinga2-doc, icinga2-ido-mysql) from 2.8.4-1 to 2.9.1-1 from repository: http://packages.icinga.com/debian
- Some hosts with the variable override will use their default values which were set in a template for example.
Context
It seems that not every override is affected and even in similar setup I couldn't reproduce it. This makes it hard to figure it out how to debug this issue.
Your Environment
- Version used (
icinga2 --version): 2.9.1-1 - Operating System and version: Debian 8.11 (Jessie)
- Enabled features (
icinga2 feature list): api checker command graphite ido-mysql livestatus mainlog notification perfdata - Icinga Web 2 version and modules (System - About): 2.6.1
quentinsch
All 21 comments
Any configuration example in order to reproduce the issue?
dnsmichi
on 7 Aug 2018
Yes, @dnsmichi . Please see issue 1579 in the Director repository for an example of my configuration.
quentinsch
on 7 Aug 2018
I was asking about a generated configuration snippet one can simple put into conf.d and reliably test in an isolated sandbox without the application overhead. The linked issue just has a Director screenshot.
dnsmichi
on 7 Aug 2018
Ok, you mean like this?:
template Host "check-interval-5m-standard" {
check_command = "ping4"
max_check_attempts = "6"
check_period = "24x7"
check_interval = 5m
retry_interval = 2m
check_timeout = 1m
enable_notifications = true
enable_active_checks = true
enable_passive_checks = true
enable_event_handler = true
enable_flapping = true
enable_perfdata = true
volatile = false
vars.enable_pagerduty = "enabled"
vars.not_per = "24x7"
vars.par_host = "10.1.1.1"
vars.ping_cpl = "90"
vars.ping_crta = "1000"
vars.ping_wpl = "75"
vars.ping_wrta = "800"
vars.slack_notifications = "enabled"
}
object Service "NTP check" {
host_name = "XXX0000"
import "check_nrpe-24x7"
vars.nrpe_arguments = [ "nvntp1", "10", "20" ]
vars.nrpe_command = "check_ntp_time"
import DirectorOverrideTemplate
}
object Host "XXX0000" {
import "check-interval-5m-standard"
display_name = "XXX0000 - Squid Proxy"
address = "xxx0000"
vars["_override_servicevars"] += {
"NTP check" = {
not_per = "never"
nrpe_arguments = [ "ntp0.nl.net", "10", "60" ]
nrpe_command = "check_ntp_time"
nrpe_timeout = "60"
}
}
}
I hope I have all the code from the Director to reproduce (although I couldn't...)
quentinsch
on 7 Aug 2018
Hm. That's the hack with the global function which reads _override_servicevars. AFAIK the code hides in 000-director.conf or similar - check the generated output config files each. That overrides a specific Icinga 2 behaviour and customizes that for the Director.
Going this region, I'd say the bug hides somewhere in there, and these kind of functions are user-space. Still I'd like to see what's going on in that function where I may help here.
dnsmichi
on 7 Aug 2018
You mean this part?:
const DirectorStageDir = dirname(dirname(current_filename))
globals.directorWarnedOnceForThresholds = false;
globals.directorWarnOnceForThresholds = function() {
if (globals.directorWarnedOnceForThresholds == false) {
globals.directorWarnedOnceForThresholds = true
log(LogWarning, "config", "Director: flapping_threshold_high/low is not supported in this Icinga 2 version!")
}
}
if (! globals["DirectorOverrideTemplate"]) {
const DirectorOverrideVars = "_override_servicevars"
const DirectorOverrideTemplate = "host var overrides (Director)"
template Service DirectorOverrideTemplate ignore_on_error {
/**
* Seems that host is missing when used in a service object, works fine for
* apply rules
*/
if (! host) {
var host = get_host(host_name)
}
if (vars) {
vars += host.vars[DirectorOverrideVars][name]
} else {
vars = host.vars[DirectorOverrideVars][name]
}
}
}
Ok, so you're using a Service object and not an apply rule. Just for testing, what happens if you change the Service object into an apply rule like
apply Service "NTP check" {
import "check_nrpe-24x7"
vars.nrpe_arguments = [ "nvntp1", "10", "20" ]
vars.nrpe_command = "check_ntp_time"
assign where host.name == "XXX0000"
import DirectorOverrideTemplate
}
In my test setup that seems to work fine, but it did also with the initial override. That's a kind of frustrating that it is hard to reproduce.
Downside of the apply rule you suggested is that it is not part of a service set and is deployed separate to the host.
But the result look in the test setup like this (lower one is the apply rule):
quentinsch
on 7 Aug 2018
It is just for testing - I don't really understand why there are service objects involved, and not apply rules everywhere. The whole override logic would also be simpler with a construct like this:
if (host.vars.bla) {
vars.bla = host.vars.bla
} else {
vars.bla = "default service value"
}
Still, I doubt that get_host() works reliably in a service object. Those object accessor methods were implemented with runtime evaluation in mind, meaning to say, you'll use them in lambda functions and not necessarily in config compile scopes.
That expression inside the service template was never officially supported by Icinga 2, and as such I do think that you need to head over to the Director project again.
dnsmichi
on 7 Aug 2018
I am with you and this what I was afraid for that the Icinga2 core slightly differs from the Director project...
I'll take your feedback back to the Director project and hopefully they can figure it out.
Thanks for you help though!
quentinsch
on 7 Aug 2018
The use of get_host() is a workaround for an Icinga 2 inconsistency and has been suggested by Icinga 2 core developers at the time being. The main goal was to provide consistent behavior. Users should be allowed to use either Service objects or Apply rules depending on their very own needs - and expect things to "just work".
Director could of course render the above example in a different way. If there is the requirement to kick out an 1.5 release to work with 2.9 we can do so. But first we need to figure out what's going wrong here. If a configuration that runs fine on 2.8 doesn't work on 2.9 to me that's a severe problem. We depend on consistent and reliable behavior. If we cannot trust such simple constructs we should better move to a system where Director flattens out the whole configuration and doesn't base it's logic on any special DSL feature at all.
Thomas-Gelf
on 7 Aug 2018
I doubt that this "feature" worked with 2.8 and versions before. I have never suggested to use it this way, I would remember this.
Anyhow, my recommendation is to find out why it fails in certain scenarios and consider a possible solution. My suggestion here would be the above with apply rules only and conditions (available since 2.3+), if there are other requirements or code changes involved with a static service-object-get-host flow, one needs to assign resources for it.
Cheers,
Michael
dnsmichi
on 7 Aug 2018
@dnsmichi: it absolutely did. Variable overrides work since a long time in the Director. They have been implemented to work around a generic problem with apply rules: host-specific thresholds. @quentinsch reported that downgrading to 2.8 works. @terra-nova reported the same problem since upgrading to 2.9.1 in a related/linked issue. Do I oversee any evidence teaching us to not believe them?
Something changed here, and I'm eager to figure out the root cause before blindly remodeling things that used to work. Constructive assistance would be highly appreciated.
Thomas-Gelf
on 7 Aug 2018
Analysis
I'll try to explain the problem in detail and provide a (technical) summary about options and solutions below.
The Problem
Given the following configuration snippet.
Define a host somewhere in your configuration.
vim hosts.conf
object Host "test" {
check_command = "dummy"
}
Define a service object somewhere else in your configuration, and try to load the host object into your scope.
vim services.conf
object Service "test" {
host_name = "test"
check_command = "dummy"
var my_host = get_host("test")
}
Our config parser will parse the host and service definitions into actual configuration items (not objects).
In a secondary step, the config items are compiled and all referenced are being resolved.
At the time where the service object calls get_host() (or any other get_object function which returns the full object) there is no guarantee that this function call actually returns the compiled object.
It may or may not work, probably it does most of the time. Still, there's a chance that it won't and therefore the behaviour of this function call is undefined.
In contrast to this undefined behaviour, the apply rules are safe. They are not compiled into actual objects at the time where hosts, services, etc. are loaded into memory, but at a later stage.
This is for the reason that e.g. a service apply needs the full host object and its attributes. Users may want to not only filter for specific attributes, but actually inherit/copy them into the future service object space.
This is what we wanted in early 2014 when designing the apply rules. When we've added the object accessors, it was clear that they need to be called when all objects are compiled into memory - either in the apply rule stage, or directly at runtime.
vars.my_host_attribute = {{
var host = get_host("$host.name$")
if (host && host.vars.contains("test")) {
return host.vars.test
}
return ""
}}
Dependent objects, another example
There is another problem with service apply rules and get_service() for example. If an apply rule would check in assign where if a service object already exists, there's no guarantee for that either. A service object may already be instantiated, a service object generated from another apply rule is not there and the checks fail.
A short example for better illustrating the problem:
object Host "test" {
check_command = "dummy"
}
apply Service "s1" {
check_command = "dummy"
assign where true
ignore where get_service(host.name, "s2")
}
apply Service "s2" {
check_command = "dummy"
assign where true
ignore where get_service(host.name, "s1")
}
One time it may work one way, another time the other way around. That's a problem with object generation and dependent objects too. Multiple apply rule stages are technically possible, but the more you add, the slower the config validation will be. Large setups with already a minute won't be happy about this.
Conclusion
Given the problem with this undefined behaviour, one configuration compilation during a reload may work, the other one may not.
I know that the mentioned snippet never worked reliably and caused a small percentage to not work. Users might then just fire another reload, or they didn't notice it. Even if one of us core developers said otherwise, it was wrong. You can trust my expertise on this.
The reason why this may be more visible are changes in 2.9 with the object activation order required by unwanted notifications and no logging up front. Still, the original undefined behaviour is not affected by this, it may just happen more often. The user who has opened this issue stated that he's not able to reproduce the behaviour locally, it just happens randomly.
I remember that we've told a customer a while ago to not use object accessor methods in other objects during static config compilation. The documentation might not be explicit about it, that's something we should fix.
One could argue to fix the configuration compiler, and compile the config items one by one, ensuring that these kinds of flows do work. From my technical understanding and feedback rounds with Gunnar, I do believe that this would be very much expensive in terms of configuration validation times with blocking sequences and synchronous processing. It definitely will slow down the configuration activation process, which is not a good strategy in times where we want to speed things up with >100k objects and issues are opened that compilation gets slower.
It may also need weeks of man power to rewrite the config compiler for such a feature, and unfortunately I cannot guarantee that I or one of my squad team members may actually solve it. I personally doubt that the resources invested into this are worth the outcome, left aside all the other projects we need to cope with. I'll leave that to @lippserd to discuss and decide.
In terms of the problem arising with the implementation inside the Director, I can only suggest to use apply rules here, even if they may be more expensive for a single host/service relation. It may be an option to only render "apply" when the user actively has overridden host custom attributes, but I could imagine that this is not possible. I don't know how the relations and rendering are bound to each other in the code, that's something you can estimate better.
Sorry for the long text, I thought I'd explain everything in detail for anyone out there.
Cheers,
Michael
dnsmichi
on 7 Aug 2018
I followed the philosophy of @dnsmichi of using apply rules and converted all Service Sets to Service Apply Rules. This worked as a charm and all the overrides are handled correctly now. So this resolves the override issue for me, but the question still remains what the purpose is of Service Sets and how they are handled. As far as I understand from Michael Friedrich that apply rules should be the way to go and this makes Service Sets an unsupported feature and should be deprecated for that reason? Or am I missing here something?
quentinsch
on 8 Aug 2018
I've had an offline meeting with @lazyfrosch today and explained and discussed the problem and possible solutions in deep.
He's going to handle this, also for service sets and takes the lead from here. Please follow icinga/icingaweb2-module-director#1579 for ongoing discussions and solutions.
dnsmichi
on 8 Aug 2018
While it would be a nice feature to be able to access such objects during config evaluation, it is more than a simple fix and ordering issue.
I'll setup a lab to test a suggested change for Director (https://github.com/Icinga/icingaweb2-module-director/issues/1579#issuecomment-411409780)
Main goal is to find a stable solution, and since this affects Director only, lets close this issue for now.
lazyfrosch
on 8 Aug 2018
I'll not tell my opinion here as it's not authoritative at all (and IMO there are already too many of opinions here). But here is a quote of someone who's opinion is definitively the most authoritative of all of us:
Even if you say "I don't have time [for evaluating the new Icinga 2 architecture with apply rules etc.]", please do it anyway.
If you just convert your Icinga 1 config 1:1 you could stay at Icinga 1 the same way.
– Bernd Erk, NETWAYS CEO (at the OSMC, translated into German by me; sorry Bernd if I don't remember quite right)
Al2Klimov
on 8 Aug 2018
@Al2Klimov: sorry, you're completely missing the point
Thomas-Gelf
on 8 Aug 2018
@Al2Klimov: thumbs down? I prefer to trust raw numbers rather than random rumor. Putting focus on the real issue instead of throwing in off-topic distraction is really appreciated.
Thomas-Gelf
on 13 Aug 2018
The issue is closed, but never know, maybe what I found can help other.
I noticed that random behavior while playing with static conf.
That issue #3825 lead me to trying some ssh command proxy.
But, as stated in that issue, it is resolved by using return macro.
root@icinga2:/# icinga2 -V
icinga2 - The Icinga 2 network monitoring daemon (version: r2.10.1-1)
Here is 2 checkcommand object that work over check_by_ssh
object CheckCommand "ssh_apt" {
import "by_ssh"
vars += get_check_command("apt").vars
vars.by_ssh_command = get_check_command("apt").command
vars.by_ssh_arguments = get_check_command("apt").arguments
}
object CheckCommand "ssh_load" {
import "by_ssh"
vars += get_check_command("load").vars
vars.by_ssh_command = get_check_command("load").command
vars.by_ssh_arguments = get_check_command("load").arguments
}
For some reason, sometimes, get_check_command("item").key return nullvalue.
Object 'ssh_load' of type 'CheckCommand':
% declared in '/etc/icinga2/conf.d/commands.d/ssh_apt.conf', lines 16:1-16:30
* __name = "ssh_load"
* arguments
[…]
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 20:1-20:36
* timeout = 60
* type = "CheckCommand"
* vars
% = modified in '/etc/icinga2/conf.d/commands.d/ssh_apt.conf', lines 19:3-19:40
* by_ssh_address = "$check_address$"
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 2226:2-2226:40
* by_ssh_arguments = null
% = modified in '/etc/icinga2/conf.d/commands.d/ssh_apt.conf', lines 21:3-21:61
* by_ssh_command = null
% = modified in '/etc/icinga2/conf.d/commands.d/ssh_apt.conf', lines 20:3-20:57
* by_ssh_quiet = false
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 2227:2-2227:26
* check_address
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 21:2-30:3
* arguments = [ ]
* deprecated = false
* name = "<anonymous>"
* side_effect_free = false
* type = "Function"
* check_ipv4 = "$by_ssh_ipv4$"
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 32:2-32:24
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 2228:2-2228:34
* check_ipv6 = "$by_ssh_ipv6$"
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 33:2-33:24
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 2229:2-2229:34
* zone = ""
Object 'ssh_apt' of type 'CheckCommand':
% declared in '/etc/icinga2/conf.d/commands.d/ssh_apt.conf', lines 8:1-8:29
* __name = "ssh_apt"
* arguments
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 2161:2-2224:2
[…]
* command = [ "/usr/lib/nagios/plugins/check_by_ssh" ]
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 2159:2-2159:42
* env = null
* execute
% = modified in 'methods-itl.conf', lines 36:3-36:23
% = modified in 'methods-itl.conf', lines 36:3-36:23
* arguments = [ "checkable", "cr", "resolvedMacros", "useResolvedMacros" ]
* deprecated = false
* name = "Internal#PluginCheck"
* side_effect_free = false
* type = "Function"
* name = "ssh_apt"
[…]
* templates = [ "ssh_apt", "plugin-check-command", "by_ssh", "plugin-check-command", "ipv4-or-ipv6" ]
% = modified in '/etc/icinga2/conf.d/commands.d/ssh_apt.conf', lines 8:1-8:29
% = modified in 'methods-itl.conf', lines 35:2-35:94
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 2156:1-2156:28
% = modified in 'methods-itl.conf', lines 35:2-35:94
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 20:1-20:36
* timeout = 60
* type = "CheckCommand"
* vars
% = modified in '/etc/icinga2/conf.d/commands.d/ssh_apt.conf', lines 11:3-11:39
* by_ssh_address = "$check_address$"
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 2226:2-2226:40
* by_ssh_arguments
% = modified in '/etc/icinga2/conf.d/commands.d/ssh_apt.conf', lines 13:3-13:60
* --critical
* description = "If the full package information of any of the upgradable packages match this REGEXP, the plugin will return CRITICAL status. Can be specified multiple times."
* value = "$apt_critical$"
* --dist-upgrade
* description = "Perform a dist-upgrade instead of normal upgrade. Like with -U OPTS can be provided to override the default options."
* value = "$apt_dist_upgrade$"
* --exclude
* description = "Exclude packages matching REGEXP from the list of packages that would otherwise be included. Can be specified multiple times."
* value = "$apt_exclude$"
* by_ssh_command = [ "/usr/lib/nagios/plugins/check_apt" ]
% = modified in '/etc/icinga2/conf.d/commands.d/ssh_apt.conf', lines 12:3-12:56
* by_ssh_quiet = false
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 2227:2-2227:26
* check_address
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 21:2-30:3
* arguments = [ ]
* deprecated = false
* name = "<anonymous>"
* side_effect_free = false
* type = "Function"
* check_ipv4 = "$by_ssh_ipv4$"
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 32:2-32:24
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 2228:2-2228:34
* check_ipv6 = "$by_ssh_ipv6$"
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 33:2-33:24
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 2229:2-2229:34
* zone = ""
For some reason, after a lot of reload, ssh_apt is loaded 50% of the time, while ssh_load does not.
Here is, after 2 restart of the config:
root@icinga2:/# service icinga2 restart
[ ok ] checking Icinga2 configuration.
[....] Restarting icinga2 monitoring daemon: icinga2[2018-10-28 22:33:07 +0000] information/cli: Icinga application loader (version: r2.10.1-1)
[2018-10-28 22:33:07 +0000] information/cli: Loading configuration file(s).
[2018-10-28 22:33:07 +0000] information/ConfigItem: Committing config item(s).
[2018-10-28 22:33:07 +0000] information/ApiListener: My API identity: icinga2
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 1 ScheduledDowntime.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 49 Services.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 1 LivestatusListener.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 1 IcingaApplication.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 12 Hosts.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 1 FileLogger.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 2 NotificationCommands.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 10 Notifications.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 1 NotificationComponent.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 2 HostGroups.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 1 ApiListener.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 2 Downtimes.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 1 GraphiteWriter.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 1 CheckerComponent.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 3 Zones.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 1 ExternalCommandListener.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 1 Endpoint.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 2 ApiUsers.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 1 CompatLogger.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 1 User.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 1 IdoMysqlConnection.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 220 CheckCommands.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 1 UserGroup.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 3 ServiceGroups.
[2018-10-28 22:33:07 +0000] information/ConfigItem: Instantiated 3 TimePeriods.
[2018-10-28 22:33:08 +0000] information/ScriptGlobal: Dumping variables to file '/var/cache/icinga2/icinga2.vars'
[2018-10-28 22:33:08 +0000] information/ConfigObject: Restoring program state from file '/var/lib/icinga2/icinga2.state'
[2018-10-28 22:33:08 +0000] information/ConfigObject: Restored 323 objects. Loaded 0 new objects without state.
[2018-10-28 22:33:08 +0000] information/ConfigItem: Triggering Start signal for config items
[2018-10-28 22:33:08 +0000] information/FileLogger: 'main-log' started.
[2018-10-28 22:33:08 +0000] information/ApiListener: 'api' started.
[2018-10-28 22:33:08 +0000] information/ApiListener: Copying 1 zone configuration files for zone 'director-global' to '/var/lib/icinga2/api/zones/director-global'.
[2018-10-28 22:33:08 +0000] information/ApiListener: Applying configuration file update for path '/var/lib/icinga2/api/zones/director-global' (0 Bytes). Received timestamp '2018-10-28 22:33:08 +0000' (1540765988.
064565), Current timestamp '2018-10-28 22:32:34 +0000' (1540765954.294276).
[2018-10-28 22:33:08 +0000] information/ApiListener: Started new listener on '[0.0.0.0]:5665'
[2018-10-28 22:33:08 +0000] information/ExternalCommandListener: 'command' started.
[2018-10-28 22:33:08 +0000] information/GraphiteWriter: 'graphite' started.
[2018-10-28 22:33:08 +0000] information/LivestatusListener: 'livestatus' started.
[2018-10-28 22:33:08 +0000] information/LivestatusListener: Created UNIX socket in '/run/icinga2/cmd/livestatus'.
[2018-10-28 22:33:08 +0000] information/CheckerComponent: 'checker' started.
[2018-10-28 22:33:08 +0000] information/NotificationComponent: 'notification' started.
[2018-10-28 22:33:08 +0000] information/DbConnection: 'ido-mysql' started.
[2018-10-28 22:33:08 +0000] information/CompatLogger: 'compatlog' started.
[2018-10-28 22:33:08 +0000] warning/CompatLogger: The CompatLogger feature is DEPRECATED and will be removed in Icinga v2.11.
Context:
(0) Activating object 'compatlog' of type 'CompatLogger'
[2018-10-28 22:33:08 +0000] information/ConfigItem: Activated all objects.
[2018-10-28 22:33:08 +0000] information/cli: Closing console log.
. ok
root@icinga2:/# icinga2 object list --type checkcommand --name ssh_load
Object 'ssh_load' of type 'CheckCommand':
% declared in '/etc/icinga2/conf.d/commands.d/ssh_apt.conf', lines 16:1-16:30
* __name = "ssh_load"
* arguments
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 2161:2-2224:2
* vars
% = modified in '/etc/icinga2/conf.d/commands.d/ssh_apt.conf', lines 19:3-19:40
* by_ssh_address = "$check_address$"
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 2226:2-2226:40
* by_ssh_arguments = null
% = modified in '/etc/icinga2/conf.d/commands.d/ssh_apt.conf', lines 21:3-21:61
* by_ssh_command = null
root@icinga2:/# icinga2 object list --type checkcommand --name ssh_apt
Object 'ssh_apt' of type 'CheckCommand':
% declared in '/etc/icinga2/conf.d/commands.d/ssh_apt.conf', lines 8:1-8:29
* __name = "ssh_apt"
* arguments
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 2161:2-2224:2
* vars
% = modified in '/etc/icinga2/conf.d/commands.d/ssh_apt.conf', lines 11:3-11:39
* by_ssh_address = "$check_address$"
% = modified in '/usr/share/icinga2/include/command-plugins.conf', lines 2226:2-2226:40
* by_ssh_arguments = null
% = modified in '/etc/icinga2/conf.d/commands.d/ssh_apt.conf', lines 13:3-13:60
* by_ssh_command = null
But, with return, the issue is fixed:
object CheckCommand "ssh_apt" {
import "by_ssh"
vars += get_check_command("apt").vars
vars.by_ssh_command = {{ return get_check_command("apt").command }}
vars.by_ssh_arguments = {{ return get_check_command("apt").arguments }}
}
object CheckCommand "ssh_load" {
import "by_ssh"
vars += get_check_command("load").vars
vars.by_ssh_command = {{ return get_check_command("load").command }}
vars.by_ssh_arguments = {{ return get_check_command("load").arguments }}
}
Tr4sK
on 28 Oct 2018
Related issues
mickenordin
·
5Comments
peteeckel
·
4Comments
ak2766
·
7Comments
ghost
·
4Comments
seventh-chord
·
5Comments
Most helpful comment
I followed the philosophy of @dnsmichi of using apply rules and converted all Service Sets to Service Apply Rules. This worked as a charm and all the overrides are handled correctly now. So this resolves the override issue for me, but the question still remains what the purpose is of Service Sets and how they are handled. As far as I understand from Michael Friedrich that apply rules should be the way to go and this makes Service Sets an unsupported feature and should be deprecated for that reason? Or am I missing here something?