Tag: nagios

mein opsview hat die tage wieder mal gestreikt. ich erinnerte mich, doch irgendwo schonmal was aufgeschrieben zu haben. in den entwuerfen meines blogs bin ich fuendig geworden. wie man am datum der logeintraege sehen kann, ists schon ein paar tage her. ich hab das ganze mal aktualisiert und voila.. da isses:

####

heute morgen hat mein nagios bzw. opsview seinen dienst quittiert. im logfile waren solche eintraege zu finden:

[2015/04/12 02:09:45] [import_ndologsd] [FATAL] Error for 1428796429.397065 in handle_SERVICECHECKDATA: Insert failed: The table ‘nagios_servicechecks’ is full
[2015/04/12 02:09:45] [import_ndologsd] [WARN] Failed to import 1428796429.397065
[2015/04/12 02:09:45] [import_ndologsd] [FATAL] Error for 1428796433.896315 in handle_SERVICECHECKDATA: Insert failed: The table ‘nagios_servicechecks’ is full
[2015/04/12 02:09:45] [import_ndologsd] [WARN] Failed to import 1428796[2015/04/12 07:38:50] [nrd] [WARN] 2015/04/12-07:38:50 Server closing!

ok, die mysql datenbank ist 22GB gross und die tabelle ‘nagios_servicechecks’ hat rund 60 millionen eintraege. was der limitierende faktor war, konnte ich auf die schnelle nicht rausfinden. normalerweise sollten in dieser tabelle nur daten von einer woche vorgehalten werden. also in mysql den befehl ausfuehren:

DELETE FROM nagios_servicechecks WHERE start_time <= '2014-07-01 00:00:00';

ursache: fehlende cronjobs! bei der letzten migration auf einen anderen server sind die entsprechenden crontab eintraege fuer den nagios user "verloren" gegangen.
dieser cronjob sollte fuer den user nagios eingerichtet sein:

11 4 * * * . /usr/local/nagios/bin/opsview_master_housekeep

heute wollte ich einen db server mit opsview (core) ueberwachen. das normale host template “Database – MySQL” funktionierte tadellos. als ich das etwas umfangreichere “Database – MySQL Server” angeschaltet habe, gabs nur fehler. der status war bei allen “(Return code of 255 is out of bounds)”

nachdem ich dann erst einmal rausgefunden habe, wie man den mysql check überhaupt konfiguriert:

…war das ergebnis noch nicht besser. also mal husch den check mit einem beliebigen parameter auf der commandline ausgefuehrt mit folgendem ergebnis:

root@nagios:~# /usr/local/nagios/libexec/check_mysql_performance -H db.int.domain.tld -u opsview -p mypassword --metricname=Connections -w 20 -c 30
Goto undefined subroutine &Carp::shortmess_real at /usr/share/perl/5.10/Carp.pm line 41.

die loesungen bei google waren recht uebersichtlich. eines hat jedoch die erhoffte abhilfe geschaffen. in der datei /usr/local/nagios/libexec/check_mysql_performance muss folgende ergaenzung gemacht werden (“use Carp::Heavy;” an der richtigen stelle eingefuegt):

[...]
use strict;
use warnings;
use FindBin qw($Bin);
use Carp::Heavy;
use lib "$Bin/../perl/lib", "/usr/local/nagios/libexec";
use Nagios::Plugin;
[...]

im hintergrund sind die knapp 40 weiteren checks natuerlich fleissig weiter gelaufen, so dass ich beim naechsten test folgende meldung bekam:

root@nagios:~# /usr/local/nagios/libexec/check_mysql_performance -H db.int.domain.tld -u opsview -p mypassword --metricname=Connections -w 20 -c 30
DBI connect('host=db.int.domain.tld','opsview',...) failed: Host 'nagios.int.domain.tld' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts' at /usr/local/nagios/libexec/check_mysql_performance line 477

hmm… sind also so viele fehler aufgetreten, dass der mysql server die anfragen erstmal blockiert hat. im normalen nagios logfile steht nicht wirklich was aussagekraeftiges drin. also debugging einschalten, in dem man in der datei /usr/local/nagios/etc/nagios.cfg diese zeiel angepassen und opsview neu starten:

[...]
debug_level=16
[...]

dann wird in die datei /usr/local/nagios/var/log/nagios.debug protokolliert. und siehe da…

[1380044880.745551] [016.0] [pid=8622] ** Handling check result for service 'MySQL SSL Session cache overflows' on host 'db.int.domain.tld' from 'Core Worker 8626'...
[1380044880.745588] [016.1] [pid=8622] HOST: db.int.domain.tld, SERVICE: MySQL SSL Session cache overflows, CHECK TYPE: Active, OPTIONS: 0, SCHEDULED: Yes, RESCHEDULE: Yes, EXITED OK: Yes, RETURN CODE: 13, OUTPUT: (No output on stdout) stderr: can't write into /tmp/nagios_mysql_perf_db.int.domain.tld_a3sApVWRDav1..tmp: Permission denied at /usr/local/nagios/libexec/check_mysql_performance line 597.

aha… also permission denied auf die datei “/tmp/nagios_mysql_perf_db.int.domain.tld_a3sApVWRDav1..tmp”
das ist so, weil ich vorher den check als root ausgefuehrt habe. deswegen ist der besitzer nun root und der user nagios kann die datei nicht loeschen.

root@nagios:~# ls -lisa /tmp/
total 68
5406721  4 drwxrwxrwt  6 root   root    4096 Sep 24 19:50 .
      2  4 drwxr-xr-x 21 root   root    4096 Jan 28  2013 ..
[...]
5406744 12 -rw-r--r--  1 root   root    8194 Sep 24 19:38 nagios_mysql_perf_db.int.domain.tld_a3sApVWRDav1..tmp
5406731  8 -rw-rw-r--  1 nagios nagios  7657 Sep 24 19:51 nagios_mysql_perf_localhost_a3HhY0MKWDmPo.tmp
[...]

also hurtig loeschen und schon funktioniert die sache wieder.

bei einem dutzend checks musste ich die standardwerte fuer die alarme in den checks anpasssen, da diese total daneben waren. vielleicht muss ich auch ein paar der cheks raus schmeissen, weil total irrelevant fuer meine zwecke. schauen wir mal…

als notiz fuer mich selbst… die nagios plugins fuer remote checks ueber ssh nicht einfach von einem server zum anderen kopieren, denn der nagios server koennte ein 32 bit system sein und der zu ueberwachende ein 64 bit system.

da kommt naemlich sowas raus:

-su: /pfad/nagios/plugins/check_disk: No such file or directory

obwohl die datei genau dort liegt… und man googled sich zu tode. die 1,5 stunden bloede suche haette ich auch im bett verbringen koennen.

wie manche mitbekommen haben, bin ich in bezug auf smartphones (zumindest vorruebergehend) auf die dunkle seite der macht gewechselt und habe mir ein iphone zugelegt.

ab und zu brauche ich ein nagios und ein otrs, was ich nun auch endlich statt mit dem browser auch als app auf dem handy benutzen kann. fuer den blackberry gibts komischerweise nichts gescheites fuer nagios. ausserdem bin ich von nagios abgekommen und nutze nun opsview zur ueberwachung von servern. fuer opsview gibts mittlerweile auch eine android app, aber ich hab jetzt momentan kein android phone mehr. fuers iphone gibts den inag ngios viewer, welcher uebrigens noch den charme hat, dass nicht direkt aufs nagios bzw. opsview zugegriffen wird. das funktioniert naemlich ueber ein stueck php, welches man auf irgendeinen webserver installiert, der zugriff auf die nagios logs etc hat. der zugriff wird ueber einen key, basicauth und ssl abgerundet. ok, die app kostet 11,99 euro, aber gut gepflegt und das geld wert.

hier ein paar screenshots zur tactical overview, services und dem eventlog (anklicken zum vergroessern):

und dann noch die geniale otrs iphone app, welche uebrigens kostenlos ist. die einzige vorraussetzung ist das installierte iphone handle auf dem otrs server. endlich bequem tickets bearbeiten, ohne dafuer die weboberflaeche auf einem viel zu kleinen bildschirm bemuehen zu muessen… (anklicken zum vergroessern)

jetzt fehlt nur noch ein iphone mit einem richtigen akku.

auf meinem quasi frischen nagios server ist gleich das erste update auf die nase gefallen.

Preparing to replace opsview-core 3.13.0.6479-1squeeze1 (using .../opsview-core_3.13.1.6691-1squeeze1_all.deb) ...
Environment not set - have you run 'su - nagios'?
invoke-rc.d: initscript opsview, action "stop" failed.
dpkg: warning: subprocess old pre-removal script returned error exit status 2
dpkg - trying script from the new package instead ...
Environment not set - have you run 'su - nagios'?
invoke-rc.d: initscript opsview, action "stop" failed.
dpkg: error processing /var/cache/apt/archives/opsview-core_3.13.1.6691-1squeeze1_all.deb (--unpack):
 subprocess new pre-removal script returned error exit status 2
configured to not write apport reports
                                      Nagios already running
invoke-rc.d: initscript opsview, action "start" failed.
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 2
Errors were encountered while processing:
 /var/cache/apt/archives/opsview-core_3.13.1.6691-1squeeze1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

mit ein bischen suchen habe ich auch bald eine loesung gefunden. das problem war, dass die datei .profile im home des user nagios nicht komplett war. scheinbar hat das bei der urspruenglichen installation nicht hingehauen. so kriegt man das wieder auf die reihe:

echo "test -f /usr/local/nagios/bin/profile && . /usr/local/nagios/bin/profile" >> ~nagios/.profile
chown nagios:nagios ~nagios/.profile

schoen, wenn andere schneller sind…

…bloed, dass es nicht funktioniert hat. aber danke fuer den hinweis… ich lass das dann erstmal 😉

mein nagios hat mich geaergert und jedes mal beim konfigurieren von irgendwas einen fehler gespuckt:

Error: Could not stat() command file ‘/var/lib/nagios2/rw/nagios.cmd’!

nach ein bischen googelei wusste ich, dass die feherquellen vielfaeltig sein koennen. am ende brachte mich das auf den richtigen weg:

ls -lisa /var/lib/nagios2/rw/

…brachte zu tage, dass der webserver keinerlei berechtigungen mehr auf das vereichniss /var/lib/nagios2/rw/ hatte (warum auch immer):

164938 4 drwx------ 2 nagios www-data 4096 2010-08-03 23:03 .
164937 4 drwxr-x--- 3 nagios nagios 4096 2008-05-31 18:22 ..
168175 0 prwxrwx--- 1 nagios nagios 0 2010-08-03 23:03 nagios.cmd

also einmal:

chmod g+rwx /var/lib/nagios2/rw

…und gut. flutscht wieder.