Mal schnell einen Blick auf die Leistungsdaten eines Linux-Servers werfen. Theoretisch kein Problem, doch wo liegt die Ursache für eine schlechte Performance in den letzten Stunden?
Mit Software wie htop
lässt sich zwar die gegenwärtige Situation bzgl. System-Load, aktiver Prozesse, Speicherverbrauch überblicken, aber eine historische Betrachtung ist nicht möglich. Dann hilft nur noch ein Blick in Logdateien, um eventuelle Probleme aufzuspüren.
Inhalt
Mehr als Prozessmanagement
Aber auch ohne eine größere Monitoring-Lösung, lassen sich Daten über Systemperformance und Dienste aufzeichnen und auf einen Blick einsehen. Dafür nutze ich die freie, quelloffene Software Monitorix.
Die leichtgewichtige Software besteht aus einem Perl-Daemon, einem CGI-Script und bringt einen eingebauten Webserver zur Darstellung mit. In der aktuellen Version vom September 2017 lassen sich eine große Anzahl Systemparameter und zusätzliche Dienste unkompliziert überwachen.
Für RedHat-, Debian- und BSD-basierende Linux-Distributionen gibt es entsprechende Pakete in den (offiziellen) Repos. In der sehr guten Dokumentation werden die Paketquellen jeweils genannt.
Installation auf CentOS
Auf einem CentOS-System genügt es, das EPEL-Repository als Paketquelle verfügbar zu machen. Ist dieses noch nicht auf dem jeweiligen System eingebunden, kann es mit folgendem Befehl installiert werden.
yum install epel-release
Anschließend wird das monitorix-Paket folgendermaßen installiert und gestartet:
yum install monitorix systemctl start monitorix
An diesem Punkt läuft Monitorix bereits und ist über <hostip>:8080/monitorix
erreichbar. Mit der jetzt aktiven Standardkonfiguration werden bereits einige generische Systemparameter überwacht, andere hingegen sollten je nach Host noch konfiguriert werden.
Konfigurationsbeispiele
In der Datei /etc/monitorix/monitorix.conf
kann die Monitorix-Konfiguration an die eigenen Bedürfnisse angepasst werden.
Wegen der sehr ausführlichen Dokumentation zu Monitorix verzichte ich hier auf eine lange Beschreibung jeglicher Konfigurationsparameter. Auf wichtige Eckpunkte möchte ich aber kurz eingehen.
Im ersten Abschnitt der Konfigurationsdatei werden allgemeine Einstellungen vorgenommen. In den Webserver-Optionen im Block <httpd_builtin>
sollte die Authentifizierung per htpasswd-Datei aktiviert werden, um das Monitorix-Dashboard mit Benutzername und Passwort zu schützen. Ein Benutzer mit Passwort wird mit folgendem Befehl generiert, wenn die Apache-Erweiterung installiert ist:
htpasswd -c /var/lib/monitorix/htpasswd benutzer
Zusätzliche Absicherung kann durch das explizite Erlauben bzw. Verbieten von IP-Adressen oder Hostnamen (hosts_deny
und hosts_allow
) erreicht werden.
Die unterschiedlichen Graphen, die im Dashboard angezeigt werden sollen, können im Block <graph_enable>
einzeln aktiviert oder deaktiviert werden. Es ergibt Sinn, nur Graphen zu aktivieren, deren Konfiguration man im entsprechenden Block auch vorgenommen hat.
HTTPS ist für den internen Webserver nicht nativ über die Konfigurationsdatei zu aktivieren. Wer sein Monitoring-Dashboard aber dennoch nur über eine verschlüsselte Verbindung aufrufen möchte, kann beispielsweise einen Reverse-Proxy vorschalten.
Aufbau der Konfigurationsdatei /etc/monitorix/monitorix.conf
:
W/# Monitorix - configuration file # # See monitorix.conf(5) manpage for a detailed description of each option. # title = <hostname> - Dashboard hostname = pvhost01 - rootserver theme_color = black refresh_rate = 180 iface_mode = graph enable_zoom = y netstats_in_bps = n disable_javascript_void = n temperature_scale = c show_gaps = n global_zoom = 1 max_historic_years = 1 accept_selfsigned_certs = y image_format = PNG enable_parallelizing = y include_dir = /etc/monitorix/conf.d base_dir = /var/lib/monitorix/www/ base_lib = /var/lib/monitorix/ base_url = /monitorix base_cgi = /monitorix-cgi / <httpd_builtin> enabled = y host = port = 8080 user = nobody group = nobody log_file = /var/log/monitorix-httpd hosts_deny = hosts_allow = <auth> enabled = y msg = Monitorix: Restricted access htpasswd = /var/lib/monitorix/htpasswd </auth> </httpd_builtin> # Log files pathnames # ----------------------------------------------------------------------------- log_file = /var/log/monitorix secure_log = /var/log/secure mail_log = /var/log/maillog milter_gl = /var/milter-greylist/greylist.db imap_log = /var/log/imap hylafax_log = /var/spool/hylafax/etc/xferfaxlog cups_log = /var/log/cups/page_log ftp_log = /var/log/proftpd/access.log fail2ban_log = /var/log/fail2ban.log spamassassin_log = /var/log/maillog clamav_log = /var/log/clamav/clamav.log cg_logdir = /var/CommuniGate/SystemLogs/ squid_log = /var/log/squid/access.log imap_log_date_format = %b %d secure_log_date_format = %b %e <piwik_tracking> enabled = n url = "://example.com/piwik/" sid = "1" img = "http://example.com/piwik/piwik.php?idsite=1" </piwik_tracking> # Graphs (de)activation # ----------------------------------------------------------------------------- <graph_enable> system = y kern = n proc = n hptemp = n lmsens = n gensens = n ipmi = n nvidia = n disk = y fs = y zfs = n du = y net = y netstat = n tc = n libvirt = n process = y serv = n mail = n port = y user = n ftp = n apache = y nginx = n lighttpd = n mysql = n mongodb = n varnish = n pagespeed = n squid = n nfss = n nfsc = n bind = n ntp = n chrony = n fail2ban = n icecast = n raspberrypi = n phpapc = n memcached = n apcupsd = n nut = n wowza = n int = n verlihub = n </graph_enable> # SYSTEM graph # ----------------------------------------------------------------------------- <system> <alerts> loadavg_enabled = n loadavg_timeintvl = 3600 loadavg_threshold = 5.0 loadavg_script = /path/to/script.sh </alerts> rigid = 1, 0, 0, 0 ,0 limit = 1, 1000, 1000, 1000, 1000 </system> # KERN graph # ----------------------------------------------------------------------------- <kern> graph_mode = r <list> user = y nice = y sys = y iow = y irq = y sirq = y steal = y guest = y </list> rigid = 2, 1, 2 limit = 100, 1000, 100 </kern> # PROC graph # ----------------------------------------------------------------------------- <proc> max = 4 graphs_per_row = 2 size = medium data = y rigid = 2 limit = 100 </proc> # PROCESS graph # ----------------------------------------------------------------------------- <process> <list> 0 = httpd, sshd, ntpd, mysqld, proftpd, clamd, imap, sendmail, named, smbd </list> <desc> httpd = Apache imap = Dovecot named = Bind </desc> rigid = 2, 0, 0, 0, 0, 0, 0, 0 limit = 100, 1000, 1000, 1000, 1000, 1000, 1000, 1000 </process> # PORT graph # ----------------------------------------------------------------------------- <port> max = 3 rule = 24000 list = 22, 7081 <desc> #25 = SMTP, tcp, in, 0, 1000, L #21 = FTP, tcp, in, 0, 1000, L 22 = SSH, tcp, in, 0, 1000, L #110 = POP3, tcp, in, 0, 1000, L #139 = NETBIOS, tcp, in, 0, 1000, L #3306 = MYSQL, tcp, in, 0, 1000, L #53 = DNS, udp, in, 0, 1000, L #143 = IMAP, tcp, in, 0, 1000, L </desc> graphs_per_row = 3 </port> # APACHE graph # ----------------------------------------------------------------------------- <apache> list = https://<hostname>/server-status?auto <alerts> </alerts> rigid = 0, 0, 2, 0, 0, 0 limit = 100, 100, 100, 100, 100, 100 </apache> # NGINX graph # ----------------------------------------------------------------------------- <nginx> url = http://<hostname>/nginx_status port = 80 rule = 24100 rigid = 0, 0, 0 limit = 100, 100, 100 </nginx> # MYSQL graph # ----------------------------------------------------------------------------- <mysql> conn_type = host list = localhost # list = /var/lib/mysql/mysql.sock <desc> localhost = 3306, user, secret </desc> rigid = 0, 2, 0, 0, 0, 0 limit = 100, 100, 100, 100, 100, 100 </mysql> #... weitere Graphen-Konfigurationen ... # Multihost # ----------------------------------------------------------------------------- <multihost> enabled = y footer_url = y graphs_per_row = 2 remotehost_list = hirsrv01, pvhost01, h2115464-gerken <remotehost_desc> 0 = http://host1:8080,/monitorix,/monitorix-cgi 1 = http://host2:8080,/monitorix,/monitorix-cgi 2 = http://host3:8080,/monitorix,/monitorix-cgi </remotehost_desc> groups = y remotegroup_list = rootserver, vhosts <remotegroup_desc> 0 = host1, host2 1 = host3 </remotegroup_desc> </multihost> # Email Reports # ----------------------------------------------------------------------------- <emailreports> enabled = n url_prefix = http://localhost:8080 smtp_hostname = localhost from_address = noreply@example.com hour = 0 minute = 0 <daily> enabled = n graphs = system, fs to = ace@example.com </daily> <weekly> enabled = n graphs = system, fs to = gene@example.com </weekly> <monthly> enabled = n graphs = system, fs to = paul@example.com </monthly> <yearly> enabled = n graphs = system, fs to = peter@example.com </yearly> </emailreports>
Multi-Host
Monitorix hat ein Multi-Host-Feature, welches das Einbinden anderer Monitorix-Dashboards in ein „zentrales Dashboard“ ermöglicht.
Vergleiche zwischen verschiedenen Hosts werden damit aber nur auf Ebene einzelner Graphen möglich, sofern diese übereinstimmend aktiviert wurden.
Auf der Dashboard-Startseite werden im Dropdownmenü weitere Einträge auswählbar, wenn Remote-Hosts in der Konfigurationsdatei monitorix.conf
(siehe oben) im Block <multihost>
angegeben werden. Wichtig ist, dass die Remote-Host-Einträge nach folgendem Schema vorgenommen werden.
Eine Gruppierung der Remote-Hosts, z. B. nach physischem oder virtuellem Host ist auch möglich.
<remotehost_desc> 0 = http://host1:8080,/monitorix,/monitorix-cgi 1 = http://host2:8080,/monitorix,/monitorix-cgi 2 = http://host3:8080,/monitorix,/monitorix-cgi </remotehost_desc>
E-Mail und Alerting
Sollten überwachte Werte aus einem definierten Rahmen fallen, muss ein Serveradministrator darüber informiert werden. Größere Monitoring-Lösungen wie Nagios oder Zabbix werden daher zur Echtzeitüberwachung von Systemen und unverzüglicher Benachrichtigung per E-Mail und SMS eingesetzt.
Diesen Anspruch kann man mit Monitorix nicht vollumfassend erfüllen, weil es nicht für alle zu überwachenden Parameter eine entsprechende <alert>
-Funktion gibt.
Darüber hinaus gibt es die Möglichkeit, sich in regelmäßigen Abständen per E-Mail Graphen zusenden zu lassen – und das unabhängig von Alarmierungen bzw. dem Überschreiten von Grenzwerten.
Dashboards
Ich habe für meine Server die Graphen-Dashboards bewusst schlank gehalten und mich auf die wichtigsten Parameter beschränkt. Dadurch bleibt die Ladezeit klein und ich werde nicht von zu vielen Details abgelenkt.

Wie man im System-Graphen erkennen kann, langweilt sich der Server den Tag über hauptsächlich.

Ein mäßig frequentierter Apache-Webserver hat ebenfalls wenig Last. Mit dem Graphen lassen sich aber gut eventuelle Lastspitzen finden und über längere Zeit Muster entdecken.

Der Disk-Graph offenbart einen Einblick in die Klimazone des physischen Servers. Es herrscht offensichtlich immer das gleiche Wetter im Rechenzentrum. Nur nachts – während des Backups – geht die Temperatur der Festplatten für kurze Zeit einige wenige Grad nach oben.
Tipp: Auch wenn ein detaillierterer Einblick als 1 Tag nicht per Dropdown auswählbar ist, kann man durch das Bearbeiten der Monitorix-URL auch beispielsweise Graphen für nur eine Stunde aufrufen. Dazu muss man in der URL einfach nur 1day durch 1hour ersetzen.
Als schnelle, kostenlose Lösung mit guter Dokumentation kann ich Monitorix also auf jeden Fall empfehlen. Sobald der Server-Zoo, die zu überwachenden Parameter und die Ansprüche an eine Monitoring-Lösung jedoch anwachsen, sind andere Produkte wohl besser geeignet.