Messwerte und Graphing

Der Graphdesigner ist in vier Bereiche unterteilt:

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

Die im Graphen enthaltenen Kurven können hier direkt bearbeitet werden. 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:

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 Checkmk generell für Input/Output-Graphen wie den folgenden verwendet:

In der Spalte Actions finden Sie zu jeder angelegten Metrik einen Knopf zum klonen derselben. So können Sie fix Kurven kopieren und schlicht etwa den Host-Namen austauschen.

Über den Metrics Kasten können Sie neue Metriken zum Graphen hinzufügen. Sobald Sie in das erste Feld einen Host-Namen ausgewählt haben, 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.

Auf die gleiche Art blenden Sie über die Funktion Add new scalar die Werte eines Services für WARN, CRIT, Maximum und Minimum als waagerechte Linien ein.

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.

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.

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, erscheinen im Kasten Metrics in der Zeile Operation on selected metrics Knöpfe für alle wählbaren Verknüpfungen:

Ein Klick auf Sum kombiniert die beiden gewählten Zeilen zu einer neuen Kurve, deren Farbe der obersten ausgewählten Metrik entspricht. Der Titel der neuen Kurve wird zu Sum of System, User. 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:

Wenn Sie die Messwerte der Vergangenheit betrachten, sind Sie manchmal nicht an deren genauem Verlauf interessiert, sondern eventuell nur an einer groben Zusammenfassung wie: Die durchschnittliche CPU-Auslastung der letzten 7 Tage. Das Ergebnis wäre dann einfach eine Zahl als Prozentwert wie 88%.

Sie können in einer Tabelle von Hosts oder Services Spalten hinzufügen, welche den Durchschnitt, das Minimum, das Maximum oder andere Zusammenfassungen einer Metrik über einen bestimmten Zeitraum als Zahl darstellen. Das ermöglicht Ihnen dann auch Auswertungen, die nach diesen Spalten sortieren und so z.B. die Liste derjenigen ESXi-Hosts anzeigen, die im Vergleichszeitraum die geringste Auslastung hatten.

Um solche Messwerte in einer Ansicht anzuzeigen, gehen Sie so vor:

Zunächst benötigen Sie eine Ansicht, zu welcher die Spalten hinzugefügt werden sollen. Dies kann entweder eine Ansicht von Hosts oder von Services sein. Einzelheiten zum Anlegen oder Editieren von Ansichten finden Sie in dem Artikel über Ansichten.

Für das folgende Beispiel wählen wir die Ansicht All hosts, die Sie über Monitor > Hosts > All hosts öffnen können. Wählen Sie im Menü Display > Customize view. Das führt Sie zur Seite Clone view, mit der Sie sich die Ansicht nach Belieben zurechtkonfigurieren können.

Damit das Original All hosts nicht durch die Kopie überlagert wird, wählen Sie eine neue ID und auch einen neuen Titel, unter der die Ansicht später im Monitor-Menü angezeigt wird.

Dann entfernen Sie (optional) alle Spalten, die die Anzahl der Services in den verschiedenen Zuständen zeigen.

Fügen Sie nun eine neue Spalte vom Typ Services: Metric History hinzu. Da dies eine Spalte für Services ist, benötigen Sie im Falle einer Host-Ansicht als erste Auswahl den Spaltentyp Joined column, welcher das Anzeigen einer Service-Spalte in einer Host-Tabelle ermöglicht. Bei einer Service-Ansicht reicht es, wenn Sie eine neue Column hinzufügen.

In Metric wählen Sie den Namen der Metrik aus, die historisch ausgewertet werden soll. Sollten Sie unsicher über den Namen der Metrik sein, finden Sie diesen in den Service-Details beim Eintrag Service Metrics:

Im Beispiel wählen wir die Metrik CPU utilization, welche hier zufällig gleich lautet wie der Name des Services.

Bei RRD consolidation wählen Sie am besten den gleichen Wert wie weiter unten bei Aggregation function, da es wenig sinnvoll ist, Dinge wie „das Minimum vom Maximum“ zu berechnen. Was es mit der Auswahlmöglichkeit bei RRDs auf sich hat, erfahren Sie im folgenden Kapitel über die Organisation der RRD-Daten.

Der Time range ist der Zeitraum in der Vergangenheit, über den Sie etwas erfahren wollen. In Beispiel sind es die letzten sieben Tage, was exakt 168 Stunden entspricht.

Column title ist dann der Spaltentitel, also zum Beispiel Util @ 7 days. Wundern Sie sich nicht, dass später noch ein Feld mit dem Namen Title kommt. Dieses sehen Sie nur dann, wenn hier eine Joined column benutzt wird, welche immer die Angabe eines Titels ermöglicht. Lassen Sie den zweiten Titel einfach leer.

Zu guter Letzt geben Sie im Feld Of Service den Namen des Services ein, zudem die oben gewählte Metrik gehört. Achten Sie auf die exakte Schreibweise des Services inklusive Groß- und Kleinschreibung.

Nach dem Speichern erhalten Sie jetzt eine neue Ansicht mit einer weiteren Spalte, welche die prozentuale CPU-Auslastung der letzten sieben Tage anzeigt:

Hinweise

Checkmk 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 werden nach 10 Tagen und 90 Tagen umgesetzt:

Jetzt stellt sich natürlich die Frage, wie denn nun fünf Werte sinnvoll zu einem einzigen konsolidiert werden sollen. Als Konsolidierungsfunktionen bieten sich 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 Checkmk 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 Round-Robin-Archiv (RRA). Im Standardaufbau gibt es also insgesamt 12 RRAs. So benötigt das Standardschema von Checkmk 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 I/O" sogar reduziert! Der Grund: Ein Update muss nicht mehr in 12 verschiedene RRAs geschrieben werden, sondern nur noch in eines.

Wenn Ihnen das voreingestellte Speicherschema nicht zusagt, so können Sie dieses über Regelsätze ändern (sogar für Hosts oder Services unterschiedlich). Den nötigen Regelsatz finden Sie am einfachsten über die Regelsuche — also das Menü Setup. Geben Sie dort einfach RRD in das Suchfeld 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 Standardeinstellungen:

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 (precision) 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 (precision) 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 Checkmk umbauen lassen. Dazu dient der Befehl cmk --convert-rrds, bei welchem sich immer die Option -v (verbose) anbietet. Checkmk kontrolliert dann alle vorhandenen RRDs und baut diese nach Bedarf in das eingestellte Zielformat um.

Wichtig: Um die Integrität der in den RRDs enthaltenen Daten sicherzustellen, stoppen Sie stets Ihre Instanz (mit omd stop) bevor Sie mit cmk --convert-rrds existierende RRDs konvertieren.

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

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.

Die oben gezeigte Regel hat noch eine weitere Einstellung: RRD storage format. Mit dieser können Sie zwischen zwei Methoden wählen, wie Checkmk die RRDs erzeugt. Das Format One RRD per host/service (oder kurz Checkmk-Format) speichert dabei alle Metriken eines Hosts bzw. Services in einer einzigen RRD-Datei. 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.

Sollten Ihre Checkmk-Instanzen mit einer älteren Version als einer der Checkmk Enterprise Editions 1.2.8 erzeugt worden sein, lohnt sich gegebenenfalls ein genauer Blick darauf, ob ihre Messdaten jemals in das aktuelle und weitaus performantere Format konvertiert worden sind. Sollten die Daten noch im alten Format vorliegen, können Sie diese über das Anlegen einer Regel im oben gezeigten Regelsatz auf das Checkmk-Format umstellen.

Auch hier benötigen Sie anschließend den Befehl cmk --convert-rrds, und auch hier gilt: Stoppen Sie stets Ihre Instanz bevor Sie existierende RRDs konvertieren.

Wie Sie an der Warnung sehen können, lässt Checkmk 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 erledigen:

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:

Alle neuen Messwerte für die RRDs werden zunächst vom Checkmk Micro Core (Enterprise Editions) bzw. von NPCD (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 zwischengespeichert 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:

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

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