Skip to content
APAdam Probert
← All work

Live-service game infrastructure

Observability tooling for cloud-hosted game servers

Built a C# metrics SDK and Unity integration to make dedicated game servers measurable in production.

Context

The situation

Cloud-hosted, dedicated game servers are hard to reason about without good telemetry. The team needed a consistent way to measure server behaviour and surface it where engineers could act on it.

Problem

What actually needed solving

This meant building a metrics SDK and Unity plugin that could capture meaningful signals from dedicated Linux server builds (connections, network traffic, CPU, memory, and frame timings) and move them reliably into a standard observability stack, while working within game-engine and platform constraints.

Constraints

What I had to work within

  • Dedicated Linux server builds with platform-specific limitations
  • Game-engine constraints on how and when metrics can be gathered
  • The need for percentile-accurate timing, not just averages
  • Unsupported deployment targets that had to be identified and worked around
Approach

How I moved it forward

  1. 01

    Built a C# metrics SDK integrating DogStatsD-style metrics and moved data through OpenTelemetry to Prometheus and Grafana.

  2. 02

    Captured server connections, network traffic, CPU, memory, and frame timings, with histograms and percentile calculations for latency-style signals.

  3. 03

    Wrote a Unity-specific metrics processor to bridge engine realities and the SDK.

  4. 04

    Tested against dedicated Linux server builds and investigated platform limitations and unsupported deployment targets.

Key decisions

The trade-offs that mattered

  • Standard rails via OpenTelemetry

    Routing through OpenTelemetry to Prometheus and Grafana kept the game servers on the same observability rails as everything else.

  • Histograms over averages

    Percentiles tell you about the bad frames and slow tails that averages hide, essential for anything latency-sensitive.

  • A Unity-aware processor

    Respecting engine constraints with a dedicated processor kept measurement accurate without fighting the runtime.

Outcome

What changed

  • A reusable metrics SDK that made dedicated game servers measurable in production.
  • Server behaviour surfaced in Prometheus and Grafana alongside the rest of the stack.
  • Clear visibility into platform limitations and unsupported targets.
Lessons

What I took from it

  • Observability for game servers lives at the seam of SDK design, engine integration, and infrastructure: you have to be comfortable in all three.
  • Measuring the right thing (tails, not means) matters more than measuring more things.
Contact

Have a difficult, important problem?

I’m happiest where the problem is unclear, several teams need to work together, and the outcome actually matters. If that sounds like your situation, let’s talk.

  • Talk through a hard technical problem
  • Scope a platform, data, or distributed-systems build
  • Get a second opinion on an architecture or delivery plan
  • A role or engagement worth a conversation