MRTG-Alternative? (Daten sammeln + anzeigen mit rrdtool und collectd)

[Eagle3386]

Nabend zusammen,

ich bin 'n kleiner Statistik-Fanatiker (Hauptsache, alles schön grafisch dargestellt.. ) und daher würde ich gern sowas wie MRTG auf meine 7170 packen wollen.. - upnp2mrtg ist ja eher als Abfrage-Tool gedacht und ich würd's gern live von der Box im Web-GUI (oder im DS-Mod-GUI) angezeigt bekommen wollen..
Infos über Traffic (täglichen & monatlichen gibts ja, nur keinen "Alltime-Traffic") und Ähnliches sollten natürlich auch nicht fehlen..

Falls irgendwer dazu Vorschläge hat - nur zu, ich bin neugierig, was meine Fritzbox noch so hergibt..


Beste Grüße,
Martin..

 

[Eagle3386]

*schieb*

Hat wirklich niemand 'ne Idee?

 

[HolyPetrus]

bei mir läuft die abfrage vom homeserver aus, aber es ist sicher keine lösung einfach einen webserver nur dafür aufzusetzen. mrtg zB direkt auf der fritzbox laufen zu lassen ist vielleicht auch nicht so einfach, weil es viel CPU braucht, da in phyton geschrieben (+ natürlich auch den interpreter). außerdem müsste das dsmod-webinterface angepasst werden oder httpd verwendet werden (noch mehr drin im image).

 

[Eagle3386]

Deshalb ja meine Frage, ob es 'ne Alternative dazu gäbe, um eben diesen "Hunger" von MRTG zu umgehen..

 

[Trick]

Ich bin momentan noch im stealth-mode, aber bin schon daran, RRDTool inkl. collectd zu kompilieren. Ich find's besser als MRTG und viel flexibler. Fuer mipsel funktioniert's grundsaetzlich, aber mit unserer tool-chain klagt's schon beim ./configure ueber nicht IEEE-konforme floating-point Instruktionen.

In zwei oder drei Wochenenden sollte ich weiter sein und 'ne bessere Idee haben; schliesslich laueft die Sache auf dem WRT54GS tadellos (auch mipsel, aber kein ar7). Die 7170 mit smbfs oder Memorystick waere ein Superkandidat, auch wenn das Fehlen von (stabilen) iptables die Netzwerkmessungen etwas eingeschraenkt.

Ich tauch im Juli wieder auf.

Trick

 

[olistudent]

@Trick
Schon mal mit "rd_cv_ieee_works=yes" beim configure-Aufruf probiert?

MfG Oliver

 

[Trick]

@olistudent
So prompt, wie deine Antworten kommen, hab ich schon bald ein schlechtes Gewissen, nicht die ganze Nacht durchzuarbeiten ;-)

Dein Hinweis traf ins Schwarze und die Sache läuft durch. Meine Frage jetzt: Wie haltet Ihr's mit den libs? Dass ich zlib nicht statisch einkompilieren sollte, dünkt mich naheliegend. Aber was ist Eure Praxis bei den spezifischen libs (libpng, etc.)? Statisch ins Paket oder ins lib-Verzeichnis?

thx

Trick

 

[olistudent]

Ins Lib-Verzeichnis.

MfG Oliver

 

[Eagle3386]

Hey, Trick,

wie schauts aus mit deiner "RRDTool inkl. collectd"-Idee? Gibts da schon was Konkretes, dass ich mal ausprobieren könnte?

 

[Trick]

Wenn ich die make Files für ds-mod auf 15/15.1 angepasst habe, werde ich die diffs mal posten. Dank Oliviers Tipps bin ich gutes Stück vorwärts gekommen, aber die lib freetype-2.1.10 stösst schon beim ./configure auf Probleme mit zlib. Ist natürlich ne tolle Aussage vom mir, so ganz ohne Quote der Fehlermeldungen. Bref, ich nehm deinen Hinweis als Motivationspritze, mich um die neuen Files zu kümmern.

Gruss

Trick

 

[Eagle3386]

Das klingt super!
Bin echt gespannt und freu mich auf weitere Meldungen von dir!

 

[Trick]

Erwarte keine Wunder, aber ich dokumentiere mal den Stand der Dinge. Nach den ersten Tests mit getrennter Compilation ist jetzt die Sache (d.h. RRDTool als App und die libs) im menuconfig drin und bereitet, wie besagt, ein paar Problemchen:

make[1]: Entering directory `.../ds26-15.1/source/libpng-1.2.10'
make[1]: *** No rule to make target `install-headers'.  Stop.
make[1]: Leaving directory `.../ds26-15.1/source/libpng-1.2.10'
make: *** [.../ds26-15.1/toolchain/build/gcc-4.2.0-uClibc-0.9.28/mipsel-linux-uclibc/usr/lib/liblibpng.so.] Error 2

und bei libart

/bin/sh: ./gen_art_config: cannot execute binary file
make[1]: *** [art_config.h] Error 126
make[1]: Leaving directory `.../ds26-15.1/source/libart_lgpl-2.3.17'
make: *** [source/libart_lgpl-2.3.17/.libs/liblibart.so.] Error 2

Klingt nicht so arg, aber ich hatte keine Zeit, den genauen Aufbau der Umgebung zu verinnerlichen. Jetzt, wo ich wieder ein bisschen Zeit habe, kann ich mich der Sache annehmen und im Forum suchen; werd' ja nicht der erste sein.

Gruss

Trick

PS: Falls jemand den Masochismus hat, selbst zu basteln, möchte ich dem abwegigen Vergnügen nicht im Wege stehen und attache meine Beihilfe zum Leiden. Ich habe das Originalverzeichnis 'make' nach 'make_original' kopiert, alle Schandtaten im 'make' begangen und dann auf Stufe dieser Dirs gedifft (diff -uNr).

 

[Eagle3386]

Leider bin ich kein make-Guru, weshalb ich damit nicht sooo viel anfangen kann..

Dennoch werde ich gespannt deinen Fortschritt beobachten und ich würde mich sehr freuen, bald weitere erfolgreiche Meldungen von dir zu lesen..

 

[Trick]

Nach Korrektur vieler "Tippfehler" sieht es schon besser aus. Einzig die libart hat es in sich, oder ist schlicht englisch "difficult":

difficult one: if the tasks must run on the target. For example, a binary to probe the target machine architecture in order to generate a header file (ntl_5.4.1.bb). Then you have to perform these tasks in the target machine and feed the generated files to oe (e.g. see gnome/libart-lgpl). Another possibility is to use qemu-native.

Mal sehen, ob die Binaries von Debian oder OpenWRT was taugen.

 

[derheimi]

Hilft das eventuell? Musst Du noch in make/libs/Config.in aufnehmen.

 

[Trick]

Cool! Das hat hingehauen Die libs compilieren alle sauber durch. Als Make-Phobiker stellt sich die Frage, wie ich rrdtool Make.am patchen oder wie ich die Miraden von Flags setzen muss, damit die lieben Kinderchen von rrdtool auch beachtet werden.

Findr 3rd-Party Libraries
checking for art_vpath_add_point in -lart_lgpl_2... yes
checking libart_lgpl/libart.h usability... no
checking libart_lgpl/libart.h presence... no
checking for libart_lgpl/libart.h... no
checking for pkg-config... no
configure: WARNING:
----------------------------------------------------------------------------
* I could not find a working copy of libart-2.0. Check config.log for hints on why this is the case. Maybe you need to set LDFLAGS and CPPFLAGS appropriately so that compiler and the linker can find libart_lgpl_2 and its header files. If you have not installed libart-2.0, you can get it either from its original home on

       LIBS=-lm
   LDFLAGS=-L/data/FbF/ds26-15.1/toolchain/target/bin/../usr/lib
  CPPFLAGS=-I/data/FbF/ds26-15.1/toolchain/target/bin/../usr/include -I/usr/include/libart-2.0

Weiss wer, ob ein Thread existiert, der schonend das Grundverständnis vermittelt?

Thx

Trick

 

[olistudent]

Wenn es bis dahin noch nicht gelöst ist, dann schau ich mir das irgendwann im Laufe des Wochenendes an.

MfG Oliver

edit: Vielleicht hilft dir das hier weiter. Wobei $(STAGING_DIR) bei uns $(TARGET_TOOLCHAIN_STAGING_DIR) heißt...

 

[Trick]

Danke für den Tipp. Ich baue mal die Ideen von OpenWRT ein und teste sie, bevor du deine Zeit ver(sch)wenden musst. Gruss Trick

 

[derheimi]

freetype und libart scheinen eine Verzeichnisebene zu tief im target/...../include zu laden. Wenn ich manuell noch einen Include-Pfad angeben, findet er die libart zumindest. Bei Libpng scheint es zu klappen, hab aber grad nur ganz fix getestet...

 

[olistudent]

Wenn ich das hier als Zeitverschwendung sehen würde, dann würdest du mich hier etwas seltener sehen. ;-)

MfG Oliver