Messwerte und Graphing

Letzte Aktualisierung: 20. Februar 2016


1. Einleitung

Nebem dem eigentlichen Sys­tem-Monitoring – näm­lich der Erkennung von Problemen -- ist Check_MK ein ausgezeichnetes Werk­zeug zur Auf­zeich­nung und Analyse von unter­schied­lichsten Mess­daten, welche in IT-Um­ge­bungen so anfallen können. Da­zu gehören zum Bei­spiel:

  • Betriebssystemperformance (Platten-IO, CPU- und Speicherauslastung, …)
  • Netzwerkgrößen (genutzte Bandbreite, Paketlaufzeiten, Fehlerraten, …)
  • Umgebungssensoren (Temperatur, Luftfeuchte, Luftdruck, …)
  • Nutzungsstatistiken (eingeloggte User, Seitenabrufe, Sessions, …)
  • Qualitätskennzahlen von Anwendungen (z. B. Antwortzeiten von Webseiten)
  • Stromverbrauch und -qualität im RZ (Ströme, Spannungen, Leistungen, Batteriegüte, …)
  • Anwendungsspezifische Daten (z. B. Länge von Mailqueues von MS Exchange)
  • Und vieles mehr …

Check_MK zeichnet grundsätzlich alle beim Monitoring anfallenden Messgrößen über einen Zeitraum von (einstellbar) vier Jahren auf, so dass Sie nicht nur auf die aktuellen, sondern auch auf historische Messwerte zugreifen können. Um den Verbrauch an Plattenplatz in Grenzen zu halten, werden die Daten mit zunehmendem Alter immer weiter verdichtet. Die Messwerte selbst werden von den einzelnen Checkplugins ermittelt. Sie legen somit auch fest, welche Metriken genau bereitgestellt werden.

2. Zugriff über die GUI

Die Messwerte eines Services werden in der GUI in drei verschiedenen Formen präsentiert. Die sogenannten Perf-O-Meter tauchen direkt in der Tabelle der Hosts oder Services auf und bieten einen schnellen Überblick und einen optischen Vergleich. Allerdings beschränken sich diese aus Platzgründen meist auf eine einzelne ausgewählte Metrik. Bei den Dateisystemen ist dies z. B. der prozentual belegte Platz:

Alle Metriken eines Services im Zeitverlauf erhalten Sie, wenn Sie mit der Maus über das Graphen-Icon fahren oder draufklicken. Die gleichen Graphen finden Sie zudem auch ganz einfach in den Details zu einem Host oder Service:

In den Host-/Servicedetails gibt es zudem eine Tabelle mit den aktuellen präzisen Messwerten für alle Metriken:

Wie genau die Zeitverläufe visualisiert werden, hängt von Ihrer Check_MK-Edition ab:

3. Das Graphing in der Enterprise Edition

Die  Check_MK Enterprise Edition enthält seit Version 1.2.8 eine eigenständige komlett neu entwickelte Oberfläche für die Visualisierung der historischen Messdaten, welche auf interaktivem HTML5 basiert. Außerdem gibt es eine native Darstellung in PDF – und zwar direkt als Vektorgraphik im PDF-Format und damit ohne sichtbare Pixel im Ausdruck.

3.1. Interaktion mit dem Graphen

Sie können die Darstellung des Graphen auf verschiedene Arten interaktiv beeinflussen:

  • Durch Pannen (mit links klicken und festhalten, dann ziehen) verschieben Sie den Zeitbereich (links/rechts) oder skalieren vertikal (hoch/runter).
  • Mit dem Mausrädchen Zoomen Sie in der Zeit rein und raus.
  • Durch Ziehen an der rechten unter Ecke verändern Sie die Größe des Graphen.
  • Ein Klick an eine Stelle im Graphen setzt eine Stecknadel (den Pin). Damit erfahren Sie die genaue zeitliche Lage eines Punkts und alle präzisen Messwerte zu diesem Zeitpunkt. Der exakte Zeitpunkt des Pins wird pro Benutzer gespeichert und in allen Graphen angezeigt:

Wenn sich auf einer Seite mehrere Graphen befinden, so folgen auch alle anderen Graphen der Seite den gemachten Änderungen am gewählten Zeitbereich und der Stecknadel. Somit sind die Werte immer vergleichbar. Auch eine Größenänderung wirkt sich auf alle Graphen aus. Der Abgleich geschieht allerdings erst beim nächsten Neuladen der Seite (sonst würde zeitweise in ziemliches Chaos auf dem Bildschirm entstehen …).

4. Graphensammlungen (Graph Collections)

Mit dem Menüsymbol können Sie den Graphen an verschiedenen Stellen einbetten, z. B. in Berichte oder Dashboards. Sehr nützlich sind dabei die Graph Collections. In so eine Graphensammlung können Sie beliebig viele Graphen packen und diese dann später vergleichen oder auch als PDF exportieren. Per Standard hat jeder Benutzer eine Graphsammlung mit dem Namen My Graphs. Sie können aber sehr einfach weitere anlegen und diese sogar für andere Benutzer sichtbar machen. Das Vorgehen ist dabei exakt das Gleiche wie bei den Ansichten. Sie gelangen zu Ihren Graphsammlungen über das Element Views in der Seitenleiste:

Der Knopf bringt Sie zur Tabelle all Ihrer Graphensammlungen mit der Möglichkeit, weitere anzulegen, zu ändern usw.

5. Freiformgraphen (Custom Graphs)

Version 1.2.8 der  Check_MK Enterprise Edition bietet erstmals einen grafischen Editor, mit dem Sie komplett eigene Graphen mit eigenen Berechungsformeln erstellen können. Damit ist es nun auch möglich, Metriken von verschiedenen Hosts und Services in einem Graphen zu kombinieren. Zu den Freiformgraphen gelangen Sie z. B. über Views ➳ EDIT und dann mit dem Knopf .

Ein anderer Weg geht über die Metrik-Tabelle bei einem Service. Dort gibt es bei jeder Metrik ein Symbol, mit der Sie diese Metrik zu einem Freiformgraphen hinzufügen können:

Folgende Abbildung zeigt die Liste der Freiformgraphen (hier mit nur einem Eintrag):

Bei jedem vorhandenen Graphen haben Sie vier mögliche Operationen:

Erzeugt eine Kopie dieses Graphen.
Löscht den Graphen.
Öffnet die allgemeinen Eigenschaften dieses Graphen. Hier können Sie nebem dem Titel auch Einstellungen zur Sichtbarkeit für andere Benutzer festlegen. Alles verhält sich exakt wie bei den Ansichten. Bitte denken Sie an die Onlinehilfe, wenn Sie Fragen zu einer der Einstellungen haben.
Hier gelangen Sie zum eigentlichen Graphdesigner, mit dem Sie die Inhalte verändern können.

Beachten Sie, dass jeder Freiformgraph – analog zu den Ansichten – eine eindeutige ID hat. Über diese wird der Graph in Berichten und Dashboards angesprochen. Wenn Sie die ID eines Graphen später ändern, gehen dadurch solche Referenzen verloren. Alle Graphen, die nicht hidden sind, werden in Ihrer Seitenleiste unter Views ➳ Metrics angezeigt.

5.1. Der Graphdesigner

Der Graphdesigner ist in vier Bereiche unterteilt:

5.2. Vorschau des Graphen

Hier sehen Sie den Graphen exakt so, wie er auch später zu sehen sein wird. Sie können alle interaktiven Funktionen nutzen.

5.3. Liste der Metriken

Die im Graphen enthaltenen Kurven, welche hier direkt editiert werden können. Eine Änderung des Titels einer Kurve in diesem Feld bestätigen Sie mit der Enter-Taste. Der Style legt fest, wie der Wert im Graphen optisch gezeichnet wird. Dabei gibt es folgende Möglichkeiten:

LineDer Wert wird als Linie eingezeichnet.
AreaDer Wert wird als Fläche eingezeichnet. Beachten Sie, dass die Kurven, die weiter oben in der Liste stehen, Vorrang vor späteren haben und diese dabei überdecken können. Wenn Sie Linien und Flächen kombinieren möchten, sollten die Flächen immer unten stehen.
Stacked AreaAlle Kurven dieses Stils werden als Flächen gezeichnet und vom Wert her aufeinander gestapelt (also quasi addiert). Die obere Grenze dieses Stapels symbolisiert also die Summe aller beteiligten Kurven.

Die weiteren drei Möglichkeiten Mirrored Line, Mirrored Area und Mirrored Stacked funktionieren analog, nur dass die Kurven von der Nulllinie aus nach unten gezeichnet werden. Das ermöglicht eine Art von Graph, wie sie Check_MK generell für Input/Output-Graphen wie den folgenden verwendet:

In der letzten Spalte der Metriktabelle können Sie bestehende Metriken editieren. Das ermöglicht z. B., eine Kurve zu klonen und dann einfach den Hostnamen auszutauschen. Die Bedeutung der einzelnen Felder wird im nächsten Abschnitt erlärt.

5.4. Formular zum Hinzufügen einer Metrik

Über das Formular Metrics können Sie neue Metriken zum Graphen hinzufügen. Sobald Sie in das erste Feld einen gültigen Hostnamen eingeben, wird das zweite Feld mit der Liste der Services des Hosts gefüllt. Eine Auswahl in dieser Liste füllt das dritte Feld mit der Liste der Metriken dieses Services. Im vierten und letzten Feld wählen Sie die Konsolidierungsfunktion. Zur Auswahl stehen Minimum, Maximum und Average. Diese Funktionen kommen immer dann zur Anwendung, wenn die Speicherung der Daten in den RRDs für den gewählten Zeitraum bereits verdichtet ist. In einem Bereich, wo z. B. nur noch ein Wert pro halber Stunde zur Verfügung steht, können Sie so wählen, ob Sie den größten, kleinsten oder durchschnittlichen Originalmesswert dieses Zeitraums einzeichnen möchten.

Sie können dem Graphen auch eine Konstante hinzufügen. Diese wird dann zunächst als waagerechte Linie angezeigt. Konstanten sind manchmal nötig zur Bildung von Berechnungsformeln. Dazu später mehr.

5.5. Graphoptionen

Hier finden Sie Optionen, die den Graphen als Ganzes betreffen. Die Einheit Unit beeinflusst die Beschriftung der Achsen und der Legende. Sie wird automatisch eingestellt, sobald die erste Metrik hinzugefügt wird. Beachten Sie, dass es zwar möglich, aber nicht sehr sinnvoll ist, zwei Metriken mit unterschiedlichen Einheiten in einem Graphen unterzubringen.

Unter Explicit vertical range können Sie den vertikalen Bereich des Graphen voreinstellen. Normalerweise wird die Y-Achse so skaliert, dass alle Messwerte im gewählten Zeitraum genau in den Graphen passen. Wenn Sie einen Graphen für z. B. einen Prozentwert entwerfen, könnten Sie sich aber auch entscheiden, dass immer von 0 bis 100 dargestellt wird. Beachten Sie dabei, dass der Graph vom Benutzer (und auch Ihnen selbst) trotzdem mit der Maus skaliert werden kann und die Einstellung dann wirkungslos wird.

5.6. Rechnen mit Formeln

Der Graphdesigner ermöglicht es Ihnen, die einzelnen Kurven durch Rechenoperationen zu kombinieren. Folgendes Beispiel zeigt einen Graphen mit zwei Kurven: CPU utilization User und System.

Nehmen wir an, dass Sie für diesen Graphen nur die Summe von beiden interessiert. Dazu wählen Sie zunächst die beiden Kurven durch Ankreuzen ihrer Checkboxen aus. Sobald Sie das tun, erscheint im Kasten Metrics eine neue Zeile Operation on selected metrics mit einer Reihe von Knöpfen:

Ein Klick auf Sum kombiniert die beiden gewählten Kurven zu einer neuen Kurve. Als Farbe wird automatisch die Mischung aus den Einzelfarben gewählt. Der Titel der neuen Kurve wird zu Sum of User, System. Die Berechnungsformel wird in der Spalte Formula angezeigt. Außerdem taucht ein neues Symbol auf:

Durch einen Klick auf machen Sie die Operation quasi rückgängig, in dem Sie die Formel wieder auflösen und die einzelnen enthaltenen Kurven wieder zum Vorschein kommen. Weitere Hinweise zu den Rechenoperationen:

  • Manchmal ist es sinnvoll, Konstanten hinzuzufügen, um z. B. den Wert einer Kurve von der Zahl 100 abzuzuiehen.
  • Sie können die Operation können beliebig verschachteln.

6. Die Graphingoberfläche von PNP4Nagios

In der  Check_MK Raw Edition bildet das Graphingsystem PNP4Nagios von Jörg Linge die Grundlage für die Erfassung und Visualisierung von Messdaten. Dieses ist in der Sprache PHP geschrieben und ein eigenständiges Projekt, welches auch ohne Check_MK verfügbar und vor allem bei Benutzern von klassichen Nagios-basierten Monitoringsystemen beliebt ist. PNP4Nagios ist über einen Frame in die Check_MK-Oberfläche eingebunden sowie von der Farbgebung her eigens an Check_MK angepasst:

6.1. Zeitraum auswählen

Um den dargestellten Zeitraum auszuwählen, haben Sie verschiedene Möglichkeiten:

  • Direkt im Graphen können Sie mit der Maus einen Bereich auswählen.
  • Die Lupe öffnet einen Dialog mit Knöpfen zum Blättern und Zoomen.
  • Der Kalender ermöglicht die Eingabe von Datum und Uhrzeit.
  • Im Kasten Timeranges können Sie einen von fünf Standardzeiträumen wählen (z. B. One Month).

6.2. Das Basket

In Ihrem Basket können Sie mit dem Icon mehrere Graphen "einsammeln", um diese dann später über My basket gleichzeitig anzusehen. So können Sie auch Graphen von verschiedenen Hosts auf einmal ansehen und diese leichter vergleichen.

6.3. PDF-Export

Der Knopf startet einen einfachen Export der aktuellen Ansicht als PDF.

7. Graphite, Grafana und InfluxDB

Wenn Sie die  Check_MK Enterprise Edition einsetzen, so können Sie parallel zum in Check_MK eingebauten Graphing auch externe Metrik-Datenbanken anbinden. Der Check_MK Micro Core kann alle Messdaten zusätzlich an eine (ab Version 1.2.8 sogar mehrere) Datenbank weiterleiten, die das Protokoll von Graphite unterstützt. Neben Graphite selbst hat z. B. die InfluxDB eine derartige Schnittstelle.

Die Anbindung konfigurieren Sie in den Global Settings unter Send metrics to Graphite / InfluxDB:

Neben den offensichtlichen Angaben zum Netzwerk können Sie hier optional einen Präfix konfigurieren, der jedem Hostnamen vorangestellt wird, um z. B. eindeutige Namen zu erzwingen. Als Namensschema für den Export der Metriken wird HOST.SERVICE.METRIK verwendet.

Sollte die Anbindung nicht funktionieren, so finden Sie Diagnoseinformationen in der Datei ~/var/log/cmc.log in ihrer Instanz. Folgendes Beispiel zeigt die Meldungen im Fall, dass ein Connect zum Graphite-Server nicht klappt:

/omd/sites/mysite/var/log/cmc.log
2016-02-24 16:30:48 [5] Successfully initiated connection to Carbon/Graphite at 10.0.0.5:2003.
2016-02-24 16:32:57 [4] Connection to Carbon/Graphite at 10.0.0.5:2003 failed: Connection timed out
2016-02-24 16:32:57 [5] Closing connection to Carbon/Graphite at 10.0.0.5:2003

Der Core versucht in so einer Situation von sich aus immer wieder, die Verbindung aufzubauen. Messdaten, die während einer Zeit anfallen, zu der keine Verbindung zu Graphite besteht, werden nicht zwischengespeichert, sondern gehen verloren (bzw. sind dann nur in den RRD-Datenbanken von Check_MK verfügbar).

8. Hintergründe, Tuning, Fehlerdiagnose

Check_MK speichert alle Messwerte in dafür eigens entwickelten Datenbanken, sogennannten RRDs (Round Robin Datenbanken). Dabei kommt das RRDTool von Tobi Oetiker zum Einsatz, welches in Open-Source-Projekten sehr beliebt und weit verbreitet ist.

Die RRDs bieten gegenüber klassischen SQL-Datenbanken bei der Speicherung von Messwerten wichtige Vorteile:

  • RRDs speichern die Messdaten sehr kompakt und effizient.
  • Der Platzverbrauch auf der Platte pro Metrik ist statisch. RRDs können weder wachsen noch schrumpfen. Der benötigte Plattenplatz kann gut geplant werden.
  • Die benötigte CPU- und Disk-Zeit pro Update ist immer gleich. RRDs sind (nahezu) echtzeitfähig, da es nicht zu Staus aufgrund von Reorganisationen kommen kann.

8.1. Organisation der Daten in den RRDs

Check_MK ist so voreingestellt, dass der Verlauf jeder Metrik über einen Zeitraum von vier Jahren aufgezeichnet wird. Die Grundauflösung ist dabei eine Minute. Dies ist deswegen sinnvoll, weil das Check-Intervall auf eine Minute voreingestellt ist und so von jedem Service genau einmal pro Minute neue Messwerte kommen.

Nun kann sich allerdings jeder ausrechnen, dass die Speicherung von einem Wert pro Minute über vier Jahre eine enorme Menge an Plattenplatz benötigen würde (obwohl die RRDs pro Messwert nur genau 8 Byte benötigen). Aus diesem Grund werden die Messdaten mit der Zeit verdichtet. Die erste Verdichtung findet nach 48 Stunden statt. Ab diesem Zeitpunkt wird nur noch ein Wert pro fünf Minuten aufbewahrt. Die übrigen Stufen sind nach 10 Tagen und 90 Tagen:

PhaseDauerAuflösungMesspunkte
12 Tage1 Minute2880
210 Tage5 Minuten2880
390 Tage30 Minuten4320
44 Jahre6 Stunden5840

Jetzt stellt sich natürlich die Frage, wie denn nun fünf Werte sinnvoll zu einem einzigen konsolidiert werden sollen. Als Konsolidierungsfunktionen bieten sich z. B. das Maximum, das Minimum oder der Durchschnitt an. Was in der Praxis sinnvoll ist, hängt von der Anwendung oder Betrachtungsweise ab. Möchten Sie z. B. den Temperaturverlauf in einem Rechenzentrum über vier Jahre beobachten, wird Sie wahrscheinlich eher die maximale Temperatur interessieren, die je erreicht wurde. Bei der Messung von Zugriffszahlen auf eine Anwendung könnte der Durchschnitt interessieren.

Um maximal flexibel bei der späteren Auswertung zu sein, sind die RRDs von Check_MK so voreingestellt, dass sie einfach jeweils alle drei Werte speichern – also Minimum, Maximum und Durchschnitt. Pro Verdichtungsstufe und Konsolidierungsfunktion enthält die RRD einen ringförmigen Speicher – ein sogenanntes RRA (Round Robin Archive). Im Standardaufbau gibt es also insgesamt 12 RRAs. So benötigt das Standardschema von Check_MK genau 384.952 Byte pro Metrik. Das ergibt sich aus 2880 + 2880 + 4320 + 5840 Messpunkten mal drei Konsolidierungsfunktionen mal acht Byte pro Messwert, was genau 382.080 Byte ergibt. Dazu kommt ein Dateiheader von 2872 Byte.

Ein interessantes alternatives Schema wäre z. B. das Speichern von einem Wert pro Minute für ein komplettes Jahr. Dabei kann man einen kleinen Vorteil ausnutzen: Da die RRDs dann zu allen Zeiten die optimale Auflösung haben, können Sie auf die Konsolidierung verzichten und z. B. nur noch Average anlegen. So kommen Sie auf 365 x 24 x 60 Messpunkte zu je 8 Byte, was ziemlich genau 4 MB pro Metrik ergibt. Auch wenn die RRDs somit mehr als den zehnfachen Platz benötigen, ist die nötige Disk-IO sogar reduziert! Der Grund: Ein Update muss nicht mehr in 12 verschiedene RRAs geschrieben werden, sondern nur noch in eines.

8.2. Anpassen des RRD-Aufbaus

Wenn Ihnen das voreingestellte Speicherschema nicht zusagt, so können Sie dieses über Konfigurationsregeln ändern (sogar pro Host oder Service unterschiedlich). Den nötigen Regelsatz finden Sie am einfachsten über die Regelsuche – also WATO ➳ Host & Service Parameters ➳ Search for rules sets. Und dort geben Sie einfach RRD ein. So finden Sie die Regel Configuration of RRD databases of services. Es gibt auch eine analoge Regel für Hosts, aber Hosts haben nur in Ausnahmefällen Messwerte. Folgendes Bild zeigt die Regel mit den Defaulteinstellungen (diese wird ab Version 1.2.8 beim Einrichten einer neuen Instanz automatisch angelegt):

In den Abschnitten Consolidation Functions und RRA Configuration können Sie die Anzahl und Größe der Verdichtungsphasen bestimmen und festlegen, welche Konsolidierungen bereit gehalten werden sollen. Das Feld Step bestimmt die Auflösung in Sekunden, in der Regel 60 (eine Minute). Für Services mit einem Check-Interval von kleiner als einer Minute kann es sinnvoll sein, diese Zahl kleiner einzustellen. Beachten Sie dabei, dass die Angaben im Feld Number of steps aggregated into one data point dann nicht mehr Minuten bedeuten, sondern die in Step eingestellte Zeitspanne.

Jede Änderung des RRD-Aufbaus hat zunächst nur Einfluss auf neu angelegte RRDs – sprich wenn Sie neue Hosts oder Services in das Monitoring aufnehmen. Sie können aber die bestehenden RRDs von Check_MK umbauen lassen. Dazu dient der Befehl cmk --convert-rrds, bei welchem sich immer die Option -v (verbose) anbietet. Check_MK kontrolliert dann alle vorhandenen RRDs und baut diese nach Bedarf in das eingestellte Zielformat um:

OMD[mysite]:~$ cmk -v --convert-rrds
myserver012:
  Uptime (CMC).....converted, 376 KB -> 159 KB
  Filesystem / (CMC).....converted, 1873 KB -> 792 KB
  OMD slave apache (CMC).....converted, 14599 KB -> 6171 KB
  Memory (CMC).....converted, 14225 KB -> 6012 KB
  Filesystem /home/mk (CMC).....converted, 1873 KB -> 792 KB
  Interface 2 (CMC).....converted, 4119 KB -> 1741 KB
  CPU load (CMC).....converted, 1125 KB -> 475 KB

Der Befehl ist intelligent genug, um RRDs zu erkennen, die bereits den richtigen Aufbau haben:

OMD[mysite]:~$ cmk -v --convert-rrds
myserver345:
  Uptime (CMC).....uptodate
  Filesystem / (CMC).....uptodate
  OMD slave apache (CMC).....uptodate
  Memory (CMC).....uptodate
  Filesystem /home/mk (CMC).....uptodate
  Interface 2 (CMC).....uptodate
  CPU load (CMC).....uptodate

Wenn das neue Format eine höhere Auflösung oder zusätzliche Konsolidierungsfunktionen hat, werden die bestehenden Daten so gut es geht interpoliert, so dass die RRDs mit möglichst sinnvollen Werten gefüllt werden. Nur ist natürlich klar, dass wenn Sie z.B ab sofort nicht 2 sondern 5 Tage mit minutengenauen Werten haben möchten, die Genauigkeit der bestehenden Daten nicht nachträglich erhöht werden kann.

8.3. RRD-Speicherformat

Die oben gezeigte Regel hat noch eine weitere Einstellung: RRD storage format. Mit dieser können Sie zwischen zwei Methoden wählen, wie Check_MK die RRDs erzeugt. Diese Einstellung existiert ab Version 1.2.8. Hier wurde das neue Format One RRD per host/service (oder Kurz Check_MK-Format oder CMK-Format) einführt. Dabei werden alle Metriken eines Hosts bzw. Services in eine einzige RRD-Datei gepackt. Dies sorgt für ein effizienteres Schreiben der Daten, da so immer ein kompletter Satz an Metriken in einer einzigen Operation geschrieben werden kann. Diese Metriken liegen dann in benachbarten Speicherzellen, was die Anzahl der Plattenblöcke reduziert, die geschrieben werden müssen.

Bitte beachten Sie, dass das Format One RRD per host/service nicht von PNP4Nagios untetstützt wird. Check_MK-Instanzen die ab Version 1.2.8 der  Check_MK Enterprise Edition erzeugt werden, verwenden automatisch das neue Format. Bestehende Instanzen aus früheren Versionen behalten das alte PNP-Format. Sie können diese über das Anlegen einer Regel im oben gezeigten Regelsatz auf das Check_MK-Format umstellen. Auch hier benötigen Sie anschließend den Befehl cmk --convert-rrds:

OMD[mysite]:~$ cmk -v --convert-rrds
myhost123:
   Uptime PNP -> CMC..converted.
  WARNING: Dupliate RRDs for stable/Uptime. Use --delete-rrds for cleanup.
   OMD heute apache PNP -> CMC..converted.
  WARNING: Dupliate RRDs for stable/OMD heute apache. Use --delete-rrds for cleanup.
   fs_/home/mk PNP -> CMC..converted.
  WARNING: Dupliate RRDs for stable/fs_/home/mk. Use --delete-rrds for cleanup.
   OMD slave apache PNP -> CMC..converted.
  WARNING: Dupliate RRDs for stable/OMD slave apache. Use --delete-rrds for cleanup.
   Memory PNP -> CMC..converted.
...

Wie Sie an der Warnung sehen können, lässt Check_MK die bestehenden Dateien im alten Format zunächst liegen. Dies ermöglicht Ihnen im Zweifel eine Rückkehr zu diesem Format, weil ein Konvertieren in die Rückrichtung nicht möglich ist. Die Option --delete-rrds sorgt dafür, dass diese Kopien nicht erzeugt bzw. nachträglich gelöscht werden. Sie können das Löschen bequem später mit einem weiteren Aufruf des Befehls machen:

OMD[mysite]:~$ cmk -v --convert-rrds --delete-rrds

8.4. Der RRD-Cache-Daemon (rrdcached)

Um die Anzahl der nötigen Schreibzugriffe auf die Platte (drastisch) zu reduzieren, kommt ein Hilfsprozess zum Einsatz: der RRD-Cache-Daemon (rrdcached). Er ist einer der Dienste, welche beim Start einer Instanz gestartet werden:

OMD[mysite]:~$ omd start
Starting mkeventd (builtin: syslog-udp)...OK
Starting Livestatus Proxy-Daemon...OK
Starting mknotifyd...OK
Starting rrdcached...OK
Starting Check_MK Micro Core...OK
Starting dedicated Apache for site stable...OK
Initializing Crontab...OK

Alle neuen Messwerte für die RRDs werden zunächst vom Kern ( Check_MK Enterprise Edition) bzw. von NPCD ( Check_MK Raw Edition) an den rrdcached gesendet. Dieser schreibt die Daten zunächst nicht in die RRDs, sondern merkt sie sich im Hauptspeicher, um sie später dann gesammelt in die jeweilige RRD zu schreiben. So wird die Anzahl der Schreibzugriffe auf die Platte (oder in das SAN!) deutlich reduziert.

Damit im Falle eines Neustarts keine Daten verloren gehen, werden die Updates zusätzlich in Journaldateien geschrieben. Dies bedeutet zwar auch Schreibzugriffe, aber da hier die Daten direkt hintereinander liegen, wird dadurch kaum IO erzeugt.

Damit der RRD-Cache-Daemon effizient arbeiten kann, benötigt er natürlich viel Hauptspeicher. Die benötigte Menge hängt von der Anzahl Ihrer RRDs ab und davon, wie lange Daten gecachet werden sollen. Letzteres können Sie in der Datei etc/rrdcached.conf einstellen. Die Standardeinstellung legt eine Speicherung von 7200 Sekunden (zwei Stunden) plus eine Zufallsspanne von 1800 Sekunden fest. Diese zufällige Verzögerung pro RRD verhindert ein pulsierendes Schreiben und sorgt für eine gleichmäßige Verteilung der IO über die Zeit:

# Data is written to disk every TIMEOUT seconds. If this option is
# not specified the default interval of 300 seconds will be used.
TIMEOUT=3600

# rrdcached will delay writing of each RRD for a random
# number of seconds in the range [0,delay).  This will avoid too many
# writes being queued simultaneously.  This value should be no
# greater than the value specified in TIMEOUT.
RANDOM_DELAY=1800

# Every FLUSH_TIMEOUT seconds the entire cache is searched for old values
# which are written to disk. This only concerns files to which
# updates have stopped, so setting this to a high value, such as
# 3600 seconds, is acceptable in most cases.
FLUSH_TIMEOUT=7200

Eine Änderung der Einstellungen in dieser Datei aktivieren Sie mit:

OMD[mysite]:~$ omd restart rrdcached
Stopping rrdcached...waiting for termination....OK
Starting rrdcached...OK

8.5. Verzeichnisse

Hier ist eine Übersicht über die wichtigsten Dateien und Verzeichnisse, die mit Messdaten und RRDs zu tun haben (alle bezogen auf das Homeverzeichnis der Instanz):

var/check_mk/rrdRRDs im Check_MK-Format
var/pnp4nagios/perfdataRRDs im alten Format (PNP)
var/rrdcachedJournaldateien des RRD-Cache-Daemons
var/log/rrdcached.logLogdatei des RRD-Cache-Daemons
var/log/cmc.logLogdatei des Check_MK-Kerns (Fehlermeldungen zu RRDs)
etc/pnp4nagiosEinstellungen für PNP4Nagios ( Check_MK Raw Edition)
etc/rrdcached.confEinstellungen für den RRD-Cache-Daemon