icinga2, modify custom attributes with api are not updated in the idodb

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


    I added to every Host object two variables on config level.

    The one custom variable contains an array with parent hosts (host_parents). The second custom variable contains the parent path (host_parent_path). Initial the parent_path is empty. This configuration goes into the IDO-DB.


    To calculate and set the host_parent_path I created a function that calculates the parent path via parentPathRebuild(). To run the function I connect to the daemon via api listener and call the function. The calculation works fine and I could verify that the path is calculated correct.


    In the idodb there is no update of the modified custom attributes.


    Why isn't the modified custom attribute updated in the idodb database?


    The attribute in the database still contains the initial value and not the modified one with the path.


    This is my script for the config dependency: apply.dependency.host.parents.conf

    Code
    1. apply Dependency "HostParent." for (aHost in host.vars.host_parents) to Host {
    2. import "generic-dependency"
    3. parent_host_name = aHost;
    4. disable_checks = false;
    5. assign where host.vars.host_parents;
    6. ignore where match(aHost,"");
    7. }


    and the defined function


  • I'm interested in how you execute that function. That sounds complicated and let's me think of runtime modifications via console (which is for debugging only).

  • Hi,

    pcasis : After reload "kill -HUP" the configuration in this way is gone

    dnsmichi : Yes, the function is called via icinga2 console


    I didn't found the right position in the config definition. There is a feature request https://github.com/Icinga/icinga2/issues/3520 "Allow to modify configuration after all config objects have been created" (from elippmann) that could solve my problem to run the function after the configuration is loaded/created.


    To use it as "Functions as Custom Attributes" would be to expensive, as every access to a variable calls the complex function that is required only once on startup.


    The post was edited 1 time, last by kobmaki: Fix link to github. Tnxs @birkch ().

  • Modifying and persisting changes via debug console is not supported. That explains why your runtime non-sandboxed calls won't update any backends (DB IDO, etc.). The linked issue about modifying configuration after all configs have been loaded would probably solve the requirement (IIRC we talked about that during the OSMC hackathon already). Although it is currently not on any TODO list.

  • What is the alternativ for this problem? Only modify via the api?


    Isn't it strange that modify via console, close the conection, connect again via console and still have the modified values!?


    How could the feature request attend on the TODO list?

  • I'll take a note for the docs explaining what you can do with the console, and what's not supported. Given what users attempt to do and then blame us for it, I'd rather remove it - it is still a debug console only.


    I'm still not certain why you would want to store that inside the Icinga 2 config dsl. If I were you I would take that dependency calculation logic into an external application.


    In terms of features - the usual thing nobody wants to hear. Sponsor us time to actually do it, or find one capable of implementing such. It is not that easy, as adding a config option somewhere. If that would have been the case I would have added it myself in a break (well rather not, breaks are for taking a deep breath).

  • I "found" an alternative way. It works without using the debug console and call the function from the api via a host alive check.


    It was borrowed from the blog entry https://www.icinga.com/2016/06…lation-from-all-services/

    that shows more details for running a function for calculation something.


    Define a host and let the alive-check run the command. In this case I use the host "localhost":

    Code
    1. object Host "localhost" {
    2. import "generic-host"
    3. address = "127.0.0.8"
    4. address6 = "::1"
    5. check_command = "dummy";
    6. vars.dummy_text = {{ return parentPathRebuild(); }}
    7. }

    When the host alive check is trigger via the check_command it call the required function.

    This technic avoids runnings the function via the debug console. The parent path is calculated after the first run of the host alive check on "localhost". The path is correct and could be verified with the console.

    Code
    1. <34> => get_object(Host,"localhost").vars.host_parent_path;
    2. "/"
    3. <35> =>

    When run the following command on the console:

    Code
    1. for (h in get_objects(Host)) { log("Hostpath: "+h.__name+" => "+h.vars.host_parent_path) ; }

    you can see the calculated path in the log file.

    Code
    1. [2017-04-08 15:55:44 +0200] information/config: Hostpath: localhost => /


    This is still not perfekt, as the api shows the correct calculated path but the command line (icinga object list --type=Host) still not shows the calculated path. The same with the ido_db.


  • It works! I recompile it from the latest version.


    icinga2 - The Icinga 2 network monitoring daemon (version: v2.6.3-160-g18005e2)


    Now the ido_db contains the expected values and icingaweb2 shows the expected calculated path!

    The icinga2 version before was v2.6.3-151-g46900ce. Something between this version and v2.6.3-160-g18005e2 has fix my problem.


    After cleanup of my configs, I will add my version for calculation for the parent_path. After this, the thread should be set to resolved.

  • My previous message was not right, as I messed up to many variants to get it work.


    The reason why / how it works is to get the function call during configuration process.


    Code
    1. apply Dependency "ParentPathRebuild" to Host {
    2. ParentPathRebuild();
    3. assign where host.name== NodeName;
    4. }

    This doesn't need an api-call or console run after start/reload. The run of time consumption at startup delays the starting process.


    The parent path calculation is still pending, as I try to make the code faster and usable for huge environments. I use a creation of hosts with a fix numbers of parents.


    With 1000 hosts it use 1-2 seconds. With 2000 it use 4-5 seconds. With 10000 it take 45 seconds.