Dynamic Service Naming

Hello all
I’m new to Icinga and I’d like to know if it is possible to have service checks named based on variables because I don’t know how to do it. For example:
https://icinga.com/docs/director/latest/doc/15-Service-apply-for-example/

Here a host would have a number of “tcp_ports” defined and the service apply rule would generate a service for each of them “TCP check”. But what I’d like to have is singular names for them.

  • 3000 - Service A
  • 4000 -. Service AB ZX
  • 5000 - Service UWH

From my searches I have seen this topic

But I understand it would generate something like “TCP Check 3000” and not “Service A”. How can I match the ports number with a name and have this name used by the Apply rule?

If I come across as uninformed or confused probably I am :pensive:

1 Like

If I understand correctly you want “both parts” of the service name to be dynamically filled.
<Port> - <Service name of the port>

This example from the docs looks like it could be what you are looking for:
https://icinga.com/docs/icinga2/latest/doc/03-monitoring-basics/#use-object-attributes-in-apply-rules

But I don’t know if this is possible with the Icinga Director.

Hi @log1c and thanks for your reply. I can live with part of the name being static and part being dynamic. To put my real world case I’m checking for different FlexLM ports so I want the services to be named in the form “FlexLM” + “Vendor”:
So if the rule iterates for ports 27000, 28000, 30000 on a server I’d like to get something like:
“FlexLM AutoDesk”
“FlexLM Mathworks”
“FlexLM Siemens NX”

Right now I either have to conform with all checks being named “FlexLM” wich doesn’t help or what I am doing as a stopgap. Assign services directly to the host so I can enter a descriptive name.

I’ll study your link but I have no experience configuring Icinga outside Director.

Hi,

this should be possible with the Director. I’ve used this functionality in the documentation for the x509 module. (https://icinga.com/docs/certificate-monitoring/latest/doc/10-Monitoring/#multiple-services)

There, service names are enriched with a macro that is fed by the Apply For setting in a service apply rule. Try to play with that, it should support any sequence like variable. If the values that are iterated over are objects, you should also be able to access them as usual with the dot notation.

That is not possible with the director (as far as i know) because the director has no dictionary support. Only ideas i have is using the api and create single services.by a query or use a importsource for it.

EDIT: I think that only $config$ is allowed in the director as variable, because Director autoquotes others. We need a “skip quoting” switch for that. But maybe that was changed some time ago.

Thanks for your replies, dictionary should be the key but as pointed out it is not a supported data type in Director.
@nilmerg I believe this would create services like: “FlexLM 27000”, “FlexLM 28000”… using the port number as part of the name but I need something more human friendly :smiley:
@log1c answer seems to be the closest but it has to be done directly in Icinga because it relies on a dictionary.
I am not sure how to go about mixing file-based configuration with Director configuration but everything seems to indicate that what I wanted to do is not really feasible with Director.

As conf file something like

apply Service "flexlm_ports_" for (port in host.vars.flexlmports) {
   check_command = "..."

   var temp = port.split("@")

   vars.flexlm_port = temp[0]
   display_name = "FlexLM " + temp[1]
}

would work, having flexlmports as an array e.g.:

[ “Service A@3000”, “Service AB ZX@4000”, “Service UWH@5000” ]

But as I’m not using director for services, I’m not able to transform this conf file into director (but maybe someone else here).

2 Likes

It is not recommended but can be done.
Simply include the .conf file in your /etc/icinga2/icinga2.conf with an include statement.
You can’t see/modify these services in the Director though (obviously).

Have done so in the past when the Director did not offer the option to implement scheduled downtimes.