check_nagiostats

bern

Profi

Beiträge: 1 641

Anzahl Nagios-Server: 2-5

Nagios-Version(en): 1-3

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 80-200

Anzahl Services: 1400-2000

Betriebssystem(e): Linux

Plugin-Version(en): Whatever I can download, patch, or cobble together myself :-)

Sonstige Addon's: n2rrd, PNP, livestatus

1

08.09.2010, 15:04

So, dann wollen wir 'mal ...

Zitat von »mess«

Zitat von »bern«

Zitat von »pitchfork«

magst du dein nagiosstats Plugin mal in einen neuen Thread packen.

Thread? MonitoringExchange? Beides ... ?

Beides bitte! Monitoring-Exchange, damit es besser wiederzufinden ist - und ein eigener Thread, damit wir Plugin-Design-Diskussionen [...] trennen koennen.

OK. Aktuelle Version liegt auf MonitoringExchange bereit; Prüft jetzt $EXEC auf Ausführbarkeit, gibt in den Performance-Daten für "XYZ -lt 0" ein saubereres "XYZ=4711" statt "XYZ=4711;;" aus (wollte ich eigentlich von Anfang an, war ein Bug) und ... hat einen (abstellbaren) RANGETRACK Mode. :whistling:

Zitat von »mess«

Zitat von »bern«

Eine Frage vorher: Ich hab' eine Weile darüber nachgedacht, ob und wie ich die Größe der Zeitfenster in die Perfdaten abbilden sollte/kann....Noch 'ne Idee ... ?

Lass es so, wie es ist. Nicht zu kompliziert.

Shell-Skripte und kompliziert?

OK, ich hab's wie gesagt abstellbar gemacht.

Zitat von »mess«

Wer sein Abfrageinterval umstellt, sollte selber wissen, was er tut

Natürlich weiß ich, "was ich tue", wenn ich wg. Glättung oder sonstwas von einem Zeitfenster auf ein anderes umstelle, und ich weiß auch, was hintendran in den RRDs passiert und daß ich eigentlich temporär den Service abstellen und die RRDs mit rrddump/rrdrestore "'mal kurz" umskalieren müßte, um keinen Bruch in die Daten zu kriegen. Aber das heißt doch nicht, daß ich mir den Findling unbedingt für den Tag X im Weg liegenlassen muß, wenn es auch anders geht! (Nämlich dadurch, daß ich das Zeitfenster mit in die RRDs logge und fürs Grafikmalen per einfacher Division auf XYZ pro Minute vereinheitliche.)

Zitat von »mess«

Y-Achsen-Skalierungseffekte sind vergleichsweise harmlos im Vergleich zu Aenderungen bei der Anzahl der Datasets.

Wenn Du meinst. Ich hab' den RANGETRACK bei mir eingeschaltet gelassen und sowohl n2rrd als auch PNP (im MULTIPLE Modus) sind's zufrieden ...

Zum Seitenanfang

mess

Meister

Beiträge: 1 902

Wohnort: Esslingen

Anzahl Nagios-Server: 3

Nagios-Version(en): 3.0.5

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: ~1100

Anzahl Services: > 90 per host (check_multi)

Betriebssystem(e): RHEL5.6, CentOS

Plugin-Version(en): 1.4.14

NagVis-Version: 1.5x

NDO-Version: livestatus ;)

Perfparse-Version: PNP 0.6.x

Sonstige Addon's: Dokuwiki, Heartbeat 1, DRBD 8.2.1

2

08.09.2010, 20:11

Zitat von »bern«

OK. Aktuelle Version liegt auf MonitoringExchange bereit

Danke.

Zitat von »bern«

Zitat von »mess«

Y-Achsen-Skalierungseffekte sind vergleichsweise harmlos im Vergleich zu Aenderungen bei der Anzahl der Datasets.

Wenn Du meinst. Ich hab' den RANGETRACK bei mir eingeschaltet gelassen und sowohl n2rrd als auch PNP (im MULTIPLE Modus) sind's zufrieden ...

Ich seh das vom Support-Standpunkt aus. Da sind 'falsche' Werte z.B. beim Umschalten von 5 auf 1 Minute ein Aergernis, aber kein Show-Stopper. Falsche Datasets im RRD aber schon.
Und nicht jeder hat genug Platz und genug IO-Performance fuer den MULTIPLE-Modus.

D.h: vorher ueberlegen, wie sehr man seinen Nagios-Server mit nagiostats quaelen will und schlimmstenfalls die RRDs nochmal loeschen. Ich bin z.B. wieder von 1 Minute auf 5 Minuten hochgegangen, weil mir die Kurven viel zu zackig waren und sich nichts Vernuenftiges daraus ablesen liess.

Jetzt hab ich eine Woche Daten verloren - macht nix.

Dafuer kann ich auch in einem halben Jahr begruenden, warum ich im 5-Minuten-Raster abfrage.

Gruss - Matthias

-> check_multi und check_generic

Zum Seitenanfang

bern

Profi

Beiträge: 1 641

Anzahl Nagios-Server: 2-5

Nagios-Version(en): 1-3

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 80-200

Anzahl Services: 1400-2000

Betriebssystem(e): Linux

Plugin-Version(en): Whatever I can download, patch, or cobble together myself :-)

Sonstige Addon's: n2rrd, PNP, livestatus

3

08.09.2010, 21:07

Zitat von »mess«

Ich seh das vom Support-Standpunkt aus.

Von welchem auch sonst ... Ich hab' noch keinen Nagios gesehen, der beim Verkauf zur Marktbeobachtung betrieben worden wäre ...

Zitat von »mess«

Da sind 'falsche' Werte z.B. beim Umschalten von 5 auf 1 Minute ein Aergernis, aber kein Show-Stopper. Falsche Datasets im RRD aber schon.

Wir wärmen hier gerade eine Diskussion auf, die schonmal ohne Ergebnis stattgefunden hat. Natürlich ist mir auch lieber, wenn eine Zeitreihe nicht mehr zu klärende Effekte zeigt als wenn ein Dutzend davon im selben RRD-File fröhlich in Zeitscheiben zerschnipselt und kunterbunt unpassend aneinandergesetzt wurde. Es ist mir und den Leuten um mich 'rum sogar so unlieb, daß wir lieber bei n2rrd bleiben würden, als PNP im SINGLE-Modus zu betreiben - wir bekämpfen das Problem nunmal lieber an einer Stelle, dem RRD Backend, als in hundertdrölfzehn Plugins.

Da kann dann auch 'mal ein Nagios-Update unbemerkt ein nagiostats mit mittendrin einsortierten neuen Feldern mitbringen und wenn der Unterschied ein, zwei Monate später bemerkt wird, sind alte und neue Felder trotzdem über (parameterloses) check_nagiostats in RRD-Files gelaufen und aufgezeichnet worden. Selber Effekt bei check_ping, das kürzlich zwei DS dazubekommen hat; bei stats_ftServer, das die Ausgabe vom jeweiligen ftsmaint liest und somit von Hardware, Firmware und OS-Treibern abhängt, die der Kunde in erster Linie selbst verwaltet; bei check_du, mit dem ich nach "Filesystem-vollmüll-Halden" suche und dessen DS wohl oder übel nach den Unterverzeichnissen benannt sind, die ich gerade im Verdacht habe und überwache; ...

Zitat von »mess«

Und nicht jeder hat genug Platz und genug IO-Performance fuer den MULTIPLE-Modus.

I/O, zugegeben. Da habe ich hier einstweilen noch Luft (und würde im Ernstfall auch mit RAMDisks und stündlichen Backups auf "echte" Platte dreinschlagen wollen

). Aber wieso Platz? Mein produktives (MULTIPLE Mode) pnp4nagios/var/perfdata hat rund 900 MB, das zurückbehaltene von meinem SINGLE Mode Test Ende Juni 800 MB, allein 50 MB Unterschied herrscht zwischen den pnp4nagios/var/perfdata/Nagios (wo zwischenzeitlich check_nagiostats und noch ein paar andere Services dazugekommen sind) ...

Zitat von »mess«

Jetzt hab ich eine Woche Daten verloren - macht nix. Dafuer kann ich auch in einem halben Jahr begruenden, warum ich im 5-Minuten-Raster abfrage.

Oha, da sind die Sitten hierzulande andere. Gerade letztens haben wir sowas wie drei Monate Perfdaten von check_memusage aus der Schublade gezogen, damit der Vendor per Verhaltensanalyse das Memory Leak in seinem Hardware-Treiber einkreisen kann. RRD-Daten wegschmeißen tu' ich nur, wenn ich positiv weiß, daß da 'was durcheinandergekommen und keine belastbare Aussage mehr möglich ist.

Zum Seitenanfang

mess

Meister

Beiträge: 1 902

Wohnort: Esslingen

Anzahl Nagios-Server: 3

Nagios-Version(en): 3.0.5

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: ~1100

Anzahl Services: > 90 per host (check_multi)

Betriebssystem(e): RHEL5.6, CentOS

Plugin-Version(en): 1.4.14

NagVis-Version: 1.5x

NDO-Version: livestatus ;)

Perfparse-Version: PNP 0.6.x

Sonstige Addon's: Dokuwiki, Heartbeat 1, DRBD 8.2.1

4

09.09.2010, 12:53

Zitat von »bern«

Zitat von »mess«
Ich seh das vom Support-Standpunkt aus.

Von welchem auch sonst ... Ich hab' noch keinen Nagios gesehen, der beim Verkauf zur Marktbeobachtung betrieben worden wäre ...

Nicht vom Standpunkt der Nagios-Anwender als Supporter ihrer Systeme. Sondern vom Blickwinkel des OSS-Entwicklers als Supporter fuer die Nagios-Anwender.
Da ist jede Ungenauigkeit im Tool, jede nicht abgefangene Laufzeitbedingung, immer eine Support-Anfrage und kostet Zeit. Ich behaupte mal, dass wir im Monitoring mehr und unterschiedliche Bedingungen haben als 'normale' Software, weil wir in jeden noch so entlegenen Winkel gucken muessen, egal wie viel Staub dort liegt.

Zitat von »bern«

Da kann dann auch 'mal ein Nagios-Update unbemerkt ein nagiostats mit mittendrin einsortierten neuen Feldern mitbringen und wenn der Unterschied ein, zwei Monate später bemerkt wird, sind alte und neue Felder trotzdem über (parameterloses) check_nagiostats in RRD-Files gelaufen und aufgezeichnet worden. Selber Effekt bei check_ping, das kürzlich zwei DS dazubekommen hat; bei stats_ftServer, das die Ausgabe vom jeweiligen ftsmaint liest und somit von Hardware, Firmware und OS-Treibern abhängt, die der Kunde in erster Linie selbst verwaltet; bei check_du, mit dem ich nach "Filesystem-vollmüll-Halden" suche und dessen DS wohl oder übel nach den Unterverzeichnissen benannt sind, die ich gerade im Verdacht habe und überwache; ...

Ja, Aenderungen bei den DS sind haeufiger geworden, sowohl bei Design-Aenderungen (wie check_ping) und bei Plugins mit haeufig wechselnden DS (disks, processes etc).
Ich finde auch, dass das vom Backend entdeckt und behandelt werden muss. Die rein numerische Indizierung der DS ist eigentlich keine weiterfuehrende Loesung, weil sie keine Soll-Ist-Vergleiche zulaesst ausser der absoluten Anzahl der DS.

Die Behandlung von Fehlern in den Perfdaten ist generell ein weites Feld. Ich hab beim check_multi schon Haue bekommen (warum eigentlich

), weil ich nur Perfdaten akzeptiere, die den Guidelines entsprechen. Dabei ist es im Interesse der folgenden Perfdaten, wenn fehlerhafte vorher rausgeworfen werden.
Joerg ist in PNP noch rigoroser - er verwirft eine komplette Datenzeile, wenn sie beim Parsen Fehler bringt. Das geht vielleicht ein bisschen weit, ist aber wieder durch die Support-Brille zu erklaeren: lieber keine Perfdaten als welche, die die DS-Reihenfolge durcheinanderbringen.

Zitat von »bern«

I/O, zugegeben. Da habe ich hier einstweilen noch Luft (und würde im Ernstfall auch mit RAMDisks und stündlichen Backups auf "echte" Platte dreinschlagen wollen ). Aber wieso Platz?

Platz ist wirklich Tuennef

- IO Performance ist alles.

Ramdisk / rsync find ich uebrigens gut fuer status.dat, checkresults und nagios.log und hab damit unsere Wait-IO-Probleme geloest. Aber fuer RRDs wuerde ich erst mal den rrdcached ausreizen.

Zitat von »bern«

Zitat von »mess«
Jetzt hab ich eine Woche Daten verloren - macht nix. Dafuer kann ich auch in einem halben Jahr begruenden, warum ich im 5-Minuten-Raster abfrage.

Oha, da sind die Sitten hierzulande andere. Gerade letztens haben wir sowas wie drei Monate Perfdaten von check_memusage aus der Schublade gezogen, damit der Vendor per Verhaltensanalyse das Memory Leak in seinem Hardware-Treiber einkreisen kann. RRD-Daten wegschmeißen tu' ich nur, wenn ich positiv weiß, daß da 'was durcheinandergekommen und keine belastbare Aussage mehr möglich ist.

Ich hab nicht gesagt, dass ich 'gern' oder 'mutwillig' Perfdaten wegwerfe.

Latency, Execzeiten und Checks unserer Nagios'se werden seit Jahren ueberwacht und solche RRDs wuerde ich sogar vom Backup wiederholen.
Nee, ich lasse neue Perfdaten-Quellen (wie jetzt nagiostats) immer eine Zeitlang unter Beobachtung laufen, bevor ich das produktiv gehen lasse. Inklusive verwerfen, wenn es nicht taugt.

Gruss - Matthias

-> check_multi und check_generic

Zum Seitenanfang

pitchfork

Super Moderator

Beiträge: 15 096

Wohnort: Kassel

Beruf: Sysadmin SAP / Linux / AIX

Anzahl Nagios-Server: 2

Hobbys: Motorrad fahren, wenns die Zeit erlaubt :-)

Nagios-Version(en): 3.2.1

Icinga-Version(en): ---

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 310

Anzahl Services: 4500

Betriebssystem(e): Debian 5.0 Lenny

Plugin-Version(en): 1.4.x

NagVis-Version: 1.4.1

NDO-Version: ---

IDO-Version: ---

Perfparse-Version: ---

Sonstige Addon's: SNMPTT, NagTrap, NagVis 1.4.5, check_mk, PNP-0.6.x. Thruk

5

09.09.2010, 13:20

Themawechsel ...

Hier mein aktuelles Template für check_nagiostats

PHP-Quelltext

# check_nagiostats written by Jochen Bern
# http://www.monitoringexchange.org/inventory/Check-Plugins/Software/Nagios/check_nagiostats
#
# Copyright (c) 2006-2010 Joerg Linge (http://www.pnp4nagios.org)
#

$opt[0] = '--title "Check Latency"';
$ds_name[0] = "Check Latency";
$def[0] = "";
$i = 0;
foreach ($this->DS as $KEY=>$VAL) {
    if(preg_match('/(.*)LAT$/', $VAL['NAME'], $matches)){
        $i++;
        $label = ucfirst(strtolower($matches[1]));
        $def[0] .= rrd::def     ("var$KEY", $VAL['RRDFILE'], $VAL['DS'], "AVERAGE");
        $def[0] .= rrd::cdef    ("var_sec$KEY", "var$KEY,1000,/");
        $def[0] .= rrd::line1   ("var_sec$KEY", rrd::color($i), rrd::cut($label,10) );
        $def[0] .= rrd::gprint  ("var_sec$KEY", array("LAST","MAX","AVERAGE"), "%8.2lf");
    }
}
$opt[1] = '--title "Service Stats"';
$ds_name[1] = "Service Stats";
$def[1] = "";
$i = 0;
foreach ($this->DS as $KEY=>$VAL) {
    if(preg_match('/^NUMSVC(.*)$/', $VAL['NAME'], $matches)){
        $i++;
        $label = ucfirst(strtolower($matches[1]));
        $def[1] .= rrd::def     ("var$KEY", $VAL['RRDFILE'], $VAL['DS'], "AVERAGE");
        $def[1] .= rrd::line1   ("var$KEY", rrd::color($i), rrd::cut($label,10) );
        $def[1] .= rrd::gprint  ("var$KEY", array("LAST","MAX","AVERAGE"), "%8.2lf");
    }
}
$opt[2] = '--title "Host Stats"';
$ds_name[2] = "Host Stats";
$def[2] = "";
$i = 0;
foreach ($this->DS as $KEY=>$VAL) {
    if(preg_match('/^NUMHST(.*)$/', $VAL['NAME'], $matches)){
        $i++;
        $label = ucfirst(strtolower($matches[1]));
        $def[2] .= rrd::def     ("var$KEY", $VAL['RRDFILE'], $VAL['DS'], "AVERAGE");
        $def[2] .= rrd::line1   ("var$KEY", rrd::color($i), rrd::cut($label,10) );
        $def[2] .= rrd::gprint  ("var$KEY", array("LAST","MAX","AVERAGE"), "%8.2lf");
    }
}
$opt[3] = '--title "Check Execution Time"';
$ds_name[3] = "Execution Time";
$def[3] = "";
$i = 0;
foreach ($this->DS as $KEY=>$VAL) {
    if(preg_match('/(.*)EXT$/', $VAL['NAME'], $matches)){
        $i++;
        $label = ucfirst(strtolower($matches[1]));
        $def[3] .= rrd::def     ("var$KEY", $VAL['RRDFILE'], $VAL['DS'], "AVERAGE");
        $def[3] .= rrd::cdef    ("var_sec$KEY", "var$KEY,1000,/");
        $def[3] .= rrd::line1   ("var_sec$KEY", rrd::color($i), rrd::cut($label,10) );
        $def[3] .= rrd::gprint  ("var_sec$KEY", array("LAST","MAX","AVERAGE"), "%8.2lf");
    }
}

PNP Developer.
PNP 0.6.14 ist online !
Fragen zu PNP mit Angabe der verwendeten PNP Version werden bevorzugt beantwortet.
OMD - Open Monitoring Distribution

Zum Seitenanfang

little

Profi

Beiträge: 762

Geburtstag: 26.11.1975 (35)

Geschlecht: Männlich

Wohnort: Mainburg

Beruf: PDM-Consultant, IT-Specialist

Anzahl Nagios-Server: 3

Nagios-Version(en): 3.2.0/3.2.1/3.2.2

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: ~200

Anzahl Services: ~1800

Betriebssystem(e): Linux, AIX, HP-UX, Windows

Plugin-Version(en): 1.4.14/1.4.15

NagVis-Version: 1.4-nightly/1.5-nightly

NDO-Version: 1.4b9

Sonstige Addon's: NRPE, PNP,NSClient++,DokuWiki,NagiosBPV, MKLivestatus, Thruk

6

09.09.2010, 14:33

Einfach nur genial, was ihr da gebaut habt.

Stefan

OMD - Open Monitoring Distribution

Zum Seitenanfang

Nagios-/Icinga-Portal