# Monitoring Amazon GameLift Servers Monitoring Monitoring is an important part of maintaining the reliability, availability, and performance of Amazon GameLift Servers and your other AWS solutions. There are three primary uses for metrics with Amazon GameLift Servers: to monitor system health and set up alarms, to track game server performance and usage, and to manage capacity using manual or auto-scaling. AWS provides the following monitoring tools to watch Amazon GameLift Servers, report when something is wrong, and take automatic actions when appropriate: + **Amazon GameLift Servers console** – Use the graphical interface to manage your Amazon GameLift Servers resources and track game hosting activity. + **Server telemetry metrics** – Amazon GameLift Servers enables you to emit custom metrics directly from your game servers through SDK and plugin integration. You can define and track your own game-specific metrics alongside built-in performance, network, memory, and timing data. All metrics can be published to [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) and monitored in Amazon Grafana using fully customizable dashboards. You can also publish to Amazon CloudWatch for integration with other AWS services. The telemetry system is fully customizable - you can create custom Prometheus queries to derive additional metrics in addition to the built-in ones. For implementation guides specific to your technology stack, see [Monitor with server telemetry metrics](monitoring-gamelift-servers-metrics.md). + **Amazon CloudWatch** – You can monitor Amazon GameLift Servers metrics in real time, as well as metrics for other AWS resources and applications that you're running on AWS services. Amazon CloudWatch offers a suite of monitoring features, including tools to create customized dashboards and the ability to set alarms that notify or take action when a metric reaches a specified threshold. + **AWS CloudTrail** – captures all API calls and related events made by or on behalf of your AWS account for Amazon GameLift Servers and other AWS services. Data is delivered as log files to an Amazon S3 bucket that you specify. You can identify which users and accounts called AWS, the source IP address from which the calls were made, and when the calls occurred. + **Game session logs** – You can output custom server messages for your game sessions to log files that are stored in Amazon S3. ## Metrics comparison across monitoring sources Metrics comparison Amazon GameLift Servers provides metrics through three primary sources: the Amazon GameLift Servers console Fleet Activity metrics, server telemetry metrics, and Amazon CloudWatch Amazon GameLift Servers metrics. Understanding the overlap and unique capabilities of each source helps you choose the right monitoring approach for your needs. ### Metrics availability by source The following tables show which metrics are available across different monitoring sources, organized by metric category. #### Instance metrics Instance-level metrics for fleet capacity and health monitoring: **Instance metrics availability** | Metric | Console | CloudWatch | Telemetry | | --- | --- | --- | --- | | Active instances | ✓ | ✓ | ✓ | | Idle instances | ✓ | ✓ | ✓\$1 | | Percent idle instances | ✓ | ✓ | ✓\$1 | | Desired instances | ✓ | ✓ | | | Max instances | ✓ | ✓ | | | Min instances | ✓ | ✓ | | | CPU utilization | | ✓ | ✓ | | Network in/out | | ✓ | ✓ | | Disk/Storage read/write | | ✓ | ✓ | | Instance interruptions | ✓ | ✓ | | | Recycled instances | ✓ | ✓ | | | Unhealthy instances replaced | | ✓ | | **\$1** Available through custom Prometheus queries using telemetry data. #### Game server metrics Server process and game session metrics: **Game server metrics availability** | Metric | Console | CloudWatch | Telemetry | | --- | --- | --- | --- | | Active game sessions | ✓ | ✓ | ✓\$1 | | Activating game sessions | ✓ | ✓ | | | Available game sessions | ✓ | ✓ | | | Percent available game sessions | ✓ | ✓ | | | Concurrent activatable game sessions | ✓ | ✓ | | | Game session interruptions | ✓ | ✓ | | | Active server processes | | | ✓ | | Healthy game servers | | | ✓ | | Crashed game sessions | | | ✓ | **\$1** Available through custom Prometheus queries using telemetry data. #### Player usage metrics Player session and concurrent user metrics: **Player usage metrics availability** | Metric | Console | CloudWatch | Telemetry | | --- | --- | --- | --- | | Current player sessions | ✓ | | | | Player session activations | ✓ | | | | Global concurrent users (CCU) | | | ✓ | | Location concurrent users (CCU) | | | ✓ | | Location capacity | | | ✓ | #### Container fleet metrics Container-specific metrics (available only in CloudWatch for container fleets): **Container fleet metrics availability** | Metric | Console | CloudWatch | Telemetry | | --- | --- | --- | --- | | Active container groups | | ✓ | ✓ | | Idle container groups | | ✓ | ✓ | | Container CPU/Memory utilization | | ✓ | ✓ | | Container network traffic | | ✓ | ✓ | | Container storage operations | | ✓ | ✓ | #### Choosing the right monitoring source Select your monitoring approach based on your specific needs: + **Use server telemetry metrics** to monitor comprehensive performance data from your game servers and emit custom metrics specific to your game. These metrics deliver detailed insights into server performance, network activity, memory usage, and timing data for all game engines and server SDKs. You can define custom metrics for gameplay events, business logic performance, and application-specific data points. All dashboards are fully customizable, and you can create custom Prometheus queries to derive additional metrics from the collected data. For more information, see [Monitor with server telemetry metrics](monitoring-gamelift-servers-metrics.md). + **Use the Amazon GameLift Servers console** for fleet management, capacity planning, and general operational oversight. The console provides an integrated view of fleet health and player activity. For more information, see [Manage game hosting resources with Amazon GameLift Servers](gamelift-console-intro.md). + **Use Amazon CloudWatch** for automated monitoring, alerting, and integration with other AWS services. CloudWatch enables custom dashboards and alarm-based automation. For more information, see [Monitor Amazon GameLift Servers with Amazon CloudWatch](monitoring-cloudwatch.md). + **Use [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html)** for high-performance metrics collection and storage with PromQL querying capabilities. Prometheus provides scalable time-series data storage for server telemetry metrics. + **Use [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html)** for advanced visualization and fully customizable dashboarding. Grafana provides pre-built GameLift dashboards that you can customize and extend, plus supports creating entirely custom dashboards with multiple data sources. You can build custom queries and visualizations to track any metrics important to your game. + **Use multiple sources** for comprehensive monitoring. Combine console oversight, server telemetry metrics, and automated alerting for complete visibility into your game hosting infrastructure. For additional monitoring capabilities, you can also use: + [Logging Amazon GameLift Servers API calls with AWS CloudTrail](logging-using-cloudtrail.md) – Track API calls and related events for auditing and compliance. + [Logging server messages in Amazon GameLift Servers](logging-server-messages.md) – Capture custom server messages and game session logs. ### Topics + [Manage game hosting resources with Amazon GameLift Servers](gamelift-console-intro.md) + [Monitor Amazon GameLift Servers with Amazon CloudWatch](monitoring-cloudwatch.md) + [Monitor with server telemetry metrics](monitoring-gamelift-servers-metrics.md) + [Logging Amazon GameLift Servers API calls with AWS CloudTrail](logging-using-cloudtrail.md) + [Logging server messages in Amazon GameLift Servers](logging-server-messages.md) # Monitor Amazon GameLift Servers with Amazon CloudWatch Monitor with CloudWatch You can monitor Amazon GameLift Servers using Amazon CloudWatch, an AWS service that collects raw data and processes it into readable, near real-time metrics. These statistics are kept for 15 months to provide a historical perspective on how your game server hosting with Amazon GameLift Servers is performing. You can set alarms that watch for certain thresholds and send notifications or take actions when those thresholds are met. For more information, see the [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/). For enhanced server-side observability with detailed telemetry metrics, Amazon GameLift Servers also supports monitoring through [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) and [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html). These telemetry metrics provide detailed server performance data including: + **Server Timings:** Server Delta Time (consistency of server tick rate), Server Tick Rate (updates per second), Server Tick Time (processing time per tick), and Server World Tick Time (game world update time) + **Network Metrics:** Connections (total network connections), Network I/O in Bytes and Packets (data transfer statistics), and Packet Loss (transmission failure percentage) + **Memory Metrics:** Memory Usage in Units (total memory consumption) and Physical Memory Usage as percentage (memory utilization) + **CPU Usage:** CPU Usage percentage (resource utilization by game server process) For implementation guides specific to your SDK or plugin, see [Monitor with server telemetry metrics](monitoring-gamelift-servers-metrics.md). The following tables list the metrics and dimensions for Amazon GameLift Servers. All metrics that are available in CloudWatch are also available in the Amazon GameLift Servers console, which provides the data as a set of customizable graphs. To access CloudWatch metrics for your games, use the AWS Management Console, the AWS CLI, or the CloudWatch API. If a metric does not have a location, it uses the home location. ## Dimensions for Amazon GameLift Servers metrics Metrics dimensions Amazon GameLift Servers supports filtering metrics by the following dimensions. | Dimension | Description | | --- | --- | | `Location` | Filter metrics for a fleet deployment location. If a metric does not have a location, it uses the home location. | | `FleetId` | Filter metrics for a single fleet. This dimension can be used with all fleet metrics for instances, server processes, game sessions, and player sessions. | | `MetricGroup` | Filter metrics for a collection of fleets. Add a fleet to a metric group by adding the metric group name to the fleet's attributes (see [UpdateFleetAttributes()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_UpdateFleetAttributes.html)). This dimension can be used with all fleet metrics for instances, server processes, game sessions, and player sessions. | | `QueueName` | Filter metrics for a single queue. This dimension is used with metrics for game session queues only. | | `ConfigurationName` | Filter metrics for a single matchmaking configuration. This dimension is used with metrics for matchmaking configurations. | | `ConfigurationName-RuleName` | Filter metrics for an intersect of a matchmaking configuration and matchmaking rule. This dimension is used with metrics for matchmaking rules only. | | `InstanceType` | Filter metrics for an EC2 instance type designation, such as "c4.large". This dimension is used with metrics for spot instances. | | `OperatingSystem` | Filter metrics for an instance's operating system This dimension is used with metrics for spot instances. | | `GameServerGroup` | Filter FleetIQ metrics for a game server group. | | `ContainerGroupType` | Filter container fleet metrics to distinguish between GameServer ContainerGroup metrics on the fleet location and PerInstance ContainerGroup metrics on the fleet location. This dimension is included for certain container fleet metrics (such as ContainerNetworkIn, ContainerStorageReadBytes) allow you to distinguish between metrics for different container group types. | ## Amazon GameLift Servers metrics for fleets Fleet metrics The `Amazon GameLift` namespace includes the following metrics related to activity across a fleet or a group of fleets. Fleets are used with a managed Amazon GameLift Servers solution. The Amazon GameLift Servers service sends metrics to CloudWatch every minute. ### Instances | Metric | Description | | --- | --- | | `ActiveInstances` | Instances with ACTIVE status, which means they are running active server processes. The count includes idle instances and those that are hosting one or more game sessions. This metric measures current total instance capacity. This metric can be used with automatic scaling. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `DesiredInstances` | Target number of active instances that Amazon GameLift Servers is working to maintain in the fleet. With automatic scaling, this value is determined based on the scaling policies currently in force. Without automatic scaling, this value is set manually. This metric is not available when viewing data for fleet metric groups. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `IdleInstances` | Active instances that are currently hosting zero (0) game sessions. This metric measures capacity that is available but unused. This metric can be used with automatic scaling. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `MaxInstances` | Maximum number of instances that are allowed for the fleet. A fleet's instance maximum determines the capacity ceiling during manual or automatic scaling up. This metric is not available when viewing data for fleet metric groups. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `MinInstances` | Minimum number of instances allowed for the fleet. A fleet's instance minimum determines the capacity floor during manual or automatic scaling down. This metric is not available when viewing data for fleet metric groups. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `PercentIdleInstances` | Percentage of all active instances that are idle (calculated as `IdleInstances / ActiveInstances`). This metric can be used for automatic scaling. Units: Percent Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `RecycledInstances` | Number of spot instances that have been recycled and replaced. Amazon GameLift Servers recycles spot instances that are not currently hosting game sessions and have a high probability of interruption. This metric is available for managed EC2 fleets only. Units: Count Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: Location | | `RecycledSpotInstances` | Number of spot instances that have been recycled and replaced. Amazon GameLift Servers recycles spot instances that are not currently hosting game sessions and have a high probability of interruption. This metric is available for container fleets only. Units: Count Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: Location | | `InstanceSpotInterruptions` | Number of spot instances that have been interrupted. Units: Count Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: Location | | `CPUUtilization` | *EC2 metric. For Amazon GameLift Servers this metric represents hardware performance across all active instances in a fleet location.* The percentage of physical CPU time that Amazon EC2 uses to run the instance, which includes time spent to run both the user code and Amazon EC2 code. Tools in your operating system can show a different percentage than CloudWatch due to factors such as legacy device simulation, configuration of non-legacy devices, interrupt-heavy workloads, live migration, and live update. Units: Percent | | `NetworkIn` | *EC2 metric. For Amazon GameLift Servers this metric represents hardware performance across all active instances in a fleet location.* The number of bytes received on all network interfaces by the instance. This metric identifies the volume of incoming network traffic to an application on a single instance. Units: Bytes | | `NetworkOut` | *EC2 metric. For Amazon GameLift Servers this metric represents hardware performance across all active instances in a fleet location.* The number of bytes sent out on all network interfaces by the instance. This metric identifies the volume of outgoing network traffic to an application on a single instance. Units: Bytes | | `DiskReadBytes` | *EC2 metric. For Amazon GameLift Servers this metric represents hardware performance across all active instances in a fleet location.* Bytes read from all instance store volumes available to the instance. This metric is used to determine the volume of the data the application reads from the hard disk of the instance. You can use it to determine the speed of the application. Units: Bytes | | `DiskWriteBytes` | *EC2 metric. For Amazon GameLift Servers this metric represents hardware performance across all active instances in a fleet location.* Bytes written to all instance store volumes available to the instance. This metric is used to determine the volume of the data the application writes onto the hard disk of the instance. You can use it to determine the speed of the application. Units: Bytes | | `DiskReadOps` | *EC2 metric. For Amazon GameLift Servers this metric represents hardware performance across all active instances in a fleet location.* Completed read operations from all instance store volumes available to the instance in a specified period of time. To calculate the average I/O operations per second (IOPS) for the period, divide the total operations in the period by the number of seconds in that period. Units: Count | | `DiskWriteOps` | *EC2 metric. For Amazon GameLift Servers this metric represents hardware performance across all active instances in a fleet location.* Completed write operations to all instance store volumes available to the instance in a specified period of time. To calculate the average I/O operations per second (IOPS) for the period, divide the total operations in the period by the number of seconds in that period. Units: Count | ### Server processes | Metric | Description | | --- | --- | | `ActiveServerProcesses` | Server processes with ACTIVE status, which means they are running and able to host game sessions. The count includes idle server processes and those that are hosting game sessions. This metric measures current total server process capacity. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `HealthyServerProcesses` | Active server processes that are reporting healthy. This metric is useful for tracking the overall health of the fleet's game servers. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `PercentHealthyServerProcesses` | Percentage of all active server processes that are reporting healthy (calculated as `HealthyServerProcesses / ActiveServerProcesses`). Units: Percent Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `ServerProcessAbnormalTerminations` | Server processes that were shut down due to abnormal circumstances since the last report. This metric includes terminations that were initiated by the Amazon GameLift Servers service. This occurs when a server process stops responding, consistently reports failed health checks, or does not terminate cleanly (by calling [ ProcessEnding()](https://docs.aws.amazon.com/gamelift/latest/developerguide/integration-server-sdk-cpp-ref-actions.html#integration-server-sdk-cpp-ref-processending)). Units: Count Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: Location | | `ServerProcessActivations` | Server processes that successfully transitioned from ACTIVATING to ACTIVE status since the last report. Server processes cannot host game sessions until they are active. Units: Count Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: Location | | `ServerProcessTerminations` | Server processes that were shut down since the last report. This includes all server processes that transitioned to TERMINATED status for any reason, including normal and abnormal process terminations. Units: Count Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: Location | ### Game sessions | Metric | Description | | --- | --- | | `ActivatingGameSessions` | Game sessions with ACTIVATING status, which means they are in the process of starting up. Game sessions cannot host players until they are active. High numbers for a sustained period of time may indicate that game sessions are not transitioning from ACTIVATING to ACTIVE status. This metric can be used with automatic scaling. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `ActiveGameSessions` | Game sessions with ACTIVE status, which means they are able to host players, and are hosting zero or more players. This metric measures the total number of game sessions currently being hosted. This metric can be used with automatic scaling. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `AvailableGameSessions` | Active, healthy server processes that are not currently being used to host a game session and can start a new game session without a delay to spin up new server processes or instances. This metric can be used with automatic scaling. For fleets that limit concurrent game session activations, use the metric `ConcurrentActivatableGameSessions`. That metric more accurately represents the number of new game sessions that can start without any type of delay. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `ConcurrentActivatableGameSessions` | Active, healthy server processes that are not currently being used to host a game session and can immediately start a new game session. This metric differs from `AvailableGameSessions` in the following way: it does not count server processes that currently cannot activate a new game session because of limits on game session activations. (See the fleet [RuntimeConfiguration](https://docs.aws.amazon.com/gamelift/latest/apireference/API_RuntimeConfiguration.html) optional setting `MaxConcurrentGameSessionActivations`). For fleets that don't limit game session activations, this metric is identical to `AvailableGameSessions`. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `PercentAvailableGameSessions` | Percentage of game session slots on all active server processes (healthy or unhealthy) that are not currently being used (calculated as `AvailableGameSessions / [ActiveGameSessions + AvailableGameSessions + unhealthy server processes]`). This metric can be used with automatic scaling. Units: Percent Relevant CloudWatch statistics: Average Dimensions: Location | | `GameSessionInterruptions` | Number of game sessions on spot instances that have been interrupted. Units: Count Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: Location | ### Player sessions | Metric | Description | | --- | --- | | `CurrentPlayerSessions` | Player sessions with either ACTIVE status (player is connected to an active game session) or RESERVED status (player has been given a slot in a game session but hasn't yet connected). This metric can be used with automatic scaling. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum | | `PlayerSessionActivations` | Player sessions that transitioned from RESERVED status to ACTIVE since the last report. This occurs when a player successfully connects to an active game session. Units: Count Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum | ### Container fleet metrics Container fleet metrics provide monitoring data for container-based game hosting, including container group status, resource utilization, and performance metrics. **Note** Enhanced dashboards for container fleet monitoring are available through [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) when using the telemetry metrics solution. See [Monitor with server telemetry metrics](monitoring-gamelift-servers-metrics.md) for setup instructions. | Metric | Description | | --- | --- | | `ActiveGameServerContainerGroups` | Container groups that are currently active and ready to host game sessions. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `IdleGameServerContainerGroups` | Container groups that are active but not currently hosting game sessions. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `PendingGameServerContainerGroups` | Container groups that are in the process of starting up. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `TerminatingGameServerContainerGroups` | Container groups that are in the process of shutting down. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `UnhealthyGameServerContainerGroupsReplaced` | Container groups that were replaced due to health check failures. Units: Count Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: Location | | `ContainerCPUUtilizationPerInstance` | Average CPU utilization across all containers on an instance. Units: Percent Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `ContainerCPUReservation` | Percentage of CPU resources reserved by containers. Units: Percent Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `ContainerMemoryReservation` | Percentage of memory resources reserved by containers. Units: Percent Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `ContainerMemoryUtilization` | Percentage of reserved memory being used by containers. Units: Percent Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: Location | | `ContainerNetworkIn` | Network bytes received by containers. Units: Bytes Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: Location | | `ContainerNetworkOut` | Network bytes sent by containers. Units: Bytes Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: Location | | `ContainerStorageReadBytes` | Bytes read from storage by containers. Units: Bytes Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: Location | | `ContainerStorageWriteBytes` | Bytes written to storage by containers. Units: Bytes Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: Location | ## DDoS protection (player gateway) metrics Amazon GameLift Servers player gateway metrics track UDP traffic flowing through the DDoS protection layer when `PlayerGatewayMode` is set to `ENABLED` or `REQUIRED`. These metrics help you monitor traffic patterns, identify potential DDoS attacks, and track relay performance. | Metric | Description | | --- | --- | | `PlayerGatewayPacketsIn` | Number of UDP packets received from players and forwarded to game servers through the DDoS protection layer. Units: Count Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: FleetId, Location | | `PlayerGatewayBytesIn` | Number of bytes received from players and forwarded to game servers through the DDoS protection layer. Units: Bytes Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: FleetId, Location | | `PlayerGatewayPacketsOut` | Number of UDP packets received from game servers and forwarded to players through the DDoS protection layer. Units: Count Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: FleetId, Location | | `PlayerGatewayBytesOut` | Number of bytes received from game servers and forwarded to players through the DDoS protection layer. Units: Bytes Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: FleetId, Location | | `PlayerGatewayPacketsThrottled` | Number of inbound packets dropped due to rate limiting by the DDoS protection layer. Units: Count Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: FleetId, Location | | `PlayerGatewayBytesThrottled` | Number of inbound bytes dropped due to rate limiting by the DDoS protection layer. Units: Bytes Relevant CloudWatch statistics: Sum, Average, Minimum, Maximum Dimensions: FleetId, Location | | `PlayerGatewayPlayerSessions` | Player sessions that are currently protected by the DDoS protection layer. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum Dimensions: FleetId, Location | ## Amazon GameLift Servers metrics for queues Queue metrics The `Amazon GameLift` namespace includes the following metrics related to activity across a game session placement queue. Queues are used with a managed Amazon GameLift Servers solution. The Amazon GameLift Servers service sends metrics to CloudWatch every minute. | Metric | Description | | --- | --- | | `AverageWaitTime` | Average amount of time that game session placement requests in the queue with status PENDING have been waiting to be fulfilled. Units: Seconds Relevant CloudWatch statistics: Average, Minimum, Maximum, Sum Dimensions: Location | | `FirstChoiceNotViable` | Game sessions that were successfully placed but NOT in the first-choice fleet, because that fleet was considered not viable (such as a spot fleet with a high interruption rate). This metric is based on cost, not latency. The first-choice fleet is either the first fleet listed in the queue or—when a placement request includes player latency data—it is the first fleet chosen by [FleetIQ prioritization](https://docs.aws.amazon.com/gamelift/latest/developerguide/queues-design.html#queues-design-fleetiq). If there are no viable spot fleets, any fleet in that region may be selected. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum, Sum | | `FirstChoiceOutOfCapacity` | Game sessions that were successfully placed but NOT in the first-choice fleet, because that fleet had no available resources. The first-choice fleet is either the first fleet listed in the queue or—when a placement request includes player latency data —it is the first fleet chosen by your defined FleetIQ prioritization. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum, Sum | | `LowestLatencyPlacement` | Game sessions that were successfully placed in a region that offers the queue's lowest possible latency for the players. This metric is emitted only when player latency data is included in the placement request. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum, Sum | | `LowestPricePlacement` | Game sessions that were successfully placed in a fleet with the queue's lowest possible price for the chosen region. This fleet can be either a spot fleet or an on-demand instance if the queue has no spot instances. This metric is emitted only when player latency data is included in the placement request. Units: CountRelevant CloudWatch statistics: Average, Minimum, Maximum, Sum | | `Placement ` | Game sessions that are successfully placed in fleets located in the specified region. This metric breaks down the `PlacementsSucceeded` metric by region.Units: CountRelevant CloudWatch statistics: Sum | | `PlacementsCanceled` | Game session placement requests that were canceled before timing out since the last report. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum, Sum | | `PlacementsFailed` | Game session placement requests that failed for any reason since the last report. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum, Sum | | `PlacementsStarted` | New game session placement requests that were added to the queue since the last report. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum, Sum | | `PlacementsSucceeded` | Game session placement requests that resulted in a new game session since the last report. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum, Sum | | `PlacementsTimedOut` | Game session placement requests that reached the queue's timeout limit without being fulfilled since the last report. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum, Sum | | `QueueDepth` | Number of game session placement requests in the queue with status PENDING. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum, Sum Dimensions: Location | ## Amazon GameLift Servers metrics for matchmaking FlexMatch metrics The `Amazon GameLift` namespace includes metrics on FlexMatch activity for matchmaking configurations and matchmaking rules. FlexMatch matchmaking is used with a managed Amazon GameLift Servers solution. The Amazon GameLift Servers service sends metrics to CloudWatch every minute. For more information on the sequence of matchmaking activity, see [How Amazon GameLift Servers FlexMatch works](https://docs.aws.amazon.com/gamelift/latest/flexmatchguide/gamelift-match.html). ### Matchmaking configurations | Metric | Description | | --- | --- | | `CurrentTickets` | Matchmaking requests currently being processed or waiting to be processed. Units: Count Relevant CloudWatch statistics: Average, Minimum, Maximum, Sum | | `MatchAcceptancesTimedOut` | For matchmaking configurations that require acceptance, the potential matches that timed out during acceptance since the last report. Units: Count Relevant CloudWatch statistics: Sum | | `MatchesAccepted` | For matchmaking configurations that require acceptance, the potential matches that were accepted since the last report. Units: Count Relevant CloudWatch statistics: Sum | | `MatchesCreated` | Potential matches that were created since the last report. Units: Count Relevant CloudWatch statistics: Sum | | `MatchesPlaced` | Matches that were successfully placed into a game session since the last report. Units: Count Relevant CloudWatch statistics: Sum | | `MatchesRejected` | For matchmaking configurations that require acceptance, the potential matches that were rejected by at least one player since the last report. Units: Count Relevant CloudWatch statistics: Sum | | `PlayersStarted` | Players in matchmaking tickets that were added since the last report. Units: Count Relevant CloudWatch statistics: Sum | | `TicketsFailed` | Matchmaking requests that resulted in failure since the last report. Units: Count Relevant CloudWatch statistics: Sum | | `TicketsStarted` | New matchmaking requests that were created since the last report. Units: Count Relevant CloudWatch statistics: Sum | | `TicketsTimedOut` | Matchmaking requests that reached the timeout limit since the last report. Units: Count Relevant CloudWatch statistics: Sum | | `TimeToMatch` | For matchmaking requests that were put into a potential match before the last report, the amount of time between ticket creation and potential match creation. Units: Seconds Relevant CloudWatch statistics: Data Samples, Average, Minimum, Maximum | | `TimeToTicketCancel` | For matchmaking requests that were canceled before the last report, the amount of time between ticket creation and cancellation. Units: Seconds Relevant CloudWatch statistics: Data Samples, Average, Minimum, Maximum | | `TimeToTicketSuccess` | For matchmaking requests that succeeded before the last report, the amount of time between ticket creation and successful match placement. Units: Seconds Relevant CloudWatch statistics: Data Samples, Average, Minimum, Maximum | ### Matchmaking rules | Metric | Description | | --- | --- | | `RuleEvaluationsPassed` | Rule evaluations during the matchmaking process that passed since the last report. This metric is limited to the top 50 rules.Units: CountRelevant CloudWatch statistics: Sum | | `RuleEvaluationsFailed` | Rule evaluations during matchmaking that failed since the last report. This metric is limited to the top 50 rules. Units: Count Relevant CloudWatch statistics: Sum | ## Amazon GameLift Servers metrics for FleetIQ FleetIQ metrics The `Amazon GameLift` namespace includes metrics for FleetIQ game server group and game server activity as part of a FleetIQ standalone solution for game hosting. The Amazon GameLift Servers service sends metrics to CloudWatch every minute. Also see [Monitoring your Auto Scaling groups and instances using amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) in the *Amazon EC2 Auto Scaling User Guide*. | Metric | Description | | --- | --- | | `AvailableGameServers` | Game servers that are available to run a game execution and are not currently occupied with gameplay. This number includes game servers that have been claimed but are still in AVAILABLE status. Units: Count Relevant Amazon CloudWatch statistics: Sum Dimensions: GameServerGroup | | `UtilizedGameServers` | Game servers that are currently occupied with gameplay. This number includes game servers that are in UTILIZED status. Units: Count Relevant Amazon CloudWatch statistics: Sum Dimensions: GameServerGroup | | `DrainingAvailableGameServers` | Game servers on instances scheduled for termination that are currently not supporting gameplay. These game servers are the lowest priority to be claimed in response to a new claim request. Units: Count Relevant Amazon CloudWatch statistics: Sum Dimensions: GameServerGroup | | `DrainingUtilizedGameServers` | Game servers on instances scheduled for termination that are currently supporting gameplay. Units: Count Relevant Amazon CloudWatch statistics: Sum Dimensions: GameServerGroup | | `PercentUtilizedGameServers` | Portion of game servers that are currently supporting game executions. This metric indicates the amount of game server capacity that is currently in use. It is useful for driving an Auto Scaling policy that can dynamically add and remove instances to match with player demand. Units: Percent Relevant Amazon CloudWatch statistics: Average, Minimum, Maximum Dimensions: GameServerGroup | | `GameServerInterruptions` | Game servers on Spot Instances that were interrupted due to limited Spot availability. Units: Count Relevant Amazon CloudWatch statistics: Sum Dimensions: GameServerGroup, InstanceType | | `InstanceInterruptions` | Spot Instances that were interrupted due to limited availability. Units: Count Relevant Amazon CloudWatch statistics: Sum Dimensions: GameServerGroup, InstanceType | # Monitor with server telemetry metrics Monitor with server telemetry metrics Amazon GameLift Servers can be configured to collect and publish telemetry metrics for game servers running on managed Amazon EC2 and Container fleets. These metrics become available after deploying the telemetry collector with your server build. The metrics system supports all SDKs (C\$1\$1, C\$1, Go), all plugins (Unreal, Unity), and the Amazon GameLift Servers Game Server Wrapper. Metrics data flows to [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html), [Monitor Amazon GameLift Servers with Amazon CloudWatch](monitoring-cloudwatch.md), and [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) dashboards (recommended for visualization). ![\[telemetry_metrics\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/images/telemetry_metrics.png) ## Benefits of telemetry metrics The telemetry metrics system offers five key benefits: + **Game engine-specific metrics** — Game engine plugins (Unreal, Unity) provide native integration with engine-specific performance metrics such as server tick time, frame rate, and engine-level resource utilization that are critical for game performance optimization. + **Custom metrics support** — Define and track your own game-specific metrics using server SDK function calls to monitor custom gameplay events, business logic performance, and application-specific data points that matter to your game. + **Automated collection** — Metrics flow automatically after telemetry collector deployment with no additional instrumentation required and direct integration with [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) and Amazon CloudWatch. + **Multi-level monitoring** — Fleet-level metrics for capacity and scaling, instance-level metrics for resource utilization, and game session metrics for performance tracking. + **Universal compatibility** — Works with all Amazon GameLift Servers-supported development environments, integrated with all server SDKs, and native support in game engine plugins. **Note** Telemetry metrics are available for Amazon GameLift Servers managed Amazon EC2 or container fleets running Amazon Linux 2023 or Windows. ## Before you begin ### Required AWS resources + AWS account configured for Amazon GameLift Servers. + Managed fleet running on: + Amazon EC2 with supported operating systems, OR + Containers with Amazon Linux 2023 + Appropriate IAM permissions ### IAM requirements The following IAM permissions are required only if you plan to use the corresponding service: + **[Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html)** (required only if publishing metrics to Prometheus) + `aps:RemoteWrite` permission + Access to your Prometheus workspace + **Amazon CloudWatch** (required only if publishing metrics to Amazon CloudWatch) + `cloudwatch:PutMetricData` permission + Access to metrics namespaces + **[Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html)** (required only if using Grafana dashboards) + `grafana:Read` permission + SSO configuration for dashboard access # Implementation Implementation Select your implementation path based on your development environment: ## SDK implementation | SDK Type | SDK Setup | Custom Metrics | API Reference | | --- | --- | --- | --- | | Go SDK | [Complete Setup Guide](https://github.com/amazon-gamelift/amazon-gamelift-servers-go-server-sdk/blob/main/telemetry-metrics/METRICS.md) | [Go Metrics API](https://github.com/amazon-gamelift/amazon-gamelift-servers-go-server-sdk/blob/main/telemetry-metrics/CUSTOM_METRICS.md) | [Go Actions and Data Types](https://docs.aws.amazon.com/gamelift/latest/developerguide/integration-server-sdk-go-actions.html) | | C\$1 SDK | [Complete Setup Guide](https://github.com/amazon-gamelift/amazon-gamelift-servers-csharp-server-sdk/blob/main/telemetry-metrics/METRICS.md) | [C\$1 Metrics API](https://github.com/amazon-gamelift/amazon-gamelift-servers-csharp-server-sdk/blob/main/telemetry-metrics/CUSTOM_METRICS.md) | [C\$1 Actions and Data Types](https://docs.aws.amazon.com/gamelift/latest/developerguide/integration-server-sdk5-csharp-actions.html) | | C\$1\$1 SDK | [Complete Setup Guide](https://github.com/amazon-gamelift/amazon-gamelift-servers-cpp-server-sdk/blob/main/telemetry-metrics/METRICS.md) | [C\$1\$1 Metrics API](https://github.com/amazon-gamelift/amazon-gamelift-servers-cpp-server-sdk/blob/main/telemetry-metrics/CUSTOM_METRICS.md) | [C\$1\$1 Actions and Data Types](https://docs.aws.amazon.com/gamelift/latest/developerguide/integration-server-sdk5-cpp-actions.html) | ## Plugin implementation | Plugin | Plugin Setup | Custom Metrics | API Reference | | --- | --- | --- | --- | | Unreal | [Complete Setup Guide](https://github.com/amazon-gamelift/amazon-gamelift-plugin-unreal/blob/main/TelemetryMetrics/METRICS.md) | [Unreal Metrics API](https://github.com/amazon-gamelift/amazon-gamelift-plugin-unreal/blob/main/TelemetryMetrics/CUSTOM_METRICS.md) | [Unreal Actions and Data Types](https://docs.aws.amazon.com/gamelift/latest/developerguide/integration-server-sdk5-unreal-actions.html) | | Unity | [Complete Setup Guide](https://github.com/amazon-gamelift/amazon-gamelift-plugin-unity/blob/main/TelemetryMetrics/METRICS.md) | [Unity Metrics API](https://github.com/amazon-gamelift/amazon-gamelift-plugin-unity/blob/main/TelemetryMetrics/CUSTOM_METRICS.md) | [C\$1 Actions and Data Types](https://docs.aws.amazon.com/gamelift/latest/developerguide/integration-server-sdk5-csharp-actions.html) | ## Implementation workflow Each implementation follows a two-step process: 1. **Complete Setup Guide (METRICS.md)** — Infrastructure deployment, AWS infrastructure configuration, fleet setup, and Grafana dashboard configuration. 1. **API Implementation Guide (CUSTOM\$1METRICS.md)** — Language-specific SDK usage, metric types, custom metrics creation, and advanced configuration. ### Verification 1. Validate metrics flow by checking your [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) workspace or Amazon CloudWatch console for incoming telemetry data. 1. Check dashboard visibility in [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) using the pre-built dashboards. 1. Test custom metrics by verifying they appear in your monitoring dashboards. **Note** After completing implementation, return to this page and go to the [Available metrics](gamelift-servers-metrics-types.md) page. # Available metrics Available metrics Metrics fall into three categories: + Automatically collected metrics + SDK-provided metrics + Custom metrics ## Automatic metrics collection No code changes required for these metrics: ### Instance metrics | Metric Type | Description | Use Case | | --- | --- | --- | | CPU | Percentage utilization per instance | Resource monitoring | | Memory | Physical memory usage and percentage | Capacity planning | | Network I/O | Bytes and packets sent/received | Connection health | | Disk I/O | Read/write operations and throughput | Storage performance | ### Fleet metrics | Metric Type | Description | Use Case | | --- | --- | --- | | Active Instances | Running instances count | Fleet scaling | | Game Sessions | Active and available sessions | Capacity management | | Crashed game sessions | Game sessions that have crashed | Error monitoring | ## SDK-provided metrics Requires SDK function calls in your code: ### Server timing metrics | Metric | Description | Implementation | | --- | --- | --- | | Server Delta Time | Difference in time between the current server tick and the previous server tick. Measures the consistency of the server's tick rate | Call GetDeltaTime() | | Server Tick Rate | Shows the number of times per second the server is processing updates | Automatically calculated | | Server Tick Time | The amount of time it takes for the server to process a single tick or update | Call GetTickTime() | | Server World Tick Time | The amount of time it takes for the server to update the game world with each tick | Call GetWorldUpdateTime() | **Implementation:** For engine-agnostic SDKs (C\$1\$1, C\$1, Go), you implement these metrics by calling SDK functions from your game loop with calculated timing values. For engine plugins (Unreal, Unity), these metrics are captured automatically through engine integration. ### Network metrics | Metric | Description | Implementation | | --- | --- | --- | | Connections | The total number of network connections the server has established | Automatic after InitMetrics() | | Network I/O (Bytes) | The total number of bytes being sent and received by the server over the network | Automatic after InitMetrics() | | Network I/O (Packets) | The total number of network packets being sent and received by the server | Automatic after InitMetrics() | | Packet Loss | The percentage of network packets that are being lost during transmission | Automatic after InitMetrics() | **Implementation:** Integrate SDK function calls with your networking library. The SDK provides guidance for different network implementations. ### Process metrics | Metric | Description | Implementation | | --- | --- | --- | | CPU Usage (%) | The percentage of CPU resources being utilized by the game server process | Automatic after InitMetrics() | | Memory Usage (Units) | The total amount of memory being consumed by the server processes | Automatic after InitMetrics() | | Physical Memory Usage (%) | The percentage of the server's total physical memory that is currently being utilized | Automatic after InitMetrics() | | Server Status | Game server health state | Automatic after InitMetrics() | **Implementation:** These metrics are automatically collected by the SDK for each game session process. #### Per-process dashboard organization Per-process metrics are available in two specialized dashboards: + **Server Performance dashboard** — Contains server timings (delta time, tick rate, tick time, world tick time), network metrics (connections, I/O bytes/packets, packet loss), memory usage, and CPU usage for individual game sessions. + **Instance Performance dashboard** — Features "Top N Memory Consuming Game Sessions" and "Top N CPU Consuming Game Sessions" tables that help identify which processes contribute most to instance resource consumption. Clicking on Game Session links enables deeper investigation of detailed metrics. #### Per-process metrics use cases The per-process/per-game-session metrics support the following monitoring scenarios: + **Dive deep performance investigation** — When a host/instance has degraded performance due to specific processes or game sessions, per-process metrics help identify which process caused the issue through Top CPU and Memory consuming Game Sessions tables. + **Game server crash investigation** — When a game session crashes, these metrics help determine if the crash was due to out of memory, CPU overload, or network bandwidth problems. + **Investigate player reported issues** — When players report lag or interruptions during gameplay, per-process metrics help identify bottlenecks in CPU, memory, network, tick time, or world update time. + **Identify performance changes in different builds** — Tick time, tick rate, and world update time metrics allow developers to measure how game performance changes across different server builds. + **Detect delays and slowness in gameplay** — Tick time, tick rate, and world update time metrics reflect how fast the server updates the game, directly impacting customer experience. + **Benchmarking** — Identify how different game scenarios affect server performance based on factors like player count, game mode, and other variables. ## Dashboard organization Metrics are organized into specialized dashboards in [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) for different monitoring scenarios. The available dashboards depend on your fleet type: ### EC2 Fleet dashboards + **EC2 Fleet Overview dashboard** — High-level fleet capacity, scaling insights, concurrent players (CCU), instances, player capacity, and crashed game sessions. + **Instances Overview dashboard** — Aggregated host-level metrics across all instances including average CPU, memory, network, and disk utilization. + **Instance Performance dashboard** — Detailed metrics for individual instances with "Top N Memory Consuming Game Sessions" and "Top N CPU Consuming Game Sessions" tables for identifying resource-intensive processes. + **Server Performance dashboard (EC2)** — Game loop timing, network performance, memory, and CPU metrics for individual game sessions on EC2 instances. ### Container Fleet dashboards + **Container Fleet Overview dashboard** — High-level overview of container fleet resource utilization including CPU reservation, memory utilization, and container group status. + **Container Performance dashboard** — Detailed metrics for individual containers within specific ECS tasks including CPU utilization, memory usage, network I/O, and storage performance. + **Server Performance dashboard (Container)** — Game loop timing, network performance, memory, and CPU metrics for individual game sessions in containers. For detailed dashboard information and usage instructions, see [Dashboard organization and usage](gamelift-servers-metrics-dashboards.md). # How it works How it works The telemetry metrics system follows a simple four-stage data flow from your game servers to visualization dashboards. **Collection:** Your game server, integrated with the GameLift Server SDK or plugin, automatically emits metrics to a local telemetry collector running on the same instance. The SDK captures both automatic metrics (server lifecycle, resource usage) and custom metrics you define in your code. **Processing:** The telemetry collector aggregates metrics from your game server and combines them with instance-level performance data (CPU, memory, network, disk usage). This provides a complete picture of both your game's performance and the underlying infrastructure. **Storage:** Processed metrics are exported to your choice of metrics warehouse - [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) for high-performance time-series storage, Amazon CloudWatch for AWS service integration, or both. All data transmission is authenticated and encrypted. **Visualization:** [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) connects to your metrics warehouse to display pre-built GameLift dashboards. These dashboards provide fleet overviews, server performance details, and container monitoring views that help you monitor and troubleshoot your game hosting infrastructure. **Note** All metric transmission between your game server and the telemetry collector occurs locally on the instance for security. Only the collector communicates with AWS services using proper authentication. # Dashboard organization and usage Dashboard organization and usage View your metrics on comprehensive dashboards in [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html). The available dashboards depend on your fleet type: ## Dashboard availability by fleet type The following table shows which dashboards are available for each fleet type: | Dashboard | Fleet Type | Description | | --- | --- | --- | | EC2 Fleet Overview | EC2 Fleet | Displays information on concurrent players (CCU), instances and player capacity | | Instances Overview | EC2 Fleet | Displays average CPU, memory, and network utilization across all fleet instances | | Instance Performance | EC2 Fleet | Displays detailed metrics (CPU, memory, disk, network) for an individual instance | | Container Fleet Overview | Container Fleet | Displays average resource utilization of all containers in a managed container fleet | | Container Performance | Container Fleet | Displays detailed metrics of individual containers within a specific ECS task | | Server Performance | Both | Displays the network, memory and runtime performance of a specified game server process (separate versions for EC2 and Container fleets) | **Managed EC2 Fleets:** + EC2 Fleet Overview provides high-level fleet capacity and scaling insights. + Use Instances Overview and Instance Performance dashboards for host-level monitoring. + Metrics collected via hostmetrics receiver for system-level visibility. + Focus on EC2 instance resource utilization and performance. + Server Performance (EC2) monitors game server application metrics independent of underlying infrastructure. **Managed Container Fleets:** + Use Container Fleet Overview and Container Performance dashboards for ECS task and container-level monitoring. + Metrics collected via ECS Container Receiver for containerized workload visibility. + Focus on task-level aggregation and container resource isolation. + Server Performance (Container) monitors game server application metrics independent of underlying infrastructure. ## EC2 Fleet Overview dashboard This dashboard provides a high-level overview of your fleet's utilization and capacity globally and by location. It features graphs showing counts for game server stops, starts, and crashes, as well as the percentage of healthy game servers. You can filter by FleetID and Location. ### Fleet Overview metrics The following table shows the metrics available on the Fleet Overview dashboard: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/gamelift-servers-metrics-dashboards.html) **Note** CCU metrics require implementation in your game server code. These metrics are not automatically collected and must be implemented and reported by your application. ## Instances Overview dashboard This dashboard provides aggregated host-level metrics across all instances in your fleet. Current averages show overall health of the instances. When performance degrades, check CPU usage, memory consumption, network and disk consumption for bottlenecks. You can filter by FleetID and Location. ### Instances Overview metrics The following table shows the metrics available on the Instances Overview dashboard: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/gamelift-servers-metrics-dashboards.html) **Note** Instance-level metrics are collected via the hostmetrics receiver and provide system-level visibility into your fleet's infrastructure performance. Use this dashboard to identify overall fleet health trends and drill down to individual instances when performance issues are detected. ## Instance Performance dashboard This dashboard provides detailed performance metrics for individual instances. Current averages show overall instance health. When performance degrades, check CPU usage, memory consumption, and file system consumption for bottlenecks. It features "Top N Memory Consuming Game Sessions" and "Top N CPU Consuming Game Sessions" tables that help identify which processes contribute the most to instance resource consumption. Clicking on Game Session links enables deeper investigation of detailed metrics. You can filter by specific Instance ID. ### Instance Performance metrics The following table shows the metrics available on the Instance Performance dashboard: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/gamelift-servers-metrics-dashboards.html) **Note** The Top N Memory and CPU Consuming Game Sessions tables are essential for identifying performance bottlenecks and resource-intensive processes that may impact overall instance performance. These rankings enable quick identification of problematic game sessions for further investigation. ## Container Fleet Overview dashboard This dashboard provides a high-level overview of your container fleet's resource utilization and capacity. It displays average resource utilization of all containers in a managed container fleet, including CPU reservation, memory utilization, and container group status. You can filter by FleetID and Location. ### Container Fleet Overview metrics The following table shows the metrics available on the Container Fleet Overview dashboard: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/gamelift-servers-metrics-dashboards.html) **Note** Container fleet metrics are collected via ECS Container Receiver and provide containerized workload visibility with focus on task-level aggregation and container resource isolation. ## Container Performance dashboard This dashboard provides detailed performance metrics for individual containers within specific ECS tasks. It displays detailed metrics of individual containers including CPU utilization, memory usage, network I/O, and storage performance. You can filter by specific Container ID or ECS Task. ### Container Performance metrics The following table shows the metrics available on the Container Performance dashboard: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/gamelift-servers-metrics-dashboards.html) **Note** Container performance metrics provide detailed visibility into individual container resource consumption and performance characteristics within ECS tasks. ## Server Performance dashboard The Server Performance dashboard shows metrics related to server timings, network activity, memory, and CPU usage for individual game sessions. You can filter by Game Session ID and export metrics directly to Amazon CloudWatch or [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html). ### Server Performance metrics The following table shows the metrics available on the Server Performance dashboard: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/gamelift-servers-metrics-dashboards.html) # Common monitoring scenarios Common monitoring scenarios ## Dive deep performance investigation **Scenario:** A host/instance is having degraded performance due to specific processes or game sessions **Investigation steps:** + Access the Instance Performance dashboard. + Review "Top N Memory Consuming Game Sessions" table to identify which processes contribute the most to instance memory consumption. + Review "Top N CPU Consuming Game Sessions" table to identify which processes contribute the most to instance CPU utilization. + Click on Game Session links to enable deeper investigation of detailed metrics. + Analyze server timings (Server Delta Time, Server Tick Rate, Server Tick Time, Server World Tick Time) to identify performance bottlenecks. ## Game server crash investigation **Scenario:** A game session has crashed and you need to determine the root cause **Investigation steps:** + Access the Server Performance dashboard for the crashed game session. + Check Memory Usage (Units) and Physical Memory Usage (%) to determine if the crash was due to out of memory. + Review CPU Usage (%) to identify if CPU overload caused the crash. + Analyze Network I/O (Bytes) and Network I/O (Packets) to determine if network bandwidth problems contributed to the crash. + Examine Packet Loss percentage to identify network-related issues. ## Investigate player reported issues **Scenario:** Players report lag or interruption during gameplay **Investigation steps:** + Access the Server Performance dashboard for the affected game session. + Review Server Tick Time and Server World Tick Time to identify delays in game updates. + Check Server Tick Rate to ensure consistent server update frequency. + Analyze CPU Usage (%) to identify processing bottlenecks. + Review Memory Usage metrics to identify memory-related performance issues. + Check Network I/O metrics and Packet Loss to identify network bottlenecks. ## Identify performance changes in different game server builds **Scenario:** You want to measure how game performance changes across different server builds **Investigation steps:** + Compare Server Tick Time metrics between different builds to measure processing efficiency changes. + Analyze Server Tick Rate consistency across builds to identify performance regressions. + Review Server World Tick Time to measure game world update performance changes. + Compare Memory Usage patterns between builds to identify memory optimization improvements or regressions. + Monitor CPU Usage trends to assess computational efficiency changes. ## Detect delays and slowness in gameplay **Scenario:** You need to monitor server responsiveness and game update speed **Investigation steps:** + Monitor Server Tick Time to measure how fast the server processes each update cycle. + Track Server Tick Rate to ensure consistent game state updates per second. + Analyze Server World Tick Time to measure game world update speed, which directly impacts customer experience. + Set up alerts for Server Delta Time variations to detect inconsistent server performance. ## Benchmarking different game scenarios **Scenario:** You want to identify how different game scenarios affect server performance **Investigation steps:** + Compare server performance metrics across different player counts to understand scaling impact. + Analyze performance differences between game modes using Server Tick Time and CPU Usage metrics. + Monitor Memory Usage patterns across different game scenarios to identify resource-intensive features. + Track Network I/O metrics to understand bandwidth requirements for different gameplay scenarios. + Use the Instance Performance dashboard to identify which game scenarios produce the highest resource-consuming game sessions. ## High resource utilization response **Scenario:** Unusual resource spikes (CPU >85%, Memory >90%) **Investigation steps:** ### Identify affected resources + Use DescribeGameSessionDetails API. + Filter by Status if needed. + Document affected instances. ### Analyze resource usage + Review Instance Overview dashboard. + Compare utilization across fleet. + Check historical patterns. ### Monitor game server impact + Check Server Performance metrics. + Review tick times and packet loss. + Monitor memory leaks. ### Resolution steps + Download session logs. + Address build issues. + Monitor improvements. ## Game server crash analysis **Scenario:** Multiple error-status game sessions across fleet **Investigation steps:** ### Initial assessment + Access Fleet Overview dashboard. + Review crashed session table. + Note patterns in timing/location. ### Performance analysis + Check server timing metrics. + Review resource utilization. + Monitor network performance. ### Infrastructure review + Verify fleet capacity. + Check instance health. + Review scaling policies. ### Resolution path + Analyze server logs. + Review code optimization. + Implement fixes. ## Fleet capacity optimization **Scenario:** Game launch or benchmark study **Analysis steps:** ### Resource utilization + Filter by location. + Review P50/P95/P99 metrics. + Analyze usage patterns. ### Instance type analysis + Compare performance by type. + Identify scaling candidates. + Document utilization patterns. ### Optimization actions + Adjust scaling policies. + Modify instance types. + Update fleet configuration. # Troubleshooting guide Troubleshooting guide ## Common issues and resolution steps ### Missing or incomplete metrics #### Symptoms + No metrics appearing in dashboards. + Partial metric collection. + Delayed metric updates. #### Resolution steps ##### A. Verify collector status Check systemd service: ``` sudo systemctl status gamelift-telemetry-collector ``` Review collector logs: ``` sudo journalctl -u gamelift-telemetry-collector ``` + Confirm collector configuration. ##### B. IAM permission verification + Check instance role permissions. + Verify required policies: + `aps:RemoteWrite` + `cloudwatch:PutMetricData` + Validate role trust relationships. ##### C. Network connectivity + Verify endpoint access. + Check security group rules. + Review network ACLs. ### Authentication errors #### Symptoms + SigV4 authentication failures. + Access denied messages. + Credential refresh issues. #### Resolution steps ##### A. SigV4 authentication + Verify temporary credentials. + Check credential rotation. + Validate instance profile. ##### B. AMP access + Review workspace configuration. + Verify remote write URL. + Check IAM role bindings. ### Dashboard issues #### Symptoms + Empty dashboards. + Missing data points. + Authentication failures. #### Resolution steps ##### A. Data source configuration + Verify Prometheus connection. + Check Amazon CloudWatch integration. + Test data source permissions. ##### B. Grafana access + Confirm SSO configuration. + Verify 2FA setup if required. + Check user permissions. ### Windows-specific issues #### Symptoms + Service startup failures. + Metric collection gaps. + Permission errors. #### Resolution steps + Verify Windows service status. + Check Windows Event Logs. + Review collector configuration. + Validate Windows-specific paths. # Logging Amazon GameLift Servers API calls with AWS CloudTrail Logging API calls Amazon GameLift Servers is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in Amazon GameLift Servers. CloudTrail captures all API calls for Amazon GameLift Servers as events. The calls captured include calls from the Amazon GameLift Servers console and code calls to the Amazon GameLift Servers API operations. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for Amazon GameLift Servers. If you don't configure a trail, you can still view the most recent events in the CloudTrail console in **Event history**. Using the information collected by CloudTrail, you can determine the request that was made to Amazon GameLift Servers, the IP address from which the request was made, who made the request, when it was made, and additional details. To learn more about CloudTrail, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). ## Amazon GameLift Servers information in CloudTrail CloudTrail is enabled on your AWS account when you create the account. When activity occurs in Amazon GameLift Servers, that activity is recorded in a CloudTrail event along with other AWS service events in **Event history**. You can view, search, and download recent events in your AWS account. For more information, see [Viewing events with CloudTrail Event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html). For an ongoing record of events in your AWS account, including events for Amazon GameLift Servers, create a trail. A *trail* enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all AWS Regions. The trail logs events from all Regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs. For more information, see the following: + [Overview for creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) + [CloudTrail supported services and integrations](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html) + [Configuring Amazon SNS notifications for CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/configure-sns-notifications-for-cloudtrail.html) + [Receiving CloudTrail log files from multiple regions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) and [Receiving CloudTrail log files from multiple accounts](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html) All Amazon GameLift Servers actions are logged by CloudTrail and are documented in the *[Amazon GameLift Servers API Reference](https://docs.aws.amazon.com/gamelift/latest/apireference/)*. For example, calls to `CreateGameSession`, `CreatePlayerSession` and `UpdateGameSession` actions generate entries in the CloudTrail log files. Every event or log entry contains information about who generated the request. The identity information helps you determine the following: + Whether the request was made with root or AWS Identity and Access Management (IAM) user credentials. + Whether the request was made with temporary security credentials for a role or federated user. + Whether the request was made by another AWS service. For more information, see the [CloudTrail userIdentity element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html). ## Understanding Amazon GameLift Servers log file entries A trail is a configuration that enables delivery of events as log files to an Amazon S3 bucket that you specify. CloudTrail log files contain one or more log entries. An event represents a single request from any source and includes information about the requested action, the date and time of the action, request parameters, and so on. CloudTrail log files aren't an ordered stack trace of the public API calls, so they don't appear in any specific order. The following example shows a CloudTrail log entry that demonstrates the `CreateFleet` and `DescribeFleetAttributes` actions. ``` { "Records": [ { "eventVersion": "1.04", "userIdentity": { "type": "IAMUser", "principalId": "AIDACKCEVSQ6C2EXAMPLE", "arn": "arn:aws:iam::111122223333:user/myUserName", "accountId": "111122223333", "accessKeyId": AKIAIOSFODNN7EXAMPLE", "userName": "myUserName" }, "eventTime": "2015-12-29T23:40:15Z", "eventSource": "gamelift.amazonaws.com", "eventName": "CreateFleet", "awsRegion": "us-west-2", "sourceIPAddress": "192.0.2.0", "userAgent": "[]", "requestParameters": { "buildId": "build-92b6e8af-37a2-4c10-93bd-4698ea23de8d", "eC2InboundPermissions": [ { "ipRange": "10.24.34.0/23", "fromPort": 1935, "protocol": "TCP", "toPort": 1935 } ], "logPaths": [ "C:\\game\\serverErr.log", "C:\\game\\serverOut.log" ], "eC2InstanceType": "c5.large", "serverLaunchPath": "C:\\game\\MyServer.exe", "description": "Test fleet", "serverLaunchParameters": "-paramX=baz", "name": "My_Test_Server_Fleet" }, "responseElements": { "fleetAttributes": { "fleetId": "fleet-0bb84136-4f69-4bb2-bfec-a9b9a7c3d52e", "serverLaunchPath": "C:\\game\\MyServer.exe", "status": "NEW", "logPaths": [ "C:\\game\\serverErr.log", "C:\\game\\serverOut.log" ], "description": "Test fleet", "serverLaunchParameters": "-paramX=baz", "creationTime": "Dec 29, 2015 11:40:14 PM", "name": "My_Test_Server_Fleet", "buildId": "build-92b6e8af-37a2-4c10-93bd-4698ea23de8d" } }, "requestID": "824a2a4b-ae85-11e5-a8d6-61d5cafb25f2", "eventID": "c8fbea01-fbf9-4c4e-a0fe-ad7dc205ce11", "eventType": "AwsApiCall", "recipientAccountId": "111122223333" }, { "eventVersion": "1.04", "userIdentity": { "type": "IAMUser", "principalId": "AIDACKCEVSQ6C2EXAMPLE", "arn": "arn:aws:iam::111122223333:user/myUserName", "accountId": "111122223333", "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "userName": "myUserName" }, "eventTime": "2015-12-29T23:40:15Z", "eventSource": "gamelift.amazonaws.com", "eventName": "DescribeFleetAttributes", "awsRegion": "us-west-2", "sourceIPAddress": "192.0.2.0", "userAgent": "[]", "requestParameters": { "fleetIds": [ "fleet-0bb84136-4f69-4bb2-bfec-a9b9a7c3d52e" ] }, "responseElements": null, "requestID": "82e7f0ec-ae85-11e5-a8d6-61d5cafb25f2", "eventID": "11daabcb-0094-49f2-8b3d-3a63c8bad86f", "eventType": "AwsApiCall", "recipientAccountId": "111122223333" }, ] } ``` # Logging server messages in Amazon GameLift Servers Logging server messages You can capture custom server messages from your Amazon GameLift Servers servers in log files. The way you configure logging depends on whether you use custom servers or Amazon GameLift Servers Realtime, and whether you're using managed EC2 fleets or container fleets (see the appropriate subsections in this chapter). **Topics** + [ # Logging differences: Managed EC2 vs Container fleets ](logging-server-messages-ec2-vs-containers.md) + [ # Logging server messages (custom servers) ](logging-server-messages-custom.md) # Logging differences: Managed EC2 vs Container fleets EC2 vs Container logging Logging behavior differs significantly between managed EC2 fleets and container fleets. Understanding these differences is crucial when migrating from EC2 to containers or choosing the right fleet type for your logging requirements. ## Key differences overview | Feature | Managed EC2 Fleets | Container Fleets | | --- | --- | --- | | Log storage | Automatically uploaded to Amazon S3 after game session ends | Must configure Amazon CloudWatch Logs or custom logging solution | | GetGameSessionLogUrl API | Available - returns Amazon S3 URL for log download | Not available - logs not automatically stored in Amazon S3 | | Log retention | 14 days in Amazon S3 (automatic) | Depends on your logging configuration | | Real-time monitoring | Limited - logs available only after game session ends | Available with Amazon CloudWatch Logs integration | | Setup complexity | Automatic - no additional configuration required | Requires explicit logging configuration | ## Managed EC2 fleet logging For managed EC2 fleets, Amazon GameLift Servers provides automatic log management: + **Automatic upload:** Server logs are automatically uploaded to Amazon S3 when a game session ends + **GetGameSessionLogUrl API:** Use this API to retrieve a pre-signed URL for downloading logs from Amazon S3 + **14-day retention:** Logs are retained in Amazon S3 for 14 days before automatic deletion + **Size limits:** Log files have size limits per game session (see [Amazon GameLift Servers endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/gamelift.html)) For more information, see [Logging server messages (custom servers)](logging-server-messages-custom.md) and the [GetGameSessionLogUrl API reference](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_GetGameSessionLogUrl.html). ## Container fleet logging Container fleets require you to configure logging explicitly: + **No automatic Amazon S3 upload:** Logs are not automatically uploaded to Amazon S3 + **GetGameSessionLogUrl not available:** This API does not work with container fleets + **Amazon CloudWatch Logs integration:** Configure your container to send logs to Amazon CloudWatch Logs for centralized logging + **Custom logging solutions:** Implement your own logging infrastructure using log drivers or sidecar containers + **Real-time access:** With proper configuration, logs can be accessed in real-time during game sessions For detailed container logging options, see [How container fleets work](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/containers-howitworks.html). ## Migration considerations When migrating from managed EC2 to container fleets, consider these logging changes: + **Update log retrieval code:** Replace GetGameSessionLogUrl API calls with Amazon CloudWatch Logs queries or your custom logging solution + **Configure log retention:** Set up appropriate retention policies in Amazon CloudWatch Logs or your logging system + **Implement real-time monitoring:** Take advantage of real-time log access for better observability + **Review log volume and costs:** Amazon CloudWatch Logs pricing differs from the included Amazon S3 storage in managed EC2 fleets ## Recommended container logging setup For container fleets, we recommend: 1. **Amazon CloudWatch Logs integration:** Configure your container definition to use the `awslogs` log driver 1. **Structured logging:** Use structured log formats (JSON) for better searchability and analysis 1. **Log levels:** Implement appropriate log levels to control verbosity and costs 1. **Retention policies:** Set retention periods based on your compliance and debugging needs # Logging server messages (custom servers) Logging for custom servers You can capture custom server messages from your Amazon GameLift Servers custom servers in log files. **Important** There is a limit on the size of a log file per game session (see [Amazon GameLift Servers endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/gamelift.html) in the *AWS General Reference*). When a game session ends, Amazon GameLift Servers uploads the server logs to Amazon Simple Storage Service (Amazon S3). Amazon GameLift Servers will not upload logs that exceed the limit. Logs can grow very quickly and exceed the size limit. You should monitor your logs and limit the log output to necessary messages only. ## Configuring logging for custom servers With Amazon GameLift Servers custom servers, you write your own code to perform logging, which you configure as part of your server process configuration. Amazon GameLift Servers uses your logging configuration to identify the files that it must upload to S3 at the end of each game session. The following instructions show how to configure logging using simplified code examples: ------ #### [ C\$1\$1 ] **To configure logging (C\$1\$1)** 1. Create a vector of strings that are directory paths to game server log files. ``` std::string serverLog("serverOut.log"); // Example server log file std::vector logPaths; logPaths.push_back(serverLog); ``` 1. Provide your vector as the [LogParameters](integration-server-sdk-cpp-ref-datatypes.md#integration-server-sdk-cpp-ref-dataypes-log) of your [ProcessParameters](integration-server-sdk-cpp-ref-datatypes.md#integration-server-sdk-cpp-ref-dataypes-process) object. ``` Aws::GameLift::Server::ProcessParameters processReadyParameter = Aws::GameLift::Server::ProcessParameters( std::bind(&Server::onStartGameSession, this, std::placeholders::_1), std::bind(&Server::onProcessTerminate, this), std::bind(&Server::OnHealthCheck, this), std::bind(&Server::OnUpdateGameSession, this), listenPort, Aws::GameLift::Server::LogParameters(logPaths)); ``` 1. Provide the [ProcessParameters](integration-server-sdk-cpp-ref-datatypes.md#integration-server-sdk-cpp-ref-dataypes-process) object when you call [ProcessReady()](integration-server-sdk-cpp-ref-actions.md#integration-server-sdk-cpp-ref-processready). ``` Aws::GameLift::GenericOutcome outcome = Aws::GameLift::Server::ProcessReady(processReadyParameter); ``` For a more complete example, see [ProcessReady()](integration-server-sdk-cpp-ref-actions.md#integration-server-sdk-cpp-ref-processready). ------ #### [ C\$1 ] **To configure logging (C\$1)** 1. Create a list of strings that are directory paths to game server log files. ``` List logPaths = new List(); logPaths.Add("C:\\game\\serverOut.txt"); // Example of a log file that the game server writes ``` 1. Provide your list as the [LogParameters](integration-server-sdk-csharp-ref-datatypes.md#integration-server-sdk-csharp-ref-dataypes-log) of your [ProcessParameters](integration-server-sdk-csharp-ref-datatypes.md#integration-server-sdk-csharp-ref-dataypes-process) object. ``` var processReadyParameter = new ProcessParameters( this.OnGameSession, this.OnProcessTerminate, this.OnHealthCheck, this.OnGameSessionUpdate, port, new LogParameters(logPaths)); ``` 1. Provide the [ProcessParameters](integration-server-sdk-csharp-ref-datatypes.md#integration-server-sdk-csharp-ref-dataypes-process) object when you call [ProcessReady()](integration-server-sdk-csharp-ref-actions.md#integration-server-sdk-csharp-ref-processready). ``` var processReadyOutcome = GameLiftServerAPI.ProcessReady(processReadyParameter); ``` For a more complete example, see [ProcessReady()](integration-server-sdk-csharp-ref-actions.md#integration-server-sdk-csharp-ref-processready). ------ ## Writing to logs Your log files exist after your server process has started. You can write to the logs using any method to write to files. To capture all of your server's standard output and error output, remap the output streams to log files, as in the following examples: ------ #### [ C\$1\$1 ] ``` std::freopen("serverOut.log", "w+", stdout); std::freopen("serverErr.log", "w+", stderr); ``` ------ #### [ C\$1 ] ``` Console.SetOut(new StreamWriter("serverOut.txt")); Console.SetError(new StreamWriter("serverErr.txt")); ``` ------ ## Accessing server logs Log access varies by fleet type: ### Managed EC2 fleets When a game session ends, Amazon GameLift Servers automatically stores the logs in an S3 bucket and retains them for 14 days. To get the location of the logs for a game session, you can use the [GetGameSessionLogUrl](https://docs.aws.amazon.com/gamelift/latest/apireference/API_GetGameSessionLogUrl.html) API operation. To download the logs, use the URL that the operation returns. Alternatively, you can set up your own logging solution by configuring your game server to send logs directly to your preferred logging service or storage location. For more information, see [Connect your Amazon GameLift Servers hosted game server to other AWS resources](gamelift-sdk-server-resources.md). ### Container fleets Container fleets capture standard output and error streams from all containers. You can configure logging using one of these options: + Save container output as CloudWatch log streams in a specified log group + Save container output to an S3 storage bucket + Turn off logging (container output isn't saved) For detailed information about configuring logging options when creating container fleets, see [LogConfiguration](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_CreateContainerFleet.html#gameliftservers-CreateContainerFleet-request-LogConfiguration) in the Amazon GameLift Servers API Reference.