icingaweb2-module-director
icingaweb2-module-director copied to clipboard
Apply for service override not working
I'm trying to override a service variable in the host to set a threshold for each partition.
The generated override only matches the Name of the Apply Rule - not the individual generated services of the apply rule - as you can't select the generated service I guess overriding apply for services isn't possible (yet)?
object Host "BAPM0" {
import "OurLinuxHost"
address = "172.31.15.43"
groups = [ "linux", "sysE" ]
vars.disks = [ "/home" ]
vars._override_servicevars = {
"Disk Mountpoint " = {
disk_crit = "5%"
}
}
}
Service Template + Apply For
template Service "Disk Mountpoint" {
import "[Template] ssh-service (active)"
vars.by_ssh_command = "~/libexec/check_disk.lin -w $disk_warn$ -c $disk_crit$ -p $disk$"
vars.disk_crit = "10%"
vars.disk_warn = "15%"
}
apply Service "Disk Mountpoint " for (config in host.vars.disks) {
import "Disk Mountpoint"
assign where "linux" in host.groups && host.name == "BAPM0"
vars.disk = config
import DirectorOverrideTemplate
}
Cool would be to have the possibilty to create an override like this
vars._override_servicevars = {
"Disk Mountpoint /home" = {
disk_crit = "5%"
}
}
I couldn't find any open bugreport regarding this.
Reasonable feature request. Makes sense to me and could be implemented. Regardless of this, wouldn't it be easier to just add single disk services to your hosts?
What do you mean by single disk services? The number of partitions varies from host to host so how can I create them automatically? Any example?
Before we had one disk service per host which itself fetched all partitions and created a summary - this led to the service being acknowledged because the enlargement of the partition was already requested - and another one ran full unnoticed in the meantime.
This starts to be interesting... Got the same Problem with Urls: The http_check sould be attached to hosts with a filled variable "URLS". These contain an array of URLs like this Url1=site1 port 1 Url2=site2 port 2 ... I managed to get the check beeing attached with each URL to the server but no chance to tell director diffenent ports. Finally solved this one with a wrapper script which filled the variables out of one string: url1=seite1:8080 url2=seite2:443 ... simply dividing the string at the (second(!)) ":" # http:.... bla.bal:443 | using a ":" wasn´t so clever...
Works but not as nice as it could be...
@friesoft: your apply for
is creating single disk services in a loop for all partitions defined via "Edit host" -> "Add a partition name entry to the 'disks' property". Clicking "Add service", choosing the "Disk" template, enter the partition name.
This involves one additional step for the user, but makes it easier to understand. You no longer have to define the partition name in one place and the threshold in another one. I could imagine giving even more guidance to this, getting rid of that additional step. This would involve marking the Disk
service template as a "Multi-instance"-Service and could result in a simple "Add Disk" link for the user directly on the host.
I'd like to implement the requested feature anyways, just trying to figure out whether this is really what we should teach people to us or whether there might be better work-flows, easier to understand and involving less abstraction.
Hm.. all our disks are synced from our CMDB into the host as property. So this would mean instead of having one service template with "Apply for" to create a service for each disk inheriting a disk template at import/sync time. Correct?
At the moment we aren't creating services automatically as there where problems in the past with Services not being cleaned up if deleted from the CMDB.
What I like about the "Apply for" solution is that you have all your services in one place and in most cases my colleagues think about "I have to edit the threshold of this service" --> so they will go to the service section - Not finding the appropriate service if synced. But that is maybe just something to educate them..
Syncing single services to hosts should work fine since at least v1.2.0, purge/cleanup also. Should also work fine when using multiple import sources - in case it doesn't please let me know. There is also a "hidden" feature allowing you to set use_override_vars
on sync, try to figure out what it does ;-)
"All your services in one place"... well, we seem to have the same objective.
So to bring this back as a "Reasonable feature request" I have the same problem with a bigger real world example. I have multiple checks for Oracle and SAP which get applied depending on an array of TNS names and SAP system numbers ranging from one to many on a system. There is no import source providing this information here. 😢 Now some checks only on one instance of the software on one specific system require adjusted thresholds as company wide default does not match.
Any news on this one? We just stumbled upon this again :)
@Thomas-Gelf Is this feature request still considered or worked on ?
I'm currently testing Icinga2 with the director to migrate from our old and trusty (rusty?) Nagios and I stumbled on the same problem as @friesoft
Essentially, the idea was was to mimic the default configuration shipped with icinga2 packages, these parts in particular:
object Host NodeName {
/* Import the default host template defined in `templates.conf`. */
import "generic-host"
...
/* Define disks and attributes for service apply rules in `services.conf`. */
vars.disks["disk"] = {
/* No parameters. */
}
vars.disks["disk /"] = {
disk_partitions = "/"
}
apply Service for (disk => config in host.vars.disks) {
import "generic-service"
check_command = "disk"
vars += config
}
Here, the applied service has all his variables correctly overridden by those defined in the host's disks dictionaries.
In the current iteration, variables for services assigned with "Apply for" rules cannot be overridden in the Host > Services tab. The service doesn't even appear in some cases, see #1387.
I think this feature is a must have as it makes the workflow really clean once the services templates and apply rules are in place. Then, you just have to define any specificity in the host itself.
This works great for disk partitions monitoring, http hosts monitoring and so on.
Relates to #1368
Also would really like this feature :) would help with complex scenarios
Our workaround currently is really ugly but it works...
select id from icinga_host where object_name = "<HOST_NAME>";
if there already is an override set:
select varvalue from icinga_host_var where host_id=<id> and varname='_override_servicevars';
update icinga_host_var set varvalue='<JSON Object>' where host_id=<id> and varname = '_override_servicevars';
if there is no override yet:
insert into icinga_host_var (host_id, varname, varvalue, format) values (<id>, '_override_servicevars', '<JSON Object>', 'json');
The JSON Object can be modified manually to contain the correct servicenames or additional ones (e.g. for services which are added using manual icinga config)
We would also need this feature for host.vars.http_vhosts used in apply rule. We offen have to override specific vars for the created http services.
it would be sooo great to have this working (https://community.icinga.com/t/override-vars-not-working-for-service-applies/429/9)
let's give it an update for this feature-request, hopefully next year! :)