@sparkie Ich hätte noch einen Kommentar zu deiner Verwendung von rrdtool. Bitte nicht als Klugscheisserei ansehen, sondern als sachliche Anmerkung.
Also du hast die Konzepte, die hinter rrdtool stehen, nicht so umgesetzt wie man das tun sollte bzw. wie es gedacht ist. Ich versuche mal zu erläutern, wie es gedacht ist eine *.rrd Datei zu erstellen und zu füttern.
Generelles Prinzip aller Messungen: man führt regelmäßig Messungen aus und erhält Werte. Man führt diese Messungen in möglichst festen und gleichen Zeitabständen durch und erhält (Zeit, Wert) Paare. Allerdings ist es in der Realität so, dass Zeitabstände nie ganz gleichmäßig sind, und manchmal fallen auch einzelne Messungen aus.
Der rrdtool Ansatz ist dazu:
Man definiert ein Zeitraster, in dem man gedenkt die Messwerte einzuliefern. In rrdtool Terminologie ist das der step, und er wird in Sekunden angegeben. Der Step unterteilt die Zeit in Intervalle. Hat man einen Step von 300 Sekunden, dann sind die ersten 300 Sekunden ein Intervall, die nächsten 300 Sekunden das nächste Intervall und so weiter.
Alle Datenwerte, die innerhalb eines Intervalls an rrdtool geliefert werden, werden auf den Anfangszeitpunkt des kommenden Intervalls konsolidiert. Ist das Intervall abgelaufen, wird der Mittelwert der gelieferten Datenwerte "primary data point" (pdp) genannt und in der Datenbank abgespeichert. Somit erhält die Datenbank normierte Werte, die so aussehen, als wären sie alle in einem absolut exakten Zeitraster generiert worden, egal wie ungenau das Zeitraster bei der Messung tatsächlich war. So kann man später daraus Grafiken mit exakten Intervallen erstellen.
Abgespeichert werden die primary data points (pdp) in sogenannten round robin archives (rra). Für jedes rra definiert man, wieviele pdp's zu einem in der Datenbank gespeicherten Wert zusammengefasst (aggregiert) werden sollen, und wieviele Punkte abgespeichert werden sollen (ältere Punkte werden automatisch gelöscht, deshalb "round robin").
Die Idee ist, dass man die Daten in mehreren rra's dupliziert abspeichert, mit jeweils unterschiedlicher Aggregierung (Konsolidierung). Die pdp's direkt speichert man z.B. für eine Woche, eine Konsolidierung auf eine halbe Stunde speichert man für einen Monat, die Konsolidierung auf eine Stunde 2 Monate, die Konsolidierung auf einen Tag 1 Jahr. Das spart Speicherplatz und geht davon aus, dass man von älteren Daten nicht mehr die höchste Auflösung benötigt, sondern nur noch einen konsolidierten Überblick. Heutzutage bei praktisch unbegrenztem Speicherplatz nicht mehr ganz zeitgemäß, aber so ist erstmal das Design.
Du hast jetzt mit -s 1 einen Step von 1 angegeben, d. h. jede Sekunde wird ein pdp generiert.
Dann hast du bei den DS Definitionen einen Heartbeat von 120 angegeben. Das bedeutet, es wird für 120 Sekunden der vorherige Wert als pdp übernommen, wenn kein neuer reinkommt.
Mit RRA:AVERAGE:0.1:10:60480 speicherst du einen rra mit der Konsolidierung 10 pdp's, der 60480 Punkte enthält, d.h. den Zeitraum 1s * 10 * 60480 = 604800s (7 Tage) umfasst, und die Konsolidierungsfunktion is AVERAGE, d. h. der Mittelwert der pdp's.
So isses nicht ganz gedacht.
Du gibst einen step von 1 vor, d.h. dein rrdtool erwartet jede Sekunde einen neuen Messwert. Bei einem Tuner und 31 Kanälen purzelt bei mir in etwa alle 80-90 Sekunden eine Messung heraus. Also hätte man nur jeden 80ten pdp mit Messwert und alle anderen Werte wären UNKNOWN. Damit das jedoch nicht passiert, sondern die Datenbank so lange mit den alten Werten befüllt wird, bis ein neuer Wert kommt, hast du einen heartbeat von 120 angegeben, d.h. bis zu 120 Sekunden lang wird nicht UNKNOWN eingetragen, wenn kein Wert kommt, sondern der vorherige Wert kopiert.
Dann gibts da noch die ominöse 0.1 bei dir in der RRA Definition, das ist der xff oder "xfiles factor". Der bestimmt, wieviele der zu konsolidierenden Werte tatsächliche Werte enthalten müssen und nicht UNKNOWN sein dürfen. Wenn nämlich zuviele Werte fehlen, dann wäre die Konsolidierung ungenau und man kann nicht konsolidieren - der konsolidierte Werte müsste dann auch UNKNOWN sein. Mit 0.1 bei 10 Werten gehst du auf Nummer sicher, damit auch ja ein Wert gespeichert wird, auch wenn es der einzige in dem Intervall ist. Und das kann dann auch durchaus ein kopierter Wert von vorher sein wegen des Heartbeat 120 und kein originaler. Damit werden die Daten recht ungenau und verschmiert.
Die Folge ist zum einen, dass lauter Kopien von alten Datenpunkten in der Datenbank liegen statt UNKNOWN. Und die Genauigkeit ist auch nicht so wahnsinnig hoch, wenn man alte Werte mehrere Minuten lang mitschleppt. Es macht keinen Sinn, mit einer Genauigkeit von 10 Sekunden abzuspeichern, wenn die Daten tatsächlich nur eine Genauigkeit von 120 Sekunden haben.
Best practice für heartbeat ist step*2, d.h. es soll mal ein Datenpunkt ausfallen dürfen, aber wenn mehr ausfallen, dann kann man auch nichts in der Datenbank abspeichern.
Best practice für xff ist 0.5, d.h. wenigstens die Hälfte in einem Konsolidierungsintervall sollte an Datenpunkten vorhanden sein, sonst kann man nicht konsolidieren - es sind schlicht zu wenig Daten vorhanden.
Heartbeat und xff mit anderen Werten, auch extremen Werten wie den deinen, machen Sinn für bestimmte Typen von Datensammlungen, z.B. freier Festplattenplatz, der sich nur ganz behäbig verändert. Für Durchsatzmessungen wie den hier jedoch nicht.
tl;dr
Am Anfang muss die Überlegung stehen, welches Intervall man möchte. Bei einem Tuner auf einem Raspberry Pi 2 wie dem meinen ist das minimale sinnvolle Intervall 90 Sekunden. Bei so einer Konfiguration wäre also ein step von 90 oder höher angesagt.
Das Heartbeat setzt man auf step*2 = 180, weil mal ein Datenwert ausfallen kann ohne dass man eine Lücke sehen will. Aber nicht höher, weil wenn es keine Werte gibt, sollte man keine künstlich generieren.
Das RRA erstellt man dann ohne Konsolidierung, so dass man direkt den Datenwert alle step Sekunden speichert. Der xff ist hier irrelevant, weil nichts konsolidiert wird. Da man aber was eintragen muss, nehmen wir best practice 0.5.
Für 1 Woche sind das 7*24*3600 / 90 = 6720 Datenpunkte.
Also:
Bash:
rrdtool create \
test.rrd \
--start 0 --step 90 \
DS:f00:GAUGE:180:U:U \
[...]
RRA:AVERAGE:0.5:1:6720
Da schrumpft die *.rrd Datei auch gleich um einiges, die *.png Erstellung geht etwas schneller, und es werden nicht weniger Daten gespeichert als zuvor. Die Grafiken hingegen werden so exakt wie die Datenerhebung es erlaubt.
Wenn man längere Zeiträume aufheben möchte, kann die 6720 erhöhen. Man kann aber auch zusätzliche RRAs hinzufügen, die höher aggregierte Werte speichern. Cacti beispielsweise erhebt Daten standardmäßig in 5-Minuten Takt, d.h. das hat einen step von 300. Wir könnten das z.b. hier simulieren und einen auf 300 Sekunden konsolidierten RRA hinzufügen. Leider geht das nicht direkt, weil 300 nicht durch 90 teilbar ist - unsere pdp's haben ja eine Auflösung von 90 Sekunden. Aber wenn wir den step auf 100 hochdrehen, dann sind 3 pdp's 3*100 = 300 Sekunden. Will ich 1 Monat so aufheben, bräuchte ich 31 Tage * 24 Stunden * 3600 Sekunden / 100 / 3 = 8928 Datenpunkte. Der erste rra hätte 7 Tage * 24 Stunden * 3600 Sekunden / 100 = 6048 Datenpunkte.
Also dann:
Bash:
rrdtool create \
test.rrd \
--start 0 --step 100 \
DS:f00:GAUGE:200:U:U \
[...]
RRA:AVERAGE:0.5:1:6048 \
RRA:AVERAGE:0.5:3:8928
Wer ein schnelleres System hat, bei dem in 75 Sekunden alles gescannt werden kann, kann den step auch auf 75 setzen und hätte dann 4*75 = 300 und bräuchte 31 Tage * 24 Stunden * 3600 Sekunden / 75 / 4 = 8928 Datenpunkte. Der erste, nicht konsolidierte RRA für 7 Tage hätte 7 Tage * 24 Stunden * 3600 Sekunden / 75 = 8064 Datenpunkte.
Also:
Bash:
rrdtool create \
test.rrd \
--start 0 --step 75 \
DS:f00:GAUGE:150:U:U \
[...]
RRA:AVERAGE:0.5:1:8064 \
RRA:AVERAGE:0.5:4:8928
Bei den 8 Tunern von no sleep könnte man bis runter auf step=10 gehen, also alle 10 Sekunden. Das wäre so in etwa die Datendichte, die das ursprüngliche rra hat, aber diesmal korrekt aufgebaut.
Das erste rra benötigt 7 Tage * 24 Stunden * 3600 / 10 = 60480 Datenpunkte, das zweite für 31 Tage * 24 Stunden * 3600 / 10 / 30 = 8928
Bash:
rrdtool create \
test.rrd \
--start 0 --step 10 \
DS:f00:GAUGE:20:U:U \
[...]
RRA:AVERAGE:0.5:1:60480 \
RRA:AVERAGE:0.5:4:8928
Bei allen besteht das zweite rra immer aus 8928 Punkten, weil es überall derselbe Zeitraum (31 Tage) mit demselben konsolidierten Intervall (300 Sekunden) ist.
Mein Vorschlag für CableLoadMonitor:
bei der Generierung des rra die minimal mögliche Auflösung abfragen/berechnen/abschätzen und step entsprechend setzen sowie die Anzahl der Datenpunkte entsprechend ausrechnen. De facto allerdings machen Auflösungen unter 120 Sekunden (step=120) wenig Sinn, weil bei niedrigeren Steps zuviele Spikes angezeigt werden und die Grafiken arg ausgefranst werden ohne damit wirklich einen Mehrwert zu bieten. Die bisherige Mittelwert-von-Mittelwert-von-geschätzten Werten Berechnung finde ich ehrlich gesagt nicht ausreichend genau. Die aufgezeichneten Daten sollten möglichst genau das wiederspiegeln, was man gemessen hat. Will man nicht 100% die gemessenen Daten, sondern Trends und gemittelte Werte in der Grafik anzeigen, dann sollte man die dafür vorgesehenen Ausdrücke und berechnete virtuelle Datenquellen bei der Grafikerzeugung nutzen. Aber nicht die Datenwerte schon beim abspeichern verschmieren.
