Identifying Services by UID via API?

Icinga 2
,
1

Hi!

Following Problem:
We have lots of Pipelines which set the downtime for a service by API. As Service-Identifier we take the “__name” variable. The Problem raises when someone modifies the Service-Object, specifically the name, without knowing that there are pipelines using this identifier to set downtimes in Icinga.

So my question is:

  • Is there a better way to identify a Service by some UID which never changes? In this case we wouldnt have to adapt our buisness process…:slight_smile:
  • Wouldn’t that make sense to assign each Service an UID or why not? High costs or would it bring other disadvantages?
  • Could I introduce a new field which increases by 1 for each Service or the like?

Another advantage? would be that if a 3rd Party Company manages the Pipelines they wouldnt have to know what lies behind the Service even though if someone sets downtimes he should know what service he sets down :thinking: Sort of obfuscating the service and decouple the service information from the Service.

The API-Command
curl -ksSfi -m 10 -u $USER:$TOKEN -H ‘Accept: application/json’ \
-X POST ‘https://monitoring.example.net:5665/v1/actions/schedule-downtime’ \
-d ‘{ “type”: “Service”, “filter”: "’“$finalString”‘", “start_time”: "’“$startDate”‘", “end_time”: "’“$endDate”‘", “author”: “Jenkins”, “comment”: “${JOB_URL}”, “pretty”: true }’

2

Thanks for posting.

In general, the object name accessible via __name is the unique name Icinga 2 uses to identify objects. Thus, it is not advisable to alter the name of an object, but rather to recreate them.

FTR: Icinga DB identifies objects via hashes, but these are built using a hash function on the $hostname!$servicename string and additional data. Changing an object name would thereby result in another hash.

Since there is currently no real technical reason to change this in Icinga 2 - and this would be a huge change -, I would advise you to reconsider your workflow. Maybe you can store the changing information in custom variables?

IMO, this would only introduce confusions. If you really need to cloak your Icinga from an external partner who should be able to create downtimes - not knowing what they are creating them for -, I would suggest writing some small middleware to map some ID to an Icinga 2 object. Or use custom vars. Use more custom vars :slight_smile:

Please feel free to describe what you are doing and perhaps we can find another way to get it done.

3

Thank you for the clarification and thoughts!

Would it be a valid way to introduce a custom_field as soon as a service-downtime must be set via API? The downtime is then identified by this custom field instead of the __name field. This change in the workflow would avoid this problem.

The problem I have is that one person creates the service. Later on a second person writes a Pipeline which sets some service-downtimes. 1 year later another person changes the names of the service for whatever reason and of course does not know that a corresponding pipeline exists binding to these __name fields.

May be it would be easier to adapt the workflow but I prefer a technical solution, if possible.