pixel
Seite wählen

Icinga 2 – Monitoring automatisiert mit Puppet Teil 6: Agenten

von | Jul 7, 2017 | Icinga, Linux, Puppet, Technology

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


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
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.
Mehr Beiträge zum Thema Icinga | Linux | Puppet | Technology

Icinga 2 mit InfluxDB 2

Die Überwachung von Infrastruktur und Software ist eine grundlegende Sache in der IT. Beim Monitoring spielt aber nicht nur der Status und die Benachrichtigung der zu überwachenden Objekte eine wesentliche Rolle, sondern auch die Aufbewahrung und die nachträgliche...

Jitsi Meetings mit Jibri aufzeichen

Trotz scheinbar eintretender Entspannung bei der aktuellen Corona-Krise ist Videoconferencing nicht mehr wegzudenken. Sei es durch das Umdenken bei den Arbeitgebern zu Homeofficeregeleungen oder bei international gewachsenen Teams. Alle müssen irgendwie miteinander...

Windows 11 Release und was ihr wissen müsst!

  Windows 11 steht vor der Tür! Seit dem 5. Oktober wird auf ausgewählten Systemen das Upgrade des neuen Betriebssystems angeboten. Ein neues Design sowie weitere Features erleichtern euch die Bedienung und Anpassung eures Systems. Ein Schelm wer die Ähnlichkeit...

Icinga for Windows v1.6.0 – Einfacher. Zentraler. Sicherer.

Die Kollegen von Icinga haben letzte Woche Icinga for Windows in Version v1.6.0 veröffentlicht. Auch wenn diese Version keine neuen Plugins für die Überwachung bietet, hat sich im Bereich des Icinga PowerShell Frameworks einiges getan. Dadurch ist die Lösung nicht nur...

Trainings

Web Services

Events

Series



Other posts in series: