• Kunden aus Hessen und Nordrhein-Westfalen können über die Rufnummer 0221 / 466 191 00 Hilfe bei allen Problemen in Anspruch nehmen.
    Kunden aus Baden-Württemberg können über die Rufnummer 0711 / 54 888 150 Hilfe bei allen Problemen in Anspruch nehmen.

Auslastung des eigenen Segments ansehen (reloaded)

Diskutiere Auslastung des eigenen Segments ansehen (reloaded) im Internet und Telefon über das TV-Kabelnetz Forum im Bereich Internet und Telefon bei Unitymedia; Prinzipiell wäre es ggfs hilfreicher, sich alle 7 Tage die aktuelle Wochen-Grafik abzusaugen (CRON Job auf einem NAS z. B. ?), und aufzubewahren...
MartinP_Do

MartinP_Do

Beiträge
3.846
Reaktionen
186
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

boba

Beiträge
1.395
Reaktionen
438
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:
Code:
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

Beiträge
14
Reaktionen
1
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

boba

Beiträge
1.395
Reaktionen
438
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)

CableLoadMonitor_2d_AVERAGE.png

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.

CableLoadMonitor_1h_AVERAGE.png
CableLoadMonitor_6h_AVERAGE.png

CableLoadMonitor_7d_AVERAGE.png

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:

CableLoadMonitor_14d_AVERAGE.png

CableLoadMonitor_2m_AVERAGE.png

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.
 

Anhänge

Zuletzt bearbeitet:
boba

boba

Beiträge
1.395
Reaktionen
438
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_

Beiträge
989
Reaktionen
202
Ich hab das mal getestet, da bekomme ich allerdings.
Code:
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

Mike0185

Beiträge
441
Reaktionen
39
Die gleichen Errors erhalte ich auch, beim Ausführen unter einem Pi3+ mit:

Code:
sudo bash cableload_graph.sh
 
MartinP_Do

MartinP_Do

Beiträge
3.846
Reaktionen
186
Werden denn aus dem neuen RRD auf dem üblichen Weg laufend Grafiken mit dem Cableloadmonitor fehlerfrei erzeugt?
 
Zuletzt bearbeitet:

sparkie

Beiträge
812
Reaktionen
53
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:D

wenn jemand Schreibrecht auf das Repos haben möchte bitte PN
 
  • Gefällt mir
Reaktionen: Holzlenkrad
MartinP_Do

MartinP_Do

Beiträge
3.846
Reaktionen
186
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

Code:
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

Code:
channels=31
#suffix="-X"
suffix=""
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: why_
Mike0185

Mike0185

Beiträge
441
Reaktionen
39
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

MartinP_Do

Beiträge
3.846
Reaktionen
186
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 ;-) )
 
Zuletzt bearbeitet:
boba

boba

Beiträge
1.395
Reaktionen
438
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:
Bash:
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:
Bash:
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.
 
  • Gefällt mir
Reaktionen: why_ und Mike0185
MartinP_Do

MartinP_Do

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

Code:
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

Code:
...
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 ....

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

13 Sekunden statt vorher 91 Sekunden ....

Code:
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 ...
 
Zuletzt bearbeitet:
boba

boba

Beiträge
1.395
Reaktionen
438
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).
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: MartinP_Do
MartinP_Do

MartinP_Do

Beiträge
3.846
Reaktionen
186
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...
 
Zuletzt bearbeitet:
boba

boba

Beiträge
1.395
Reaktionen
438
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

MartinP_Do

Beiträge
3.846
Reaktionen
186
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?
 
Zuletzt bearbeitet:
MartinP_Do

MartinP_Do

Beiträge
3.846
Reaktionen
186
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 ...
 
Zuletzt bearbeitet:
MartinP_Do

MartinP_Do

Beiträge
3.846
Reaktionen
186
So, habe es erstmal so notdürftig integriert ...

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


Code:
...
# 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

Code:
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


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

why_

Beiträge
989
Reaktionen
202
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?
 
Thema:

Auslastung des eigenen Segments ansehen (reloaded)

Auslastung des eigenen Segments ansehen (reloaded) - Ähnliche Themen

  • Hat Vodafone zu viele Techniker und muss die jetzt irgendwie Auslasten?

    Hat Vodafone zu viele Techniker und muss die jetzt irgendwie Auslasten?: Hallo zusammen, ich frag mich schon länger was bei Vodafone schief läuft. Da hier auch Leute mitlesen die das ausbaden müssen würde ich gerne mal...
  • Auslastung durch aktuelle Corona-Lage

    Auslastung durch aktuelle Corona-Lage: Bis vor wenigen Tagen habe ich nix von irgendwelchen Auslastungen des Netzes durch die Corona-Lage bemerkt, aber seit ca. Montag habe ich immer...
  • Connect Box ping auslastung

    Connect Box ping auslastung: Hallo Zusammen Diese " Werte " sind doch nicht normal Oder ? https://www.directupload.net/file/d/5357/nkwu36cq_jpg.htm RxMER liegt bei 37,5...
  • Auslastung des Netztes

    Auslastung des Netztes: Hallo , Viele Leute schreiben oft von geschwindigkeits einbußesn in den abendstunden . Ich konnte da noch nichts feststellen mit meine 32mbit...
  • Verbindungsabbruch bei Auslastung der Geschwindigkeit

    Verbindungsabbruch bei Auslastung der Geschwindigkeit: Hallo Forum, ich wende mich an euch mit folgendem Problem: 1. Ausstattung FB6360 Firmware-Version 85.04.89-19078 Sync: 70,5 MBit/s 5,5 MBit/s...
  • Ähnliche Themen
  • Hat Vodafone zu viele Techniker und muss die jetzt irgendwie Auslasten?

    Hat Vodafone zu viele Techniker und muss die jetzt irgendwie Auslasten?: Hallo zusammen, ich frag mich schon länger was bei Vodafone schief läuft. Da hier auch Leute mitlesen die das ausbaden müssen würde ich gerne mal...
  • Auslastung durch aktuelle Corona-Lage

    Auslastung durch aktuelle Corona-Lage: Bis vor wenigen Tagen habe ich nix von irgendwelchen Auslastungen des Netzes durch die Corona-Lage bemerkt, aber seit ca. Montag habe ich immer...
  • Connect Box ping auslastung

    Connect Box ping auslastung: Hallo Zusammen Diese " Werte " sind doch nicht normal Oder ? https://www.directupload.net/file/d/5357/nkwu36cq_jpg.htm RxMER liegt bei 37,5...
  • Auslastung des Netztes

    Auslastung des Netztes: Hallo , Viele Leute schreiben oft von geschwindigkeits einbußesn in den abendstunden . Ich konnte da noch nichts feststellen mit meine 32mbit...
  • Verbindungsabbruch bei Auslastung der Geschwindigkeit

    Verbindungsabbruch bei Auslastung der Geschwindigkeit: Hallo Forum, ich wende mich an euch mit folgendem Problem: 1. Ausstattung FB6360 Firmware-Version 85.04.89-19078 Sync: 70,5 MBit/s 5,5 MBit/s...