Icinga2 und director

Inhaltsverzeichnis

Icinga2; Icinga-web2; Director und Graphite

Da es mich ewig Zeit gekostet hat Icinga2, den Director und Graphite zum Laufen zu bekommen, schreibe ich hier wieder einmal meine Notizen auf. Das Ganze natürlich unter Debian Jessie.

Ein paar Worte vorab: Icinga2 benötigt selbst keine Datenbank um zu funktionieren (was mir verdammt wichtig ist), allerdings die ganzen Tools die das Monitoring abrunden sowie die Webseiten. Da seien erwähnt:

Icinga-Web2 -> Weniger aufdringliche Oberfläche mit mehr "Fancy" Gedöns
Icinga2 Director -> Die neue Möglichkeit Icinga2 über die Webseite Hosts, Services und Notifications zu konfigurieren
Ido -> Datenquelle über die Zustände von Hosts und Services für Drittprogramme (inkl. Icinga-web2)
Graphite -> Alternative zu pnp4nagios
Grafana -> Die richtige Oberfläche für Graphite :-)

Das Gute daran ist, dass man im Unternehmen den ganzen graphischen Kram auf anderen Servern installieren kann, um den eigentlichen Monitoring Host zu entlasten. Dies dürfte sich vor allem beim I/O bemerkbar machen.

Was den Werbserver angeht, so gehe ich davon aus, dass der Apache2(.4) vorinstalliert ist. Nginx und Co funktionieren zwar auch, aber der steht hier nicht im Fokus.

Quellen

Normalerweise stehen die Quellen unten, da ich aber ohne diese Quellen die Notizen für mich nicht hätte erstellen können, nehmen sie in diesem Fall einen Sonderstatus ein.

Meine wichtigste Quelle:

https://www.unixe.de/ von ihr habe ich fast alles geklaut.
- https://www.unixe.de/icinga2-director-die-einrichtung/ - Director einrichten
- https://www.unixe.de/icinga2-director-erste-schritte-und-nutzung/ - Erste Director Schritte
- https://www.unixe.de/icingaweb2-und-graphite/ - Graphite

Dann kommen noch:

http://www.credativ.de/blog/howto-icinga2-mit-graphite-und-grafana-unter-debian - Graphite und Grafana
https://www.linuxfrickeln.de/visualisierung-von-performancedaten-in-der-icingaweb2-gui/ - Alternative Anleitung Graphite / Grafana
https://dokuwiki.nausch.org/doku.php/centos:web_c7:icinga:graphite - Nochmal Graphite

Daher großen Dank an meine Quellen :-)

Icinga2

Installation von Icinga2

Aller Anfang ist einfach:

Pakete kommen vom Icinga Repository direkt:

# echo 'deb http://packages.icinga.org/debian icinga-jessie main' >> /etc/apt/sources.list.d/icinga2.list
# wget -O - http://packages.icinga.org/icinga.key | apt-key add -
# apt-get update

Icinga2, ido und Mariadb-Server installieren

# apt-get install mariadb-server icinga2 icinga2-ido-mysql

Debconf Fragen:
- MariaDB Root Kennwort -> Kennwort ausfüllen
- Enable Icinga 2's ido-mysql feature? -> Yes
- Configure database for icinga2-ido-mysql with dbconfig-common? -> Yes
- Password of the database's administrative user: -> MariaDB Root Kennwort
- MySQL application password for icinga2-ido-mysql -> Kennwort ausfüllen

Installation von Icingaweb2

Man kann auch noch icinga2-classicui parallel installieren, falls die Datenbank wirklich ein Problem hat, lässt sich diese als Fallback Oberfläche verwenden.

Jetzt aber kommt zuerst Icingaweb2.

# apt-get install icingaweb2 php5-xcache php5-intl php5-imagick

Wenn, wie eingangs erwähnt, der Apache2 vorinstalliert war, muss nun die Webseite http(s)://example.com/icingaweb2/setup aufgerufen werden:

Also führen wir wie gewünscht die Kommandos aus:

# addgroup --system icingaweb2
# usermod -a -G icingaweb2 www-data
# icingacli setup config directory --group icingaweb2
# icingacli setup token create

The newly generated setup token is: a0f9cc9bdd78550b

Das Token muss dann in das "Setup Token" Feld eingefügt werden. Nach einem Klick auf "Next" wählen wir die Module aus, die wir benötigen. Das sind im Augenblick nur Doc und Monitoring:

Auf der nachfolgenden Seite sollte nachgeschaut werden, ob alles "grün" ist. Ausnahmen bilden Module die ohnehin nicht zum Einsatz kommen, wie für PostgreSQL.

Auf meinem System war zu erledigen:

Zeitzone in /etc/php5/apache2/php.ini festlegen (Europe/Berlin)

Bei der Authentifizierung verwende ich als Quelle die Datenbank. Man hat auch die Wahl den Apache davor zu schalten, wenn ich mich nicht irre ...

Für die Datenbank gelten folgende Parameter:
- Resource Name: icingaweb_db
- Database Type: MySQL
- Host: localhost
- Port:
- Database Name: icingaweb_db
- Username: icingaweb_db
- Password: das-ist-Ein-Wirkliches-GEheimniss!!
- Character Set: utf8

Das nachfolgende Bild spare ich mir. Es wird das MySQL Root Kennwort angefragt, um die Datenbank zzgl. User zu erzeugen. Folgt nur noch die Frage nach dem Backend Namen: icingaweb2

Jetzt folgt der erste User:
- Username: admin
- Password: Uuuuuultraaageheim
- Repeat password: Uuuuuultraaageheim

Einstellungen der Benutzer sollen in der gleichen Datenbank abgelegt werden:

Folgt nur noch die obligatorische Zusammenfassung. ... Denkt euch bitte das Bild hier.

Nach der Konfiguration fragt der Wizard die Parameter für das Monitoring Modul ab.

Als Backend Name nehmen wir:
- Backend Name: "icinga2"
- Backend Type: IDO

Bei den Parametern werden die Daten eingegeben, die Debconf bei der Installation von icinga2-ido-mysql angefragt hat (hat man die vergessen: dpkg-reconfigure icinga2-ido-mysql).

Als nächstes teilen wir dem Wizard mit, dass wir Kommandos per lokaler Datei mitgeben können wollen:

Felder die vor allzu neugierigen Augen zu schützen sind, können hier angegeben werden. Einige von euch werden vor allem SNMP Felder wieder erkennen ;-)

Fehlt nur noch wieder die Zusammenfassung .... Endlich fertig ...

Ist das alles geschafft, führt ein erster Login zu diesem Bild:

Installation von Icingaweb2 Director

Gleich eine Sache vorab: es gibt derzeit kein Debian Paket, was allerdings nicht weiter tragisch ist. Wir holen uns das Modul gleich per Git.

Zuvor sind noch ein paar Voraussetzungen zu erfüllen, wie das Aktivieren der API Schnittstelle und das Erstellen der Datenbank.

Noch ein PHP Modul:

# apt-get install php5-curl

Dann das Modul selbst:

# cd /usr/share/icingaweb2/modules
# git clone https://github.com/Icinga/icingaweb2-module-director.git director

Die Datenbank erstellen und befüllen:

# mysql -u root -p
mysql> CREATE DATABASE icinga2director CHARACTER SET 'utf8';
mysql> GRANT ALL ON icinga2director.* TO 'icinga2director'@'localhost' IDENTIFIED BY 'das ist alles nur geklaut';

# mysql -u icinga2director -p icinga2director < /usr/share/icingaweb2/modules/director/schema/mysql.sql

Die API aktivieren:

Wer sich eventuell schon ein wenig näher mit Icinga2 und dem Director beschäftigt hat, wird sicherlich schon über die durchgehende Verschlüsselung mittels TLS/CA gestolpert sein. Mit dem Aktivieren der API Schnittstelle, erzeugt Icinga2 eine CA die dann die Grundlage bildet für die Zertifikatskette bildet:

# icinga2 api setup
information/cli: Generating new CA.
information/base: Writing private key to '/var/lib/icinga2/ca/ca.key'.
information/base: Writing X509 certificate to '/var/lib/icinga2/ca/ca.crt'.
information/cli: Generating new CSR in '/etc/icinga2/pki/icinga.example.com.csr'.
information/base: Writing private key to '/etc/icinga2/pki/icinga.example.com.key'.
information/base: Writing certificate signing request to '/etc/icinga2/pki/icinga.example.com.csr'.
information/cli: Signing CSR with CA and writing certificate to '/etc/icinga2/pki/icinga.example.com.crt'.
information/pki: Writing certificate to file '/etc/icinga2/pki/icinga.example.com.crt'.
information/cli: Copying CA certificate to '/etc/icinga2/pki/ca.crt'.
information/cli: Adding new ApiUser 'root' in '/etc/icinga2/conf.d/api-users.conf'.
information/cli: Enabling the 'api' feature.
Enabling feature api. Make sure to restart Icinga 2 for these changes to take effect.
Done.

Now restart your Icinga 2 daemon to finish the installation!

Vor dem Neustart von Icinga2 müssen wir noch einen API User für den Director anlegen, über den dieser dann zugreifen kann:

/etc/icinga2/conf.d/api-users.conf:

object ApiUser "director" {
  password = "bloss,niemandem,verraten"
  permissions = [ "*" ]
}

Damit später die Zertifikate für den Icinga2 Agent korrekt erzeugt werden, bedarf es noch einer Überarbeitung der constants.conf:

/etc/icinga2/constants.conf:

[...]
/* Secret key for remote node tickets */
const TicketSalt = "1112223334445556667788999000"
}

Würden wir den TicketSalt nicht setzen, gäbe es später Fehlermeldungen wie zum Beispiel:

# bash icinga-agent-script.sh
information/base: Writing private key to '/etc/icinga2/pki/www.pug.org.key'.
information/base: Writing X509 certificate to '/etc/icinga2/pki/www.pug.org.crt'.
information/pki: Writing certificate to file '/etc/icinga2/pki/trusted-master.crt'.
critical/cli: Ticket salt is not configured.

Um später irritierende Fehlermeldungen beim Erstellen von Kommandos vorzubeugen, erweitern wir die zone.conf:

/etc/icinga2/zone.conf:

object Zone "director-global" {
        global = true
}

Dann kann der Icinga2 Daemon neugestartet werden:

#  service icinga2 restart

Damit Icingaweb2 etwas von der neuen Datenbank weiß, müssen wir eine neue (Datenbank) Ressource hinzufügen:

In den Feldern werden dann die notwendigen Werte eingegeben ...

Meine Werte:
- Resource Type: SQL Database
- Ressource Name: director_db
- Database Type: MySQL
- Host: localhost
- Port:
- Database Name: icinga2director
- Username: icinga2director
- Passwort: UnfassbarGeheim!
- Character Set: utf8

Damit kann man die neue Ressource verwenden. Im Webfrontend wird dazu nun unter Modules das "Director" Modul angeklickt:

Zum Aktivieren des Moduls auf enable klicken.

Danach kann auf das "Configuration" Tab geklickt und als erstes die DB Resource director_db ausgewählt werden. Nach dem Klick auf Store configuration' startet ein neuer Wizard, der die initiale Einrichtung abfragt.

Im Prinzip sind es nur drei Dinge:

Endpoint Name: -> Name der für die CA verwendet wurde beim Aufruf von icinga2 api setup (hier icinga.example.com)
API user: -> Hier der API Benutzer der in der /etc/icinga2/conf.d/api-users.conf eingetragen wurde.
Icinga Host: In der Regel immer localhost

Folgt zum Schluss nur noch der Klick auf Run import. Hat alles geklappt, dürfte es nun so aussehen:

Nun wird es ein wenig tricky. Der Director hat bereits eine Vielfalt an Checks, Notifications und Commands mit im Gepäck, die allerdings noch ausgerollt werden müssen. Man kann einige Zeit damit verbringen die passenden Knöpfe zu finden, daher habe ich den Pfad im nachfolgendem Bild einmal aufgelistet:

Anzahl der Änderungen die noch nicht ausgerollt worden sind
Tab für die "Deployments"
Konfiguration erstellen lassen
Ja, das ist tatsächlich anklickbar. Ein Klick hat zur Folge, dass die neue Icinga2 Konfiguration generiert und dann auf dem Dateisystem abgelegt wird.

Damit ist die grundsätzliche Inbetriebnahme abgeschlossen.

Erste Schritte mit Icingaweb2 Director

Da ich auch ein wenig Zeit benötigt habe, um meinen ersten Host, den ersten Check und das erste Kommando hinzuzufügen, zeige ich die dazu nötigen Schritte.

Erster Linux Host mittels Icinga2 Agent

Bei Icinga1 / Nagios kommen entweder NRPE (in seinen verschiedenen Variationen), SSH oder manchmal sogar SNMP zum Einsatz (nsca mal außen vorgelassen). Meistens ist es NRPE, da es bisher keinen richtigen Agent gibt/gab, wie das eventuell einige von Zabbix (zabbix_agent) kennen. Eine Ausnahme bildet check_mk (verdammt geniales Stück Software), allerdings steck da eine komplette neue Software dahinter. Mit Icinga2 ist der Icinga2 Daemon sowohl Server als auch Agent in einem. Ich weiß noch nicht, ob ich das gut finde oder einen abgespeckten Client bevorzugt hätte, aber in Anbetracht dessen, dass von der Pflege her weniger zu beachten ist, war diese Entscheidung vermutlich am sinnvollsten.

Um einen ersten Host über den Director hinzuzufügen, muss zuerst ein Template angelegt werden. Es enthält dann bereits die notwendigen Parameter. Dazu im Director auf Host klicken, das Tab Templates und die Werte wie gewünscht ausfüllen. Auf dem Bild verwende ich einen Check von 60 Sekunden, statt den sonst üblichen 300 Sekunden. Ob man das so übernehmen möchte, sollte man im Vorfeld abklären ;-)

Die Paramter sind:
- Hostname: host-linux-generic-template
- Check command: hostalive
- Check intervall: 60
- Retry intervall: 60
- Max check attempts: 5
- Execute active checks: Yes
- Execute passive checks: Yes
- Send notifications: Yes
- Process performance data: Yes
- Volatile: Yes
- Icinga2 Agent: Yes
- Establish connection: Yes
- Accepts config: Yes

Bei den letzten drei Punkten ist es natürlich wieder Geschmackssache ob immer per Default den Icinga2 Agent gesetzt werden soll. Eventuell könnte das Template auch bereits passend benannt werden, ob der Icinga2 Agent zum Einsatz kommt oder nicht.

Die restlichen Felder habe ich belassen.

Auf Basis dieser Vorlage kann nun ein Host erstellt werden. Dazu im Director wieder auf Hosts klicken und in diesem Fall auf dem Tab Host Add Host klicken. Bei Object Type wählen wir nun Object und wählen bei Imports das neu erstellte Template aus. Alle anderen Felder müssen passend ausgefüllt werden.

Als Beispiel verwende ich diesen Wiki Server hier:

Nach dem Ausfüllen und dem Abspeichern, kann auch gleich auf Deploy geklickt werden, welches dann die Konfiguration für Icinga2 aufbereitet und aus der Datenbank auf die Platte ablegt.

Hat das soweit geklappt, wird im nächsten Schritt die Agent Konfiguration herauskopiert und auf den zu überwachenden Host übertragen. Bei dem neu erstellten Host gibt es das Tab Agent, bei dem eine rudimentäre Anleitung zum Vorschein kommt. Den Bash Teil einfach in eine Datei kopieren später und mittels: bash sript.sh ausführen.

Bevor das aber klappen kann, ist dafür zu sorgen, dass:

icinga2 ebenfalls auf dem Host installiert wurde (icinga2-bin reicht meistens)
Der Monitoring Host auf den Port 5665 des zu überwachenden Host zugreifen darf (Routing/Firewall)
Die benötigten Monitoring Plugins installiert sind
Die generierte Konfiguration vor dem Start auf dem neuen Host in die icinga2.conf eingetragen wurde
Icinga2 auf dem zu überwachendem Host auch läuft

Hier ein generiertes Beispiel, wie das in meinem Fall aussieht:

#!/bin/bash

# This generates and signs your required certificates. Please do not
# forget to install the Icinga 2 package and your desired monitoring
# plugins first:

ICINGA_PKI_DIR=/etc/icinga2/pki
ICINGA_USER=nagios
chown $ICINGA_USER $ICINGA_PKI_DIR

icinga2 pki new-cert --cn www.pug.org \
--key $ICINGA_PKI_DIR/www.pug.org.key \
--cert $ICINGA_PKI_DIR/www.pug.org.crt

icinga2 pki save-cert --key $ICINGA_PKI_DIR/www.pug.org.key \
--trustedcert $ICINGA_PKI_DIR/trusted-master.crt \
--host icinga.example.com 

icinga2 pki request --host icinga.example.com \
--port 5665 \
--ticket 1111222222334445556667778899qwerttuisdfg \
--key $ICINGA_PKI_DIR/www.pug.org.key \
--cert $ICINGA_PKI_DIR/www.pug.org.crt \
--trustedcert $ICINGA_PKI_DIR/trusted-master.crt \
--ca $ICINGA_PKI_DIR/ca.crt

Folgt noch die Anpassung der icinga2.conf:
/etc/icinga2/icinga2.conf:

include "constants.conf"
include <itl>
include <plugins>
// include <plugins-contrib>

object FileLogger "main-log" {
  severity = "information"
  path = LocalStateDir + "/log/icinga2/icinga2.log"
}

// TODO: improve establish connection handling
object Endpoint "www.pug.org" {}
object Endpoint "icinga.example.net" {}
object Zone "icinga.example.net" {
  endpoints = [ "icinga.example.net" ]
  // TODO: all endpoints in master zone
}

object Zone "director-global" { global = true }

object Zone "www.pug.org" {
  parent = "icinga.example.net"
  endpoints = [ "www.pug.org" ]
}

object ApiListener "api" {
  cert_path = SysconfDir + "/icinga2/pki/www.pug.org.crt"
  key_path = SysconfDir + "/icinga2/pki/www.pug.org.key"
  ca_path = SysconfDir + "/icinga2/pki/ca.crt"
  accept_commands = true
  accept_config = true
}

Wichtig aus Perspektive der Sicherheit sind die beiden letzten Parameter. Sie besagen, dass der Agent vom Master sowohl Kommandos akzeptiert als auch Konfigurationen übermittelt bekommen kann.

Nach der Änderung kann auf dem zu überwachendem Host der Icinga2 Daemon neu gestartet und das Script ausgeführt werden. Kurze Zeit später taucht im Icingaweb2 der neue Host auf und stellt sich in etwa so dar:

Damit ist nun der erste Schritt getan, um den Host zu überwachen.

Erster Check

Als ersten Check - um das Prinzip zu verstehen - nehmen wir check_load. Beim Aktivieren vom Director werden bereits eine Menge Check Kommandos eingebunden. Es gibt allerdings einige Check Kommandos, bei denen wir gern Einfluss auf die Schwellwerte von Warning und Critical nehmen wollen. Wie dies geschieht, zeige ich in den nachfolgenden Zeilen. Zur Demonstration eignet sich check_load sehr gut.

Check Kommando Parameter

Als erster Schritt wird im Director das Kommando check_load ausgewählt und klickt dann auf Preview:

In der Vorschau lassen sich gut die Standardwerte ablesen:

 vars.load_cload1 = 10
    vars.load_cload15 = 4
    vars.load_cload5 = 6
    vars.load_percpu = false
    vars.load_wload1 = 5
    vars.load_wload15 = 3
    vars.load_wload5 = 4

Um diese Werte zu überschreiben, findet man auf dem Tab Fields nun die Möglichkeit diese Felder Variable zu gestalten, sodass diese später (optional) gesetzt werden können. Dazu einfach alle gewünschten Felder die der Check bietet, hinzufügen:

Wichtig an dieser Stelle: Optional vs. Mandatory: Es gibt einige Checks die benötigen immer die Werte für Warning und Critical, doch es sind keine vordefiniert. Bei diesen Checks (zum Beispiel check_mailq / mailq) müssen diese Felder auf Mandatory gesetzt werden.

Service Check Template

Als nächstes wird ein Service Template erstellt, wie auch schon beim Host. Ich habe es "service-linux-generic-template" genannt:

Meine Werte:
- Name: service-linux-generic-template
- Run on agent: Yes
- Check interval: 300
- Retry interval: 150
- Max check attempts: 3
- Execute active checks: Yes
- Accept passive checks: Yes
- Send notifications: Yes
- Enable event handler: Yes
- Process performance data: Yes
- Volatile: Yes

Der Rest bleibt wie gehabt unangetastet.

Service

Jetzt wird der eigentliche Service Check definiert: check-load. Dazu im Director auf Services wieder ein Service Template hinzufügen. In diesem Fall bekommt der Check unser vorher erstelltes Template als Import mit auf den Weg:

Wird bei Check command load ausgewählt, erhalten wir auch die Felder um die Warning und Critical Werte anpassen zu können. Allerdings habe ich sie hier nicht angepasst, da es an dieser Stelle nicht viel Sinn ergeben würde. Ein sinnvoller Schwellwert hängt von der Anzahl der CPU Kerne ab. Daher werden die Schwellwerte bei der Zuweisung zum jeweiligen Host mitgegeben.

Service Zuweisung

Jetzt kann der Check dem Host zugewiesen werden. Also wieder zurück zum Director auf Hosts und den gewünschten Host klicken. In diesem Fall www.pug.org. Dort lässt sich der Check check-load zuweisen und die Load Schwellwerte anpassen:

Die Reihenfolge habe ich hier angepasst, da im Director die Parameter falsch sortiert werden (1 15 5, statt 1 5 15).

Meine Werte:
- Imports: check-load
- Name: check-load
- Disabled: No
- load_wload1: 15
- load_wload5: 10
- load_wload15: 5
- load_cload1: 30
- load_cload5: 25
- load_cload15: 20

Dies entspricht einem Host mit zwei CPU Kernen. Die Werte habe ich von hier geklaut.

Sind alle Vorarbeiten erledigt, kann die Konfiguration wie gehabt ausgerollt werden, über Director -> Config history -> Tab Deployments -> Render config und schlussendlich auf "Deploy to master". Am Ende erscheint ein grünes Häkchen und der Check wird nach ein paar Minuten in etwa so aussehen:

Dauert es einem etwas zu lang, so genügt ein "service icinga2 reload" auf dem Host, dem der Check zugewiesen wurde. Dann besorgt sich der Icinga2 Agent sofort die neue Konfiguration vom Master. Als letztes hilft noch die Check Ausführung zu forcieren, über "Check now".

Apply Regeln

Eine sehr nützliche Funktion von Icinga2 sind die Apply Regeln. Damit lassen sich Checks automatisch an alle Hosts zuweisen, die zum Beispiel dem Betriebssystem Linux angehören. Damit das funktioniert, werden drei Dinge benötigt:

Eine Liste
Einträge für die Liste
Ein neues Feld für das Host Template

Daten Liste

Auf der Director Startseite findet sich unterhalb von der Überschrift "Do more with your data" der Punkt "Provide data lists".

Nach einem Klick lässt sich eine Liste anlegen, mit dem Namen "OS" für "Operating System". Diese neu angelegte Liste lässt sich mit Werten füllen:

Es ist nicht weiter spannend, dass der Schlüssel und Wert den gleichen Namen tragen. Nach dem Abspeichern geht es zurück auf die Startseite, wählen "Define data fields" und fügen ein neues Feld mit Namen "Operating System" hinzu. Als "Caption" können wir ebenfalls Operating System verwenden. Bei Data type wird Datalist gewählt und die vorher erstellte Liste OS.

Datenfeld Zuweisung

Damit ist nun das neue Feld Operating System verfügbar und kann dann z.B. dem Template host-linux-generic-template zugewiesen werden.

Dieses neue Feld kann nun dem Host www.pug.org zugewiesen werden, mit Linux als Wert. In der Vorschau lässt sich das gut darstellen:

object Host "www.pug.org" {
    import "host-linux-generic-template"

    display_name = "www.pug.org"
    address = "217.11.62.30"
    address6 = "2a00:1828:2000:167:8::1"
    vars.OperatingSystem = "Linux"
}

Als letztes kann eine Apply Regel erstellt werden, die den Check auf allen Hosts ausführt, die in ihrer Konfiguration ein vars.OperatingSystem = "Linux" haben.

check-load via Apply Zuweisung

Neben dem Service Namen "check-load" findet sich der Link "Create apply-rule"

Nach dem Klick haben wir die Möglichkeit genau zu definieren, wann diese Regel greift.

Bei Assignment rules gilt nun:

assign where OperatingSystem = Linux

In der Vorschau stellt sich dies so da:

zones.d/director-global/service_apply.conf
apply Service "check-load" {
    import "check-load"
    assign where host.vars.OperatingSystem == "Linux"
    import DirectorOverrideTemplate
}

Das war es auch schon. Jedem Host der das Feld OperatingSystem mit Linux als Wert hat, wird dieser Check nun zugewiesen.

Installation von Graphite

Als langjähriger Fan von pnp4nagios wollte ich es wieder einsetzen, musste aber erkennen, dass sich auch da vieles getan hat. Dazu gehören noch auch die Graphen.En vogue ist aktuell Graphite, welches viel flexibler im Umgang mit Metriken ist. Auch für Icingaweb2 gibt es ein passendes Modul. Der Weg dahin ist aber ein wenig steinig, daher schreibe ich den auch mal auf.

Wir benötigen dazu:

#  apt-get install graphite-carbon libapache2-mod-wsgi python-django python-django-tagging python-cairo python-tz python-pyparsing python-memcache python-rrdtool

Die Frage von Debconf, ob nach der Deinstallation auch die erzeugten Dateien gelöscht werden sollen, bejahe ich in der Regel. Dies muss aber jeder Admin für sich selbst entscheiden.

Als nächstes wird das Gaphite Modul für icingaweb2 aktiviert:

#  icinga2 feature enable graphite
# service icinga2 restart
[...]
[2016-10-11 20:50:46 +0200] information/ConfigItem: Triggering Start signal for config items
[2016-10-11 20:50:46 +0200] information/ApiListener: Adding new listener on port '5665'
[2016-10-11 20:50:46 +0200] critical/TcpSocket: Invalid socket: Connection refused
[2016-10-11 20:50:46 +0200] critical/GraphiteWriter: Can't connect to Graphite on host '127.0.0.1' port '2003'.
[2016-10-11 20:50:46 +0200] information/ConfigItem: Activated all objects.

Die Meldungen am Ende sind in Ordnung, da der Carbon Daemon von Graphite noch nicht gestartet wurde. Debian üblich müssen wir noch die Default Datei editieren:

/etc/defaults/graphite-carbon:

# sed -i 's/false/true/g' /etc/default/graphite-carbon

Nun kann Carbon gestartet werden:

# service carbon-cache start
[....] Starting Graphite backend daemon: carbon-cacheStarting carbon-cache (instance a)
. ok

Die Metriken werden dann nach und nach im Ordner /var/lib/graphite/whisper/icinga2 erscheinen. Das alles dient bisher lediglich dazu, dass Icinga2 die Performancedaten an Carbon übergibt, nicht jedoch um Graphen darzustellen. Das kommt jetzt:

Installation und Konfiguration von Graphite-web

#  graphite-web

Mit dem Paket kommt eine Beispielkonfiguration für den Apache2 mit ( /usr/share/graphite-web/apache2-graphite.conf ), die ich allerdings etwas für SSL abgewandelt habe. Des Weiteren habe ich eine Basic Authentifizierung davor geschaltet:

/etc/apache2/sites-available/graphite-web.conf

<VirtualHost *:443>

ServerAdmin webmaster@icinga.example.com
ServerName graphite.example.com
SSLCertificateFile /etc/letsencrypt/live/icinga.example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/icinga.example.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

<Location "/">
	AllowOverride AuthConfig
	Order Allow,Deny
	Allow From All

	AuthName "Graphite Access"
	AuthType Basic
	AuthUserFile /etc/apache2/htpasswd.users
	Require valid-user
</Location>

	WSGIDaemonProcess _graphite processes=5 threads=5 display-name='%{GROUP}' inactivity-timeout=120 user=_graphite group=_graphite
	WSGIProcessGroup _graphite
	WSGIImportScript /usr/share/graphite-web/graphite.wsgi process-group=_graphite application-group=%{GLOBAL}
	WSGIScriptAlias / /usr/share/graphite-web/graphite.wsgi

	Alias /content/ /usr/share/graphite-web/static/
	<Location "/content/">
		SetHandler None
	</Location>

	ErrorLog ${APACHE_LOG_DIR}/graphite-web_error.log

	# Possible values include: debug, info, notice, warn, error, crit,
	# alert, emerg.
	LogLevel warn

	CustomLog ${APACHE_LOG_DIR}/graphite-web_access.log combined

</VirtualHost>

Wie sich unschwer erkennen lässt, nutze ich Letsencrypt um einen VirtualHost mit TLS abzusichern. Des Weiteren erfolgt wie erwähnt eine Authentifizierung, für die wir eine einfache Benutzerdatenbank benötigen:

# htpasswd -c /etc/apache2/htpasswd.users admin
New password:
Re-type new password:
Adding password for user admin

Anmerkung: In einem wirklich produktiven Umfeld würde ich an dieser Stelle keine Basic Authentifizierung mittels Datei verwenden, sondern LDAP, oder SQL via mod_authn_dbd.

Dann lässt sich der neue VirtualHost aktivieren:

# a2ensite graphite-web.conf

Nun muss Graphite-web selbst noch konfiguriert werden. Dazu gibt es die Datei /etc/graphite/local_settings.py, welche die Datenbank definiert und noch ein paar andere Dinge. Für den schnellen Erfolg kann durchaus die sqlite3 Datenbank verwendet werden, allerdings läuft ja ohnehin ein MySQL (aka MariaDB), daher nutzen wir diesen als Datenbank Quelle.

Die wichtigen Zeilen:

SECRET_KEY = 'ohhh mein tuxx ein Passwort steht hier'
TIME_ZONE = 'Europe/Berlin'
LOG_RENDERING_PERFORMANCE = True
LOG_CACHE_PERFORMANCE = True
LOG_METRIC_ACCESS = True
GRAPHITE_ROOT = '/usr/share/graphite-web'
CONF_DIR = '/etc/graphite'
STORAGE_DIR = '/var/lib/graphite/whisper'
CONTENT_DIR = '/usr/share/graphite-web/static'
WHISPER_DIR = '/var/lib/graphite/whisper'
LOG_DIR = '/var/log/graphite'
INDEX_FILE = '/var/lib/graphite/search_index'  # Search index file
DATABASES = {
    'default': {
        'NAME': 'graphite_db',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'graphite',
        'PASSWORD': 'Geheimes Datenbank Kennwort',
        'HOST': 'localhost',
        'PORT': '3306'
    }
}

Dazu müssen wir natürlich die Datenbank anlegen:

# mysql -u root -p
mysql> CREATE DATABASE graphite_db CHARACTER SET 'utf8';
mysql> GRANT ALL ON graphite_db.* TO 'graphite'@'localhost' IDENTIFIED BY 'Geheimes Datenbank Kennwort';
mysql> FLUSH PRIVILEGES;
mysql> exit;

Nun können wir die Datenbank von Django befüllen lassen. Der Debian Maintaner hat dazu ein passendes Tool hinterlegt:

# graphite-manage syncdb

Es folgen nun einige Ausgaben in diversen Farben, am Ende wird nach einem Django superusers gefragt, bei dem dann wieder ein User (root) ein Passwort und eine Mailadresse hinterlegt werden müssen. Ähnlich wie bei RRD, müssen wir Carbon mitteilen, wie die Zeiträume am Ende zusammen gestaucht werden können (Aggregation). Damit das richtig klappt, gibt es nur eine wirklich wichtige Regel:

Die Intervalle er Icinga2 Checks müssen mit denen im Carbon übereinstimmen. Dazu kann man hier mehr lesen.

/etc/carbon/storage-schemas.conf

[carbon]
pattern = ^carbon\.
retentions = 60:90d

[default_1min_for_1day]
pattern = .*
retentions = 60s:1d

[icinga_internals]
pattern = ^icinga\..*\.(max_check_attempts|reachable|current_attempt|execution_time|latency|state|state_type)
retentions = 5m:7d

[icinga_default]
pattern = ^icinga\.
retentions = 1m:2d,5m:10d,30m:90d,360m:4y

Hat das geklappt und Apache2 und carbon-cache wurden noch einmal neugestartet, kann man auf der Webseite http(s)://graphite.example.com Graphite bewundern. Um einen Graph zu erhalten, genügt es die Ordnerstruktur von z.B. icinga2 durchzugehen und einen Wert "Value" auszuwählen.

Damit nun die Graphen auch auf der icingaweb2 Webseite zu sehen sind, benötigen wir dazu erneut ein Modul aus dem Git Universum.

# cd /usr/share/icingaweb2/modules/
# git clone https://github.com/findmypast/icingaweb2-module-graphite.git graphite
# mkdir /etc/icingaweb2/modules/graphite

Danach kann im Icingaweb2 unter Configuration -> Module -> graphite Das Graphite Modul aktiviert werden. Wird nun auf das Tab Configuration geklickt, erhält man praktischerweise eine Konfiguration die unter /etc/icingaweb2/modules/graphite/config.ini ablegt werden muss. Einige Zeilen sind allerdings anzupassen. Dazu zählt unter anderem die base_url:

/etc/icingaweb2/modules/graphite/config.ini:

[graphite]
metric_prefix = icinga2
base_url = https://graphite.example.com/render?
legacy_mode = false
;if legacy mode is false (2.4 and newer):
service_name_template = "icinga2.$host.name$.services.$service.name$.$service.check_command$.perfdata.$metric$.value"
host_name_template = "icinga2.$host.name$.host.$host.check_command$.perfdata.$metric$.value"
;if legacy mode is true (pre 2.4):
;service_name_template = "icinga.$host.name$.services.$service.name$.$service.check_command$"
;host_name_template = "icinga.$host.name$.host.$host.check_command$"
;this template is used for the small image, macros $target$ , $areaMode$ and $areaAlpha$ can used.
graphite_args_template = "&target=$target$&source=0&width=300&height=120&hideAxes=true&lineWidth=2&hideLegend=true&colorList=$colorList$&areaMode=$areaMode$&areaAlpha=$areaAlpha$"
;this template is used for the large image, macros $target$ , $areaMode$ and $areaAlpha$ can used.
;graphite_large_args_template = "&target=alias(color($target$_warn,'yellow'),'warning')&target=alias(color($target$_crit,'red'),'critical')&target=$target$&source=0&width=800&height=700&colorList=$colorList$&lineMode=connected&areaMode=$areaMode$&areaAlpha=$areaAlpha$"
graphite_iframe_w = 800px
graphite_iframe_h = 700px
graphite_area_mode = all
graphite_area_alpha = 0.1
graphite_summarize_interval = 10min
graphite_color_list = 049BAF,EE1D00,04B06E,0446B0,871E10,CB315D,B06904,B0049C

Wurde die Datei angelegt, dürfte sich schon nach ein paar Reloads der Webseite folgendes Bild auftauchen:

Installation und Konfiguration von Grafana

Da Graphite selbst nicht sonderlich "hübsch" ist, gibt es Grafana.

Für Grafana verwenden wir am Besten das entsprechende Repository:

# apt-get install apt-transport-https
# echo 'deb https://packagecloud.io/grafana/stable/debian/ jessie main' >> /etc/apt/sources.list.d/grafana.list
# curl -s https://packagecloud.io/gpg.key | sudo apt-key add -
# apt-get update
# apt-get install grafana

Grafana nutzt per Default eine SQLite Datenbank. Da wir aber MySQL nutzen wollen, erstellen wir schnell eine Datenbank:

Datenbank:

# mysql -p
mysql> CREATE DATABASE grafana_db CHARACTER SET 'utf8';
mysql> GRANT ALL ON grafana_db.* TO 'grafana'@'localhost' IDENTIFIED BY 'Das Geheime Kennwort;
mysql> FLUSH PRIVILEGES;
mysql> quit;

Da Grafana einen eigenen Dienst mitbringt der auf Port 3000 horcht, ist es nicht sehr praktisch, daher erstellen wir eine Apache2 Konfiguration, die als ReverseProxy alle Anfragen an den Port 3000 weiterreicht. Zuvor müssen wir Grafana konfigurieren. Es gibt zuvor allerdings noch eine Sache die zu beachten ist: Die Authentifizierung!

Entweder alles läuft über den Apache2, oder -- wie in diesem Fall -- über Apache2 und Grafana.

Ich habe hier folgende Zeilen angepasst:

domain -> Der Hostname
root_url -> Die entsprechende URL hier mit /grafana/ am Ende
header_name -> Authentifizierung durch den Webserver
header_property -> Authentifizierung durch den Webserver
auto_sign_up -> -> Authentifizierung durch den Webserver
type = mysql -> Statt sqlite
host -> Wo läuft der Datenbank Server
name -> Datenbank Name
user -> User für die Datenbank
password -> Passwort für die Datenbank

/etc/grafana/grafana.ini:

[paths]
[server]
domain = example.org
root_url = %(protocol)s://%(domain)s:%(http_port)s/grafana/
[database]
type = mysql
host = 127.0.0.1:3306
name = grafana_db
user = grafana
password = das Geheime Passwort
[session]
[analytics]
check_for_updates = true
[security]
admin_user = admin
secret_key = sinnloserTextmit726494762Zahlen
disable_gravatar = true
[snapshots]
[users]
allow_sign_up = false
auto_assign_org = true
auto_assign_org_role = Editor
[auth.anonymous]
enabled = false
org_role = Viewer
[auth.github]
[auth.google]
[auth.proxy]
enabled = true
header_name = X-WEBAUTH-USER
header_property = username
auto_sign_up = true
[auth.basic]
enabled = false
[auth.ldap]
[smtp]
[emails]
[log]
[log.console]
[log.file]
[log.syslog]
[event_publisher]
[dashboards.json]
[metrics]
[grafana_net]
url = https://grafana.net

Als nächstes den Dienst aktivieren und starten. Grafana wird dabei automatisch die Datenbank befüllen:

Für das klassische Init:

# update-rc.d grafana-server defaults 95 10
#

Für Systemd:

# systemctl enable grafana-server.service

Starten:

# servive grafana-server start

Nun lauscht ein Dienst auf Port 3000:

# netstat -tln | grep 3000
tcp6       0      0 :::3000                 :::*                    LISTEN

Als letztes fehlt noch die Apache2 Konfiguration. Dabei gibt es zwei Möglichkeiten:

Als triviale Konfiguration
Als Virtualhost - wie in meinem Beispiel

/etc/apache2/sites-available/grafana.conf:

ProxyPreserveHost On
    ProxyPass /grafana http://0.0.0.0:3000
    ProxyPassReverse /grafana http://0.0.0.0:3000

Bevor der Apache2 neugestartet werden kann, müssen die beiden Module proxy und proxy_html aktiviert werden:

# a2enmod proxy proxy_html
# a2ensite grafana.conf

Damit kann nun die Webseite https://graphite.example.com/grafana aufgerufen werden. Als erstes erfolgt die Anmeldung an dem Apachen, dann kann man sich an Grafana authentifizieren, mittels dem User admin und dem Passwort admin.

Grafana Basis

Da Icinga2 und Graphite bereits funktionieren, müssen wir nur noch Graphite als Datenquelle einstellen.

Im ersten Bild: Nach dem Login oben links auf das bunte Logo klicken und Data Source auswählen.

Dann die Daten wie im folgendem Bild ausfüllen:

Stimmen die Daten, wird beim Speichern automatisch geprüft, ob die Einstellungen stimmig sind.

Dann wird ein neues Dashboard erzeugt:

Nun gibt es ein kleine grüne Lasche an der linken Seite. Wird es mit der Maus angeklickt fährt es heraus und man erhält weitere Optionen:

Wir wollen einen neuen Graphen hinzufügen. Es wird per Default ein Beispielgraph automatisch eingefügt, der aber gleich verschwindet, sobald als Quelle "Graphite" (der Name der bei der Einrichtung der Data Source vergeben wurde) ausgewählt wird:

Unten am Bild ist "Panel data source" zu erkennen, bei dem default ausgewählt wurde. Das lässt sich in den Einstellungen von Grafana ändern. Wird Panel data source auf Graphite geändert ...

... lassen sich nun die von Icinga2 gesammelten Werte auswählen und anzeigen ....

Damit lässt sich das Panel nun speichern. Möchte man weitere Parameter / Einstellungen ändern, so genügt ein Klick auf den Titel des Panels. Es erscheint darauf hin ein kleines Menü.

Hat man alles zusammen, kann dann das dann Dashboard gespeichert und umbenannt werden. Das lässt sich jeweils mit den Icons neben dem Dashboard Namen auslösen.

Influxdb

Seit Icinga 2.5 besteht die Möglichkeit als "Zeitdatenbank" (Time series database) InfluxDB zu verwenden. Influxdb hat da einige Vorteile gegebenüber Carbon von Graphite:

Prallen zu viele Daten auf Carbon ein, fängt dieser an Metriken zu verwerfen. Das ist ein Problem von Pyhton und Multithreading ...
Kommt Carbon an eine Grenzen, verrät er das einem leider nicht
Schreibt Carbon Daten, passiert dies nicht in einem Strom, sondern der Daemon führt das komplette Programm von "öffnen, schreiben, schließen" durch.

Hier findet sich eine schöne Beschreibung.

Vom Prinzip her ist die Einrichtung sehr einfach:

Deb Zeile hinzufügen
Influxdb Daemon anpassen und Datenbank erstellen
Icinga2 Influxdb als Datenempfänger aktivieren
Neue Datequelle zu Grafana hinzufügen
Schickes Dashboard einrichten

Influxdb - Installation

Sources.list hinzufügen

# echo "deb https://repos.influxdata.com/debian jessie stable" | tee /etc/apt/sources.list.d/influxdb.list
# curl -sL https://repos.influxdata.com/influxdb.key |  apt-key add -
# apt-get update

Influxdb installieren

# apt-get install influxdb

Grundkonfiguration erzeugen

# cd /etc/influxdb
# influxd config > influxdb.generated.conf
Merging with configuration at: /etc/influxdb/influxdb.conf

Influxdb - Konfiguration

Influxdb lässt sich auf Anhieb ohne Restriktionen nutzen und würde nach dem Start auf den Ports 8083, 8086 und 8088 horchen. Um das Influxdb ein wenig sicherer zu konfigurieren, aktivieren wir Authentifizierung und SSL. Zuvor wird ein Admin Account erstellt:

Admin Account erzeugen

# service influxdb start
# influx
> CREATE USER admin WITH PASSWORD 'timeismoney' WITH ALL PRIVILEGES
> quit

LetsEnctypt Berechtigungen

Wer wie im Beispiel LetsEncrypt verwendet, muss ein paar Berechtigungen anpassen, sonst kann der Daemon nicht auf die Zertifikate zugreifen:

# usermod -a -G ssl-cert influxdb
# chgrp -R ssl-cert /etc/letsencrypt

Danach kann die Konfiguration angepasst werden. Hier werden nur die abgeänderten Werte aufgelistet.

Hier sind die Zeilen für TLS hinzugekommen. Es ist allerdings eine Sache zu beachten: Während die http Sektion mit getrennten Dateien für das Zertifikat und Schlüssel zurecht kommt, kann das die Admin Sektion nicht.

Für LetsEncrypt gilt dann:

# cat /etc/letsencrypt/live/icinga.example.com/cert.pem /etc/letsencrypt/live/icinga.example.com/chain.pem /etc/letsencrypt/live/icinga.example.com/privkey.pem > /etc/letsencrypt/live/icinga.example.com/full.pem
# chown root:letsencrypt /etc/letsencrypt/live/icinga.example.com/full.pem
# chmod 640 /etc/letsencrypt/live/icinga.example.com/full.pem

/etc/influxdb/influxdb.conf:

[....]
[admin]
  enabled = true
  bind-address = ":8083"
  https-enabled = true
  https-certificate = "/etc/letsencrypt/live/icinga.example.com/full.pem"
[...]

Hier wird ebenfalls SSL aktiviert und die Authentifizierung:

[....]
[http]
  enabled = true
  bind-address = ":8086"
  auth-enabled = true
  log-enabled = true
  write-tracing = false
  pprof-enabled = false
  https-enabled = true
  https-certificate = "/etc/letsencrypt/live/icinga.example.com/fullchain.pem"
  https-private-key = "/etc/letsencrypt/live/icinga.example.com/privkey.pem"
  max-row-limit = 10000
  realm = "InfluxDB"
[...]

Jetzt kann Influxdb neugestartet und die Authentifizierung getestet werden.

Admin Account testen

# service influxdb restart
# influx -ssl -host icinga.example.com
> auth
username: admin
password: ....
>

Hat man ein selbst signiertes Zertifikat und Probleme sich zu verbinden, kann man auch "-unsafeSsl" als Parameter verwenden.

Hat der Login geklappt, kann es weitergehen.

Influxdb - Icinga2 Datenbank

Als erstes mit dem Admin Account einloggen, danach Datenbank und User erzeugen:

# influx -ssl -host icinga.example.com
> auth
username: admin
password: ....
> create database icinga2;
> create user icinga2 with password 'supersecret';
> grant all on icinga2 to icinga2;

Diese Login Daten werden später auch für Grafana benötigt.

Jetzt kann das Icinga2 Influxdb Modul aktiviert werden:

# icinga2 feature enable influxdb

Vor dem Neustart muss allerdings noch die Konfiguration angepasst werden:

/etc/icinga2/features-enabled/influxdb.conf:

library "perfdata"

object InfluxdbWriter "influxdb" {
	host = "icinga.example.com"
		port = 8086
		database = "icinga2"
		ssl_enable = true
		username = "icinga2"
		enable_send_metadata = true
                enable_send_thresholds = true
		password = "supersecret"
		host_template = {
			measurement = "$host.check_command$"
			tags = {
				fqdn = "$host.name$"
				hostname = "$host.vars.hostname$"
				domain = "$host.vars.domain$"
				}
		}
	service_template = {
		measurement = "$service.check_command$"
			tags = {
				fqdn = "$host.name$"
				domain = "$host.vars.domain$"
				service = "$service.name$"
				instance = "$service.vars.instance$"
			}
	}
}

Wichtig sind hier die Logindaten und das auch SSL aktiv ist. Die Templates für Service und Host stammen von hier. Danach reicht ein Neustart von Icinga2, um dann die ersten Daten in Influxdb bewundern zu können.

# influx -ssl -host icinga.example.com
> auth
username: icinga2
password: ...
> use icinga2
> show measurements
name: measurements
------------------
name
apt
check_scsi_smart
disk
hostalive
http
icinga
load
ping4
ping6
procs
ssh
swap
users

> quit

Damit ist die Einrichtung von Influxdb für das erste abgeschlossen.

Influxdb - Grafana Quelle und Dashboard

Um auf die neue Datenquelle über Grafana zugreifen zu können, muss zu der Graphite (sofern schon vorhanden) noch Influxdb hinzugefügt werden. Das geht wie bei Graphite oben über den Admin Account -> Add Data source.

Damit lässt sich nun ein Graph hinzufügen, der wie eine SQL Abfrage augebaut wird. Hier ein Beispiel:

Richtig schön ist das Beispiel von den Netways Leuten, die ein Dashboard für Influx und Grafana gebastelt haben. Dazu genügt es ein neues Dashboard zu erzeugen und dieses von hier zu importieren.

Dann lassen sich auch schon die ersten Daten visualisieren

Sinatra Dashboard

Wenn etwas nicht sonderlich schön anzuschauen ist, dann die Standardseite von Icinga, Icinga2. Zumeist passt es nicht auf einen Bildschirm, oder es muss zu viel umgebaut werden, sodass die wesentlichen Informationen dargestellt werden können. An diese Stelle tritt nun das [Dashboard http://dashing.io/]. Es ist im Grunde ein Framework, welches Informationen "hübsch" darstellt, passend für einen großen Monitor an der Wand.

Von Netways gibt es eine angepasste Version die sich recht leicht installieren lässt. Einzig: wieder kein Debian Paket und vor allem ruby / bundler kram :-(

In meinem Fall installiere ich das Dashboard auf einem Cubietruck, auf dem lediglich ein icinga2-bin installiert ist.

Installation und Konfiguration

Da das Dashboard die API von Icinga2 anzapft, benötigen wir dafür einen weiteren API User auf dem Icinga2 Monitoring Host:

/etc/icinga2/conf.d/api-users.conf

object ApiUser "dashing" {
  password = "Das andere geheime Kennwort"
  permissions = [ "status/query", "objects/query/*" ]
}

Nach einem reload von Icinga2, steht der Benutzer zur Verfügung.

Nun geht es auf dem Rechner weiter, auf dem das Dashboard installiert werden soll.

Pakete die notwendig sind:

# apt-get install ruby-dev nodejs

Git ausschecken:

# cd /opt
# git clone https://github.com/Icinga/dashing-icinga2
# chown nagios: -R dashing-icinga2

Bundler kram

# su - nagios -s /bin/bash
$ cd /opt/dashing-icinga2/
$ gem install bundler
$ gem install dashing

Bundler ruft sudo auf um einige Programme nach /usr/local/bin zu installieren, daher sollte man das sudo konfigurieren ...

Konfiguration /opt/dashing-icinga2/jobs/icinga2.rb anpassen:

...
 $api_url_base = "https://icinga.example.com:5665"
...
$api_username = "dashing"
...
$api_password = "Das andere geheime Kennwort"

Für den Fall, dass eine Firewall zwischen beiden steht, besser vorher mit einem Telnet auf Port 5665 prüfen, ob sich der Icinga2 meldet.

Starten

# su - nagios -s /bin/bash
$ cd /opt/dashing-icinga2/
$ ./restart-dashing

Hat alles geklappt, meldet sich das Dashboard auf Port 8005.

Damit auch bei einem Reboot das Dashboard gestartet wird, habe ich ein Init Script von hier verwendet und leicht angepasst:

/etc/init.d/dashboard:

#!/bin/bash
# USAGE: start|stop|restart|status

### BEGIN INIT INFO
# Provides:          dashboard
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start daemon at boot time
# Description:       Enable service provided by daemon.
### END INIT INFO

set -e
. /lib/lsb/init-functions

# Must be a valid filename
NAME=dashing
DASHING_DIR=/opt/dashing-icinga2
PIDFILE="$DASHING_DIR/$NAME.pid"
DAEMON=/usr/local/bin/$NAME
GEM_HOME=/var/lib/gems/1.9.1

DASHING_PORT=8005
DAEMON_OPTS="start -d -p $DASHING_PORT -P $PIDFILE --tag $NAME -D"

RUNUSER=nagios
RUNGROUP=nagios

test -x $DAEMON || { log_failure_msg "$NAME not installed";exit 1; }

function checkuser() {
  if [[ $UID != 0 ]]; then
    if [[ `whoami` != "$RUNUSER" ]]; then
      log_failure_msg "$1 must be run as root or $RUNUSER"
      exit 1
    fi
  fi
}

function start_dashing() {
  log_action_msg "Starting daemon: $NAME" || true
  sleep 5
  start-stop-daemon --verbose --quiet --start --chuid $RUNUSER:$RUNGROUP --chdir $DASHING_DIR --exec $DAEMON -- $DAEMON_OPTS
  log_end_msg 0
}

function stop_dashing() {
  log_action_msg "Stopping daemon: $NAME" || true
  start-stop-daemon --quiet --stop --pidfile $PIDFILE --user $RUNUSER --retry 30 --oknodo
  log_end_msg 0
}


case "$1" in
  start)
    checkuser start
    start_dashing
  ;;
  stop)
    checkuser stop
    stop_dashing
  ;;
  restart)
    checkuser restart
    log_action_msg "Restarting daemon: $NAME"
    stop_dashing
    start_dashing
  ;;
  status)
    status_of_proc -p $DAEMON $NAME
  ;;
  logs)
    tail -F $DASHING_DIR/log/thin.log
  ;;
  *)
  echo "Usage: "$1" {start|stop|restart|status}"
  exit 1
esac

exit 0

Init Script aktivieren

# chmod +x /etc/init.d/dashboard
# update-rc.d dashboard defaults

Vor dem ersten Test, prüfen ob der "thin" Prozess noch läuft und eventuell killen:

Starten

# ps ax | grep thin
28368 ?        Rl     0:02 thin server (0.0.0.0:8005) [dashing]
# kill 28368
# ps ax | grep thin

# service dashboard start
# service dashboard status

dashboard.service - LSB: Start daemon at boot time
   Loaded: loaded (/etc/init.d/dashboard)
   Active: active (running) since Sun 2016-10-30 21:16:27 CET; 2min 8s ago
  Process: 28306 ExecStop=/etc/init.d/dashboard stop (code=exited, status=0/SUCCESS)
  Process: 28354 ExecStart=/etc/init.d/dashboard start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/dashboard.service
           └─28368 thin server (0.0.0.0:8005) [dashing]

Oct 30 21:16:15 web dashboard[28354]: Starting daemon: dashing.
Oct 30 21:16:27 web dashboard[28354]: .
Oct 30 21:16:27 web systemd[1]: Started LSB: Start daemon at boot time.

Denny (Diskussion) 22:10, 23. Okt. 2016 (CEST)