Posts by log1c

    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\"}"

    If I see this correct, you created a service, but it is not bound to anything, so it does not show at any host.


    here is how a service template and an applied service look like:


    so I'd say, you need to create an apply rule that imports your service template and assign it to a host.

    Can you be more precise as to what you mean by

    Quote

    .is there any way to find some built in check command like the nagios plugins.

    In the command list inside Icinga Director all commands displayed with a "pin" in the front are pre-defined.

    The are ready to use, you only need to configure:

    1. the needed fields for the arguments

    2. the corresponding plugin script in /usr/lib/nagios/plugins

    3. a service template that uses the check command

    Do you have the scripts that these commands need in the respective folder?

    Default for "PluginDir" is "/usr/lib/nagios/plugins"

    So you will need your "check_updates" script in this folder, as well as any other script you want to execute.


    Concerning your command:

    Why the skip_key for your "-c" argument?


    to get more scripts in you PluginDir you can install these packages (example for Ubuntu):

    Code
    1. monitoring-plugins - Erweiterungen für zu Nagios kompatible Überwachungssysteme
    2. monitoring-plugins-basic - Plugins for nagios compatible monitoring systems (basic)
    3. monitoring-plugins-common - Common files for plugins for nagios compatible monitoring
    4. monitoring-plugins-standard - Plugins for nagios compatible monitoring systems (standard)
    5. nagios-snmp-plugins - SNMP Plugins for nagios

    Hi all,


    I'm having a question(or some :D) concerning an Icinga2 setup with satellites in different time zones.

    The system has a master and a satellite in time zone Europe/Berlin, one satellite in the US and one in South Korea (don't know the exact location of those two).

    As of know I have set up ntp on all of these machines and configured it to "Europe/Berlin".

    The reasons I did this are:

    1. the customer has disabled Hyper-V time sync for the guest machines

    2. before the ntp setup, checks were often overdue


    The disabled Hyper-V time sync also leads to the problem, that Icinga2 starts with the "random time" the Hyper-V injects (e.g. two months in the future).

    To work around this I added the ntp service to the requirements in the icinga2 system.d script.


    Is setting all sattellites to the same time zone the correct way?

    I have read, that IcingaWeb2 takes the time zone from the browser and converts timestamps to UTC internally. Can this and the ntp settings combined, be a problem when someone from, lets say, South Africa works with IcingaWeb2.


    Version:

    I'm not sure, to be honest, as I can only work on the system, when the customer lets me :D

    Last update of Icinga2 and IcingaWeb2 I did was around March '17


    If I can provied anything else, pls tell me.


    Thanks and greetings :)