Sync rule of Services

Icinga Web Modules Icinga Director
1

Hi,

I’ struggling with importing services from a rest api call. The actual import is of course working fine. There is only three columns: name, color, url. In the sync rule I have chosen object type service. And the sync property mapping is set to name -> object_name, url -> notes_url, color -> vars.color.

I understand that I need to relate these services to a host (or hosts), but I don’t understand how to do that. There is two hosts I want to add these services to.

The error I get is: Exception while syncing Icinga\Module\Director\Objects\IcingaService batch-: Cannot store a Service object without a related host

2

Okay, I found a way to “hard code” the host property by making one sync rule per host to create all services on. And then set the Source Column to Custom expression and enter the hostname as a variable. Is this the only way to do this? Can I set several hosts in one sync rule for example? With like an apply rule where I wildcard the hostname?

3

Yes, you can. You have to define the object_type as apply and the assign_filter like described in https://github.com/Icinga/icingaweb2-module-director/pull/1304/files

1 Like
4

Thank you for the reply!

Okay, this got really messy. Since service apply rules are duplicated I destroyed my whole Director config by adding over 2000 apply rules that was wrong. :smiley: Luckily I was in test! When I finally got it working (by filtering out all but one object) it got duplicated each sync.

In contrast to the documentation I had to format the filter as “host.vars.os=%22Linux%2A%22” not as suggested “host.vars.os = Linux*”. But the issue sustained, every time I synced a new apply rule was added and stopped deployment since the host already had an object.

Is this solvable?

5

apply_filter
apply_filter837×294 10.6 KB

This Sync Rule resulted in:

apply Service "batch-dummy" { 
	   import "passive-check-template" 
	 
	   notes_url = "http://cron-master.domain.com/jenkins/job/batch-dummy/" 
	   assign where match("service-cron-slave*", host.name) 
	   vars.color = "blue" 
	 
	   import DirectorOverrideTemplate 
	}

But as I wrote, every time I run the sync rule another object is created and deployment fails due to duplicate entry

6

So typically I see a failure when director is trying to recreate an object and not a duplication, but in most cases this is caused by having a different primary key in the import rule than the object_name in the sync rule. Could this be the case? Because this is the only idea I have at the moment.

7

I think there’s something special with Service Apply Rules in Icinga2. From the Rest API documentation (that I used to build a script to remove the over 2000 objects that was wrongfully created):

Service Apply Rules

Please note that Service Apply Rule names are not unique in Icinga 2. They are not real objects, they are creating other objects in a loop. This makes it impossible to distinct them by name. Therefore, a dedicated REST API endpoint director/serviceapplyrules ships all Service Apply Rules combined with their internal ID. This ID can then be used to modify or delete a Rule via director/service .

Source: https://icinga.com/docs/director/latest/doc/70-REST-API/

8

Another approach would be to create a serviceset and then sync the services to it. This is what I did at some customers.

1 Like
9

Brilliant! That worked like a charm! Thanks @dgoetz!