Konfiguration des Bloonix-Agenten

Die Konfiguration des Agenten befindet sich in:

/etc/bloonix/agent/main.conf

Globale Parameter

agents 4
user bloonix
group bloonix
plugins /usr/lib/bloonix/plugins
simple_plugins /usr/local/lib/bloonix/simple-plugins,/usr/lib/bloonix/simple-plugins
include /etc/bloonix/agent/conf.d

Detailierte Beschreibung einzelner Parameter

Parameter agents und max_concurrent_checks

Der Bloonix-Agent verwendet fork(), um bei Programmstart die angegebene Anzahl an Agenten, die mit dem Parameter agents angegeben ist, zu forken. Der Parent-Prozess fungiert als Scheduler und verteilt die Arbeit auf die Child-Prozesse. Mit dem Parameter max_concurrent_checks wird bestimmt, wieviele Service-Checks parallel pro Host ausgeführt werden. Es wird empfohlen, den Parameter agents und max_concurrent_checks auf mindestens 4 einzustellen.

Der Parameter max_concurrent_checks sollte nie größer sein als der Parameter agents, da nur soviele konkurrierende Checks ausgeführt werden können, wie es Agenten gibt.

Parameter max_concurrent_hosts

Der Parameter max_concurrent_hosts funktioniert ähnlich dem Parameter max_concurrent_checks. Die Hosts, die in der Konfigurationsdatei des Agenten zur Überwachung eingetragen sind, werden in regelmäßigen Abständen gepollt, um zu prüfen, ob Services zur Überwachung anstehen. Hierzu sendet der Bloonix-Agent eine Anfrage zum Bloonix-Server. Wenn Services zur Überwachung anstehen, dann werden die Services geprüft. Die maximale Anzahl an Hosts, die gleichzeitig geprüft werden, kann mit dem Parameter max_concurrent_hosts reguliert werden. Standardmäßig steht der Parameter auf dem Wert auto (oder auch 0) und wird auf 50% der Anzahl des Parameters agents gesetzt.

Parameter max_concurrent_hosts + max_concurrent_checks

Mit den Parametern max_concurrent_hosts und max_concurrent_checks kann die Aufteilung der Ausführung von Checks optimiert werden und sollte immer mit Bezug auf den Parameter agents konfiguriert sein. Nehmen wir einmal an, Sie haben die Parameter wie folgt gesetzt:

# nicht optimierte Konfiguration:
agents 50
max_concurrent_hosts 50
max_concurrent_checks 50

In diesem Beispiel gibt es 50 Prozesse, die die Queue zur Abarbeitung von Hosts und Service-Checks abarbeiten. Das Problem dabei ist, dass die Prozesse je nach Anzahl der Service-Checks eines Hosts allesamt geblockt werden können. Wenn Sie zum Beispiel einen einzelnen Host in der WebGUI mit 50 HTTP-Checks konfiguriert haben, dann würden diese 50 Checks auf alle Agenten aufgeteilt. Hat der Host in einem Moment Lastprobleme und benötigt für die HTTP-Checks eine längere Abarbeitungszeit, so würden alle 50 Agenten geblockt, bis die Checks ausgeführt sind. Um das zu vermeiden, können die maximalen Checks, die gleichzeitig von einem Host geprüft werden, limitiert werden.

Beide Parameter in Kombination können also dazu führen, dann Hosts und Service-Checks optimiert verteilt werden:

# optimierte Konfiguration:
agents 50
max_concurrent_hosts 20
max_concurrent_checks 5

In diesem Beispiel können maximal 20 Hosts gleichzeitig mit je 5 Service-Checks bearbeitet werden. Somit würde ein Host, der 50 HTTP-Checks eingerichtet hat, nur 5 Agenten-Prozesse belegen.

Umgebungsvariablen

Der Bloonix-Agent setzt beim Start und vor jeder Ausführung eines Checks diverse Umgebungsvariablen, die wiederrum von den Plugins selbst verwendet werden können, um spezifische Informationen zum Host, zum Service oder zur Umgebung zu erlangen. Es werden folgende Variablen standardmäßig gesetzt:

PLUGIN_LIBDIR
CONFIG_PATH
CHECK_HOST_ID
CHECK_SERVICE_ID

Die Variablen PLUGIN_LIBDIR und CONFIG_PATH werden zum Start des Agenten einmal gesetzt. Die Konfigurationsparameter hierzu lauten plugin_libdir und config_path. Die Variablen CHECK_HOST_ID_ und __CHECK_SERVICE_ID werden immer vor jedem Check immer auf die Host-ID und die Service-ID gesetzt, für die der Check gerade ausgeführt wird. Die Checks von Bloonix verwenden diese Umgebungsvariablen für interne Zwecke.

Parameter: use_sudo

Da der Bloonix-Agent nicht mit root-Rechten läuft, für manche Service-Checks jedoch root-Rechte benötigt werden, kann hier definiert werden, welche Service-Checks mit sudo ausgeführt werden sollen.

Die notwendigen Parameter und Dateien zur Funktionalität von sudo sollten nach der Installtion der Pakete, die Checks enthalten, welche via sudo ausgeführt werden müssen, bereits angelegt sein. Wenn Sie zum Beispiel das Paket bloonix-plugins-sensors installieren, dann werden die Dateien /etc/bloonix/agent/conf.d/check-lm-sensors.conf und /etc/sudoers.d/60_bloonix_check_lm_sensors angelegt, die folgenden Inhalt haben:

cat /etc/bloonix/agent/conf.d/check-lm-sensors.conf
use_sudo check-lm-sensors

cat /etc/sudoers.d/60_bloonix_check_lm_sensors
bloonix ALL=(ALL) NOPASSWD:/usr/lib/bloonix/plugins/check-lm-sensors

Falls Sie Nagios-Plugins einsetzen und diese via sudo ausgeführt werden müssen, dann muss der Nagios-Check in /etc/sudoers eingetragen werden und in der Konfigurationsdatei des Agenten mit dem Parameter use_sudo.

Sektion: server

server {
    host p1.bloonix.de, s1.bloonix.de
    port 5460
    mode failover
    use_ssl yes
    ssl_verify_mode peer

    # Debian / SuSE / SLES
    ssl_ca_path /etc/ssl/certs

    # Red Hat / CentOS / Fedora
    ssl_ca_file /etc/pki/tls/certs/ca-bundle.crt
}

Parameter

Sektion: logger

Hier findet die Konfiguration des Logger statt. Weitere Informationen zu den Einstellungsmöglichkeiten finden Sie unter
http://search.cpan.org/dist/Log-Handler/ .

logger {
    file {
        filename /var/log/bloonix/
        filelock 0
        maxlevel info
        minlevel emerg
        timeformat %b %d %Y %H:%M:%S
        message_layout [%T] %L %P %t %X %Y %m (%C)
    }
}

Sektion: env

Hier können globale Umgebungsvariablen gesetzt werden.

env {
    NAME value
}

Sektion: host

host {
    host_id 12345
    password secret
}

Parameter: env

Mit diesem Parameter können Umgebungsvariablen der Checks eines Hosts geändert werden.

host {
    host_id 12345
    password secret
    env {
        PATH /usr/local/bin
    }
}

Parameter: execute_on_event

Manchmal kann es hilfreich sein, wenn man auf dem Server, der überwacht wird, bei bestimmten Ereignissen ein Skript ausführen kann. Nehmen Sie zum Beispiel an, dass Sie ein selbstgeschriebenes Skript ausführen möchten, sobald der Status für einen Service CRITICAL oder UNKNOWN ist. Die Einrichtung sieht beispielhaft wie folgt aus:

host {
    host_id 12345
    password secret
    execute_on_event {
        $service_id { # "$service_id" bitte mit der Service-ID ersetzen
            status CRITICAL, UNKNOWN
            command /usr/local/bin/my-script %I %C %S
        }
    }
}

In der Untersektion execute_on_event wird zunächst das Kommando oder die Service-ID angegeben. Im Weiteren muss angegeben werden, für welchen Status das Skript, welches unter command angegben wird, ausgeführt werden soll. Die Platzhalter %I, %C und %S werden wie folgt ersetzt:

Parameter: when

Mit dem Parameter when ist es möglich, ein Shell-Kommando auszuführen. Wenn der Exitstatus des Kommandos 0 ist, dann wird der Host überwacht. Beispiel:

host {
    host_id 12345
    password secret
    when test -e /tmp/active.test
}

In diesem Fall würde der Host mit der ID 12345 nur von dem Agenten geprüft werden, wenn die Datei /tmp/active.test existiert.