Icinga 2 – Monitoring automatisiert mit Puppet Teil 6: Agenten

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.

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'],
  }

Als nächstes kommt dann das Feature API dran bei dem ich mich entscheiden muss, welche Option für die Zertifikate ich wähle. Die einfachste Option ist die Mitnutzung der Puppet-Zertifikate, da diese bereits vorhanden sein müssen, damit Puppet funktioniert. Dies ist allerdings nur eine Option, wenn denn die ganze Umgebung durch Puppet verwaltet wird. In diesem Fall sieht die Konfiguration des Features folgendermaßen aus.

  class { 'icinga2::feature::api':
    accept_config   => true,
    accept_commands => true,
    pki             => 'puppet',
    endpoints       => {},
    zones           => {},
  }

Hierbei habe ich das Akzeptieren von Kommandos und Konfiguration aus der übergeordneten Zone aktiviert und die Standardwerte für Endpoints und Zonen überschrieben, da ich diese in einem letzten Schritt machen möchte. Statt mit der Option puppet die CA des Konfigurationsmanagement mitzunutzen kann die eigene des Monitoringsystems mit der Option icinga genutzt werden. Diese erstellt dann mit den entsprechenden Kommandozeilen-Tools einen Zertifikatsrequest, holt sich das Zertifikat der CA und lässt ihr eigenes Zertifikat signieren. Hierfür muss allerdings der Verbindungsaufbau von Agent zu CA-Server (üblicherweise dem ersten Master) möglich sein. Zwar empfehle ich diese Richtung des Kommunikationsaufbaus üblicherweise, aber er ist nicht immer möglich und mit dem Satellitenkonzept ist eine direkte Kommunikation Agent zu Master sowieso nicht immer das Ziel. Zusätzlich zum CA-Server muss auch noch der Ticket-Salt bekannt gemacht werden, mit dem dann auf dem Puppet-Server das benötigte Ticket errechnet wird.

  class { 'icinga2::feature::api':
    accept_config   => true,
    accept_commands => true,
    pki             => 'icinga2',
    ca_host         => 'icinga-master01.localdomain',
    ticket_salt     => '9abf43bdb2134231b212b1253ff2ad',
    endpoints       => {},
    zones           => {},
  }

Da beide Optionen gewisse Voraussetzungen haben, die nicht immer zu erfüllen sind, gibt es noch die Option none. Dies heißt nicht, dass keine CA verwendet wird, sondern dass diese nicht durch Puppet verwaltet wird und stattdessen der Benutzer selbst diese erstellen und verteilen muss. Dies kann außerhalb von Puppet erfolgen, aber sinnvoller ist es meist zumindest die Verteilung mit Puppet zu steuern. Das Modul kann diese zwar auch in Form des Base64-codierten Strings verteilen, aber Dateien mit dem FQDN des Agents als Namen finde ich persönlich flexibler.

  class { 'icinga2::feature::api':
    accept_config   => true,
    accept_commands => true,
    pki             => 'none',
    endpoints       => {},
    zones           => {},
  }
  file { '/etc/icinga2/pki/ca.crt':
    ensure => file,
    owner  => 'icinga',
    group  => 'icinga',
    tag    => 'icinga2::config::file',
    source => 'puppet:///modules/icinga2/ssl_certs/ca.crt',
  }
  file { "/etc/icinga2/pki/$::fqdn.crt":
    ensure => file,
    owner  => 'icinga',
    group  => 'icinga',
    tag    => 'icinga2::config::file',
    source => "puppet:///modules/icinga2/ssl_certs/$::fqdn.crt",
  }
  file { "/etc/icinga2/pki/$::fqdn.key":
    ensure => file,
    owner  => 'icinga',
    group  => 'icinga',
    mode   => '0600',
    tag    => 'icinga2::config::file',
    source => "puppet:///modules/icinga2/ssl_certs/$::fqdn.key",
  }

Erfolgreich genutzt habe ich dies schon in einer Umgebung, in der die CA Teil des “Active Directories” sein sollte und es nur etwa 30 Linux-Systeme gab, aber auch schon bei dieser Größe empfiehlt es sich die Zertifikatserstellung zu automatisieren.
Damit wäre Icinga 2 nun zwar installiert und für die Netzwerkkommunikation vorbereitet, aber weiß noch nicht mit welchen Systemen es reden soll, denn hierfür benötigt es noch die Endpoint- und Zonen-Objekte. Die Standardwerte legen nur den lokalen Endpoint und Zone an ohne die übergeordnete Zone, weshalb ich diese bei der Installation oben bereits rausgenommen habe und stattdessen die Objekte selbstständig pflege. Die einfachste Option ist hierbei diese einfach manuell aufzulisten.

  icinga2::object::endpoint { $::fqdn:
    host => $::ipaddress,
  }
  icinga2::object::zone { $::fqdn:
    endpoints => [ $fqdn ],
    parent    => 'master',
  }
  icinga2::object::endpoint { 'icinga-master01.localdomain':
    host => '192.168.100.3',
  }
  icinga2::object::endpoint { 'icinga-master02.localdomain':
    host => '192.168.100.4',
  }
  icinga2::object::zone { 'master':
    endpoints => [ 'icinga-master01.localdomain', 'icinga-master02.localdomain' ],
  }
  icinga2::object::zone { 'linux-agents':
    global => true
  }

Die globale Zone ist hierbei für die Synchronisation der CheckCommands gedacht. Wie man sieht kann dies bei verteilten Umgebungen recht schnell kompliziert werden, so dass ich hierfür gerne exportierte Resourcen verwende. Dies sähe dann folgendermaßen auf der Agent-Seite aus, wobei die Zonen auf dem Master und den Satelliten mit entsprechenden Tags exportiert werden:

  icinga2::object::endpoint { $::fqdn:
    host => $::ipaddress,
  }
  icinga2::object::zone { $::fqdn:
    endpoints => [ $fqdn ],
    parent => $parent_zone,
  }
  Icinga2::Object::Endpoint <<| tag == "icinga2::endpoints::$parent_zone" |>>
  Icinga2::Object::Zone <<| tag == "icinga2::zone::$parent_zone" |>>  {
    parent => undef,
  }
  Icinga2::Object::Zone <<| title == 'agents-linux' |>>

Hiermit bräuchte der Agent nur noch eine Option parent_zone, welche entweder übergeben oder anhand von Namen oder Adressen ausgerechnet werden kann. Die Agenten könnten ihre Konfiguration nun natürlich auch exportieren und auf dem Master realisieren oder einfach im Direktor erstellt werden und schon lassen sich die Checks über die ganze Infrastruktur verteilen.

Dirk Götz

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

Read more from Dirk and meet the Team