Auslastung des eigenen Segments ansehen (reloaded)

[MartinP_Do]

Prinzipiell wäre es ggfs hilfreicher, sich alle 7 Tage die aktuelle Wochen-Grafik abzusaugen (CRON Job auf einem NAS z. B. ?), und aufzubewahren. Bei nicht einmal 60 Grafiken pro Jahr kann man da ggfs auch von Hand Ordnung halten ...

 

[boba]

Kann man aktivieren, frisst aber speicher wie blöd, so ab 90 Tage reichen dann selbst 16 gb ram nicht mehr für die Generierung und das schmiert mit malloc ab. Die rrd ist an dem Punkt schon über einen gigabyte groß

Ja das ist halt, weil die rrd Erstellung so angelegt wird, dass sie für den gesamten Zeitraum ein Zeitraster von 10 Sekunden für gespeicherte Datenpunkte vorsieht und keinerlei Konsolidierung auf größere Abstände vorsieht. Das sind gigantisch viele Datenpunkte. Sowas macht man nicht und muss man nicht machen. Niemand braucht eine 10 Sekunden-Auflösung von Daten vor 5 Monaten, wo man doch immer nur Komplettgrafiken über Tage oder Wochen bei sowas erstellen würde. Da sieht man keine 10 Sekunden-Abstände.

Realistisch bei solchen Datenerhebungen ist eine Auflösung von 5 Minuten. Da halten sich die aufzuzeichnenden Datenmengen in Grenzen. Von mir aus auch 1 Minute für letzte Woche.

Will man Peaks erkennen und speichern, wählt man keine super feine Auflösung wie jetzt, sondern fügt weitere RRAs mit der MAX Konsolidierungsfunktion (statt AVERAGE) hinzu und verwendet diese bei der Grafikerstellung. Die MAX Funktion speichert die Höchstwerte vom Daten-Input und konserviert damit die Situation, wenn mal zufällig alle Kanäle während der Messung komplett dicht waren. Braucht man eigentlich nicht, wenn man die generelle Auslastung sehen will (ist ja eigentlich verfälscht im Sinne der Mathematik), aber wenn es einem wichtig vorkommt, kann man es aufnehmen.

Nimmt man meine Erstellung mit der stufenweise gröberen Auflösung für ältere Daten, kann man direkt 1 Jahr speichern. Die rrd Datei ist gerade mal knapp 4MB groß.
Will man die Peaks mit speichern, erweitert man die Erstellung um:

RRA:MAX:0.5:1:1440 \
RRA:MAX:0.5:5:2016 \
RRA:MAX:0.5:30:2976 \
RRA:MAX:0.5:60:8760

Wie gesagt, das ist rrd Theorie. Konkret umsetzen für einen Grafik-Export muss man das natürlich dann im Skript.

 

[bliblablubbe]

Ich nutze die Aufzeichnung tatsächlich zur Zeit sehr hochauflösend, weil ich kurze Einbrüche sehen möchte. Da geht der Traffic für ca. 5s im segment massiv runter, nahezu auf null, erholt sich aber auch schnell wieder. Das ist natürlich nicht der Normalfall, wenn man einfach den Auslastungsverlauf sehen möchte, da gebe ich dir recht, ist die Auflösung nicht nötig.

Ich habe es auf einem PI3 mit 6 XBox Tunern nun häufiger beobachtet, dass die Datenrate als zu niedrig ausgewertet wird. Ich konnte es etwas verbessern, indem ich eine 1s Pause zwischen dem tune und snoob command eingebaut habe. Genauer eingegrenzt habe ich das Phänomen aber noch nicht. Es fällt dadurch auf, dass normalerweise alle 31 Kanäle sehr gleichmäßig Ausgelastet sind. Wenn dann plötzlich beiD urchschnittlich 40 Mbit/s pro Kanal eine Messung einen Wert < 10 Mbit/s ausspuckt, dann ist dieser vermutlich nicht korrekt. Es ist meist der gleiche Tuner betroffen aber auch nicht in jedem Scan, sondern eher bei jedem 3-5 Scan mit diesem Tuner.(evtl hat natürlich auch die Hardware eine Macke).
Hat jemand etwas ähnliches beobachtet?

 

[boba]

Ich habe mal ein bisschen mit der Grafikerstellung herumgespielt. Rrdtool kann auch hübsche Grafiken produzieren: (Ich habe das Layout ein wenig von Cacti geklaut)



Das grüne sind die übereinandergestapelten Auslastungen der einzelnen Kanäle. Sieht ganz hübsch aus, und in der 1h-Grafik kann man damit ganz gut Unregelmäßigkeiten/unausbalancierte Auslastungen zwischen den Kanälen sehen. Bei größeren Zeitintervallen eher sinnlos, sieht aber hübscher aus als den Platz frei zu lassen. Unten der rote Bereich sind die einzelnen Kanäle nochmal übereinander gemalt so wie es auch das originale CableLoadMonitor macht. Je schmaler dieser Bereich, desto ausgewogener und gleichverteilter (also desto besser) die Kanäle.

Der rosa Flaum oberhalb sind die Peaks, also die Maximalwerte, die gelesen wurden. Sieht man bei längeren Intervallen besser. Die Peaks würden durch die Mittelung/Durchschnittsberechnung bei der Aggregierung hin zu größeren Intervallen verloren gehen, wenn man das nicht extra aufbewahrt.

Die graue Linie oben ist die "95th percentile". Unterhalb dieser Linie sind 95% aller Daten.
Dann gibts in längeren Intervallen noch eine blaue Linie, das ist eine Trendlinie der letzten 24 Stunden. Durch dieses Intervall sind alle Tag/Nacht Schwankungen ausgemittelt und man könnte bei einer Grafik mit einem Zeitraum von einigen Monaten mit einem Blick sehen, ob sich die Segmentauslastung tendenziell eher erhöht oder eher erniedrigt. Erhöht sie sich, könnte man sogar voraussagen, wann man selbst Performanceprobleme durch überhöhte Segmentauslastung bekommt.

Was noch fehlt, das ist das Segment-Limit, eine statische horizontale Linie oben mit der maximal möglichen Auslastung. Da weiß ich nicht so genau, welchen Wert ich da ansetzen kann.






Wenn man die rrd Datei so ändert, wie ich vorgeschlagen hatte, kann man größere Zeitspannen darstellen. Das ist insbesondere für Trends interessant (die blaue Linie mittendurch). Da kann man z.B. sehen, ob im eigenen Segment innerhalb der letzten Monate die Tendenz eher zu höherer oder eher zu niedrigerer Auslastung tendiert. Da ich das erst heute gemacht habe, habe ich noch nicht wirklich mehr als die Daten von 7 Tagen, aber so als Vorab-Bild:





Angehängt sind 2 Shellskripte.

create_rrd.sh konvertiert die von CableLoadMonitor produzierte existierende rrd in eine mit besserer (effizienterer) Datenspeicherung, so dass da bis 1 Jahr drin ist. Die davon produzierte *.rrd wird weiterhin von CableLoadMonitor befüllt - da muss man gar nix dran ändern.

cableload_graph.sh produziert die Grafiken. Gibt man keine Parameter an, schreibt es alle vorbereiteten Grafiken (also alle vorbereiteten Intervalle). Gibt man ein Intervall an, schreibt es nur die Datei für dieses Intervall. Das kann man direkt via Cron-Job aufrufen, indem man z.B. in einem 5-minütigen Cron-Job "cableload_graph.sh 1h" aufruft, in 1-stündigem Job "cableload_graph.sh 6h" und so weiter in immer breiteren Cron-Intervallen die längeren Grafiken. Es muss im selben Verzeichnis wie CableLoadMonitor laufen, denn es liest CableLoadMonitor.cfg aus für die Frequenzen, um die in der Grafik anzeigen zu können.

 

[boba]

ps. beachtet auch mal die "Total bytes transferred". Das sind die Bytes, die im angegebenen Zeitraum übertragen wurden. Schaut euch den Wert mal von der 2Tages-Grafik an. Das ist nur ein Segment. Jetzt stellt euch vor, wie viele Segmente Vodafone hat (hunderte, wahrscheinlich tausende), und wie viele Internetprovider es in Deutschland, in Europa, in der Welt gibt. Das sind zusammen ungeheure, nicht vorstellbare und mit dem Gehirn nicht erfassbare Datenmengen, die da übertragen werden.

Ich hoffe, ihr verballert euren persönlichen Anteil daran nicht nur mit Internet-Speedtests.

 

[why_]

Ich hab das mal getestet, da bekomme ich allerdings.

ERROR: the RRD does not contain an RRA matching the chosen CF

Per Google konnte ich nicht wirklich rausfinden was genau der Fehler ist.
Installiert ist RRDtool 1.7.1

Meine rrd die ich bisher von sparkies Script generieren lassen ist 30 Tage groß.
Eine Idee was ich falsch mache?
Danke für die hilfe.

 

[Mike0185]

Die gleichen Errors erhalte ich auch, beim Ausführen unter einem Pi3+ mit:

sudo bash cableload_graph.sh

 

[MartinP_Do]

Werden denn aus dem neuen RRD auf dem üblichen Weg laufend Grafiken mit dem Cableloadmonitor fehlerfrei erzeugt?

 

[sparkie]

interessiert lese ich hier ab und zu mit was ihr für Ideen habt

ich komme aber frühestens im Laufe der nächsten Woche dazu im Script etwas davon zu integrieren.

Github Pull Requests wären mir natürlich am liebsten

wenn jemand Schreibrecht auf das Repos haben möchte bitte PN

 

[why_]

Werden denn aus dem neuen RRD auf dem üblichen Weg Grafiken fehlerfrei erzeugt?

Edit sorry falsch verstanden

 

[MartinP_Do]

Wenn ich das richtig verstehe, erzeugt "create_rrd.sh" aus der Datei/Datenbank "CableLoadMonitor.rrd" die Datei/Datenbank "CableLoadMonitor-X.rrd"

Danach muss man z. B. mit

mv CableLoadMonitor.rrd CableLoadMonitor_sicher.rrd
mv CableLoadMonitor-X.rrd CableLoadMonitor.rrf

die Datei "scharfschalten"

Will man das nicht muss man die Auskommentierungen in cableload_graph.sh bei "suffix" anders setzen

channels=31
#suffix="-X"
suffix=""

 

[Mike0185]

Interessant!

Müssen dann create_rrd.sh und cableload_graph.sh in einen crontab, damit diese alle x-Minuten automatisch ausgeführt werden?

 

[MartinP_Do]

Die davon produzierte *.rrd wird weiterhin von CableLoadMonitor befüllt - da muss man gar nix dran ändern.

Wenn ich das richtig verstanden habe, kommt das Skript von @sparkie auch mit der veränderten RRD-Struktur zurecht - sollte also die gewohnten PNG-Dateien weiterhin ausspucken und die veränderte RRD-Datei aktualisieren, wenn man es laufen lässt ...

RRD Datei umbenennen, CableLoadMonitor Skript starten, dann sollte alles wie vorher laufen ...

Ich werde das aber erst heute abend ausprobieren (und zur Vorsicht die ursprüngliche RRD-Datei sichern ;-) )

 

[MartinP_Do]

Was noch fehlt, das ist das Segment-Limit, eine statische horizontale Linie oben mit der maximal möglichen Auslastung. Da weiß ich nicht so genau, welchen Wert ich da ansetzen kann.

Bei 256QAM und Euro-DOCSIS ca 50 MBit/s pro Kanal.
Bei 24 Kanälen also 1,2 GBit/s, Bei 31 1,55 GBit/s

 

[boba]

Also zur Vorgehensweise:

• einmalig die *.rrd Datei konvertieren, und zwar einmal create_rrd.sh ausführen, das erstellt CableLoadMonitor-X.rrd mit den Daten aus der alten. Das braucht man dann nicht wieder. Nicht in cron aufnehmen!
• einmalig mv -f CableLoadMonitor-X.rrd CableLoadMonitor.rrd ausführen, damit schiebt man CableLoadMonitor die neue rrd unter. Das braucht man dann nicht wieder. Nicht in cron aufnehmen!
• immer wenn man neue Grafiken haben will, ruft man cableload_graph.sh auf. Kann man in cron aufnehmen.

CableLoadMonitor kommt mit der neuen rrd zurecht, aber für die Grafikgenerierung benötigt cableload_graph.sh die neue rrd - da sind Dinge drin, die nicht in der originalen Datei drin sind. Im Detail: es ist eine neue Datenreihe mit den MAX Werten enthalten. Daher rühren auch die Fehler "ERROR: the RRD does not contain an RRA matching the chosen CF".
Man sollte auch CableLoadMonitor unbedingt die neue rrd aktualisieren lassen, damit sich dort historische Daten ansammeln, die über 1 Woche hinausgehen. Wenn man die alte behält und immer wieder neu konvertiert, hat man immer nur Daten von 1 Woche drin.


Wenn man Backups alter rrd Dateien mit historischen Daten hat, kann man bei der Konvertierung mit etwas Fummelarbeit einmalig in die in die neue rrd mergen und hat gleich historische Daten im Graph.
Schaut euch create_rrd.sh an. Das sieht so aus:

rrdtool create CableLoadMonitor-X.rrd \
-r CableLoadMonitor.rrd \
-s 60 \
DS:f00:GAUGE:120:U:U \
DS:f01:GAUGE:120:U:U \
[...]

Man kann mehrere -r <alte datei>.rrd Parameter angeben. Wenn ihr also 5 Backups habt, und die habt ihr in lauter verschiedenen Verzeichnissen namens backup1, backup2, backup3, ..., dann macht das so:

rrdtool create CableLoadMonitor-X.rrd \
-r CableLoadMonitor.rrd \
-r backup1/CableLoadMonitor.rrd \
-r backup2/CableLoadMonitor.rrd \
-r backup3/CableLoadMonitor.rrd \
-r backup4/CableLoadMonitor.rrd \
-r backup5/CableLoadMonitor.rrd \
-s 60 \
DS:f00:GAUGE:120:U:U \
DS:f01:GAUGE:120:U:U \
[...]

Die Reihenfolge ist egal. rrdtool zieht sich die Daten immer korrekt zusammen.

 

[boba]

Werden denn aus dem neuen RRD auf dem üblichen Weg laufend Grafiken mit dem Cableloadmonitor fehlerfrei erzeugt?

Ja, die werden weiterhin parallel erstellt.

 

[MartinP_Do]

Ganz smooth ist es noch nicht - ich bin in einem 24-Kanal Segment - da sind wohl irgendwo noch 31 Kanäle hartcodiert

650:658:666:674:682:690:698:706:746:754:762:770 -i -v
evaluating given downstream channel frequencies
downstream channel frequencies now in use: [ 24 ]
546/QAM256 554/QAM256 562/QAM256 570/QAM256 578/QAM256 586/QAM256 594/QAM256
602/QAM256 618/QAM256 626/QAM256 634/QAM256 642/QAM256 650/QAM256 658/QAM256
666/QAM256 674/QAM256 682/QAM256 690/QAM256 698/QAM256 706/QAM256 746/QAM256
754/QAM256 762/QAM256 770/QAM256
graph display mode: accumulated
graph destination dir: /var/www/html/
recording RRA step size: 10 seconds
recording RRA history size: 7 day(s) 0 hour(s) 0 minute(s) 0 second(s)
using multiple DVB-C tuners: in parallel (if applicable)
DVB-C bit errors reported: ignored
DVB-C failure recovery method: retry
generating graph for: 1h recording length, size 1200x600 pixels
generating graph for: 6h recording length, size 1200x600 pixels
generating graph for: 1d recording length, size 1200x600 pixels
generating graph for: 3d recording length, size 1200x600 pixels
no Sundtek card(s) found, trying others (unsupported)
DVB-C tuner(s) found: 1, using thereof: 1
SCAN 12:13:15: 15294 21215 15726 14445 16935 14533 14244 16064 14655 19760 17450 15982 15622 12930 12243 18768 15259 19971 14100 18981 23172 17576 16372 22064ERROR: /home/pi/docsis-cable-load-monitor/CableLoadMonitor.rrd: expected 32 data source readings (got 25) from N
403361
RRD 0 12:14:13: MV 12:14:16: DONE 12:14:16
RRD 1 12:14:16: MV 12:14:20: DONE 12:14:20
RRD 2 12:14:20: MV 12:14:27: DONE 12:14:27
RRD 3 12:14:27: MV 12:14:32: DONE 12:14:32
SCAN 12:14:32: 16493ERROR: /home/pi/docsis-cable-load-monitor/CableLoadMonitor.rrd: expected 32 data source readings (got 25) from N
15473ERROR: /home/pi/docsis-cable-load-monitor/CableLoadMonitor.rrd: expected 32 data source readings (got 25) from N
19675ERROR: /home/pi/docsis-cable-load-monitor/CableLoadMonitor.rrd: expected 32 data source readings (got 25) from N
14912ERROR: /home/pi/docsis-cable-load-monitor/CableLoadMonitor.rrd: expected 32 data source readings (got 25) from N
16902ERROR: /home/pi/docsis-cable-load-monitor/CableLoadMonitor.rrd: expected 32 data source readings (got 25) from N
18253ERROR: /home/pi/docsis-cable-load-monitor/CableLoadMonitor.rrd: expected 32 data source readings (got 25) from N
15394ERROR: /home/pi/docsis-cable-load-monitor/CableLoadMonitor.rrd: expected 32 data source readings (got 25) from N
17222ERROR: /home/pi/docsis-cable-load-monitor/CableLoadMonitor.rrd: expected 32 data source readings (got 25) from N
17150ERROR: /home/pi/docsis-cable-load-monitor/CableLoadMonitor.rrd: expected 32 data source readings (got 25) from N

Habe dann die Zeilen die mit "DS:f25 ... " bis "DS:f31 ... " beginnen aus dem Konvertierungsskript gelöscht, und aus dem Backup die alte rrd Datei erneut konvertiert

Jetzt funktioniert es

...
DS:f22:GAUGE:120:U:U \
DS:f23:GAUGE:120:U:U \
DS:f24:GAUGE:120:U:U \
DS:sum:GAUGE:120:U:U \
RRA:AVERAGE:0.5:1:2880 \
...

Jetzt dauert das Generieren der Grafiken nur noch Sekunden ....

RRD 3 12:26:03: MV 12:26:16: DONE 12:26:16

13 Sekunden statt vorher 91 Sekunden ....

RRD 3 20:26:39: MV 20:28:10: DONE 20:28:10

Durchlaufzeit für einen Scan ist länger, als 60 Sekunden:

z. B. 12:26:16 - 12:24:45 = 91 Sekunden

Eigentlich müssen die "Langlauf" Grafiken ja gar nicht so häufig generiert werden - vielleicht die Stunden-Grafik bei jedem Durchlauf, und reihum nur eine der weiter spannenden Grafiken jeweils zusätzlich ...

 

[boba]

Ja, sorry mit den 24 Kanälen. In create_rrd.sh ist das hardcoded drin (muss man halt die überzähligen Kanäle per Hand rauswerfen)

In cableload_graph.sh sollte es reichen, am Anfang des Skriptes die Variable channels=31 auf channels=24 zu ändern.

Bei mir dauert auf einem pi 2b mit 1 Empfänger (der von Microsoft) ein Scan-Durchgang aller 31 Kanäle so um die 79 Sekunden. Das reicht noch für die Toleranzschwelle von 120 Sekunden in der rrd Datei, so dass keine Lücken auftreten, obwohl die step size auf 60 Sekunden steht, also mindestens 1 Datenwert pro Kanal pro 60 Sekunden erwartet werden. CableLoadMonitor ist da total paranoid, es setzt nach jedem Scan sämtliche Werte, und zwar immer auch die zuvor gelesenen. Muss man eigentlich nicht machen, verzerrt das Ergebnis im statistisch-mathematischem Sinne. Das hat sparkie wohl wegen des ursprünglichen 10 Sekunden Rasters gemacht, das auch noch nicht korrekt verwendet wurde (step size 1 und nicht step size 10 wie es bei 10 Sekunden Raster eigentlich nötig wäre).

 

[MartinP_Do]

Kein Problem - ist ja eine übersichtliche Datei, die durch eine Parametrierung sicherlich unübersichtlicher geworden wäre ... Die paar Zeilen weghauen sollte niemanden überfordern, der es geschafft hat, die Sache überhaupt ans Laufen zu bekommen ....

Die cableload_graph.sh ist nicht soo hilfreich, mein Pi 1 wird headless betrieben, und ich müsste das dann über den Webserver, der auf dem Pi 1 läuft sichtbar machen ...

Da habe ich mit meinen rudimentären HTML und Javascript-Kenntnissen "gerade so" eine HTML-Datei hingefummelt. die die Grafiken von @sparkie s Skript einbettet...

 

[boba]

Die cableload_graph.sh ist nicht soo hilfreich, mein Pi 1 wird headless betrieben, und ich müsste das dann über den Webserver, der auf dem Pi 1 läuft sichtbar machen ...

Aber darum gehts ja gerade. Einfach nur eine andere Formatierung des rrd nützt nur, wenn man mehr aus der Datenauswertung macht. Es sollte wirklich nicht so schwer sein, die Generierung via cron anzustoßen und das in einem Verzeichnis zu tun, das via http Webserver freigegeben ist. Das kann man dann beliebig von irgendwo anders einbetten. Es gibt auch unzählige Slideshow- und Bilder-Thumbnail-Funktionalitäten im Internet, die aus einem Haufen Dateien eine hübsche Webansicht machen.

 

[MartinP_Do]

Aber darum gehts ja gerade. Einfach nur eine andere Formatierung des rrd nützt nur, wenn man mehr aus der Datenauswertung macht. Es sollte wirklich nicht so schwer sein, die Generierung via cron anzustoßen und das in einem Verzeichnis zu tun, das via http Webserver freigegeben ist. Das kann man dann beliebig von irgendwo anders einbetten. Es gibt auch unzählige Slideshow- und Bilder-Thumbnail-Funktionalitäten im Internet, die aus einem Haufen Dateien eine hübsche Webansicht machen.

Ist denn die RRD - Datenbank Multiclient-Fähig? Dass ein Prozess die RRD aktualisieren, und der andere für die Grafikerstellung währenddessen parallel Lesend zugreifen kann?

 

[boba]

Ja, das ist sie. Unter anderem genau für sowas sie gebaut. Einige Prozesse aktualisieren (durchaus auch parallel) die Daten, und andere Prozess lesen sie parallel aus für die Visualisierung. Das geht.
Siehe auch: https://lists.oetiker.ch/pipermail/rrd-users/2007-August/013070.html vom Autor höchstpersönlich.

 

[MartinP_Do]

Dann sollte man wirklich das Generieren der Grafiken vom Einsammeln der Daten von dem Tuner / den Tunern separieren.
Den Prozess, der die Daten sammelt kann man dann ja durchlaufen lassen, und die Grafiken werden dann nur alle paar Minuten aktualisiert ...
Die höchste Zoomstufe ggfs. einmal pro Minute, aber die anderen Zoomstufen ggfs nur mit der Darstellungsbreite der Vorstufe

Wenn man also 1 Stunde, 6 Stunden, 24 Stunden, 1 Woche darstellt, wird die 6-Stunden-Grafik nur 1x pro Stunde erzeugt, die 24-Stunden-Grafik alle 6 Stunden usw ...

Nachtrag: Wenn das Rendern der Grafiken aus der RRD-Datenbank auf meinem Rechner ca 3...7 Sekunden dauert, wäre es ja ggfs. auch möglich, die Grafiken erst "OnDemand" zu generieren, wenn die Webseite aufgerufen wird ...

 

[MartinP_Do]

So, habe es erstmal so notdürftig integriert ...

Im Sparkie-Skript die Generierungen bis auf die Stundenübersicht auskommentiert

...
# feel free to add other history sizes (aka generated graphs) as well
RRDGRAPHS[RRDGRAPHS_CNT++] = 60 * 60 " |1h"
# RRDGRAPHS[RRDGRAPHS_CNT++] = 60 * 60 * 6 " |6h"
# RRDGRAPHS[RRDGRAPHS_CNT++] = 60 * 60 * 24 " |1d"
# RRDGRAPHS[RRDGRAPHS_CNT++] = 60 * 60 * 24 * 3 " |3d"
# RRDGRAPHS[RRDGRAPHS_CNT++] = 60 * 60 * 24 * 7 " |7d"
# RRDGRAPHS[RRDGRAPHS_CNT++] = 60 * 60 * 24 * 30 " |30d"
# RRDGRAPHS[RRDGRAPHS_CNT++] = 60 * 60 * 24 * 365 " |365d"
...

Dann in der Crontab ein paar Einträge gemacht

0 */1 * * * bash ~/docsis-cable-load-monitor/cableload_graph.sh 6h
5 */6 * * * bash ~/docsis-cable-load-monitor/cableload_graph.sh 1d
10 0 */1 * * bash ~/docsis-cable-load-monitor/cableload_graph.sh 7d

- Einmal pro Stunde eine 6-Stunden-Grafik erzeugen (zur vollen Stunde)
- Alle sechs Stunden eine Tagesgrafik erzeugen (5 Minuten nach voll)
- Einmal pro Tag eine Wochengrafik erzeugen (um 00:10)

in der "cableload_graph.sh" den Pfad für die Webdokumente als Ziel im filename abgelegt

 filename="/var/www/html/CableLoadMonitor_${intervalname}_${cf}${suffix}.png"

 

[why_]

Da ihr ja euch mit rrd echt gut auszukennen scheint, wisst ihr was beim de-cix graph anders gemacht wird gegenüber dem von bobas script generierten?

Obwohl graph zwei scheinbar mehr Datenpunkte hat ist es irgendwie schwerer einen Trend zu erkennen, oder vertue ich mich da?