Die Konfiguration des Agenten befindet sich in:
/etc/bloonix/agent/main.conf
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
Parameter | Standard | Beschreibung |
---|---|---|
agents | 1 | Wieviele Agenten sollen geforkt werden, um die konfigurierten Hosts zu überwachen. |
max_concurrent_checks | 4 | Mit diesem Parameter wird festgelegt, wieviele Checks maximal gleichzeitig für einen Host ausgeführt werden sollen. Der Parameter ist abhängig von der Einstellung des Parameters agents. Wenn der Parameter agents auf 1 gesetzt ist, kann auch immer nur ein Check gleichzeitig ausgeführt werden. |
max_concurrent_hosts | auto | Jeder konfigurierte Host wird in regelmäßigen Abständen gepollt (siehe poll_interval), um zu prüfen, ob Services geprüft werden müssen. Hierzu werden die Hosts in eine Queue gelegt, die von den Agenten abgearbeitet wird. Mit diesem Parameter wird festgelegt, wieviele Hosts maximal gleichzeitig von den Agenten verarbeitet werden. |
poll_interval | 60 | Der Bloonix-Agent pollt für jeden konfigurierten Host den Bloonix-Server standardmäßig alle 60 Sekunden um eine Liste der Services zu erhalten, die er prüfen soll. Dieser Parameter sollte nur dann kleiner gesetzt werden, wenn der Intervall eines Hosts oder von Services kleiner 60 Sekunden ist. |
agent_active_when | 0 | Hier kann ein Shell Kommando hinterlegt werden. Der gesamte Agent ist erst aktiv, wenn dieses Kommando erfolgreich ausgeführt werden konnte (exit 0). Wenn der Parameter auf 0 gesetzt ist, so ist der Parameter deaktiviert. |
user, group | bloonix | Mit diesen Parametern wird bestimmt, mit welchem Benutzer und welcher Gruppe der Agent läuft und die Checks ausführt. |
plugins | /usr/local/lib/bloonix/plugins | Mit dem Parameter plugins wird der Pfad angegben, unter dem die Plugins zur Ausführung liegen. Sollte der Bloonix-Agent über einen Paketmanager installiert werden, so kann der Pfad abweichen. Auf Debian werden die Plugins beispielsweise unter /usr/lib/bloonix/plugins installiert. Unter Windows liegen die Plugins höchstwahrscheinlich im Installationsverzeichnis des Agenten. |
plugin_libdir | /var/lib/bloonix/agent | Unter diesem Pfad legen diverse Plugins Daten ab, um Deltas von statistischen Daten berechnen zu können. |
config_path | /etc/bloonix/agent | Unter diesem Pfad können Plugin-spezifische Konfigurationsdateien abgelegt werden. |
simple_plugins | Falls Sie Nagios-kompatible Plugins einsetzen möchten, so können Sie hier den Pfad zu den installierten Plugins setzen. Eine komma-separierte Liste von Pfaden ist möglich. | |
include | Mit dem Parameter include lassen sich andere Konfigurationsdateien oder sogar Verzeichnisse einbinden. Falls das Ziel ein Verzeichnis ist, so werden alle Dateien darin inkludiert, die mit .conf enden. | |
use_sudo | Welche Checks sollen mit sudo ausgeführt werden. Hier werden nur die Checks Skripte angegeben, ohne Pfade. Es ist möglich mehrere Skripte komma-separiert anzugeben. |
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.
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.
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.
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.
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.
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 | Standard | Beschreibung |
---|---|---|
host | Hier wird eine komma-separierte Liste von IP-Adressen oder Hostnamen eingeben, unter denen der Bloonix-Server erreichbar ist. Die Verbindung zum Bloonix-Server wird zusätzlich über den Parameter mode beeinflusst. | |
port | Die Portnummer, unter welcher der Bloonix-Server erreichbar ist. | |
mode | failover | Mit diesem Parameter wird konfiguriert, wie sich der Client gegen multiple IP-Adressen verbindet. Mit dem Wert failover verbindet sich der Client mit der ersten Adresse. Sollte die erste Adresse nicht verfügbar sein, versucht er die nächste Adresse in der Liste. Es wird immer die Adresse verwendet, die als letztes verfügbar war. Ein Wechsel zur nächsten Adresse findet also nur statt, wenn eine Adresse nicht erreichbar war. Mit dem Wert balanced wird mit jeder Verbindung die nächste Adresse in der Liste verwendet, unabhängig davon, ob eine Adresse verfügbar ist oder nicht. Ist eine Adresse nicht verfügbar, wird zur nächsten Adresse in der Liste gesprungen. Mögliche Werte: failover, balanced |
force_ipv4 | yes | Soll die Verwendung von IPv4 bevorzugt werden. Mögliche Werte: no, yes |
use_ssl | yes | Mit diesem Schalter kann die Verwendung von SSL zur Absicherung der Kommunikation aktiviert oder deaktiviert werden. Mögliche Werte: no, yes |
ssl_ca_file | Die CA Datei, mit der das Zertifikat des Server validiert werdern soll. | |
ssl_ca_path | Der Pfad zu den CA Dateien, mit denen das Zertifikat des Servers validiert werden soll. | |
ssl_cert_file | Die Zertifikatsdatei. | |
ssl_key_file | Die Datei des privaten Schlüssels. | |
ssl_verify_mode | peer | Einstellung, ob das Zertifikat des Servers validiert werden soll. Mögliche Werte: none, peer |
recv_max_bytes | 512k | Die maximale Datenmenge, die pro Request empfangen werden darf. Mögliche Werte: unlimited, Angabe in Bytes, Kilobytes etc., Beispiel: 512k für 512 Kilobytes, 2m für 2 Megabytes |
send_max_bytes | unlimited | Die maximale Datenmenge, die pro Request versendet werden darf. Mögliche Werte: unlimited, Angabe in Bytes, Kilobytes etc., Beispiel: 512k für 512 Kilobytes, 2m für 2 Megabytes |
recv_timeout | 15 | Die Zeitspanne, in der Daten gelesen sein müssen. Die Angabe erfolgt in Sekunden. |
send_timeout | 15 | Die Zeitspanne, in der Daten versendet sein müssen. Die Angabe erfolgt in Sekunden. |
timeout | Wenn dieser Parameter gesetzt ist, überschreibt er den Wert von recv_timeout und send_timeout. | |
connect_timeout | 10 | Die Zeitspanne, in der eine Verbindung aufgebaut sein muss. Die Angabe erfolgt in Sekunden. |
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)
}
}
Hier können globale Umgebungsvariablen gesetzt werden.
env {
NAME value
}
host {
host_id 12345
password secret
}
Parameter | Standard | Beschreibung |
---|---|---|
host_id | Die ID des Hosts, welcher überwacht werden soll. Die ID ist im Webinterface in der Konfiguration des Hosts zu finden. | |
password | Das Passwort des Hosts, welcher überwacht werden soll. Das Passwort ist im Webinterface in der Konfiguration des Hosts zu finden. | |
agent_id | localhost | Jeder Service ist mit einer Agenten-ID gekennzeichnet. Mit dieser Option kann ausgewählt werden, welche Services eines Hosts von diesem Agenten aus überwacht werden. Mögliche Werte sind localhost, intranet und remote. |
active | yes | Mit diesem Parameter kann die Überwachung des Hosts aktiviert oder deaktiviert werden. |
env | Umgebungsvariablen für die Checks dieses Hosts. | |
execute_on_event | Ausführung eines Skripts bei einem bestimmten Status. | |
when | Der Host wird nur überwacht, wenn das Kommando True zurückgibt. |
Mit diesem Parameter können Umgebungsvariablen der Checks eines Hosts geändert werden.
host {
host_id 12345
password secret
env {
PATH /usr/local/bin
}
}
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:
%I | Service-ID |
%C | Das Kommando, was ausgeührt wurde. Beispiel: check-http |
%S | Status des Checks |
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.