Icinga 2 – Monitoring automatisiert mit Puppet Teil 4: Konfiguration I

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

Im ersten Teil zur Konfiguration von Objekten, die überwacht werden sollen, widmen wir statischen Dateien, die nicht von Define Resources des Moduls verwaltet werden. Zuerst beschäftigen wir uns jedoch mit dem Parameter confd der Main-Class icinga2. Als Werte werden die Boolean-Werte true und false akzeptiert oder auch eine Pfadangabe. Beim Defaultwert true wird das Verzeichnis /etc/icinga2/conf.d rekursiv in die Konfiguration in /etc/icinga2/icinga2.conf eingebunden. Bei der Verwendung von false entfällt diese Eintrag ersatzlos, hilfreich beim Konfigurieren von verteilten Szenarien der Überwachung.

class { '::icinga2':
  confd => '/etc/icinga2/local.d',
}

Die Angabe eines Pfades, wird das entsprechende Verzeichnis rekursiv als Konfiguration eingelesen. Um die Existenz müssen wir uns jedoch selber kümmern. In diesem Beispiel kopieren wir einmalig die im Paket mitgelieferte Beispielkonfiguration, als Grundlage für weitere Konfigurationen.

file { '/etc/icinga2/local.d':
  ensure  => directory,
  owner   => 'icinga',
  group   => 'icinga',
  mode    => '0750',
  recurse => true,
  replace => false,
  source  => '/etc/icinga2/conf.d',
  tag     => 'icinga2::config::file',
}

Damit diese File- oder Concat-Resources im Zusammenhang mit den anderen Resources in der korrekten Reihenfolge abgearbeitet werden ist das Tag icinga2::config::file von entscheidender Bedeutung. Handelt es sich bei der File-Resource nicht um ein Verzeichnis, wird automatisch ein Reload von icinga2 veranlasst. Letzteres kann unterdrückt werden, indem in der Main-Class das Verwalten des Services ausgeschaltet (manage_service => false) wird, daraus folgt aber, dass man den Service gesondert selbst managen muss.

file { '/etc/icinga2/local.d/my_hosts.conf':
  ensure => file,
  owner  => 'icinga',
  group  => 'icinga',
  mode   => '0640',
  source => 'puppet:///modules/profile/icinga2/my_hosts.conf',
  tag    => 'icinga2::config::file',
}

Das selbe Vorgehen kann analog auch mit einer Concat-Resource aus dem Modul gleichen Namens benutzt werden.

Lennart Betz
Lennart Betz
Senior Consultant

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.

Puppet Hash Injection

forge-logoFolgende Ausgangssituation, wir wollen eine Konfigurationsdatei zeilenweise mit beliebigen Optionen und den zugehörigen Werten verwalten. Hierzu benutzen wir eine Defined Resource, um jeweils einen Eintrag zu konfiguration:

define config::setting(
  $option = $title,
  $value,
) {
  file_line { "config::setting::${option}":
    line => "${option} = ${value}",
    ...
}

Nun möchten wir jedoch aus einer Klasse heraus, einen einfachen Hash zur Deklaration verwenden und nicht einen Hash of Hashes.

class { 'config':
  options => { 'opt1' => 'alpha', 'opt2' => 'beta' },
}

Das Problem ist nun, dass wir aus options einen Hash der folgenden Form machen müssen, um mit create_resources, opt1 und opt2 anlegen zu können.

{ 'opt1' => { 'value' => 'alpha' },
  'opt2' => { 'value' => 'beta' },
}

Ruby bietet für Hashes eine Methode inject, die wir innerhalb eines inline_templates anwenden. Die inline_template Funktion liefert jedoch nur Strings zurück und keinen Hash. Deshalb geben wir den String in YAML zurück, den wir abschließend mit der im Module puppetlabs-stdlib enthaltenen Funktion parseyaml wieder in einen Hash der geforderten Form umwandeln.

class config(
  $options = {},
) {
  create_resources('config::setting',
    parseyaml(inline_template(
      '<%= @options.inject({}) {|h, (x,y)| h[x] = {"option" => x, "value" => y}; h}.to_yaml %>'))
  )
}
Lennart Betz
Lennart Betz
Senior Consultant

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.

Neue Webinar-Termine und Änderung zum Webinar am 26. Juni

Es ist wieder soweit – die nächste Runde von Webinaren ist jetzt online! Vorab gibt es meinerseits noch eine kleine Planänderung bzgl. des Webinars am 26. Juni 2014. Anstatt des Themas “inGraph: Neues Webfrontend für Graphite“, werden wir das Thema “Foreman: OpenNebula orchestrieren” behandeln.
Das Graphing-Webinar werden wir voraussichtlich gegen Ende des Jahres mit Icinga-Web 2 durchführen.
In den anderen geplanten Webinaren werden wir uns schwerpunktmäßig mit Icinga 2 beschäftigen.
Übrigens: Der Release ist heute!
Hier nochmal eine kurze Auflistung der nächsten Themen:

Titel Zeitraum
Foreman: OpenNebula orchestrieren 26. Juni 2014 – 10:30 Uhr
Icinga 2: Enterprise Monitoring der nächsten Generation 22. Juli 2014 – 10:30 Uhr
Icinga 2: Migration von Nagios oder Icinga 1.x leicht gemacht 02. September 2014 – 10:30 Uhr
Icinga 2: Integrierte Hochverfügbarkeit 07. Oktober 2014 – 10:30 Uhr

Einige weitere Themen für mögliche Webinare sind aktuell noch in Planung und wir werden natürlich zeitnah informieren, sobald diese konkret feststehen. Wer in der Sommerpause lust auf Webinare hat, kann natürlich gerne in unserem Webinar-Archiv vorbeischauen und sich bereits gehaltene Vorträge anschauen.
Bis dann!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Icinga 2 Konfiguration – Lust auf mehr?

In der Icinga 2 Entwicklung wurden in den letzten Wochen einige Testrunden mit der Konfiguration gedreht, und festgestellt, dass hier noch Verbesserungspotienzial besteht. In den Releases 0.0.9 und 0.0.10 sind diese Änderungen drinnen – offen ist noch die Anpassung des LConf Exports. Ich empfehle zum Testen von Icinga 2 nach wie vor die Snapshot Pakete, die den aktuellen Entwicklungsstand wiederspiegeln (Hintergrund: Manchmal treten Bugs auf, wie gestern Abend, als ich mir das untenstehende Szenario angesehen habe – Fix ist im Git next).
Eine der Fragen zum Thema Konfiguration ist mit Sicherheit folgendes Szenario:

  • Host www.netways.de wird in einer CMDB / Puppet / etc mit Custom Attributes ausgestattet, beispielsweise sla = “24×7 for everyone”
  • Unabhängig von diesem Beispiel wird dieses Attribut auch für SLA Reporting verwendet
  • Zusätzlich soll dieser Host noch in die Hostgruppe “sla-24×7” zur besseren Visualisierung im Webinterface
  • Dieser Host soll einen passiven Service “sla-report” zugewiesen bekommen, aber nur dann, wenn sich dieser in der Hostgruppe “sla-24×7” befindet
  • Alle Services die diesem Host in der Hostgruppe “sla-24×7” zugeordnet worden sind, sollen eine Notifizierung erhalten.

Die Konfiguration dazu ist relativ kurz und sehr modular erweiterbar – etwa wenn man neue Hosts mit dem Custom Attribut “sla” und dem Muster “24×7*” anlegen würde.

object Host "www.netways.de" {
  import "generic-host"
  address = "91.198.2.92"
  vars.sla = "24x7 for everyone"
}
object HostGroup "sla-24x7" {
  display_name = "Hosts with SLA 24x7"
  assign where match("24x7*", host.vars.sla)
}
apply Service "sla-report-24x7" {
  import "generic-service"
  check_command = "dummy"
  enable_active_checks = false
  vars.dummy_text = "SLA Report 24x7"
  assign where "sla-24x7" in host.groups
}
object User "net-admin" {
  import "generic-user"
  display_name = "NETWAYS Admin"
}
apply Notification "mail-24x7" to Service {
  import "mail-service-notification"
  period = "24x7"
  users = [ "net-admin" ]
  assign where "sla-24x7" in host.groups
}

Nachdem man diese Konfiguration in Icinga 2 geladen hat, sieht das ganze in Icinga Web 2 dann so aus 🙂
icingaweb2_hostgroup_sla-24x7 icingaweb2_host_sla-24x7
icingaweb2_host_services_sla-24x7 icingaweb2_host_services_sla-report_sla-24x7
Wers nun nicht mehr erwarten kann, endlich tagtäglich mit Icinga (Web) 2 zu arbeiten, hat gefühlte 3 Möglichkeiten – selbst mit Vagrant spielen, bei uns bewerben oder die Kollegen aus Sales anschreiben 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler 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 und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

NETWAYS startet mit 3 Webinaren in 2014!

Auch 2014 ist NETWAYS wieder aktiv mit Webinaren vertreten. Starten werden wir Mitte Februar 2014, um einen Vorgeschmack auf die CeBIT zu ermöglichen.
Aktuelle Themen sind:

Logstash Open Source Log-Management
20. Februar 2014 – 10:30 Uhr
Icinga Web 2 Icinga Web in neuem Design
25. Februar 2014 – 10:30 Uh
Icinga 2 Entwicklungsstand 2014
05. März 2014 – 10:30 Uhr

Logstash
Ziel der Webinare ist es, unter anderem das Thema Logstash weiter zu vertiefen. Hierbei handelt es sich um eine schlanke Open Source Lösung, welche es ermöglicht Logs von hunderten von Systemen zu erfassen und in einem Webfrontend mit wenigen Klicks auszuwerten. Die Skalierbarkeit spielt hierbei ebenfalls eine entscheidende Rolle, da durch die schlanke Architektur das Setup auf mehrere Komponenten aufgeteilt werden kann.
Das Webinar hierzu findet am 20. Februar 2014 um 10:30 Uhr statt. Zur Registrierung.
Natürlich darf auch im neuen Jahr Icinga 2 nicht fehlen. Hierzu sind gleich zwei Webinare geplant.
Icinga Web 2
Zuerst wollen wir natürlich das neue und verbesserte Icinga Web 2 vorstellen, welches nicht nur in der Performance deutlich optimiert wurde, sondern auch ein komplett neues Design bekommt, um noch intuitiver zu werden. Weitere Infos gibt es auf unsere Webinarseite und während des Webinars.
Dieses findet am 25. Februar 2014 um 10:30 Uhr statt. Zur Registrierung.
Icinga 2
Als letzten Punkt wollen wir vor der CeBIT noch den aktuellen Entwicklungsstand zu Icinga 2 zeigen und auf alle bisher eingebauten Änderungen eingehen. Anhand einer Demo veranschaulichen wir dann die Unterschiede zu Nagios / Icinga und die Neuheiten von Icinga 2. Zum Schluss gibt es dann noch einen Ausblick auf den nächsten Milestone mit Version 0.0.8.
Das Webinar findet am 05. März 2014 um 10:30 Uhr statt. Zur Registrierung.
Wer unsere bisherigen Webinare verpasst hat, hat die Chance sich über unseren YouTube-Channel alle Webinar-Videos anzusehen. Eine detaillierte Übersicht findet sich inklusive der Slides in unserem Webinar-Archiv.
Wir freuen uns wieder auf eine rege Teilnahme!
Übrigens: Wer eine persönliche Beratung wünscht, kann gerne mit uns Kontakt aufnehmen.
Cebit BlogAlternantiv bietet sich natürlich auch ein Besuch auf unserem CeBIT Stand an. Vertreten sind wir, wie jedes Jahr, im Open Source Park. Diesmal in Halle 6, an Stand E16 (310). Um uns schneller zu finden, gibt es natürlich auch eine Wegbeschreibung.

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Icinga-Configmanagement mit Puppet

Puppet ist sehr mächtig und so gut wie grenzenlos erweiterbar. Im Zusammenhang mit Icinga tritt dann früher oder später die Frage auf ob sich diese beiden “Welten” auch miteinander vereinen lassen. Die Antwort darauf ist kurz: “Ja!”.
Der Teufel steckt hier natürlich im Detail. Über die sog. Hauptresourcen bietet Puppet in der Standardinstallation bereits vielfältige Möglichkeiten zur Verwaltung von Monitoringlösungen an. So lassen sich schon mit “file”, “package”, “service” u.a. sehr viele Anwendungszwecke abdecken. Für das Konfigurationsmanagement von Icinga geht das mit zusätzlichen Resourcen wie z.B. “nagios_host” oder “nagios_service” aber noch durchaus eleganter, die Zauberformel heißt hier: Exported Resources.
Mit Exported Resources ist es unter Puppet möglich gesammelte Daten von bestimmten Nodes auf anderen Nodes auszugeben, also dort zu exportieren. Das bedeutet das definierte Daten von bestimmten Hosts, wie z.B. die IP-Adresse, durch den Puppetmaster in einer zentralen Datenbank (PuppetDB) gespeichert werden und auf anderen Hosts gesammelt weiterverarbeitet werden können.
Hier ein Beispiel eines Puppetcodes wie das Einsammeln von Daten zum Erstellen der Icinga-Hostkonfiguration aussehen könnte:

@@nagios_host { "$fqdn":
     ensure => "present",
     alias => "$hostname",
     address => "$ipaddress",
     max_check_attempts => "3",
     use => "generic-host",
}

Wenn einem Node diese exportierte Resource zugewiesen ist, werden die darin enthaltenen Variablen beim Puppetlauf durch hostspezifische Inhalte (sog. Facts) ersetzt und in der zentralen Datenbank des Puppetmasters abgespeichert. In diesem Fall sind das also Full Qualified Domain Name ($fqdn), Hostname ($hostname) und die primäre IP-Adresse ($ipaddress).
Der folgende Puppetcode sorgt dann dafür das die zuvor gesammelten Daten in einer gemeinsamen Konfigurationsdatei auf dem Icingamaster ausgegeben werden:

Nagios_host <<| |>>

Der Eintrag in der Konfigurationsdatei auf dem Icingamaster würde unter Verwendung des vorhergehenden Codes dann für einen Host nach dem Export beispielhaft so aussehen:

define host {
     host_name                      puppetclient01.localdomain
     address                        192.168.56.11
     use                            generic-host
     max_check_attempts             3
     alias                          puppetclient01
}

Natürlich können neben Hosts im Zusammenhang mit Icinga noch weitere Resourcen für Services, Kontakte, Kontaktgruppen, uvm. verwendet werden. Auch bieten die einzelnen Resourcen viele andere Parameter für das Feintuning an. Mit Puppet-Bordmitteln ist es außerdem möglich Berechtigungen und Abhängigkeiten zu steuern, sodass z.B. der Eintrag zum Laden der neuen Konfigurationsdatei in die “icinga.cfg” automatisch erfolgt und auch der Icinga-Dienst im Anschluss von alleine neu geladen wird.

Markus Waldmüller
Markus Waldmüller
Lead Senior Consultant

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Aufzeichnung des LConf-Webinars ist online!

lconf_logo
Die Aufzeichnung unseres gestern geführten Webinars steht ab sofort zum Ansehen auf YouTube bereit. Vielen Dank nochmal an alle Teilnehmer für die Aufmerksamkeit. Im Webinar wurden folgende Punkte durchgesprochen:

  • Kurzvorstellung NETWAYS
  • Einführung LDAP
  • Vorteile/Funktionen LConf mit LDAP

natürlich wurde dann noch ausführlich eine Live-Demo gezeigt.

 
Nicht vergessen: Nächste Woche führen wir ein Webinar zum Thema Puppet. Ein Blick in unser Webinar-Archiv lohnt sich, dort gibt es auch die Präsentationsfolien zum Download!

Georg Mimietz
Georg Mimietz
Lead Support Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

NETWAYS Webinar für das Nagios/Icinga Konfigurationstool LConf

lconf_logo
Neben dem Bearbeiten von Nagios/Icinga Konfigurationsdateien über die Command-Line, gibt es noch Web-basierte Lösungen, welche die Konfiguration deutlich vereinfachen.
 
Eines dieser Tools ist der LConf. Ein aus dem Audi Projekt entstandenes Tool, welches die Nagios-Konfiguration über eine LDAP Struktur abbildet und an Nagios/Icinga zurück exportieren kann.
In diesem Webinar, werden wir näher auf die Möglichkeiten, die Vererbungslogik sowie den daraus resultierenden Vorteil eingehen.
Die Registrierung erfolgt wie immer über unser Webinar Center. Das Webinar startet am Mittwoch 09. Oktober um 14 Uhr.
Wir freuen uns auf eine rege Teilnahme!
Übrigens: nächste Woche Donnerstag (17.10.2013) halten wir ein Webinar über Puppet.

Georg Mimietz
Georg Mimietz
Lead Support Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Schneller, schöner, besser: LConf 1.3


Wer sich unsere Software gerne tippfrisch aus den git Repositories zieht hat es vielleicht Bemerkt: In den letzten Monaten hat sich bei LConf, unserem LDAP-basierten Icinga/Nagios® Konfigurationstool einiges getan – sowohl im Backend als auch im Frontend. Heute freue ich mich, nach langer Arbeit die RC Version 1.3.0. bekanntgeben zu dürfen.
Alles unter Kontrolle – auch bei großen Setups: 
LConf erlaubt es dem Admin, sein Icinga (natürlich auch Nagios®) Setup grafisch auf einem LDAP Server zu verwalten und sich aus diesem Baum die Monitoringkonfiguration zu exportieren. Durch die Baumstruktur, Aliase und Vererbung lassen sich dabei auch sehr große Monitoring setups bequem und übersichtlich verwalten – und das ohne an ein bestimmtes Frontend zur Datenverwaltung gebunden zu sein.
LConf besteht dabei aus zwei unterschiedlichen Projekten:

  • Einmal dem eigentlichen LConf CLI-Tool, das Icinga Konfigurationen aus dem LDAP Baum erstellen und bestehende Konfigurationen in den LDAP Baum Importieren kann. Auch verteilte Setups können mit LConf erstellt und verwaltet werden. Die Verteilung der einzelnen Konfigurationen auf die Satelliten übernimmt dabei der Exporter selbst.
  • Und zusätzlich unserem (optionalen) Icinga-Web Modul, für alle die es noch bequemer wollen. LConf lässt sich mit zwar mit jedem beliebigen LDAP Editor (oder auch programmatisch von der Kommandozeile aus) bedienen, jedoch bietet das Icinga-Web Frontend einige LConf-spezifische Features, die einem die Verwaltung noch einfacher machen (z.B. besondere Suchfunktionen, Operationen über Verbindungen hinweg, Export der Konfiguration vom Frontend aus, etc. ). Zusätzlich gibt es noch LConf-Web – eine standalone Version die keine vorherige Icinga-Web Installation benötigt.

Das Frontend: Spezifische Dialoge für alle Objekttypen
Die auffälligste Neuerung in der Version 1.3 sind ( neben einer Menge Bugfixes) zahlreiche objektspezifische Dialoge, die einem bei der Konfiguration unterstützen. Jedes LConf spezifische Objekt hat jetzt eine eigene Eingabemaske, die einem bei der Arbeit unterstützt (wer lieber direkt mit den LDAP Attributen arbeitet, kann das jedoch immer noch).
Hier spare ich mir die Worte und lasse einige der neuen Dialoge für sich sprechen:
         
Zusätzlich gibt es natürlich die bewährten Features: Aliaserstellung/Aktualisierung, einfaches Arbeiten mit Drag&Drop, serverübergreifende Operationen, Export aus der Oberfläche, bequeme Filter- und Suchfunktionen, uvm.
Das Modul samt Doku und Bugtracker ist wie immer unter netways.org zu finden. Die Standalone Version vom LConf-Web ist derzeit noch in Bearbeitung, folgt aber in den nächsten Tagen.
Das Backend: Schneller und aufgeräumt
Im Backend hat Tobias zahlreichen Bugs den Garaus gemacht und nebenbei viel von der Codebasis aufgeräumt und umgeschrieben. Das Ergebnis kann sich sehen lassen: Neben kosmetischen Änderungen bietet Version 1.3 einen viel schnelleren Export und jetzt auch die Möglichkeit, Templates in die Vererbung mit einzubeziehen.
Obwohl letzteres wohl eines der gefragtesten Features im LConf ist, beeinflusst es doch das Ergebnis des Exportes stark. Aus diesem Grund ist das Feature standardmäßig Deaktiviert und die 1.3. Version als RC Version gekennzeichnet.
Das heisst: Die  Version ist zwar stabil, kann durch das ggf. andere Verhalten jedoch ein anderes Ergebnis als die Version 1.2 im Export liefern, sollte man das Vererbungsfeature Scharf schalten. Das sollte aber nicht vom Herunterladen und Verwenden abhalten (eher ermutigen!) – ein Blick in die Dokumentation schadet dabei aber nie.