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.

Paketstation

Mit FPM stellt Jordan Sissel, der führende Kopf hinter Logstash, ein Tool zur Verfügung mit dem man sehr einfach Pakete für die gängigsten Distributionen erstellen kann.
Für Effing Package Management (=FPM) muss Ruby und ein C-Compiler vorhanden sein:

# apt-get install ruby-dev gcc
# yum install ruby-devel gcc

Danach kann die eigentliche Installation des Ruby-Moduls erfolgen:

# gem install fpm

Als Beispiel für die Erstellung von Paketen mit FPM habe ich im Folgenden LConf Standalone Web gewählt, natürlich kann dies auch auf andere Softwareprodukte abgewandelt werden.
Zuerst muss bei LConf Web das Archiv mit dem Quellcode herunter geladen und entpackt werden, danach wechselt man wie gewohnt in das extrahierte Verzeichnis. Im Anschluss wird hier der configure-Befehl ausgeführt:

# ./configure --with-user=icinga --with-group=icinga

Bis zu diesem Zeitpunkt besteht noch kein Unterschied zum üblichen Installationsvorgang, erst bei make install unterscheidet sich der Aufruf. Statt die Dateien an den dafür vorgesehenen Stellen im Dateisystem abzulegen, leitet man sie mit dem DESTDIR-Parameter um:

# make install DESTDIR=/usr/local/src/lconf-web-1.4.0_installdir

Jetzt ist die Zeit von FPM gekommen, den hier kann nun das DESTDIR-Verzeichnis als Chroot verwendet und die darin enthaltene Verzeichnisstruktur “usr/local/lconf-web” beispielsweise in ein Debian-Paket integriert werden:

# fpm -s dir -t deb -n lconf-web -v 1.4.0 --deb-use-file-permissions \
-C /usr/local/src/lconf-web-1.4.0_installdir usr/local/lconf-web

Das dabei entstandene Paket lconf-web-1.4.0_amd64.deb kann nun natürlich mit dpkg auf einem Debian basierten System installiert werden.

Markus Waldmüller
Markus Waldmüller
Lead Senior Consultant

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Weekly Snap: Icinga in C’t, with FastCGI & Logstalgia, plus a sold-out OSMC

21 – 25 November brought Icinga to the fore, with an Icinga article in the C’t magazine, an example of its use with FastCGI in a how-to guide, and a game played with its log files… all topped off with a sold-out OSMC 2011.
In celebration of Linux’ 20th Anniversary, we contributed an article on “Server Monitoring with Icinga” to C’t magazine’s 7th special edition. Though Icinga is also suitable for large enterprise environments, the article focuses on smaller implementations. It offers a guide to installation on Ubuntu and standard configuration of typical checks and email alerts.
On a similar thread, Marius used FastCGI and Icinga Web to show how FPM (FastCGI Process Manager) can be used to help scale a PHP installation while avoiding interpreter instance and wrapper stress on the web server. He started with Apache2 (mpm-worker) on Ubuntu and a standard Icinga Web installation per the project quick-start guides, to end with grouped applications, easily adjustable scaling, and an overview of critical web applications.
Marcus then made child’s play of web server log analysis with Logstalgia (a.k.a Apache Pong). The amusing retro game takes both real-time traffic and existing logfiles to display incoming queries as ping-pong balls of different sizes to vary with file size. Logstalgia runs on the usual operating systems and even comes with packaged with some.
Last but not least, Pamela sold out of tickets to the OSMC 2011. Those who are still hoping to attend this year’s Open Source Monitoring Conference can join the waiting list. We look forward to a varied and informative program of speeches and workshops, as well as a festive dinner and drinks atop the renowned Nuremberg Christmas market. Till tomorrow!

FastCGI und Icinga-web

PHP skaliert in Standardinstallationen relativ schlecht. Grund dafür ist, daß der Webserver jedes mal eine neue Interpreterinstanz erstellen muss und danach wieder zerstört. Das kostet Zeit und eine Menge Performance / Nerven. Besser funktioniert es mit FastCGI. Hier werden die Interpreterinstanzen unabhängig vom Webserver gestartet und stehen fertig geladen bereit wenn der Request beim Webserver eintrifft. Leider ist die Konfiguration etwas schwieriger da es für FastCGI keine richtige Standardlösung gibt. Je nach Webserver werden eigene Wrapper benötigt die gestartet werden müssen. Weshalb ein solches Konstrukt oft auf wackeligen Beinen steht und anfällig für Bedienfehler ist.
Mit PHP 5.3 führt die Interpretersprache einen eigenen Manager für FastCGI Prozesse ein: FPM – FastCGI Process Manager. Mit ihm ist es auf einfache Art möglich Gruppen von Applikationen anzulegen, Skalierung einzustellen und dadurch den Überblick über kritische oder schwer gewichtige Webapplikationen zu behalten.
Ich habe mal versucht den FPM mit Apache2 (mpm-worker) unter Ubuntu am Beispiel von Icinga-web zum laufen zu bekommen. Ausgangssituation ist ein installierter Apache2 und eine Standard Icinga-web Installation aus den Tutorials oder den Quickstart Guides.
1) Installation der benötigten Pakete und aktivieren der benötigten Module:

# aptitude install libapache2-mod-fastcgi php5-fpm
# a2enmod fastcgi actions rewrite
Enabling module fastcgi.
Enabling module actions.
Enabling module rewrite.

2) Vorbereiten der Konfiguration für FPM

# pwd
/etc/php5/fpm
# cat pool.d/icinga-web.conf
[icinga-web]
listen = 127.0.0.1:9000
user = www-data
group = www-data
pm = dynamic
pm.max_children = 100
pm.start_servers = 30
pm.min_spare_servers = 30
pm.max_spare_servers = 50
;pm.max_requests = 500
chroot =
chdir = /usr/local/icinga-web/pub

Ich habe die Standardkonfiguration für “www” vorher deaktiviert. Ansonsten würden sich die Sockets auf Port 9000 einen Strich durch die Rechnung machen.
3) Fehlt noch eine Apache Konfiguration (Icinga-web Standard mit FastCGI Erweiterung):

# pwd
/etc/apache2/sites-available
# cat fcgi-test
	FastCgiExternalServer /var/www/php5.external -host 127.0.0.1:9000
	DocumentRoot /var/www
	AddHandler php5-fcgi .php
	Action php5-fcgi /usr/lib/cgi-bin/php5.external
	Alias /usr/lib/cgi-bin/ /var/www/
	AliasMatch /icinga-web/modules/([A-Za-z0-9]*)/resources/styles/([A-Za-z0-9]*\.css)$ /usr/local/icinga-web/app/modules/$1/pub/styles/$2
	AliasMatch /icinga-web/modules/([A-Za-z0-9]*)/resources/images/([A-Za-z_\-0-9]*\.(png|gif|jpg))$ /usr/local/icinga-web/app/modules/$1/pub/images/$2
	Alias /icinga-web/js/ext3 /usr/local/icinga-web/lib/ext3
	Alias /icinga-web /usr/local/icinga-web/pub
	        Order allow,deny
	        Allow from all
	        Order allow,deny
	        Allow from all
	        Order allow,deny
	        Allow from all
	        DirectoryIndex index.php
	        Options FollowSymLinks
	        AllowOverride all
	        Order allow,deny
	        Allow from all
# a2ensite  fcgi-test
Enabling site fcgi-test.

4) Apachen neu laden und den FPM Pool starten:

# ps aux | grep fpm | head -3
root      5213  0.0  0.0 145792  4872 ?        Ss   13:18   0:00 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)
www-data  5214  0.1  0.4 173028 34312 ?        S    13:18   0:00 php-fpm: pool icinga-web
www-data  5215  0.3  0.4 175140 36824 ?        S    13:18   0:00 php-fpm: pool icinga-web

Das ganze ist zwar nur rudimentär getestet und icinga-web nicht optimiert für FastCGI, bietet aber Potential für mehr: Persistenter Agavi Cache, Connection Pooling für die Datenbank, usw.

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.