Überwachung linuxbasierter Server: Unterschied zwischen den Versionen

Aus FHEMWiki
(völlig unfertiger Stub)
 
K ("source" Tag auf "syntaxhighlight" umgestellt.)
 
(22 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{Baustelle}}  
{{Baustelle}}  
Beachte: Artikel derzeit fragmentarisch, daher NICHT nutzbar.
[[Datei:2019-03-13-serverueberwachung-1.jpg|right|500px]]


In diesem Artikel wird im Sinne eines '''proof of concept''' die Möglichkeit der Überwachung vieler linuxbasierter Server auf ausstehende Updates, Plattenplatz usw. beschrieben.  
In diesem Artikel wird im Sinne eines '''proof of concept''' die Möglichkeit der Überwachung vieler linuxbasierter Server auf ausstehende Updates, Plattenplatz usw. beschrieben.  
 
<!-- Falls das Inhaltsverzeichnis komplett darunter starten soll diese und die übernächste Zeile löschen...
<br clear=all>
-->
==Vorbemerkung==
==Vorbemerkung==
Es gibt bereits mehrere, recht ausgefeilte Lösungen zur Überwachung von Servern: Angefangen von Nagios  
Es gibt bereits mehrere, recht ausgefeilte Lösungen zur Überwachung von Servern: Angefangen von Nagios  
bis hin zum Modul [[sysmon]]. Dem soll keine weitere Lösung hinzugefügt werden, es geht in diesem Projekt '''nicht''' um die minutengenaue Überwachung von Serverparametern. Hier geht es um einen '''täglichen''' Status aller Server im Hausnetz. Dabei ist der Fokus gelegt auf minimale Belastung der zu überwachenden Server und des Netzes.
bis hin zum Modul [[SYSMON]]. Dem soll keine weitere Lösung hinzugefügt werden, es geht in diesem Projekt '''nicht''' um die minutengenaue Überwachung von Serverparametern. Hier geht es um einen '''täglichen''' Status aller Server im Hausnetz: Liegen Updates an, ist noch Plattenplatz frei? - Dabei ist der Fokus gelegt auf minimale Belastung der zu überwachenden Server (die im Folgenden "Clients" genannt werden) und des Netzes.
 
==Installation==


==Begriffsbestimmung==
In diesem Artikel ist "Server" das Gerät, auf dem FHEM läuft. Client/Clients sind Maschinen, die linuxbasiert (Debian, Ubuntu, Raspian) sind, beispielsweise kleine, leistungsschwache Raspberry Pi Zero. Obwohl auf diesen Clients ein Webserver erforderlich ist, installiert sein muss, werden sie der sprachlichen Klarheit wegen als "Client" benannt.
==Installation auf den Clients==
Jeder Client muss künftig zwei Bedingungen erfüllen: Erstens muss er täglich eine JSON-Datei seines Zustands bereitstellen. Zweitens muss ein Webserver diese Datei dem Server ausliefern können.
===Installation Webserver auf Clients===
Sofern noch kein Webserver installiert ist, sollte bei kleinen, schwachen Geräten ein möglichst leichtgewichtiger, ressourcensparender Webserver installiert werden. Ein Beispiel wird im Artikel [[Webserver auf Raspberry]] beschrieben, dort sind weitere Alternativen benannt. - Der Webserver sollte von /var/www ausliefern, dort ist händisch sodann ein Unterverzeichnis "html" anzulegen.
===Installation JSON-Script auf Clients===
Danach muss jeder Client in die Lage versetzt werden, eine JSON-Datei mit den tagesbezogenen Zustandsdaten des Client bereitzustellen. Dafür werden keinerlei Java oder Javascript (und im Sinne der Schlankheit auch nicht diesbezügliche riesige Pakete) benötigt. Das folgende bash-Script wird als status-pruefen unter /etc/cron.daily abgelegt, es erstellt täglich eine JSON-Datei unter /var/www/html, welche durch den Webserver auf Anfrage ausgeliefert wird:
<syntaxhighlight lang=perl>
#!/bin/bash
# Aufbau:
# ab V0.2 JSON
#
# 2018-12-18 V0.5b me nur die 1. IP nehmen
# 2018-12-14 V0.5a me Plattenbelegung Root-Partition
# 2018-12-13 V0.3 me Filterung Temperatur Debian, Leerzeichen IP korrigiert
#                    leere Variabeln nicht ausgeben
# 2018-11-22 V0.3 me Vereinheitlichung der JSON-Variablen
# 2018-11-19 V0.2 me Umbau auf JSON
#
# Diese Datei muss in /etc/cron.daily
#  Die Datei darf keine Extension haben!
#
# allgemeine Definitionen
#
# Root-Verzeichnis des Webservers - Name der Statusdatei
# Verzeichnis ggf. anpassen!
#
ZIEL=/var/www/html/status2fhem.txt
# Ab hier nichts veränder!
VERS="V0.5b"
DATE=`date +%Y-%m-%d`
HOSTNAME=`/bin/hostname`
SYS1=`/bin/cat /etc/issue`
SYS2=`/bin/uname -a`
IP1=`/bin/hostname -I | awk '{print $1}'`
IPwlan0=`/sbin/ip addr show wlan0 | /bin/grep -vw "inet6" | /bin/grep "global" | /bin/grep -w "inet" | /usr/bin/cut -d/ -f1 | /usr/bin/awk '{ print $2 }'`
UPDATE=`/usr/bin/apt-get dist-upgrade -qq -y -s | /bin/grep '^Inst ' | /usr/bin/wc -l`
# gilt nur für RPi. Hier fehlt eine Weiche (weil es auch noch Debian und Ubuntu gibt)!
#
if [ -x /usr/bin/vcgencmd ]
  then RPitemp=`/usr/bin/vcgencmd measure_temp |/bin/sed -e s/temp=// |/bin/sed -e s/\'C//`
fi
# für Linux-like Systeme wie Debian muss es der Befehl "sensors" sein. Hier für APU, da ist die Ausgabe von sensors anders
# das geht schief, wenn lm-sensors installiert ist, aber mit Fehler zurück kommt
#
if [ -x /usr/bin/sensors ]
  then APUtemp=$( /usr/bin/sensors | awk '/temp1/ {print $2}' | /bin/sed -e s/\+// | /bin/sed -e s/°C// )
fi
# Belegung der Root-Partition in %:
PLATTE=`/bin/df --output=pcent / | /usr/bin/tail -1 | /bin/sed -e s/\ //g | /bin/sed -e s/\%//`
# Ende der Befehle
# testweise: Wann wird das Script eigentlich aufgerufen?
/bin/cp /dev/null /tmp/timestamp
# das JSON bauen:
echo "{" > $ZIEL
echo "  "\"date\"\: \"$DATE\", >> $ZIEL
# etwas wild: hinten 6 Zeichen Unfug abschneiden:
echo "  "\"sys-state\"\: \"${SYS1::-6}\", >> $ZIEL
echo "  "\"sys-detail\"\: \"$SYS2\", >> $ZIEL
echo "  "\"hostname\"\: \"$HOSTNAME\", >> $ZIEL
if [ -n "$IP1" ] ; then echo "  "\"IP\"\: \"$IP1\", >> $ZIEL ; fi
if [ -n "$IPwlan0" ] ; then echo "  "\"IPwlan0\"\: \"$IPwlan0\", >> $ZIEL ; fi
echo "  "\"update\"\: $UPDATE, >> $ZIEL
if [ $RPitemp ]
  then echo "  "\"temp\"\: $RPitemp, >> $ZIEL
fi
if [ $APUtemp ]
  then echo "  "\"temp\"\: $APUtemp, >> $ZIEL
fi
echo "  "\"platten\"\: $PLATTE, >> $ZIEL
echo "  "\"version\"\: \"$VERS\" >> $ZIEL
echo "}" >> $ZIEL
</syntaxhighlight>
==Installationen auf dem Server==
...
...
===FHEM Scripte und Devices===
Sofern eine IP 24 Stunden nicht erreichbar war, wird die entsprechende Device automatisch gelöscht:
<syntaxhighlight lang="perl">
##########
# alte IP-Devices rausschmeissen
# https://forum.fhem.de/index.php/topic,94475.0.html
#
sub check_dead() {
  my $maxAge  = 86400;
  my @checkDev = devspec2array("192.168.*");
  my $alive    = 0;
  foreach my $d (@checkDev){
    $alive = 0;
    foreach my $r (keys %{$defs{$d}{READINGS}}){
      my $age = ReadingsAge($d,$r,0);
      $alive = 1 if ($age < $maxAge);
      Debug "device: $d reading: $r age: $age";
    }
#    Debug "delete $d" unless $alive;
    CommandDelete(undef,$d) unless $alive;
  }
}
</syntaxhighlight>
===[[FTUI]] Kachel===


===Fakultative Installation auf dem Server===
...
...


==Danksagung==
==Danksagung==
Bei der Umsetzung der Idee halfen -manchmal ohne es zu wissen- mehrere Teilnehmer des FHEM-Forums, denen der Primärautor des Beitrags für ihre uneigennützige, freundliche Hilfe zu Dank verpflichtet ist.
Bei der Umsetzung der Idee halfen -manchmal ohne es zu wissen- mehrere Teilnehmer des FHEM-Forums, denen der Primärautor des Beitrags für ihre uneigennützige, freundliche Hilfe zu Dank verpflichtet ist.

Aktuelle Version vom 30. September 2021, 12:46 Uhr


Clock - Under Construction.svg An dieser Seite wird momentan noch gearbeitet.


Beachte: Artikel derzeit fragmentarisch, daher NICHT nutzbar.

2019-03-13-serverueberwachung-1.jpg

In diesem Artikel wird im Sinne eines proof of concept die Möglichkeit der Überwachung vieler linuxbasierter Server auf ausstehende Updates, Plattenplatz usw. beschrieben.

Vorbemerkung

Es gibt bereits mehrere, recht ausgefeilte Lösungen zur Überwachung von Servern: Angefangen von Nagios bis hin zum Modul SYSMON. Dem soll keine weitere Lösung hinzugefügt werden, es geht in diesem Projekt nicht um die minutengenaue Überwachung von Serverparametern. Hier geht es um einen täglichen Status aller Server im Hausnetz: Liegen Updates an, ist noch Plattenplatz frei? - Dabei ist der Fokus gelegt auf minimale Belastung der zu überwachenden Server (die im Folgenden "Clients" genannt werden) und des Netzes.

Begriffsbestimmung

In diesem Artikel ist "Server" das Gerät, auf dem FHEM läuft. Client/Clients sind Maschinen, die linuxbasiert (Debian, Ubuntu, Raspian) sind, beispielsweise kleine, leistungsschwache Raspberry Pi Zero. Obwohl auf diesen Clients ein Webserver erforderlich ist, installiert sein muss, werden sie der sprachlichen Klarheit wegen als "Client" benannt.

Installation auf den Clients

Jeder Client muss künftig zwei Bedingungen erfüllen: Erstens muss er täglich eine JSON-Datei seines Zustands bereitstellen. Zweitens muss ein Webserver diese Datei dem Server ausliefern können.

Installation Webserver auf Clients

Sofern noch kein Webserver installiert ist, sollte bei kleinen, schwachen Geräten ein möglichst leichtgewichtiger, ressourcensparender Webserver installiert werden. Ein Beispiel wird im Artikel Webserver auf Raspberry beschrieben, dort sind weitere Alternativen benannt. - Der Webserver sollte von /var/www ausliefern, dort ist händisch sodann ein Unterverzeichnis "html" anzulegen.

Installation JSON-Script auf Clients

Danach muss jeder Client in die Lage versetzt werden, eine JSON-Datei mit den tagesbezogenen Zustandsdaten des Client bereitzustellen. Dafür werden keinerlei Java oder Javascript (und im Sinne der Schlankheit auch nicht diesbezügliche riesige Pakete) benötigt. Das folgende bash-Script wird als status-pruefen unter /etc/cron.daily abgelegt, es erstellt täglich eine JSON-Datei unter /var/www/html, welche durch den Webserver auf Anfrage ausgeliefert wird:

#!/bin/bash

# Aufbau:
# ab V0.2 JSON
#
# 2018-12-18 V0.5b me nur die 1. IP nehmen
# 2018-12-14 V0.5a me Plattenbelegung Root-Partition
# 2018-12-13 V0.3 me Filterung Temperatur Debian, Leerzeichen IP korrigiert
#                    leere Variabeln nicht ausgeben
# 2018-11-22 V0.3 me Vereinheitlichung der JSON-Variablen
# 2018-11-19 V0.2 me Umbau auf JSON
#

# Diese Datei muss in /etc/cron.daily
#  Die Datei darf keine Extension haben!

#
# allgemeine Definitionen
#

# Root-Verzeichnis des Webservers - Name der Statusdatei
# Verzeichnis ggf. anpassen!
#
ZIEL=/var/www/html/status2fhem.txt

# Ab hier nichts veränder!
VERS="V0.5b"

DATE=`date +%Y-%m-%d`

HOSTNAME=`/bin/hostname`

SYS1=`/bin/cat /etc/issue`

SYS2=`/bin/uname -a`

IP1=`/bin/hostname -I | awk '{print $1}'`

IPwlan0=`/sbin/ip addr show wlan0 | /bin/grep -vw "inet6" | /bin/grep "global" | /bin/grep -w "inet" | /usr/bin/cut -d/ -f1 | /usr/bin/awk '{ print $2 }'`

UPDATE=`/usr/bin/apt-get dist-upgrade -qq -y -s | /bin/grep '^Inst ' | /usr/bin/wc -l`

# gilt nur für RPi. Hier fehlt eine Weiche (weil es auch noch Debian und Ubuntu gibt)!
# 
if [ -x /usr/bin/vcgencmd ]
  then RPitemp=`/usr/bin/vcgencmd measure_temp |/bin/sed -e s/temp=// |/bin/sed -e s/\'C//`
 fi

# für Linux-like Systeme wie Debian muss es der Befehl "sensors" sein. Hier für APU, da ist die Ausgabe von sensors anders
# das geht schief, wenn lm-sensors installiert ist, aber mit Fehler zurück kommt
#
if [ -x /usr/bin/sensors ]
  then APUtemp=$( /usr/bin/sensors | awk '/temp1/ {print $2}' | /bin/sed -e s/\+// | /bin/sed -e s/°C// )
 fi

# Belegung der Root-Partition in %:
PLATTE=`/bin/df --output=pcent / | /usr/bin/tail -1 | /bin/sed -e s/\ //g | /bin/sed -e s/\%//`

# Ende der Befehle

# testweise: Wann wird das Script eigentlich aufgerufen?
/bin/cp /dev/null /tmp/timestamp

# das JSON bauen:

echo "{" > $ZIEL
echo "  "\"date\"\: \"$DATE\", >> $ZIEL
# etwas wild: hinten 6 Zeichen Unfug abschneiden:
echo "  "\"sys-state\"\: \"${SYS1::-6}\", >> $ZIEL
echo "  "\"sys-detail\"\: \"$SYS2\", >> $ZIEL
echo "  "\"hostname\"\: \"$HOSTNAME\", >> $ZIEL
if [ -n "$IP1" ] ; then echo "  "\"IP\"\: \"$IP1\", >> $ZIEL ; fi
if [ -n "$IPwlan0" ] ; then echo "  "\"IPwlan0\"\: \"$IPwlan0\", >> $ZIEL ; fi
echo "  "\"update\"\: $UPDATE, >> $ZIEL
if [ $RPitemp ]
  then echo "  "\"temp\"\: $RPitemp, >> $ZIEL 
 fi
if [ $APUtemp ]
  then echo "  "\"temp\"\: $APUtemp, >> $ZIEL
 fi
echo "  "\"platten\"\: $PLATTE, >> $ZIEL
echo "  "\"version\"\: \"$VERS\" >> $ZIEL
echo "}" >> $ZIEL

Installationen auf dem Server

...

FHEM Scripte und Devices

Sofern eine IP 24 Stunden nicht erreichbar war, wird die entsprechende Device automatisch gelöscht:

##########
# alte IP-Devices rausschmeissen
# https://forum.fhem.de/index.php/topic,94475.0.html
# 

sub check_dead() {
  my $maxAge   = 86400;
  my @checkDev = devspec2array("192.168.*");
  my $alive    = 0;
 
  foreach my $d (@checkDev){
    $alive = 0;
    foreach my $r (keys %{$defs{$d}{READINGS}}){
      my $age = ReadingsAge($d,$r,0);
      $alive = 1 if ($age < $maxAge);
      Debug "device: $d reading: $r age: $age";
    }
#    Debug "delete $d" unless $alive;
    CommandDelete(undef,$d) unless $alive;
  }
}


FTUI Kachel

Fakultative Installation auf dem Server

...

Danksagung

Bei der Umsetzung der Idee halfen -manchmal ohne es zu wissen- mehrere Teilnehmer des FHEM-Forums, denen der Primärautor des Beitrags für ihre uneigennützige, freundliche Hilfe zu Dank verpflichtet ist.