Infrastructure Monitoring Game Ops

Monitoring & Game Ops

Purpose

Structured logging, player telemetry, alerting, and performance budgets for game servers.

When to Use

Trigger: monitoring, logging, telemetry, alerting, performance, metrics, observability, error tracking, player analytics, server health, uptime

Prerequisites

• game-backend-architecture — what we're monitoring
• redis-game-patterns — metrics storage

Core Principles

1. Structured logging — JSON logs with consistent fields; never unstructured console.log in production
2. Player telemetry — track actions, session length, retention, spending — anonymized
3. Alert on anomalies — sudden drops in DAU, spike in errors, economy inflation
4. Performance budgets — server tick must complete in < 16ms (60fps); API responses < 200ms p95
5. Dashboard first — if you can't see it, you can't fix it

Key Metrics

Log Schema

interface GameLogEntry {
  timestamp: string;     // ISO 8601
  level: 'debug' | 'info' | 'warn' | 'error';
  service: string;       // 'game-server' | 'api' | 'worker'
  event: string;         // 'player.login' | 'combat.resolved' | 'purchase.completed'
  playerId?: string;
  sessionId?: string;
  data: Record<string, unknown>;
  duration?: number;     // ms, for timed operations
  error?: {
    message: string;
    stack?: string;
    code?: string;
  };
}

Cross-References

• game-backend-architecture — server topology to monitor
• redis-game-patterns — real-time metrics storage
• bullmq-game-queues — queue health monitoring
• stripe-game-payments — revenue tracking
• ci-cd-game — post-deployment monitoring

Sources

• "Game Server Monitoring at Scale" — GDC 2020
• "Player Telemetry Best Practices" — GDC 2019
• OpenTelemetry documentation