Die Konfiguration des Servers befindet sich in:
/etc/bloonix/server/main.conf
user bloonix
group bloonix
timezone Europe/Berlin
hostname yourhostname
allow_from 127.0.0.1
elasticsearch_roll_forward /var/log/bloonix/elasticsearch-roll-forward.json
Parameter | Standard | Beschreibung |
---|---|---|
user | bloonix | Mit welchem Benutzer soll der Daemon laufen. |
group | bloonix | Mit welcher Gruppe soll der Daemon laufen. |
timezone | Europe/Berlin | Die Zeitzone des Servers. |
hostname | wird ermittelt | Der Hostname, auf dem der Server läuft. Der Hostname wird automatisch ermittelt, wenn er nicht angegeben ist. |
allow_from | 127.0.0.1 | Dieser Parameter ist vergleichbar mit einer Whitelist. Es können alle vertrauenswürdigen IP-Adressen eingetragen werden, auf denen ein Bloonix-Agent läuft. Den Parameter gibt es auch in der Weboberfläche von Bloonix bei der Einrichtung eines Hosts. Dort können ebenfalls IP-Adressen eingetragen werden, denen es erlaubt ist, Daten für einen Host abzufragen bzw. Daten abzuliefern. |
elasticsearch_roll_forward | /var/log/bloonix/elasticsearch-roll-forward.json | Siehe unten. |
Jedesmal, wenn Elasticsearch nicht erreichbar ist oder ein Fehler auftritt, werden Inserts und Updates in eine Datei geschrieben. Wenn zum Beispiel Elasticsearch nach einem Update einen Cluster-Restart erfordert, landen alle Aktionen in der Datei. Diese Einträge können später importiert werden. Das Kommando hierzu lautet:
bloonix-roll-forward-log
Das Skript läd automatisch die Serverkonfiguration und importiert vorhandene Einträge im Logfile nach Elasticsearch. Das Skript geht dabei wie folgt vor:
Ist das Skript einmal gestartet, sollte es auf keinen Fall gestoppt werden. Das Skript merkt sich zwar, bis zu welcher Zeile die Daten verarbeitet wurden, trotzallem kann zu einem Verlust oder zu doppelten Einträgen kommen, wenn der Verarbeitungsprozess seinen Status nicht erfolgreich auf die Platte schreiben konnte.
In dieser Sektion findet die Verwaltung der Prozesse statt, die der Bloonix-Server startet, um Anfragen zu bearbeiten.
proc_manager {
max_servers 10
min_spare_servers 5
max_spare_servers 8
}
Parameter | Standard | Beschreibung |
---|---|---|
min_spare_servers | 10 | Wieviele Prozesse mit Leerlauf sollen mindestens verfügbar sein. Wenn die Zahl unterschritten wird, werden weitere Prozesse gestartet, solange, bis der Parameter max_spare_servers erreicht ist. |
max_spare_servers | 20 | Wieviele Prozesse mit Leerlauf darf es maximal geben. Wenn die Zahl erreicht ist, werden soviele Prozesse beendet, bis der Parameter min_spare_servers erreicht ist. |
max_servers | 50 | Wieviele Prozesse dürfen maximal gestartet sein. |
max_requests | 0 | Wieviele Requests darf ein Prozess verarbeiten, bis er sich selbst beendet. 0 bedeuted unendlich. |
max_process_size | 1GB | Auf wieviel MB/GB darf ein Prozess maximal wachsen, bis er sich selbst beendet. 0 bedeuted unendlich. Möglich Angaben: xMB, xGB |
timeout | 300 | Wie lange darf ein Requests und dessen Verarbeitung andauern. Nach Ablauf des Timeouts wird die Verarbeitung abgebrochen. |
lockfile | /var/lib/bloonix/ipc/server.%P.lock | Diese Datei wird lediglich zum internen Locking verwendet. |
In dieser Sektion werden die Parameter für den TCP Server konfiguriert. Die Konfiguration ist sehr einfach.
tcp_server {
port 5460
use_ssl yes
ssl_key_file /etc/bloonix/server/pki/server.key
ssl_cert_file /etc/bloonix/server/pki/server.cert
}
Parameter | Standard | Beschreibung |
---|---|---|
host | Die IP-Adresse, auf die der Server lauschen soll. '::' für IPv6. | |
port | Die Portnummer, auf die der Server lauschen soll. | |
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. |
In der Sektion notifications werden die Subsektionen zur Konfiguration von E-Mail und SMS Benachrichtigungen konfiguriert.
notifications {
sms {
command /usr/bin/curl -s https://sms.test?key=SECRET&from=BLOONIX&to=%TO%&message=%MESSAGE%
response ^100$
}
mail {
from subdomain@yourdomain.test
bcc admin@yourdomain.test
subject *** STATUS %s FOR %h (%a) ***
}
}
Parameter | Standard | Beschreibung |
---|---|---|
command | Das Kommando, um eine SMS zu versenden. Die Platzhalter TO und MESSAGE werden URL-encoded mit der Mobilfunknummer und der Warnmeldung ersetzt. | |
response | Die erwartete Antwort, wenn die SMS erfolgreich übersendet werden konnte. Der Wert ist ein regulärer Ausdruck. | |
failover_command | Mit failover_command lässt sich ein weiteres Kommando einrichten, welches aufgerufen wird, wenn das erste Kommando fehlgeschlagen ist. Dies ist sinnvoll, wenn zum Beispiel der Anbieter zur Versendung der SMS nicht verfügbar ist. | |
failover_response | Die erwartete Antwort von failover_command. |
Diese Sektion wird für das Versenden von E-Mails an Kontakte konfiguriert.
Parameter | Standard | Beschreibung |
---|---|---|
sendmail | /usr/sbin/sendmail -t -oi -oem | Kommando zum Versenden von E-Mails. |
from | bloonix@localhost | Die Adresse des Absenders. |
bcc | Mit diesem Parameter ist es möglich, E-Mails an Kontakte als Blindkopie zu erhalten. Zusätzlich erhält der Empfänger eine Kopie jeder SMS, die versendet wurde. | |
subject | *** STATUS %s FOR %h (%a) *** | Hier wird der Betreff konfiguriert. Die Strings %s (Status), %h (Hostname) und %a (IP-Adresse) werden ersetzt. |
Die Sektion redirect_remote_agent_timeouts bietet ein ganz spezielles Feature an, welches nur verwendet werden sollte, wenn Sie Kundenserver über Bloonix überwachen und wenn die Kunden als Kontakt für Benachrichtigungen eingerichtet sind.
Stellen Sie sich folgendes Szenario vor:
Sie bieten Ihren Kunden Monitoring über Bloonix an und haben hierfür einen Agenten eingerichtet, der zum Beispiel per Remote-Check die Webseiten Ihrer Kunden überwacht. Wenn dieser Agent ausfallen würde, dann würden Ihre Kunden nach Ablauf eines Timeouts eine kritische Meldung per E-Mail oder SMS erhalten, da der Service seit mehreren Minuten nicht mehr geprüft wurde. Was hier beachtet werden muss ist, dass weder der Webserver des Kunden ausgefallen ist, noch ein Agent, der auf einem Kundenserver läuft. Der Kunde würde also über einen kritischen Zustand informiert, den der Kunde nicht zu verantworten hat, da in diesem Fall der Agent ausgefallen ist, der auf Ihrem Server und in Ihrem Zuständigkeitsbereich läuft, um die Webseiten Ihrer Kunden zu überwachen.
Um nun zu vermeiden, dass Kunden in diesem Fall fälschlicherweise benachrichtigt werden, gibt es den Parameter mail_to in der Sektion redirect_remote_agent_timeouts. Der Kunde selbst würde keine SMS und auch keine E-Mail mehr für Services erhalten, die mit der Option Standort des Agenten: remote konfiguriert sind, stattdessen würden die Benachrichtigungen per E-Mail an die Adresse umgeleitet, die mit dem Parameter mail_to gesetzt ist.
Die Konfiguration der Sektion ist sehr einfach:
redirect_remote_agent_timeouts {
mail_to foo@example.test
}
Parameter | Standard | Beschreibung |
---|---|---|
mail_to | Die E-Mail-Adresse, zu der Nachrichten umgeleitet werden sollen. |
Möchten Sie diese Funktion nicht einsetzen, so können Sie die Sektion auskommentieren.
In dieser Sektion werden die Parameter für die Datenbank konfiguiert und sind selbsterklärend.
database {
include /etc/bloonix/database/main.conf
#driver Pg
#host 127.0.0.1
#port 5432
#database bloonix
#user bloonix
#password secret
logger {
file {
filename /var/log/bloonix/bloonix-server-database.log
filelock 0
maxlevel info
minlevel emerg
message_layout [%T] %L %P %t %X %Y %m (%C)
}
}
}
Die Konfiguration des Loggers ist identisch zur Konfiguration des Haupt-Loggers weiter unten.
In dieser Sektion werden die Verbindungsparameter zu Elasticsearch konfiguriert.
elasticsearch {
proto http
host 127.0.0.1:9200, 127.0.0.2:9200
timeout 60
mode balanced
}
Parameter | Standard | Beschreibung |
---|---|---|
proto | http | Das Protokoll, unter das Elasticsearch erreichbar ist. |
host | 127.0.0.1 | Der Hostname bzw. die IP-Adresse zu Elasticsearch. Es können mehrere komma-separierte Hosts angegeben werden. |
timeout | 60 | Die maximale Zeit pro Request. Danach wird der Request abgebrochen. |
mode | balanced | Es ist möglich, die Requests auf mehrere Elasticsearch-Server zu verteilen oder aber ein Failover einzurichten. Mögliche Werte sind balanced und failover. |
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/bloonix-server-database.log
filelock 0
maxlevel info
minlevel emerg
timeformat %b %d %Y %H:%M:%S
message_layout [%T] %L %P %t %X %Y %m (%C)
}
}