MRTG

All posts tagged MRTG

Damit das ganze Funktioniert war schon ein wenig Vorarbeit notwendig, aber das haben wir ja nun hinter uns … für jedes System wird eine Config angelegt, als Beispiel die Config die wir für den PiHole Verwenden. Jede Config erzeugt 2 RRD Graphen, einer für die aktuelle Pingzeit zum Client und ein 2. für den gemessenen Packetloss, damit wir auch sicher sind das Clients offline sind und nicht einfach nur eine Schlechte Verbindung haben


Title[pihole.ping]: Ping of RPI
PageTop[pihole.ping]: <H1>RPI Ping</H1>
<P>Die Pingzeiten zw. dem RPI und RPI werden gemessen

MaxBytes[pihole.ping]: 180
AbsMax[pihole.ping]: 10000
WithPeak[pihole.ping]: ymwd
Options[pihole.ping]: gauge
Target[pihole.ping]: `/usr/bin/mrtg-ping-probe 192.168.178.43`
YLegend[pihole.ping]: Pingzeit
ShortLegend[pihole.ping]: ms
Legend1[pihole.ping]: Pingzeit in ms
Legend2[pihole.ping]: Pingzeit in ms
Legend3[pihole.ping]: Maximal 5 Minute Maximum Pingzeit in ms
Legend4[pihole.ping]: Maximal 5 Minute Minimum Pingzeit in ms
LegendI[pihole.ping]: &nbsp;Max:
LegendO[pihole.ping]: &nbsp;Min:

Target[pihole.loss]: `/usr/bin/mrtg-ping-probe -t 42 -p loss/loss 192.168.178.43`
Title[pihole.loss]: Packet Loss Analysis
PageTop[pihole.loss]: <H1>Packet Loss Analysis</H1>
MaxBytes[pihole.loss]: 100
AbsMax[pihole.loss]: 101
WithPeak[pihole.loss]: ymwd
Options[pihole.loss]: gauge
Unscaled[pihole.loss]: dwmy
YLegend[pihole.loss]: % Packet Loss
ShortLegend[pihole.loss]: %
Legend1[pihole.loss]: % Packet Loss
Legend2[pihole.loss]: % Packet Loss
Legend3[pihole.loss]: Maximal 5 Minute % Packet Loss
Legend4[pihole.loss]: Maximal 5 Minute % Packet Loss
LegendI[pihole.loss]: &nbsp;% loss:
LegendO[pihole.loss]: &nbsp;% loss:

 

Das Wiederholt man jetzt für ca. 30 Clients so wie ich und hat dann eine Funktionierende Überwachung die alle 1 Minute pollt ob die Rechner noch im Netz sind.

Na dann mal ran an den Speck … erstmal alles benötigte für unser Vorhaben installieren:


apt-get install mrtg mrtg-ping-probe rrdtool librrds-perl snmp snmpd snmp-mibs-downloader apache2 libapache2-mod-perl2 libnet-snmp-perl libgd-gd2-perl

Während der Installation fragt das Setup für MRTG ob die Config Datei nur mit Root beschreibbar sein soll oder von jedem, die antwort ist an sich egal, wir nehmen jedoch der Sicherheit Halber die Option mit root only zugriff.

Kommen wir zu den wichtigen Dingen der Konfiguration der gerade installierten Module … zuallererst haben wir hier den

Apache2 Webserver

Da dieser Läuft sollte auf port 80 auch bereits die Standard Seite vom Apache verfügbar sein, der in diesem Fall über die Config Struktur des Apache Servers aufklärt. Diese Seite können wir soweit ignorieren, wir müssen uns zunächst erstmal um die aktivierung von PERL über das CGI Paket kümmern:


a2enmod cgi
service apache2 restart

Danach sollte man unter


/etc/apache2/sites-enabled/000-default.conf

Die Zeile “ Include conf-available/serve-cgi-bin.conf  “ aktivieren ( # entfernen am Anfang )
Auch nach diesem Speichern ist ein beherzter neustart des Apache2 Services fällig.

im Prinzip  ist es das auch schon für die Konfiguration für den Apache gewesen. Kommen wir also zu

MRTG und dem RRDtool

Zunächst ist es hilfreich den cronjob von MRTG anzupassen , von 5 auf 1 Minute:


nano /etc/cron.d/mrtg


*/1 *   * * *   root    if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg.cfg ] && [ -d "$(grep '^[[:space:]]*[^#]*[[:space:]]*WorkDir' /etc/mrtg.cfg | awk '{ print $NF }')" ]; then mkdir -p /var/log/mrtg ; env LANG=C /usr/bin/mrtg /etc/mrtg.cfg 2>&1 | tee -a /var/log/mrtg/mrtg.log ; fi


nano /etc/mrtg.cfg


Interval: 1


rm -r /var/mrtg/*.rrd

Die nächste Anpassung machen wir für den RRD Ordner als auch für die ganzen MRTG Config Files, hier werden also 2 neue Verzeichnisse benötigt.


mkdir /var/mrtg #für das  rrd Verzeichnis
mkdir /etc/mrtg #ffür die Config Dateien

Der Nächste Part bezieht sich auf die Einstellung von der

Routers2.cgi

Zunächst müssen wir die Routers2.cgi erstmal beziehen und dann auch noch installieren:


wget http://www.steveshipway.org/software/rrd/routers2-v2.23.tar.gz
tar xfv routers2-v2.23.tar.gz
cd routers2-v2.23/
perl install.pl

Während der Installation werden wir einige Fragen gefragt bezüglich pfaden auf dem RPI und anderen Dingen, der  einfachheit halber habe ich die korrekten Einstellungen vornotiert:


Document root? /var/www/html
CGI directory? /usr/lib/cgi-bin
MRTG config directory? /etc/mrtg
MRTG files [*.cfg]?
RRD directory [/tmp]? /var/mrtg
Perl executable [/usr/bin/perl]?
Configuration file [/var/mrtg/routers2.conf]?
Activate routingtable extensions [no]?
'usebigk' option [mixed]? no
auth option [none]?
Caching option [no]?
Can I mail [no]?

INSTALLING SOFTWARE

Perl is : /usr/bin/perl
MRTG files : /etc/mrtg/*.cfg
RRD files : /var/mrtg
Doc root : /var/www
CGI bin : /usr/lib/cgi-bin
Config file : /var/mrtg/routers2.conf
Routingtable: INACTIVE
Compact page: ENABLED
Caching : DISABLED
'usebigk' : no
Auth option : NONE
Mail Steve : no
Other options can be set later by modifying the Config file
Continue to install [no]? yes

Nach der Installation ist noch die Anpassung der Routers2.cgi config notwendig:


nano /var/mrtg/routers2.conf


charset = utf-8 #Für korrekte Zeichenanzeige
actuals = yes #Die Aktuellen Zahlen im Popup anzeigen
defaulttarget = summary #Zusammenfassung zuerst anzeigen
graphstyle = x3 #Das größte Bild anzeigen
graphtype = w #Die Wochenanzeige per Default zeigen
percentile = yes #Prozentuale Berechnung
sorder = l2 l2D x3 x3D #Nur große Bilder anbieten
showtotal = yes #Eine Gesammtlinie anzeigen
compact = no #Es werden keine Kompakten Graphen angezeigt.
daystart = 8 #Um einen Werktag hervorzuheben ( Startuhrzeit)
dayend = 18 #Ditto ( Enduhrzeit )
windowtitle = Title #Hier kann der Seitentitel definiert werden
bgcolour = #fffffff #Wenn das nicht eingegeben ist haben einige Graphen einen  lilanen Hintergrund
twinmenu = yes #ja da wir alle mit Widescreens heutzutage arbeiten
showfindbox = no #ist deaktiviert da wir nicht soviele Geräte überwachen.
6hour = always #wird hinzugefügt durch uns damit die 6 Stunden anzeige freigeschaltet wird

Nun muss noch die Standard mrtg.cfg angepasst werden.


nano /etc/mrtg.cfg


#Directory in which the RRD files will be stored
WorkDir: /var/mrtg
#Tells MRTG to use RRD instead of its own log format
LogFormat: rrdtool
#To have multiple instances of MRTG running to immediately pass through all targets
Forks: 4
#Use the configs in the mrtg subfolder (/etc/mrtg)
Include: mrtg/*.cfg

Erster Testlauf ohne angebundene Geräte

Dann rufen wir mal testweise http://PiHole/cgi-bin/routers2.cgi auf, Zeigt  das ganze eine Seite mit „no valid target is selected“ sind wir richtig und das Script funktioniert. da wir aber noch verifizieren wollen ob die Konfiguration soweit hinhaut rufen wir folgende Seite auf http://PiHole/cgi-bin/routers2.cgi?page=verify . Ist hier alles soweit in Ordnung ist das Grund Setup abgeschlossen ( Yay ).

Man könnte jetzt über viele Wege configurationen anlegen für neue Geräte, ich Persönlich wollte sowieso mrtg-ping-probe nutzen und verzichtete daher über snmp traps als auch den cfgmaker von MRTG, da dieser leider nicht die nötigen Einträge unterstützt hätte.

Im Nächsten Beitrag gehe ich auf das Verwendete MRTG Template für alle Clients ein.

Wir errinern uns an meine Worte: Vieles geht, und vielmehr nicht.

Eigendlich war die Erste aufgabe eine Leichte, habe ich sie ja bisher mit meinem Standard Linux Server und einem Docker Container bewerkstelligt mi Quasi 0 Aufwand dahinter:

Netzwerkmonitoring … im allgemeinem und eigendlich NUR! das Anpingen von Hosts im lokalen LAN und dieses dann in einem GRAPH erfasst damit ich einen überblick über die Up & Downtimes der Systeme im LAN habe und das am besten auch über längere Zeiträume hinweg.

Meine Ursprüngliche Lösung war Cacti, welches zwar etwas viel Configurationsaufwand für diese Aufgabe bedeutet, aber wenn es mal läuft dann läufts … dachte ich zumindest.

Erster Check -> Cacti und alle Dependencies sind als ARM Version verfügbar , hätte mich auch gewundert wenn nicht 😀
Installation -> Cacti und Dependencies installieren ohne Fehler
Zugriff -> Cacti ist wie erwartet auf dem Vorgesehenen Port erreichbar und lässt sich Grundeinrichten ( Einloggen / User PW / HOSTs )

Beim einrichten der Hosts wurde mir erwartungsgemäß von Cacti ein Ping angezeigt, da das Anvisierte Netzwerkgerät online war und gemessen werden konnte. Aus mir nicht nachvollziehbaren gründen Endet von Cacti GENAU an der Stelle sämtliche Funktionalität, der für den ICMP Ping eingerichtete Graph zeigte NICHTS an, also rein garnichts, keine Werte obwohl das System online ist und von anderen Systemen Pingbar ( im Cacti Dashboard wurde sogar der Ping angezeigt ).

Eine Kurze Recherche Zeigt das der Ping Graph über eine PL datei geladen wird, Perl ist installiert und funktioniert, alle Module die ich auf dem Debian Server bei mir hab sind auch hier vorhanden , und dennoch keine Funktion für das Script was aufgerufen wird, ich prüfen erneut manuell, Wert egal ob der Host im Lokalen Netz oder im Internet ist -> NaN … grrr Natürlich gibt es ausgerechnet zu diesem Modul, was das einzigste ist was man nutzen kann um eine Online Überwachung durchzuführen ohne überall Software zu installieren in Cacti ist keine Berichte, weil das kaum einer Nutzt -.- Sfz.

Wenn es doch einen Garantierten Weg geben würde das Egal mit welchem Unterbau eine Software funktioniert … wie bei Docker … moment, gibbet doch auch für den RPI , kurz gesucht und besätigt als auch Installiert.

Hier kommt die Krux … die Docker Packages für x86 / amd64 funktionieren nicht auf dem RPI ARM … es müssen Docker Packages genutzt werden die nur aus Scripten / configs bestehen ODER binarys beinhalten die für ARMHF geschrieben sind … Ok den Plan mein Dockerimage vom großen Server zu nutzen rückt wieder in die Ferne … vielleicht hat ja einer bereits ein cacti Image gebastelt für den PI … RPI-Cacti bei Docker im Hub gesucht und gefunden … viele Sterne und Downloads , na das sieht gut aus … Gnah kein Komplett Paket … ich muss also die MYSQL … öhm MARIADB? ( wieso zum Teufel ein MYSQL Fork?! ) seperat als Dockerimage anwerfen … nach einer myade an Konfigurationsanpassungen habe ich dann auch mal geschafft das beide Komponenten Kommunizeren ( ich musste ein Docker Image installieren mit PHPMYADMIN! ) und funktionieren … Und schwupps stehe ich wieder vor dem gleichen Problem wie ohne Docker … der Dashboard Ping läuft aber das SCRIPT was gepollt wird zum Pingen will partout nicht eine Abfrage rauswürgen …

Alternativen zu Cacti gibt es viele … Zabbix … Nagios … usw … ein angepasstes Docker Image nach dem Anderen wanderte über den PI … kaum eines funktionierte, und die die funktionierten boten nicht den Gewünschten Funktionsumfang. Es fehlten Ping funktionen, die möglichkeit Grafen darzustellen oder generell der Zwang eine Client Komponente auf jedem System zu isntallieren oder sich auf eventuell vorhandene SNMP Zugänge zu verlassen… Ich musste auch viele Tools auslassen zum Testen, möchte auch garnicht alle nennen … zuviel Zeit und Frust steckt dahinter, um einen eventuellen Kandidaten zur Lösung meiner Probleme zu finden nur um Herauszufinden das es Kein Port für ARMHF / RPI und / oder ein angepasstes Docker image für den PI gibt …

Ich lies das ganze ein paar Tage liegen und ärgerte mich richtig böse, wie toll doch die ganzen Modernen Tools sind, und kein Einziges funktioniert wo doch damals zu meiner Linux Start Zeit alles mit ein paar kleinen Configs und Apache / RRDTOOL / MRTG in wenigen Stunden brauchbare Ergebnisse lieferte … Moment mal , was hab ich da gedacht … wenn das damals ging gehts heute noch … also mal bei Tobi Oetiker auf der Seite geschaut … MRTG wird zwar nichtmehr so aktiv gepflegt ist aber wohl weiterhin existent und alle benötigten Tools liegen im RPI SW Pool vor.

Da ich ja durchaus mehr als ein Gerät überwachen will un durchaus auch viele Graphen erzeuge, wollte ich eine Lösung haben die mir zumindest halbwegs aufgeräumt ein Webinterface bietet … so kam ich zu einem alten Freund … routers2.cgi … ein Frontend für MRTG … was selbstständig aus RRD Daten ohne GD ressourcen schonend und flott  Grafen zaubert und das ganze in einem Gut aufgeräumten Frontend. Machen wirs kurz … die Einrichtung dauerte ca. 1 1/2 stunden, danach war es Stabil… und schon haben wir das Nächste Thema 😀