Posts Tagged ‘RRDtool’

Sonntag, 25. Februar 2018

Eine RRD-Datei mit einer weiteren Data Source DS ergänzen

Heute musste ich in Cacti eine zusätzliche Data Source zu einer bestehenden Round Robin Database hinzufügen, welche bereits Daten enthielt, welche ich nicht verlieren wollte.

Cacti scheint ein solches Update des RRDs nicht selbständig machen zu können, weshalb etwas Handarbeit angesagt ist.

Glücklicherweise unterstützt rrdtool (mittlerweile) eine solche Aktualisierung von RRDs:

in the 1.5 series there is a much better solution for the whole ‚modify rrd‘ problem … create has the ability to pre-populate a new rrd file based on an existing one …

Quelle: since when rrdtool tune can add another DS?

Tatsächlich, schaut man sich die man-Page von rrdcreate an, findet man den Parameter --source, mit welchem man auf eine bestehende Datei zeigen kann, deren Messdaten dann nach allen Regeln der Kunst in die neue Datei importiert werden.

Da Cacti im Data Source Debug Mode einem auch den rrdcreate-Befehl anzeigt, konnte ich diesen kopieren und mit diesem Parameter ergänzen. Um keine Daten zu verlieren, kopierte ich vorher die ursprüngliche RRD-Datei nach /tmp/legacy.rrd und arbeitete nur mit dieser Datai als Quelle. Schlussendlich sah der Befehl dann so aus:

/usr/bin/rrdtool create \
/var/www/cacti/rra/fr24.rrd \
--step 60  \
--source /tmp/legacy.rrd \
DS:AIRCRAFTS:GAUGE:120:0:U \
DS:MESSAGES:COUNTER:120:0:U \
RRA:AVERAGE:0.5:1:500 \
RRA:AVERAGE:0.5:1:600 \
RRA:AVERAGE:0.5:6:700 \
RRA:AVERAGE:0.5:24:775 \
RRA:AVERAGE:0.5:288:797 \
RRA:MIN:0.5:1:500 \
RRA:MIN:0.5:1:600 \
RRA:MIN:0.5:6:700 \
RRA:MIN:0.5:24:775 \
RRA:MIN:0.5:288:797 \
RRA:MAX:0.5:1:500 \
RRA:MAX:0.5:1:600 \
RRA:MAX:0.5:6:700 \
RRA:MAX:0.5:24:775 \
RRA:MAX:0.5:288:797 \
RRA:LAST:0.5:1:500 \
RRA:LAST:0.5:1:600 \
RRA:LAST:0.5:6:700 \
RRA:LAST:0.5:24:775 \
RRA:LAST:0.5:288:797 \

In der Legacy-Datei existierte bereits eine Zeitreihe für AIRCRAFTS, MESSAGES kamen heute dazu.

Fertig!

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 24. Februar 2016

Eine interne Smokeping-Installation über Apache Reverse Proxy verfügbar machen

Heute morgen (US Pacific-Zeit) habe ich mir einige Minuten Zeit genommen, um eine Smokeping-Installation auf dem Linux-Server (nennen wir ihn BETA) in meiner Wohnung in Bern über einen Linux-Server im Elternhaus in Neuenegg zugänglich zu machen. Nur der Apache 2.4 Web-Server auf dem Linux-Server im Elternhaus (nennen wir ihn ALPHA) ist öffentlich aus dem Internet zugänglich.

Wenn Smokeping auf einem bestehenden Server bereits installiert, konfiguriert und aufrufbar ist, ist dieses Vorhaben äusserst simpel:

Als erstes laden wir auf ALPHA die benötigten zwei Proxy-Module:

# cd /etc/apache2/mods-enabled
# ln -s ../mods-available/proxy.conf .
# ln -s ../mods-available/proxy_http.conf .

Weiter erstellen wir ebenfalls auf ALPHA einen virtuellen Host mit folgenden Angaben:

<VirtualHost *:80>
	ServerName smokeping-beta.bern.homeip.net
	ServerAdmin info@eMeidi.com
	
	ProxyPass	/	http://10.1.2.3/
	
	<Location />
		AuthName		"Eyes Only"
		AuthType 		Digest
		AuthUserFile		/etc/apache2/auth/users.digest
		AuthDigestProvider	file
		AuthDigestDomain	/
		
		Require			valid-user
	</Location>
</VirtualHost>

Diese Angaben legen wir unter /etc/apache2/sites-available ab und nennen die Datei beispielsweise smokeping-bern. Schlussendlich aktivieren wir diese folgendermassen:

# cd /etc/apache2/sites-enabled
# ln -s ../sites-available/smokeping-bern

Anschliessend starten wir auf ALPHA den Web-Server neu:

# apache2ctl graceful

Damit Smokeping in der Folge sauber mit allen relativen Pfaden funktioniert, aber auch die Bilder (RRDtool-Graphen) angezeigt werden, rufe ich die Web-Site auf einem beliebigen Computer mit Internetverbindung folgendermassen auf:

http://smokeping-beta.bern.homeip.net/smokeping/smokeping.cgi

WICHTIG: Damit nur authentifizierte Personen auf diesen Reverse Proxy zugreifen können, schütze ich den gesamten Virtual Host mit Benutzernamen und Passwort. Dies ist deshalb auch wichtig, weil meine Konfiguration alle Anfragen auf den Virtual Host an den anderen Server weiterleitet — habe ich in anderen Unterverzeichnissen noch andere Applikationen laufen, wären diese ebenfalls über den Reverse Proxy ansprechbar. Das ist nicht schön, aber momentan als Quick & Dirty-Lösung akzeptabel.

Tags: , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen