Icinga 2 – Monitoring automatisiert mit Puppet Teil 1: Installation

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


Der erste Release vom Rewrite des Puppetmoduls zu Icinga 2 liegt nun auch schon einige Monate zurück und somit wird es Zeit sich im Zuge einer Blog-Serie genauer damit zu befassen. Zu beziehen ist das Module entweder über die Puppet Forge oder via GitHub.
Zu Beginn steht natürlich immer erstmal die “Installation” bzw. weil Puppet deklarativ arbeitet, die Beschreibung installiert zu sein. Schon hier zeigt sich das Modul flexibel und kann vom Benutzer angepasst benutzt werden. So greift Puppet bei einer einfachen Deklaration ohne Parameter auf die auf dem System konfigurierten Repositories zurück. Es bietet jedoch auch die Möglichkeit für die unterstützten Plattformen RedHat, Debian, Ubuntu und Suse, die automatisch Einbindung der offiziellen Icinga-Repositories auf packages.icinga.com.

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

Betreibt man selbst ein internes Repository, z.B. als Spiegel des offiziellen, muss dieses vor der Deklaration der Klasse ::icinga2 erfolgen. Beispielhaft hier für RedHat-Systeme:

yumrepo { 'ICINGA-release':
  descr => 'ICINGA (stable release for epel)',
  baseurl => 'http://packages.icinga.org/epel/$releasever/release/',
  failovermethod => 'priority',
  enabled => '1',
  gpgcheck => '1',
  gpgkey => 'http://packages.icinga.org/icinga.key',
}
->
class { '::icinga2': }

Ein Problem beim Einsatz in verteilten Umgebungen und vor allem durch die Benutzung von Icinga als Agent ist die Software-Verwaltung. So sollten keine Instanzen miteinander kommunizieren, die zwei Major Releases auseinander liegen, z.B. 2.6.x mit 2.5.x sollte noch ok sein, 2.6er mit 2.4.x und früher jedoch nicht. Besser ist jedoch die Benutzung ausschließlich von 2.6er Versionen. Setzt man hierfür kein Software-Management-Tool ein, kann Puppet helfen. Voraussetzung sollte jedoch ein Repository-Spiegel sein, den man nur zu gegebenen Zeitpunkten synchronisiert.

package { 'icinga2':
  ensure => latest,
}
->
class { '::icinga2':
  manage_package => false,
}

Damit wird bei jedem Puppetlauf dafür gesorgt, das die neuste Version installiert ist. Welche das ist, steuert man über den “händischen” Repo-Sync. Sind für einzelne Features zusätzliche Pakte erforderlich, müssen dann auch diese durch eigene Package-Resources verwaltet werden. Betroffen sind hier außer auf Windows oder FreeBSD die Features idomysql und idopgsql.
Auch das Handling des Icinga Services kann angeschaltet werden. Standardmäßig zieht jede Änderung an einer mit Puppet verwalteten Konfigurationsdatei einen Reload des icinga-Prozesses nach sich. Vor Version 1.2.0 von puppet-icinga2 wird allerdings noch ein Neustart ausgelöst. Für den Fall, dass lediglich zu bestimmten Zeiten eine neue Konfiguration eingelesen werden soll, kann man wie folgt vorgehen:

schedule { 'everyday':
  range  => '2 - 4',
  period => daily,
  repeat => 1,
}
class { '::icinga2':
  manage_service => false,
}
~>
service { 'icinga2':
  ensure => running,
  enable => true,
  schedule => 'everyday',
}

Zu bedenken ist hier nur der Nachteil, dass auch nur zwischen 2 und 4 nachts der Dienst wieder gestartet wird, falls er nicht laufen sollte. Aber dafür gibt es ja das Monitoring. Abschließend für heute kann nicht unerwähnt bleiben: Auch um benötigte Plugins darf sich der Benutzer selbst kümmern. Hierbei ist die Reihenfolge, ob erst die Plugins und dann Icinga oder umgekehrt, unerheblich.

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.

Weekly Snap: VMware & FreeBSD, End-to-End Monitoring & Headless

weekly snap31 March – 4 April started a new month with monitoring tips and fun galore, a how-to guide or two, as well as new hardware.
Eva started the week by counting 8 days to the OSDC and sharing Jan Gehring’s talk on “Orchestrating Servers with Rex” as Bernd peddled our last two tickets to the Berlin event.
He also released the ultimate check_netways plugin just in time for April 1st and offered video evidence that we are home to Germany’s most flexible salesman.
Johannes then gave a guide to installing VMware tools on a FreeBSD 6-8 guest while Christoph showed how to set up end-to-end monitoring with Watir WebDriver and Headless.
Christian continued the monitoring theme, reminding interested attendees to join our Icinga Web webinar and Georg announced newcomers to our hardware store: Braintower SMS Gateway S & L with workshops to boot.