NETWAYS Blog

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

von Lennart Betz | Mai 26, 2017 | DevOps, Icinga, Puppet

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

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.

Lies mehr von Lennart und triff unser Team

Icinga 2 – Monitoring automatisiert mit Puppet Teil 3: Plugins

von Lennart Betz | Mai 12, 2017 | Linux, Icinga, Puppet, Nagios

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

Senior Consultant

Lies mehr von Lennart und triff unser Team

Icinga 2 – Monitoring automatisiert mit Puppet Teil 2: Features

von Lennart Betz | Apr 28, 2017 | Icinga, Puppet

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

Senior Consultant

Lies mehr von Lennart und triff unser Team

Icinga 2 – Monitoring automatisiert mit Puppet Teil 1: Installation

von Lennart Betz | Mrz 31, 2017 | Icinga, Puppet, Betriebssysteme, Linux, Windows

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

Senior Consultant

Lies mehr von Lennart und triff unser Team