Planungen zu eisgraph (inkl. Umfrage)

[Thomas Quast]

Hallo,

bevor ich mir die Arbeit mache und Features in eisgraph einbaue, moechte
ich hier vorher eine Umfrage machen, ob es sich ueberhaupt lohnt.

Um was geht es?

Derzeit werden gesammelte Werte in eine RRD geschrieben. Erweiterung des
Zeitraums ueber 1 Jahr hinaus ist ohne weiteres nicht moeglich, da die
Werte, stehen sie einmal in einer RRD nicht erneut zur Verarbeitung zur
Verfuegung stehen.

Mir schwebt nun vor, die gesammelten Werte von nun an, in eine SQL-DB
zu schreiben. Es ist ohne weiteres moeglich, die Werte von dort in eine
RRD zu ueberfuehren, ohne den Originalzustand zu veraendern.

Damit koennen die Grafiken, wenn gewuenscht, wie gewohnt aus rrdtool heraus
generiert werden.

Alternativ schwebt mir noch vor, die Grafiken, wenn auf rrdtool verzichtet
wird, mit gnuplot darzustellen. Hierbei werden die Daten auf jeden Fall in
einer SQL-DB gespeichert.


Zusammengefasst:

- Wie bisher, jedoch Zeitraum auf 2 / 5 / 10 Jahre vergroessert

- Zusaetzliche Moeglichkeit der Datenspeicherung in einer SQL-DB (MariaDB)

- Grafische Darstellung alternativ mit gnuplot


Die derzeitige ToDo-Liste sieht vor, das bis Version 1.6.0 eisgraph von
/usr/local nach /usr/lib umgezogen ist (inkl. aller Module).

Erst ab dann, also ab Version 1.7.0, wuerde ich damit beginnen, o.g. Punkte
umzusetzen und offiziell einzufuehren (sofern ausreichend Interesse besteht).

Ueber reichliche Antworten wuerde ich mich freuen.

Fuer weitere Anregungen bin aber ebenfalls offen.

Gruss,
Thomas

[Thomas Quast]

Hallo Nelson,

Post by Thomas Quast
- Wie bisher, jedoch Zeitraum auf 2 / 5 / 10 Jahre vergroessert

individueller Zeitraum? 09/2018 - 08/2020?

So war das nicht gedacht. Gemeint war, bei Speicherung in einer RRD den
Zeitraum von 3h / 1d / 1m / 1y erweitern auf 2y / 5y / 10y.

Was Du ansprichst, einen Zeitraum frei waehlen zu koennen, wuerde den Einsatz
von CGI Scripts bedeuten. Doch dabei fehlt es mir noch an Wissen/Erfahrung.
Bisher werden beim oeffnen der Website die Grafiken sofort angezeigt, ohne
zutun vom User. Doch dann muesste zuerst der Zeitraum gewaehlt werden.

Post by Thomas Quast
- Zusaetzliche Moeglichkeit der Datenspeicherung in einer SQL-DB (MariaDB)

definitiv wünschenswert für mich. Ich würde aber trotzdem eine
Möglichkeit behalten wollen, für Server, die keine MariaDB
wollen/sollen. Es wird immer solche Puristen geben.

Natuerlich wird das Urspruengliche beibehalten. Aber es bietet sich dann die
Moeglichkeit, die Daten zu speichern in RRD, oder SQL, oder RRD und SQL. ,-)

Post by Thomas Quast
Ueber reichliche Antworten wuerde ich mich freuen.

Meine ist schon mal da.

Vielen Dank.

Ich hoffe es finden sich genug Interessierte :)

Mal sehen. Wenn nicht, baue ich es nur fuer mich. :)

Gruss,
Thomas

[Thomas Quast]

Hallo Nelson,

Post by Thomas Quast

Post by Thomas Quast
- Wie bisher, jedoch Zeitraum auf 2 / 5 / 10 Jahre vergroessert

individueller Zeitraum? 09/2018 - 08/2020?

So war das nicht gedacht. Gemeint war, bei Speicherung in einer RRD den
Zeitraum von 3h / 1d / 1m / 1y erweitern auf 2y / 5y / 10y.

Muss ja nicht sein. Die normalen Grafiken koennen ja weiterhin gleich
angezeigt werden. Die individuelle Anzeige kann ja zu einem Formular
führen, wo man seinen Zeitraum eingeben kann.

Mittlerweile habe ich mir einige Gedanken gemacht und wuerde auch diese
Loesung bevorzugen.

Jetzt könne die Werte aus der SQL-DB gelesen werden und temporäre
Grafiken erstellt werden. Nach der Anzeige soll der User noch
entscheiden, ob er diese behalten will (-> download) oder nicht.
Ein Cron-job schaut einmal täglich nach Bildleichen und führt diese dem
digitalen Recycling zu.
'Ende vom Kompost'

Dein Kompost gefaellt mir. :-)

Mir sind aber mittlerweile einge Ungereimtheiten aufgefallen. rrdtool scheint
mit der Namensgebung von einigen Tabellen in einer SQL-DB nicht zurecht zu
kommen und moniert, das es sie nicht finden kann. Scheint ein Bug in rrdtool
zu sein.

Nach ausgiebigen Tests an drei Datenbanken mit insgesamt 22 Tabellen und
etwas mehr als 215.000 Datensaetzen viel mir auch auf, das der Import in
eine rrd bei einigen Fehlerhaft ist. Da werden einfach Werte 'uebersprungen',
also nicht einfach mit '0' gefuellt, sondern als nicht existent gewertet.

Hmmm ...

Auch zieht sich die Ueberfuehrung von einer SQL-DB in eine rrd etwas hin.
Auf einem i5 benoetige ich fuer ca. 10.000 Datensaetze ca. 60 Sekunden.

Also das wäre meine Herangehensweise, aber ich bin nicht fit in Sachen
Programmierung.

Ist nicht wild, dafuer machst Du guten Kompost. :)

Gruss,
Thomas

[Stefan Heidrich]

Hallo Thomas,

Post by Thomas Quast
Mir schwebt nun vor, die gesammelten Werte von nun an, in eine SQL-DB
zu schreiben. Es ist ohne weiteres moeglich, die Werte von dort in eine
RRD zu ueberfuehren, ohne den Originalzustand zu veraendern.
Alternativ schwebt mir noch vor, die Grafiken, wenn auf rrdtool verzichtet
wird, mit gnuplot darzustellen. Hierbei werden die Daten auf jeden Fall in
einer SQL-DB gespeichert.

finde ich eine gute Idee!

Viele GrÌße
Stefan

[Kay Martinen]

Post by Thomas Quast
bevor ich mir die Arbeit mache und Features in eisgraph einbaue, moechte
ich hier vorher eine Umfrage machen, ob es sich ueberhaupt lohnt.
Derzeit werden gesammelte Werte in eine RRD geschrieben. Erweiterung des
Zeitraums ueber 1 Jahr hinaus ist ohne weiteres nicht moeglich, da die
Werte, stehen sie einmal in einer RRD nicht erneut zur Verarbeitung zur
Verfuegung stehen.

Müssen die Werte nicht eh dort raus kommen um den Graph zu erzeugen?
Kann man die dann nicht auch alle zusammen auslesen und in eine neue
RRD, eine DB oder ein Textfile sichern - zwecks Export, Sicherung oder xyz?

Post by Thomas Quast
Mir schwebt nun vor, die gesammelten Werte von nun an, in eine SQL-DB
zu schreiben. Es ist ohne weiteres moeglich, die Werte von dort in eine
RRD zu ueberfuehren, ohne den Originalzustand zu veraendern.

Umgekehrt nicht?

Post by Thomas Quast
Damit koennen die Grafiken, wenn gewuenscht, wie gewohnt aus rrdtool heraus
generiert werden.

Ich verstehe das mal so das länger als ein Jahr mit rrdtool nicht geht
weil nicht mehr genug datenpunkte gespeichert sind, die Auflösung also
mist wäre oder?

Post by Thomas Quast
Alternativ schwebt mir noch vor, die Grafiken, wenn auf rrdtool verzichtet
wird, mit gnuplot darzustellen. Hierbei werden die Daten auf jeden Fall in
einer SQL-DB gespeichert.

Vom alleinigen Einsatz einer DB für eisgraph bin ich nicht begeistert.
Die jetzige Lösung gefällt mir vor allem weil keine DB involviert ist
die es komplizierter macht.

Ein Vorteil könnte es aber sein wenn man eine Zentrale DB für die Werte
von mehreren Eisgraph instanzen haben könnte. Es gibt doch eh schon dies
Export Feature bei dem ein Eisgraph die Werte eines anderen Hosts
anzeigen können soll. Ich wollte das immer mal ausprobieren aber mit
Zentraler DB stelle ich mir das einfacher vor. Für n+1 Hosts mit eisgraph.

Gnuplot kenne ich so nicht. Wird das nicht in smokeping und für die
charts vom smartmon auch verwendet? Bei smokeping gibt es da wohl noch
die Möglichkeit Zeiträume raus zu picken und zu zoomen.

Post by Thomas Quast
- Wie bisher, jedoch Zeitraum auf 2 / 5 / 10 Jahre vergroessert

Also ich hab bisher eher keinen Eisfair der 10 Jahre lief. Eher das
Problem die gesammelten Daten vom Alten auf den neuen zu übertragen. Ein
Export/Import weg wäre da auch nett.

Post by Thomas Quast
- Zusaetzliche Moeglichkeit der Datenspeicherung in einer SQL-DB (MariaDB)

Wenn sie Zusätzlich und optional bliebe, okay.

Post by Thomas Quast
- Grafische Darstellung alternativ mit gnuplot

Mir gefällt der Look der Graphen jetzt. Geht denn das auch damit?

Post by Thomas Quast
Erst ab dann, also ab Version 1.7.0, wuerde ich damit beginnen, o.g. Punkte
umzusetzen und offiziell einzufuehren (sofern ausreichend Interesse besteht).

Gibt es schon einen Zeitrahmen, so ungefähr?

Post by Thomas Quast
Ueber reichliche Antworten wuerde ich mich freuen.
Fuer weitere Anregungen bin aber ebenfalls offen.

S.o. Hoffe es ist Hilfreich.

Kay

[Marcus Röckrath]

Hallo Kay,

Post by Kay Martinen

Post by Thomas Quast
Mir schwebt nun vor, die gesammelten Werte von nun an, in eine SQL-DB
zu schreiben. Es ist ohne weiteres moeglich, die Werte von dort in eine
RRD zu ueberfuehren, ohne den Originalzustand zu veraendern.

Umgekehrt nicht?

Post by Thomas Quast
Damit koennen die Grafiken, wenn gewuenscht, wie gewohnt aus rrdtool
heraus generiert werden.

Ich verstehe das mal so das länger als ein Jahr mit rrdtool nicht geht
weil nicht mehr genug datenpunkte gespeichert sind, die Auflösung also
mist wäre oder?

Bitte mal Google bemühen und das Konzept von rrd-Datenbanken eruieren.

Eine rrd-Datenbank (RoundRobin) wird schon beim Anlegen auf eine feste Menge
von Datensätzen festgelegt. Bei Eintragung von neuen Werten, fliegt dann
der älteste Datenwert raus.

Welchen Zeitraum diese x-Werte abbilden, ist dabei nicht gesagt, denn das
hängt ja davon ab,, wie oft Daten eingetragen werden (Frequenz).

Es ist also jeder beliebige Zeitraum abbildbar, nur muss das beim Anlegen
der DB festgelegt werden.

Die Auflösung hängt natürlich von den Zeitabständen ab, in denen Daten in
die Datenbank eingetragen werden.

Eine SQL-DB wie mysql/mariadb wächst schlicht immer weiter.

Post by Kay Martinen
Vom alleinigen Einsatz einer DB für eisgraph bin ich nicht begeistert.
Die jetzige Lösung gefällt mir vor allem weil keine DB involviert ist
die es komplizierter macht.

Es ist eine DB involviert nämlich rrd.

Post by Kay Martinen
Ein Vorteil könnte es aber sein wenn man eine Zentrale DB für die Werte
von mehreren Eisgraph instanzen haben könnte. Es gibt doch eh schon dies
Export Feature bei dem ein Eisgraph die Werte eines anderen Hosts
anzeigen können soll.

Es werden nicht die Werte von anderen Servern übertragen sondern die
fertigen Grafiken/Webseiten.

Post by Kay Martinen
Gnuplot kenne ich so nicht. Wird das nicht in smokeping und für die
charts vom smartmon auch verwendet? Bei smokeping gibt es da wohl noch
die Möglichkeit Zeiträume raus zu picken und zu zoomen.

gnuplot ist ein reines Konsolen-Zeichenprogramm, dem man eine Reihe von
Daten zur Visualisierung "vor die Füße schmeißt".

rrd enthält ein eigenes Modul, um aus den Daten der rrd-DB den Graphen zu
erzeugen; ob gnuplot rrd-Datenbanken als Input auch verarbeiten könnte,
müsste ich auch erst nachlesen.

[Thomas Quast]

Post by Marcus Röckrath
ob gnuplot rrd-Datenbanken als Input auch verarbeiten könnte,
müsste ich auch erst nachlesen.

Nein, das kann gnuplot nicht.

Du hast die Werte aus einer rrd in der Form

<!-- 2020-05-10 11:51:00 CEST / 1589104260 --> <row><v>2.3200000000e+01</v></row>

vorliegen. Da muesste man erst den Timestamp und den Value extrahieren.

Speichert man je Minute fuer ein Jahr immer einen Datenpunkt waere die rrd
zwar 'nur' 12,6 MByte, die xml daraus aber ca. 112,2 MByte mit ca.
1,6 Millionen Zeilen. Mit Erstellund der xml und anschliessender Auswertung
(am schnellsten wuerde hier wohl awk arbeiten), kaemen aber trotzdem noch
einige Sekunden zusammen. Und dann hat man nur EINE Grafik.

Gruss,
Thomas

[Rolf Bensch]

Hallo Thomas,

angeregt durch dieses Posting habe ich auf meinem neuen E64 Eisgraph
installiert. Dabei fallen mit 3 Dinge auf:

- netstat wird noch benötigt obwohl es auf Packeis nur noch über
net-tools-deprecated verfügbar ist.

- Section = Mail wird zur Auswahl angeboten, erscheint aber nicht auf
der Website

- Eisgraph kommt offensichtlich noch nicht mit vort. Devices Festplatten
klar obwohl sie als Target angeboten werden:

Checking configuration file ...

check targets ...
create scripts ...
/usr/local/eisgraph/eisgraph.sh: line 74:
/usr/local/eisgraph/eisgraph.target: No such file or directory
create graphics ...
creating webpages section style ...
cat: /var/eisgraph/img/picres_vda1: No such file or directory
cat: /var/eisgraph/img/picres_vda1: No such file or directory
...

Post by Thomas Quast
Hallo,
bevor ich mir die Arbeit mache und Features in eisgraph einbaue, moechte
ich hier vorher eine Umfrage machen, ob es sich ueberhaupt lohnt.
Um was geht es?
Derzeit werden gesammelte Werte in eine RRD geschrieben. Erweiterung des
Zeitraums ueber 1 Jahr hinaus ist ohne weiteres nicht moeglich, da die
Werte, stehen sie einmal in einer RRD nicht erneut zur Verarbeitung zur
Verfuegung stehen.
Mir schwebt nun vor, die gesammelten Werte von nun an, in eine SQL-DB
zu schreiben. Es ist ohne weiteres moeglich, die Werte von dort in eine
RRD zu ueberfuehren, ohne den Originalzustand zu veraendern.

Datenspeicherung in einer SQL-DB ist grundsätzlich eine gute Idee. Der
einfacheren Pflege wegen würde ich hier aber auch SQLite ins Auge fassen.

Verstehe ich das richtig? Du möchtest Werte speichern um dann RRDs
on-the-fly zu erzeugen? Das finde ich gut.

Post by Thomas Quast
Damit koennen die Grafiken, wenn gewuenscht, wie gewohnt aus rrdtool heraus
generiert werden.
Alternativ schwebt mir noch vor, die Grafiken, wenn auf rrdtool verzichtet
wird, mit gnuplot darzustellen. Hierbei werden die Daten auf jeden Fall in
einer SQL-DB gespeichert.
- Wie bisher, jedoch Zeitraum auf 2 / 5 / 10 Jahre vergroessert

Ob ich Graphe älter als 1 Jahr benötige, das sei mal dahingestellt.
Interessant für Diagnosen wäre für mich eine höhere Auflösung als 3h.
Insofern möchte ich mich dem Wunsch nach "individuellen Zeiträumen"
abschließen. Wenn es darum geht Graphen per cgi beim Zugriff auf einen
Zeitraum zu erstellen, das sollte nicht schwierig in der Umsetzung sein.
Ich könnte unterstützen.

Grüße Rolf

[Thomas Quast]

Hallo Rolf,

Post by Rolf Bensch
angeregt durch dieses Posting habe ich auf meinem neuen E64 Eisgraph
- netstat wird noch benötigt obwohl es auf Packeis nur noch über
net-tools-deprecated verfügbar ist.

Mift. Hatte ich ausgetauscht, ist aber trotzdem wieder reingerutscht.
Werde es wieder austauschen. Kommt mit der naechsten Version.

Post by Rolf Bensch
- Section = Mail wird zur Auswahl angeboten, erscheint aber nicht auf
der Website

In "Edit Sections" rein -> raus, dann in "Edit configuration" rein -> raus.

Zeige mir bitte mal

cat /usr/local/eisgraph/section.list
cat /usr/local/eisgraph/section_target.list

Post by Rolf Bensch
- Eisgraph kommt offensichtlich noch nicht mit vort. Devices Festplatten

Da habe ich mir wohl mehr zerschossen.

Gib mir bitte mal die Ausgabe von

df -k
lsblk

Post by Rolf Bensch

Post by Thomas Quast
Mir schwebt nun vor, die gesammelten Werte von nun an, in eine SQL-DB
zu schreiben. Es ist ohne weiteres moeglich, die Werte von dort in eine
RRD zu ueberfuehren, ohne den Originalzustand zu veraendern.

Datenspeicherung in einer SQL-DB ist grundsätzlich eine gute Idee. Der
einfacheren Pflege wegen würde ich hier aber auch SQLite ins Auge fassen.

Ich setze hier MySQL fuer viele Situationen ein und hatte wegen der Pflege
noch keine Probleme und schwer war es auch nicht, von daher lag es fuer mich
nahe, dies auch zu verwenden. Aber ich muss auch gestehen, das ich mir
SQLite bis dato noch nicht angesehen habe. Hole ich nach.

Post by Rolf Bensch
Verstehe ich das richtig? Du möchtest Werte speichern um dann RRDs
on-the-fly zu erzeugen? Das finde ich gut.

Unter anderem. Vor allem bleibt dann, bei einem 'Collect Interval'
von einer Minute, die Aufloesung erhalten, auch wenn man einen Ausschnitt
von vor sechs Mnaten mit einem Zeitraum von 6 Stunden weahlt. :)

Post by Rolf Bensch

Post by Thomas Quast
- Wie bisher, jedoch Zeitraum auf 2 / 5 / 10 Jahre vergroessert

Ob ich Graphe älter als 1 Jahr benötige, das sei mal dahingestellt.
Interessant für Diagnosen wäre für mich eine höhere Auflösung als 3h.

Koenntest Du dies bitte etwas genauer ausfuehren. Derzeit wird die
Default Graphic mit 180 Punkten gezeichnet, entsprechend 180 Werte, also
3 Stunden. Moechtest Du den Graph mit einer Breite von einer Stunde?
Dann waeren dies derzeit drei Punkte pro eingetragenem Wert.

Fuer eine hoehere Aufloesung muesste man den Intervall aendern, in dem
gesammelte Daten der RRD zugefuehrt werden. Auch muesste dies bei der
Erstellung der RRD beruecksichtigt werden.

Bis jetzt ist eisgraph auf den kleinsten Intervall zum sammeln von
60 Sekunden / 1 Minute begrenzt, wegen cron. Via cron werden die Scripts
zum sammeln angestossen und die kleinste Zeiteinheit, die cron kennt,
ist eine Minute.

Man koennte zu jeder vollen Minute das Script starten, Daten sammeln und
30 Sekunden warten (oder auch 15). Damit haette man dann die Aufloesung
verdoppelt, bzw. vervierfacht. Ist der Rechner aber zu sehr ausgelastet,
kann es passieren, das sich die Scripts in die Quere kommen, bzw. sich
ueberschneiden.

Von rrdtool aus gesehen, ist der kleinste Intervall eine Sekunde. Das
waeren dann 86.400 Eintraege, gegenueber 1.440 fuer jede Minute.
Die RRD wurden dementsprechend enorm anwachsen. Vor allem dann, wenn Du
diese Aufloesung dann auch ueber einen groesseren Zeitraum (z.B. 1 Monat,
oder 1 Jahr) haben moechtest.

Machbar ist vieles. Aber vielleicht verraetst Du mir den Grund fuer Deinen
Wunsch nach einer hoeheren Aufloesung, als eine Minute. Eventuell verstehe
ich Deinen Wunsch ja dann.

Post by Rolf Bensch
Insofern möchte ich mich dem Wunsch nach "individuellen Zeiträumen"
abschließen. Wenn es darum geht Graphen per cgi beim Zugriff auf einen
Zeitraum zu erstellen, das sollte nicht schwierig in der Umsetzung sein.
Ich könnte unterstützen.

Das Angebot nehme ich gerne an und komme dann auf Dich zu. Vielen Dank.

Gruss,
Thomas

[Rolf Bensch]

Post by Thomas Quast
Hallo Rolf,

Post by Rolf Bensch
angeregt durch dieses Posting habe ich auf meinem neuen E64 Eisgraph
- netstat wird noch benötigt obwohl es auf Packeis nur noch über
net-tools-deprecated verfügbar ist.

Mift. Hatte ich ausgetauscht, ist aber trotzdem wieder reingerutscht.
Werde es wieder austauschen. Kommt mit der naechsten Version.

Post by Rolf Bensch
- Section = Mail wird zur Auswahl angeboten, erscheint aber nicht auf
der Website

In "Edit Sections" rein -> raus, dann in "Edit configuration" rein -> raus.

Diesen Menüpunkt hatte ich bis jetzt vollständig übersehen.

Post by Thomas Quast
Zeige mir bitte mal
cat /usr/local/eisgraph/section.list

vor "Edit Sections"
eis64-2 (/) # cat /usr/local/eisgraph/section.list
System
Disk
Network

danach:
eis64-2 (/) # cat /usr/local/eisgraph/section.list
System
Disk
Network
Mail

"Mail" war in "Edit Section" bereits als "Name" vorhanden und ist nach
erneuter Speicherung auch in der Website sichtbar. Es bleibt aber eine
Fehlermeldung:

Checking configuration file ...

check targets ...
create scripts ...
/usr/local/eisgraph/eisgraph.sh: line 74:
/usr/local/eisgraph/eisgraph.target: No such file or directory
create graphics ...
...

Post by Thomas Quast
cat /usr/local/eisgraph/section_target.list

eis64-2 (/) # cat /usr/local/eisgraph/section_target.list
Disk|vda1
Disk|sda3
Mail|exim-frozen
Mail|exim
System|mem
System|cpu0
System|cpu1
System|load
Network|enx525400769e29

Post by Thomas Quast

Post by Rolf Bensch
- Eisgraph kommt offensichtlich noch nicht mit vort. Devices Festplatten

Da habe ich mir wohl mehr zerschossen.
Gib mir bitte mal die Ausgabe von
df -k
lsblk

eis64-2 (/) # df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 25312264 13087704 10909036 55% /
tmpfs 2026344 348 2025996 1% /run
devtmpfs 2020532 0 2020532 0% /dev
/dev/sda1 91099 27879 56339 34% /boot
tmpfs 2026344 0 2026344 0% /run/shm
/dev/vda1 3782691148 1658861468 1931609368 47% /home
tmpfs 2048 352 1696 18% /brute_force_blocking

eis64-2 (/) # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 25G 0 disk
├─sda1 8:1 0 96M 0 part /boot
├─sda2 8:2 0 128M 0 part [SWAP]
└─sda3 8:3 0 24.8G 0 part /
sr0 11:0 1 355M 0 rom
vda 253:0 0 3.6T 0 disk
└─vda1 253:1 0 3.6T 0 part /home

Grüße Rolf

[Thomas Quast]

Hallo Rolf,

Post by Rolf Bensch

Post by Thomas Quast

Post by Rolf Bensch
- Section = Mail wird zur Auswahl angeboten, erscheint aber nicht auf
der Website

In "Edit Sections" rein -> raus, dann in "Edit configuration" rein ->

raus.
Diesen Menüpunkt hatte ich bis jetzt vollständig übersehen.

Kann vorkommen.

Post by Rolf Bensch

Post by Thomas Quast
Zeige mir bitte mal
cat /usr/local/eisgraph/section.list

vor "Edit Sections"
eis64-2 (/) # cat /usr/local/eisgraph/section.list
System
Disk
Network
eis64-2 (/) # cat /usr/local/eisgraph/section.list
System
Disk
Network
Mail
"Mail" war in "Edit Section" bereits als "Name" vorhanden und ist nach
erneuter Speicherung auch in der Website sichtbar.

Lass mich raten:

EISGRAPH_SECTION_N='4'
EISGRAPH_SECTION_5_NAME='Mail'

Post by Rolf Bensch
Checking configuration file ...
check targets ...
create scripts ...
/usr/local/eisgraph/eisgraph.target: No such file or directory
create graphics ...
...

Hm, wuesste jetzt nicht, wo ich da suchen sollte. Welche Version von
eisgraph verwendest Du?

Post by Rolf Bensch

Post by Thomas Quast
cat /usr/local/eisgraph/section_target.list

Post by Rolf Bensch
- Eisgraph kommt offensichtlich noch nicht mit vort. Devices Festplatten

Da habe ich mir wohl mehr zerschossen.

Und wie ich mittlerweile rausgefunden habe, sogar mehr als mir lieb ist. ;-(

Post by Rolf Bensch

Post by Thomas Quast
Gib mir bitte mal die Ausgabe von
df -k
lsblk

eis64-2 (/) # df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 25312264 13087704 10909036 55% /
tmpfs 2026344 348 2025996 1% /run
devtmpfs 2020532 0 2020532 0% /dev
/dev/sda1 91099 27879 56339 34% /boot
tmpfs 2026344 0 2026344 0% /run/shm
/dev/vda1 3782691148 1658861468 1931609368 47% /home
tmpfs 2048 352 1696 18% /brute_force_blocking
eis64-2 (/) # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 25G 0 disk
├─sda1 8:1 0 96M 0 part /boot
├─sda2 8:2 0 128M 0 part [SWAP]
└─sda3 8:3 0 24.8G 0 part /
sr0 11:0 1 355M 0 rom
vda 253:0 0 3.6T 0 disk
└─vda1 253:1 0 3.6T 0 part /home

Wunderbar, danke. Das baue ich gleich ein. Kommt dann mit Version 1.4.5.

Gruss,
Thomas

[Thomas Quast]

Post by Thomas Quast
Wunderbar, danke. Das baue ich gleich ein. Kommt dann mit Version 1.4.5.

eisgraph 1.4.5 stable steht ab sofort zur Installation auf meinem Paketserver
bereit.

in dieser Version wurde auch der Support fuer /dev/xdx (Helmut Pohl) wieder
hinzugefuegt. Den hat es, wie so manches, mit Version 1.4.4 'geloescht'. :-(

Gruss,
Thomas

[Rolf Bensch]

Hallo Thomas,

Post by Thomas Quast
Hallo Rolf,

Post by Rolf Bensch
"Mail" war in "Edit Section" bereits als "Name" vorhanden und ist nach
erneuter Speicherung auch in der Website sichtbar.

EISGRAPH_SECTION_N='4'
EISGRAPH_SECTION_5_NAME='Mail'

Nein, aktuell jedenfalls nicht. Ich kann mir auch nicht vorstellen, dass
das vorher so war. "Mail" war hier immer als Eintrag präsent.

EISGRAPH_SECTION_N='4'
EISGRAPH_SECTION_4_NAME='Mail'

Post by Thomas Quast

Post by Rolf Bensch
Checking configuration file ...
check targets ...
create scripts ...
/usr/local/eisgraph/eisgraph.target: No such file or directory
create graphics ...
...

Hm, wuesste jetzt nicht, wo ich da suchen sollte. Welche Version von
eisgraph verwendest Du?

1.4.4 (weil das gestern veröffentlichte 1.4.5 auf Deinem Paketserver
noch nicht sichtbar ist - auch nicht nach DB-Update)

Post by Thomas Quast

Post by Rolf Bensch

Post by Thomas Quast
cat /usr/local/eisgraph/section_target.list

Post by Rolf Bensch
- Eisgraph kommt offensichtlich noch nicht mit vort. Devices Festplatten

Da habe ich mir wohl mehr zerschossen.

Und wie ich mittlerweile rausgefunden habe, sogar mehr als mir lieb ist. ;-(

Post by Rolf Bensch

Post by Thomas Quast
Gib mir bitte mal die Ausgabe von
df -k
lsblk

eis64-2 (/) # df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 25312264 13087704 10909036 55% /
tmpfs 2026344 348 2025996 1% /run
devtmpfs 2020532 0 2020532 0% /dev
/dev/sda1 91099 27879 56339 34% /boot
tmpfs 2026344 0 2026344 0% /run/shm
/dev/vda1 3782691148 1658861468 1931609368 47% /home
tmpfs 2048 352 1696 18% /brute_force_blocking
eis64-2 (/) # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 25G 0 disk
├─sda1 8:1 0 96M 0 part /boot
├─sda2 8:2 0 128M 0 part [SWAP]
└─sda3 8:3 0 24.8G 0 part /
sr0 11:0 1 355M 0 rom
vda 253:0 0 3.6T 0 disk
└─vda1 253:1 0 3.6T 0 part /home

Wunderbar, danke. Das baue ich gleich ein. Kommt dann mit Version 1.4.5.

Prima. Vielen Dank.

Gruß Rolf

[Thomas Quast]

Hallo Rolf,

Post by Rolf Bensch

Post by Thomas Quast
Hm, wuesste jetzt nicht, wo ich da suchen sollte. Welche Version von
eisgraph verwendest Du?

1.4.4 (weil das gestern veröffentlichte 1.4.5 auf Deinem Paketserver
noch nicht sichtbar ist - auch nicht nach DB-Update)

Ups, sollte auch das Update auf den Produktivserver hochladen, nicht nur auf
meinen Testserver. Sorry. Soeben hochgeladen.

Gruss,
Thomas

[Rolf Bensch]

Post by Thomas Quast
Hallo Rolf,

Post by Rolf Bensch

Post by Thomas Quast
Hm, wuesste jetzt nicht, wo ich da suchen sollte. Welche Version von
eisgraph verwendest Du?

1.4.4 (weil das gestern veröffentlichte 1.4.5 auf Deinem Paketserver
noch nicht sichtbar ist - auch nicht nach DB-Update)

Ups, sollte auch das Update auf den Produktivserver hochladen, nicht nur auf
meinen Testserver. Sorry. Soeben hochgeladen.

1.4.5 ist jetzt installiert. vda wird unterstützt. Keine Fehlermeldung
beim Speichern.

Aus meiner Sicht ist alles wieder in Ordnung.

Vielen Dank

Gruß Rolf

[Thomas Quast]

Hallo Rolf,

Post by Rolf Bensch
1.4.5 ist jetzt installiert. vda wird unterstützt. Keine Fehlermeldung
beim Speichern.
Aus meiner Sicht ist alles wieder in Ordnung.

Super. Vielen Dank fuer die Rueckmeldung.

Gruss,
Thomas

[Rolf Bensch]

Post by Thomas Quast
Hallo Rolf,

Post by Rolf Bensch

Post by Thomas Quast
Mir schwebt nun vor, die gesammelten Werte von nun an, in eine SQL-DB
zu schreiben. Es ist ohne weiteres moeglich, die Werte von dort in eine
RRD zu ueberfuehren, ohne den Originalzustand zu veraendern.

Datenspeicherung in einer SQL-DB ist grundsätzlich eine gute Idee. Der
einfacheren Pflege wegen würde ich hier aber auch SQLite ins Auge fassen.

Ich setze hier MySQL fuer viele Situationen ein und hatte wegen der Pflege
noch keine Probleme und schwer war es auch nicht, von daher lag es fuer mich
nahe, dies auch zu verwenden. Aber ich muss auch gestehen, das ich mir
SQLite bis dato noch nicht angesehen habe. Hole ich nach.

Post by Rolf Bensch
Verstehe ich das richtig? Du möchtest Werte speichern um dann RRDs
on-the-fly zu erzeugen? Das finde ich gut.

Unter anderem. Vor allem bleibt dann, bei einem 'Collect Interval'
von einer Minute, die Aufloesung erhalten, auch wenn man einen Ausschnitt
von vor sechs Mnaten mit einem Zeitraum von 6 Stunden weahlt. :)

Das ist doch etwas sehr, sehr Gutes!!!

Post by Thomas Quast

Post by Rolf Bensch

Post by Thomas Quast
- Wie bisher, jedoch Zeitraum auf 2 / 5 / 10 Jahre vergroessert

Ob ich Graphe älter als 1 Jahr benötige, das sei mal dahingestellt.
Interessant für Diagnosen wäre für mich eine höhere Auflösung als 3h.

Koenntest Du dies bitte etwas genauer ausfuehren. Derzeit wird die
Default Graphic mit 180 Punkten gezeichnet, entsprechend 180 Werte, also
3 Stunden. Moechtest Du den Graph mit einer Breite von einer Stunde?
Dann waeren dies derzeit drei Punkte pro eingetragenem Wert.

Habe mir das nochmal genauer angesehen und festgestellt, dass diese
Bitte ein Schnellschuss von mir war. 3h-Graphen bieten eine Auflösung,
bei der auch "EISGRAPH_COLLECT_INTERVAL = 1" erkennbar bleibt. Somit ist
das auch für mir absolut ausreichend.
Ideal wäre aber tatsächlich dieses 3h-Raster auch auf ältere Zeiträume
anwenden zu können (wie oben beschrieben)

Post by Thomas Quast
Fuer eine hoehere Aufloesung muesste man den Intervall aendern, in dem
gesammelte Daten der RRD zugefuehrt werden. Auch muesste dies bei der
Erstellung der RRD beruecksichtigt werden. >
Bis jetzt ist eisgraph auf den kleinsten Intervall zum sammeln von
60 Sekunden / 1 Minute begrenzt, wegen cron. Via cron werden die Scripts
zum sammeln angestossen und die kleinste Zeiteinheit, die cron kennt,
ist eine Minute.
Man koennte zu jeder vollen Minute das Script starten, Daten sammeln und
30 Sekunden warten (oder auch 15). Damit haette man dann die Aufloesung
verdoppelt, bzw. vervierfacht. Ist der Rechner aber zu sehr ausgelastet,
kann es passieren, das sich die Scripts in die Quere kommen, bzw. sich
ueberschneiden.
Von rrdtool aus gesehen, ist der kleinste Intervall eine Sekunde. Das
waeren dann 86.400 Eintraege, gegenueber 1.440 fuer jede Minute.
Die RRD wurden dementsprechend enorm anwachsen. Vor allem dann, wenn Du
diese Aufloesung dann auch ueber einen groesseren Zeitraum (z.B. 1 Monat,
oder 1 Jahr) haben moechtest.

Intervall < 1 halte ich nicht für zielführend. Ich hoffe damit jetzt
nicht zu viel Verwirrung gestiftet zu haben - sorry.

Post by Thomas Quast
Machbar ist vieles. Aber vielleicht verraetst Du mir den Grund fuer Deinen
Wunsch nach einer hoeheren Aufloesung, als eine Minute. Eventuell verstehe
ich Deinen Wunsch ja dann.

Ich nutze die Graphen überwiegend um Aussagen zu prüfen wie z.B. "die
Performance ist heute mal wieder grottenschlecht". Wenn dann "heute"
verbal mal wenigstens auf einen Zeitraum < 1h reduziert werden kann, und
der load-Graph des Eis unauffällig ist, suche ich auf den Clients und im
Netz, andernfalls auf dem Eis. Wenn man dann über "last week" oder "last
month" regelmäßige Peaks entdeckt, kann man weiteres über die Logfiles
analysieren. Exakt hierfür wünsche ich mir die höhere Auflösung in
zurückliegenden Zeiträumen.

Habe noch einr Frage zur DB-Nutzung: wie würde es sich den darstellen,
wenn zur Laufzeit eine Änderung der Targets erfolgt? Mit fallen da z.B.
ein: mehr RAM, zusätzliche Festplatte, Austausch von Festplatten mit
Vergrößerung der Partitionen, Austausch von Netzwerkarten...

Grüße Rolf

[Thomas Quast]

Hallo Rolf,

Post by Rolf Bensch
Habe mir das nochmal genauer angesehen und festgestellt, dass diese
Bitte ein Schnellschuss von mir war. 3h-Graphen bieten eine Auflösung,
bei der auch "EISGRAPH_COLLECT_INTERVAL = 1" erkennbar bleibt. Somit ist
das auch für mir absolut ausreichend.

Gut.

Post by Rolf Bensch
Ideal wäre aber tatsächlich dieses 3h-Raster auch auf ältere Zeiträume
anwenden zu können (wie oben beschrieben)

Das ist machbar.

Will man aber keine SQL-DB, sondern doch lieber nur RRDs, so erfordert dies
ein neues Design der RRD. Alte Daten koennen dabei nicht uebernommen werden.

Post by Rolf Bensch
Intervall < 1 halte ich nicht für zielführend. Ich hoffe damit jetzt
nicht zu viel Verwirrung gestiftet zu haben - sorry.

Kein Problem.

Post by Rolf Bensch

Post by Thomas Quast
Machbar ist vieles. Aber vielleicht verraetst Du mir den Grund fuer Deinen
Wunsch nach einer hoeheren Aufloesung, als eine Minute. Eventuell verstehe
ich Deinen Wunsch ja dann.

Ich nutze die Graphen überwiegend um Aussagen zu prüfen wie z.B. "die
Performance ist heute mal wieder grottenschlecht". Wenn dann "heute"
verbal mal wenigstens auf einen Zeitraum < 1h reduziert werden kann, und
der load-Graph des Eis unauffällig ist, suche ich auf den Clients und im
Netz, andernfalls auf dem Eis. Wenn man dann über "last week" oder "last
month" regelmäßige Peaks entdeckt, kann man weiteres über die Logfiles
analysieren. Exakt hierfür wünsche ich mir die höhere Auflösung in
zurückliegenden Zeiträumen.

Klingt nachvollziehbar und ist umsetzbar.

Post by Rolf Bensch
Habe noch einr Frage zur DB-Nutzung: wie würde es sich den darstellen,
wenn zur Laufzeit eine Änderung der Targets erfolgt? Mit fallen da z.B.
ein: mehr RAM, zusätzliche Festplatte, Austausch von Festplatten mit
Vergrößerung der Partitionen, Austausch von Netzwerkarten...

Zu jedem 'Target' wird eine 'Table' mit den Daten erstellt. Vergroesserst
Du (z.B) Dein RAM von 16 GByte auf 32 GByte, so macht sich das natuerlich
auch in den Garfiken bemerkbar. Genauso wie auch in den Grafiken bei
rrdtool.

Grussm
Thomas

[Helmut]

Hallo Thomas,

Post by Thomas Quast
Um was geht es?
Derzeit werden gesammelte Werte in eine RRD geschrieben. Erweiterung des
Zeitraums ueber 1 Jahr hinaus ist ohne weiteres nicht moeglich, da die
Werte, stehen sie einmal in einer RRD nicht erneut zur Verarbeitung zur
Verfuegung stehen.
Mir schwebt nun vor, die gesammelten Werte von nun an, in eine SQL-DB
zu schreiben. Es ist ohne weiteres moeglich, die Werte von dort in eine
RRD zu ueberfuehren, ohne den Originalzustand zu veraendern.

gute Idee

Post by Thomas Quast
Damit koennen die Grafiken, wenn gewuenscht, wie gewohnt aus rrdtool heraus
generiert werden.
Alternativ schwebt mir noch vor, die Grafiken, wenn auf rrdtool verzichtet
wird, mit gnuplot darzustellen. Hierbei werden die Daten auf jeden Fall in
einer SQL-DB gespeichert.
- Wie bisher, jedoch Zeitraum auf 2 / 5 / 10 Jahre vergroessert

gute Idee, alte Daten sollten aber bei recreate Database erhalten
bleiben oder vorher in die sql-Datenbank überführt werden.

Post by Thomas Quast
- Zusaetzliche Moeglichkeit der Datenspeicherung in einer SQL-DB (MariaDB)
- Grafische Darstellung alternativ mit gnuplot

Ich habe mir gerade auf deren Homepage das angeschaut, schicke 2D und 3D
plots. :-)

Post by Thomas Quast
Die derzeitige ToDo-Liste sieht vor, das bis Version 1.6.0 eisgraph von
/usr/local nach /usr/lib umgezogen ist (inkl. aller Module).
Erst ab dann, also ab Version 1.7.0, wuerde ich damit beginnen, o.g. Punkte
umzusetzen und offiziell einzufuehren (sofern ausreichend Interesse besteht).
Ueber reichliche Antworten wuerde ich mich freuen.

Gute Idee.

Post by Thomas Quast
Fuer weitere Anregungen bin aber ebenfalls offen.

Ist es möglich die smartmon-logs mit in die Anzeige aufzunehmen ?
Eventuell auch zu gruppieren, damit es übersichtlicher in der Anzeige wird?

Gruß,
Helmut

[Thomas Quast]

Hallo Helmut,

Post by Helmut

Post by Thomas Quast
- Wie bisher, jedoch Zeitraum auf 2 / 5 / 10 Jahre vergroessert

gute Idee, alte Daten sollten aber bei recreate Database erhalten
bleiben oder vorher in die sql-Datenbank überführt werden.

Bei einem recreate werden, wie der Begriff suggeriert, die RRDs neu erstellt.
Damit gehen auch die gesammelten Werte verloren.

Du koenntest aber fuer Dich eine Sicherung erzeugen und den Inhalt
exportieren:

rrdtool dump filename.rrd > filename.xml

Dann hast Du alles in einer XML-Datei. Anders ist es nicht machbar.

Wenn Du in die XML-Datei hineinsiehst, wirst Du erkennen, das die
Zeitabstaende (weiter unten in der Datei) spaeter immer groesser werden.
Die gesammelten Werte werden zusammengefasst, um nicht unnoetig Platz zu
belegen. In der Regel reicht dies aus.

Damit dies nicht passiert und Du spaeter noch immer Daten aus einer RRD
verlustfrei exportiren kannst, musst Du ALLE Werte speichern und nicht
zusammenfuehren lassen.

Hier mal eine kleine Rechnung:
- Du moechtest einen Wert speichern
- Dein Speicherintervall betraegt 60 Sekunden

60 Werte x 24 Stunden x 366 Tage = 527.040 Eintraege
527.040 Eintraege x 3 (Min, Max, Average) = 1.581.120 Eintrage.
Die RRD ist jetzt 13 MByte (12.649.960 Byte) gross.

Und dabei sammelst Du nur einen Wert.

Gesammelte Werte nachtraeglich zu bearbeiten ist uwar nicht unmoeglich, aber
sorgt dann doch schon Knoten in den Fingern. :)

Post by Helmut

Post by Thomas Quast
- Grafische Darstellung alternativ mit gnuplot

Ich habe mir gerade auf deren Homepage das angeschaut, schicke 2D und 3D
plots. :-)

Was hier so 'schick' ist, sind wohl eher Funktionen. :-)

Gnuplot dient primaer zur grafischen Darstellung von Messdaten und
mathematischen Funktionen (Funktionenplotter).

Post by Helmut
Ist es möglich die smartmon-logs mit in die Anzeige aufzunehmen ?
Eventuell auch zu gruppieren, damit es übersichtlicher in der Anzeige wird?

Wenn ich mich recht erinnere verwendet smartmon gnuplot und erzeugt die
Grafiken ueber ein Script cron-gesteuert.

Seinerzeit wollten Jens Berger und ich das mal in eisgraph einbauen. Daraus
wurde aber dann nichts mehr.

Keine Ahnung, was das fuer ein Aufwand heute darstellt. Wenn ich alles
abgearbeitet habe, schaue ich es mir mal an.

Gruss,
Thomas

[Rene Hanke]

Hallo!

Die technische Umsetzung im Hintergrund ist mir eigentlich egal. Ich
möchte nur um die Beachtung zweier Punkte bitten:

a) Ressourcenschonung

b) Optik

Punkt a) ist mir hier eindeutig wichtiger. Ich bin mit der Performance
auf meinem Atom N230 derzeit sehr zufrieden, andere Pakete mit anderen
Datenbanken fÃŒhren dagegen zu deutlicher Last.

Zu Punkt b) möchte ich ergÀnzen, dass mir die derzeitige Darstellung
sehr gefÀllt. Smartmon nutzt IIRC gnuplot, das sieht bei Weitem nicht
so schön aus.


Lieber Gruß

René

[Thomas Quast]

Hallo René,

Post by Rene Hanke
Punkt a) ist mir hier eindeutig wichtiger. Ich bin mit der Performance
auf meinem Atom N230 derzeit sehr zufrieden, andere Pakete mit anderen
Datenbanken führen dagegen zu deutlicher Last.

Fuer all jene, welche das angedachte nicht wollen, aendert sich auch nichts.

Es muessen auch keine zusaetzlichen Pakete installiert werden.

Das von mir genannte ist lediglich optional. Wer moechte, muss dann aber
nachtraeglich noch Pakete installieren (so ist es angedacht).

eisgraph ist derzeit (ausgepackt) 752 KByte gross und bedient sich (bis
auf rrdtool) ausschliesslich vorhandener 'Bordmittel'. Das wird auch so
bleiben.

Post by Rene Hanke
Zu Punkt b) möchte ich ergänzen, dass mir die derzeitige Darstellung
sehr gefällt. Smartmon nutzt IIRC gnuplot, das sieht bei Weitem nicht
so schön aus.

Dem stimme ich Dir zu. Auch ist die Annaeherung bzgl. dem Design von
gnuplot an rrdtool ein ziemlicher Aufwand. Aber letztendlich ist es
eine Entscheidung jedes Einzelnen. Jeder kann, niemand muss.
Du kannst eisgraph auch noch wie aus den Anfangszeiten verwenden, ohne
Menues, Alle Grafiken untereinander. :-)

Gruss,
Thomas

[Marcus Röckrath]

Hallo Thomas, hallo Rene,

Post by Thomas Quast

Post by Rene Hanke
Zu Punkt b) möchte ich ergänzen, dass mir die derzeitige Darstellung
sehr gefällt. Smartmon nutzt IIRC gnuplot, das sieht bei Weitem nicht
so schön aus.

Dem stimme ich Dir zu. Auch ist die Annaeherung bzgl. dem Design von
gnuplot an rrdtool ein ziemlicher Aufwand.

Genau das; bei gnuplot hat man jedewede Gestaltungsfreiheit, man muss sich
nur mit den ganzen Optionen auseinandersetzen.

Wer smartmon aufhübschen will, darf mir gerne Vorschläge machen.

[Thomas Quast]

Post by Marcus Röckrath

Post by Thomas Quast
Dem stimme ich Dir zu. Auch ist die Annaeherung bzgl. dem Design von
gnuplot an rrdtool ein ziemlicher Aufwand.

Genau das; bei gnuplot hat man jedewede Gestaltungsfreiheit, man muss sich
nur mit den ganzen Optionen auseinandersetzen.
Wer smartmon aufhübschen will, darf mir gerne Vorschläge machen.

Vorschlag: Wie waere es, mit einem 'dunklem Design'? So in etwa wie bei
eisgraph.

Hint: Alle kommen immer mit einer hellen und/oder grellen Oberflaeche daher.
Ein bisschen schwaerzer Text auf (fuer mich) grellweissen Hintergrund. Das
schmerzt jedesmal in den Augen. Deshalb habe ich bei meinem Debian mich auch
fuer Adwaita dunkel unter XFCE entschieden. :)

Gruss,
Thomas

[Marcus Röckrath]

Hallo Thomas,

Post by Thomas Quast

Post by Marcus Röckrath
Wer smartmon aufhübschen will, darf mir gerne Vorschläge machen.

Vorschlag: Wie waere es, mit einem 'dunklem Design'? So in etwa wie bei
eisgraph.

Das mit dem Vorschlag war anders gemeint: Keine grafischen Ideen sondern
fertige Kommandozeilen für gnuplot, ich habe nämlich nicht die Zeit, mich
da einzuarbeiten.

[Kay Martinen]

Post by Marcus Röckrath

Post by Thomas Quast

Post by Marcus Röckrath
Wer smartmon aufhübschen will, darf mir gerne Vorschläge machen.

Ist schon ganz schön so jetzt.

Post by Marcus Röckrath

Post by Thomas Quast
Vorschlag: Wie waere es, mit einem 'dunklem Design'? So in etwa wie bei
eisgraph.

Das mit dem Vorschlag war anders gemeint: Keine grafischen Ideen sondern

Wäre aber auch mein Wunsch. Ich benutze bei Eisgraph auch das Dunkle
Design mit "Bunt auf Schwarz" und das im mini_httpd dessen seitenleiste
eh schon schwarz ist. Nur der rest nicht. Also logviewer, smartmon
u.s.w. Und dafür gibt es keine Farbpresets.

Idee am Rande: Könnte man das unversell lösen in dem man die Farbpresets
vom ECE-Setup übernimmt? Ich setze z.b. beim Fileserver immer blau und
cyan ein. Beim mailserver rot und bei sonstigen (infrastruktur,
monitoring) grau. So verirrt man sich nicht so leicht und das könnte
dann z.b. auch für den mini_httpd und dessen Hintergrund-design gelten.

Post by Marcus Röckrath
fertige Kommandozeilen für gnuplot, ich habe nämlich nicht die Zeit, mich
da einzuarbeiten.

Kann ich leider nicht helfen weil noch weniger als Null Ahnung.


Kay

[Thomas Quast]

Post by Marcus Röckrath

Post by Thomas Quast

Post by Marcus Röckrath
Wer smartmon aufhübschen will, darf mir gerne Vorschläge machen.

Vorschlag: Wie waere es, mit einem 'dunklem Design'? So in etwa wie bei
eisgraph.

Das mit dem Vorschlag war anders gemeint: Keine grafischen Ideen sondern
fertige Kommandozeilen für gnuplot,

Ja, sowas dachte ich mir schon.

Andere Vorschlag:

Vielleicht koenntest Du ja die Bins in ein Paket packen und den Rest dann
als 'App' gesondert anbieten.

Wenn jetzt jemand nur die Bins braucht muss auch noch das gedroesel drumherum
mit installiert werden, inkl. gnuplot.

Sollte doch locker machbar sein.

Post by Marcus Röckrath
ich habe nämlich nicht die Zeit, mich da einzuarbeiten.

Wieso einarbeiten? Du bist doch der Autor:

https://www.pack-eis.de/?p=smartmon

Gruss,
Thomas

[Marcus Röckrath]

Hallo Thomas,

Post by Thomas Quast
Vielleicht koenntest Du ja die Bins in ein Paket packen und den Rest dann
als 'App' gesondert anbieten.

Nein, das Paket bleibt so, wie es ist.

Wer möchte kann ja problemlos auch ein Paket oben draufsatteln und sich
seine grafischen Wünsche erfüllen.

Post by Thomas Quast

Post by Marcus Röckrath
ich habe nämlich nicht die Zeit, mich da einzuarbeiten.

https://www.pack-eis.de/?p=smartmon

Und? Das Paket läuft, habe es so als verwaistes Paket übernommen und so wird
es auch im wesentlichen bleiben.

Aufgabe des Paketes ist zunächst die Überwachung der Platten, um notfalls
gewarnt zu werden.

Das Plotting ist ein Gimmick oben drauf und kann deaktiviert werden, so dass
ein Addon-Paket hier gänzlich andere Wege gehen kann.

Oder du baust smartmon-Graphen in eisgraph ein, basierend auf den vom
smartmon-Paket erhobenen oder selbst ermittelten Daten.

[Thomas Quast]

Post by Marcus Röckrath
Das Plotting ist ein Gimmick oben drauf und kann deaktiviert werden, so dass
ein Addon-Paket hier gänzlich andere Wege gehen kann.

Es mag aus Deiner Sicht ein Gimmick sein, aber es wird pauschal mitinstalliert.

Post by Marcus Röckrath
Oder du baust smartmon-Graphen in eisgraph ein, basierend auf den vom
smartmon-Paket erhobenen oder selbst ermittelten Daten.

Um z.B. aus den erhobenen Daten ein Modul fuer eisgraph zu bauen, muss dann
der User zusaetzlich gnuplot UND mail installieren (und konfigurieren).

Da sehe ich kein 'Easy'[isfair] mehr. Dann gibt es kein Modul fuer eisgraph.

Erledigt.

Gruss,
Thomas

[Marcus Röckrath]

Hallo Thomas,

Post by Thomas Quast

Post by Marcus Röckrath
Das Plotting ist ein Gimmick oben drauf und kann deaktiviert werden, so
dass ein Addon-Paket hier gänzlich andere Wege gehen kann.

Es mag aus Deiner Sicht ein Gimmick sein, aber es wird pauschal mitinstalliert.

So ist das Konzept des Paketes.

Post by Thomas Quast
Um z.B. aus den erhobenen Daten ein Modul fuer eisgraph zu bauen, muss
dann der User zusaetzlich gnuplot UND mail installieren (und
konfigurieren).

1. Irgendein mail-Paket ist unabdingbarfür die Warnfunktion, das hat mit dem
Plotting nichts zu tun.

Post by Thomas Quast
Da sehe ich kein 'Easy'[isfair] mehr. Dann gibt es kein Modul fuer eisgraph.

2. Ob ein reines Binärpaket wie gnuplot mitinstalliert wird, ist kein
Widerspruch zu Easy.

Post by Thomas Quast
Erledigt

Ich habe nicht danach gefragt, somit ist mir das auch ziemlich egal.

[Kay Martinen]

Post by Thomas Quast

Post by Marcus Röckrath
Das Plotting ist ein Gimmick oben drauf und kann deaktiviert werden, so dass
ein Addon-Paket hier gänzlich andere Wege gehen kann.

Es mag aus Deiner Sicht ein Gimmick sein, aber es wird pauschal mitinstalliert.

Ich weiß jetzt nicht ob es von haus aus auch mit aktiviert wird aber es
ist ebenso "nur" eine Visualisierung von erhobenen Meßwerten wie
Eisgraph - nur anders. Quasi die kleinste Variante von Monitoring. Man
kann natürlich auch mit nagios(2png) via snmp auf Server schießen und
sich zentral alarmieren lassen... = noch mehr Brimborium plus separater
VM oder Host aber eben mit log, verlauf, alarmen u.s.w. Ähh, wenn es
noch ein snmp-paket gibt. War da nich was???

Wenn ich smartmon installiere dann immer mit dem aktivierten Plotting.
Damit ich bei Warnungen dort rein schauen kann. Wenn man es dann erst
einschaltet ist es zu spät weil keine Historie da ist. In sofern für
mich mehr als ein Gimmick.

Post by Thomas Quast

Post by Marcus Röckrath
Oder du baust smartmon-Graphen in eisgraph ein, basierend auf den vom
smartmon-Paket erhobenen oder selbst ermittelten Daten.

Um z.B. aus den erhobenen Daten ein Modul fuer eisgraph zu bauen, muss dann
der User zusaetzlich gnuplot UND mail installieren (und konfigurieren).

und mod_hddtemp fragt das hddtemp binary obwohl 'smartctl' auch einen
Temperaturwert liefert. An die komme ich für Eisgraph aber eben NICHT
via smartctl ran, da brauche ich dann immer noch hddtemp. Das AFAIR
letztlich auch nur den Smart-wert 194 ausliest - und nur den.

Wirkt auf mich als müsse man ein anderes Binary nehmen und dann die
"logik" machen um dessen Werte aus zu knobeln zum speichern. Die ja
leider je nach platte verschieden umfangreich sein können. Aber ein
Grundset an Werten wird es m.E. immer geben.

Kann mich nicht erinnern gnuplot konfigurieren zu müssen. Und mail ist
ein eigenes Paket, das muß man immer konfigurieren. Die Freiheit
stattdessen ssmtp oder msmtp nutzen zu können wäre mir da wichtiger. Da
hakte es zuletzt aber - so weit ich erinnere.

Post by Thomas Quast
Da sehe ich kein 'Easy'[isfair] mehr. Dann gibt es kein Modul fuer eisgraph.
Erledigt.

Ach so, das lese ich jetzt erst. Na gut. Wäre nur ne Idee gewesen. Du
hattest ja danach gefragt.


Kay

[Marcus Röckrath]

Hallo Kay,

Post by Kay Martinen
Kann mich nicht erinnern gnuplot konfigurieren zu müssen.

Natürlich nicht, das ist nur ein Binary.

Post by Kay Martinen
Und mail ist
ein eigenes Paket, das muß man immer konfigurieren. Die Freiheit
stattdessen ssmtp oder msmtp nutzen zu können wäre mir da wichtiger. Da
hakte es zuletzt aber - so weit ich erinnere.

smartmontools hat kein require auf ein bestimmtes mail-Paket.

Bei der Konfiguration wird gecheckt, ob der sendmail-Befehl existiert, mehr
nicht; daher reicht irgendein sens-only-mail-Paket.

[Kay Martinen]

Post by Marcus Röckrath

Post by Kay Martinen
stattdessen ssmtp oder msmtp nutzen zu können wäre mir da wichtiger. Da
hakte es zuletzt aber - so weit ich erinnere.

smartmontools hat kein require auf ein bestimmtes mail-Paket.

Mein Praktisches Erleben spricht dagegen aber...

Post by Marcus Röckrath
Bei der Konfiguration wird gecheckt, ob der sendmail-Befehl existiert, mehr
nicht; daher reicht irgendein sens-only-mail-Paket.

... das kann ein Jahr oder so her sein. Da hatte ich ssmtp installiert
und dann wollte smartmon nicht installieren weil es meinte es wäre kein
mail-paket da. In der Situation muß ich dann entweder auf smartmon
verzichten (ungern auf physischer HW) oder mit einem kompletten
mail-paket leben das ich zu der Zeit erst mal *komplett* konfigurieren
müßte. Auch nicht schön wenn ssmtp gereicht hätte um den internen
mailserver zu erreichen. IMHO hat 'mail' jetzt mehr Schalter so das es
leichter als send-only laufen könnte. Früher nicht.


Kay

[Marcus Röckrath]

Hallo Kay,

Post by Kay Martinen

Post by Marcus Röckrath
smartmontools hat kein require auf ein bestimmtes mail-Paket.

Mein Praktisches Erleben spricht dagegen aber...

Post by Marcus Röckrath
Bei der Konfiguration wird gecheckt, ob der sendmail-Befehl existiert,
mehr nicht; daher reicht irgendein sens-only-mail-Paket.

... das kann ein Jahr oder so her sein. Da hatte ich ssmtp installiert
und dann wollte smartmon nicht installieren weil es meinte es wäre kein
mail-paket da.

Der Check auf sendmail ist in der aktuellen Form im Oktober 2017 eingeführt
worden.

Falls es da noch Probleme geben sollte, brauche ich konkrete
Fehlermeldungen.

[Alexander Dahl]

Hallo Thomas,

Post by Thomas Quast
Derzeit werden gesammelte Werte in eine RRD geschrieben. Erweiterung des
Zeitraums ueber 1 Jahr hinaus ist ohne weiteres nicht moeglich, da die
Werte, stehen sie einmal in einer RRD nicht erneut zur Verarbeitung zur
Verfuegung stehen.

Ein ähnliches Problem haben quasi alle Dienste, die ihren Kram in
RRDtool ablegen, bei munin und collectd sieht das ähnlich aus. Kenne so
einige Leute, die sich da drüber schon geärgert haben.

Post by Thomas Quast
Mir schwebt nun vor, die gesammelten Werte von nun an, in eine SQL-DB
zu schreiben. Es ist ohne weiteres moeglich, die Werte von dort in eine
RRD zu ueberfuehren, ohne den Originalzustand zu veraendern.

Ich habe nicht viel Ahnung von Datenbanken, aber soweit ich weiß gibt es
speziell für solche Monitoring-Daten gut geeignete Datenbanken,
sogenannte "Time series database" [1]. Moderne monitoring systeme
benutzen da bspw. InfluxDB oder Graphite, Prometheus bringt glaube ich
seine eigene TSDB mit? Ggf. wäre sowas besser geeignet als SQL?

Post by Thomas Quast
Alternativ schwebt mir noch vor, die Grafiken, wenn auf rrdtool verzichtet
wird, mit gnuplot darzustellen. Hierbei werden die Daten auf jeden Fall in
einer SQL-DB gespeichert.

Man sieht ja heutzutage sehr oft Grafana um Daten aus diversen
Monitoring-Quellen darzustellen.

Post by Thomas Quast
Fuer weitere Anregungen bin aber ebenfalls offen.

Hoffe die Anregungen werfen Dich nicht aus der Bahn, aber wenn Du mal
links und rechts schauen willst, vielleicht interessant.

Grüße
Alex

[1] https://en.wikipedia.org/wiki/Time_series_database

[Marcus Röckrath]

Hallo Alexander,

Post by Alexander Dahl

Post by Thomas Quast
Derzeit werden gesammelte Werte in eine RRD geschrieben. Erweiterung des
Zeitraums ueber 1 Jahr hinaus ist ohne weiteres nicht moeglich, da die
Werte, stehen sie einmal in einer RRD nicht erneut zur Verarbeitung zur
Verfuegung stehen.

Ein ähnliches Problem haben quasi alle Dienste, die ihren Kram in
RRDtool ablegen, bei munin und collectd sieht das ähnlich aus. Kenne so
einige Leute, die sich da drüber schon geärgert haben.

Wer sich darüber ärgert, hat sich vorher nicht über die Arbeitsweise von
rrdtool informiert.

Wie rrdtool arbeitet ist klar dokumentiert und wenn das für das eigene
Projekt nicht passt, muss man halt etwas anderes nehmen.

[Thomas Quast]

Hallo Alex,

Post by Alexander Dahl

Post by Thomas Quast
Derzeit werden gesammelte Werte in eine RRD geschrieben. Erweiterung des
Zeitraums ueber 1 Jahr hinaus ist ohne weiteres nicht moeglich, da die
Werte, stehen sie einmal in einer RRD nicht erneut zur Verarbeitung zur
Verfuegung stehen.

Ein ähnliches Problem haben quasi alle Dienste, die ihren Kram in
RRDtool ablegen, bei munin und collectd sieht das ähnlich aus. Kenne so
einige Leute, die sich da drüber schon geärgert haben.

Das war fuer mich der Grund, das Aergernis anzugehen und nach einer Loesung
zu suchen.

Post by Alexander Dahl

Post by Thomas Quast
Mir schwebt nun vor, die gesammelten Werte von nun an, in eine SQL-DB
zu schreiben. Es ist ohne weiteres moeglich, die Werte von dort in eine
RRD zu ueberfuehren, ohne den Originalzustand zu veraendern.

Ich habe nicht viel Ahnung von Datenbanken, aber soweit ich weiß gibt es
speziell für solche Monitoring-Daten gut geeignete Datenbanken,
sogenannte "Time series database" [1]. Moderne monitoring systeme
benutzen da bspw. InfluxDB oder Graphite, Prometheus bringt glaube ich
seine eigene TSDB mit? Ggf. wäre sowas besser geeignet als SQL?

Eine allzu grosse Auswahl habe ich nicht, da mir libdbi Grenzen setzt.
Solange ich mit einer der Driver (freetds, mysql, pqsql oder sqlite3) auf
einer Datenbank zugreifen kann, geht es.

Post by Alexander Dahl

Post by Thomas Quast
Alternativ schwebt mir noch vor, die Grafiken, wenn auf rrdtool verzichtet
wird, mit gnuplot darzustellen. Hierbei werden die Daten auf jeden Fall in
einer SQL-DB gespeichert.

Man sieht ja heutzutage sehr oft Grafana um Daten aus diversen
Monitoring-Quellen darzustellen.

Grafana sieht auch nicht schlecht aus, aber ist fuer meinen Geschmack etwas
zu schwerfaellig, genau wie Nagios, Zabbix, Cacti, Zenoss, Ganglia, Observium
und all die anderen. Darum habe ich selber etwas geschrieben, was eben im
Grundgeruest mit den Bordmitteln auskommt ... und eben rrdtool.

Post by Alexander Dahl

Post by Thomas Quast
Fuer weitere Anregungen bin aber ebenfalls offen.

Hoffe die Anregungen werfen Dich nicht aus der Bahn, aber wenn Du mal
links und rechts schauen willst, vielleicht interessant.

Noe, mach Dir da mal keine Sorgen, das mich da etwas aus der Bahn wirft.
Mein Blick geht bei sowas immer nach links und recht und auch ueber den
Tellerrand hinaus. Will mir doch alles offenhalten und weiterkommen, getreu
dem Motto: Stillstand ist Rueckschritt. ,-)

Post by Alexander Dahl
***** http://blog.antiblau.de/ *****************************

Netter Blog, gefaellt mir.

Gruss,
Thomas

[Alexander Dahl]

Moin,

Post by Thomas Quast

Post by Alexander Dahl
***** http://blog.antiblau.de/ *****************************

Netter Blog, gefaellt mir.

Danke. :-)

Ich kipp da hauptsächlich Dinge ab, die ich selbst später vermutlich
nochmal nachlesen will. Hat mich schon mehrfach gerettet, insbesondere
bei den ganzen obskuren Geschichten, wo man ewig recherchiert und
probiert. ;-)

Grüße
Alex