Icinga 2.10 released: Namespaces, Notifications, TLS Performance

Our friends from the Max-Planck-Institut for Marine Mikrobiologie kindly sponsored that acknowledgement notifications are now sent only to users which have been notified about a problem before – thanks a lot. Another sponsor asked for more child options for the ScheduledDowntime which are now released in 2.10.
2.10 also brings support for namespaces and allows us to keep the “globals” namespace clean. In addition to that, user-defined namespaces are possible and can be imported into the global namespace too. Read more about this feature here. An additional DSL feature is the support for references. You’ll also find new fine granular path constants in this release, e.g. ConfigDir instead of SysconfDir + “/icinga2”. The old constants are still intact but deprecated.
As promised in the 2.9.2 release post, we’ve been debugging TLS connection handling with many threads and TLS timeouts in large scale environments. This release adds a dynamic thread connection pool for both, cluster messages and HTTP requests. With the performance boost granted, we’ve also lowered the cluster reconnect interval from 60 to 10 seconds. This ensures that configuration deployments triggering a reload don’t leave clients behind.
(more…)

Monthly Snap August – v2.5, InfluxDB, Contributions

IMG_0330We keep working together as an open source community. We’re here to listen what you say – keep it polite and encourage/motivate us to solve your problem with you as best as we can. Lean back and think how others would react if you click “send”, frustrated with an issue tab opened in your browser. Sometimes it doesn’t hurt to just close the tab or rephrase. The person on the other end (dev and/or user) will appreciate it. In the end we all are human beings with emotions, language & culture differences and offline needs (friends, family, hobbies, etc.). What we have in common – we all want to build a great Icinga monitoring product together 🙂
Bernd did a great ignite on that topic with “Working in and with Open Source Communities” at DevOpsDays Amsterdam (video starts at 17:35).
(more…)

Icinga 2 v2.5 released

We’ve come a long way with our new release Icinga 2 v2.5. After the 2.4 release in November we’ve focussed on fixing many of the remaining bugs. 2.5 isn’t just a feature release – it includes all the bugfixes from the past months. (more…)

Icinga 2: Host state calculation from all services

There is a variety of questions answered in the community support channels. Sometimes we just hack away fancy solutions directly inside the Icinga 2 DSL. Some of these examples are collected inside the documentation, others are posted on the community channels. Or they are just provided in hands-on workshops at customers waiting for sharing their stories to the world 🙂
This time there was the this question over at monitoring-portal.org – a host object collects a bunch of passive services and should calculate its overall state and output from the (worst) state of all referenced services.
Sounds easy. You could go for business process check returning the calculated value. Or you stick with many of the Icinga 2 configuration language features and put them altogether.

For a small test environment, I’ve generated 5 services using the random check (replace that with your real world scenario).
 

for (j in range(5)) {
  object Service "host-servicestatus-" + j {
    check_command = "random"
    check_interval = 30s
    retry_interval = 15s
    host_name = "host-servicestatus"
  }
}

The host object called “host-servicestatus” just uses the “dummy” check command provided by the ITL. This check command expects two custom attributes: “dummy_state” and “dummy_text”.
Now for the fun part – implement two lambda functions for these custom attributes using the available methods.

  vars.dummy_state = {{ ... }}
  vars.dummy_text = {{ ... }}

We want to calculate the worst state for all services on this specific host. Therefore we’ll use a temporary variable to save and update the worst state.

    var worst_state = 0

At first glance we want to selectively iterate over all service objects using the object accessor method “get_objects” with “Service” type. Then we’ll compare the service “host_name” attribute to the local scope (our host and its name). We’ll just skip all services not matching.

    for (s in get_objects(Service)) {
      if (s.host_name != host.name) {
        continue; //skip all services not referencing this host object
      }

The local to the loop variable “s” provides us with access to the all attributes for the current service object. Check whether its state is greater than 0 (not OK) and greater than the previously collected worst state. If so, store it in the local variable “worst_state”.

      if (s.state > 0 && s.state > worst_state) {
        worst_state = s.state
      }
    }

After the loop is finished, just return the “worst_state” variable for this function.

    return worst_state

In terms of generating an additional output text with all service names and their state, we’re using the same loop and conditional checking as above. Except we are using a temporary variable as an array of strings like this:

    var output = []

Inside the loop we’ll add the current service name and its state as string element to the “output” array.

      output.add(s.name + ": " + s.state)

Once the loop is finished, join the array elements with the separator “, ” concatenate the final output string and return it.

    return "Service summary: " + output.join(", ")

We could also concatenate the string as is but then we would need to think about the last loop run not adding the “,” character. The array join method just simplifies that step.
icinga2_host_servicestatus_web2The final solution works like a charm 🙂 If you say – hey I am not a coder – it helps to know Javascript, or Python or something similar of course. After all it is a pretty neat solution for helping a community member 🙂
 

object Host "host-servicestatus" {
  check_command = "dummy"
  vars.dummy_state = {{
    var worst_state = 0
    for (s in get_objects(Service)) {
      if (s.host_name != host.name) {
        continue; //skip all services not referencing this host object
      }
      if (s.state > 0 && s.state > worst_state) {
        worst_state = s.state
      }
    }
    return worst_state
  }}
  vars.dummy_text = {{
    var output = []
    for (s in get_objects(Service)) {
      if (s.host_name != host.name) {
        continue; //skip all services not referencing this host object
      }
      output.add(s.name + ": " + s.state)
    }
    return "Service summary: " + output.join(", ")
  }}
}

User story: Bachelor thesis on Icinga 2

We’re busy developers always trying to help on our community channels (mailing lists, forum, IRC) whenever possible. Some users just ask one question, others stick around and get into detail. One of them was Benjamin asking lots of questions about Icinga 2 HA clusters and clients. We exchanged several private messages and emails and it turned out that he is studying Information and Communication Technology at the University of Applied Sciences Leipzig and was writing his bachelor thesis on the Icinga 2 Migration at Deutsche Telekom Technik (in German).
I kindly asked him to share his bachelor thesis as we love to see how Icinga 2 is used and evaluated in user and enterprise environments. Benjamin did send it this week, enjoy reading 🙂 Note: The content copyright is held by the author only.
Have your own story on Icinga? Get in touch and share yours 🙂