Zum Inhalt springen
clausvb.de

Monitoring und Logauswertung im Alltag

Was überwacht gehört, welche Schwellen sinnvoll alarmieren und wie du aus Logs eine Störungsursache herausliest, statt sie zu erraten.

Zuletzt geprüft: Gedacht für: Betrieb produktiver Seiten

Das Wichtigste

  • Von aussen prüfen, nicht nur auf dem Server. Ein Dienst, der lokal antwortet und von aussen nicht, ist trotzdem ausgefallen.
  • Auf Inhalt prüfen, nicht auf Statuscode. Eine Fehlerseite mit HTTP 200 besteht jeden reinen Statuscheck.
  • Ein Alarm, der zu oft grundlos auslöst, wird ignoriert. Lieber wenige, verlässliche Alarme als vollständige Abdeckung.
  • Plattenplatz ist die häufigste Ursache für Störungen, die zunächst nach etwas anderem aussehen.

Überwachung soll eine Frage beantworten: Merkst du einen Ausfall vor deinen Besuchern? Alles andere ist nachgeordnet.

Die vier Prüfungen, die den meisten Nutzen bringen

1. Erreichbarkeit von aussen, mit Inhaltsprüfung.

Ein Statuscode-Test allein reicht nicht. Viele Anwendungen liefern ihre Fehlerseite mit HTTP 200 aus, und Cloudflare oder ein Reverse Proxy können antworten, während die Anwendung dahinter längst steht.

#!/usr/bin/env bash
ANTWORT=$(curl -s --max-time 10 https://example.com/)
echo "$ANTWORT" | grep -q 'Erwarteter Text im Seitenkopf' \
  || echo "Inhaltsprüfung fehlgeschlagen" | mail -s "example.com" admin@example.com

Der geprüfte Text sollte aus dem dynamischen Teil der Seite kommen – idealerweise aus etwas, das eine Datenbankabfrage voraussetzt. Dann deckt die Prüfung die ganze Kette ab.

2. Plattenplatz.

df -h --output=pcent,target / | tail -1

Alarm bei 85 Prozent, nicht erst bei 95. Zwischen den beiden Werten liegt die Zeit, in der man das Problem in Ruhe lösen kann.

3. Zertifikatsgültigkeit.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

Alarm bei weniger als 20 Tagen Restlaufzeit. Bei 90-Tage-Zertifikaten bedeutet das: Die Automatik hatte bereits zwei Wochen Zeit und hat nicht gegriffen.

4. Sicherung gelaufen und plausibel.

find /var/backups -name 'db-*.sql.gz' -mtime -1 -size +1M | grep -q . \
  || echo "Backup fehlt oder ist zu klein" | mail -s "Backup-Alarm" admin@example.com

Die Grössenprüfung fängt den Fall ab, in dem das Skript läuft, aber einen leeren Dump erzeugt.

Schwellen, die sich bewährt haben

MesswertWarnungAlarm
Plattenplatz85 %92 %
Systemlast (pro Kern)1,53,0
Speicher belegt85 %95 %
Antwortzeit (Median)800 ms2.000 ms
Zertifikat Restlaufzeit20 Tage7 Tage
HTTP-Fehlerquote1 %5 %

Die Zahlen sind Startwerte. Nach zwei Wochen Betrieb passt man sie an die tatsächliche Kurve an – ein Server, der normal bei 80 Prozent Speicher läuft, braucht andere Schwellen als einer bei 30.

Fehlalarme vermeiden

Ein Alarmsystem, das zweimal pro Woche grundlos meldet, wird nach einem Monat weggeklickt. Zwei Massnahmen dagegen:

  • Erst nach mehreren Fehlversuchen alarmieren. Drei aufeinanderfolgende fehlgeschlagene Prüfungen im Abstand von einer Minute – dann ist es kein Netzwerkrauschen.
  • Von mehreren Standorten prüfen. Nur wenn zwei unabhängige Standorte scheitern, liegt es am Server.

Logs lesen, statt zu raten

Bei einer Störung dieselbe Reihenfolge:

# 1. Was ist zuletzt passiert - alle Dienste, chronologisch
journalctl -p err -n 50 --no-pager

# 2. Der verdächtige Dienst
journalctl -u apache2 --since "30 min ago" --no-pager

# 3. Anwendungsfehler
tail -n 100 /var/log/apache2/example.com-error.log

# 4. Muster im Zugriffslog
awk '$9 ~ /^5/ {print $7}' example.com-access.log | sort | uniq -c | sort -rn | head

Schritt 4 zeigt, welche URLs Serverfehler erzeugen. Wenn sich das auf einen einzelnen Endpunkt konzentriert, ist die Suche vorbei, bevor sie anfängt.

Weitere Auswertungen, die im Alltag helfen:

# Zeitlicher Verlauf der Fehler - wann fing es an?
awk '$9 ~ /^5/ {print substr($4,2,14)}' access.log | uniq -c

# Langsamste Anfragen (mit %D im LogFormat)
awk '{print $NF, $7}' access.log | sort -rn | head -20

# Verteilung der Statuscodes
awk '{print $9}' access.log | sort | uniq -c | sort -rn

Logrotation prüfen

Volle Logverzeichnisse sind eine der häufigsten Ursachen für Störungen, die nach etwas anderem aussehen:

du -sh /var/log/* | sort -rh | head
cat /etc/logrotate.d/apache2
logrotate -d /etc/logrotate.conf 2>&1 | head -40

Der Probelauf mit -d zeigt, was passieren würde, ohne etwas zu ändern. Häufiger Fund: Ein Log, das eine Anwendung selbst schreibt und für das nie eine Rotationsregel angelegt wurde.

Aufbewahrung und Datenschutz

Zugriffslogs enthalten IP-Adressen und damit personenbezogene Daten. Zwei praktikable Wege:

Kürzen beim Schreiben:

LogFormat "%{X-Anon-IP}e %l %u %t \"%r\" %>s %O" anon
SetEnvIf Remote_Addr "^(\d+\.\d+\.\d+)\." ANON=$1.0

Oder kurz aufbewahren: sieben bis vierzehn Tage für Rohdaten, und was länger gebraucht wird, vorher zu Kennzahlen verdichten. Für die Fehlersuche reicht das aus – ein Problem, das nach drei Wochen niemandem aufgefallen ist, war keins.

Häufige Fragen

Was sollte ich mindestens überwachen?

Vier Dinge: Erreichbarkeit der Seite von aussen mit Inhaltsprüfung, freier Plattenplatz, Gültigkeit des TLS-Zertifikats und ob die Sicherung tatsächlich gelaufen ist. Damit sind die meisten Ausfälle abgedeckt, die man vorher hätte bemerken können.

Wie vermeide ich Fehlalarme?

Zwei Massnahmen: erst nach mehreren aufeinanderfolgenden Fehlversuchen alarmieren, und von mehreren Standorten prüfen. Ein einzelner Zeitüberschreitungsfehler ist meistens Netzwerkrauschen, drei in Folge sind ein Ausfall.

Wie lange soll ich Logs aufbewahren?

Für die Fehlersuche reichen meist 14 bis 30 Tage. Personenbezogene Daten wie vollständige IP-Adressen sollten kürzer gehalten werden – oder beim Schreiben gekürzt. Länger aufbewahren lohnt bei aggregierten Auswertungen, nicht bei Rohdaten.

Brauche ich ein zentrales Logsystem?

Ab mehreren Servern ja, sonst sucht man in jeder Störung an drei Stellen gleichzeitig. Für einen einzelnen Server reichen journalctl und die Standardwerkzeuge völlig aus.

Weiterlesen