Notifications.conf - service notifications based on host variable

This forum was archived to /woltlab and is now in read-only mode.
  • HI

    Can someone please confirm if this config in notifications.conf is valid?

    For a bit of background... some of our hosts have a custom variable which contains the number of live customers using that host.

    If someone has not set the notification period for a service it needs to look at the host to see if it has live customers or not, then it decides if it needs to be a 24x7 alert.


  • I am not sure that this will work.


    Config files will be evaluated at startup and that's it.

    What you are trying to do with your variable seems to be a runtime update and thus

    i fear it will not work.

  • I don't know if it helps but we currently have almost exactly the same code set for the host config.
    but instead of service.vars.notification.period we obviously have host.vars.notification.period and it has been working

  • The syntax is not entirely correct. You cannot for example return something from an if condition. But that's fine, easy to fix.


    I guess host.vars.live_customers is just a number since you're checking for equal to 0? If it would be an array containing some string elements, you might want to call host.vars.live_customers.len() == 0 then.


    Since you have both object scopes inside a notification apply rule (host, service), you could rewrite your code to the following - untested as always:



    As said, I am not sure about the type of host.vars.live_customers - a host object example would help here in refining your conditions and code.


    sru

    Just a note for your understanding - you can access specific scopes inside apply rules, as you are doing with assign where expressions. The notification apply rules (not the object declartion!) allow for "host" and "service", and you are correct, only the configuration attributes. You cannot access runtime attributes such as state or last_check_result during startup (they simply do not exist at this stage).


    There is a limited set of locations where we can allow runtime calculation for attributes. That's happening with defining a function as a value, as you know from the abbreviated lamdba syntax {{ return 0 }} (you can also omit the "return" keyword, the last value is automatically returned).

    It is only allowed for custom attributes (which can be referenced via runtime macro somewhere else in command arguments), set_if and value inside command arguments.

    The downside of the story - there is no direct handler for runtime calculated values for custom attributes. Inside Icinga 2 it is a compiled function, but there is no real value available in DB IDO for example. If you are considering a DB update each time such a function is evaluated (at command execution), this slows down everything. Things get complex and are not working, if such values are exchanged between cluster nodes.


    So the simplest approach here are config compile time conditions. If you have sorts of multiple apply rules which re-use the same algorithm over and over, you can also avoid code duplication by creating a global function (i.e. in constants.conf, or create a new include which is imported before all objects.



    and simply call that inside your notification apply rule(s).


    Code
    1. calc_live_customers_notification_period(host, service)


    This could certainly be extended for users and user groups too, but that's too much for now ;)

  • Thanks for that dnsmichi


    I've tested it and it seems to work, just in case it helps anyone else in the future here is my full code to set service notifications