Skip to content

Observability

Observability is the operational depth behind “the server feels bad”. It shows whether a problem is the tick loop, memory pressure, garbage collection, or the data pipeline itself.

Each server reports CPU, RAM, disk, TPS, MSPT, players, and latency. Metrics are stored with average, p95, min, and max aggregations, and the dashboard exposes granularities from 1 minute to daily.

MetricUnitWatch for
TPSticks/sSustained drops below 19.
MSPTmsMedian and p95 rising together.
CPU%Process versus system share.
Memory%Process, physical, and swap.
LatencymsPlayer-facing ping average and p95.
DiskMBGrowth and instance size.

These bands match the platform’s alert defaults and are a reasonable starting point:

MetricWarningCritical
TPSbelow 19below 17
MSPTabove 40 msabove 50 ms
CPUabove 70%above 90%
Memoryabove 75%above 90%
Latencyabove 100 msabove 200 ms

Server observability includes JVM-specific views:

  • Runtime: thread count, peak and daemon threads, GC collections, total GC time, average pause, and open versus max file descriptors.
  • Memory pools: used bytes per pool, with a pool selector.
  • GC events: an event table, histogram, and scatter view with per-event names and filters.

Use these together: rising memory with more frequent GC pauses usually points at heap pressure, while high CPU with stable memory points at tick work.

Pipeline health tells you whether data itself is flowing: batches sent and failed, data points sent, queue depth, authentication blocks, and connection failures. If a chart looks stale, check here before assuming the server is idle.

The network interfaces view reports RX/TX per interface, with an interface selector, so host-level traffic can be compared with player-facing latency.

Observability is server-scoped; fleet-level health appears on the command center and operations home. Metrics arrive after collection and processing, so a chart can lag the live server by a short interval.