Service Observability And Metrics Contract
Service observability covers health, readiness, info, metrics, tracing, and the control-panel telemetry history that derives rates from raw counters. The contract is shared through common-proto service status and metrics types.
Purpose
Use this page when adding a service metric, debugging a missing control-panel graph, or deciding which service should expose /metrics.
Endpoint Capability Matrix
Service descriptors declare which status endpoints a service supports. Health and readiness are baseline operational endpoints. Metrics support is service-specific; the control panel should consult endpoint capabilities instead of assuming every service exposes every endpoint.
The control plane currently has a metrics response type in the shared protocol, but not the same live metric surface as login and game.
Login Metrics
Login server metrics include request rate, auth failure rate, token issuance rate, database latency, and Redis latency. The login support layer measures DB/Redis calls and records auth failures through audit contexts.
If login metrics are zero during traffic, inspect middleware and measurement wrappers before blaming the panel.
Game Metric Families
Game metrics include active and pending realtime sessions, AOI enters/leaves, visible entity counts, full and delta snapshots, rate-limit decisions, packet-validation decisions, move-input transport decisions, movement authority decisions/backlog, trigger authority decisions, QUIC transport decisions/samples, queue depths, tick health, and session lifecycle journal depths.
Dynamic metric maps must use descriptor-generated keys so panel deserialization remains forward-compatible.
Session Lifecycle Journal Metrics
The game /metrics snapshot also reads session lifecycle journal pending, processing, and dead-letter depths from Redis. If those fields are missing or stale, inspect Redis access from the metrics endpoint rather than only the worker.
Control-Panel Derived Rates
The control panel derives per-second series from monotonically increasing counters using CounterRateTracker. It also keeps rolling telemetry for health, active sessions, AOI, snapshot rates, trigger authority, and packet validation.
Do not change counter semantics to gauges without updating panel derivation.
Tracing And RUST_LOG
Services initialize tracing through aether_observability. Use RUST_LOG or the service's logging config to raise detail during incident debugging. Metrics should answer "what is happening"; traces should answer "which path did it take".
Adding Metrics Safely
Add a descriptor or typed field, update the service snapshot, update control-panel deserialization/visualization if needed, and add tests for dynamic-key compatibility. Keep labels stable; dashboards and alert rules depend on them.