Hi,
we have to check databases, where more then one instance is running on one host. Basic idea was as follows:
create service template for each check
create host template “db_checks” and assign check templates
create host template “<DB_SID>” which contains the value of “db_sid” + any instance specific variables and inherits the service checks from “db_checks” template
assign host template “<DB_SID>” to host, where DB is running
if there is more then one instance running, assign further “<DB_SID>” templates to this host
This works well for a single instance per host. If I have two instances, the checks will show up only once in Icinga2, because they have the same names. Solution: Use an apply rule “<check_name> $config$”, and assign the checks where “<db_sid>” is set (which is true for host template “<DB_SID>”. Now we see a check for each service called “<check_name> <DB_SID>” and the template “db_checks” is not needed anymore in this configuration, because the rule is assigning the checks to template “<DB_SID>” directly.
Problem: If I assign a variable “connect_string” to a <DB_SID> template “DB1” and the same variable to template “DB2” with a different value (because we need a different connect string there), the assignment of the value to the Instance name is getting lost during inheritance (not a code problem, but conceptual error by ourself). Both checks will use the value assigned to the template that is last in the inheritance list, so one connect will fail.
I assume it is not possible to use a dynamic variable name in the command definition like "connect_string = “connect_string_$db_sid$”? Is there another elegant way to solve this? Please keep in mind, that there might be quite a lot of adaptions/variables per database instance, so an array [ <db_sid> , <connect_string> ] is not what I’m looking for. I need to fill the same variables (command options) dedicated to specific <db_sid> values, so they can coexist on one host.
This should work.
I use something similar for the snmp_community for the nwc_health command.
The field $snmp_community$ is assigned to the host template and filled there. The service check then has the field $nwc_health_communit$ = $snmp_community$
Also doing this for setting a notification_from address for specific hosts like so:
Field $notification_from$ added to a host template and then is filled by $notification_from$ = $host.groupname$@domain.de
Hi log1c,
thanks a lot. I agree, this should work, but it would require to define a lot of data fields:
connect_string_<SID_1>
connect_string_<SID_2>
connect_string_<SID_3>
…
And the same for every command option I want to set, so this would generate an excessive list of data fields (we run more then 10 checks per instance and most checks have more then 5 command options, so = 50 * <instance_count>).
That’s not an optimal solution. I’d like to use the same field name (lets say “<connect_string>” again), define it anywhere together with the <DB_SID>, so it will be bound to it. This works for a single instance per host, if I do it inside a host template, but not anymore if I assign a second host template (instance) to the same host, because the variables will be overwritten by the last imported template.
Hi again,
sorry, I didn’t read your response carefully enough. You stated “the SERVICE CHECK has the field…” and that’s indeed the solution because we have distinct check names. My thoughts were still bound to host templates…
There is only one thing left. I have to set all common instance parameters for every check:
check1.connect_string=…
check2.connect_string=…
…
Would be nice to be able to set common variables, that effect every service check of a specific instance only once.
If there is a possibility, please let me know, but my main problem is solved.
Hi,
sorry again, but after checking this, I found it is not working as expected. Because I assign the service templates via apply rule, I can’t configure them independently for each instance (or each $config$ item), because the check is only shown as “<service_name> $config$” in the service section of the target host. So I cannot set a different value per instance. And even if I overwrite the value manually there, it is still overwritten by the last imported host template.
@log1c: Your solution is working, if you don’t assign 2 host templates to the same host with different settings for “$snmp_community$” (or “$host.groupname$”).
Any other solutions please?
Thank you.
Regards,
Dirk
Hi log1c,
sorry, was bound by other stuff for a while. Lets check the inheritance problem.
Create a new command:
Create 2 host templates and assgin each one a value for “db_adm”:
Create an apply rule:
Now lets change the import order:
So we have proof now, that the templates overwrite each other and the last in list wins. We can apply the same test twice to the same host, if we set the values of “db_adm” inside the host (or inside a host template), using the array:
But now comes the tricky part: How to assign other variables that should affect only one instance? Lets say it is a password and my check is called like
“testservice -p $password$ [here might be several other instance and service specific parameters]”
I could define the command to use “password_$DB_ADM$”, but in this case I have to define the data fields “password_ADM1” and “password_ADM2”, before I can use them and assign values. If I have 50 instances, each running 10 checks and each check knows 10 parameters, I have to define 5000 data fields.
How would you solve this?
Thanks a lot for your time and ideas
(If you should have troubles with quoting: I was not allowed to upload more then 5 pictures, so I had to consolidate a bit).
Regards,
Dirk
I’m still not 100% sure if I got it correctly, but I`ll here’s what I think:
Wouldn’t it be possible to define each instance as its own host object?
This way you could define just one generic instance template that hold the needed check parameters and you can fill them on a per host (instance) basis.
That is the only way I can think of right now
Maybe someone else has some more input, maybe the Icinga DSL would be something that comes into play here.
Hi log1c,
marked your answer as solution, thanks a lot. I build it as suggested for one server with two instances and received errors, that my new hostname is not known (I assume this comes from agent, didn’t investigate any further so far, maybe this can even be solved), but I can run the tests via ssh for the additional hostname at least, so this is a way I can go.
(or not 
)
