Dieser Beitrag gehört zu der Artikelserie Nagiosgrapher
Dieser Beitrag wurde vor über 3 Monaten veröffentlicht. Die darin beschriebenen Informationen sind mit Vorsicht zu geniessen, da sie bereits veraltet oder nicht mehr gültig sein könnten. Solltest du von Neuerungen oder Verbesserungen wissen, so freue ich mich über einen klärenden Kommentar.Wie versprochen, für alle welche sich jetzt auch mit NagiosGrapher herumkämpfen, stelle ich mal meine Konfiguration zur Verfügung. Ich überwache dabei folgende Punkte von NSClient++:
- Auslastung der CPU (5 Min. Durchschnitt)
- Auslastung vom Drive C:
- Auslastung vom Drive D:
- Auslastung vom RAM
Zusätzlich noch folgende Werte von eigenen Scripts:
- Auslastung vom ESX Datastore
Damit mein Script auch bei euch funktioniert, müsst ihr natürlich die selben Check-Scripts verwenden, wie ich. Entweder habe ich dazu aber einen Standard verwendet, wie check_nt von NSClient oder ihr findet das Script irgendwo in meinem Blog. Einfach mal die Suchfunktion ein bisschen bemühen
Meine Konfiguration für NagiosGrapher sieht wie folgt aus:
# ---
# NagiosGrapher Template for MS-Windows-related checks
# Modified by compr00t
# ---
# CPU load
define ngraph{
service_name CPU
graph_log_regex ([0-9]+)%
graph_value cpu_load
graph_units Prozent
graph_legend 5 Min Durchschnitt
graph_upper_limit 100
graph_lower_limit 0
rrd_plottype AREA
rrd_color 00a000
}
define ngraph{
service_name CPU
type VDEF
graph_value vdef_cpu_average
graph_units
graph_legend Durchschnitt
graph_calc cpu_load,AVERAGE
graph_legend_eol LEFT
rrd_plottype LINE1
rrd_color 0000ff
hide no
}
# nt-disk
define ngraph{
service_name C-Drive
graph_log_regex (\d+)%\)\s+-
graph_value c_drive
graph_units Prozent
graph_legend benutzer Speicher
graph_upper_limit 100
graph_lower_limit 0
page 1 Auslastung
rrd_plottype AREA
rrd_color ff0000
}
define ngraph{
service_name D-Drive
graph_log_regex (\d+)%\)\s+-
graph_value d_drive
graph_units Prozent
graph_legend benutzer Speicher
graph_upper_limit 100
graph_lower_limit 0
page 1 Auslastung
rrd_plottype AREA
rrd_color ff0000
}
define ngraph{
service_name C-Drive
graph_log_regex (\d+)\.(\d+)\sGb\s-
graph_value c_drivefix
graph_units GB
graph_legend Speicher
page 2 Speicher
rrd_plottype AREA
rrd_color c0c0ff
}
define ngraph{
service_name D-Drive
graph_log_regex (\d+)\.(\d+)\sGb\s-
graph_value d_drivefix
graph_units GB
graph_legend Speicher
page 2 Speicher
rrd_plottype AREA
rrd_color c0c0ff
}
define ngraph{
service_name Datastore
graph_log_regex ([0-9]*)\.([0-9]*)%
graph_value esx_datastore
graph_units Prozent
graph_legend freier Speicher
graph_upper_limit 100
graph_lower_limit 0
rrd_plottype AREA
rrd_color ff0000
}
# nt-memory
define ngraph{
service_name Memory
graph_log_regex (\d+)%\) -
graph_value memory
graph_units Prozent
graph_legend genutzes RAM
graph_upper_limit 100
graph_lower_limit 0
rrd_plottype AREA
rrd_color ff0000
}
define ngraph{
service_name Memory
type VDEF
graph_value vdef_memory_average
graph_units
graph_legend Durchschnitt
graph_calc memory,AVERAGE
graph_legend_eol LEFT
rrd_plottype LINE1
rrd_color 0000ff
hide no
}
# [EOF]
Diese Datei muss einfach unter /usr/local/nagios/etc/ngraph.d/ abgelegt werden und die Endung .ncfg besitzen. Bedenkt aber, es dauert ein bisschen, bis die Einträge und überhaupt auch Werte in der Grafik auftauchen. Einfach den NagiosGrapher neustarten und nach einer Zeit mal Nagios reloaden:
/etc/init.d/nagios_grapher restart /etc/init.d/nagios reload
Die restlichen Graphen basieren alle auf eigenen Check-Skripten. Aber mit ein bisschen Grundwissen in RegEx ist es keine Hexerei mehr, selbst etwas zu zaubern

NSClient++ in NagiosGrapher integrieren http://t.co/sODKI3yh
Neue Publizierung: Patrick Schmid (compr00t): NSClient++ in NagiosGrapher integrieren http://t.co/Pr5qOHbe #planetdfde
Hallo,
da ich unsere Monitoring Lösung betreue lese ich deine Nagios-Artikel immer gerne.
Mich würde mal interessieren, ob du check_mk (bzw. OMD) kennst?
Wenn ja, gibt es für dich Gründe, die gegen deren Nutzung sprechen? Die Konfiguration ist aus meiner Sicht erheblich einfacher, als die reine Nagios-Konfiguration.
Hi Gordon. Leider nein, check_mk kenne ich nicht und verwende es auch selbst nicht. Für mich klingt es wie ein Fork von Nagios korrekt? Nagios ist eigentlich auch nicht schwer in der Konfiguration und wenn es mal eingerichtet ist, läuft es überaus stabil und sauber.
Hallo. Nein es ist kein Fork. Check_mk benötigt den Nagios-Core (oder einen kompatiblen wie Icinga oder Shinken). Ich würde es eher als eine gute Symbiose bezeichnen
Es ist eine andere Herangehensweise an die Art, wie Systeme Überwacht werden. Es wird der entsprechende Agent auf dem System installiert, in der Konfiguration der Host bekannt gemacht und dann lässt man check_mk den Host inventarisieren und er generiert selbstständig valide Nagios-Konfiguration. Im Idealfall ist die Einrichtung eines neuen Hosts somit exakt 1 Zeile Editieraufwand.
Schlussendlich wird der Nagios-Core dann einen aktiven Check auf den Server (Agent) starten und wird aus den erhaltenen Daten für alle weiteren Dienste extrahieren und im Nagios anzeigen.
OMD ist die Open Monitoring Distribution, die eine stattliche Sammlung an Nagios-Komponenten vorkonfiguriert mitbringt. Diese sind zum Beispiel Nagios/Icinga/Shinken, PNP4Nagios, NagVis, check_mk (inkl MK_Multisite und MK_Livestatus) und vielem mehr. Sie bieten für jede große Distribution ein Repositorium an. Und das Highlight ist, dass ich mehrere Nagios-Instanzen parallel auf meinem Monitoring-Server betreiben kann.
Wenn Du mal Zeit hast würde ich dir empfehlen, dir mal die einleitenden Worte unter http://mathias-kettner.de/check_mk.html durchzulesen. Seit der Umstellung auf check_mk (bzw. OMD) ist unser Monitoring fast ein Selbstläufer.
Klingt ja schon nach dem Overtool
Muss ich mir echt mal genauer anschauen!