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

This entry is part 4 of 4 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

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 – Monitoring automatisiert mit Puppet Teil 3: Plugins

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

Heute gehen wir der Frage nach wann und wie Plugins installiert werden sollten, was besonders wichtig bei Systemen mit icinga Benutzern zum Gegensatz nagios zu beachten ist. Auf z.B. RedHat-Systemen besteht das Problem, dass der Prozess Icinga 2 unter dem Benutzer icinga läuft, aber unteranderem das Plugin check_icmp oder auch check_dhcp nur vom Benutzer root oder einem Mitglied der Gruppe nagios mittels suid-Bit ausgeführt werden können.

# ls -l /usr/lib64/nagios/plugins/check_icmp
-rwsr-x---. 1 root nagios ... /usr/lib64/nagios/plugins/check_icmp

Das Ändern der Gruppenzugehörigkeit mit Puppet ist wenig hilfreich, da leider bei einem Update des Paketes nagios-plugins die alten Berechtigungen wieder hergestellt werden. Man könnte nun natürlich den Benutzer icinga und das Paket nagios-plugins explizit vor der Klasse icinga2 managen, verliert dann jedoch die Paketkontrolle über die uid und muss das Home-Directory, Shell und weitere Eigenschaften per Hand in Puppet entscheiden. Klarer ist die Methode genau diese Sachen dem Paket zu überlassen und erst danach icinga in die Gruppe nagios aufzunehmen.

yumrepo { 'icinga-stable-release':
  ...
}
->
package { [ 'icinga2', 'nagios-plugins' ]:
  ensure => installed,
}
->
user { 'icinga':
  groups => [ 'nagios' ],
}
->
class { '::icinga2':
  manage_package => false,
}

Um dieses Vorhaben umzusetzen ist es erforderlich die benötigten Repositories zuerst einzubinden, hier mit yumrepo angedeutet, dann die Pakete zu installieren, den Benutzer anzupassen und erst dann die Klasse icinga2 zu deklarieren.

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 5: Autosign von Zertifikatsanfragen in verteilten Umgebungen

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

Ein jeder kennt das Problem, im Unternehmensnetz gibt es unterschiedliche netzwerkbezogene Sicherheitszonen, die mittels Perimeter voneinander getrennt sind. Für das Monitoring bedeutet dies im Idealfall, man stellt in jeder dieser Zonen einen Icinga-Satelliten bereit, der die von ihm ermittelten Ergebnisse an eine zentrale Instanz weiter meldet, den Icinga-Master. Damit ist gewährleistet, was Firewall-Admins berechtigterweise verlangen, lediglich Punkt-zu-Punkt-Verbindungen zu erlauben. Auch die Richtung des Verbindungsaufbaus ist mit Icinga 2 wählbar.
Setzt man zusätzlich auch Icinga 2 in der Ausprägung Agent ein, benötigt dieser ein signiertes Zertifikat um mit seinem jeweiligen Satelliten oder direkt mit dem Master zu kommunizieren. Im letzten Fall entstehen hieraus keine Probleme. In der Regel wird die CA, in einer Umgebung mit mehreren Satelliten auf dem Master betrieben. Bei lediglich einem Satelliten könnte die CA auch auf genau diesem Satelliten laufen, was jedoch Sicherheitsbedenken hervorruft. Ein Zertifikat aus einer niedrigen Sicherheitszone könnte verwendet werden, um mit einer höheren zu kommunizieren. Gleiches gilt natürlich auch bei der Benutzung lediglich einer CA, aber die Netzwerksicherheit soll ja dieses Risiko Minimieren.
Bleibt das Problem auf einem neuinstallierten Agenten mittels Autosigning ein beglaubigtes Zertifikat zu erhalten. Hier kann eine eigene CA auf jedem Satelliten Abhilfe schaffen. Der jeweilige Agent benötigt nun nur eine Verbindung zu seinem Satelliten um einen Request zu senden und keine Kommunikation zum Master. Wie wird nun dieses genau bewerkstelligt?

  • Erstellen einer CA auf dem Satelliten
  • Der Satellit bekommt ein Zertifikat signiert von seiner eigene CA
  • Der Satellit benötigt sein eigenes RootCA-Zertifikat und das vom Master
  • Der Master bekommt umgekehrt ebenfalls das RootCA vom Satelliten
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 – Monitoring automatisiert mit Puppet Teil 2: Features

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

Heute steht der Blog um des Icinga Puppet-Modul ganz im Zeichen der Icinga-2-Features. Features lassen sich entweder über die main class aktivieren und via Hiera parametrisieren oder dediziert mittels einer eigenen Klasse deklarieren.

include ::mysql::server
include ::icinga2

mysql::db { 'icinga':
  user     => 'icinga',
  password => 'secret',
  host     => 'localhost',
  grant    => ['SELECT', 'INSERT', 'UPDATE', 'DELETE', 'DROP', 'CREATE VIEW', 'CREATE', 'INDEX', 'EXECUTE', 'ALTER'],
  before   => Class['::icinga2']
}

Da die Klasse icinga2 auch über einen Parameter features verfügt über den die angegeben Features aktiviert werden, kann auch dieser Parameter nach Hiera ausgelagert werden. Nachfolgend wird für die MySQL-IDO-Anbindung das Passwort gesetzt und veranlasst, dass erstmalig das DB-Schema importiert wird. Alle anderen Parameter für das Feature idomysql, sowie alle für mainlog und checker sind die entsprechenden Default-Werte.

---
icinga2::features:
  - checker
  - notification
  - mainlog
  - idomysql
icinga2::feature::idomysql::password: secret
icinga2::feature::idomysql::import_schema: true

Das selbe erreicht man ebenfalls unter Verwendung der direkten Deklaration:

class { '::icinga2::feature::idomysql':
  password      => 'secret',
  import_schema => true,
}

Etwas anders verhält es sich, wenn man die Feature checker, notification oder mainlog explizit deklarieren möchte. Da diese die standardmäßig aktivierten Features sind, muss das entsprechende Feature vorher deaktiviert werden bzw. nur die anderen im Parameter features angegeben werden:

class { '::icinga2':
  features => [ 'checker', 'notification' ],
}

class { '::icinga2::feature::mainlog':
  severity => 'notice',
}

Der Weg über die Konfiguration über Hiera ist da doch wirklich eleganter. Die Deklaration ist übersichtlich

include ::icinga2

und auch in Hiera ist nicht viel zu hinterlegen:

---
icinga2::feature::manilog::severity: notice
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.

Monitoring-Projekt bei der htp GmbH

Die htp GmbH ist ein Provider im Bereich Telefon und Internet im Großraum Hannover und Braunschweig für geschäfts- und Privatkunden. Seit einiger Zeit unterstützen wir htp bei der Migration auf Icinga 2. Im Zuge dieses Umzuges wurde die neue Monitoring-Plattform verteilt mit einem mehrstufigen Satellitenkonzept realisiert. Herzstück sind zwei Satelliten an zwei unterschiedlichen Standorten der eigene RZ-Umgebung. Die beiden zu HA zusammengeschalteten Icinga 2 Instanzen sind je mit einem Braintower SMS Gateway gekoppelt, die das Mail-Benachrichtigungssystem um den Versand von SMS erweitern.

Diese beiden Knoten, die an den Icinga Master inklusive Icinga Web 2 angeschlossen sind, dienen ihrerseits als Kommunikationspartner für weitere Icinga 2 Satelliten zur Überwachung eigner Systeme oder dedizierten Kundenumgebungen.

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.