Wer sein System permanent überwacht, hat den Grundstein dafür gelegt Engpässe zu vermeiden und Fehler frühzeitig zu erkennen. Neben dem Platzhirsch Nagios ... (mehr)

Monitor- und Status-Operation

Eines der sehr angenehmen Features von Pacemaker ist die Möglichkeit, eine Ressource im Hinblick auf ihren Status zu untersuchen; das geschieht mittels der »Monitor« -Operation. Der Resource Agent muss, wenn Pacemaker ihn mit dem »monitor« -Target aufruft, überprüfen, ob das jeweilige Programm so läuft, wie es in der Ressourcen-Konfiguration vorgeschrieben ist. Meistens fällt deshalb die Überprüfung mehrerer Faktoren an. Im Falle von Asterisk ist die Monitor-Funktion über zwei Funktionen im OCF-Agent realisiert. Einerseits überprüft die »asterisk_status« -Funktion, ob ein Prozess vorhanden ist, der dem Eintrag in Asterisks PID-File entspricht und ob ein zu dieser Instanz gehörender »astcanary« -Prozess vorhanden ist. »asterisk_monitor« findet außerdem heraus, ob der Asterisk-Prozess auf eine Anfrage über die Asterisk-Console antwortet und testet darüber hinaus, ob eine Test-Anfrage mittels »sipsak« funktioniert.

Sonderfall Astcanary

Anhand von Asterisk lässt sich gut nachvollziehen, wie mit Sonderfällen bei der Status-Abfrage umzugehen ist. Wenn Asterisk im Realtime-Modus läuft, muss zusätzlich zum eigentlichen »asterisk« -Prozess auch »astcanary« laufen. Astcanary aktualisiert den Timestamp einer Datei mit dem etwas schrägen Namen »alt.asterisk.canary.tweet.tweet.tweet"« , die im Asterisk-Status-Ordner liegt, im Sekundentakt. Solange diese Timestamp-Änderung stattfindet, läuft Asterisk im Realtime-Modus. Hört die Timestamp-Aktualisierung auf, wechselt Asterisk in den normalen Modus zurück. Setzt der Cluster-Admin den Parameter »realtime« auf »yes« , muss also zusätzlich zu Asterisk auch der Status von »astcanary« überprüft werden – denn wenn Astcanary nicht läuft, liefe auch Asterisk nicht mehr so, wie konfiguriert, und der Resource Agent müsste bei einer Status-Abfrage einen Fehler zurückgeben.

Anhand von Asterisk lässt sich auch gut demonstrieren, wie mit Programmen umzugehen ist, die die Angabe ihrer Status-Files (PID-File, Socket für die Verbindung von externen Programme) nicht per Parameter an das eigentliche Binary unterstützen. Asterisk kennt keinen entsprechenden Parameter.

Das File, das die PID einer gerade laufenden Asterisk-Instanz enthält, heißt stets » asterisk.pid« und liegt im Asterisk-Rundir. Wo das Rundir liegt, steht in der Asterisk-Konfigurationsdatei, die Variable heißt »astrundir« . Konkret ist es im Falle des Asterisk-Agents also empfehlenswert, zuerst eine Variable zu definieren, die den Wert für »astrundir« enthält. Die Definition dieser Variable gehört ans Ende des Resource Agents und kann dann etwa so aussehen:

ASTRUNDIR=`grep astrundir $OCF_RESKEY_config | awk '/^astrundir/{print $3}'`

Zusätzlich empfiehlt es sich auch, den Wert von »astlogdir« in einer eigenen Variablen zu speichern, denn der wird beim Programmstart gebraucht. Die Definition ist analog zu »astrundir« :

ASTLOGDIR=`grep astlogdir $OCF_RESKEY_config | awk '/^astlogdir/{print $3}'`
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 /2021