KenntWas.de – Technische Tipps

Technische Informationen zu Linux, (Oracle-) Datenbanken und mehr

[Update1] OMD: State Retention der nagios-Plugins in /var/tmp !???

| 6 Comments

OMD PluginsDie Open Monitoring Distribution OMD unterstützt den Betrieb mehrerer Sites auf einem Server. Die Sites laufen jeweils unter einem eigenen Benutzer. Leider verwenden einige nagios-plugins einen absoluten Pfad (/var/tmp/) zum Cachen von Dateien oder als statesdir. Ein Beispiel dafür sind check_oracle_health und check_logfiles, die sich gewisse Informationen zwischen zwei Aufrufen persistent ‘merken’.

Der absolute Pfad führt zu Problemen (Versionsunterschiede und Zugriffsrechte).

check_oracle_health: tablespace-remaining-time

Es gibt mehrere Plugins, die sich den Status zwischen zwei Aufrufen merken müssen.

Hier ein Beispiel für check_oracle_health –tablespace-remaining-time. Drei Sites installiert. Nach dem Update von OMD 0.46 auf OMD 0.48 kam es zu einem Problem.
Das Kommando lieferte einen Fehler, da das Stateddir in /var/tmp/check_oracle_health nicht zur Version passte. In Nagios kommt die Fehlermeldung “no data from plugin”, weil das Plugin mit einem Laufzeitfehler abstürzt.

OMD[mysite]:~$ type check_oracle_health
check_oracle_health ist /omd/sites/mysite/version/lib/nagios/plugins/check_oracle_health

OMD[mysite]:~$ check_oracle_health  --connect=//bigbox:1521/nie1.world \
   --username=nagios --password=secret \
   --mode=tablespace-remaining-time --report=short
Can't use an undefined value as an ARRAY reference at
/omd/sites/mysite/version/lib/nagios/plugins/check_oracle_health line 3145.

Nach dem Löschen des Cache funktioniert der Aufruf wieder.

OMD[mysite]:~$ sudo rm -f /var/tmp/check_oracle_health/*

OMD[mysite]:~$ check_oracle_health  –connect=//bigbox:1521/nie1.world \
–username=nagios –password=secret \
–mode=tablespace-remaining-time –report=short
OK – no problems

Codestelle

Code anzeigen »

3135     if (scalar(@{$self->{usage_history}})) {
3136       $self->trace(sprintf "loaded %d data sets from     %s - %s",
3137           scalar(@{$self->{usage_history}}),
3138           scalar localtime((@{$self->{usage_history}})[0]->[0]),
3139           scalar localtime($now));
3140       # only data sets with valid usage. only newer than 91 days
3141       $self->{usage_history} =
3142           [ grep { defined $_->[1] && ($now - $_->[0]) < $lookback } @{$self->{usage_history}} ];
3143       $self->trace(sprintf "trimmed to %d data sets from %s - %s",
3144           scalar(@{$self->{usage_history}}),
3145           # MN: This will break, if cache in /var/tmp/check_oracle_health is not correct
3146           scalar localtime((@{$self->{usage_history}})[0]->[0]),
3147           scalar localtime($now));
3148     } else {
3149       $self->trace(sprintf "no historical data found");
3150     }
3151     push(@{$self->{usage_history}}, [ time, $self->{percent_used} ]);
3152     $params{save} = $self->{usage_history};
3153     $self->save_state(%params);
3154   }

Das ist nicht unbedingt ein Programmierfehler. Das Plugin bekommt einfach die falschen Dateien (von einer alten Version oder parallel installierten OMD site). Vielleicht stimmen die Rechte auch nicht, da jede Site unter einem anderen Unix-Benutzer läuft.

statefilesdir

Das statefilesdir kann in check_oracle_health nicht per Kommandozeile gesetzt werden. Es wird zur Compiletime (configure) fest vorgegeben.

use vars qw ($PROGNAME $REVISION $CONTACT $TIMEOUT $STATEFILESDIR $needs_restart %commandline);

$PROGNAME = "check_oracle_health";
$REVISION = '$Revision: 1.6.8 $';
...
$TIMEOUT = 60;
$STATEFILESDIR = '/var/tmp/check_oracle_health';
$needs_restart = 0;

Lösungsvorschlag

Das Statefilesdir wird eventuell recht groß und sollte nicht auf der Ramdisk in ~mysite/tmp gespeichert werden. Ausserdem muss es meistens persistent sein.
Zur Zeit kann man es meistens nur beim Compilieren (configure) fest konfigurieren.
Es fehlt also eine Kommandozeilenoption oder eine Umgebungsvariable.

Jede Site sollte aber ihr eigenes statedir für alle Plugins haben, die ein state retention dir brauchen (z.B. ~mysite/var/tmp/plugin-name).

Auf nagiosplugins.org wurde dies schon einmal diskutiert (Nagios Plugin State Retention).

  • Location – use ./configure –sharedstatedir to define, default $PREFIX/var. Override with NAGIOS_PLUGIN_STATE_DIRECTORY envvar at runtime if set. Add plugin name to end
  • Key – Is used as the filename of the store. Default to state.dat. Recommend that this is set to the string returned by np_state_generate_key(), to be unique per plugin call. Key can only consist of alphanumerics and underscore

Vielleicht können die Entwickler sich auf einen Standard für Kommandozeilenparameter und/oder Umgebungsvariable einigen. Umgebungsvariablen müssten dann aber auch von anderen Komponenten, die Plugins aufrufen (mod_gearman, check_multi,..) weitergegeben werden.

Per Kommandozeile könnte man den Plugins dann auch das Verzeichnis übergeben:

$USER1$/check_oracle_healtth --statefilesdir $USER4$/var/temp/check_oracle_health ...

oder

$USER1$/check_oracle_healtth --statefilesdir /var/tmp/$USER3$/check_oracle_health ...

(den Parameter –statefilesdir gibt es noch nicht ab Version 1.6.9).

 

Ein Patchen der plugins fällt als Lösung aus, weil dann die Vorteile von OMD (Kopieren von sites, unterschiedliche Versionen von Sites) verloren gehen.

In OMD sollte das Verzeichnis bei einem Update vielleicht auch noch gelöscht werden um Kompabilitätsprobleme zu vermeiden.

Update1: 16.06.2011: check_oracle_health 1.6.9 verwendet $ENV(OMD_ROOT)

Ab Version 1.6.9 erkennt check_oracle_health durch die Umgebungsvariable OMD_ROOT automatisch, dass das Plugin unter OMD läuft und setzt das statefilesdir auf $ENV(OMD_ROOT)/var/tmp. Damit wird es bei “omd cp” mit kopiert und die Rechte passen wieder (siehe Kommentar von Gerhard ).

Der Mechanismus ist einfach und plausibel. Andere Plugins sollten es ebenso machen.

6 Comments

  1. Hi,
    ich bin letzte Woche auf dem Nagios-Workshop schon auf das Problem angesprochen worden. Ich habe da schlichtweg gepennt, als ich die Plugins in OMD aufgenommen habe. Daß die Statefiles kollidieren können, darf natürlich nicht passieren. Ich werde die Plugins so aufbohren, daß sie erkennen, wenn sie unter OMD laufen und dann entsprechend andere Verzeichisse/Dateinamen benutzen. Ein –statefilesdir für die Datenbank-Plugins ist auch keine schlechte Idee. Bei check_logfiles kann man bereits jetzt ein –seekfilesdir angeben.
    Gerhard

  2. Hi Gerhard,
    ich weiß, weil ich dich vor dem Hotel darauf angesprochen habe :-)
    Ich bin jetzt nur noch einmal drauf gestoßen, weil es bei mir halt zu einem Fehler führte.
    Generell sollte man eine einheitliche Regelung für alle Plugins anstreben.

  3. Unter http://labs.consol.de/nagios/check_oracle_health gibt’s jetzt eine Version 1.6.9 von check_oracle_health. Das Plugin merkt jetzt, wenn es unter einem OMD-Environment ausgeführt wird und verwendet $HOME/var/tmp, also ein site-spezifisches Verzeichnis, das auch bei “omd cp/mv” mitwandert.
    Meine anderen Plugins sind auch schon umgestellt, ich release sie in den nächsten Tagen.

    Gruß,
    gerhard

    • Prima, jetzt stellt sich nur noch die Frage,
      wie Du erkennst, dass das Plugin unter OMD arbeitet.
      Moment …

      Ah, da ist es ja:

      if (! exists $commandline{statefilesdir}) {
        if (exists $ENV{OMD_ROOT}) {
          $commandline{statefilesdir} = $ENV{OMD_ROOT}."/var/tmp/check_oracle_health";
        } else {
          $commandline{statefilesdir} = $STATEFILESDIR;
        }
      }
      

      ——–
      So können es die anderen Plugins dann ja auch machen. Einfach überprüfen, ob die Umgebungs-Variable OMD_ROOT
      gesetzt ist.

  4. Pingback: Die Feature-Liste von check_oracle_health wächst weiter… – ConSol* Labs

  5. Hi,

    ich bin gerade erst auf diesen Beitrag gestossen und wollte nur kurz eine Ergaenzung in Punkto check_multi unter OMD loswerden:

    check_multi verwendet unter OMD schon immer die Variablen OMD_ROOT und OMD_SITE und verhaelt sich dementsprechend anders. Kollisionen der temporaeren Daten sowie State-Daten sind damit nicht moeglich.

    Gruss – Matthias

Leave a Reply

Required fields are marked *.