Tag Archive: systemstatus

atop: Das top mit Rückblick

Atop

Das Paket „atop“ aus den Paketquellen Ubuntus sowie Debians, in jeder Version, ist relativ veraltet, wohl auch sehr selten benutzt, was sehr schade ist.

Für die Netzwerküberwachung arbeitete „atop“ bislang mit einem Kernel-Patch, der für neuere Kernel lange nicht mehr zur Verfügung steht.
Seit Versionen größer 2 hingegen, stellte der Entwickler als neues Konzept auf ein Kernel-Modul „netatop“ um. Daher installiere ich beide Komponenten aus dem Quellcode manuell.

Das Tool ist in seiner Funktion „top“ sehr ähnlich. Jedoch treten viele Probleme nicht genau zu dem Zeitpunkt auf, in dem der Admin den Task-Manager geöffnet hat.
An dieser Stelle kommt der besondere Vorteil des Tools „atop“ zu tragen, dessen Daemon das System in einem festgelegten Intervall überwacht.

Installation

Vorbereitend installiere ich die Abhängigkeiten:

apt-get install zlib1g-dev linux-headers-`uname -r` build-essential debhelper libncurses5-dev

Damit das Init-Script für Atop funktioniert, erstelle ich zuerst das Verzeichnis für den Lock-State:

sudo mkdir /var/lock/subsys

Anschließend wird „Bash“ zur Standard-Shell befördert, da „Dash“ nicht mit dem Befehl „let“ arbeiten kann.
Folgender Befehl fragt, ob „Dash“ als Standard-Shell benutzt werden soll, hier wähle ich „Nein“. „Bash“ wird fortan benutzt:

dpkg-reconfigure dash

Natürlich könnte auch einfach „/bin/sh“ im Script ersetzt werden, jedoch halte ich es für sinnvoll, „Dash“ nie als Standard-Shell zu benutzen.

sudo dpkg-reconfigure dash

Nun die Quell-Dateien nach ~/build herunterladen und entpacken:

mkdir ~/build && cd ~/build
wget -q -O - http://www.atoptool.nl/download/atop-2.0.2.tar.gz | tar xvzf -
wget -q -O - http://www.atoptool.nl/download/netatop-0.3.tar.gz | tar xvzf -

„Atop“ kompilieren und installieren:

cd ~/build/atop*
sudo make && sudo make install

„Netatop“ Kernel-Modul kompilieren, installieren und beide Dienste starten:

cd ~/build/netatop*
sudo make && sudo make install && sudo service netatop start && sudo service atop start

Das Modul sollte jetzt geladen sein, das kann schnell und einfach überprüft werden:

lsmod | grep netatop

Die Ausgabe darf nicht leer sein.

Alle Daten des „atop“-Dienstes werden nach „/var/log/atop“ geschrieben. Dateien älter als vier Wochen werden täglich gesucht und gelöscht.
Der Systemstatus wird in einem Intervall von 600 Sekunden geprüft und gespeichert.
Diese Zeit kann in der Kopfzeile der Datei „/etc/atop/atop.daily“ angepasst werden.
Ein „netatop“-Dienst ist notwendig, um die Schnittstelle für „atop“ zum Netzwerk dauerhaft zur Verfügung zu stellen.

Funktionsweise und Beispiele

Vorab die Echtzeit-Überwachung, ähnlich „top“.
Zu Beginn wird immer erst eine kurze Übersicht der Daten seit Systemstart angezeigt! Diese Übersicht schließt nach dem ersten Aktualisierungsintervall.
Im Abstand von 10 Sekunden wird die Ansicht zum Systemstatus aktualisiert, dies ist der Standardwert des Intervalls („t“ drücken, um sofort zu aktualisieren). Es werden nur aktive Prozesse angezeigt:

atop

Alle Prozesse anzeigen und die Ansicht alle 2 Sekunden aktualisieren:

atop -a 2

Netzwerkanalyse mit Aktualisierung alle 5 Sekunden:

atop -n 5

Netzwerkanalyse mit Startbefehl der Anwendung, aktualisiert jede Sekunde:

atop -nc 1

Das Auswerten der Logs ist, wie bereits angesprochen, die interessanteste Funktion. Um aufgezeichnete Aktivitäten zu untersuchen, hänge ich „-r Logfile.log“ an:

atop -r /var/log/atop/atop_2014XXXX

Gut: Mit Eingabe von „t“ sowie „T“, gehe ich zeitlich in der Aufzeichnung vor und zurück. Die Schritte entsprechen logischerweise dem Intervall der Konfiguration aus „/etc/atop/atop.daily“.
Besser: Mit „-b“ und -e“ steht es mir frei, einen Zeitraum des Tages auszuwählen.
Anzeigen der Aufnahme vom 1. März, begrenzt auf den Zeitraum 13:00 bis 15:00 Uhr:

atop -r /var/log/atop/atop_20140301 -b 13:00 -e 15:00

Obiges, jedoch zusätzlich Netzwerkaktivität und Startbefehl anzeigen:

atop -r /var/log/atop/atop_20140301 -b 13:00 -e 15:00 -nc

Alle Parameter finden sich selbstverständlich in der „man page“.
Jeder Paramter kann auch im Programm aktiviert werden. Beispielsweise die Taste „n“ für „-n“ (…).

Systemstatus mit Collectd und Collectd Graph Panel

Voraussetzung, Umfeld und Vorwort

„Collectd“ ist eine Software, um den Status von Hard- und Software zu erfassen. „Collectd“ kann diese Daten in Form von RRD-Dateien ablegen und zur weiteren Verarbeitung zur Verfügung stellen.

CGP Beispiel
CGP Beispiel
An dieser Stelle kommt das „Collectd Graph Panel“ (CGP) zum Einsatz. CGP greift auf die bereitgestellten Dateien zu und erstellt aussagekräftige Graphen zur Systemanalyse über einen bestimmten Zeitraum.

Von folgenden Umständen gehe ich bei der Einrichtung des CGP aus:

  • Funktionsfähiger Web-Server mit PHP-Unterstützung
  • Debian/Ubuntu (Server) OS
  • Webroot-Verzeichnis des CGP: /var/www/cgp
  • PHP- und Web-Server-Benutzer: www-data

Welche Plugins des „Collectd“ zum CGP kompatibel sind, kann zum Beispiel festgestellt werden, indem ein Blick in das GIT-Repository geworfen wird.

Collectd installieren/konfigurieren

Collectd

Das Paket „collectd“ installiert alle für die spätere Funktion von CGP benötigten Abhängigkeiten:

sudo apt-get install collectd

Der Pfad zur Konfigurationsdatei lautet „/etc/collectd/collectd.conf“.
Die Grundeinstellung kann beibehalten werden. Es steht jedem frei, die (weitgehend) selbsterklärenden Einträge zu verändern.
„BaseDir“ setze ich sicherheitshalber fest, um Komplikationen mit CGP zu vermeiden:

#Hostname „localhost“
FQDNLookup true
BaseDir „/var/lib/collectd“
#PluginDir „/usr/lib/collectd“
#TypesDB „/usr/share/collectd/types.db“ „/etc/collectd/my_types.db“
#Interval 10
#Timeout 2
#ReadThreads 5

In selbiger Datei werden im Anschluss an die Grundeinstellung auch die Plugins konfiguriert.
Das Muster ist immer das gleiche:

LoadPlugin XYZ

    EINSTELLUNGEN

Bereits eingeschaltete Plugins erfordern in der Regel keine Konfiguration.

Collectd Beispielkonfiguration: Lokaler Nginx-Server

Als kleines Beispiel für ein Plugin mit notwendiger Konfiguration, wähle ich das Plugin „Nginx“.
In der Konfigurationsdatei „/etc/collectd/collectd.conf“ folgende Anpassungen durchführen:

LoadPlugin nginx

    URL "http://127.0.0.7/ngxstatus"

Eine neue Site für Nginx erstellen oder eine vorhandene öffnen, dort eine neue Location anlegen:

location /ngxstatus {
    stub_status on;
    allow 127.0.0.1;
    deny all;
}

Nach einem Neustart des Nginx ist das Plugin auch schon funktionsfähig und rudimentär nach außen geschützt.
Nginx muss mit „–with-http_stub_status_module“ konfiguriert worden sein, damit „stub_status“ eingeschaltet werden kann. Durch den Befehl „nginx -V“ kann festgestellt werden, ob das Modul zur Verfügung steht.

PHP-Anpassungen

Es folgen die Anpassungen für PHP, um das CGP korrekt nutzen zu können.
„date.timezone“ ist nicht kritisch, verhindert aber nervige Fehler in den Log-Dateien – nicht nur im Zusammenhang mit CGP (Stichwort: „strptime“).
In jedem Fall darf die Verwendung von „shell_exec“ nicht verboten werden! Um etwas mehr Sicherheit zu erreichen, empfehle ich daher den Einsatz von „open_basedir“ sowie (im Verlauf) „Hypertext Access“.

PHP via FPM

In Anlehnung an einen vorherigen Artikel.
Wird PHP via PHP-FPM ausgeführt, kann ein eigener Socket für die Anwendung erstellt werden, etwa nach diesem Beispiel:

sudo nano /etc/php5/fpm/pool.d/cgp.conf

Der Inhalt könnte so aussehen:

[cgp]
listen = /var/run/php5-fpm-cgp.sock
listen.backlog = 4096
user = www-data
group = www-data
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 4
pm.max_requests = 10
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp
php_admin_value[open_basedir] = /var/www/cgp:/tmp:/var/lib/collectd/rrd:/usr/bin
php_admin_value[date.timezone] = "Europe/Berlin"
php_admin_value[disable_functions] = 

Andere PHP-Module

Für jede andere Konfiguration muss sicher gestellt sein, dass folgende Einstellungen in der entsprechenden „php.ini“ definiert sind („/tmp“ der eigenen Konfiguration anpassen):

date.timezone= "Europe/Berlin"
open_basedir = /var/www/cgp:/tmp:/var/lib/collectd/rrd:/usr/bin

Collectd Graph Panel installieren/konfigurieren

Zur Zeit ist Version 0.4.1 aktuell. Ein Blick auf die Seite des Entwicklers schadet nicht.
Das Paket herunterladen, entpacken, Besitzer anpassen (gegebenenfalls „sudo apt-get install unzip“):

cd ~
wget -O cgp.zip https://github.com/pommi/CGP/archive/v0.4.1.zip
unzip cgp.zip
rm cgp.zip
mv CGP-0.4.1 /var/www/cgp
chown -R www-data: /var/www/cgp

Bevor die Konfiguration vorgenommen wird, wird die Version des „Collectd“ festgestellt:

collectd -h

Im Fall von Debian Wheezy erhalte ich folgende Ausgabe: collectd 5.1.0, http://collectd.org/ – ergo Version 5.x. Hinweis: Ubuntu 12.04 LTS benutzt Version 4.x.
Außerdem kann es nicht schaden sicherzustellen, dass die Binärdatei „rrdtool“ unter „/usr/bin“ zu finden ist:

which rrdtool

Die Konfigurationsdatei im Anschluss zur Bearbeitung öffnen:

sudo nano /var/www/cgp/conf/config.php

Folgende Einträge überprüfen und konfigurieren:

$CONFIG['version'] = 5; # Oder eben 4
$CONFIG['datadir'] = '/var/lib/collectd/rrd'; # Basedir des "Collectd", +rrd
$CONFIG['rrdtool'] = '/usr/bin/rrdtool';

Alle weiteren Einstellungen können natürlich ebenfalls verändert werden. Für diesen Artikel sind sie jedoch nicht relevant.
Die Konfiguration ist soweit beendet.

CGP „absichern“

Eine Möglichkeit unter Unzähligen ist der Klassiker via „htaccess“ („Hypertext Access“). Um die, naja, Datenbank für die Benutzer anzulegen, kann sich ungeachtet des Web-Servers an den „apache2-utils“ bedient werden – es wird NICHT Apache installiert:

sudo apt-get install apache2-utils

CGP via Apache

sudo nano /var/www/cgp/.htaccess

Folgenden Inhalt ergänzen:

AuthName "CGP Access"
AuthType Basic
AuthUserFile /etc/htpasswd.cgp
require valid-user

Anschließend den Benutzer generieren und ein Passwort setzen:

htpasswd -c /etc/htpasswd.cgp BENUTZERNAME

…und Apache „reloaden“:

sudo service apache2 reload

CPG via Nginx

Nginx bedarf einer Veränderung der Site-Konfiguration für die Zugriffseinstellungen. Gleichzeitig können die mitgebrachten Einträge der „.htaccess“-Datei direkt an Nginx angepasst werden:

sudo nano /etc/nginx/sites-enabled/cgp-site-name

Folgendes ergänzen:

server {
    location / {
        [...]
    }
    location ~ ^/.git(ignore|/) {
        return 403;
    }
    [...]
    auth_basic "CGP Access";
    auth_basic_user_file /etc/htpasswd.cgp;
    autoindex off;
}

Anschließend den Benutzer generieren und ein Passwort setzen:

htpasswd -c /etc/htpasswd.cgp BENUTZERNAME

…und Nginx „reloaden“:

sudo service nginx reload

Testen und Schlusswort

Nun kann das CGP aufgerufen- und, falls der „Collectd“ schon fleißig war, einige schöne Graphen bewundert werden.