KI-Reports

Die Reports sind der Sinn von PulseNode. Diagramme sagen dir, dass etwas passiert ist; der Report sagt dir, was es war und was du ändern sollst.

Frequenz

Zustellung per E-Mail und, wenn verbunden, in deinen Discord-Kanal. Empfänger und Frequenz stellst du unter Server → Reports im Dashboard ein.

Was ein Report enthält

Zuerst ein Fazit. Ob die Woche besser oder schlechter war als die vorige, in einem Satz.

Performance-Zusammenfassung. Durchschnittliche und schlechteste TPS/MSPT, wann die schlimmsten Momente waren und wie sie zur Vorperiode stehen.

Korrelationen. Der Teil, für den ein Mensch Stunden braucht: das wiederkehrende Muster hinter den Einbrüchen. Jeden Tag zur selben Zeit? Immer derselbe Spieler online? Steigend mit der Entity-Zahl in einer Welt?

Lag-Snapshots. Jeder erfasste Einbruch mit dem Zustand in diesem Moment — du liest Fakten, statt zu rekonstruieren.

Konsolenfehler. Nach Signatur gruppiert mit Zähler, schlimmste zuerst — ein Stacktrace, der sich 4.000-mal wiederholt, erscheint einmal mit einer Zahl, nicht 4.000-mal.

Konkrete Tipps. Handfeste Änderungen, mit Bezug auf deine tatsächliche Konfiguration. Nicht „zieh mal die Entities runter", sondern „world_nether liegt im Schnitt bei 9.400 Entities gegenüber 1.200 in world; dein spawn-limits.monsters steht auf dem Standard 70 bei view-distance: 12".

Security-Zusammenfassung in Tarifen, die sie enthalten: gefährliche Befehle, Verbindungsfluten, Login-Fehlschläge.

Wie die Tipps entstehen

Die Mustererkennung ist gewöhnliche Analyse auf den Zeitreihendaten — dieser Teil ist Rechnung, keine KI. Was das Modell macht, ist, aus den Befunden und deinem Konfigurations-Snapshot lesbaren Text mit einer Empfehlung zu formen.

Diese Trennung ist wichtig fürs Vertrauen: Die Fakten in einem Report kommen deterministisch aus deinen Daten. Die Formulierung und die Priorisierung sind generiert.

Welche Daten der Report sieht

Alles, was das Plugin für den Zeitraum gesendet hat:

• die Metrik-Zeitreihe
• Lag-Snapshots
• erfasste Konsolenfehler
• Security-Ereignisse
• Konfigurations-Snapshots von Plugins und Server

Die Konfigurations-Snapshots sind es, die einen Tipp view-distance oder spawn-limits beim Namen nennen lassen, statt allgemein zu bleiben.

Geheimnisse werden im Plugin, vor der Übertragung geschwärzt — Schlüssel wie password, secret, token, key, credentials, mysql, database, jdbc, webhook, license und ähnliche verlassen deine Maschine nie und landen damit auch nie in einem Report.

Reports nützlicher machen

Spark installieren. Die CPU-Zeit pro Plugin ist der handfesteste Datenpunkt überhaupt, und ohne Spark ist sie geschätzt. Mit Spark kann ein Report das Plugin benennen.

track-console-errors anlassen. Fehler erklären Einbrüche, die Metriken allein nicht erklären.

Servern erkennbare Namen geben. Ein Report über „Server 3" ist schwerer umzusetzen als einer über „survival".

critical-tps auf einen Wert setzen, der auf deinem Server etwas bedeutet. Feuert er ständig, steckt jeder Report voller Snapshots und keiner sticht heraus.

Den ersten Report lesen

Der erste Report auf einem neuen Server bleibt dünn — eine Woche Historie ist kaum eine Stichprobe, und Korrelationen brauchen Wiederholung, um sichtbar zu werden. Ab dem dritten Report wird PulseNode sein Abo wert, denn dann wird aus „jeden Abend um 19:00" ein erkennbares Muster statt drei einzelner Vorfälle.

Crash-Analyse

Pro und Business enthalten die Crash-Analyse: Hört ein Server auf zu senden und startet danach neu, werden die letzten Snapshots vor der Lücke mit den erfassten Konsolenfehlern zusammengeführt — der Report kann dann sagen, was der Server beim Abschmieren gerade tat.