Server-Monitoring: Kennzahlen, Tools und Alarme einrichten

Kennen Sie das? Ihr Onlineshop wird langsamer, nicht dramatisch, nur für ein paar Sekunden. Sie denken: “Wahrscheinlich gab es gerade mehr Besucher.” Am nächsten Tag passiert es wieder. Eine Woche später ist es ein Muster. Und Ihr Anbieter antwortet: “Alles in Ordnung, Sie haben nur die übliche Last.” Genau hier beginnt die Geschichte, wie man so ein Problem in wenigen Minuten aufklärt, wenn man weiß, worauf man schauen muss.

Hosting-Monitoring ist kein Privileg großer Konzerne mit dickem Budget und teurer Infrastruktur. Es ist Ihre Versicherung gegen böse Überraschungen im ungünstigsten Moment: wenn Bestellungen ins Leere laufen und Sie mit dem Telefon am Ohr darauf warten, dass der Support sagt “wir starten den Server gleich neu”.

Was wirklich hinter den Zahlen in den Diagrammen steckt

Wenn Sie sich in das Control Panel Ihres Hostings einloggen, sehen Sie Diagramme. Ganz normale Zähler für CPU, Arbeitsspeicher und Traffic. Doch diese scheinbar harmlosen Zahlen erzählen eine ganze Kriminalgeschichte darüber, was mit Ihrer Website tatsächlich passiert.

Die CPU-Last ist nicht einfach ein Prozentwert von abstrakten 100 %. Sie zeigt, wie viel Zeit der Prozessor tatsächlich mit Ihrer Website verbringt. Springt die CPU-Last nachts, wenn kaum Besucher da sind, plötzlich vom üblichen Niveau bis fast ans Limit, ist das keine natürliche Schwankung, sondern ein Notsignal. Vielleicht greifen Bots Sie an und versuchen, Ihr Passwort zu knacken. Oder ein WordPress-Plugin macht ausgerechnet zur Hauptverkehrszeit stündliche Backups. Oder jemand lässt einen Scraper über Ihren Katalog laufen.

Arbeitsspeicher ist kostbar. Das Tariflimit wirkt auf dem Papier ausreichend. In der Praxis hängt alles davon ab, wie Ihre Website ihn nutzt. WordPress mit Dutzenden Plugins und eigenem Code von einem Entwickler, der unsauber gearbeitet hat, kann den gesamten Speicher innerhalb weniger Minuten Spitzenlast aufbrauchen.

Traffic ist ein weiterer Teil der Gleichung. Wenn Ihr Tarif ein Traffic-Limit im Preis hat, behalten Sie im Blick, wie nah Sie daran sind (bei den Hosting-Tarifen von RichHost ist der Traffic unbegrenzt). Und wenn Sie an einem einzigen Tag mehr verbrauchen als sonst in einem Monat, lohnt es sich herauszufinden, warum. Eine geplante Werbekampagne muss es nicht gewesen sein.

Sieben Warnsignale, die förmlich “Hilfe!” schreien

• Serverantwortzeit (TTFB) dauerhaft über 1,8 Sekunden: der web.dev-Leitfaden von Google stuft das als schlecht ein, ein guter TTFB liegt bei 0,8 Sekunden oder weniger (geprüft am 30.10.2026).
• CPU oder Arbeitsspeicher stoßen regelmäßig an das Tariflimit: das System balanciert auf Messers Schneide. Von welcher Servicequalität kann die Rede sein, wenn der Server kurz vor dem Zusammenbruch steht? Das ist, als würden Sie jeden Tag mit leerem Tank fahren.
• Veränderungen bei der Zahl der 404-, 500- und 502-Fehler: wenn 500er-Fehler plötzlich um ein Vielfaches häufiger auftreten als sonst, ist das kein Zufall, sondern ein Trend. Irgendetwas ist schiefgelaufen.
• Plötzliche Traffic-Spitzen ohne erkennbaren Grund: Sie haben keine Aktion gestartet, aber der Traffic hat sich vervielfacht. Gut so? Oder hat ein DDoS-Angriff begonnen? Ein Hack? Ein Scraper?
• Die Ladezeit der Seiten steigt von Tag zu Tag: dann verschlechtert sich etwas rund um Ihre Website.
• Datenbankabfragen hängen: wenn eine MySQL-Abfrage Sekunden statt der üblichen Millisekunden dauert, haben Sie die Ursache der Verlangsamung gefunden. Der Index muss optimiert werden, oder die Tabelle ist zu groß geworden.
• Der Speicherplatz füllt sich ungewöhnlich schnell: wenn der belegte Platz über Nacht deutlich gewachsen ist und Sie nichts hochgeladen haben: Wohin gehen die Daten? Logs? Nicht gelöschte Backups? Der Cache eines Plugins?

Tools, die mehr Aufmerksamkeit verdienen als eine Tasse Kaffee

Seien wir ehrlich: Die eingebauten Diagramme im Hosting-Panel sind wie ein Blick auf die Straße durch einen Türspalt. Sie sehen etwas, aber nicht das ganze Bild. Deshalb setzen erfahrene Betreiber schon lange auf externes Monitoring.

Jedes dieser Tools erzählt seinen Teil der Geschichte. UptimeRobot verrät, wann und wie viele Minuten Ihre Website nicht erreichbar war. New Relic zeigt, was in diesem Moment mit den Datenbankabfragen los war. Sentry zeigt Ihnen die genaue Codezeile, die den Fehler verursacht hat.

Entscheidend ist nicht ein einzelnes Monitoring-Tool, sondern eine Kombination von Tools, die Ihnen volle Klarheit verschafft. Wie bei einem Puzzle, bei dem jedes Teil eine Information ist.

Alarme: So entkommen Sie der Benachrichtigungsflut

Sie bekommen täglich Dutzende E-Mails über kurze CPU-Spitzen und gleich viele mit der Entwarnung. Und die nächste, wenn die Website wirklich ausfällt, lesen Sie gar nicht mehr, weil Sie sie mit allen anderen gelöscht haben.

Das nennt man Alarmmüdigkeit, und sie untergräbt die Sicherheit. Richten Sie Alarme deshalb mit Bedacht ein. Hier sind Beispiele für Startwerte, die Sie anschließend an das normale Verhalten Ihrer Website anpassen:

1. CPU über 85 % für mindestens 5 Minuten: das ist ein Signal. Eine einzelne Spitze von einer Minute dagegen nicht.
2. Serverantwortzeit (TTFB) über 1,8 Sekunden, der Grenzwert für “schlecht” bei web.dev: nur wenn das dauerhaft auftritt, nicht bei zufälligen Schwankungen.
3. Die Website ist nicht erreichbar: das ist IMMER kritisch. Sofort. Ohne Filter.
4. 5xx-Fehler werden zum Problem, wenn es deutlich mehr sind, als Sie normalerweise pro Stunde sehen.

Und das Wichtigste: Alarme müssen dort ankommen, wo Sie sie garantiert sehen. Nicht per E-Mail. E-Mail ist wie Briefe per Post in den 1990ern. Besser sind Slack-Nachrichten, SMS, Push-Benachrichtigungen in Telegram, Bauchschmerzen: irgendetwas, das Sie um 3 Uhr nachts weckt und sagt: “Hey, schau hier hin.”

Logs als Ermittlungsakte: Was Ihnen das Hosting mitteilt

Das Hosting speichert Logs: Webserver-Fehler, Zugriffsprotokolle, PHP-Fehler, Fehler der Datenbank. Diese Logs sind wie das Tagebuch des Hostings über alles, was es im Laufe des Tages getan hat.

Ein typisches Szenario: Ein Problem, das Sie nicht reproduzieren können, lässt sich am einfachsten über die Logs untersuchen. Auch wenn sich der Ausfall nicht wiederholen lässt, enthalten die Logs meist die Details, die zur Ursache führen.

Zum Beispiel sehen Sie, dass die Website um 14:32 langsamer wurde. Sie haben zu dem Zeitpunkt nichts Besonderes gemacht. Doch wenn Sie in die Logs eintauchen, finden Sie Tausende PHP-Fehler eines Plugins, das sich mit einer API verbinden wollte, die um 14:30 ausgefallen war. Das System kämpfte, und jede Anfrage blieb mehrere Sekunden lang blockiert, während sie auf eine Antwort wartete.

Ohne Blick in die Logs wäre das ein Rätsel geblieben. Mit ihnen wird es eine Diagnose.

So automatisieren Sie, was Sie täglich quält

Seien wir realistisch: Sie werden sich nicht jeden Tag in Ihr Hosting-Panel einloggen und Diagramme anschauen. Das ist langweilig, anstrengend für die Augen und Zeitverschwendung.

Deshalb schreiben erfahrene Betreiber Skripte. In Bash, Python, PHP, egal. Ein Skript, das stündlich Folgendes erledigt:

• Holt Daten über die API des Hostings (falls vorhanden)
• Vergleicht sie mit Schwellenwerten
• Liegt etwas über dem Normalwert, kommt ein Alarm
• Speichert die Daten in einer Datenbank für Verlauf und Analyse

Das ist überhaupt nicht kompliziert. Wirklich. Ein Python-Skript mit 50 Zeilen, und Sie haben bereits ein System, das stündlich Daten sammelt.

Dafür brauchen Sie allerdings eines: Der Anbieter muss eine API oder zumindest SSH-Zugang bereitstellen. Wenn Ihr Hosting-Anbieter noch nie von einer offenen API gehört hat, ist das ein Signal. Er denkt offenbar nicht an anspruchsvolle Kunden, und vielleicht sollten Sie sich nach einem anderen umsehen.

Wollen Sie sich wirklich auf einen Server verlassen, der im Dunkeln arbeitet, ohne dass Sie sehen, was dort passiert? Das ist wie Autofahren mit verbundenen Augen. Alles geht gut, bis jemand auf die Straße tritt.