Struggle to create a CheckCommand using the Icinga2 API

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


    I'm quite new to monitoring and Icinga2. I've spend quite some time with the documentation before decided to post my question here.


    I'm trying to create a CheckCommand object using the API, but I'm struggling the achieve the bare minimum. I should mention as well that my aim is to enable a custom build plugin that is working well with Icinga to work with Icinga2. When I check the currently existing check_commands with a GET to https://my_IP:5665/v1/objects/checkcommands I get quite a few check_command for example below is the load check_command:


    According to the docs the bare minimum attributes that have to be specified are the command and execute. Firstly I'm quite confused with the execute attribute (The "execute" script method takes care of executing the check. In virtually all cases you should import the "plugin-check-command" template to take care of this setting.) as for load above it seems to be a dictionary containing "type": "Function"? For testing reasons I'm trying to pass the only required attributs when I PUT to https://my_IP:5665/v1/objects/checkcommands/mem_linux with the following raw Body: { "attrs": { "command": ["usr/lib/nagios/plugins/check_mem_linux"], "execute": "import 'plugin-check-command'" }}. Why do I get the error below as it follows the same syntax as the load check_command from above:



  • I've accepted defeat and created the CheckCommand manually. It work all fine.


    I would advise other beginners like me to go through Icinga1 documentation first as it written more in dept.

  • When you are referencing a template, you need to pass it like so. In a similar fashion all object attributes must be set inside the "attrs" dictionary.


    Code
    1. $ curl -k -s -u root:icinga -H 'Accept: application/json' -X PUT https://localhost:5665/v1/objects/checkcommands/mytest -d '{ "templates": [ "plugin-check-command" ], "attrs": { "command": [ "/usr/local/sbin/check_http" ], "arguments": { "-I": "$mytest_iparam$" } } }'
    2. {"results":[{"code":200.0,"status":"Object was created"}]}




  • Thanks a lot dnsmichi. That does exactly what I need.


    By the way one thing I spotted in the docs for Service API call is that there are 3 required attributes (host_name, name, check_command) of which actually only the check_command is essential.

  • http://docs.icinga.org/icinga2…nga2/chapter/object-types


    The section for the Service object:


    Configuration Attributes:

    display_name Optional. A short description of the service.
    host_name Required. The host this service belongs to. There must be a Host object with that name.
    name Required. The service name. Must be unique on a per-host basis (Similar to the service_description attribute in Icinga 1.x).
    groups Optional. The service groups this service belongs to.
    vars Optional. A dictionary containing custom attributes that are specific to this service.
    check_command Required. The name of the check command.
    max_check_attempts Optional. The number of times a service is re-checked before changing into a hard state. Defaults to 3.
    check_period Optional. The name of a time period which determines when this service should be checked. Not set by default.
    check_interval Optional. The check interval (in seconds). This interval is used for checks when the service is in a HARD state. Defaults to 5 minutes.



    I'm able PUT Services by only providing the check_command attribute

  • Hm, that is the table for the static configuration files which is partially different to the REST API calls and their required attributes. Since you are using the service full name already, you don't need the host_name attribute being passed as body.

  • As an Icinga2 beginner most of my understanding how the monitoring works was based on going through the Documentation.


    Similarly for the CheckCommand API call I find it weird that the working solution you provide doesn't include the execute attribute despite being marked as Required.



    Configuration Attributes:

    execute Required. The "execute" script method takes care of executing the check. In virtually all cases you should import the "plugin-check-command" template to take care of this setting.
    command Required. The command. This can either be an array of individual command arguments. Alternatively a string can be specified in which case the shell interpreter (usually /bin/sh) takes care of parsing the command. When using the "arguments" attribute this must be an array. Can be specified as function for advanced implementations.
    env Optional. A dictionary of macros which should be exported as environment variables prior to executing the command.
    vars Optional. A dictionary containing custom attributes that are specific to this command.
    timeout Optional. The command timeout in seconds. Defaults to 60 seconds.
    arguments Optional. A dictionary of command arguments.
  • Sorry just realized that you clarified that is the table for the static configuration files which is partially different to the REST API calls and their required attributes.


    Is there such section regarding the REST API calls and their required attributes?

  • The documentation is not perfect but instead of duplicating all object attributes from inside the object type chapter, we decided to just link over there. If you find a more satisfying solution with some remarks for the API in that table, go for it and send in a patch (it is just markdown).