Business Process 2.2.0

Business Process 2.2.0

Gut Ding will Weile haben. Or, Rome wasn’t built in a day. Though, I like the German version more because it’s not that quite a stretch.

Well, what this is all about you ask? It’s been the first quarter of 2017 when the first version of the Icinga Business Process Module had the chance to impress its audience. It’s gone rather quiet since then. But don’t worry, just two years later there is the solution to the so-called order it imposed on us: Chaos.

Okay, okay, straight to the point:

 

Drag’n’Drop

Previously it wasn’t possible to disable the automatically applied alphabetical order of nodes. It is now possible to simply grab a node and move it wherever you want it to. Or, to be the master of chaos, so to speak.

 

Importing Processes

Ever wanted to re-use a process you defined within a different configuration? Without duplicating it? This has been an undocumented feature but is now fully integrated into the UI and documented.

 

Usability and Visualization

Additionally the breadcrumbs and the tree view were adjusted and got a lighter design to help those with epilepsy. Well, not quite correct, we just thought a change is due. Besides, the navigation has been enhanced by allowing you to jump to the overview using the breadcrumbs and letting external info URLs open in a new browser tab.

 

The full changelog can be found here.

All issues and features related to this release can be found on our roadmap.

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(", ")
  }}
}

Vagrant box playtime

vagrant_icingaweb2_dashboardWhile preparing for our OSMC booth and talk, we thought about enhancing the existing Vagrant boxes and include more demo cases. While the icinga2x-cluster boxes illustrate the cluster in a master-checker setup, the standalone box icinga2x focuses on a single Icinga 2 instance with Icinga Web 2 and the Icinga 2 API.
Alongside the Icinga 2 API and Icinga Web 2 there are numerous additions to the icinga2x Vagrant box:
 

PNP

vagrant_icinaweb2_detail_graphs_ttsPNP4Nagios is installed from the EPEL repository. The Icinga 2 Perfdata feature ensures that performance data files are written and the NPCD daemon updates the RRD files. Navigate to the host or service detail in Icinga Web 2 and watch the beautiful graphs. There’s also a menu entry in Icinga Web 2 providing an iframe to the PNP web frontend on its own.
 

GenericTTS

There are demo comments including a ticket id inside the Vagrant box. A simple script feeds them into the Icinga 2 API and the Icinga Web 2 module takes care of parsing the regex and adding a URL for demo purposes.
 

Business Process

vagrant_icingaweb2_business_processThe box provides 2 use cases for a business process demo: web services and mysql services. In order to check the MySQL database serving DB IDO and Icinga Web 2, we’ve added the check_mysql_health plugin (Icinga 2 v2.4 also provides a CheckCommand inside the ITL <plugins-contrib> already, so integration is a breeze).
These Icinga 2 checks come configured as Business Processes in the Icinga Web 2 module which also allows you to change and simulate certain failure scenarios. You’ll also recognise a dashboard item for the Top Level View allowing you to easily navigate into the BP tree and the host and service details. Pretty cool, eh?
 

NagVis

vagrant_icingaweb2_nagvisThe puppet module installs the latest stable NagVis release and configures the DB IDO as backend. The integration into Icinga Web 2 uses a newly developed module providing a more complete style and integrated authentication for the NagVis backend. Though there are no custom dashboards yet – send in a patch if you have some cool ones 🙂
 
 

Graphite

vagrant_graphite_webThe Graphite backend installation is helped with Puppet modules, the main difference is that Graphite Web VHost is listening on port 8003 by default (80 is reserved for Icinga Web 2). The carbon cache daemon is listening on 2003 where the Icinga 2 Graphite feature is writing the metrics to.
 
 

Grafana

vagrant_grafanaGrafana 2 uses Graphite Web as datasource. It comes preconfigured with the Icinga 2 dashboard providing an overview on load, http, mysql metrics and allows you to easily modify or add new graphs to your dashboard(s).
 
 

Dashing

vagrant_dashingWe’ve had a Dashing demo using the Icinga 2 API with us at Icinga Camp Portland though it required some manual installation steps. Since the Vagrant box already enabled the Icinga 2 API, the provisioner now also installs Dashing and the demo files. Note: Installing the Ruby gems required for Dashing might take a while depending on your internet connection. If Dashing is not running, call `restart-dashing`.
 
 

Playtime!

The icinga2x box requires a little more resources so make sure to have 2 cpu cores and 2 GB RAM available. You’ll need Vagrant and Virtualbox or Parallels installed prior to provision the box.

git clone https://github.com/Icinga/icinga-vagrant.git
cd icinga-vagrant/icinga2x
vagrant up

The initial provisioning takes a while depending on your internet connection.
Each web frontend is available on its own using the host-only network address 192.168.33.5:

Icinga Web 2 http://192.168.33.5/icingaweb2 icingaadmin/icinga
PNP4Nagios http://192.168.33.5/pnp4nagios
Graphite Web http://192.168.33.5:8003
Grafana 2 http://192.168.33.5:8004 admin/admin
Dashing http://192.168.33.5:8005

 
In the future we’ll add more Icinga Web 2 modules or other addons, just let us know what you want to play with or send a patch even 🙂