Migrate service from NRPE to Icinga2 agent

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


    I'm currently moving all my clients away from NRPE to Icinga2 Agent. Following is the service with variables I'd like to move to Icinga2 command:


    Code
    1. object Host "de-staging-app" {
    2. import "linux-box-remote"
    3. address = "10.14.0.15"
    4. vars.mounts = { "/data" = "de-staging-gluster1:gv0" }
    5. vars.queues = { "paperboy_in" = "de_staging!paperboy_in!1000!7", "paperboy_out" = "de_staging!paperboy_out!1000!7" }
    6. }

    What is the best way to use vars.queues arguments in Icinga2 command?

  • Current command for NPRE is: /usr/lib/nagios/plugins/rabbitmq.sh $ARG1$ $ARG2$ $ARG3$ $ARG4$ $ARG5$

    Where:

    And I want to use Icinga2 command for that, something like

    But I'm not sure how to organize those values in service description and how to use them in command.

    The post was edited 2 times, last by vaisov ().

  • I know how to pass the arguments overall, I'm just not sure how to describe arrays in dictionaries and then use them in command. I imagine something like that:

  • That value logic shouldn't happen inside the CheckCommand. The arguments and their values should be static and unique for the CheckCommand.


    Code
    1. "min_consumer_count" = {
    2. skip_key = true
    3. value = "$rabbitmq_min_consumer_count$"
    4. order = 4
    5. }


    Your host object and service apply rule may then set these custom attributes as command parameters accordingly. This is where you can use the programmatic logic with if-then-else and array/dictionary accessors.


    I would propose a more programmatic solution, but still, your "queues" and "mounts" custom attributes don't make much sense to me. Which check plugin (URL!) are you using and how does the current "nrpe" config look like?

  • For rabbitmq I'm using our custom written plugin. Current nrpe config for queues:

  • Solved the issue with following host description:

    Code
    1. object Host "de-staging-app" {
    2. import "linux-box-remote"
    3. address = "10.14.0.15"
    4. vars.mounts = { "/data" = "de-staging-gluster1:gv0" }
    5. vars.queues = { "paperboy_in" = [ "de_staging", "paperboy_in", "1000", "7" ], "paperboy_out" = [ "de_staging", "paperboy_out", "1000" ,"7" ] }
    6. }

    And following service:

    and following command:

  • Ah ok, that's what I wanted to do - nest the dictionary keys a bit more. Your post just lacked the context a bit, so I did not want to propose anything wrong.


    One thing at last about custom attribute naming - do use a unique name for each argument, so that you know which value means what. You don't see the benefit now, only later after months when you look into it and want to troubleshoot or adopt thresholds.


    One thing you are encouraged to do - add docs and add that CheckCommand upstream. Others may review it, and you'll never have to configure it on your own. This is especially helpful on clients having the CheckCommands by default.


    How I would do it, to keep me safe from future maintenance?


    • renamed command to pluginname_purpose - rabbitmq_queue
    • argument values like best practice



    Don't use arrays where you don't know the key. Furthermore arrays with indexes are serious about the order. One error could break your entire configuration. Rather go for dictionaries and keys. Use the same key as used above in the CheckCommand definition.


    rabbitmq_queue_name is omitted, that's the dictionary key.


    That reduces the logic used in your service apply for rule a lot. And the host code above is modular for more services. Note aside - numbers don't need quotes.



    Bonus with the above - should you ever have to add a new CheckCommand argument, you just name it in the same way and add it to your Host dictionary as additional nested dictionary key. You don't have to touch the Service apply for rule ever again.


    More documentation on apply for loop unrolling was added for 2.8 into the docs: https://www.icinga.com/docs/ic…attributes-in-apply-rules


    (did not test my examples, you might find typos)