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)

Die Status-Operation

Das Listing 6 enthält ein vollständiges Beispiel für eine Status-Operation nach den beschriebenen Vorgaben. Diese überprüft, ob es ein PID-File gibt und ob die darin erwähnte PID tatsächlich im System existiert. Falls das so ist, überprüft sie anhand von »OCF_RESKEY_realtime« , ob der Realtime-Modus aktiviert ist. Falls das der Fall ist, überprüft die Status-Funktion mittels »pgrep« , ob ein zu dieser Asterisk-Instanz gehörender Astcanary vorhanden ist (die vormals erwähnte Datei »alt.asterisk.canary.tweet.tweet.tweet« liegt stets im Asterisk-Rundir). Verlaufen alle Tests positiv, quittiert die Funktion das mit »OCF_SUCCESS« . Läuft Asterisk nicht, gibt die Funktion »OCF_NOT_RUNNING« zurück und entfernt eine eventuell vorhandene PID-Datei. Läuft Asterisk, aber Astcanary trotz Realtime-Modus nicht, kommt ein Fehler mit dem Rückgabewert »OCF_ERR_GENERIC« zurück. Das würde Pacemaker dazu bringen, die Resource neu zu starten. Eine detaillierte Übersicht über alle OCF-Rückgabewerte enthält der Kasten "OCF-Rückgabewerte" .

OCF-Rückgabewerte

Der Rückgabewert, der beim Aufruf eines OCF-Agents mit einem bestimmten Parameter kommt, legt fest, wie Pacemaker den Zustand der Ressource bewertet. Die folgenden Parameter sind die wichtigsten:

OCF_SUCESS: Die durchgeführte Operation war erfolgreich. Verläuft der Start einer Ressource erfolgreich, ist dieser Rückgabewert adäquat – er ist auch zu verwenden, wenn eine »monitor« -Operation durchgeführt wird und die Ressource ordnungsgemäß funktioniert. Der Rückgabewert ist 0.

OCF_NOT_RUNNING: Die Ressource läuft nicht. Der Rückgabewert ist 7.

OCF_ERR_GENERIC: Ein generischer Fehler ist aufgetreten, und Pacemaker wird versuchen, die Ressource zu stoppen und zu starten. Der Rückgabewert ist 1.

Neben diesen drei Parametern gibt es einige weitere, die zum Beispiel die präzisere Angabe von Fehlern ermöglichen. Eine ausführliche Auflistung ist im Resource Agent Developers Guide im Kapitel 3 zu finden.

Übrigens: Die »asterisk_status« ( Listing 7 ) nutzt die OCF-Funktion »ocf_run« , um Binaries aufzurufen. Gegenüber dem direkten Aufruf bietet das den Vorteil, dass alle Kommandozeilenausgaben von »ocf_run« mitgeloggt werden (siehe auch Lasten Logging mit OCF). Beim direkten Aufruf würden diese im Nirvana verschwinden – und mögliche Fehlermeldungen mit ihnen. Wenn ein externes Programm aufzurufen ist, empfiehlt sich daher »ocf_run« .

Logging mit OCF

In den Code-Snipplets der einzelnen Funktionen finden sich diverse Aufrufe von »ocf_log« mit verschiedenen Parametern, die die Relevanz der Ausgaben für den Admin festlegen. Die »Severity« eines »ocf_log« -Aufrufs sorgt dafür, dass im HA-Log die Logeinträge entsprechend markiert werden, sodass ein Admin später gezielt danach suchen kann. Die folgenden Kategorien kennt die Funktion:

debug: Debug-Informationen, die für den normalen Betrieb des Clusters nur von sehr geringer Relevanz sind. Standardmäßig verschluckt der HA-Stack auf den meisten Systemen diese Meldungen und zeigt sie gar nicht erst an.

info: Allgemeine Logging-Informationen, die für den Administrator keinen unmittelbaren Handlungsbedarf signalisieren.

warn: Warnungen, unerwartete Ereignisse, aber die nicht als Fehlermeldung gelten.

err: Fehlermeldungen, an die der OCF-Agent jeweils ein »exit« mit dem dazugehörigen Returnwert anschließen sollte.

crit: Kritische Fehler, die ein Eingreifen des Admins unbedingt und schnell notwendig machen.

Listing 7

Die asterisk_status -Funktion

 

Übrigens: Das Beispiel verwendet die OCF-Funktion »ocf_is_true« , um den Wert des Parameters »realtime« über die Umgebungsvariable »OCF_RESKEY_realtime« abzufragen. Das hat den Vorteil, dass Admins in der CRM-Shell sowohl »realtime=true« als auch »realtime=yes« eintragen können (und ebenso die entsprechenden Negativ-Pendants) – die Funktion »ocf_is_true« erkennt all diese Parameter und verhält sich entsprechend. Würde der Agent »OCF_RESKEY_realtime« direkt per if-Klausel auf einzelne Werte hin überprüfen, würde das in wesentlich mehr Code resultieren.

Die Monitor-Operation

Anders als die Status-Operation überprüft die Monitor-Operation nicht, ob Prozesse vorhanden sind, sondern ob Asterisk auf Anfragen von außen reagiert. Für andere Programme wäre es beispielsweise denkbar, mittels eines Programms wie »telnet« oder »openssl s_client« zu testen, ob auf einem bestimmten Port eine Antwort kommt. Das Asterisk-Binary hat selbst einen Client-Modus, der mit »-c -r« aufzurufen ist. Mithin könnte eine Monitor-Operation für Asterisk aussehen wie in Listing 8 . Es ist übrigens kein Zufall, dass die »asterisk_monitor« -Funktion gleich am Anfang »asterisk_status« aufruft und mit einem Fehler abbricht, falls der Rückgabewert nicht »OCF_SUCCESS« ist. Nach diesem Prinzip muss der Agent später nämlich beim Start mit dem »monitor« -Target nur die »asterisk_monitor« -Funktion laufen lassen.

Listing 8

Die Monitor-Funktion

 

Die erwähnte Funktion »asterisk_rx« ist übrigens eine am Anfang des Agents definierte Hilfsfunktion, die so aussieht:

asterisk_rx() {
 # if $HOME is set, asterisk -rx writes a .asterisk_history there
 (
 unset HOME
 ocf_run $OCF_RESKEY_binary -r -s $ASTRUNDIR/asterisk.ctl -x "$1"
 )
}

Die Funktion überprüft zunächst, ob Asterisk überhaupt läuft (dazu ruft sie wie erwähnt asterisk_status() auf) und bringt dann den Asterisk-Client dazu, auf der Asterisk-Console den Befehl »core show channels count« zu starten. Falls der Administrator ein SIP-URL beim Parameter »sipuri« eingetragen hat, versucht der Agent im Anschluss, eine SIP-Verbindung mit »sipsak« zu dieser URL aufzubauen. Je nach Erfolg der einzelnen Befehle gibt die Funktion 0 oder eine Fehlermeldung zurück.

Die Start-Funktion soll freilich in erster Linie Sorge dafür tragen, dass der Asterisk-Daemon so läuft, wie es in der CRM-Konfiguration vorgesehen ist. Sie muss aber noch mehr leisten: Im OCF-Standard ist vorgesehen, dass sie in solchen Fällen, in denen Asterisk bereits läuft, OCF_SUCCESS zurückgeben muss, also 0. Es wäre dann ohnehin nicht sinnvoll, den Daemon nochmal zu starten, denn das würde höchstwahrscheinlich in einer Fehlermeldung enden. Ein mächtiges Werkzeug, um die Funktion von Asterisk zu testen, ist bereits in Form der »asterisk_monitor« -Funktion vorhanden – diese ruft »start« idealerweise auf und interpretiert deren Rückgabewert entsprechend, bevor die Funktion irgendetwas anderes tut.

comments powered by Disqus
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 /2023