Seite wählen

NETWAYS Blog

Awesome Dashing dashboards with Icinga 2

vagrant_dashingWe at NETWAYS are using Dashing on our office dashboards already. This blog post solely targets integrating yet another new API providing data – the Icinga 2 REST API introduced in v2.4.
The following instructions were taken from the existing Vagrant boxes and their puppet manifests to allow faster installation. Doing it manually shouldn’t be an issue though 😉

Requirements

Ensure that the following packages are installed, example for RHEL 7 with EPEL enabled:

package { [ 'rubygems', 'rubygem-bundler', 'ruby-devel', 'openssl', 'gcc-c++', 'make', 'nodejs' ]:
  ensure => 'installed',
  require => Class['epel']
}

Furthermore put a specific /etc/gemrc file which disables installing the documentation for gems – this can take fairly long and is not required by default. Especially not when provisioning a Vagrant box or a Docker container.

dashing-icinga2

I’ve created that project as demo for Icinga Camp Portland with the help of the existing Icinga 1.x dashing scripts from Markus, and a new job for fetching the Icinga 2 status data from its REST API.
Clone the git repository somewhere applicable. You don’t need any webserver for it, Dashing uses Thin to run a simple webserver on its own.

vcsrepo { '/usr/share/dashing-icinga2':
  ensure   => 'present',
  path     => '/usr/share/dashing-icinga2',
  provider => 'git',
  revision => 'master',
  source   => 'https://github.com/Icinga/dashing-icinga2.git',
  force    => true,
  require  => Package['git']
}

Install the dashing gem

The installation might take pretty long when it tries to install the gem’s documentation files. Therefore the flags „–no-rdoc“ and „–no-ri“ ensure that this isn’t done and only the dashing gem and its dependencies are installed into the system.

exec { 'dashing-install':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "gem install --no-rdoc --no-ri dashing",
  timeout => 1800
}

Install the gems for dashing-icinga2

Next to the dashing application itself the project requires additional gems, such as a rest client for communicating with the Icinga 2 REST API (check the Gemfile for details). Additionally the bundled gems are not installed into the system’s library but locally into the dashing-icinga2 git clone underneath the „binpaths“ directory (this is to prevent conflicts with rubygem packages in the first place).

exec { 'dashing-bundle-install':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "cd /usr/share/dashing-icinga2 && bundle install --path binpaths", # use binpaths to prevent 'ruby bundler: command not found: thin'
  timeout => 1800
}

Dashing startup script

Put a small startup script somewhere executable to (re)start the Dashing application.

file { 'restart-dashing':
  name => '/usr/local/bin/restart-dashing',
  owner => root,
  group => root,
  mode => '0755',
  source => "puppet:////vagrant/files/usr/local/bin/restart-dashing",
}

Dashing runs as Thin process which puts its pid into the local tree. It is merely all about killing the process, removing the pid and then starting dashing again. „-d“ puts the process into daemonize mode (not foreground) as well as „-p 8005“ tells the application where to listen for browsers connecting to. Adjust that for your needs 🙂

#!/bin/bash
cd /usr/share/dashing-icinga2
kill -9 $(cat tmp/pids/thin.pid)
rm -f tmp/pids/thin.pid
/usr/local/bin/dashing start -d -p 8005

Now run Dashing.

exec { 'dashing-start':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "/usr/local/bin/restart-dashing",
  require => Service['icinga2'],
}

Configure the Icinga 2 API

The dashing job script just requires read-only access to the /v1/status endpoint. Being lazy I’ve just enabled everything but you should consider limited access 🙂

object ApiUser "dashing" {
  password = "icinga2ondashingr0xx"
  client_cn = NodeName
  permissions = [ "*" ]
}

Configure the Dashing job

There’s a bug in Dashing where job scripts ignore the settings from the config.ru file so there is no other way than to put the Icinga 2 REST API credentials and PKI paths directly into the jobs/icinga2.rb file.

$node_name = Socket.gethostbyname(Socket.gethostname).first
if defined? settings.icinga2_api_nodename
  node_name = settings.icinga2_api_nodename
end
#$api_url_base = "https://192.168.99.100:4665"
$api_url_base = "https://localhost:5665"
if defined? settings.icinga2_api_url
  api_url_base = settings.icinga2_api_url
end
$api_username = "dashing"
if defined? settings.icinga2_api_username
  api_username = settings.icinga2_api_username
end
$api_password = "icinga2ondashingr0xx"
if defined? settings.icinga2_api_password
  api_password = settings.icinga2_api_password
end

Modifications?

You really should know your HTML and Ruby foo before starting to modify the dashboards. The main widget used inside the dashboards/icinga2.erb file is „Simplemon“ defined as data-view attribute. It is already provided inside the dashing-icinga2 repository. data-row and data-col define the location on the dashboard matrix.

    <li data-row="2" data-col="2" data-sizex="1" data-sizey="1">
      <div data-id="icinga-host-down" data-view="Simplemon" data-title="Hosts Down"></div>
    </li>

The important part is the data-id attribute – that’s the value coming from the icinga2 job defined in jobs/icinga2.erb.
The job update interval is set to 1 second in jobs/icinga2.erb:

SCHEDULER.every '1s' do

Connecting to the Icinga 2 REST API, fetching the status data as JSON and then iterating over these dictionaries is pretty straight forward. Additional programming examples can be found inside the Icinga 2 documentation.
Take the „hosts down“ example from above:

hosts_down = status["num_hosts_down"].to_int

Now send the event to dashing by calling the send_event function providing the previosuly extracted value and the demanded color.

  send_event('icinga-host-down', {
   value: hosts_down.to_s,
   color: 'red' })

In case you’re wondering which values are fetched, let dashing run in foreground and print the „status“ dictionary to get an idea about possible keys and values. Or query the Icinga 2 REST API with your own client first.

More?

You can play around with an already pre-installed environment inside the icinga2x Vagrant box and if you’re interested in an automated setup, check the puppet provisioner manifest.
I’m fairly certain that I might improve these puppet manifests after joining the NETWAYS Puppet Practitioner & Architect trainings in February 😉 In case you’ll need your own dashboards and custom modifications, just ask 🙂

Vagrant box playtime

vagrant_icingaweb2_dashboardWhile preparing for the Icinga OSMC booth and talk, the Icinga developers 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, the check_mysql_health plugin is used (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_nagvis
The 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_web
The 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_grafana
Grafana 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_dashing
There was a Dashing demo using the Icinga 2 API 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

 

NETWAYS legt noch einen drauf – einen kostenlosen Chromecast!

Da wir von NETWAYS meinen, wir haben die besten Kunden der Welt, bekommen diese nun etwas von uns zurück – einen Google Chromecast. Zwar kann man diesen auch regulär bei uns im Shop kaufen, jedoch bekommen alle Besteller im Shop mit einem Nettobestellwert ab 1.000,00 € einen Chromecast KOSTENLOS dazu. Warum verkauft NETWAYS überhaupt Chromecasts? Ein gutes Beispiel dafür ist Dashing – NETWAYS Betreibt selber einige Dashboards, damit alle Mitarbeiter sofort sehen was los ist. Der Chromecast eignet sich optimal dazu, den Dashboard-Tab auf den jeweiligen TV in der Abteilung zu bringen. Natürlich kann man noch andere Sachen mit dem Chromecast machen – aber das ist ja jedem selbst überlassen. Auch nett anzusehen: Icinga Web mit dem Tab-Slider!
Wie es genau funktioniert:

  • Unseren Online-Shop besuchen
  • Waren für mind. 1.000,00 € netto aussuchen und in den Warenkorb legen
  • Chromecast in den Warenkorb legen
  • im Warenkorb den Gutscheincode „NETWAYS-Chromecast“ eingeben
  • Bestellung absenden
  • über kostenlosen Chromecast freuen

chromecastBedingungen: Nur auf Bestellungen ab 22.04.2014 anwendbar, keine Auszahlungen des Gutscheinwertes, nur solange der Vorrat reicht, Anspruch nur wenn der Chromecast in den Warenkorb gelegt wurde und der korrekte Gutschein-Code eingegeben wurde. Nur ein Chromecast je bestellendem Kunde+Tag. Keine rückwirkende Anwendung auf vergangene Bestellungen. Nur für Bestellungen über das Shop-System. Bei einer Warenrücksendung ist der Chromecast Bestandteil der reibungslosen Rückabwicklung. NETWAYS kann nach eigenem Ermessen die Vergabe kostenloser Chromecasts verweigern. Der Rechtsweg ist ausgeschlossen!

Weekly Snap: Syslog & Graphite, Dashing & Brainstorming

weekly snap27 – 31 January finished off the month with events aplenty, monitoring in different forms and best practices in brainstorming and virtual machines.
In usual style, Eva started the week counting 71 days to the OSDC by sharing Philipp Reisner’s talk on the latest in DRBD9. She went on to announce our Call for Papers for the next Puppet Camp in Berlin on 11 April.
Seeking out best practices, Marius H considered the best way to brainstorm as Dirk compared Cloud Provisioner to Compute Resource to find the best method to deploy virtual machines.
Thomas then added a second instalment to his Logstash series with a look at the Logstash predecessor Syslog and Bernd shared a video on the reality of conference calling.
The week ended on monitoring, as Marius G took a look at Dashing for good-looking, custom dashboards and Markus W introduced our advanced course on Real-time Graphing with Graphite.

Dashing – ein Blickfang in der Firma

Auf der Suche nach tollen neuen Features, sind wir auf das sogenannte „Dashing“ gestoßen.
Dashing ist ein „Sinatra based Framework“, das es einem ermöglicht schöne Dashboards zu bauen.
Dashing ist in der Hinsicht für Abteilungen und Firmen von Vorteil, da man sein Dashboard individuell anpassen und nach seinem Belieben mit Daten befüllen kann.
Wir von NETWAYS nutzen unser Dashboard beispielsweise, um Daten aus dem Monitoring, Backup und Foreman zu visualisieren und für alle Beteiligten gut sichtbar und übersichtlich darzustellen.
Was die Gestaltung des Dashboards angeht, sind der Kreativität keine Grenzen gesetzt.
Man kann die Größe, die Anzahl und die Positionen der Kacheln bestimmen, sowie Signalfarben einsetzen um auf ein Problem oder eine Störung hinzuweisen.
Auch ist es möglich, beispielsweise mit Graphite erzeugte Graphen im besagten Dashboard anzuzeigen.
So hat man also auf einen Blick eine schöne, bunte, geordnete Übersicht über mögliche Probleme, Datenauswertungen und vielem mehr.
Die Kachel selbst ist aufgebaut aus einem HTML-Code für das Layout, einem SCSS-Code für das Design, einem Coffee-script für die interaktiven Werte und aus einem kleinen Ruby-script, das Daten für die interaktiven Werte zur Verfügung stellt.
Man kann also „problemlos“ seine eigenen Kacheln schreiben, sofern man des Ruby mächtig ist und auch versteht wie eine Kachel aufgebaut ist.
Für diejenigen unter uns, die es nicht beherrschen, mich eingeschlossen, gibt es im Internet eine breite Palette an bereits fertigen Kacheln zum Downloaden, die wiederum individuell mit ein paar Handgriffen angepasst werden können.
Screenshot
Ein gutes Beispiel für ein erzeugtes Dashboard findet ihr hier.
Gut zu sehen bei diesem Beispiel sind die unterschiedlichen Methoden seine Daten zu verarbeiten und zu visualisieren, aber auch, dass ein solches Dashboard doch ein Blickfang ist und man so noch schneller auf Probleme und Fehler reagieren kann, als sowieso schon.