Damit Sie als Admin stets über alle Parameter Ihrer IT Bescheid wissen, befasst sich IT-Administrator im Juni mit dem Schwerpunkt 'Monitoring'. Darin lesen Sie ... (mehr)

Monitoring mit Templates vereinfachen

Das Monitoring umfangreicher Umgebungen ist mit einem erheblichen Vorbereitungsaufwand verbunden. Nun müssen Sie nicht für jeden Host eine eigene Konfiguration anlegen, sondern können sich mit der Verwendung von Templates die Arbeit deutlich vereinfachen. In Templates konfigurieren Sie Items, Trigger und so weiter und weisen die Monitoring-Vorlage dem Host zu. Das hilft auch dabei, die Konfiguration konsistent zu halten.

Zabbix ist mit einer umfangreichen Template-Bibliothek ausgestattet, in der typische Standardeinstellungen hinterlegt sind. Die Vorlagen lassen sich über das Menü "Configuraton / Templates" verwalten. Hier können Sie auch eigene Vorlagen generieren. Die Zuweisung von Hosts beziehungsweise Host-Gruppen und den Templates erfolgt in der Host-Konfiguration. Eine Besonderheit der Template-Funktion: Sie können Verschachtelungen vornehmen und damit beispielsweise in einem Master-Template die Monitoring-Einstellungen bestehender Vorlagen bündeln. Die Verknüpfung nehmen Sie über die Registerkarte "Linked Templates" der Template-Konfiguration vor.

Beim Umgang mit Templates sind einige Dinge zu beachten. Prinzipiell sollten Sie, wo immer es praktikabel und möglich ist, Agenten auf den zu überwachenden Systemen einsetzen. Aber je mehr Systeme Sie überwachen, desto größer wird auch die Zahl der Hosts, bei denen das nicht möglich ist. Sie vereinfachen das Monitoring, wenn Sie ein Template-Set für die Hosts entwickeln, bei denen entweder kein Agent-Einsatz möglich oder notwendig ist. Es ist außerdem nicht sinnvoll, betriebssystemunabhängige mit betriebssystemspezifischen Items in einem Template zu vermengen.

Bild 3: Trigger sind eine der Säulen der Monitoring-Umgebung. Allerdings ist ihre Konfiguration nicht trivial und daher fehleranfällig.

Trigger-Konfiguration

Die Effizienz der Überwachung wird maßgeblich von der Trigger-Konfiguration bestimmt. Erst wenn das Monitoring-System weiß, auf welche Informationen es achten muss und ab welchen Zuständen diese als informativ oder kritisch zu bewerten sind, kann es sein ganzes Potenzial entfalten. Mit Hilfe von Triggern erzeugen Sie komplexe Tests, die Sie in grafischen Auswertungen weiteranalysieren können. Eine einfache Trigger-Konfiguration sieht wie folgt aus:

{server:schlüssel.funktion(parameter)}operator konstante

Was auf den ersten Blick einfach zu verstehen ist, erweist sich bei der praktischen Verwendung als komplex und fehleranfällig. Schon die fehlerhafte Verwendung eines logischen Operators oder einer mathematischen Funktion kann dazu führen, dass Ihnen kritische Ereignisse entgehen. Insbesondere deren Verknüpfung ist ursächlich für manche Fehlkonfigurationen.

Anhand einiger typischer Beispiele wird die Verwendung deutlich. Wenn Sie die Passwortdatei "/etc/passwd" des Systems "www.server.de" auf Änderungen überprüfen wollen, verwenden Sie dafür folgende Konfiguration:

{www.server.de:vfs.file.cksum[/etc/passwd].diff()}=1

Dieser Ausdruck gibt den Wert "TRUE" zurück, wenn die Prüfsumme der Datei "/etc/passwd” sich vom letzten Wert unterscheidet. Entsprechende Konfigurationen sind für weitere wichtige Konfigurationsdateien wie "/etc/inetd.conf" und "/kernel" denkbar.

Die Verfügbarkeit eines SMTP-Server-Clusters ist für die Kommunikation relevant. Mit einem einfachen Ausdruck überwachen Sie zwei SMTP-Server:

{smtp1.server.de:net.tcp.service [smtp].last()}=0 and {smtp2.server.de:net.tcp.service[smtp].last()}=0

Dieser Ausdruck ist wahr, wenn beide SMTP-Server mit den Adressen "smtp1.server.de" und "smtp2.server.de" nicht erreichbar sind.

Damit eine korrekte zeitliche Einordnung der Monitoring-Daten möglich ist, müssen die Clients, der Datenbankserver und der Zabbix-Server die identische Zeitkonfiguration verwenden. Das prüfen Sie mit Hilfe der Funktion "fuzzytime()". Die nachfolgende Konfiguration kann die Grundlage für eine Alarmierung bilden, wenn sich die Zeiteinstellung des MySQL-Datenbank- und der Zabbix-Server um mehr als 10 Sekunden unterscheiden:

{MySQL_DB:system.localtime.fuzzytime(10)}=0

Eine häufig genutzte Möglichkeit stellt der Vergleich der Server- beziehungsweise Systemlast dar. Eine übermäßig höhere Last im Vergleich zu einem Vortag ist immer ein Hinweis darauf, dass bestimmte Dinge nicht rund laufen. Sie könnten beispielsweise die durchschnittliche Last der letzten Stunden mit der des Vortags vergleichen:

{server:system.cpu.load.avg(1h)}/{server:system.cpu.load.avg(1h,1d)}>2

Diese Trigger-Konfiguration löst einen Alarm aus, wenn die Last doppelt so hoch wie am Vortag ist.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2022