Icinga 2 Buch Reloaded

Heute mal ein Blogpost in eigener Sache. In wenigen Tagen werden wir das überarbeitete Icinga 2 Buch fertiggestellt haben. Es muss dann noch redigiert und gedruckt werden, so dass es dann hoffentlich Mitte des Jahres erhältlich sein wird. Der Umfang hat sich von 320 Seiten auf 550 deutlich erhöht. Neu hinzugekommen sind z.B. folgende Kapitel:

  • Director (ca. 40 Seiten)
    • Installation
    • alle zu konfigurierende Objekte
    • Datenfelder und Datenlisten
    • Best Practice
    • Automation
  • Icinga 2 REST-API (ca. 30 Seiten)
    • Abfragen, Actions, Event Streams
    • Vorstellung einer Bibliothek für Ruby
    • Dashing als Anwendung
  • Hochverfügbarkeit (ca. 20 Seiten)
    • Thematisierung für Icinga 2
    • Abhandlung weiterer Komponenten wie Icinga Web 2, Datenbank, etc.

Auch sind nahezu alle Kapitel von uns überarbeitet worden, viele sogar komplett neugeschrieben. So beschäftigen wir uns auf über 60 Seiten mit dem Thema Graphing, insbesondere mit Graphite. Aber auch PNP4Nagios, InfluxDB und Grafana werden besprochen wie sie mit Icinga zu integrieren sind. Icinga Web 2 wird nun in aller Ausführlichkeit auf 50 Seiten vorgestellt und behandelt. Natürlich wurden neben Business Process (ca. 15 Seiten) inbesondere das Kapitel Logmanagement (ca. 20 Seiten), um neue Komponenten wie Icinga Beat erweitert. Das Rückgrat des Buches bilden aber weiterhin Überwachung mit Icinga 2, besonders verteilte Überwachung und die Integration und Verwendung von Plugins.

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 7: “Friss oder stirb” der Variablen-Scope

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

Aus der Dokumentation kann man entnehmen das Objekte und Funktionen ihren eigene Variablen-Scope besitzen und nicht ohne weiteres auf Variablen eines “übergelagerten Scopes” zu greifen dürfen. Sollen z.B. Objekte über eine Schleife erzeugt werden, die sich nur maginal voneinander unterscheiden, können Variablen an diese bzw. dessen Scope via use gegeben werden.

template CheckCommand "by_ssh_base" {
  import "by_ssh"
  vars.by_ssh_plugindir = PluginDir
}

var cmdlist = [ "load", ""ntp_time", "yum" ]

for (cmd in cmdlist) {
  object CheckCommand "by_ssh_" + cmd use(cmd) {
    import cmd
    vars.by_ssh_arguments = arguments
    arguments = null
    vars.by_ssh_command = "$by_ssh_plugindir$/check_" + cmd
    import "by_ssh_base"
  }
}

Gleiches Verfahren lässt sich auch für das Erzeugen von Services über eine Schleife anwenden. Hier soll sich nun jedoch die Service-Bezeichnung vom verwendenten Check-Command unterscheiden und es kommt kein Array zum Einsatz, sondern ein Dictionary. Das folgende Beispiel ist allerdings für Commands, die via command_endpoint auf einer anderen Icinga-2-Instanz aufgerufen werden.

var srvlist = {
        "load" = "load"
        "time" = "ntp_time"
        "updates" = "yum"
}

for (srv => cmd in srvlist) {
  apply Service srv use(cmd) {
    import "generic-service"
    check_command = cmd
    command_endpoint = host.name
    assign where host.vars.os == "Linux"
    ignore where host.vars.noagent
  }
}

Werden im apply-Block mehrere Variablen, z.B. im obigen Beispiel auch srv, kann use durch Komma getrennt mehrere Variablen “weiter reichen”.

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 8: Integration von Icinga Web 2

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

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.

Die Unterlagen zum neuen Infrastructure for Puppet Training sind da!

Heute geben wir bekannt, dass nach Veröffentlichung der Schulungsunterlagen unserer Foreman Schulung und Fundamentals for Puppet, auch die Unterlagen zu unserem neuen Kurs Infrastructure for Puppet als Github Pages und im Source-Code zum nicht kommerziellen Gebrauch bereit stehen.

In den kommenden Monaten wird auch die Veröffentlichungen zu Advanced Puppet folgen. Einen Überblick über all unsere Unterlagen findet ihr unter training.netways.de.

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.

Training: Fundamentals for Puppet erweitert

Seit letzter Woche erst online und schon eine Erweiterung! Im neuen Release v1.1.1 sind nun zwei Definitionen zu Vagrant Boxen für den in der Schulung verwendeten Puppetmaster, sowie den CentOS-Agenten enthalten. Die Markup Datei Setup.md beschreibt die Voraussetzungen und wie die Virtuellen Maschinen benutzt werden können.

Die Boxen sind wie in der Schulung beschrieben via SSH erreichbar oder mittels vagrant ssh. Das Root-Passwort ist allerdings, wie bei Vagrant üblich, natürlich ‘vagrant’.

Fehlerreports sind wie immer herzlich willkommen und sollten via GitHub bei uns eingekippt werden. Aber auch sonstige Rückmeldung, die Schulung betreffend, sind herzlich willkommen, auch über Inhalt und Schwerpunkte.

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.