Icinga / icinga2

The core of our monitoring platform with a powerful configuration language and REST API.
https://icinga.com/docs/icinga2/latest
GNU General Public License v2.0
2k stars 574 forks source link

Can't use original_attributes in apply Service #10138

Closed sottolski closed 1 month ago

sottolski commented 1 month ago

We manipulate the "display_name" of our host objects via api. However, when calling NRPE, we want to use the original value of the display name. According to the documentation, the dictionary original_attributes would hold that value. However, it doesn't seem to work how I try to use it

apply Service "mysql_version" { import "generic-service"

assign where "sng-dsa-db-nbg1" in host.groups

check_command = "nrpe" vars.nrpe_command = "check_mysqlversion$host.original_attributes[\"display_name\"]$" }

I tried all variations of

original_attributes[display_name] original_attributes['display_name'] original_attributes[\"display_name\"]

to no avail. I get no error, but nrpe is called without the "-c" parameter, so I suppose the expression evaluates to null.

But when getting the host objects via API, the original_attributes dict is there, and has the former display_name in it. So either the syntax is somehow wrong, or the config somehow doesn't have access to that dictionary.

Our version is a bit behind, r2.13.7-1

julianbrost commented 1 month ago

If anything works in the macro string syntax, that would be $host.original_attributes.display_name$ (otherwise, you'd have to resort to use a lambda function to access that attribute there).

However, I don't really understand what you're trying to achieve and this sounds quite strange. Why aren't you simply leaving the display name unset in the config (i.e. the object name will be used), write the value you care about into a proper custom variable to use in your check, and then only set the display name using the API?

sottolski commented 1 month ago

thanks a lot @julianbrost , that works, so it was only a question of syntax. Regarding the "why", of course you are right. However, it's currently setup that way, and why refactor if it a simpler solution is at hand :-)