Serverstats - Alternative zu cacti, mrtg & Co.

Bash, Shell, PHP, Python, Perl, CGI
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen

Serverstats - Alternative zu cacti, mrtg & Co.

Post by andreask2 »

Hallo!

Ich hatte diesen Thread eröffnet, als ich vor einiger Zeit auf Serverstats (demo) gestoßen war. Damals gab es noch überhaupt keine Dokumentation, keine Beispiel-Konfig und keine Projekt-Infrastrukur (Mailingliste, Forum, Bug-Tracker, SVN...). Das hat sich inzwischen glücklicherweise grundlegend geändert, inzwischen wird Serverstats bei Berlios gehostet (und es gibt sogar ein Gentoo ebuild):

Serverstats Homepage: http://serverstats.berlios.de/

Berlios Projekt-Seite: http://developer.berlios.de/projects/serverstats/

Inzwischen ist dieser Thread mehr oder weniger zu _dem_ "Support-Forum" für Serverstats geworden, in diesem Thread ist die erste Dokumentation im rootiewiki entstanden (bisher übrigens die einzige in deutsch), einige Sourcen die sich inzwischen im "Lieferumfang" von Serverstats befinden etc. Allerdings ist das nicht der Zweck dieses Forums hier, dafür wurde die Projektseite auf Berlios eingerichtet. ddanier und ich haben natürlich auch die serverstats-user Mailingliste abonniert und sind dort bei Fragen gerne behilflich. Trotzdem findet Ihr hier die bisher meisten Informationen rund um Serverstats, wenn Ihr also ein Problem habt, ist es sicher nicht die schlechteste Idee, nochmal hier vorbei zu schauen, ob die Frage evtl. schon beantwortet wurde.

Neulinge sollten als erstes mal einen Blick auf die aktuelle Dokumentation werfen:

INSTALL - beschreibt die notwendigen Schritte für eine minimale Installation. Das Verzeichnis config.sample/ enthält eine simple Konfiguration, die normalerweise ohne jegliche Anpassung direkt funktioniert und Graphen erzeugt (wenn man das Verzeichnis in config/ umbenannt hat, und den update.php cronjob eingerichtet hat).
doc/graph-config.txt - beschreibt, wie man prinzipiell an etwas fortschrittlichere Graphen gelangt, wie z.B. in der Online-Demo.
doc/sources.txt - enthält die hierzu notwendigen speziellen Anweisungen für sämtliche mitgelieferten Sourcen (Datenquellen).
doc/faq.txt - ist im Moment vor allem eine Art "Troubleshooting Guide", das sollte man sich vor allem dann ansehen um herauszufinden, warum ein Graph nicht angezeigt wird.

Hilfreich beim Erstellen eigener Graphen ist vor allem die Beispiel-Config zur Online-Demo. Und natürlich die rrdtool Doku nicht zu vergessen, denn Serverstats ist eigentlich "nur" eine Art Wrapper für rrdtool, die ganzen Parameter/Kommandos sind an das original angelehnt, entsprechend hilfreich ist es die rrdtool Dokus zu lesen, z.B. man rrdgraph für die Erstellung von Graphen...

Wenn man eine eigene Source schreiben will, ist der Rootiewiki Artikel zu Serverstats ganz hilfreich.

Zusätzliche Sourcen findet man auf einer Extra Seite, dort kann man auch eigene Sourcen veröffentlichen: http://serverstats.berlios.de/sources.html

So, das sollte erstmal reichen, wie gesagt, hier im Thread, im rootiewiki und auf den Serverstats Seiten findet Ihr inzwischen schon einiges an Infos, ich hoffe demnächst von Euch auf den Serverstats Mailinglisten zu lesen ;-)


Viele Grüße
Andreas

Und hier das "originale" Ausgangsposting:

====================================================================

Hallo!

Nachdem ich mit mrtg, rrdtool und cacti aus verschiedenen Gründen unzufrieden war, habe ich jetzt glaube ich genau das gefunden, was ich suche: Serverstats - rrdtool harvester (demo).
der Autor wrote:I created this because Cacti was much to overloaded and I disliked that it depends on a database.
Womit er mir 100%ig aus der Seele spricht. Das ganze basiert auf PHP5 und rrdtool.

Leider hat das aber einen Haken - es ist noch so ziemlich gar nicht dokumentiert. Die Konfiguration wird in den PHP-Dateien im Verzeichnis config/ vorgenommen. Allerdings habe ich es bisher nicht geschafft, dass mir das Tool mal eine Grafikdatei ausgespuckt hätte. Kennt das zufällig jemand von Euch, der mir mal seine Konfiguration posten kann?

Ich kann ja mal posten was ich bisher gemacht habe:


- PHP5 und rrdtool ist installiert

- Archiv entpackt, Rechte OK (siehe INSTALL)

- mv config.sample config (Vorlagen für die configs)

- config/sources.php angepasst (für den Anfang nur 2 einfache Anzeigen)

Code: Select all

$config = array();
$config['load']['module'] = new load();
$config['load']['rra'] = 'default';
$config['users']['module'] = new users();
$config['users']['rra'] = 'default';
- der Pfad zum rrdtool in config/main.php stimmt

Wie ich das verstehe, findet der größte Teil der Konfiguration in der config/graph.php statt.
Ich hab in dieser Datei $config['list']['content'] angepasst, und zwar indem ich bei dem ersten Element 'source' auf 'load' gesetzt habe, ich gehe mal davon aus, dass 'load' ein möglicher Wert für 'source' ist, weil ich es in config/sources.php so konfiguriert habe. Alle anderen Elemente von $config['list']['content'] habe ich erstmal auskommentiert. Allerdings funktioniert es nicht, die Grafiken werden nicht erzeugt. Natürlich habe ich update.php (hiermit sollten eigentlich Daten in die rrd geschreiben werden) ausgeführt.

Wenn ich eine Grafik öffnen will (graph.php?graph=0&start=-3600&title=Hour), erhalte ich folgende PHP-Fehlermeldung:

Code: Select all

Warning: readfile(/var/www/serverstats/graph/32f24d3a30fa5f7c3f5d27451358fc7b.png) [function.readfile]: failed to open stream: No such file or directory in /var/www/serverstats/graph.php on line 163

Call Stack
1 {main}() /var/www/serverstats/graph.php:0
2 readfile() /var/www/serverstats/graph.php:163
Wenn ich mir das Shell-Kommando, das graph.php erzeugt in includes/rrdgraph.class.php ausgeben lasse, erhalte ich folgenden Befehl:

Code: Select all

/usr/bin/rrdtool graph '/var/www/serverstats/graph/32f24d3a30fa5f7c3f5d27451358fc7b.png' -t 'Test - Hour' -s '-3600' -a 'PNG' -w '500' -h '150' -l '0' -v 'SampleLabel' -M  'DEF:load_s1=/var/www/serverstats/rrd/load.rrd:s1:AVERAGE' 'LINE2:load_s1#FF0000:Load'
Dieses hat leider keine Auswirkungen, wenn ich den ausführe. In graph/ wird keine Grafik erzeugt. Und es ist definitiv kein Rechteproblem.

Wie es aussieht braucht man wohl doch ein paar rrdtool Kenntnisse um das ganze zu konfigurieren. Im Moment blicke ich noch nicht so richtig durch. Kennt jemand evtl. noch irgendwelche Infos die ich noch nicht gefunden habe?


Viele Grüße
Andreas

edit: Neuer Einleitungs-Text, "Serverstats Support" gehört auf Serverstat ML
Last edited by andreask2 on 2005-12-23 01:58, edited 1 time in total.
User avatar
Joe User
Project Manager
Project Manager
Posts: 11174
Joined: 2003-02-27 01:00
Location: Hamburg

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

Post by Joe User »

http://www.webmasterpro.de/~ddanier/serverstats/ wrote: Todo

* rrdtool 1.2 support, will drop compability with <1.2
Welche rrdtool-Version hast Du installiert?
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen

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

Post by andreask2 »

Ach ja, stimmt, hatte ich auch gelesen. Jetzt habe ich mal 1.0.49 installiert, aber es funktioniert immer noch nicht. rrdtool so funktioniert, aber die Parameter die durch die PHP-Scripte genriert werden, stimmen irgendwie nicht richtig. Ein Königreich für ein funktionierendes Beispiel oder ein Tutorial, oder einen Blog-Eintrag.... ;-)
Ich habe mir die kompletten Befehlszeilen in includes/rrdgraph.class.php und includes/rrd.class.php ausgeben lassen (system).

$config['list']['content'] sieht jetzt so aus:

Code: Select all

array(
			// Simple Options, no need to care about the DEFs
			array(
				'type' => 'line',
				'width' => 2, // may be 1, 2 or 3 (optional, default: 2)
				'source' => 'load',
				'ds' => 'load',
				'cf' => 'AVERAGE',
				'legend' => 'Load', // Always optional
				'color' => 'FF0000'
			)
)
weil bei der Ausführung von graph.php der Fehler kam, dass 'ds' => s1 nicht definiert sei. Aber leider ist bei 'load' dasselbe Problem.

Ich weiß es auch nicht. rrd-Dateien werden angelegt, aber schon die Updates funktionieren nicht mehr. Es gibt keine Fehlermeldung, aber es wird immer nur "nan" reingeschrieben. Einen Fehler gibt es dann erst beim Graphen, eben dass "DS" (in diesem Fall 'load') nicht existiere.
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen

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

Post by andreask2 »

OK, bekomme jetzt einfache Graphen erzeugt, aber nicht wirklich solche netten wie in der Demo. Aber ohne ein paar konkrete Beispiele macht das nicht wirklich Spaß :-(

Wenn ich das alles mal hinbekommen habe, werde ich da wohl mal was ins http://rootiewiki.de/ schreiben.

Mal was ich bisher noch so konfiguriert habe:

in config/graph.php

Code: Select all

$config['list'] = array(
        array(
                'title' => 'Eingeloggte User',
                'verticalLabel' => 'Users',
                'lowerLimit' => 0,
                'altAutoscaleMax' => true,

                'content' => array(
                        // Simple Options, no need to care about the DEFs
                        array(
                                'type' => 'line',
                                'width' => 2, 
                                'source' => 'users',
                                'ds' => 'users',
                                'cf' => 'AVERAGE',
                                'legend' => 'Anzahl User', 
                                'color' => 'FF0000'
                        )
                )
        ),
        array(
                'title' => 'Systemauslastung',
                'verticalLabel' => 'loadavg',
                'lowerLimit' => 0,
                'altAutoscaleMax' => true,
                'content' => array(
                        array(
                                'type' => 'area',
                                'source' => 'load',
                                'ds' => '1min',
                                'cf' => 'AVERAGE',
                                'legend' => '1min',
                                'color' => 'FF0000'
                        ),
                        array(
                                'type' => 'area',
                                'source' => 'load',
                                'ds' => '5min',
                                'cf' => 'AVERAGE',
                                'legend' => '5min',
                                'color' => 'EE0000'
                        ),
                        array(
                                'type' => 'area',
                                'source' => 'load',
                                'ds' => '15min',
                                'cf' => 'AVERAGE',
                                'legend' => '15min',
                                'color' => 'DD0000'
                        )
                )
        )
);
$config['list'] ist das Array mit den Graphen. Jedes Element dieses Arrays ist ein eigener Graph. Der Erste Graph ($config['list'][0]) wird später z.B. per graph.php?graph=0 angesprochen

Wichtig sind dann die Einstellungen in 'content':

- 'type' ist der Typ des Graphen (line, area..., siehe: http://people.ee.ethz.ch/~oetiker/webto ... html#graph)

- 'source' ist die entsprechende Zuordung zu einer Datenqelle, wie es (nach meinem aktuellen Verständnis) in config/sources.php definiert ist. Diese müssen mit einer entsprechenden Datenquelle im Verzeichnis sources/ zusammenpassen.

- 'ds' (datasource) bezeichnet die Datenquelle aus der rrd-Datei, wie es beim Anlegen und Aktualisieren der Daten angegeben wird (zumindest glaube ich das). Dieser Wert muss mit einer Angabe aus einer Datenquelle zusammenpassen, die aber nicht im config/ Verzeichnis benannt werden, sondern in der jeweiligen Source-Klasse im Verzeichnis sources/. Daher hier mal der passende abschnitt aus sources/load.php:

Code: Select all

	public function initRRD(rrd $rrd)
	{
		$rrd->addDatasource('1min', 'GAUGE', null, 0);
		$rrd->addDatasource('5min', 'GAUGE', null, 0);
		$rrd->addDatasource('15min', 'GAUGE', null, 0);
		$rrd->addDatasource('running', 'GAUGE', null, 0);
		$rrd->addDatasource('tasks', 'GAUGE', null, 0);
	}
Siehe: http://people.ee.ethz.ch/~oetiker/webto ... _arguments

- 'cf' (consolidation function) bezeichnet halt die Art der "Datenkonsolidierung (average, minimum, maximum, total, last), meisten will man wohl den Durchschnittswert, also AVERAGE. Siehe:
http://people.ee.ethz.ch/~oetiker/webto ... solidation

- 'legend' (optional) ist die Legende unter der Grafik (wie man es allerdings hinbekommt diese in eine jeweils eigene Zeile zu schreiben weiß ich nicht)

- 'color' ist die Farbe des Graphen (also der entsprechenden Linie bzw. Fläche)

Naja, ohne Doku, ohne funktionierende Beispiele und ohne fundiertes Wissen bzgl. rrdtool ist es etwas schwierig - zumindest für mich. Ich hab mir halt immer noch die Kommandozeilen-Aufrufe ausgeben lassen, und die mal selber ausgeführt, um zu sehen was da jetzt generiert wird, und um ggfs. Fehlermeldungen von rrdtool zu bekommen. Dazu muss man in den Scripten nur nach "system" suchen, da hat man die Aufrufe, muss man dann nur noch ausgeben oder loggen. Ich habe den Autor mal angeschrieben, ob er evtl. mal die konkrete Konfiguration für ein paar der Demo-Beispiele veröffentlichen kann.
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen

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

Post by andreask2 »

Hab im Prinzip das was ich hier im Thread geschrieben habe, mal im rootiewiki zusammengefasst, und werde das dann entsprechend erweitern, wenn ich bessere Beispiele habe und einen besseren Durchblick ;-)

http://rootiewiki.de/wiki/Serverstats

Wenn sonst jemandem noch was dazu einfällt bitte unbedingt hinzufügen!
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen

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

Post by andreask2 »

Netterweise hat David Danier, der Autor von serverstats, seine config/graph.php für die demo-Version online gestellt:

http://webmasterpro.de/~ddanier/servers ... graph.phps
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen

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

Post by andreask2 »

So, nachdem das inzwischen bei mir ganz gut funktioniert, habe ich jetzt nochmal die Seite im rootiewiki aktualisiert und deutlich erweitert. Hab unter anderem auch erklärt, wie man eigene Datenquellen schreibt.

http://rootiewiki.de/wiki/Serverstats

PS: Man kann doch rrdtool 1.2 verwenden
captaincrunch
Userprojekt
Userprojekt
Posts: 7066
Joined: 2002-10-09 14:30
Location: Dorsten

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

Post by captaincrunch »

Heißen Dank für die Mitarbeit!
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen

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

Post by andreask2 »

Gerne!

Leider ist Serverstats noch nirgendwo dokumentiert, ich dachte da wäre das rootiewiki vielleicht genau das richtige wo man das mal anfangen kann. Ist ein sehr interessantes Tool für die Auswertungen, und kommt mir sehr entgegen weil ich eh viel mit PHP mache. Für mich besteht da nur das Problem, dass man einigermaßen wissen sollte wie rrdtool funktioniert und was es mit den Optionen auf sich hat... das war bei mir nicht der Fall, aber inzwischen - vor allem Dank der Hilfe des Autors - klappt es ganz gut.

Hoffe dass da im Wiki noch einige interessante Artikel entsehen!
ddanier
Posts: 23
Joined: 2005-07-15 19:20

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

Post by ddanier »

Version 0.6 steht seit heute zum Download bereit. Den Eintrag im Wiki hab ich bereits angepasst. ;-)
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen

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

Post by andreask2 »

Ah, das ist gut, super!

Muss ich dann wohl rrdtool 1.2 installieren, und am besten lösche ich einfach die cache/* und rrd/* Dateien - wenn ich die nicht mehr brauche, oder?

Hab noch eine (vielleicht etwas seltener benötigte) neue Source gebastelt - APC (php opcode cache):

Hierfür muss natürlich APC installiert sein, und man benötigt ein Script, welches die Status-Daten vom Cache abfragt und per HTTP unter localhost ausliefert, das sieht bei mir so aus:

Code: Select all

<?php
header('Content-Type: text/plain');
if(!$cache_info = @apc_cache_info()) { //$mode!
        die("No cache info available.");
}
$sma_info = apc_sma_info();
$mem_used = $sma_info['seg_size'] - $sma_info['avail_mem'];
echo "mem_size: $sma_info[seg_size]n";
echo "mem_used: $mem_usedn";
echo "num_hits: $cache_info[num_hits]n";
echo "num_misses: $cache_info[num_misses]n";
echo "cached_files: ".count($cache_info['cache_list'])."n";
echo "deleted_files: ".count($cache_info['deleted_list'])."n";
?>
Hiermit kann man dann z.B. Graphen für Speicherverbrauch und cache-hits/cache-misses des Caches erzeugen.

sources/apc.php:

Code: Select all

<?php
/**
 * Author: Andreas Korthaus, akorthaus@web.de
 * Project: Serverstats, http://www.webmasterpro.de/~ddanier/serverstats/
 * License: GPL v2 or later (http://www.gnu.org/copyleft/gpl.html)
 *
 * Copyright (C) 2005 Andreas Korthaus
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 *
 *
 * Requirements:
 *
 * In order to use this source you have to install APC and put a php-script
 * which answeres to something like http://localhost/apc-status.php with
 * the following code:
 *
 *      <?php
 *              header('Content-Type: text/plain');
 *              if(!$cache_info = @apc_cache_info()) { //$mode!
 *                      die("No cache info available.");
 *              }
 *              $sma_info = apc_sma_info();
 *              $mem_used = $sma_info['seg_size'] - $sma_info['avail_mem'];
 *              echo "mem_size: $sma_info[seg_size]n";
 *              echo "mem_used: $mem_usedn";
 *              echo "num_hits: $cache_info[num_hits]n";
 *              echo "num_misses: $cache_info[num_misses]n";
 *              echo "cached_files: ".count($cache_info['cache_list'])."n";
 *              echo "deleted_files: ".count($cache_info['deleted_list'])."n";
 *      ?>
 */

class apc extends source
{
        private $url_apcstatus;
        private $data = array();
        private $show = array();
        private $types = array();

        public function __construct($url_apcstatus = 'http://localhost/apc-status.php', $show = null)
        {
                $this->url_apcstatus = $url_apcstatus;
                if (!isset($show))
                {
                        $show = array(
                                'mem_size',
                                'mem_used',
                                'num_hits',
                                'num_misses',
                                'cached_files',
                                'deleted_files'
                        );
                }
                if (!is_array($show))
                {
                        $show = array($show);
                }
                $this->show = $show;
                $this->types = array(
                        'mem_size' => 'GAUGE',
                        'mem_used' => 'GAUGE',
                        'num_hits' => 'DERIVE',
                        'num_misses' => 'DERIVE',
                        'cached_files' => 'GAUGE',
                        'deleted_files' => 'GAUGE'
                );
        }

        public function refreshData()
        {
                if (!($lines = @file($this->url_apcstatus)))
                {
                        throw new Exception('Error while reading APC-status');
                        return;
                }
                foreach ($lines as $line)
                {
                        $parts = explode(':', $line);
                        if (in_array(trim($parts[0]), $this->show)) {
                                $this->data[trim($parts[0])] = trim($parts[1]);
                        }
                }
        }

        public function initRRD(rrd $rrd)
        {
                foreach ($this->show as $source) {
                        $rrd->addDatasource($source, $this->types[$source], null, 0);
                }
        }

        public function updateRRD(rrd $rrd)
        {
                foreach ($this->data as $name => $value)
                {
                        if ($rrd->hasDatasource($name))
                        {
                                $rrd->setValue($name, $value);
                        }
                }
        }
}

?>
config/sources.php:

Code: Select all

$config['apc']['module'] = new apc();
$config['apc']['rra'] = 'default';
config/graph.php:

Code: Select all

    array(
        'title' => 'APC (memory usage)',
        'lowerLimit' => 0,
        'altAutoscaleMax' => true,
        'content' => array(
            array(
                'type' => 'def',
                'source' => 'apc',
                'ds' => 'mem_size',
                'cf' => 'AVERAGE',
                'name' => 'total'
            ),
            array(
                'type' => 'area',
                'name' => 'total',
                'legend' => 'total memory',
                'color' => 'FFFFCC'
            ),
            array(
                'type' => 'line',
                'width' => 1,
                'name' => 'total',
                'color' => '000000'
            ),
            array(
                'type' => 'area',
                'source' => 'apc',
                'ds' => 'mem_used',
                'cf' => 'AVERAGE',
                'legend' => 'used memory',
                'color' => 'FF0000'
            )
        )
    ),
    array(
        'title' => 'APC (cache hits)',
        'lowerLimit' => 0,
        'altAutoscaleMax' => true,
        'content' => array(
            array(
                'type' => 'area',
                'source' => 'apc',
                'ds' => 'num_hits',
                'cf' => 'AVERAGE',
                'legend' => 'cache hits/s',
                'color' => 'FFDD00'
            ),
            array(
                'type' => 'area',
                'source' => 'apc',
                'ds' => 'num_misses',
                'cf' => 'AVERAGE',
                'legend' => 'cache misses/s',
                'color' => 'FF0000'
            )
        )
    ),
legato
Posts: 115
Joined: 2004-06-03 12:40

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

Post by legato »

Hallo!

Mir gefällt dieses script soweit wirklich gut, würde es daher gern auch bei mir einsetzen.
Habe es zuerst auf meinem Testserver (nach der Kurzanleitung im rootiewiki) installiert, wo es auch auf Anhieb lief.

Nun wollte ich es soweit schon mal auf meinem Produktivserver aufsetzen.
Hier habe ich das Problem, dass zwar die .rrd Dateien korrekt abgelegt werden, im graph Ordner passiert aber nichts.

Ich hab schon an der PHP Konfiguration geschraubt, open_basedir und safe_mode sind momentan aus.
Auch disable_functions habe ich per vHost reduziert.
Trotzdem keine pngs zu finden...

Hat jemand einen Tipp zur Fehlersuche?

Danke, stephan
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen

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

Post by andreask2 »

Hat der Webserver/PHP Schreibzugriff auf das Verzeichnis graph ?
legato
Posts: 115
Joined: 2004-06-03 12:40

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

Post by legato »

Ja, Rechte sind alle da.
Ich habe die Ordner wirklich soweit entschärft wie ich nur konnte, trotzdem keine pngs..

Dann hab ich noch mal einen genauen Blick auf phpinfo() geworfen. Natürlich hatte ich bei disable_functions noch einige Funktionen drin, allerdings hatte ich das für den vHost schon geändert.
Trotzdem zusätzlich direkt in der php.ini geändert, und nun geht es...

Orientiert PHP sich bei disable_functions nicht an den Local Values? Oder gelten immer die Master Values? Konnte das eben bei kurzer Suche nicht feststellen...

Ich möchte das in der php.ini ungern ändern, dann müsste ich bei jedem vHost den lange disable_functions string hinzufügen...:

Code: Select all

php.ini:
disable_functions = exec,passthru,system,popen,proc_open,shell_exec,escapeshellcmd,escapeshellarg

vHost:
php_admin_value disable_functions feof
Die Syntax für den vHost ist ja korrekt, oder? Wird zumindest laut phpinfo() akzeptiert...

Hm.


===
edit:

Ok, etwas Recherche hat ergeben das man disable_functions nicht per vHost steuer kann.
Komisch, denn bei local value wir ja immerhin mein wert eingetragen.

Muss ich nun tatsächlich die Funktionen systemweit erlauben? Gibts da noch eine geschickte Möglichkeit, die Funktionen nur einem vHost zur Verfügung zu stellen?
:?
User avatar
Joe User
Project Manager
Project Manager
Posts: 11174
Joined: 2003-02-27 01:00
Location: Hamburg

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

Post by Joe User »

Legato wrote:Gibts da noch eine geschickte Möglichkeit, die Funktionen nur einem vHost zur Verfügung zu stellen?
suPHP
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
legato
Posts: 115
Joined: 2004-06-03 12:40

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

Post by legato »

Joe User wrote:
Legato wrote:Gibts da noch eine geschickte Möglichkeit, die Funktionen nur einem vHost zur Verfügung zu stellen?
suPHP
Hach, genau das habe ich befürchtet.
Mit suPHP habe ich vor längerer Zeit mal was gemacht... Muss ich mich mal wieder mit befassen.
Danke.
legato
Posts: 115
Joined: 2004-06-03 12:40

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

Post by legato »

Hallo mal wieder,

nachdem ich Serverstats nun im Einsatz habe und eine eigene Klasse zur Abfrage von Spielerzahlen auf Gameservern "geschrieben" habe, habe ich den Eintrag im rootiewiki mal etwas erweitert und IMHO verschönert.

Ich hoffe das ist in Ordnung so, aber das ist ja schließlich der Sinn eines wikis...

http://www.rootiewiki.de/wiki/Serverstats
elvis
Posts: 94
Joined: 2004-05-08 20:27
Location: Recklinghausen

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

Post by elvis »

Hallo Andreas,

ich habe Deinen Thread gelesen und dachte mir, daß Du mir vielleicht helfen könntest.

Ich habe Cacti installiert und soweit funktioniert auch alles. Aber die Graphen werden erzeugt, nur es wird dort nichts eingezeichnet! (leere Graphen!)

Nun habe ich gesehen das in den Settings steht "SNMP not in use". Grund ist wohl das ich eine zu alte rrdtool installiert (1.0.45) habe. Als ich ein aktuelles compilieren wollte, fehlte mir die cgilib - aber die bekomme ich nicht compiliert.

Ich habe Suse 9.0 Pro, Apache2, PHP 4.3.11 - sonst eigentlich alles.

Ach so, ... reicht das, das man in Cacti unter SNMP Community
nur public eingibt?

Wie Du siehst - kein Plan mit Cacti

Gruß,
Elvis
ddanier
Posts: 23
Joined: 2005-07-15 19:20

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

Post by ddanier »

Hmmm...so wies aussieht wächst die Anzahl an Sourcen. Wenn das so weiter geht werde ich wahrscheinlich ein Script zur Verfügung stellen um die Sourcen auf der offiziellen Webseite eintragen und aktualisieren zu können. ;-)
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen

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

Post by andreask2 »

Elvis wrote:Ich habe Cacti installiert und soweit funktioniert auch alles. Aber die Graphen werden erzeugt, nur es wird dort nichts eingezeichnet! (leere Graphen!)
Ich habe aus gutem Grund von Cacti/MRTG zu Serverstats gewechselt. Cacti war mir einfach zu komplex. Serverstats kommt mir sehr viel mehr entgegen.

Wenn Du nicht Serverstats ausprobieren willst, solltest Du einen eigenen Thread eröffnen, oder besser direkt im Cacti Support Forum nachfragen.
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen

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

Post by andreask2 »

ddanier wrote:Hmmm...so wies aussieht wächst die Anzahl an Sourcen. Wenn das so weiter geht werde ich wahrscheinlich ein Script zur Verfügung stellen um die Sourcen auf der offiziellen Webseite eintragen und aktualisieren zu können. ;-)
0.6 läuft übrigens wunderbar!

Mal ne kleine Idee für die 2.0er Version ;-):

So wie es heute ist, ist es recht schwer das ganze zu installieren. Man muss erstmal verstehen wie die PHP-Scripte funktionieren, man muss sich einigermaßen mit rrdtool auskennen, man muss verstehen wie das alles zusammenhängt. Das ist nicht ganz so trivial wie Dir das als Autor vermutlich vorkommt ;-) Inzwischen habe ich da auch keine Probleme mehr, hat aber etwas gedauetr, wenn ich ehrlich bin. Für Leute ohne angemessene PHP/rrdtool/System Kenntnisse ist das allerdings unmöglich, denke ich zumindest.

Abgesehen davon ist die Konfiguration so komplex, dass man es IMHO nicht wirklich sinnvoll in eine Paketverwaltung wie Gentoo-Portage einbauen könnte (was ich sehr gerne sehen würde!).

Man könnte irgendwann den ganzen rrdtool- und PHP-Kram vor den Usern verstecken - zumindest optional. Ich meine, das meiste funktioniert doch auf den meisten Server genau gleich. Ich kann zum Beispiel die komplette Beispielkonfiguration übernehmen, und habe sofort wunderbare Graphen. Wenn also ein Archiv erstellen würde, mit der Beispiel-Konfiguration, könnte man ganz einfach durch Entpacken die schönen Graphen bekommen, wie Du sie auf Deine Homepage hast. Man muss lediglich den cronjob einrichten, und ggfs. noch ein IP-Tables Script starten.

Das Problem dabei ist die Anpassung an eigene Bedürfnisse. Und hier würde ich ansetzen. Die meisten Leute wollen doch die gleichen Graphen haben, also könnte man eine sehr simple Konfiguration über die aktuelle Konfiguration "legen", die nur die notwendigsten Daten enthält, ja womöglich nur eine Liste welche Graphen gewünscht werden, evtl. mit der ein oder anderen Option. Das könnte aus einer Konfig-Datei stammen, oder aus einer Konfig-Oberfläche.

Man könnte dann immer mehr Sourcen/Graphen sammeln, diese Graphen irgendwo Beispielhaft abbilden, so dass der User am Ende nur die Graphen die er will auswählen (oder in der Konfig-Datei angeben) muss. Das ist dann lediglich bei den Sourcen, die Externe Daten benötigen (Traffic, Apache-Requests, MySQL-Daten...) nicht ganz so einfach. Hier benötigt man dann eine idiotensicher Installations-Anweisung (fertiges IP-Tables-Script, 3 extra-Parameter für MySQL-Zugangsdaten, fertige Apache-Config...).

Wenn man das über eine einfache Web-Oberfläche macht, ist das wirklich simpel, man kann die Daten entweder per XML oder als serialisierten Array speichern. Am besten erzeugt man dann einmalig die fertigen Arrays (Graph-Config...) mit

Code: Select all

file_put_content('autograph.config.php','<?php $condig='.var_export($generated_config, TRUE);.'?>');
Natürlich darf das ganze nicht in Richtung Cacti abdriften, aber ich denke dass die meisten User besser mit einem einfachen System, das eben nicht 100% flexibel ist leben könnten. Und für diejenigen, die die absolute Flexibilität wollen, können ja parallel noch eigene Graphen konfigurieren. Man müsste die automatische Graphen-Konfiguration nur von der manuellen sauber trennen, und das ganze so implementieren, dass es am Ende doch wieder eine Konfiguration, wie heute ist (wenn Du verstehst was ich meine ;-).

Das wäre dann genau so ein System, wie ich es schon seit Ewigkeiten Suche. Sicher, einmal konfiguriert und läuft, und läuft... ist ja schön und gut, aber die Hürde für jeden Einsteiger ist doch immens, und wenn man mehrere Server hat, und alle paar Wochen/Monate neue, ist es doch jedes mal wieder ein Problem, wenn man das Programm nicht gerade selber geschrieben hat :-)

Das mal als grobe Idee für die Zukunft, ich könnte mir vorstellen dass sich serverstats dann wegen der Einfachheit und wenigen Anhängigkeiten und geringer Komplexität durchaus gegen MRTG, rrdtool und Cacti durchsetzen könnte!
ddanier
Posts: 23
Joined: 2005-07-15 19:20

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

Post by ddanier »

Dann zerpflücke ich das mal :)
andreask2 wrote:So wie es heute ist, ist es recht schwer das ganze zu installieren. Man muss erstmal verstehen wie die PHP-Scripte funktionieren, man muss sich einigermaßen mit rrdtool auskennen, man muss verstehen wie das alles zusammenhängt.
Zumindest hierzu fehlt die Doku, ich weiß. Allgemein finde ich es aber garnicht schlecht zu fordern sich mit rrdtool auszukennen. Ich erinner mich an meine ersten Cacti-Versuche und wie ich nahezu keine Ahnung hatte, wie das Ding eigentlich funktioniert.
andreask2 wrote:Abgesehen davon ist die Konfiguration so komplex, dass man es IMHO nicht wirklich sinnvoll in eine Paketverwaltung wie Gentoo-Portage einbauen könnte (was ich sehr gerne sehen würde!).

Code: Select all

emerge phpmyadmin
Schonmal gesehen, dass der dir da deinen MySQL-Login in die Konfiguration überträgt? ;-)
andreask2 wrote:Man könnte irgendwann den ganzen rrdtool- und PHP-Kram vor den Usern verstecken - zumindest optional.
In irgendeiner der nächten Versionen will ich da etwas anbieten. Aber ich les mal weiter...
andreask2 wrote:Ich meine, das meiste funktioniert doch auf den meisten Server genau gleich. Ich kann zum Beispiel die komplette Beispielkonfiguration übernehmen, und habe sofort wunderbare Graphen. Wenn also ein Archiv erstellen würde, mit der Beispiel-Konfiguration, könnte man ganz einfach durch Entpacken die schönen Graphen bekommen, wie Du sie auf Deine Homepage hast. Man muss lediglich den cronjob einrichten, und ggfs. noch ein IP-Tables Script starten.
Wäre eine Idee. Könnte man parallel zu Scriptsammlung anbieten.
Problem hierbei: Jede Graphenconfiguration setzt bestimmte definierte Sourcen vorraus. Wenn das nun jemand umbenennt oder so gibts Probleme.
andreask2 wrote:Das Problem dabei ist die Anpassung an eigene Bedürfnisse. Und hier würde ich ansetzen. Die meisten Leute wollen doch die gleichen Graphen haben, also könnte man eine sehr simple Konfiguration über die aktuelle Konfiguration "legen", die nur die notwendigsten Daten enthält, ja womöglich nur eine Liste welche Graphen gewünscht werden, evtl. mit der ein oder anderen Option. Das könnte aus einer Konfig-Datei stammen, oder aus einer Konfig-Oberfläche.
Also ehe ich die Konfiguration verkomplizier und fertige Template für Konfigurationen ins Grundsystem einbaue würde ich das doch lieber in einen Editor auslagern, der die Templates im jetzigen Format in die Konfiguration einträgt.
(KISS)
andreask2 wrote:Man könnte dann immer mehr Sourcen/Graphen sammeln, diese Graphen irgendwo Beispielhaft abbilden, so dass der User am Ende nur die Graphen die er will auswählen (oder in der Konfig-Datei angeben) muss. Das ist dann lediglich bei den Sourcen, die Externe Daten benötigen (Traffic, Apache-Requests, MySQL-Daten...) nicht ganz so einfach. Hier benötigt man dann eine idiotensicher Installations-Anweisung (fertiges IP-Tables-Script, 3 extra-Parameter für MySQL-Zugangsdaten, fertige Apache-Config...).
...weshalb ich soetwas hinten anstellen würde und erstmal einen einfachen Konfigurationseditor schreiben will. ;-)
andreask2 wrote:Wenn man das über eine einfache Web-Oberfläche macht, ist das wirklich simpel, man kann die Daten entweder per XML oder als serialisierten Array speichern. Am besten erzeugt man dann einmalig die fertigen Arrays (Graph-Config...) mit

Code: Select all

file_put_content('autograph.config.php','<?php $condig='.var_export($generated_config, TRUE);.'?>');
Sowas in der Art ist geplant...ich fass das unten mal zusammen.
andreask2 wrote:Natürlich darf das ganze nicht in Richtung Cacti abdriften, aber ich denke dass die meisten User besser mit einem einfachen System, das eben nicht 100% flexibel ist leben könnten. Und für diejenigen, die die absolute Flexibilität wollen, können ja parallel noch eigene Graphen konfigurieren. Man müsste die automatische Graphen-Konfiguration nur von der manuellen sauber trennen, und das ganze so implementieren, dass es am Ende doch wieder eine Konfiguration, wie heute ist (wenn Du verstehst was ich meine ;-).
Hehe, stimme ich zu.
andreask2 wrote:Das mal als grobe Idee für die Zukunft, ich könnte mir vorstellen dass sich serverstats dann wegen der Einfachheit und wenigen Anhängigkeiten und geringer Komplexität durchaus gegen MRTG, rrdtool und Cacti durchsetzen könnte!
Gegen rrdtool sicher nciht, da es auf rrdtool basiert :D


Zu meinen Plänen:
In einer der nächsten Versionen habe ich vor einen Editor einzufügen der die jetzige Konfiguration in eine Weboberfläche abbildet. Vorteil für mich ist hier hauptsächlich, dass keine Konfigurationsfehler passieren können und man schneller Konfigurationen erstellen kann, da man nicht immer die benötigten Felder kennen muss. Diesen Editor könnte man optional sogar als Zusatzprogramm anbieten, also nicht in die Standarddistribution von Serverstats aufnehmen. Vorteil: Nur User die ihn brauchen müssen ihn auch herunterladen. Außerdem wurde auch aus Sicherheitsgründen bisher auf jegliche Ã?nderungsmöglichkeit über eine Weboberfläche verzichtet, ganz abgesehen von der zusätzlichen Komplexität (ich denke an Userverwaltung und so Zeug).
Wenn dieser Editor steht kann man überlegen ihn zu erweitern und soetwas wie Templates für Graphkonfigurationen einzufügen. Insofern man das in einer sauberen Struktur speichert kann man auch Abhängigkeiten prüfen (beispielweise das eine Source vom Typ XXX vorhanden ist) und evtl. erweiterte Auswahlmöglichkeiten anbieten (beispielsweise wenn mehrere Sourcen vom Typ XXX vorhanden sind eine Auswahl welche man nutzen möchte oder eine Möglichkeit die vordefinierten Farben zu ändern ohne das bei jedem Auftauchen in der Konfiguration händisch zu machen).
Bevor man solche Features erstellt halte ich es aber für sinnvoll ersteinmal einen Editor zu erstellen der nur die Konfiguration wie bisher vereinfacht. Bis Serverstats so weit ist wie von dir vorgeschlagen werden also mindesten 2 Releases stattfinden.
Kommentare hierzu sind natürlich willkommen. ;-)

Allgemein finde ich deine Ideen aber sehr gut und werde wenn ich genug Zeit hab denke ich damit beginnen etwas in die Richtung zu implementieren.
andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen

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

Post by andreask2 »

ddanier wrote:Zumindest hierzu fehlt die Doku, ich weiß. Allgemein finde ich es aber garnicht schlecht zu fordern sich mit rrdtool auszukennen.
Glaubst wirklich dass man das braucht? Von einem Editor wo man rrdtool Kenntnisse haben sollte um den vernünftig bedienen zu können halte ich eigentlich nichts, das wird vermutlich sogar noch komplizierter als Cacti. Allerdings weiß ich nicht wie genau Du Dir so einen Editor vorstellst. Ich wollte unbedingt von der Teilung "sourcen, graph..." und rrdtool/mrtg mäßigen Einstellungen weg. Die sind zwar sehr ausgeklügelt, aber sehr schwer zu verstehen. Ich würde das ganze gerne aus der Sicht eines Server-Admins sehen, der kein PHP-Programmierer ist, rrdtool gar nicht kennt, dem cacti zu kompliziert ist und unnötigerweise einen extra DB-Server erfordert. Dieser Admin will lediglich ein paar nette Graphen.

Er will eine Ã?bersicht für Load, CPU, RAM, vielleicht noch Traffic oder Mail-Versand.

Dann installiert er sich als serverstats:

Code: Select all

emerge serverstats
Dann ruft er http://admin.example.com/serverstats/install.php auf:

Code: Select all

Willkommen bei der serverstats Installations für DAUs!

Bitte wählen Sie Ihre Graphen aus der Folgenden Liste, ein Beispiel-Graph wird daneben angezeigt:

[x] CPU
[ ] RAM 1
[x] RAM 2
[x] Load
[ ] Traffic (global)*
[x] Traffic (in/out)*
[ ] Traffic (http)*
[ ] Traffic (ssh)*
[x] Apache Requests*
[ ] Mails (Postfix)


[Abschicken]

* Graph benötigt zusätzliche Konfiguration zum Sammeln der Daten, eine Anleitung wird im nächsten Schritt aufgelistet.

Code: Select all

Sie haben Graphen ausgewählt, die zusätzliche Konfiguration erfordern. Konfiguration erfolgt nach folgender Anleitung:

1) Traffic (in/out):
... muss ein iptables Script installiert werden. Hierzu führen SIe bitte folgende Schritte auf der Kommandozeile als superuser aus:

iptables-restore < /path/to/src/iptables_inout
cp /path/to/src/traffic.cron /etc/cron.d
...


2) Apache Requests:

... fügen sie in die httpd.conf ein:

  <Location /server-status>
       SetHandler server-status
       Order deny,allow
       Deny from all
       Allow from 127.0.0.1
  </Location>
  ExtendedStatus On

...danach Apache neu starten

------------------

[weiter]

Code: Select all

Zum Abschluss der Installation müssen sie nur noch den Cronjob einrichten, der serverstats minütlich aufruft:

cp /path/to/src/serverstats.cron /etc/cron.d


Bitte geben Sie ein Passwort für spätere Ã?nderungen der Konfiguration ein

Passwort: [         ]

[Installation abschließen]

So ungefähr hätte ich das gerne, und das alles mit schön vielen Sourcen und Graphen. Nicht mehr fürs erste. Dann kann man von mir aus noch ein paar grundsätzliche Sachen konfigurieren (wie groß die Graphen...). Evtl. könnte man ein paar mehr parameter einstellbar machen, vielleicht indem man unter jedem Graphen auf ein [+] klickt so dass sich noch ein kleines Menü aufklappt, wo man dann halt noch ein paar rrdtool Parameter eingeben kann - aber abgehoben von rrdtool, so dass es aus Sicht des gewünschten Graphen selbsterklärend ist.

Einen Editor für die aktuelle Konfiguration würde ich davon trennen. Ich würde den glaube ich nicht unbedingt benötigen, naja, vielleicht doch. Muss man sich einen gruten Weg überlegen, wie man diese DAU Konfiguration von der rrd basierten Konfiguration (ob editor oder in config) trennt. Das heißt eigene Dateien, die dann vom Framework mit array_merge() zusammengefügt werden oder sowas. Das heißt, die generierten Graph/config Arrays in ein ganz anderes Verzeichnis als config/. Evtl. könnte man einen Editor verwenden, um eine eigene Config in das Format für die DAU-Config übernhemen könnte, so erstellt man die einmal - ob mit editor oder als PHP, und erstellt dann mit Hilfe eines Scripts ein Template für die DAU Oberfläche, wo das dann als zusätzliche Graphen angezeigt wird (evtl. ein eigenes Verzeichnis für die Templates, am Ende wird aus den Eingaben der DAU-Oberfläche und den entsprechendne Templates eine Konfig generiert, am besten also gar nicht mit eigenen Configs mischen, also nur über die Templates).
ddanier wrote:

Code: Select all

emerge phpmyadmin
Schonmal gesehen, dass der dir da deinen MySQL-Login in die Konfiguration überträgt? ;-)
Ob das auch mit Deinem kompletten config/* klappt? ;-)
ddanier wrote:In irgendeiner der nächten Versionen will ich da etwas anbieten.
das ist gut ;-)
ddanier wrote:Also ehe ich die Konfiguration verkomplizier und fertige Template für Konfigurationen ins Grundsystem einbaue würde ich das doch lieber in einen Editor auslagern, der die Templates im jetzigen Format in die Konfiguration einträgt.
(KISS)
Ich will die Konfiguration nicht verkomplizieren, ich will es DAU-Kompatibel machen, und ich bin mir relativ sicher dass das auch funktioniert!

Bisher gibt es sowas nicht.
ddanier wrote:Bevor man solche Features erstellt halte ich es aber für sinnvoll ersteinmal einen Editor zu erstellen der nur die Konfiguration wie bisher vereinfacht. Bis Serverstats so weit ist wie von dir vorgeschlagen werden also mindesten 2 Releases stattfinden.
Ja, ein Editor wäre vielleicht nicht schlecht, mit dem könnte man dann ja auch Templates speichern, die dann vom späteren DAU-Installations-Wizzard genutzt werden können.
ddanier
Posts: 23
Joined: 2005-07-15 19:20

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

Post by ddanier »

andreask2 wrote:
ddanier wrote:Zumindest hierzu fehlt die Doku, ich weiß. Allgemein finde ich es aber garnicht schlecht zu fordern sich mit rrdtool auszukennen.
Glaubst wirklich dass man das braucht? Von einem Editor wo man rrdtool Kenntnisse haben sollte um den vernünftig bedienen zu können halte ich eigentlich nichts, ...
Das war auf die derzeitige Konfiguration, nciht auf einen Editor bezogen.
andreask2 wrote:...das wird vermutlich sogar noch komplizierter als Cacti. Allerdings weiß ich nicht wie genau Du Dir so einen Editor vorstellst. Ich wollte unbedingt von der Teilung "sourcen, graph..." und rrdtool/mrtg mäßigen Einstellungen weg.

...viel Text...
Was du da beschreibst ist ein Installationswizard...
Bevor ich soetwas mache hätte ich gerne einen Editor für die aktuelle Konfiguration mit dem man eben auch so Dinge anstellen kann wie Templates zur Graphenkonfiguration einzufügen. Basierend darauf
würde sich so ein Wizand dann ziemlich einfach schreiben.
(Immer erst den Weg des kleinsten Widerstandes gehen und dann darauf basierend arbeiten...)

Aber wie bereits gesagt: Dir steht es natürlich frei so ein Wizard zu schreiben, ich biete es auch gerne zum Download an.
...vor dem Wizard oder auch vor Templates kommt bei mir aber ein Editor.
andreask2 wrote:Einen Editor für die aktuelle Konfiguration würde ich davon trennen. Ich würde den glaube ich nicht unbedingt benötigen, naja, vielleicht doch.
Ziemlich sicher brauch man den...und das schlimme ist: Wenn der komplizierter ist als das Installationswizard kommen die Leute nicht damit klar, ein weitere Grund erst einen Editor zu schreiben.
andreask2 wrote:Muss man sich einen gruten Weg überlegen, wie man diese DAU Konfiguration von der rrd basierten Konfiguration (ob editor oder in config) trennt. Das heißt eigene Dateien, die dann vom Framework mit array_merge() zusammengefügt werden oder sowas. Das heißt, die generierten Graph/config Arrays in ein ganz anderes Verzeichnis als config/. Evtl. könnte man einen Editor verwenden, um eine eigene Config in das Format für die DAU-Config übernhemen könnte, so erstellt man die einmal - ob mit editor oder als PHP, und erstellt dann mit Hilfe eines Scripts ein Template für die DAU Oberfläche, wo das dann als zusätzliche Graphen angezeigt wird (evtl. ein eigenes Verzeichnis für die Templates, am Ende wird aus den Eingaben der DAU-Oberfläche und den entsprechendne Templates eine Konfig generiert, am besten also gar nicht mit eigenen Configs mischen, also nur über die Templates).
Das klingt nach Suseconfig....nachdem man in langer Handarbeit seine eigene Config hineditoert hat überschreibt einem das Ding diese wieder, weil es ein anderes Verzeichnis mit dem config-Verzeichnis abgleichen will.

Sinnvoller finde ich folgendes:
Wenn ich ein Template einfüge wird das direkt in die Konfiguration geschrieben. Um das wieder als Template zu erkennen wird evtl. eine Markierung gesetzt (Wert 'fromtemplate' im Array). Hierbei kann ich den dadurch erzeugten Graphen im Nachinein beliebig anpassen...ich kann also eine Konfiguration erstellen die auf dem Template basiert, muss aber nicht beim Template bleiben.
andreask2 wrote:
ddanier wrote:

Code: Select all

emerge phpmyadmin
Schonmal gesehen, dass der dir da deinen MySQL-Login in die Konfiguration überträgt? ;-)
Ob das auch mit Deinem kompletten config/* klappt? ;-)
Das hast du falsch verstanden:
Es klappt bei phpmyadmin nicht, weil portage nicht weiß wie die Zugangsdaten sind. Genausowenig klappt das bei typo3, cacti oder phppgadmin....und genausowenig muss das bei Serverstats klappen. Portage ist eine Paketverwaltung, wenn es Aufgaben der Konfiguration übernimmt ist das ein Zusatz, kein Muss.
andreask2 wrote:
ddanier wrote:Also ehe ich die Konfiguration verkomplizier und fertige Template für Konfigurationen ins Grundsystem einbaue würde ich das doch lieber in einen Editor auslagern, der die Templates im jetzigen Format in die Konfiguration einträgt.
(KISS)
Ich will die Konfiguration nicht verkomplizieren, ich will es DAU-Kompatibel machen, und ich bin mir relativ sicher dass das auch funktioniert!
Wieder ein Missverständnis:
Mit Konfiguration verkomplizieren meinte ich: Ich will Templates o.ä. nicht in die jetzige Konfiguration einbauen. Soetwas sollte zu 100% extern ablaufen (mit der Einschränkung, dass man evtl. eine "Notiz" hinterlassen könnte wo die Einstellung herkommt, siehe oben). Die Konfiguration sollte nichts von Templates wissen müssen.
andreask2 wrote:
ddanier wrote:Bevor man solche Features erstellt halte ich es aber für sinnvoll ersteinmal einen Editor zu erstellen der nur die Konfiguration wie bisher vereinfacht. Bis Serverstats so weit ist wie von dir vorgeschlagen werden also mindesten 2 Releases stattfinden.
Ja, ein Editor wäre vielleicht nicht schlecht, mit dem könnte man dann ja auch Templates speichern, die dann vom späteren DAU-Installations-Wizzard genutzt werden können.
Also ich fass die nötigen Features mal zusammen, geordnet nach Priorität:
  • Editor für die bestehenden Daten, Möglichkeit neue Daten hinzuzufügen
    • Frontend und Backend getrennt (Damit ist der Code wiederverwendbar)
    • Backend sollte alle Methoden zum Bearbeiten zur Verfügung stellen
    • Frontend benutzt diese, kein direkter Zugriff auf die Konfiguration
    • Hier bleibt die Sicht sources/graphen/... zu 100% erhalten
  • Templates für einzelne Konfigurationsabschnitte und/oder Wizards
  • Ein Installationsscript das die Fähigkeiten des bisherigen Codes nutzt, wie oben von dir vorgeschlagen
persil
Posts: 5
Joined: 2005-09-13 11:16

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

Post by persil »

Hi!
ich hab auch das problem, dass die graph.php kein bild anzeigt.
es sind laut phpinfo() keine funktionen disabled. lib_gd etc. ist alles drauf und funktioniert eigentlich auch.
wenn ich in der graph.php die zeile mit header() auskommentiere kommt folgende fehlermeldung:

Code: Select all

Warning: readfile(/var/www/kazzam/serverstats-0.6/graph/2b18452259cd8f5dbace645e6570b1d6.png) [function.readfile]: failed to open stream: No such file or directory in /var/www/kazzam/serverstats-0.6/graph.php on line 244
was ist da nun los? die dateirechte für den graph/ ordner sind 777 und gehören dem webserver user.