In summary, I want to enable icinga2 to query the vm object from the vSphereDB module.
Someone have already provided an answer to this problem,
however I don’t think I could find this variable: host.vars.custom_values.icinga_director_teams
as suggested from this post when he tries to import a “DirectorOverrideTemplate”
your check commands looks weird. what’s in the argument section?
take any other check command as reference.
the command is the binary / script /whatever.
all arguments go to the argument section with an argument and a value.
the value can be something like $host.name$, or $check_blabla_value$
these values can be added to the field section of the check.
I tried to take any other command as reference.
The command is in the first snapshot, the arguments and values in the third one.
The field section is the second snapshot.
There is also the Service template attached.
My aim is to trigger my notifications that I also attached to the service and host objects.
first screenshot shows arguments in the command line and some strange ${host
second screenshot shows fields
third screenshot shows 2 arguments with the corresponding fields, which looks ok
I lost track, but there is a screenshot with check type = $host.name$ and object name = vm, which looks weird too
zones.d/director-global/commands.conf
object CheckCommand "116-cmd-check-icingacli-vspheredb" {
import "plugin-check-command"
command = [ "/usr/bin/icingacli", "vspheredb", "check" ]
arguments += {
"--name" = {
description = "name of object to check - only needed if check_type is singular"
order = 1
required = false
value = "$116_check_icingacli_vspheredb_name$"
}
check_type = {
description = "Type of check to perform"
order = 0
required = true
skip_key = true
value = "$116_check_icingacli_vspheredb_type$"
}
}
}
To bind the imported hosts together with the check, a service is used:
zones.d/master/service_templates.conf
template Service "116-tpl-service-vspheredb-vm" {
import "tpl-service-generic"
check_command = "116-cmd-check-icingacli-vspheredb"
max_check_attempts = "3"
check_interval = 1m
retry_interval = 15s
command_endpoint = null
vars["116_check_icingacli_vspheredb_name"] = "$host.name$"
vars["116_check_icingacli_vspheredb_type"] = "vm"
}
zones.d/master/servicesets.conf
/**
* Service Set: 116 vSphereDB VM
*
* assign where host.vars.custom_values.icinga_director_teams || "vspheredb-vm" in host.vars.custom_tags
*/
apply Service "Icingacli vSphereDB - VM Status" {
import "116-tpl-service-vspheredb-vm"
assign where host.vars.custom_values.icinga_director_teams || "vspheredb-vm" in host.vars.custom_tags
zone = "master"
import DirectorOverrideTemplate
}
icinga_director_teams is a custom attribute on the VM in the vCenter that I set via the import so it’s certain to be a VM as no other hosts have this and the vspheredb-vm is used to manually declare the host a VM in my setup.
Where I went wrong? As you can see I can’t do anything from the “drop down command” menu (like you did in your first picture @rivad ). No Datastore available for me.
From the image above, I suppose that vm is going to be the vm name.
In addition, is “$host.name$” recognized from the host that uses the service or not? (Do I have to add as a data field in the Icinga Director?)
I’d like to check the VM status from the Icinga dashboard as the final result.
I have no Property Modifiers defined in my Datastore (Icinga Director-> automation-> modifiers) if this might help.
These are the data fields defined inside the Icinga Director:
Have a look at this section on the main director page:
here you can define lists for your fields to make the drop down but be aware, that this is optional and just writing out the valid type also works.
Which host should I attach the service to?
Is it advisable to create custom attributes on the vCenter?
If you can provide an anonymized screenshot I believe it can be easier.
I attached the service that is checking the virtual machine status to the hosts that are VMs.
Maybe it would make sense to have a host for the vCenter and attach check of a global type, like the datastore type, there.
Only you and your vCenter admin can figure out if it makes sense in your environment to put custom attributes on the vCenter to have them available in the import and what to do with them.
A screenshot of what? The custom tags and attributes? Here a screenshot of a old test server of mine, as seen by the Icingaweb2 vSphereDB module:
