Monolith Analytics · Monolith Wiki

COMMAND → ACTIONBAR → HTML → VERSTEHEN

Ein Befehl bis zum verständlichen Bericht

01
Aufnahme starten
STANDARD ist der empfohlene Einstieg für normale Lag- und Spike-Diagnose.
text
```
/monolith analytics start standard 60
```
02
Problem reproduzieren
Erzeuge während des begrenzten Fensters dieselbe echte Last. Die Actionbar zeigt Modus, exakten Zeitfortschritt, Samples und Spikes.
03
Analyse abwarten
Nach der Aufnahme folgen Finalisierung, Analyse und HTML-Erzeugung. Monolith zeigt in diesen Phasen keine erfundenen Prozentwerte.
04
Eine Datei öffnen
Kopiere den fertigen Bericht vom Server und öffne ihn lokal per Doppelklick. Alle Ansichten funktionieren offline.

monolith/analytics/monolith-analytics-MA-<Zeit>-<ID>.html

Ruhiger Fortschritt in der Actionbar

◆ Analytics STANDARD │ 48% │ 00:29 / 01:00 │ 12.4k Samples │ 1 Spike

Nur der Spieler, der den Capture gestartet hat, erhält die Anzeige.
Die Aktualisierung erfolgt höchstens ein- bis zweimal pro Sekunde und verwendet nur günstig verfügbare Zähler.
INITIALIZING, FINALIZING, ANALYZING und GENERATING_REPORT zeigen Text statt erfundener Prozentwerte.
Bei einem Konsolenstart gibt es keine Spieler-Actionbar; die Konsole erhält seltene Fortschrittsmeldungen.
Nach einem Disconnect bleibt keine Player-Referenz erhalten und ein Reconnect erhält keinen veralteten Status.

Drei Ansichten statt überfüllter Karten

Ansicht	Geeignet für	Inhalt
Übersicht	Serverbetreiber und schnelle Diagnose	Serverzustand, wichtige Messwerte, kompakte Befunde und direkte Links zur passenden Forensik.
Erweitert	Technische Admins und Entwickler	Breite Arbeitsbereiche für CPU, Ticks, Threads, Speicher, GC, Plugins, Entities, Chunks, Netzwerk, Warteschlangen, Speicherung, JVM und Analytics-Eigenlast.
Rohdaten	Prüfung der zugrunde liegenden Evidenz	Progressiver JSON-Baum mit Suche, Pfad- und Wertekopie sowie unverändertem Export.

Übersicht → Forensik

Kompakte Befunde

Priorität, Primärmesswert und Hauptquelle bleiben knapp. Messgrundlage, Aussagegrenze und nächster Schritt öffnen sich im großen Inspektor.

CPU-gewichtet oder RUNNABLE-only

Großer CPU-Arbeitsbereich

Flamegraph, Top-down-Aufrufbaum und Bottom-up-Ansicht erhalten nahezu die volle Breite, 500 Pixel Höhe, Suche, Zoom und Fokusmodus.

Keine erfundenen Werte

Tick- und Spike-Inspektor

Nur vorhandene Overlay-Reihen werden angeboten. Ein Klick öffnet Tickkontext, Entities, Chunks, GC und Warteschlangenwerte, sofern erfasst.

Bewusste Leerzustände

Speicher, GC & Allokation

Zeitverläufe, Sammlerübersicht und Allokationsattribution sind getrennt. Fehlt ein Backend, erklärt der Bericht Grund, verfügbare Evidenz und nächste Aufnahme.

Ein oder zwei Spalten

Engine-Forensik

Plugins, Entity-Abfragen, Mob-KI, Chunks, Hopper, Weltzugriffe, Netzwerk, Speicherung und Queues besitzen eigene navigierbare Bereiche.

Für DEEP-Berichte

Reaktionsfähige Rohdaten

Große Zweige, Tabellen und Aufrufbäume werden erst bei Bedarf oder begrenzt dargestellt. Das eingebettete Reportmodell bleibt vollständig.

Globale Suche, sortierbare Tabellen, Messqualitäts-Badges, Fokusmodus, Diagnosetext-Kopie und Rohdatenexport funktionieren direkt in der Datei. Es gibt keine externen Skripte, Schriftarten, Bilder, APIs oder CDNs.

CPU, Threadzustände und Messaufwand richtig lesen

Ansicht	Was sie zeigt	Wichtige Grenze
CPU Flame Graph	Bevorzugt Gewichte aus Thread-CPU-Zeitdeltas; sonst ausschließlich RUNNABLE-Stichproben als gesampelte CPU-Näherung.	WAITING, TIMED_WAITING und BLOCKED zählen nie als CPU-Arbeit.
Thread State Graph	RUNNABLE, WAITING, TIMED_WAITING und BLOCKED als getrennte Zustandspräsenz.	Zustandspräsenz ist kein CPU-Anteil.
Sampler Self-Overhead	CPU-Zeit, Allocation, Abtastrate und Eigenlastklasse der Analytics-Aufnahme.	UNAVAILABLE bleibt unbekannt und wird nicht zu null umgedeutet.

Entity- und Plugin-Befunde richtig lesen

Messbereich	Was Analytics trennt	Aussagegrenze
Entity-Abfragen	Anfragen, gescannte Kandidaten, Ausschluss-, Broadphase-, AABB-, Typ- und Prädikatsablehnungen sowie akzeptierte und zurückgegebene Entities.	Eine gemeinsame Stichprobenentscheidung hält die Zähler konsistent; Hochrechnungen bleiben sichtbar geschätzt.
Aufruf und Form	Gemessene aufrufende Grenze, Abfragetyp, Kandidatendichte und AABB-Größenklasse.	Es werden keine einzelnen Entity-Identitäten gespeichert.
Plugin-Callbacks	Inklusive und exklusive Callback-Grenzzeit, Aufrufe, P95/Maximum sowie verfügbare Callback-Allokation.	Inklusive Zeiten dürfen überlappen und ergeben keinen summierbaren CPU-Anteil.
Plugin-ausgelöste Engine-Arbeit	Nur Engine-Grenzen, die Analytics innerhalb eines Plugin-Callbacks tatsächlich beobachtet.	Nicht instrumentierte Engine-Arbeit bleibt im nicht klassifizierten Rest.
Monolith-/Paper-Dispatch	Zeit des Event-Dispatches außerhalb der unmittelbaren Listener-Grenzen.	Nur dieser getrennte Anteil ist eindeutig dem Server-Framework zugeordnet.

Passenden Modus wählen

Modus	Typischer Einsatz	Grenze
LIGHT	Sehr günstige Tick- und JVM-Grunddaten ohne CPU-Stacksampling.	Maximal 1.800 Sekunden
STANDARD	Empfohlene normale Diagnose mit CPU, Tick-Autopsie und JVM-Trends.	Maximal 600 Sekunden
DEEP	Kurze Vertiefung mit zusätzlichen Engine- und Contention-Messpunkten.	Maximal 300 Sekunden
DEVELOPER	Interne MONO-PERF-Counter für kontrollierte Entwicklung.	Nicht für normalen Serverbetrieb

Export, Verlauf und Aufbewahrung

/monolith analytics start [light|standard|deep|developer] [Sekunden]

Startet den begrenzten Capture; Spieler sehen echten Actionbar-Fortschritt.

/monolith analytics stop

Beendet den Capture vollständig und startet Analyse sowie HTML-Erzeugung.

/monolith analytics status

Zeigt Lifecycle, Restzeit, Samples, Spikes, Bericht und Fehlerzustand.

/monolith analytics cancel

Verwirft die aktive Aufnahme ohne Bericht.

/monolith analytics history

Listet Report-ID, Status, Modus, Dauer, P95, P99, Primärbefund und HTML-Datei.

/monolith analytics export <ID>

Validiert den eigenständigen HTML-Bericht. Dies ist der normale Export.

/monolith analytics export <ID> raw

Optionaler Maschinenexport für Automatisierung; für normale Nutzung nicht erforderlich.

/monolith analytics compare <A> <B>

Vergleicht kompatible Rohmodelle zweier Berichte serverseitig.

monolith:
  analytics:
    retention:
      max-reports: 64
      max-age-days: 30
      max-total-mib: 512

Monolith entfernt nach einem neuen Bericht die ältesten HTML-/Rohdaten-Paare, bis Anzahl, Alter und Gesamtgröße wieder innerhalb aller Grenzen liegen. Der gerade erzeugte Bericht bleibt immer erhalten.

Status, Sicherheit und Datenschutz

Status	Bedeutung
COMPLETE	Capture und HTML-Bericht wurden vollständig erzeugt.
INCOMPLETE	Teilbericht, beispielsweise nach Server-Shutdown; sichtbar nicht vollständig.
CANCELLED	Aufnahme wurde bewusst verworfen.
REPORT_GENERATION_FAILED	Server läuft weiter; finalisierte Rohdaten bleiben nach erfolgreichem Sidecar-Schreiben erhalten.

HTML und internes JSON stammen aus demselben versionierten Reportmodell. JSON bleibt ein Implementierungs- und Maschinenformat; Nutzer müssen es nicht manuell öffnen oder verstehen.