Replace spaces with tabs in Visual Studio 2017

Visual Studio has several source code edit settings. This defaults to 4 spaces and no tabs by default and is slightly different to what we use in Icinga 2. There we put focus on tabs in our code style.

Editing the Icinga 2 source code on Windows with Visual Studio requires adjusting the editor settings. Navigate into Tools > Options > Text Editor > C# and C++ and adjust the settings to “Keep tabs”.

I accidentally forgot to specify these settings for C# too, and had the problem that half of the Icinga 2 setup wizard code had 4 spaces instead of tabs. Luckily I’ve found this blog post which sheds some lights in the comments.

Hit Ctrl+H to open the replace search window. Tick the icon to use regular expressions and search for “((\t)*)([ ]{4})”. Add “\t” as replacement text.

Happy coding for Icinga 2 v2.8 – ready for OSMC 🙂

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach NĂŒrnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den sĂŒchtig machenden Dragee-Keksi. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im BĂŒro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nĂ€chsten LEGO-Projekt oder geniesst das schöne NĂŒrnberg. Oder - at an Icinga Camp near you 😉

Flapping in Icinga 2.8.0

The author viewing the code for the first time

Flapping detection is a feature many monitoring suites offer. It is mainly used to detect unfortunately chosen thresholds, but can also help in detecting network issues or similar. In most cases two thresholds are used, high and low. If the flapping value, which is the percentage of state changes over a set time, gets higher than the high threshold, it is considered flapping. It will then stay flapping until the value drops below the low threshold.

Naturally Icinga 2 had such a feature, just that it implemented a different approach and didn’t work. For 2.8.0 we decided it was time to finally fix flapping, so I went to investigate. As I said the flapping was working differently from Icinga 1, Shinken, etc. Instead of two thresholds there was just one, instead of one flapping value there were two and they change based on the time since the last check. Broken down it looks like this:

positive; //value for state changes
negate; //value for stable changes
FLAPPING_INTERVAL; //Compile time constant to smoothen the values

OnCheckResult() {
  if (positive + negative > FLAPPING_INTERVAL) {
    pct = (positive + negative - FLAPPING_INTERVAL) / FLAPPING_INTERVAL;
    positive -= pct * positive;
    negative -= pct * negative;
  }

  weight = now - timeOfLastCheck;
  if (stateChange)
    positive += weight;
  else
    negative += weight;
}

IsFlapping() {
  return 100 * positive / (negative + positive);
}

The idea was to have the two flapping values (positive & negative) increase one or the other with every checkresult. Positive for state changes and negative for results which were not state changes, by the time since the last check result. The first problem which arises here, while in most cases the check interval is relatively stable, after a prolonged Icinga outage one of the values could be extremely inflated. Another problem is the degradation of the result, in my tests it took 17 consecutive stable results for a flapping value to calm down.

After some tweaking here and there, I decided it would be wisest to go with the old and proven style Icinga 1 was using. Save the last 20 checkresults, count the state changes and divide them by 20. I took inspiration in the way Shinken handles flapping and added weight to the sate changes, with the most recent one having a value of 1.2 and the 20th (oldest) one of 0.8. The issue of possibly wasting memory on saving the state changes could be resolved by using one integer as a bit array. This way we are actually using slightly less memory now \o/

The above example would then have a value of 39.1%, flapping in the case of default thresholds. More details on the usage and calculation of flapping in Icinga 2 can be found in the documentation once version 2.8.0 is released.

Jean-Marcel Flach

Autor: Jean-Marcel Flach

Geboren und aufgewachsen in Bamberg, kam Jean (das "-Marcel" ist still) nach einem Ausflug an die Uni, als Azubi zu NETWAYS. Dort sitzt er seit 2014 im Icinga 2 core Entwicklungsteam.

Trick 42 mit dem Director – Jobs in Reihenfolge

Nachdem wir unseren Trick 17 mit dem Director veröffentlichten, schiebe ich Trick 42 direkt hinterher. Wie im Blogpost von Markus beschrieben, sind Schnittmengen aus mehreren Importquellen eine geniale Lösung um beispielsweise Hosts aus mehreren Quellen mit Informationen anzureichern. Konfiguriert man nun eine Vielzahl solcher Importquellen die fĂŒr die Schnittmenge dienen sollen, bekommt man evtl. im Ablauf gewisse Probleme mit der Reihenfolge.

Zur genauen ErklÀrung unser Ausgangsszenario:

  • CMDB 1: Quelle fĂŒr die Basisdaten des Hosts (Name, IP, FQDN, …)
  • CMDB 2: Quelle fĂŒr den OS-Type (CentOS, OpenSuSE, Debian, …)
  • CMDB 3: Quelle fĂŒr den Ansprechpartner (Hr. MĂŒller, Hr. Maier, …)

Damit die Hosts aus CMDB 1 angereichert erstellt (Import + Sync) werden können mĂŒssen zuerst CMDB 2 und CMDB 3 abgearbeitet werden. Logisch – wenn der OS-Type und der Ansprechpartner des Hosts dem Director nicht bekannt sind wird es mit Hilfe von Trick 17 auch nicht möglich sein den Host aus CMDB 1 mit Daten anzureichern.

HauptsĂ€chlich fĂ€llt dieses Problem beim initialen Import + Sync der Daten auf. Je nachdem wie oft sich eure Importquellen Ă€ndern kann dies “gar nicht schlimm” (Hr. MĂŒller ist fĂŒr den Server 3 Jahre zustĂ€ndig) oder auch “sehr unglĂŒcklich” (Ihr importiert die Kontaktdaten einer stĂ€ndig wechselnden Rufbereitschaft) sein.

FĂŒr den Fall das die Reihenfolge der Importquellen wichtig ist gibt es eine denkbar simple Lösung.

Ihr legt fĂŒr jeden Import und Sync einen Job im Director an…

 

…und notiert euch jeweils die ID des Director Jobs (die Zahl an der letzten Stelle der URL).

Mit Hilfe dieser ID könnt ihr nun die im Director konfigurierten Jobs von der Kommandozeile aus ausfĂŒhren. Der Job mit der ID 1 (Import Job fĂŒr CMDB1) kann mit dem Kommando “icingacli director jobs run 1” gestartet werden.

Am Ende bauen wir uns dazu noch ein kleines Skript:

#!/bin/bash

# set paths and vars
ICINGA_CLI=`which icingacli`
JOB_CMD=${ICINGA_CLI}" director jobs run"

# execute jobs
echo "import and sync..."

echo -e "\tcmdb1"
${JOB_CMD} 1
${JOB_CMD} 2

echo -e "\tcmdb2";
${JOB_CMD} 3
${JOB_CMD} 4

echo -e "\tcmdb3";
${JOB_CMD} 5
${JOB_CMD} 6

Und voilĂ  – wir haben die Imports und Syncs in einer Reihenfolge 🙂

Tobias Redel

Autor: Tobias Redel

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstĂŒtzt. Insgeheim fĂŒhrt er jedoch ein Doppelleben als Travel-Hacker, arbeitet an seiner dritten Millionen Euro (aus den ersten beiden ist nix geworden) und versucht die Weltherrschaft an sich zu reißen.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 7: Objekte aus Hiera erzeugen

This entry is part 7 of 7 in the series Icinga 2 Monitoring automatisiert mit Puppet

Vor einiger Zeit trat der Wunsch auf mit dem aktuellen Icinga-2-Modul fĂŒr Puppet beliebe Objekte aus Hiera heraus zu erzeugen. Zum Beispiel aus folgender Hiera-Datei sollen ein Host-Objekt und zwei Service-Objekte gebaut werden.

---
monitoring::object:
  'icinga2::object::host':
    centos7.localdomain:
      address: 127.0.0.1
      vars:
        os: Linux
  'icinga2::object::service':
    ping4:
      check_command: ping4
      apply: true
      assign: 
        - host.address
    ssh:
      check_command: ssh
      apply: true
      assign:
        - host.address && host.vars.os == Linux

In Puppet 4 lÀsst sich dies nun sehr einfach mit zwei Schleifen realisieren:

class { 'icinga2':
  manage_repo => true,
}

$default = lookup('monitoring::default')

lookup('monitoring::object').each |String $object_type, Hash $content| {
  $content.each |String $object_name, Hash $object_config| {
    ensure_resource(
      $object_type,
      $object_name,
      deep_merge($default[$type], $object_config))
  }
}

Hierbei sind sogar fĂŒr jeden Objekt-Type auch noch Defaults in Hiera gesetzt, z.B. in einer Datei common.yaml, die immer gelesen wird.

---
monitoring::default:
  'icinga2::object::host':
    import:
      - generic-host
    target: /etc/icinga2/conf.d/hosts.conf
  'icinga2::object::service':
    import:
      - generic-service
    target: /etc/icinga2/conf.d/services.conf

Dieses Verfahren ist mit dem selben Code auf Objekte mit allen möglichen Objekt-Typen erweiterbar. Passt man den Funktionsaufruf von lookup entsprechend an, kann auch ĂŒber die Hiera-Struktur gemerged werden.

Lennart Betz

Autor: Lennart Betz

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im BĂŒro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen VortrĂ€gen die seinesgleichen suchen.

Icinga 2 Best Practice Teil 6: Service-Checks auf Agenten schedulen

This entry is part 6 of 6 in the series Icinga 2 Best Practice

In Teil 1 dieser Blogserien beschĂ€ftigten wir uns mit Zonen, Agenten und wie man zentral angetriggert Plugins auf diesen Agenten ausfĂŒhrt. Nun im aktuellen Teil soll es darum gehen, das einplanen und ausfĂŒhren dem Agenten selbst zu ĂŒberlassen, damit werden auch wĂ€hrend eines Verbindungsausfalls weiter Daten gesammelt und spĂ€ter, wenn die Verbindung wieder besteht, nachtrĂ€glich ĂŒbertragen.

In dem hier folgenden verdeutlichen wir, wie dies zu konfigurieren ist, mit einem Beispiel von einer Zone master, einer globalen Zone global-templates und einer Zone zu einem Beispiel Agenten agent.example.org.

Die Zonen- und Endpoint-Definitionen des Agenten auf Seite des Masters mĂŒssen in einer Datei in der Master-Zone oder in zones.conf hinterlegt werden. Leider ist es hier nicht möglich die jeweiligen Host-, Zonen- und Endpoint-Objekte in einer Datei zusammen zufassen, da wir das Host-Objekt agent.example.org zum Agenten selbst synchronisieren mĂŒssen und diese Definition in der Agenten-Zone abgelegt sein muss, z.B. in der Datei zones.d/agent.example.org/agent.conf:

object Host "agent.example.org“ {
 import "generic-host"

 address = "10.0.10.42"
 zone = get_object(Zone, name).parent

 vars.os = "Linux“
}

Durch die Ablage an genau diesem Ort, wird das Objekt zum Agenten synchronisiert. Mit setzen des Attributes zone auf die eigene Parent-Zone sorgen wir jedoch wieder dafĂŒr, dass das Host-CheckCommand sowie alle an diesen Host gebundenen Services auf einem Endpoint der Parent-Zone ausgefĂŒhrt werden, hier die Zone master.

Damit wird der hostalive vom Master ausgefĂŒhrt, was gewĂŒnscht ist, da sonst der Host seine Erreichbarkeit von sich selbst aus testen wĂŒrde. D.h. alle Services, die auf den Agenten ĂŒber das Netzwerk zugreifen sollen, bleiben wie sie sind und wir mĂŒssen keine Anpassungen vornehmen. Ganz im Gegensatz zu Services, die ein Plugin lokal auf dem Agenten ausfĂŒhren sollen.

apply Service "load“ {
 import "generic-service“

 check_command = "load“
 if ( get_object(Zone, host.name) ) {
   zone = host.name
 }

 assign where host.vars.os == "Linux"
}

Auch Objekte vom Typ Service besitzen das Attribut zone mit dem wir hier nun die umgekehrten Weg beschreiten, existiert zum Host eine Zone selben Namens, wird die Zone zur AusfĂŒhrung des zugeordneten Plugins in die eigene Agenten-Zone verlegt.

Lennart Betz

Autor: Lennart Betz

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im BĂŒro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen VortrĂ€gen die seinesgleichen suchen.

Apply Service for im Icinga Director

Mit den Icinga 2 Apply Rules ist es spielend einfach möglich Services zu erstellen. Möchte man mehrere, gleiche Services erstellen (z. B. mehrere Port-Checks oder SNMP-Counteer) kommt Apply For zum Einsatz.

Im Zusammenhang mit dem Icinga Director erhalten wir ab und an Fragen zur Konfiguration von Apply For und sehr oft stellt sich dabei heraus das die ErklĂ€rung dieser Konfiguration per E-Mail oder Telefon sehr umstĂ€ndlich ist. Daher habe ich ein kleines Video fĂŒr euch vorbereitet.

 

Schönes Wochenende! 🙂

Tobias Redel

Autor: Tobias Redel

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstĂŒtzt. Insgeheim fĂŒhrt er jedoch ein Doppelleben als Travel-Hacker, arbeitet an seiner dritten Millionen Euro (aus den ersten beiden ist nix geworden) und versucht die Weltherrschaft an sich zu reißen.