Wie wir 4.000 Discord Server im Blick behalten: Grafana, PostHog und was sie uns gezeigt haben

AlphaCloud läuft auf gut 4.000 Discord Servern, verteilt auf vier Shards. Das sind vier Prozesse, die jeweils einen Teil der Server bedienen und alle mit derselben API sprechen.

Bei dieser Größe fällt ein Fehler selten dadurch auf, dass etwas kaputtgeht. Viel häufiger funktioniert alles, nur teurer, langsamer oder lauter als nötig. Genau dafür haben wir im September 2026 unser Monitoring neu aufgebaut. Dieser Artikel zeigt, wie es aussieht und was es uns in den ersten Wochen gezeigt hat.

Zwei Werkzeuge, zwei Fragen

Grafana beantwortet die Frage: Was macht der Bot? Bot und API liefern Kennzahlen an Prometheus (Anfragen, Antwortzeiten, Fehlerquoten, Discord Antworten, KI Verbrauch), die Logs landen in Loki. Jeder Server Knoten hat seinen eigenen Stack, und Grafana ist nur über ein privates Netz erreichbar, nicht aus dem Internet.

PostHog beantwortet die Frage: Was erleben die Menschen auf unseren Webseiten? Seitenaufrufe, Fehler im Browser, Ladezeiten und, bei Zustimmung, aufgezeichnete Sitzungen. PostHog startet erst nach der Einwilligung im Cookie Banner.

Die Trennung ist Absicht. Grafana schaut auf Maschinen, PostHog auf Oberflächen. Wer beides in ein Werkzeug presst, bekommt entweder Nutzerdaten in die Serverlogs oder Serverlast in die Produktanalyse.

Was es gefunden hat

Ein Loop, der die Hälfte des Verkehrs erzeugte

Umfragen mit Endzeit schließt ein Hintergrundprozess, der jede Minute nachsieht, ob etwas abgelaufen ist. Er tat das für jeden Server einzeln. Bei rund 1.000 Servern pro Shard und vier Shards waren das etwa 70 Anfragen pro Sekunde, fast alle mit dem Ergebnis "nichts abgelaufen".

Aufgefallen ist das erst in Grafana, als wir die Anfragen vom Bot an die API nach Pfad aufgeschlüsselt haben: dieser eine Endpunkt war mehr als die Hälfte des gesamten Verkehrs. Funktioniert hat alles. Nur eben mit einer Last, die niemand bestellt hatte.

Jetzt fragt jeder Shard einmal pro Minute: "Auf welchen Servern gibt es überhaupt eine abgelaufene Umfrage?" Und nur für diese holt er Details. Aus rund 4.200 Anfragen pro Minute wurden etwa vier.

Drei Millionen Mal "nicht eingerichtet"

Ähnliches Muster, andere Stelle: Mehrere Module (Supporteinträge, Abmeldungen, Teamliste, Bot Statistiken, Newsletter) fragten in ihren Schleifen regelmäßig die Einstellungen jedes Servers ab. Auf den meisten Servern ist ein bestimmtes Modul gar nicht eingerichtet, die Antwort war also ein "nicht gefunden". Rund drei Millionen Mal am Tag.

Die Lösung ist unspektakulär: Ein "nicht eingerichtet" wird jetzt 30 Minuten gemerkt. Sicher ist das nur, weil jedes dieser Module beim Speichern im Webpanel sofort eine Aktualisierung an den Bot schickt. Wer ein Modul einrichtet, wartet also keine 30 Minuten.

Discords Ausfälle sind nicht unsere Fehler

Unser Fehlerkanal für das Team postete jede fehlgeschlagene Aktion als "Runtime Error", mit eindeutiger Kennung und allem Drum und Dran. Darunter waren auch Momente, in denen Discord selbst mit einem Serverfehler antwortete. Das ist weder ein Fehler bei uns noch etwas, das wir beheben können, und es stand im Kanal genau so da wie ein echter Bug.

Heute wird das als Warnung geloggt, und das Mitglied bekommt einen Hinweis, es in ein paar Sekunden erneut zu versuchen, statt eines Links zum Bug Report. Ein Fehlerkanal, in dem die Hälfte der Meldungen kein Fehler ist, wird irgendwann nicht mehr gelesen. Dann übersieht man den echten.

Ein Angriff, der eine Minute dauerte

An einem Nachmittag Ende September bekam unsere Startseite innerhalb einer Minute gut 500.000 Anfragen aus vielen Ländern gleichzeitig. Der Großteil wurde vor unseren Servern abgefangen, eine Minute später war der Verkehr wieder normal.

Gesehen haben wir das nicht, weil etwas ausfiel, sondern weil die Zahl in der Auswertung nicht zum Rest passte. Das ist die eigentliche Aufgabe von Monitoring: nicht Alarm schlagen, wenn alles brennt, sondern zeigen, wo etwas nicht zur Normalität passt.

Was unser Monitoring bewusst nicht sieht

Die Regeln hier sind genauso wichtig wie die Dashboards:

• Keine Besucher IP Adressen in Logs. Unsere Datenschutzerklärung sagt das zu, also entfernen wir sie an zwei Stellen: schon beim Schreiben des Zugriffsprotokolls und noch einmal vor der Ablage.
• Keine Server, Nutzer oder Nachrichten IDs in Kennzahlen. Jede Kennzahl wird nur nach groben Merkmalen aufgeteilt (Modul, Statusklasse, Shard). Das schützt Daten und hält die Datenbank der Kennzahlen klein.
• Sitzungsaufzeichnungen zeigen unsere Oberfläche, nicht deine Inhalte. Lesbar bleibt nur Text, der wörtlich aus unseren Übersetzungsdateien stammt. Server, Kanal und Nutzernamen, Eingaben und Vorschauen werden maskiert. Kann die Liste der erlaubten Texte nicht geladen werden, wird alles maskiert.
• Alles auf der Webseite erst nach Einwilligung. Und die Zahlen dort sind deshalb eine Untergrenze. Für die echten Aufrufzahlen schauen wir auf die anonymen Zählungen unseres Netzwerkanbieters.

Details dazu stehen in der Datenschutzerklärung.

Was wir daraus mitnehmen

Das Teure ist selten das Kaputte. Keiner der Funde oben hat einen Fehler erzeugt. Sie haben Last, Kosten und Lärm erzeugt, und genau das sieht man ohne Messung nie.

Pro Server fragen skaliert nicht. Beide großen Funde waren dasselbe Muster: eine Schleife über alle Server, die für jeden einzeln nachfragt. Die Antwort ist fast immer dieselbe Frage, einmal für alle gestellt.

Ein Alarm muss selten sein, sonst ist er keiner. Deshalb pingt nur Grafana das Team, und nur bei Dingen, die wirklich eingreifen erfordern. Neue Fehlertypen aus PostHog landen ohne Ping im Kanal.

Wenn du selbst einen Discord Server betreibst und wissen willst, welche Module wir hier erwähnt haben: Umfragen, Supporteinträge und Abmeldungen findest du im Webpanel, die Beschreibungen in der Dokumentation.