Posts by log1c

    If I understand you correctly what you would need is a master-satellite setup.

    The master monitors your productive environment, the satellite monitors your development env.


    Master and satellite the communicate over port tcp/5666 with a secured connection.


    A passive service in monitoring will only work if the component you want to monitor can actively monitor itself (like SNMP traps or NSCA with nsclient) (or am I wrong here?). For SNMP traps for example you need a SNMP trap translator configured on your monitoring server to translate the received traps and forward them to the correct icinga service. -> https://www.icinga.com/docs/ic…ck-results-and-snmp-traps

    seems like your master-satellite conncetion is not working.

    Did you run the icinga2 node wizard on the master and set up a master (first question "NO")?

    And on the satellite you set up a satellite and connected it correctly to the master (master fqdn, ip, ticketsalt)?

    Is 'icinga.meinefirma.com' your master servers fqdn?


    Maybe run the node wizard on master and satellite again, add the global zone to both zones.conf files, restart icinga2 on both master and satellite and then run the kickstart assistent from director ([your master ip]/icingaweb2/director/dashboard?name=infrastructure#!/icingaweb2/director/kickstart).

    After this you should have 3 zones and 3 endpoint objects in your director (global,master,satellite) which you can use to bind hosts to your zones.


    I don't know if this is the "right" way to do it, but it certainly works for me.

    Glad I could help :)


    Play around some more and you'll get the hang of it ;) Maybe look at some tutorials (unixe and nausch have some good ones!)


    Don't forget to mark the thread as resolved, if your problem is solved:)

    Now I see the problem :)

    The check command is configured correctly but you made a mistake when setting up your data fields. Which you did manually, right?


    If you define a data field you must not add the $ signs!

    So your data field "DruckerArgument" needs to look like this:



    But you don't have to define every data field yourself.

    When you define a command that uses a new, not existing, data field and you want to add this field in the "Fields Tab" of the command, the Director will automatically create this field for you (you will get the "extended" new field dialogue like shown above).


    I hope this is explained comprehensibly :D

    Are the variables $community$ and $DruckerArgument$ filled by your host or service template?


    When you set the whole command line you are using the explicit values (status, public) for those variables, that's why it works.

    $address$ autoamtically gets the ip address of the host the service is attached to.


    So what you need is a service template that fills the fields $community$ and $DruckerArgument$ and that than is applied to a specific host.

    Hey Goku ;),


    are you using the "real" v1.3.1 of the Director? Or did you clone/pull the current Director master from git?

    I'm asking because I don't have this problem with v1.3.1 neither v1.3.2 in my testing environment and you seem to have a different version, because of the "info blobs" on the bottom of the director panel.


    I couldn't find any bug reports on this though(quick check), so it might not be related to the version.

    Hi Alex,


    if you click on the deployment itself you should get a deployment details page. The log excerpt in there will pretty much exactly tell you what Icinga2 does not like about your config :).

    See screenshot for an example:

    In case you don't use the Icinga2 Agent on your Windows Server and you want/need to use check_nt there also is a pre-definde command "nscp".

    To use this command to check your service you have to attach the appropriate fields to the check command. As kevin states the Icinga Director already suggests you some of the fields the check command uses when opening the drop down menu.

    To use the nscp command like before you will need to create a data field "nscp_showall" beforehand:



    After this you can attach the needed fields to the "nscp" command:



    The next step is creating a service template that uses the configured check command and configures settings like intervals:



    This service template can now be applied as a "proper" service that checks something specific on a host (like your service).

    In this apply rule you define the name of your service check, e.g "SP2010 Foundation Search Service" and apply this check to your "Sharepoint Host".

    Also you have to set the needed variables in the corresponding data fields:


    As this thread has been "dug up" ;):

    Just in case someone is looking for a workaround for scheduled downtimes before they are configurable via Direcot:


    Currently I configure scheduled downtimes as a config file on the Icinga2 master server.

    /etc/icinga2/conf.d/downtimes.conf

    following an example for a flexible downtime that startes between 00:15 und 01:30

    It works and keeps your checks working 24x7, so there is no gap in perfdata for example.


    Best Regards!

    Forgive me if this is completely wrong, as I am not familiar with the Icinga2 Agent for Windows (bc I still use the standalone NSClient for that).

    I assume, that the check commands in director with ".exe" are the ones that are provided/used by the Icinga2 Agent?

    Then why not use the service-windows (check_service.exe) command to check different services?

    there is also an argument for object_type:

    Code
    1. icingacli director service create generic-service --object_type template --max_check_attempts '5' --check_interval '1m' --retry_interval '30s'
    2. icingacli director service create load --object_type template --imports "generic-service" --check_command load
    3. icingacli director service create load --json "{\"object_type\":\"apply\",\"imports\":[\"load\"],\"assign_filter\":\"host.name=%22${HOSTNAME}%22\"}"