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.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 2: Features

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
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.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 3: Plugins

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
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.

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.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 5: Konfiguration II

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

Heute werden wir uns die Define Resource icinga2::object::host zum konfigurieren eines Host-Objekts anschauen und auch Services via apply-Regeln an diesen Host binden.

::icinga2::object::host { 'NodeName':
  target  => '/etc/icinga2/example.d/my_hosts.conf',
  import  => [ 'generic-host' ],
  address => '127.0.0.1',
}

Generell kann bei Objekten mit target angegeben werden in welche Datei sie geschrieben werden. Auch lässt sich mit dem Parameter order Einfluss auf die Reihenfolge der einzelnen Objekte in der jeweiligen Datei nehmen. Der Defaultwert für Host-Objekte ist 50, möchte man nun ein weiteres Host-Objekt davor einfügen, ist bei diesem order auf einen Wert kleiner 50 zu setzen. Das funktioniert mit anderen Objekttypen auf die gleiche Weise. So werden z.B. Hostgruppen oder Services mit einer order von 55 bzw. 60 standardmäßig hinter Hosts einsortiert. Um das mittels import eingebundene Template generic-host vor dem Host in die Datei zu schreiben muss im folgenden Codebeispiel order explizit gesetzt werden, da auch ein Host-Template aus icinga2::object::host erzeugt wird und damit den Defaultwert 50 hat.

::icinga2::object::host { 'generic-host':
  template           => true,
  target             => '/etc/icinga2/example.d/my_hosts.conf',
  order              => '47',
  check_interval     => '1m',
  retry_interval     => 30,
  max_check_attempts => 3,
  check_command      => 'hostalive',
}

Der Titel, also der Name des Objektes, und Werte aller Attribute werden durch einen einfachen Parser ausgewertet. So werden Zahlen als solche erkannt, auch wenn sie in Puppet als String geschrieben sind. Das gilt auch für Zeitabstände wie 1h, 1m oder 1s. Auch Konstanten werden erkannt, dadurch wird NodeName als solche erkannt und in der Icinga-Konfiguration nicht gequotet als Konstanten geschrieben. Die erzeugte Konfigurationsdatei sieht dann wie folgt aus:

template Host "generic-host" {
  check_interval = 1m
  retry_interval = 30
  max_check_attempts = 3
  check_command = "hostalive"
}
object Host NodeName {
  import "generic-host"
  address = "127.0.0.1"
}

Ein einzelnes Service-Objekt wird äquivalent erstellt. Möchte man jedoch mittels Apply den Service mehreren Hosts zuordnen geht dies mit Puppet ebenfalls, der Parameter apply muss hier lediglich auch true gesetzt werden.

::icinga2::object::service { 'ping4':
  target        => '/etc/icinga2/example.d/services.conf',
  apply         => true,
  import        => [ 'generic-service' ],
  check_command => 'ping4',
  assign        => [ 'host.address' ],
}

Die Assign- bzw. Ignore-Ausdrücke werden über die Parameter assign bzw. ignore definiert. Die Werte müssen als Array zugewiesen werden. Aus den einzelnen Elemente werden jeweils Assign- bzw. Ignore-Ausdrücke erzeugt.

apply Service "ping4" to Host {
  import "generic-service"
  check_command = "ping4"
  assign where host.address
}

Custom-Attribute können in beliebiger Anzahl dem Parameter vars als Dictionary-Elemente zugewiesen werden. So erzeugt dieser zusätzlich Puppet-Code für das oben beschriebene Host-Objekt,

  vars => {
    os     => 'Linux',
    disks  => {
      'disk /' => {
        disk_partition => '/',
      },
    },

die folgenden Zeilen Icinga-Konfiguration:

  vars.os = "Linux"
  vars.disks["disk /"] = {
    disk_partition = "/"
  }

Der Parser kann auch komplexere Ausdrücke korrekt bearbeiten, wie in assign des folgenden Services ssh.

::icinga2::object::service { 'ssh':
  target        => '/etc/icinga2/example.d/services.conf',
  apply         => true,
  import        => [ 'generic-service' ],
  check_command => 'ssh',
  assign        => [ '(host.address || host.address6) && host.vars.os == Linux' ],
}

Attribute aus dem Host-Kontext wie auch die Operatoren werden korrekt erkannt, das Wort Linux ist nicht bekannt und damit gequotet dargestellt. Alle bekannten Wörter werden ohne Quotes geschrieben. Bekannte Wörter sind neben dem Objekt-Titel, alle Objekt-Attribute, Custom-Attribute, die Konstanten der Icinga-Instanz und eine in icinga2::params::globals definierte Liste.

apply Service "ssh" to Host {
  import "generic-service"
  check_command = "ssh"
  assign where (host.address || host.address6) && host.vars.os == "Linux"
}

Um nun via Puppet auch die folgende Konfiguration modellieren zu können,

apply Service for (fs => config in host.vars.disks) to Host {
  import "generic-service"
  check_command = "disk"
  vars = vars + config
}

Hierzu setzt man den Parameters apply auf einen String, der dem Zuweisungsteil einer Icinga-Foreach-Schleife für Services entspricht. Wichtig hier zu beachten ist, das fs und config nun auch bekannte Wörter sind und nicht gequotet werden. Nähme man anstatt fs z.B. disk, hätte das zur Folge, das die Zeile check_command, mit disk ohne Quotes geschrieben wird. Damit ist dann aber leider die Konfiguration nicht korrekt, die Validierung schlägt fehl und ein Neustart von Icinga wird nicht ausgeführt.

::icinga2::object::service { 'disk':
  target        => '/etc/icinga2/example.d/services.conf',
  apply         => 'fs => config in host.vars.disks',
  import        => [ 'generic-service' ],
  check_command => 'disk',
  vars          => 'vars + config',
}

Zu den bisher erschienen Artikel dieser Serie geht es hier.

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.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 6: Agenten

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

Nachdem Lennart sich bereits mit vielen Aspekte des Moduls befasst hat, will ich dieses Mal auf die Installation von Icinga 2 als Agenten eingehen. Neben einem generellen Einstieg mit zu beachtenden Konfigurationsoptionen, will ich hierbei auf die verschiedenen Möglichkeiten für die benötigten Zertifikate und Anbindung an die übergeordnete Zone eingehen.
Puppet-Icinga2
Die Installation und Feature-Konfiguration erfolgt wie Lennart dies in den ersten beiden Teilen der Serie beschrieben hat. Hierbei möchte ich beim Agent sicherstellen, dass keine lokale Konfiguration angezogen wird, da ich für die Verteilung der CheckCommands die Konfigurationssynchronisation von Icinga 2 nutzen möchte. Alternativ können diese zwar auch über Puppet verteilt werden, da ja auch die Plugins installiert werden müssen, aber in den meisten Umgebungen trenne ich an dieser Stelle Konfiguration der Monitoring-Infrastruktur von der eigentlichen Monitoring-Konfiguration. Der Start meines Agenten-Profils sieht also meist so aus:

  class { 'icinga2':
    confd       => false,
    manage_repo => true,
    features    => ['checker','mainlog'],
  }

(mehr …)

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

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

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

Icinga 2 – Monitoring automatisiert mit Puppet Teil 8: Integration von Icinga Web 2

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

Zum Ausklang des Jahres 2017 gibt es nochmals einen Post zum Thema Puppet und Icinga. Es geht heute um das Ziel, einen Icinga-Server inklusive Icinga Web 2 mittels Puppet zu managen. Die Icinga IDO sowie eine Datenbank zur Authentifizierung am Icinga Web 2 sind beide als MySQL-Datenbanken realisiert. Kommandos von Icinga Web 2 werden zum Icinga-Core via Icinga-2-API übertragen.
Als Plattform kommt ein CentOS 7 zum Einsatz. Damit muss für die aktuellen Pakete zum Icinga Web 2 ab Version 2.5.0 der verwendete Apache den PHP-Code mittels FastCGI ausführen.
Voraussetzung ist, dass die erforderlichen Puppet-Module icinga-icinga2, icinga-icingaweb2, puppetlabs-mysql und deren jeweilige Abhängigkeiten installiert sein müssen.
Beginnen wir zuerst mit einigen Variablen, die wir setzen, um im nachfolgenden Code keine Redundanzen zu haben. Wir setzen hier wie die Datenbanken für die IDO und fürs Icinga Web 2 heißen sollen und mit welchem Account jeweils darauf zugegriffen werden soll. Zusätzlich kommt noch der Name und das Passwort des Benutzers für die Icinga-2-API hinzu.

$ido_db_name = 'icinga'
$ido_db_user = 'icinga'
$ido_db_pass = 'icinga'
$api_user    = 'icingaweb2'
$api_pass    = '12e2ef553068b519'
$web_db_name = 'icingaweb2'
$web_db_user = 'icingaweb2'
$web_db_pass = 'icingaweb2'

Der nun folgende Code ist für Puppet 4 und neuer gedacht, da das Feature bzgl. Reihenfolge der Deklarationen in der Datei vorausgesetzt wird.
Für CentOS werden im Vorfeld zusätzliche Repositories benötigt, EPEL für die Plugins und SCL für das FastCGI PHP in der Version 7. Die Klasse icinga2 kümmert sich nicht nur um die Grundkonfiguration, sondern außerdem auch um die Einbindung des Icinga-Repos.

package { ['centos-release-scl', 'epel-release']:
  ensure => installed,
}
class { '::icinga2':
  manage_repo => true,
}

Als nächstes kümmern wir uns um den MySQL-Server und die von uns benötigten Datenbanken für die IDO und das Icinga Web 2. Beide laufen auf dem selben Host wie Icinga 2 und Icinga Web 2.

include ::mysql::server
mysql::db { $ido_db_name:
  user     => $ido_db_user,
  password => $ido_db_pass,
  host     => 'localhost',
  grant    => ['SELECT', 'INSERT', 'UPDATE', 'DELETE', 'DROP', 'CREATE VIEW', 'CREATE', 'ALTER', 'INDEX', 'EXECUTE'],
}
mysql::db { $web_db_name:
  user     => $web_db_user,
  password => $web_db_pass,
  host     => 'localhost',
  grant    => ['ALL'],
}

Nun können wir das IDO-Feature von Icinga 2 konfigurieren und aktivieren. Da es im Zusammenhang der Defined Resources für die Datenbank und das Feature zu einer Abhängigkeit kommt, die nicht via Top-Down-Dependency gelöst werden kann, muss hier mit require gearbeitet werden, damit die Datenbank vorher erzeugt wird.

class { '::icinga2::feature::idomysql':
  database      => $ido_db_name,
  user          => $ido_db_user,
  password      => $ido_db_pass,
  import_schema => true,
  require       => Mysql::Db[$ido_db_name],
}

Da Icinga Web 2 Kommandos mittels API an Icinga 2 senden soll, benötigen wir eine CA sowie die Aktivierung der Features API selbst. Die Certificate Authority soll eine von Icinga verwaltete CA sein. Das erfordert die Deklaration der Klasse icinga2::Pki::ca, die sich um genau dieses kümmert. Das Feature muss dann mit none für den Parameter pki werden, da sonst mit dem Default, die Puppet-Zertifikate verwendet werden und damit nicht mehr zur CA passen würden.
Zusätzlich erzeugen wir in einer Konfigurationsdatei noch einen API-User, der entsprechend eingeschränkte Rechte hat, um dann von Icinga Web 2 verwendet zu werden Kommandos zu übertragen.

class { '::icinga2::feature::api':
  pki => 'none',
}
include ::icinga2::pki::ca
::icinga2::object::apiuser { $api_user:
  ensure      => present,
  password    => $api_pass,
  permissions => [ 'status/query', 'actions/*', 'objects/modify/*', 'objects/query/*' ],
  target      => "/etc/icinga2/conf.d/api-users.conf",
}

Das Icinga-Repository ist schon aktiviert und wir ziehen die Installation der Pakete für Icinga Web 2 aus der Klasse icingaweb2 heraus. Damit profitieren wir davon, dass die abhängigen Pakete für PHP mit FastCGI zu diesem Zeitpunkt schon installiert werden und wir den Dienst rh-php71-php-fpm schon vor der Installation von icinga Web 2 mit allen benötigten PHP-Modulen starten können. Anders herum müsste dafür Sorge getragen werden die Dienst nach icingaweb2 nochmals für einen Neustart zu triggern.
Zusätzlich kommen noch die Standard-Plugins und der Apache aufs System. Bevor der Apache-Service deklariert wird, soll noch die erforderliche Apache-Konfiguration fürs Icinga Web 2 ins Konfigurationsverzeichnis des Webservers abgelegt werden. Dieses Beispiel für FastCGI ist erst im Module ab Version 2.0.1 von puppet-icingaweb2 enthalten.
TIPP: Die hier verwendete File-Resource mit der Quelle auf das Example aus dem offiziellen Modul sollte in Produktion nicht verwendet werden, sondern nur als Beispielvorlage für eine eigene Source dienen.

package { ['icingaweb2', 'icingacli', 'httpd', 'nagios-plugins-all']:
  ensure => installed,
}
file { '/etc/httpd/conf.d/icingaweb2.conf':
  ensure => file,
  source => 'puppet:///modules/icingaweb2/examples/apache2/for-mod_proxy_fcgi.conf',
  notify => Service['httpd'],
}
service { 'httpd':
  ensure => running,
  enable => true,
}

Das in Abhängigkeit vom Paket icingaweb2 installierte PHP mit dem FastCGI-Dienst kann nun konfiguriert und gestartet werden. Die hier verwendete file_line Resource kann bei bedarf durch eine mit Augeas gemanagte ersetzt werden.

file_line { 'php_date_time':
  path  => '/etc/opt/rh/rh-php71/php.ini',
  line  => 'date.timezone = Europe/Berlin',
  match => '^;*date.timezone',
}
~> service { 'rh-php71-php-fpm':
  ensure => running,
  enable => true,
}

Nachdem nun alle Voraussetzungen gegeben sind, kümmern wir uns abschließend um Icinga Web 2. Dies unterteilt sich in zwei Schritte. Icinga Web 2 ist als aller erstes ein Framework für Weboberflächen, die spezifischen Sachen fürs Monitoring ist in einem Modul implementiert. Da es viele weitere zusätzliche Module gibt, folgt auch das Puppet-Modul diesem Schema.

class { 'icingaweb2':
  manage_package => false,
  import_schema  => true,
  db_name        => $web_db_name,
  db_username    => $web_db_user,
  db_password    => $web_db_pass,
  require        => Mysql::Db[$web_db_name],
}

Zuerst wird das Framework mit dem zur Authentifizierung nötigen Datenbankzugriff konfiguriert und erst dann das Monitoring-Modul. Für dieses ist der IDO-Zugriff zwingend erforderlich und der Transportweg für die zusendenden Kommandos wird mittels API konfiguriert.

class { 'icingaweb2::module::monitoring':
  ido_host        => 'localhost',
  ido_db_name     => $ido_db_name,
  ido_db_username => $ido_db_user,
  ido_db_password => $ido_db_pass,
  commandtransports => {
    icinga2 => {
      transport => 'api',
      username  => $api_user,
      password  => $api_pass,
    }
  }
}

Bleibt als letzten allen unseren Bloglesern ein Frohes Neues Jahr zu wünschen!

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.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 9: Profile

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

Es ist nun nahzu schon ein Jahr her, dass in dieser Blogserie ein Artikel erschien. Zeit diese Serie fortzusetzen, auch weil wir für diese Jahr noch den Release 2.0.0 des Moduls puppet-icinga2 planen. In den kommenden Artikeln möchte ich sukezessive eine Profil-Klasse entwickeln, die einen Icinga-2-Server inklusive Plugins, IDO, Api und Icinga Web 2 installiert und konfiguriert. Als weitere Anforderung soll dies erfolgreich auf RedHat- wie auch Debian-Systemen durchgeführt werden können. Getestet wurde der Code auf Debian-9 (stretch) und CentOS-7.
Als erstes Teilziel für diesen Artikel soll Icinga 2 nebst Plugins enthalten sein. Bei den Plugins soll auch berücksichtig sein, dass es Plugins wie check_icmp oder check_dhcp gibt, die erweiterte Berechtigungen benötigen. So dürfen ICMP-Pakete oder auch DHCP-Request auf Unix nur im Ring-0 erzeugt werden. Auf RedHat wird dies über das Setzen des setuid-Bits erreicht, unter Debian mittels Posix Capabilities. Damit stellt uns Debian nicht vor größere Herausforderungen, die Plugins für RedHat-Systeme erfordern jedoch, dass der Aufrufende Benutzer Mitglied der Gruppe nagios sein muss. Um dies Anforderung zu realisieren, muss der Benutzer icinga der Gruppe nagios hinzugefügt werden, dass bei Puppet heißt, er ist via User-Resource zu verwalten. Am besten überlässt man das Anlegen vom Benutzer icinga weiterhin dem Paket icinga2, damit werden solche Eigenschaften wie UID oder das Home-Verzeichnis dem Paketverantwortlichen überlassen, d.h. aber auch die Paketinstallation muss vor der User-Resource und die wiederum vor der Klasse icinga2 abgearbeitet werden. Der Service, der von der Klasse verwaltet wird, darf erst gestartet werden, wenn der Benutzer schon korrekt konfiguriert ist. Andernfalls würde Icinga als Prozess weiterhin unter einem Benutzer laufen, der zum Startzeitpunkt von seiner Zugehörigkeit zur Gruppe nagios noch nichts wusste.
Zusätzlich muss auch die Gruppe nagios vor der User-Resource vorhanden sein, was sichergestellt ist, wenn vorher das Paket nagios-plugins-all installiert ist.

class profile::icinga2::server {
  case $::osfamily {
    'redhat': {
      require ::profile::repo::epel
      require ::profile::repo::icinga
      $manage_package = false
      $manage_repo    = false
      package { [ 'nagios-plugins-all', 'icinga2' ]:
        ensure => installed,
        before => User['icinga'],
      }
      user { 'icinga':
        groups => [ 'nagios' ],
        before => Class['icinga2']
      }
    } # RedHat
    'debian': {
      $manage_package = true
      $manage_repo    = true
      package { 'monitoring-plugins':
        ensure => installed,
      }
    } # Debian
    default: {
      fail("'Your operatingsystem ${::operatingsystem} is not supported.'")
    }
  } # case
  class { '::icinga2':
    manage_package => $manage_package,
    manage_repo    => $manage_repo,
  }
}

Die Plugins befinden sich bei RedHat in einem zusätzlichen Repository, dem EPEL-Repository, das in der dedizierten Profilklasse profile::repo::epel verwaltet wird. Gleiches gilt für das Icinga-Repo mit der Klasse profile::repo::icinga, was auf RedHat für die gesonderte Paketinstalltion vorhanden sein muss und damit nicht, wie unter Debian, der Klasse icinga2 überlassen werden kann.

class profile::repo::epel {
  yumrepo { 'epel':
    descr => "Extra Packages for Enterprise Linux ${::operatingsystemmajrelease} - \$basearch",
    mirrorlist => "https://mirrors.fedoraproject.org/metalink?repo=epel-${::operatingsystemmajrelease}&arch=\$basearch",
    failovermethod => 'priority',
    enabled => '1',
    gpgcheck => '1',
    gpgkey => "http://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-${::operatingsystemmajrelease}",
  }
}
class profile::repo::icinga {
  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',
  }
}
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.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 10: Profile Part II

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

In Weiterführung vom letzten Post dieser Serie, beschäftigen wir uns zuerst damit dem Icinga-Server eine CA hinzuzufügen. Dies erledigt die Deklaration der Klasse icinga2::pki::ca. Sie erzeugt auch noch gleich ein Zertifikat für den eigenen Server.
Das ist auch der Grund, warum im Folgenden der Parameter pki des Features API mit none belegt werden muss, da genau dies verhindert, dass nochmals versucht wird ein Zertifikat zu generieren. Dieser Wert für pki ist also nur sinnvoll für Hosts mit einer Icinga-2-CA.

class profile::icinga2::server {
  ...
  #
  # CA / API
  #
  include ::icinga2::pki::ca
  class { '::icinga2::feature::api':
    pki             => 'none',
    accept_commands => true,
  }

Als nächstes widmen wir uns dem Feature IDO, welches die IDO-DB befüllt, hier eine MySQL-Datenbank, die ebenfalls per Puppet verwaltet werden soll und sich auch dem gleichen Server befindet. Hierfür ist zusätzlich das MySQL-Puppetmodule erforderlich. Das Datenbank-Schema kann vom Icinga2-Modul automatisch angelegt werden. Hierfür ist dann zu den üblichen Berechtigungen auch CREATE für den Benutzer, den auch Icinga für den Zugriff verwendet, erforderlich, da auch dieser zum initalen Erzeugen der Tabellen vom Icinga2-Modul verwendet wird.
In Bezug auf die Reihenfolge der Abarbeitung unserer Ressourcen, muss nur dafür Sorge getragen werden, dass die Datenbank für die IDO vor dem IDO-Feature dran kommt.
Für den zu verwenden Benutzernamen, das zugehörige Passwort und den eigentlichen Datenbanknamen fügen wir der Profilklasse Parameter hinzu. Im Gegensatz zum Datenbank- und Benutzernamen, die beide als Default icinga2 gesetzt bekommen, ist das Passwort als Parameter vom Endbenutzer immer selbst anzugeben.

class profile::icinga2::server(
  String   $ido_db_pass,
  String   $ido_db_name  = 'icinga2',
  String   $ido_db_user  = 'icinga2',
) {
  case $::osfamily {
    'redhat': {
      ...
      package { [ 'nagios-plugins-all', 'icinga2', 'icinga2-ido-mysql' ]:
        ensure => installed,
        before => User['icinga'],
      }
      ...
    }
    ...
  }
  #
  # Icinga 2
  #
  class { '::icinga2':
    manage_package => $manage_package,
    manage_repo    => $manage_repo,
  }
  #
  # IDO database
  #
  include ::mysql::server
  mysql::db { $ido_db_name:
    user     => $ido_db_user,
    password => $ido_db_pass,
    host     => '127.0.0.1',
    grant    => ['SELECT', 'INSERT', 'UPDATE', 'DELETE', 'DROP', 'CREATE VIEW', 'CREATE', 'INDEX', 'EXECUTE', 'ALTER'],
    before   => Class['icinga2::feature::idomysql']
  }
  class{ '::icinga2::feature::idomysql':
    user          => $ido_db_user,
    password      => $ido_db_pass,
    database      => $ido_db_name,
    import_schema => true,
  }

Auf RedHat-Systemen musste, wie in vorherigen Teil zu sehen war, da Paketmanagement aus dem eigentlichen Icinga-Modul herausgezogen werden, um den Benutzer icinga zwischen Paketinstallation und Icinga-Klasse verwalten zu können. Das bezieht sich nun ebenfalls auf das Paket icinga2-ido-mysql, das für das IDO-Feature erforderlich ist. Debianbasierte Systeme sind hiervon nicht betroffen.

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.