DPNP (PNP in verteilten Umgebungen)

(Simon Meggle)

Ich empfehle ein solches Setup nicht mehr. Für Distributed Monitoring sollte man sich besser gleich mit mod_gearman/livestatus, Merlin oder Shinken auseinandersetzen.

„Ein RRD-File ist wie guter Wein: je älter, desto wertvoller.“

Zunächst war die nachfolgend beschriebene Vorgehensweise nur als Proof-of-concept für eine neue Nagios-Umgebung gedacht, mit dem ich in drei Nagios-VMs beweisen wollte, dass „distributed Monitoring“ mit „centralized Graphing“ vereinbar ist. In Kombination mit dem Template-Mechanismus ergab sich daraus aber eine durchaus brauchbare Lösung, incl. einiger angenehmer Nebeneffekte. Daraus entstand nun spontan eine (hoffentlich komplette) Anleitung, die den Aufbau eines Distributed Monitoring im Zusammenhang mit PNP erläutert.

Gehen wir zunächst von einer Single-Nagios-Installation mit PNP aus; Zitat aus der PNP-Doku:

Nagios benutzt wieder eine temporäre Datei, um die Daten zu speichern, und führt nach Ablauf der Zeit wieder ein Command auf. Jedoch wird die Datei nicht sofort von Process_perfdata.pl verarbeitet, sondern in ein spool-Verzeichnis verschoben. Da das verschieben einer Datei im gleichen Filesystem so gut wie keine Zeit beansprucht, ist Nagios sofort wieder in der Lage, wichtige Arbeiten auszuführen.
Der NPCD ( Nagios Performance C Daemon ) überwacht nun das Verzeichnis auf neue Dateien und übergibt diese an process_perfdata.pl. Die Verarbeitung der Performancedaten ist also komplett von Nagios entkoppelt. NPCD wiederum ist in der Lage, zum Verarbeiten der Daten mehrere Threads zu starten. —- In einer verteilten Umgebung stellt es an sich kein Problem dar, auch die passiv (=per NSCA) erhaltenen PD auf dem MN zu plotten. Allerdings hat die Übermittlung der CRs per NSCA einen Schönheitsfehler:
Passiv übermittelte CR werden vom MN mit dem Timestamp versehen, zu dem er sie erhalten hat. Selbst wenn man sich einer der Mechanismen bedient, die CRs zu puffern (z.b. durch OCSP Sweeper), werden ihre Timestamps bei wiederaufgenommener Verbindung zum MN (und Übermittlung der gepufferten Daten) durch den aktuellen Timestamp ersetzt.
Folge: der Graph enthält Lücken (und ganz „nebenbei“ werden die Daten kontaminiert, über die später ggf. auch reported werdem muss.
Wer Netzwerkausfälle auch in den Graphen durch Lücken sehen will, kann an dieser Stelle aufhören zu lesen. Die Verfügbarkeit des Netzwerks gehört aber imho in separate Checks (und Graphen) ausgelagert und sollte sich nach Möglichkeit nicht in einem Graphen fürs Application Monitoring widerspiegeln. Denn womöglich ist nur die Verbindung zwischen MN und DN gestört, der Kunde konnte aber zu jederzeit auf Euren Webserver. Solch ein (zu Unrecht) durch Lücken verunstalteter Graphen zeigt dem Kunden im SLA-Report eine Downtime, die er nicht wirklich hatte!

Mit diesem HowTo …

• werden die RRD-Files auf einem einzigen Nagios-Host (MN) erzeugt, gleich wieviele DNs es gibt. Die Probleme mit RRDs aus 32-, und 64-Bit-Systemen sind somit passé. Eine rrdtool-Installation auf MN reicht also.
• gibt es eine einzige PNP-Seite auf dem MN, welche alle Graphen, auch die der DN, enthält. Auch die Services auf DN enthalten action_url-Links, die auf den zentralen PNP auf MN verweisen
• sind die DN in der Lage, bei Netzwerkproblemen die PD nahezu beliebig lange zu puffern auf einem „separaten Kanal“ an den MN zu übermitteln
• sind die DN in der Lage, die PD auf File-Ebene zu archivieren, um ein evt. mal zerschossenes (evt. vier Jahre altes und hoch-heiliges) RRD-File mit einem grep-Klimmzug über die archivierten PD wieder neu aufzubauen.
• eröffnet sich eine Alternative zu RRD-Dumps/Imports: RRD-File einfach löschen, ggf. die RRA-Config anpassen und per find/grep die alten Performancedaten neu an NPCD verfüttern.

Ich bin tippfaul. Folgende Abkürzungen werden verwendet:

• PD ⇒ Performancedaten
• CR ⇒ Checkresults
• DM ⇒ Distributed Monitoring
• DN ⇒ Distributed Nagios ( x „n“, also beliebig viele)
• MN ⇒ Master Nagios
• MN = DN ⇒ Diese Definition ist auf MN und DN 1:1 identisch.
• MN != DN ⇒ “ “ “ “ unterschiedlich definiert.

(Randbemerkung: Meine Nagios-Objekte werden mit Prefixen und Suffixen wie folgt benannt:) ziemlich praktisch mit der Codevervollständigung von vim

• tpl_ ⇒ Template
• tpl_s_ ⇒ Service-Template
• hg_ ⇒ Hostgroup
• virt_ ⇒ virtuelle Server
• usw…

Desweiteren …

• wird das etc/-Verzeichnis von Nagios in die Bereiche local, global, sites/siteXYZ unterteilt. Näheres zu diesem Verfahren, insb. „verteiltes Monitoring“ ist in Wolfgang Barths Nagios-Buch gut beschrieben. (Keine Panik vor dem augenscheinlich immensen Overhead an Konfiguration; er lohnt sich). Verständnis von DM und dem Template-Mechanismus ist Voraussetzung für dieses HowTo.
• sind alle Pfadangaben unterhalb der Nagios-Verzeichnisses zu verstehen, falls nicht explizit angegeben.
• spreche ich nur von Service-PD. Wer das ganze für Hosts ebenfalls einrichten will, kann das ganze leicht noch erweitern.
• wird in dieser Beschreibung davon ausgegangen, dass PNP bereits auf dem MN im Bulk Mode mit NPCD eingerichtet ist. „Kompliziert“, wie Jörg in der PNP-Doku diesen Weg beschreibt, ist relativ. Auch dieser Weg lohnt sich.

Wir legen uns folgende Templates an:

tpl_s_generic:
Enthält sämtliche generischen Service-Optionen, die für dieses HowTo nicht von Belang sind. Seid kreativ

# generic Service template
# THIS TEMPLATE IS VALID FOR ALL SERVICES ON ALL NAGIOS INSTANCES
define service{
        name                            tpl_s_generic
        register                        0
...
...
        }

tpl_s_perfdata:
Dieses Template wird auf DN und MN in alle services eingebunden. Erklärung folgt im nächsten Absatz zu den local Templates des MN.

#-------------------------------------------------------------------------
# include the following (global) template in  e v e r y  Service with perfdata.
# To prevent the master Nagios to process perfdata from remote servers (which have been processed
# t h e r e  already), write this template as the last template, e.g.
#
# define service{
#       use     tpl_s_remote,[...], tpl_s_perfdata
#       ...
# }
# The earlier mentioned a template is, the more weight it has. tpl_s_remote contains
#       "process_perfdata       0"
# which would cause the master Nagios  n o t  to process perfdata, even if tpl_s_perfdata
# contains the opposite meaning.

define service{
        register                        0
        name                            tpl_s_perfdata
        process_perf_data               1
        action_url                      http://mn/nagios/pnp/index.php?host=$HOSTNAME$&srv=$SERVICEDESC$
}

Die folgenden beiden Templates werden auf MN und DN in /local definiert. tpl_s_remote bestimmt, ob nun MN oder DN für das processing der PD zuständig sind. (Der Name „Remote“ bezeichnet einen distributed Service, der auf dem MN angezeigt werden soll). Um doppelte Zeilen zu sparen, habe ich die Unterschiede zwischen MN und DN im der Tabelle hervorgehoben:

Direktive	MN	DN	Bemerkung
active_checks_enabled	0	1
passive_checks_enabled	1	0
notifications_enabled	1	0	(der DN ist „stumm“)
check_freshness	1	0
freshness_threshold	300	–	MN wartet 5 Minuten auf Ergebnis
process_perfdata	0	1	PD von checks auf DNs werden weiterverarbeitet (siehe ), die per NSCA auf dem MN empfangenen CR jedoch nicht mehr

(Codeschnippsel zeigt die exemplarische Definition für den MN)

#-------------------------------------------------------------------------
# Remote-Template
# use this template for services which
#               - are executed on remote sites
#               - checks are received passive
#               - should be displayed on  t h i s  Nagios host
# This template also exists on all servers, but with  o t h e r  values!
define service{
        register                        0
        name                            tpl_s_remote
        use                             tpl_s_generic
        # no active checks of remote services...
        active_checks_enabled           0
        #         ...waiting for passive results:
        passive_checks_enabled          1
        notifications_enabled           1
        # (execute check_command after freshness_threshold = 4 minutes)
        check_freshness                 1
        freshness_threshold             300
        # this (local) directive overrides the (global) template tpl_s_perfdata, and
        # prevents the master Nagios to process perfdata from remote servers which have already been processed
        process_perf_data               0
}

tpl_s_local stellt das Gegenstück zu tpl_s_remote dar. „Local“ ist also als „nur auf diesem Server“ zu verstehen. Wir werden es für Services einsetzen, die wir z.b. nur auf einem Nagios definieren, also genau keine distributed Services sind. Um doppelte Zeilen zu sparen, habe ich die Unterschiede im der Tabelle hervorgehoben:

(Ein über tpl_s_local definierte service verarbeitet Performancedaten, sobald tpl_s_perfdata eingebunden ist (process_perfdata = 1). Deshalb ist hier keine Angabe mehr nötig. )

#-------------------------------------------------------------------------
# local-Template
# use this template for services on  t h i s  Nagios host
define service{
        register                        0
        name                            tpl_s_local
        use                             tpl_s_generic
        # local checks are active (in general)...
        active_checks_enabled           1
        #     ...and not passive (in general):
        passive_checks_enabled          0
        notifications_enabled           1
        check_freshness                 0
}

Die Freshness-Direktve in der Servicedefinition ermöglicht es, dass der MN „selbst nach dem rechten sehen kann“, wenn ein distributed Service nach Ablauf der Freshness Time immer noch kein Ergebnis gesendet hat. Leider ist dies nicht immer möglich (Firewalls…), wenn gar nicht erwünscht. Es wäre ja durchaus sinnvoll, zu erfahren, dass der DN ein Problem hat, den Check auszuführen - auch wenn der MN dazu imstande wäre.
Da der Service incl. check_command jedoch im sites/-Teil definiert ist (und somit auf allen Instanzen identisch), müssen wir einen Workaround schaffen, mit dem der MN nach Ablauf der Freshness eben genau nicht das gleiche Kommando ausführt wie der DN, sondern beispielsweise ein sauberes „No data received from remote Nagios server.“ abliefert: commands, die wir auf den Satelliten ausführen wollen, werden wir also im local-Teil der jeweiligen Instanz ablegen. Folgende Tabelle zeigt den Unterschied für das Beispiel-command check_http.

(Codeschnippsel zeigt exemplarisch die Definition auf dem DN, das Kommentarzeichen vereinfacht das Duplizieren)

# 'check_http' command definition
define command{
        command_name    remote_check_http
        command_line    $USER1$/check_http -I $HOSTADDRESS$ $ARG1$
#       command_line    $USER1$/check_dummy 3 "No data received from remote Nagios server."
        }

Somit wird ein und das gleiche Command auf MN und DN unterschiedlich ausgeführt: auf DN „so wie es soll“, und auf MN mit der Meldung, dass die Freshness überschritten wurde.

Nun sind wir bereit, einen ersten Service einzurichten. Nachfolgend der exemplarische remote_check_http (der auf DN und MN identisch ist!):

define service{
        use                             tpl_s_remote,tpl_s_perfdata
        hostgroup_name                  hg_dn_testserver
        service_description             HTTP
        check_command                   remote_check_http
        }

Wir erinnern uns:

• tpl_s_remote ⇒ active/passive?, notifications?, freshness?, process_perfdata?
• tpl_s_perfdata ⇒ action_url?, process_perfdata?

Wir sehen anhand der Hervorhebung: Einzig process_perfdata wird zweimal aus einem Template gereicht. Bei Mehrfachnennungen matcht (gemäß Nagios-Doku, Multiple Inheritance Sources) das Template, in der use-Direktive zuerst genannt wurde, nämlich tpl_s_remote. Da wir dieses Template auf DN und MN unterschiedlich definiert haben (s.o.), wird also nur DN die PD weiterverarbeiten.

Bisher ist alles noch ein alter Hut. Nun wollen wir den DN dazu bringen, die PD zu puffern und dem MN vorzuwerfen.
(Nachfolgende Schritte sind ebenfalls auf dem MN durchzuführen, sind aber exemplarisch an DN erklärt.)

process_performance_data=1
\\
service_perfdata_file=/usr/local/nagios/var/service-perfdata
service_perfdata_file_template=DATATYPE::SERVICEPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$SERVICEPERFDATA$\tSERVICECHECKCOMMAND::$SERVICECHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$\tSERVICESTATE::$SERVICESTATE$\tSERVICESTATETYPE::$SERVICESTATETYPE$
service_perfdata_file_mode=a
service_perfdata_file_processing_interval=15
service_perfdata_file_processing_command=process-service-perfdata-file

DN wird also für alle Services mit aktivierem PD-Processing

• die PD an /usr/local/nagios/var/service-perfdata anhängen
• das in service_perfdata_file_template genannte Schema verwenden
• und alle 15s das command process-service-perfdata-file aufrufen.

Nun geht es an die Definition des Kommandos process-service-perfdata-file, welches die service-perfdata-Datei periodisch wegschiebt. Dieses Kommando definieren wir im global-Teil - wir können es auf jedem Nagios-Satelliten gebrauchen.

define command{
        command_name    process-service-perfdata-file
        # moves the service-perfdata to service-perfdata.timestamp
        # creates a archive copy
        # moves service-perfdata.timestamp to spool directory
        command_line    /usr/local/nagios/bin/spool_perfdata.sh /usr/local/nagios/var/service-perfdata /usr/local/nagios/var/spool/perfdata/ /usr/local/nagios/var/perfdata-archive/
 }

process-service-perfdata-file ruft also spool_perfdata.sh mit folgenden Parametern:

• ARG1: Pfad zur service-perfdata-Datei
• ARG2: Pfad zum Spool-Verzeichnis
• ARG3: Pfad zum Archiv-Verzeichnis

ARG2 ist das Spool-Verzeichnis, in dem unsere PD-Files darauf warten, zum MN kopiert zu werden, wo NPCD zur Weiterverarbeitung wartet.
ARG3 ist unser Archiv. Wir sichern also die rohen PD weg. Wie man daraus wieder einen Graphen restaurieren kann, siehe Wiederherstellung von Graphen.

spool_perfdata.sh findet Ihr am Ende der Seite.
Kopiert es an den oben angegebenen Pfad oder einen anderen Eurer Wahl.

Nach einem Nagios-Reload sollten sich nach spätestens 15 Sekunden unter var/spool/perfdata Dateien befinden wie

service-perfdata.1236358666.dn  service-perfdata.1236692813.dn  service-perfdata.1245830667.dn
service-perfdata.1236358696.dn  service-perfdata.1236693043.dn  service-perfdata.1245830682.dn
service-perfdata.1236683053.dn  service-perfdata.1236693272.dn  service-perfdata.1245830857.dn
service-perfdata.1236683068.dn  service-perfdata.1236693501.dn  service-perfdata.1245831076.dn
service-perfdata.1236683083.dn  service-perfdata.1236693728.dn  service-perfdata.1245831296.dn
service-perfdata.1236683172.dn  service-perfdata.1236693956.dn  service-perfdata.1245831516.dn
service-perfdata.1236683173.dn  service-perfdata.1236694187.dn  service-perfdata.1245831736.dn

Unter var/perfdaata-archive findet sich folgende Struktur (YYYYMMDD-hh):

|-- 20090624-11
|   |-- service-perfdata.1245834142.dn
...
...
|   `-- service-perfdata.1245837591.dn
|-- 20090624-12
|   |-- service-perfdata.1245837789.dn
...
...
|   `-- service-perfdata.1245841079.dn
`-- 20090624-13
    |-- service-perfdata.1245841298.dn
...
...
    `-- service-perfdata.1245842171.dn

Format / Inhalt dieser Dateien ist im Anhang referenziert.

Bis hierhin arbeiten DN und MN gleich: sie legen ihre PD-Files einfach in /var/spool/perfdata ab. Auf MN läuft ja bereits NPCD, der von dort aus die dort anfallenden PD process_perfdata.pl vorwirft.

Wenn Admins am DN ebenfalls schöne Graphen sehen, aber nicht auf Euren MN zugreifen können/sollen, entfernt das Gatter in Zeile

#  $CPCMD $NEWFILENAME $NPCD_SPOOL

Somit werden die Daten nicht nur archiviert und zum MN geleitet, sondern zudem einem lokalen NPCD zur Weiterverarbeitung für ein lokales PNP gegeben.

Nach gleicher Manier kann natürlich auch die Archivfunktion deaktiviert werden, falls nicht gewünscht.

…damit aber auch die PD von DN zum MN kommen, bedienen wir uns eines weiteren Scripts: cp_perfdata.sh, welches Ihr ebenfalls im Anhang findet. Es kopiert alle Files von DN in /usr/local/nagios/var/spool/perfdata per SCP (secure Copy) in gleichnamiges Verzeichnis auf MN. Und eben dieses Verzeichnis wird ja bereits von NPCD überwacht, welcher die PD von MN abarbeitet. Diesem werden wir nun die PD der Satelliten „unterjubeln“ - dass diese in Wirklichkeit auf einem anderen Host entstanden, interessiert ihn nämlich nicht.
Mit dem Eintrag in die crontab von User „Nagios“ (ebenfalls im Anhang) werden die Dateien minütlich zum MN verschoben. je nach Gusto/Auslastung ist das Intervall natürlich anzupassen. (Wichtiger Hinweis: damit das Script die Daten zu MN per SCP kopieren kann, ist ein Austausch des SSH-Keys des Nagios-users, sowie ein erster Login auf der Shell erforderlich, um den Host-Key des MN zu bekommen; ansonsten schlägt der scp-Vorgang im Script fehl. Dokus hierzu gibt es zuhauf im Netz.)
Die im Script hinterlegte Logdatei (sorry, logrotation ist keine eingebaut!) sollte nun berichten, dass die Dateien erfolgreich zum MN kopiert werden:

2009-06-24 14:15 ________________________________
2009-06-24 14:15 (Started with PID 17309)
2009-06-24 14:15 Entering spool directory /usr/local/nagios/var/spool/perfdata
2009-06-24 14:15 1 files found. Processing...
2009-06-24 14:15 -----
2009-06-24 14:15    Trying to SCP /usr/local/nagios/var/spool/perfdata/service-perfdata.1245845675.dn to nagios@xx.xx.xx.xx:/usr/local/nagios/var/spool/perfdata/service-perfdata.1245845675.dn
2009-06-24 14:15      SCP was successfull. File will be deleted.
2009-06-24 14:15 Removing lockfile and exiting. Waiting for the next run.
2009-06-24 14:15
[nagios@dn /usr/local/nagios/var]$ tail -n 100 mv_perfdata.log
2009-06-24 14:12    Trying to SCP /usr/local/nagios/var/spool/perfdata/service-perfdata.1245839105.dn to nagios@xx.xx.xx.xx:/usr/local/nagios/var/spool/perfdata/service-perfdata.1245839105.dn
2009-06-24 14:12      SCP was successfull. File will be deleted.
2009-06-24 14:12 -----
2009-06-24 14:12    Trying to SCP /usr/local/nagios/var/spool/perfdata/service-perfdata.1245839325.dn to nagios@xx.xx.xx.xx:/usr/local/nagios/var/spool/perfdata/service-perfdata.1245839325.dn
2009-06-24 14:12      SCP was successfull. File will be deleted.
2009-06-24 14:12 -----
2009-06-24 14:12    Trying to SCP /usr/local/nagios/var/spool/perfdata/service-perfdata.1245839544.dn to nagios@xx.xx.xx.xx:/usr/local/nagios/var/spool/perfdata/service-perfdata.1245839544.dn
2009-06-24 14:12      SCP was successfull. File will be deleted.
2009-06-24 14:12 -----

Auf dem MN sollten wir nun im Verzeichnis var/spool/perfdata nicht nur die PD von MN, sondern auch von DN sehen:

[root@mn /usr/local/nagios/var/spool/perfdata]# ls | head -n 20
service-perfdata.1236331871.mn
service-perfdata.1236331886.mn
service-perfdata.1236331888.dn
service-perfdata.1236331903.dn
service-perfdata.1236331918.dn
service-perfdata.1236331974.mn
service-perfdata.1236331989.mn
service-perfdata.1236332004.mn
service-perfdata.1236332018.dn
service-perfdata.1236332019.mn
service-perfdata.1236332033.dn

Anhand des Suffixes “.mn“ / “.dn“ erkennen wir, woher die Daten kommen. NPCD sollte diese Dateien nun abarbeiten können.

Durch die Benennung der Dateien entsteht immer eine chronologische Sortierung. Diese ist elementar für RRDTool, denn neue Datensätze müssen stets jünger sein als der Zeitstempel des letzten RRD-Updates, nie älter!

Von pitchfork kam der Vorschlag, anstatt der Shellscripts auf dem DN NPCD einzusetzen. NPCD läuft als Daemon im Hintergrund, und dürfte die PD bei größeren Installationen deutlch performanter verarbeiten.

Mythenmetz hat dankenswerterweise dpnp schon im Einsatz und setzt anstatt der Shellscripts rsync ein:

Hier soll kurz darauf eingegangen werden, wie man einen Graphen von DN aus dem Archiv der Performancedaten wiederherstellt.

• löschen des evt. beschädigten .rrd/.xml-Files auf MN
• Wechseln in das Archiv-Verzeichnis auf DN:

cd /Usr/local/nagios/var/perfdata-archive 

• Suchen (find) und Ausgeben (cat) aller Datein mit Suffix “.dn“, filtern nach host+service (grep), sortieren nach Feld „TIMET“ (Timestamp), und anschließendes Ausgeben in eine Datei im Spool-Verzeichnis.

for file in `find . -type f -name "*.dn"`; do cat $file | grep $'localhost-4\tSERVICEDESC::PING'; done | sort -k 2,2 > /usr/local/nagios/var/spool/perfdata/service-perfdata_restoreddata.dn

(Sollen nur die letzten zwei Monate/Stunden eines Graphens restored werden, ist find/grep einfach auf das jeweiige Unterverzeichnis anzuwenden; Duch den Timestamp als Prefix des Dateinamens lassen sich mit einem rekursiven find jedoch beliebig andere Timeranges definieren)

• Der nächste Run von cp_perfdata.sh auf DN wird diese Datei zu MN kopieren, NPCD wird die (chronologisch sortierten) PD an process_perfdata.pl verfüttern, und wir können im Browser duch wiederholtes Aktualisieren (F5) der PNP-Seite zusehen, wie tausende historischer Werte nach und nach in ein jungfräuliches RRD-File geschrieben werden.

#!/bin/sh
# Spool service-perfdata file and make a archive copy

PERFDATA_FILE=$1
SPOOL_DIR=$2
ARCHIVE_DIR=$3
HOSTNAME=`hostname`
MVCMD=`which mv`
CPCMD=`which cp`
MKDIRCMD=`which mkdir`
BASENAMECMD=`which basename`
LSCMD=`which ls`
DATECMD=`which date`
TIMESTAMP=`$DATECMD +%s`
AWKCMD=`which awk`
DATE=`$DATECMD "+%Y%m%d-%H"`

if [ ! -d $ARCHIVE_DIR$DATE ];
then
        $MKDIRCMD -p $ARCHIVE_DIR$DATE
fi

# Check file size. Empty files are skipped.
if [ `$LSCMD -l $PERFDATA_FILE | $AWKCMD '{print $5}'` -gt 0 ];
then
    # First, rename the file
      NEWFILENAME="$PERFDATA_FILE.$TIMESTAMP.$HOSTNAME"
      $MVCMD $PERFDATA_FILE $NEWFILENAME
    # copy the file to archive
      $CPCMD $NEWFILENAME $ARCHIVE_DIR$DATE/
    # copy the file to the local npcd spool (optional, if there
    # is still a local NPCD daemon running)
    # $CPCMD $NEWFILENAME $NPCD_SPOOL
    # mv the file to spool directory
      $MVCMD $NEWFILENAME $SPOOL_DIR
fi

(Ein Perl-Daemon wäre natürlich noch schicker. )

#!/bin/sh

SOURCE_DIR=/usr/local/nagios/var/spool/perfdata
DST_NAGIOS=192.168.10.128
SCPCMD=/usr/bin/scp
MKDIRCMD=/bin/mkdir
LSCMD=/bin/ls
RMCMD=/bin/rm
DATELONG=`date "+%Y-%m-%d %H:%M"`
LOGFILE=/usr/local/nagios/var/mv_perfdata.log
LOCKFILE=/tmp/mv_perfdata.lock

# make sure only one instance is running
if [ -e ${LOCKFILE} ] && kill -0 `cat ${LOCKFILE}`; then
#       echo "Hey Dude. I am still working!"
        exit
fi
# write process ID in lockfile
trap "rm -f ${LOCKFILE}; exit" INT TERM EXIT
echo $$ > ${LOCKFILE}

func_log () {
        echo "$DATELONG $1" >> $LOGFILE
}

func_log "________________________________"
func_log "(Started with PID $$)"
func_log "Entering spool directory $SOURCE_DIR"
COUNT=`find $SOURCE_DIR -type f | wc -l`
if [ $COUNT -eq 0 ];
then
        func_log "No files in there. Exiting."
        exit 0
else
        func_log "$COUNT files found. Processing..."
fi

for file in $SOURCE_DIR/*;
do
        func_log "-----"
        func_log "   Trying to SCP file to nagios@$DST_NAGIOS:$file"
        $SCPCMD $file nagios@$DST_NAGIOS:$file
        if [ $? -eq 0 ];
        then
                func_log "     SCP was successfull. File will be deleted."
                $RMCMD $file
        else
                func_log "     ERROR: SCP was not successfull!"
        fi
done;

func_log "Removing lockfile and exiting. Waiting for the next run."
func_log ""

sleep 1
rm -f ${LOCKFILE}

…und die passende Crontab dazu:

[root@dn /usr/local/nagios/bin]# crontab -u nagios -l
*       *       *       *       *       /bin/sh -c /usr/local/nagios/bin/cp_perfdata.sh

(nur zu Veranschaulichung, bloß nicht abtippen!)

...
...
DATATYPE::SERVICEPERFDATA       TIMET::1245846541       HOSTNAME::mn_localhost SERVICEDESC::SSH        SERVICEPERFDATA::       SERVICECHECKCOMMAND::remote_check_ssh   HOSTSTATE::UP    HOSTSTATETYPE::HARD     SERVICESTATE::OK        SERVICESTATETYPE::HARD
DATATYPE::SERVICEPERFDATA       TIMET::1245846541       HOSTNAME::dn_localhost-10      SERVICEDESC::SSH        SERVICEPERFDATA::       SERVICECHECKCOMMAND::remote_check_ssh   HOSTSTATE::UP    HOSTSTATETYPE::HARD     SERVICESTATE::OK        SERVICESTATETYPE::HARD
...
...

Wer sich im vim bewegen kann, wird sich mit einer solchen Konvention einen großen Gefallen tun. Beispiel:

• Öffne Dateien services.cfg, hosts.cfg und commands.cfg (zwischen den Tabs wechseln: gt):

vim -p services.cfg hosts.cfg commands.cfg templates.cfg[ENTER]

Alternativ:

vim services.cfg [ENTER]
:tabnew services.cfg hosts.cfg templates.cfg

• Um beispielsweise ein Template benutzen:

use   tpl_[ctrl-n]

• Wie hieß gleich noch mal dieses selbstgebaute snmp-command…?

check_command   check_snmp_[ctrl-n]

• Wie hieß denn noch dieser eine virtuelle Proxy in Rack A?

host_name   virt_A_proxy_[ctrl-n]

Danke an

• Mythenmetz (Test, rsync-Variante)
• pitchfork (NPCD-Variante)
  

für die Mithilfe an dem Artikel! — Simon Meggle (simmerl) 2009/06/24 13:35