Monitoring Icinga 2 features

Icinga 2
1

Hi,

Today I stumbled upon a setup where someone deactivated the notification feature on both master nodes and forgot to reactivate it on one. So they ended up with one master sending notifications and the other one remaining silent.

So I thought about introducing (and if you like it, contributing) a check that checks whether a certain feature is enabled and active. I’m not very used to writing function so you might have a suggestion or two for what I’d be very thankful. Especially getting rid of the duplicated function would be something I’d like to see.

Thanks to @Al2Klimov for the initial idea of using DSL, not bash.

So here it is (Don’t mind the apply rule, I just used copy and paste within my dev-environment)

apply Service "Notification" {
  import "generic-service"
  check_command = "feature"
  command_endpoint = host.name
  vars.component_type = "NotificationComponent"
  vars.component_name = "notification"
  assign where host.vars.os == "linux"
}

object CheckCommand "feature" {
  import "dummy"
  vars.dummy_text = {{
    var comp_type = macro("$component_type$")
    var comp_name = macro("$component_name$")
    var res = "Object " + comp_name + " of type " + comp_type + " exists"
    var mycomponent = get_object(comp_type,comp_name)
    if ( mycomponent == null)  {
       res = "Object " + comp_name + " of type " + comp_type + " missing"
    }
    return res
  }}
  vars.dummy_state = {{
    var comp_type = macro("$component_type$")
    var comp_name = macro("$component_name$")
    var restate = 0
    var mycomponent = get_object(comp_type,comp_name)
    if ( mycomponent == null)  {
       restate = 2
    }
    return restate
  }}
}
4 Likes
2

I’d…

  • get_objects and use the array’s length instead of requiring a particular object name (see also IDO master - set prefered host)
  • look at the feature names from icinga2 feature list, require them as $component_type$ and map them via a variable inside the CheckCommand (dummy_text and dummy_state would have to be () use (...) => { ... }) to the DSL types
  • $component_type$ => $feature_name$ (as command name is “feature”)
  • don’t compute stuff als long as you don’t know you need it, at best return ... ? ... : ...
  • put repeating stuff into a function inside the CheckCommand (dummy_text and dummy_state would have to be () use (...) => { ... })
  • avoid the variable mycomponent
  • have a more precise look at whitespaces, indents and empty lines (latter for readability)
  • actually open a PR and continue the discussion there
  • consider my like and not the amount of these bullets as your grade :wink:
2 Likes
3

Thanks a lot, @Al2Klimov . I’ll see what I can make of it but I’m positive, your tips help me with providing a useful solution.

Regarding not using a PR: I planned on starting a PR I just wanted to have my early verison reviewed here because I’m more used to GitLab’s style of working with MRs and maybe I’m a bit intimidated by GitHub and don’t want to do things like pushing a squashed commit. This is something I had to do in the past and I wanted to avoid it this time.

The extra whitespaces and empty lines come from me playing around in my devel kit. I’ll remove them before opening the PR.

Thanks again, I’ll have a look.

1 Like