| 17.1 | Warum Monitoring? |
Vertrauen ist ja bekanntermaßen zwar gut, aber Kontrolle doch immer besser – insbesondere bei IT-Systemen. Das gilt daher auch für den LDAP-Dienst. Dieser ist schließlich in den meisten Fällen von zentraler Bedeutung. Und da sollten Sie schon rechtzeitig wissen, wenn es einem der Server Ihrer LDAP-Umgebung schlecht geht, damit Sie rechtzeitig gegensteuern können. Zunächst müssen Sie dem LDAP-Server mitteilen, dass er seine Leistungsdaten in Form von (wie könnte es auch anders sein) LDAP-Objekten bereitstellt. Im Anschluss richten Sie dann in Ihrem Monitoring-System die entsprechenden Plug-ins ein, um diese Daten regelmäßig abzufragen. Wir zeigen dies am Beispiel von Munin. Aber auch andere Monitoring-Systeme wie checkmk haben entsprechende Möglichkeiten.
| 17.2 | cn=monitor |
Die Arbeit, Leistungsdaten zu sammeln und bereitzustellen, übernimmt ein separates Backend: back_monitor. Dieses sammelt diverse Leistungsdaten des LDAP-Service und legt diese in einer eigenen Datenbank unter einem separaten Kontext cn=monitor ab.
Das Laden des entsprechenden Moduls und das Anlegen der Datenbank können Sie über die dynamische OLC-Konfiguration mit folgenden LDIF-Dateien aus Listing 17.1 durchführen:
Listing 17.1 Einrichten des Monitorings über OLC
dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: back_monitor dn: olcDatabase=monitor,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top olcDatabase: monitor
Hinweis: Das back_monitor-Backend benötigt die Erweiterungen aus dem core.schema. Stellen Sie sicher, dass dies geladen ist.
Damit nicht jeder von außen auf die gesammelten Daten zugreifen kann, sollten Sie die Datenbank mit entsprechenden ACL-Einträgen versehen. Dazu empfiehlt sich das Anlegen eines eigenen Benutzers. Legen Sie also einen Benutzer an wie beispielsweise in Listing 17.2 und vergeben diesem Leserechte auf der neuen Datenbank:
Listing 17.2 Absicherung der Monitoring-Daten
dn: ou=systemkonten,dc=example,dc=net changetype: add objectClass: organizationalUnit ou: systemkonten dn: cn=monitoring,ou=systemkonten,dc=example,dc=net changetype: add objectClass: top objectClass: person cn: monitoring sn: Monitor userPassword: $argon2i$v=19$m=4096,t=3,p=1$4oCdbW9uaXRvcnBhc3N3b3Jk4oCd$6p/ pKzVMmWmmukUQmbq+VeSaoKe+VPgIDlizbE530lk #Kennwort: kontrolle dn: olcDatabase={1}monitor,cn=config changetype: modify add: olcAccess olcAccess: to dn.subtree="cn=monitor" by dn.base="cn=monitoring,\ ou=systemkonten,dc=example,dc=net" read
Hinweis: Je nachdem, wie Sie die Berechtigungen für die beiden Kontexte dc=example,dc=net und cn=config gesetzt haben, müssen Sie die beiden Änderungen aus Listing 17.2 eventuell mit zwei verschiedenen Benutzern durchführen.
Hinweis: Natürlich müssen Sie Ihrem neuen Benutzer monitoring noch ein Kennwort vergeben. Dies sollte möglichst komplex sein. Damit Ihr Monitoring später dauerhaft funktioniert, sollten Sie eine eigene Kennwortrichtlinie für diesen Benutzer erstellen, die sicherstellt, dass das Kennwort nicht abläuft. Ansonsten schlägt Ihr Monitoring irgendwann fehl. Alternativ richten Sie sich beispielsweise einen regelmäßigen Termin im Kalender ein, zu dem Sie das Kennwort des Benutzers und die Konfiguration Ihres Überwachungs-Tools ändern.
Jetzt sind Sie in der Lage, mit dem angegebenen Benutzer unter dem Kontext cn=monitor Informationen des laufenden slapd-Prozesses und der LDAP-Datenbanken abzufragen.
Die Werte sind unterhalb des Kontexts hierarchisch angeordnet. Im Apache Directory Studio stellt sich dies wie in folgendem Bild 17.1 dar:
Bild 17.1 Die Kategorien in cn=monitor
In Bild 17.2 werfen wir einen Blick auf die Informationen, welche zu den Operationen geliefert werden:
Bild 17.2 Informationen zu den Operationen
Gehen Sie noch einen Schritt weiter und schauen sich wie in Bild 17.3 beispielsweise die Anzahl der Suchen an, welche bislang durchgeführt wurden.
Was hier nun aber fehlt, sind Messwerte. Die verbergen sich als Werte, welche vom System selbst geändert werden, hinter den operationalen Attributen. Daher müssen Sie diese wie in Bild 17.4 noch abrufen.
Bild 17.3 Informationen zu durchgeführten Suchen
Bild 17.4 Operationale Attribute abrufen
Bild 17.5 Alle Informationen zu den Suchen
Dann sehen Sie das Ergebnis wie hier in Bild 17.5. Da haben wir es also: 120 Suchen wurden initiiert, 119 beendet.
Wenn Sie nun wissen, welche Attribute von welchem Messobjekt Sie benötigen, können Sie damit gezielte Abfragen auf der Kommandozeile oder über eigene Skripte absetzen. Einige Beispiele dafür finden Sie in Listing 17.3:
Listing 17.3 Beispiele für gezielte Abfragen
provider01:~$ ldapsearch -D "cn=monitoring,ou=systemkonten,dc=example,dc=net" \ -W -b "cn=Start,cn=Time,cn=Monitor" -LLL monitorTimestamp dn: cn=Start,cn=Time,cn=Monitor monitorTimestamp: 20221202204447Z provider01:~$ ldapsearch -D "cn=monitoring,ou=systemkonten,dc=example,dc=net" \ -W -b "cn=Active,cn=Threads,cn=monitor" -LLL monitoredInfo dn: cn=Active,cn=Threads,cn=Monitor monitoredInfo: 1 provider01:~$ ldapsearch -D "cn=monitoring,ou=systemkonten,dc=example,dc=net" \ -W -b "cn=Entries,cn=Statistics,cn=monitor" -LLL dn: cn=Entries,cn=Statistics,cn=Monitor monitorCounter: 589
Mit diesem Handwerkszeug ausgestattet können Sie nun zum Beispiel über Cronjobs Ihre LDAP-Services überwachen, Werte in Datenbanken hinterlegen, auswerten und bei Erreichen von kritischen Werten entsprechend reagieren. Allerdings können Ihnen Überwachungs-Tools hier einige Arbeit abnehmen.
| 17.3 | Munin |
Als Beispiel für die Überwachung mit einem zentralen Tool werden wir uns Munin anschauen. Die Architektur und die Funktionalität ist ähnlich der von anderen Tools wie checkmk. Es besteht aus einem oder mehreren Munin-Servern (in unserem Beispiel beschränken wir uns auf einen) und sogenannten Nodes, den zu überwachenden Elementen (in unserem Fall die LDAP-Server). Der Munin-Server sammelt in regelmäßigen Intervallen die Informationen der einzelnen Knoten ein. Diese wiederum können um Plug-ins erweitert werden und unterschiedlichste Informationen an den Server liefern. So kann ein Knoten, auf welchem ein MariaDB-Server aktiv ist, über ein entsprechendes Plug-in Informationen zur Datenbank liefern, während ein Apache-Webserver mit einem anderen Plug-in Informationen zu den Aktivitäten auf seinen Webseiten liefert.
Bild 17.6 zeigt Ihnen die Architektur mit einem Munin-Server und drei Knoten:
Bild 17.6 Munin-Architektur
| 17.3.1 | Munin-Server |
Auf dem Munin-Server benötigen Sie einen Webserver und das Munin-Paket. Als Webserver wählen wir in unserem Beispiel den Apache-Webserver. Anpassungen an andere HTTP-Daemons wie NGinx sind allerdings relativ einfach zu bewerkstelligen.
Für die Installation genügt neben dem Webserver das Paket munin. Dabei werden alle nötigen Abhängigkeiten wie RRDtools zum Generieren der Graphen automatisch aufgelöst.
Listing 17.4 Installation der notwendigen Pakete
munin:# apt install munin apache2 Paketlisten werden gelesen . . . Fertig Abhängigkeitsbaum wird aufgebaut . . .Fertig Statusinformationen werden eingelesen . . . Fertig Die folgenden zusätzlichen Pakete werden installiert: [...]
Unter /etc/munin/ befindet sich nach der Installation des munin-Pakets die Konfigurationsdatei apache24.conf. Für diese Datei wird durch die Installation von Munin ein symbolischer Link /etc/apache2/conf-available/munin erstellt. In Listing 17.5 sehen Sie den Inhalt der Datei:
Listing 17.5 Apache-Konfiguration für Munin
ScriptAlias /munin-cgi/munin-cgi-graph /usr/lib/munin/cgi/munin-cgi-graph Alias /munin/static/ /var/cache/munin/www/static/ <Directory /var/cache/munin/www> Require all granted Options None </Directory> <Directory /usr/lib/munin/cgi> Require all granted <IfModule mod_fcgid.c> SetHandler fcgid-script </IfModule> <IfModule !mod_fcgid.c> SetHandler cgi-script </IfModule> </Directory> Alias /munin /var/cache/munin/www ScriptAlias /munin /usr/lib/munin/cgi/munin-cgi-html
Um die Ausgaben von Munin zu erreichen, müssen Sie diese Konfiguration lediglich nach der Installation der Pakete mit a2enconf munin aktivieren.
Listing 17.6 Aktivieren der Munin-Konfiguration für den Apache-Webserver
munin:# a2enconf munin Enabling conf munin. To activate the new configuration, you need to run: systemctl reload apache2 munin:# systemctl reload apache2
Wichtig: Über den Apache-Service haben Sie nun sämtliche Möglichkeiten, den Zugriff auf Ihren Munin-Service abzusichern. Zunächst empfiehlt sich eine Verschlüsselung über HTTPS. Vor allem aber sollten Sie die Zugriffsmöglichkeiten auf IP-Adressen und/oder Benutzer einschränken.
Sobald der munin-Dienst und der Apache-Webserver (neu) gestartet wurden, können Sie unter http://<IhrServer>/munin den Server aufrufen. Allerdings müssen Sie sich ein bisschen gedulden. Die ersten Werte tauchen standardmäßig erst nach etwa fünf Minuten auf. Dies ist das Standardintervall, in welchem der Server die Knoten abfragt.
Wie Sie Munin nach dem ersten Start begrüßt, sehen Sie in Bild 17.7:
Bild 17.7 Erster Blick auf Munin
Der Server trägt sich als ersten Knoten ein und überwacht dabei Standardparameter wie
Festplatte
Netzwerk
Prozesse
CPU
Hauptspeicher
Das Intervall der Abfragen können Sie ebenfalls über den Cronjob ändern, welcher mit der Datei /etc/cron.d/munin konfiguriert wird. Einen Eintrag finden Sie in Listing 17.7:
Listing 17.7 Cronjob auf dem Munin-Server
*/5 * * * * munin if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi
Die Konfiguration des Munin-Dienstes an sich erfolgt in der Datei /etc/munin/munin.conf.Dort sind zunächst die diversen Pfade festgelegt. Listing 17.8 zeigt Ihnen ein Beispiel für diese Datei:
Listing 17.8 Konfigurierte Pfade des Munin-Servers
dbdir /var/lib/munin htmldir /var/cache/munin/www logdir /var/log/munin rundir /var/run/munin
Insbesondere die Pfade dbdir, htmldir und logdir sollten Sie für eine Sicherung vorsehen. Im dbdir befinden sich sämtliche gesammelten Werte und daraus generierten RRD-Graphen, htmdir enthält die dynamisch generierten HTML-Seiten, und im logdir finden Sie die Protokolle der diversen Munin-Prozesse.
Wie Sie oben gesehen haben, richtet der Munin-Server sich selbst während der Installation als Knoten ein und überwacht sich somit selbst. Den entsprechenden Eintrag finden Sie in Listing 17.9:
Listing 17.9 Eintrag des Servers als Munin-Knoten
[munin.example.net] address 127.0.0.1 use_node_name yes diskstats_latency.contacts no
An dieser Stelle könnten Sie Ihre LDAP-Server hinzufügen. Wir empfehlen Ihnen aber, sich unter /etc/munin/munin-conf.d eine eigene Datei anzulegen, damit Ihre Einstellungen nicht zum Beispiel durch Updates überschrieben werden. Die Dateien in diesem Verzeichnis werden über das Statement includedir /etc/munin/munin-conf.d in der Datei /etc/munin/munin.conf mit eingebunden. Listing 17.10 zeigt Ihnen ein Beispiel für einen einfachen Eintrag für zwei neue Knoten:
Listing 17.10 Beispiel eines eingetragenen Munin-Knotens
[provider01.example.net] address provider01.example.net [provider02.example.net] address provider02.example.net [lb.example.net] address lb.example.net
Hinweis: Der Munin-Server wird nun natürlich in seinen Protokollen bei jedem Intervall Fehlermeldungen produzieren, solange die eingetragenen Knoten noch nicht eingerichtet sind. Mit der Ergänzung update no in der Konfiguration der noch nicht aktiven Knoten können Sie dies aber vermeiden.
Navigation in der Oberfläche
Auf der linken Seite der Munin-Oberfläche finden Sie zunächst die Möglichkeit, direkt auf die Graphen eventuell problematischer Werte zuzugreifen. Wie Sie diese Schwellwerte für WARNUNGEN und KRITISCHE WERTE festlegen, betrachten wir etwas später. Als Nächstes folgen die GRUPPEN, welche Munin erstellt. Diese Gruppierung erfolgt anhand des Domänenanteils der Server. Daher finden Sie in den vorliegenden Beispielen die Server in einer Gruppe example.net zusammengefasst. Zu guter Letzt können Sie auf die einzelnen KATEGORIEN der gesammelten Leistungswerte zugreifen mit der Möglichkeit, direkt die täglichen (d), wöchentlichen (w), monatlichen (m) oder jährlichen (y) Graphen aufzurufen.
Wählen Sie einen Graphen aus, so erhalten Sie die vier Ansichten mit der täglichen, wöchentlichen, monatlichen und jährlichen Ansicht. Darunter befindet sich meist noch eine Erläuterung der angezeigten Werte inklusive der eingestellten Schwellwerte. In Bild 17.8 sehen Sie die Graphen für die prozentuale Plattenauslastung der einzelnen Mountpoints des Servers:
Bild 17.8 Details der überwachten Werte
(Diesen Graphen hätten Sie auch unter den WARNUNGEN gesehen, da die Warnschwelle von 92% überschritten wurde.)
Wählen Sie an dieser Stelle einen der vier Graphen aus, haben Sie die Möglichkeit zu zoomen. Sie können dazu beispielsweise den Start- und Endzeitpunkt direkt eingeben und auf Update klicken. Eine andere Möglichkeit ist, im Graphen nacheinander die Zeitpunkte mit je einem Mausklick auszuwählen und im Anschluss auf DATEN ABSENDEN zu klicken. Zudem lassen sich noch die Ober- und Untergrenze der y-Achse ändern. In Bild 17.9 sehen Sie die vergrößerte Darstellung eines Graphen und die einzelnen Möglichkeiten zum Verändern der Parameter: Einige Werte fasst Munin in einer Grafik zusammen. Dann kann es bei der automatischen Skalierung passieren, dass Sie einige Graphen einiger Werte in der Grafik nicht sehen, da deren Werte zu gering für die gewählte Skalierung ist. Die Skalierung richtet sich immer nach dem größten Wert im gewählten Zeitintervall. Besitzt in diesem Intervall beispielsweise ein Messwert A irgendwo Werte um 1.000.000, ein anderer anzuzeigender Wert B bewegt sich allerdings im Bereich zwischen 0 und 10, so werden Sie den Graphen von B zunächst nicht sehen. Dazu können Sie in den beiden Feldern LIMIT LOW/HIGH die Unter- und Obergrenze der y-Achse entsprechend der angezeigten Werte aus der Tabelle anpassen.
| 17.3.2 | Knoten |
Da der Munin-Server nun für die Überwachung bereit ist, geht es jetzt um die Einrichtung des Knotens. Zunächst installieren Sie dort das Paket munin-node. Der Dienst wird nach der Installation automatisch gestartet. Stellen sie sicher, dass der TCP-Port 4949 vom Munin-Server aus erreichbar ist. Die Konfiguration des Nodes erfolgt über die Datei /etc/munin/munin-node.conf. Hier müssen Sie mindestens eine Zeile ändern, wie in Listing 17.11 gezeigt, damit der Munin-Server diesen Knoten verwalten kann:
Bild 17.9 Zoomen eines Graphen
Listing 17.11 Zugriffssteuerung für den Knoten
allow ^127\.0\.0\.1\$ allow ^::1\$
Über diese Parameter sichern Sie den Knoten vor ungewollter Überwachung durch andere Munin-Server als Ihren eigenen ab. Tragen Sie also statt 127.0.0.1 bzw. ::1 die IP-Adresse (IPv4 bzw. IPv6) des Munin-Servers ein (wie Sie an dem Beispiel sehen, kommen an dieser Stelle reguläre Ausdrücke zum Einsatz).
Ist der Dienst munin-node neu gestartet und der Knoten auf dem Server eingetragen, dauert es ein paar Minuten (je nach eingestelltem Intervall für den Cronjob auf dem Server), bis der Knoten in der Überwachung auftaucht. Auf Bild 17.6 sehen Sie, wie sich die Startansicht von Munin um zwei LDAP-Server erweitert hat:
Bild 17.10 Weitere Knoten in der Überwachung
Der Knoten ist für die Überwachung auf Plug-ins angewiesen. Die Plug-ins wiederum sind Skripte (Bash-, Perl- oder andere Skripte), welche eine „Munin-lesbare“ Rückgabe liefern. Installiert werden die Skripte im Verzeichnis /USR/SHARE/MUNIN/PLUGINS/. Da nicht alle installierten Plug-ins auf einem Knoten sinnvoll sind (ein Plug-in für MySQL ist z.B. schließlich nur dann sinnvoll, wenn es sich bei dem Server auch um einen MySQL-Server handelt), müssen Plug-ins eventuell noch aktiviert werden. Dazu werden lediglich entsprechende symbolische Links im Verzeichnis /ETC/MUNIN/PLUGINS/ angelegt. Listing 17.12 zeigt Ihnen die standardmäßig aktivierten Plug-ins:
Listing 17.12 Aktivierte Plug-ins
provider01:~# ls -l /etc/munin/plugins/ total 0 lrwxrwxrwx 1 root root 28 Dec 12 08:11 cpu \ -> /usr/share/munin/plugins/cpu lrwxrwxrwx 1 root root 27 Dec 12 08:11 df \ -> /usr/share/munin/plugins/df lrwxrwxrwx 1 root root 33 Dec 12 08:11 df_inode \ -> /usr/share/munin/plugins/df_inode lrwxrwxrwx 1 root root 34 Dec 12 08:11 diskstats \ -> /usr/share/munin/plugins/diskstats lrwxrwxrwx 1 root root 32 Dec 12 08:11 entropy \ -> /usr/share/munin/plugins/entropy lrwxrwxrwx 1 root root 30 Dec 12 08:11 forks \ -> /usr/share/munin/plugins/forks lrwxrwxrwx 1 root root 37 Dec 12 08:11 fw_conntrack \ -> /usr/share/munin/plugins/fw_conntrack lrwxrwxrwx 1 root root 43 Dec 12 08:11 fw_forwarded_local \ -> /usr/share/munin/plugins/fw_forwarded_local lrwxrwxrwx 1 root root 35 Dec 12 08:11 fw_packets \ -> /usr/share/munin/plugins/fw_packets lrwxrwxrwx 1 root root 32 Dec 12 08:11 if_err_eth0 \ -> /usr/share/munin/plugins/if_err_ lrwxrwxrwx 1 root root 28 Dec 12 08:11 if_eth0 \ -> /usr/share/munin/plugins/if_ lrwxrwxrwx 1 root root 35 Dec 12 08:11 interrupts \ -> /usr/share/munin/plugins/interrupts lrwxrwxrwx 1 root root 33 Dec 12 08:11 irqstats \ -> /usr/share/munin/plugins/irqstats lrwxrwxrwx 1 root root 29 Dec 12 08:11 load \ -> /usr/share/munin/plugins/load lrwxrwxrwx 1 root root 31 Dec 12 08:11 memory \ -> /usr/share/munin/plugins/memory lrwxrwxrwx 1 root root 35 Dec 12 08:11 open_files \ -> /usr/share/munin/plugins/open_files lrwxrwxrwx 1 root root 36 Dec 12 08:11 open_inodes \ -> /usr/share/munin/plugins/open_inodes lrwxrwxrwx 1 root root 34 Dec 12 08:11 processes \ -> /usr/share/munin/plugins/processes lrwxrwxrwx 1 root root 33 Dec 12 08:11 proc_pri \ -> /usr/share/munin/plugins/proc_pri lrwxrwxrwx 1 root root 29 Dec 12 08:11 swap \ -> /usr/share/munin/plugins/swap lrwxrwxrwx 1 root root 32 Dec 12 08:11 threads \ -> /usr/share/munin/plugins/threads lrwxrwxrwx 1 root root 31 Dec 12 08:11 uptime \ -> /usr/share/munin/plugins/uptime lrwxrwxrwx 1 root root 30 Dec 12 08:11 users \ -> /usr/share/munin/plugins/users lrwxrwxrwx 1 root root 31 Dec 12 08:11 vmstat \ -> /usr/share/munin/plugins/vmstat
Plug-ins anpassen
Um die Konfiguration eines Plug-ins vorzunehmen, haben Sie prinzipiell fünf Möglichkeiten:
Knoten: Plug-in-Skript unter /USR/SHARE/MUNIN/PLUGINS/
Dies ist etwas für Fortgeschrittene, aber auch verbunden mit der Einschränkung, dass Ihre Änderungen bei dem nächsten Updates voraussichtlich verlorengehen. Von daher nicht empfehlenswert.
Knoten: Konfigurationsdatei /ETC/MUNIN/PLUGIN-CONF. D/MUNIN-NODE
Diese Datei ist die zentrale Datei des Pakets munin-node. Hier könnten Sie Änderungen und Ergänzungen vornehmen. „Könnten“, denn auch diese Datei wird eventuell bei einem Update des munin-node-Pakets überschrieben, und Ihre Anpassungen sind passé.
Knoten: eigene Konfigurationsdateien unter ETC/MUNIN/PLUGIN-CONF. D
Dabei handelt es sich um den empfohlenen Weg. Ob Sie dabei alle Plug-in-Anpassungen in eine einzelne Datei schreiben, nach Themen aufteilen oder für jedes Plug-in eine eigene Datei anlegen, bleibt Ihnen überlassen. Beachten müssen Sie dabei nur, dass die Dateien in diesem Verzeichnis in alphabetischer Reihenfolge eingelesen werden. Stellen Sie also sicher, dass sich Ihre Einstellungen nicht überschneiden oder wählen Sie ein entsprechendes Namensschema.
Server: Konfigurationsdatei /ETC/MUNIN/MUNIN.CONF
Auf dem Server werden (wie unter Listing 17.10 gesehen) die Knoten eingerichtet. In diesem Abschnitt können Sie auch die Parameter für einzelne Plug-ins auf dem jeweiligen Knoten festlegen.
Server: eigene Konfigurationsdatei /ETC/MUNIN/MUNIN.CONF
Wie bei der Konfiguration der Plug-ins können oder sollten Sie die Konfiguration der Knoten in eigene Dateien auslagern, und auch dieses Verzeichnis wird in alphabetischer Reihenfolge abgearbeitet.
Die Reihenfolge dieser Liste entspricht auch der Reihenfolge, in welcher die Einstellungen eingelesen werden.
Ein Beispiel für solch eine Konfiguration auf dem Knoten finden Sie in Listing 17.13. Das munin-Plug-in soll in diesem Beispiel immer mit Benutzer und der Gruppe munin gestartet werden:
Listing 17.13 Plug-in-Konfiguration auf dem Knoten
[munin_stats] user munin group munin
Konfigurieren Sie das Plug-in auf dem Server, dann sähe es ähnlich wie die Einträge in Listing 17.14 aus. Hier konfigurieren Sie das Plug-in im Abschnitt des Servers. Daher müssen Sie dem Parameter, welchen Sie festlegen wollen, noch den Namen des Plug-ins voranstellen:
Listing 17.14 Plug-in-Konfiguration auf dem Server
[provider01.example.com] address provider01.example.com munin_stats.user munin munin_stats.group munin
Um die lokalen Einstellungen auf einem Knoten zu prüfen, gibt es den Befehl munin-run. Ohne Argument werden Ihnen die aktuellen Werte ausgegeben, wie in Listing 17.15 zu sehen:
Listing 17.15 Aktuelle Werte eines Plug-ins
munin:~# munin-run load load.value 5.88
Ergänzen Sie den Befehl um das Unterkommando config, so bekommen Sie die aktuell eingestellten Parameter angezeigt. Das Ergebnis sehen Sie in Listing 17.16:
Listing 17.16 Aktuelle Konfiguration eines Plug-ins
munin:~# munin-run load config graph_title Load average graph_args --base 1000 -l 0 graph_vlabel load graph_scale no graph_category system load.label load graph_info The load average of the machine describes how many processes \ are in the run-queue (scheduled to run "immediately"). load.info 5 minute load average
Es gibt jeweils einen unteren und einen oberen Schwellwert. Der Zustand wird dann jeweils unterhalb des unteren oder oberhalb des oberen Wertes angenommen. Sie können also beispielsweise festlegen, dass bei einem Load unterhalb 0.2 und oberhalb 10 der Zustand Warnung erreicht werden soll. Die Werte tragen Sie dann als Schlüssel-Wert-Paare der Form env.warning <min:max> beziehungsweise env.critical <min:max> ein. Benötigen Sie einen der Werte min oder max nicht, können Sie diesen weglassen, müssen aber den Doppelpunkt mit eintragen. In Listing 17.17 finden Sie einige Beispiele:
Listing 17.17 Schwellwerte für Munin-Plug-ins
[load] env.warning 0.2:10 env.critical 0.1:20
Ein Wert kann zudem noch den Zustand Unknown annehmen, wenn das Plug-in nicht in der Lage war, diesen zu bestimmen. Damit der laufende Dienst munin-node ebenfalls die neuen Werte nutzt, starten Sie ihn einmal neu.
Hinweis: In den Plug-in-Skripten unter /usr/share/munin/plugins/ können Sie jeweils nachlesen, welche Parameter es für das jeweilige Plug-in gibt.
Mailversand und Protokollierung von Alarmen
Um Mails zu versenden, wenn ein Messwert in den Zustand Warnung oder Kritisch kommt, müssen Sie zunächst einmal Kommunikationswege für den Munin-Server definieren. Sie legen dabei fest, wer welche E-Mail bekommen und bei welcher Warnstufe benachrichtigt werden soll. Wie Sie diese Wege festlegen, zeigt Ihnen Listing 17.18:
Listing 17.18 Ziele für Munin-Alarme
contact.ldapadmin.command mail -s "Munin-Alarm für ${var:host}" ldapadmins@example .net contact.ldapadmin.always_send warning critical
In diesem Beispiel teilen Sie Munin mit, eine Nachricht mit dem mail-Kommando und dem Betreff „Munin-Alarm für Server XY“ im Falle von Warnungen und Kritischen Alarmen an ldapadmins@example.net zu senden. Dieser Kommunikationsweg bekommt den Namen ldapadmin. Sie können dabei die Variablen aus Tabelle 17.1 verwenden. Diesen Kommunikationsweg tragen Sie dann in der Konfiguration für den jeweiligen Knoten ein, wie Listing 17.19 zeigt:
Listing 17.19 Munin-Alarm für einen Knoten
[provider01.example.com] [...] contacts ldapadmin
Damit legen Sie fest, welcher Kommunikationsweg für den Knoten provider01 genutzt werden soll.
Tabelle 17.1 Variablen für Munin-Mails
host |
Servername |
group |
Gruppe, zu welcher der Host gehört |
plugin |
Name des Plug-ins, welches die Warnung generiert |
category |
Kategorie des Plug-ins |
extinfo |
erweiterte Information zum Plug-in |
graph_title |
Titel des Graphen |
label |
Label des betroffenen Werts |
value |
aktueller Wert |
wrange |
Schwellen, bis/ab welcher das Level Warnung gilt |
crange |
Schwellen, bis/ab welcher das Level Kritisch gilt |
wfields |
Felder des Plug-ins, welche sich aktuell im Level Warnung befinden |
cfields |
Felder des Plug-ins, welche sich aktuell im Level Kritisch befinden |
ufields |
Felder des Plug-ins, welche sich aktuell im Level Unbekannt befinden |
Erreicht also ein Wert eines Plug-ins auf dem Knoten provider01 das Level Warnung oder Kritisch, so wird das lokale mail-Programm gestartet und eine Mail mit dem entsprechenden Betreff, in diesem Fall zum Beispiel „Munin-Meldung für provider01“, an die hinterlegte E-Mail-Adresse ldapadmins@example.net gesendet.
Auf ähnliche Weise können Sie diese Meldungen auch an den lokalen Syslog-Dienst übergeben. Dazu erstellen Sie einen entsprechenden Kommunikationsweg, wie in Listing 17.20 dargestellt:
Listing 17.20 Syslog-Konfiguration in Munin
contact.syslog.command logger -p local2.crit -t "Munin-Alarm auf Knoten \ ${var::host}: ${var::graph_title}=${var::value}" contact.syslog.always_send warning critical
Damit werden alle auftretenden Alarme als Meldungen der Quelle local2 und der Priorität crit an den lokalen Syslog-Dienst übergeben. Von diesem können die Meldungen dann weiterverarbeitet werden, also entweder lokal in eine (eigene) Datei geschrieben oder an einen zentralen Loghost weitergeleitet werden. Diesen Kommunikationsweg können Sie dann wieder in der Konfiguration des Knotens eintragen, wie in Listing 17.21 gezeigt:
Listing 17.21 Munin-Alarm per Syslog für einen Knoten
[munin.example.com] [...] contacts syslog
| 17.3.3 | OpenLDAP-Daten |
Was uns nun noch fehlt, ist die Überwachung der OpenLDAP-Umgebung. Dazu existieren zwei Plug-ins auf dem Munin-Knoten: slapd_zurÜberwachung des OpenLDAP-Dienstes und slapd_bdb_cache_zur Überwachung der Berkeley-Datenbank. Zur Konfiguration der beiden Plug-ins legen Sie im Verzeichnis /etc/munin/plugin-conf.d/ eine eigene Datei an (beispielsweise slapd) mit dem Inhalt aus Listing 17.22:
Listing 17.22 Konfiguration der OpenLDAP-Plug-ins
[slapd_*] env.server 127.0.0.1 env.binddn cn=monitoring,ou=systemkonten,dc=example,dc=net env.bindpw kontrolle [slapd_bdb_cache_*] user openldap env.dbstat /usr/bin/db5.3_stat
Damit erhält das Plug-in slapd_den Zugriff auf die Daten im Kontext cn=monitor in der LDAP-Datenbank, und das Plug-in slapd_bdb_cache_greift mit dem passenden Tool zur Datenbankprüfung mit einem autorisierten Benutzer auf die Datenbankdatei zu.
Die Plug-ins sind nun konfiguriert und müssen noch aktiviert werden. Geben Sie dazu den Befehl munin-node-configure -suggest auf der Kommandozeile ein. Der Server prüft nun, welche Plug-ins aktiviert sind, welche sinnvoll sind oder wo es Probleme gibt. Für die beiden benötigten Plug-ins werden Sie aber noch Fehler erhalten, wie Sie in Listing 17.23 sehen:
Listing 17.23 Erste Kontrolle der OpenLDAP-Plug-ins
provider01:~# munin-node-configure --suggest Plugin | Used | Suggestions ------ | ---- | ----------- [...] slapd_ | no | no [Net::LDAP not found] slapd_bdb_cache_ | no | no {Can’t execute db_stat file \ ’/usr/bin/db5.3_stat’] [...]
Es fehlen also noch Pakete: für Perl NET::LDAP (zu finden in dem Paket libnet-ldap-perl) und für die Auswertung der Berkeley-Datenbank die entsprechenden Tools (aktuell zu finden in dem Paket db5.3-util ). Installieren Sie eine andere Version als 5.3 der Berkeley Utilities, dann müssen Sie den Eintrag env.dbstat in Listing 17.22 entsprechend anpassen. Eine erneute Prüfung bringt aber noch einen weiteren Fehler:
Hier fehlt noch die Änderung des Pfades zur Datenbank. Die Symas-Version von Open-LDAP legt die Datenbank im Pfad /var/symas/openldap-data ab. Daher müssen Sie in der Plug-in-Konfiguration noch folgende Zeile ergänzen:
Die Prüfung der Plug-ins wird nun erfolgreich sein wie in Listing 17.24:
Listing 17.24 Zweite Kontrolle der OpenLDAP-Plug-ins
provider01:~# munin-node-configure --suggest Plugin | Used | Suggestions ------ | ---- | ----------- [...] slapd_ | no | yes (+connections +operations \ +operations_diff +statistics_bytes +statistics_entries +statistics_pdu \ +statistics_referrals +waiters) slapd_bdb_cache_ | no | yes (+pages +percent) [...]
Sie können damit schon die möglichen Tests sehen, welche von den Plug-ins durchgeführt werden können. Die Plug-ins werden nun als empfohlen, aber noch nicht benutzt gekennzeichnet. Was dem Munin-Knoten nun noch fehlt, teilt Ihnen der Munin-Server mit, wenn Sie ihn danach fragen, welche Befehle Sie noch ausführen müssen. Listing 17.25 zeigt Ihnen, wie:
Listing 17.25 Anzeigen der fehlenden Befehle zur Einrichtung der OpenLDAP-Plug-ins
provider01:/# munin-node-configure --suggest --shell ln -s ’/usr/share/munin/plugins/slapd_’ \ ’/etc/munin/plugins/slapd_connections’ ln -s ’/usr/share/munin/plugins/slapd_’ \ ’/etc/munin/plugins/slapd_operations’ ln -s ’/usr/share/munin/plugins/slapd_’ \ ’/etc/munin/plugins/slapd_operations_diff’ ln -s ’/usr/share/munin/plugins/slapd_’ \ ’/etc/munin/plugins/slapd_statistics_bytes’ ln -s ’/usr/share/munin/plugins/slapd_’ \ ’/etc/munin/plugins/slapd_statistics_entries’ ln -s ’/usr/share/munin/plugins/slapd_’ \ ’/etc/munin/plugins/slapd_statistics_pdu’ ln -s ’/usr/share/munin/plugins/slapd_’ \ ’/etc/munin/plugins/slapd_statistics_referrals’ ln -s ’/usr/share/munin/plugins/slapd_’ \ ’/etc/munin/plugins/slapd_waiters’ ln -s ’/usr/share/munin/plugins/slapd_bdb_cache_’ \ ’/etc/munin/plugins/slapd_bdb_cache_pages’ ln -s ’/usr/share/munin/plugins/slapd_bdb_cache_’ \ ’/etc/munin/plugins/slapd_bdb_cache_percent’
Es fehlen ihm also noch die Verweise in seinem Plug-in-Verzeichnis auf die einzelnen Tests. Sie können die Befehle einzeln aufrufen oder den Server direkt um Ausführung bitten. Wie, zeigt Ihnen Listing 17.26:
Listing 17.26 Ausführen der fehlenden Befehle
munin-node-configure --suggest --shell|bash
Um zu testen, ob die Plug-ins nun auch funktionieren, können Sie folgenden Befehl aus Listing 17.27 absetzen:
Listing 17.27 Test eines OpenLDAP-Plug-ins
provider01:/# munin-run slapd_connections connections.value 1759
Nach der erfolgreichen Aktivierung der Plug-ins starten Sie den Dienst munin-node einmal mit dem Befehl systemctl restart munin-node neu. Auf der Web-Oberfläche des Munin-Services sehen Sie nun (nach dem nächsten Prüfintervall durch den Munin-Server) bei den LDAP-Knoten einen entsprechend openldap-Eintrag. In Bild 17.11 sehen Sie den entsprechenden Eintrag bei den beiden LDAP-Knoten:
Bild 17.11 OpenLDAP-Knoten in Munin
Jetzt, wo alles in Munin eingerichtet ist, schauen wir uns an, welche Daten des OpenLDAP-Services wie in Munin dargestellt werden. In Bild 17.12 sehen Sie die Liste der möglichen Tests eines LDAP-Knotens. In der Tabelle 17.2 sind die Werte erläutert. In Bild 17.13 sehen Sie die Graphen für die einzelnen LDAP-Operationen.
Tabelle 17.2 OpenLDAP
Number of bytes sent |
gesendete Daten pro Sekunde |
Number of Connections |
neue Verbindungen pro Sekunde |
Number of LDAP Entries |
gesendete LDAP-Objekte pro Sekunde |
Number of LDAP Referrals |
gesendete LDAP-Verweise pro Sekunde |
Number of PDUs sent |
Protocol Data Units (LDAP-Nachrichtenblöcke) pro Sekunde |
Number of Waiters |
Anzahl der aktuell wartenden Threads zum Lesen und Schreiben |
Operations |
Übersicht über die einzelnen LDAP-Operationen pro Sekunde (bind, search, add . . . ) |
Operations deviance |
Abweichung zwischen initiierten und beendeten LDAP-Operationen |
Requested pages found in cache |
gefundene Seiten im Cache (Total und in Prozent) |
Bild 17.12 Überwachung von OpenLDAP-Operationen
Bild 17.13 Überwachung von OpenLDAP-Operationen
| 17.3.4 | Überwachung des Loadbalancers |
Die Einrichtung des Monitorings eines Loadbalancers ist nahezu identisch mit der eines LDAP-Servers. Da der Server, welcher als Loadbalancer agiert, keine eigene Datenbank besitzt, entfällt das Plug-in slapd_bdb_cache, mit dem die Performance der lokalen Datenbank überwacht wird. Da der Loadbalancer keine eigene LDAP-Datenbank verwaltet, benötigen Sie darüber hinaus einen weiteren Benutzer. Diesem sind anschließend noch entsprechende Leserechte auf dem Backend monitor zu vergeben. Listing 17.28 zeigt Ihnen exemplarisch einen solchen Benutzer.
Listing 17.28 Anlegen und berechtigen eines Monitoring-Benutzers
dn:olcDatabase={1}monitor,cn=config changetype: modify add: olcRootDN olcRootDN: cn=munin,cn=monitor - add: olcRootPW olcRootPW: $argon2i$v=19$m=4096,t=3,\ p=1$aWVncmVsaXVocmVsaXVo$asLBnNV4C23Fz2r7LahIOzeQF7eI9Oi/Smfh8tiaSpQ - add: olcAccess olcAccess: {0}to dn.subtree="cn=monitor" by dn.exact=cn=munin,cn=monitor read
Eine Konfigurationsdatei für Munin mit dem neuen Benutzer finden Sie dann im folgenden Listing 17.29.
Listing 17.29 Munin-Konfiguration für den Loadbalancer
[slapd_*] env.server 127.0.0.1 env.binddn cn=munin,cn=monitor env.bindpw geheim
Damit können Sie nun auch die Performance des Loadbalancers hinsichtlich Verbindungen, Operationen etc. überwachen. Das lloadd-Module bietet allerdings noch einige weitere Werte hinsichtlich des eigentlichen „Loadbalancings“, wie Sie in Bild 17.14 sehen können. Wie Sie an der obigen Abbildung sehen, liefert der Loadbalancer sehr detaillierte Informationen. Dazu gehören Informationen über die Anzahl der an ihn gestellten, der an einen der Backend-Server weitergeleiteten sowie der über einzelne Verbindungen gesendeten LDAP-Abfragen. Angezeigt werden dabei:
olcIncomingConnections: aktive Verbindungen eines Backends
olcOutgoingConnections: ausgehende Verbindungen des Loadbalancers zu den Backend-Servern
olmActiveConnections: die aktiven Verbindungen zu einem Backend-Server
olmPendingConnections: ausstehende Verbindungen zu einem Backend-Server
olmConnectionState: momentaner Status der Verbindung
olmConnectionType: Art der Verbindung
olmReceivedOps: empfangene LDAP-Operationen
Bild 17.14 Zusätzliche Loadbalancing-Werte für das Monitoring
olmForwardedOps: an einen Backend-Server weitergeleitete Operationen
olmRejectedOps: vom Loadbalancer abgewiesene Anfragen
olmPendingOps: ausstehende LDAP-Operationen
olmCompletedOps: erfolgreich bearbeitete Operationen
olmFailedOps: fehlgeschlagene LDAP-Operationen
Eine Kontrolle, ob der Loadbalancer wie erwartet erfüllt und ankommende Verbindungen wie erwartet verteilt, können Sie zum Beispiel mit ldapsearch absetzen wie in Listing 17.30 zu sehen:
Listing 17.30 Monitor-Abfragen des Loadbalancers
lb:~/Docker# ldapsearch -D cn=admin,cn=monitor -w geheim -b cn=monitor \ -H ldap://localhost:3389 ’(objectClass=olmBalancerServer)’ olmReceivedOps \ olmCompletedOps olmPendingOps -LLL dn: cn=server 1,cn=tier 1,cn=Backend Tiers,cn=Load Balancer,\ cn=Backends,cn=Monitor olmPendingOps: 0 olmReceivedOps: 216730 olmCompletedOps: 216730 dn: cn=server 2,cn=tier 1,cn=Backend Tiers,cn=Load Balancer,\ cn=Backends,cn=Monitor olmPendingOps: 2 olmReceivedOps: 216689 olmCompletedOps: 216687
| 17.4 | Andere Monitoring-Systeme |
Wir haben hier Munin als Monitoring-Lösung gewählt, da Sie mit Munin schnell eine Lösung für ein Monitoring realisieren können. Selbstverständlich können Sie auch andere, bereits in Ihrem Netzwerk eingesetzte Monitoring-Lösungen so konfigurieren, dass das Objekt cn=monitor mit allen Child-Objekten ausgewertet werden kann. Die Vorbereitungen auf den LDAP-Servern und der Datenbank hinsichtlich des monitor-Backends sowie eines Benutzers mit entsprechenden Rechten bleiben identisch.
Für checkmk finden Sie Plug-ins z.B. unter https://pypi.org/project/slapdcheck/ oder https://github.com/seppovic/check_mk-plugins/tree/master/slapd.
Für Nagios gibt es ebenfalls eine Lösung, die Sie unter
https://ltb-project.org/documentation/nagios-plugins/check_ldap_monitor finden.