専用サーバーのクラッシュを分析する（ベータ版）
注釈：本資料はAI技術を用いて翻訳されています。
Server Crashes はクローズドベータ版で、AccelByte Gaming Services (AGS) Public Cloud でのみ利用できます。デフォルトでは有効になっておらず、AccelByte がリクエストに応じてゲームネームスペースごとに有効化します。アクセスをリクエストするには、お問い合わせください。機能、フィールド、制限は一般提供開始までに変更される場合があります。
概要
AccelByte Multiplayer Servers（AMS）のフリート内の専用サーバー（DS）がクラッシュすると、AMS はそのサーバーを置き換え、プレイヤーが引き続き利用可能なサーバーにマッチングされるようにします。AGS Admin Portal の Server Crashes 機能は、各クラッシュを記録し、その原因を特定するために必要な以下の情報を提供します。
- クラッシュイベント：クラッシュしたすべてのサーバーの記録。終了コード、フリート、リージョン、イメージ、セッションが含まれます。
- コールスタック：各クラッシュに至った関数呼び出しの流れ。サーバーイメージとともにデバッグシンボルをアップロードした場合は、関数名と行番号が表示されます。
- クラッシュのグループ化：同じコールスタックを持つクラッシュイベントは 1 つのクラッシュにまとめられるため、最も頻繁に発生している問題を優先して対応できます。
- デバッグファイル：クラッシュした各サーバーのコアダンプとサーバーログ。いずれもダウンロードできます。
- クラッシュメトリクス：クラッシュイベントの推移、クラッシュフリーサーバー率、メモリ不足により終了したサーバー数、最も多い終了コード。
Server Crashes を利用するために、SDK やサードパーティのクラッシュレポーターは必要ありません。AMS は仮想マシン（VM）からコアダンプとログを直接収集し、収集した各コアダンプをコールスタックに変換します。
この記事では、以下の方法について説明します。
- クラッシュレポート用にサーバーイメージとフリートを設定する
- Admin Portal でクラッシュを表示および調査する
- 各クラッシュイベントの結果を解釈し、よくある問題を解決する
Server Crashes の仕組み
- 専用サーバーが 0 以外の終了コードで終了するか、セグメンテーション違反（
SIGSEGV）などのシグナルによって終了します。AMS はこの終了をクラッシュイベントとして記録します。 - フリートでコアダンプの収集が有効になっている場合、AMS は VM からコアダンプとサーバーログをアップロードします。アップロードは通常、クラッシュから 1～3 分以内に完了します。
- AMS は、サーバーイメージとともにアップロードされたデバッグシンボルを使用して、コアダンプをコールスタックに変換します。
- AMS は、同じコールスタックを持つ既存のクラッシュにクラッシュイベントを追加するか、新しいクラッシュを作成します。
セッションのタイムアウトや応答しないサーバーの削除など、AMS 自身が実行した終了は、クラッシュイベントとして記録されません。
前提条件
- ゲームネームスペースで Multiplayer パッケージが有効になっていること。
- ゲームネームスペースで Server Crashes が有効になっていること。クローズドベータ期間中にアクセスをリクエストするには、お問い合わせください。
- AMS 上で専用サーバービルドを実行しているフリートがあること。詳細については、AMS を始めるを参照してください。
- AGS コマンドラインインターフェース（CLI）がインストールされ、ゲームネームスペースにサインインしていること。AGS CLI には、デバッグシンボル付きのサーバーイメージをアップロードする AMS コマンドが含まれています。詳細については、インストールとサインインを参照してください。スタンドアロンの AMS CLI を引き続き使用している場合は、代わりに
--symbolFilesフラグを付けてams uploadを使用するか、AMS CLI からの移行を参照してください。 - ゲームネームスペースで以下の権限を持っていること。
| タスク | 権限 | アクション |
|---|---|---|
| Server Crashes の表示とファイルのダウンロード | ADMIN:NAMESPACE:{namespace}:AMS:ARTIFACT | Read |
| フリートのコアダンプ収集率の変更 | ADMIN:NAMESPACE:{namespace}:AMS:ARTIFACT | Update |
| クラッシュからフリートとサーバーの詳細を開く | ADMIN:NAMESPACE:{namespace}:ARMADA:FLEET | Read |
| サーバーイメージのアップロード | AMS:UPLOAD | Create、Update |
AMS:ARTIFACT に対する Read アクションを持たないユーザーには、Server Crashes メニューは表示されません。詳細については、Admin Portal に必要な権限を参照してください。
AMS:UPLOAD は ADMIN:NAMESPACE:{namespace}: プレフィックスを付けずに入力してください。Identity and Access Management（IAM）クライアントで AGS CLI にサインインする場合は、そのクライアントにこの権限が必要です。ユーザーアカウントでサインインする場合は、ユーザーロールにこの権限が必要です。デフォルトの AMS Access ロールではサーバーイメージを管理できますが、AMS:UPLOAD は含まれていません。
主な用語
| 用語 | 定義 |
|---|---|
| クラッシュイベント | ステータス Crashed（0 以外の終了コードまたは終了シグナル）または Start error（サーバープロセスの起動に失敗）で終了した 1 台の専用サーバーの記録。 |
| クラッシュ | 同じコールスタックを持つクラッシュイベントのグループ。各クラッシュは、SRV-12 などの ID とともに Crashes タブに一覧表示されます。 |
| コアダンプ | クラッシュ時点のサーバープロセスのメモリのスナップショット。AMS がコールスタックを生成するにはコアダンプが必要です。 |
| デバッグシンボル | ビルドによって生成されるファイルで、メモリアドレスを関数名、ソースファイル、行番号に対応付けます。 |
| コールスタック | クラッシュに至った関数呼び出しの流れ。サーバープロセスのスレッドごとに記録されます。 |
| クラッシュフリーサーバー | 選択した期間中にクラッシュせずに稼働したサーバーの割合。 |
クラッシュレポートを設定する
クラッシュイベントは、デフォルトですべてのフリートで記録されます。コールスタックを生成してクラッシュをグループ化するには、以下の手順を完了してください。設定が完了するまで、Server Crashes ページには Set up crash reporting チェックリストが表示されます。
ステップ 1：専用サーバーがコアダンプを書き込めるようにする
Linux では、プロセスが SIGSEGV や SIGABRT などのシグナルによって終了すると、コアダンプが書き込まれます。専用サーバーがこれを許可するように設定されていることを確認してください。
- サーバーイメージや起動スクリプトで、コアファイルのサイズ制限を
0に設定しないでください（例：ulimit -c 0）。 - サーバーが致命的なエラーを内部で処理する場合は、0 以外の終了コードで終了するようにしてください。終了コード
0は正常なシャットダウンとして扱われ、クラッシュとして記録されません。
メモリ不足などにより SIGKILL で終了したサーバーは、コアダンプを生成しません。これらのクラッシュイベントは記録されますが、コールスタックはありません。
ステップ 2：デバッグシンボル付きでサーバーイメージをアップロードする
デフォルトでは、ags ams upload は拡張子が .debug、.sym、.pdb のシンボルファイルをイメージから除外します。これらを含めるには、--symbol-files フラグを追加します。エンジンの Linux ビルドで生成されたデバッグファイルが、アップロードするディレクトリに配置されていることを確認してください。
- Server Crashes がバイナリと対応付けられるように、分離されたデバッグファイルは末尾を
.debugにするか、実行ファイルの.gnu_debuglinkセクションで指定された名前にする必要があります。 - Unity：
--symbol-filesフラグにより、UnityPlayer_s.debugとasu_s.debugがアップロードされます。IL2CPP ビルドの場合、行番号ファイルLineNumberMappings.jsonは常にアップロードされます。 - Unreal Engine： パッケージ化された Linux サーバービルドでは、
<Project>/Binaries/Linux/内のサーバーバイナリの隣に<Project>Server.debugと<Project>Server.symが書き込まれます。--symbol-filesフラグにより、両方がアップロードされます。Server Crashes は.debugファイルを使用し、.symファイルは無視します。.debugファイルはバイナリの隣に置いたままにしてください。DefaultEngine.iniでbPreservePSYM=Trueを設定しないでください。設定すると.debugファイルが.psymファイルに置き換えられ、このファイルはアップロードも使用もされません。
イメージをアップロードするたびに、デバッグシンボルファイルを含めてください。シンボルはイメージとビルド ID に基づいてクラッシュと照合されます。また、アップロード済みのイメージに後からシンボルを追加することはできません。シンボルがない場合、コールスタックには関数名ではなくメモリオフセットが表示され、そのクラッシュには Missing symbols というラベルが付きます。
ags ams upload --path <path_to_server_folder> --executable <exec_command> \
--image-name <image_name> --symbol-files
AGS CLI は、実行ファイルから CPU アーキテクチャを検出します。エントリポイントがシェルスクリプト（.sh）の場合は、--target-arch linux-x86_64 も追加してください。シンボルファイルを含め、どのファイルがアップロードされるかを確認するには、--dry-run を追加します。ドライランはローカルで実行され、サインインは不要です。すべてのアップロードオプションを表示するには、ags ams upload --help を実行します。
デバッグファイルはサーバーバイナリの数倍のサイズになることがあるため、--symbol-files を付けたアップロードには時間がかかります。
ステップ 3：フリートでコアダンプの収集を有効にする
フリートがコアダンプを収集するのは、その Core dumps on crash サンプリングルールが有効になっている場合のみです。
- Admin Portal で作成したフリートは、デフォルトでクラッシュしたサーバーからコアダンプを収集します。フリートフォームの Logs & Artifacts Sampling セクションでは、コアダンプのオプションに On by default というラベルが表示されます。
- API または CLI で作成したフリートと既存のフリートでは、コアダンプの収集を有効にする必要があります。API で有効にするには、
samplingRules.coredumps.crashedを{ "collect": true, "percentage": 100 }に設定します。詳細については、サンプリングルールを参照してください。
Admin Portal で既存のフリートのコアダンプ収集率を変更するには、以下の手順に従います。
- Admin Portal のサイドバーで、Multiplayer Servers > Server Crashes に移動します。
- Crash reporting settings をクリックします。
- Core dump collection セクションで、フリートごとに Core dumps from crashed servers を設定します。すべてのフリートに同じ収集率を適用するには、Set all fleets to で収集率を選択し、Set for all fleets をクリックします。
収集率を変更する際に、フリートを無効化する必要はありません。新しい収集率は次のクラッシュから適用されます。フリートの詳細ページの Core dump collection セクションで Change をクリックして、収集率を変更することもできます。
すべてのクラッシュイベントにコールスタックが含まれるように、収集率を 100% に設定してください。収集率を 100% 未満にすると、クラッシュしたサーバーのうちその割合のサーバーのみがコアダンプを保持し、残りのクラッシュイベントには Skipped by sampling というラベルが付きます。フリートのコアダンプの量を見積もるには、Crashes that would write a core dump, last 7 days 列を参照してください。
また、各クラッシュイベントにサーバーログの最後の行が含まれるように、Logs on crash の収集も有効にしておいてください。
設定を確認する
次のクラッシュが発生したら、Server Crashes ページを開きます。クラッシュイベントは Crash events タブにすぐに表示されます。コアダンプとログは通常数分以内に利用可能になり、その後にコールスタックが表示されます。処理時間は、コアダンプのサイズが大きいほど長くなります。
クラッシュを表示および調査する
Server Crashes ページを開く
Admin Portal のサイドバーで、Multiplayer Servers > Server Crashes に移動します。
ページ上部のサマリータイルは、過去 7 日間を対象としています。コアダンプの収集を変更したり、デバッグシンボルのアップロード手順を表示したりするには、Crash reporting settings をクリックします。
この期間中に、コアダンプを収集せずにクラッシュを記録したフリートがある場合は、該当するフリートを一覧表示した警告が Review fleets リンクとともに表示されます。
サマリータイル
| タイル | 説明 |
|---|---|
| Crash events, last 7 days | クラッシュイベントの数と、直前の同じ長さの期間からの増減。 |
| Crash-free servers | 期間中にクラッシュせずに稼働したサーバーの割合。 |
| Killed (SIGKILL) | メモリ不足により終了した、または AMS によって停止されたサーバーの数。これらのサーバーはコアダンプを生成しません。 |
| Top exit code | 最も多い終了コードと、その終了コードを持つクラッシュイベントの数。 |
サマリータイルのデータは、クラッシュの一覧より数分遅れて反映される場合があります。
Crashes タブ
Crashes タブには、クラッシュが一覧表示されます。各クラッシュは、同じコールスタックを持つクラッシュイベントのグループです。最も頻繁に発生している問題を特定するには、このタブを使用します。
- このタブには、Crash（タイトルと最上位の関数）、Events、First seen、Last seen の各列が表示されます。
- 一覧を絞り込むには、Search by title or function を使用するか、Missing symbols only を選択します。
SIGKILLによる終了、エラー終了、コアダンプのないクラッシュなど、コールスタックのないクラッシュイベントはクラッシュに割り当てられません。これらのイベントは Crash events タブにのみ表示されます。
クラッシュの詳細を表示するには、そのクラッシュをクリックします。クラッシュの詳細ページには、以下の情報が含まれます。
- Summary：イベント、サーバー、セッションの数と、クラッシュが最初および最後に確認された日時。
- Event breakdown：By fleet（フリート別）および By image（イメージ別）のイベントの分布。行を選択すると、イベントの一覧が絞り込まれます。
- 選択したイベントの詳細（コールスタックやログを含む）。矢印ボタンでイベント間を移動するか、View all events をクリックしてクラッシュ内のすべてのイベントを一覧表示します。
- All events：クラッシュ内のクラッシュイベントの完全な一覧。
Crash events タブ
Crash events タブには、クラッシュした各サーバーが新しい順に一覧表示されます。
- デフォルトでは、Time、Server、Image、Exit code、Reason、Result の各列が表示されます。Fleet、Region、Session ID、Core dump、Log、Call stack の各列を表示するには、Columns をクリックします。
- 一覧は、期間、フリート、環境（Fleets only または Development servers）、イメージ、リージョン、終了コード、理由（Crashed または Start error）、コアダンプのステータス（Collected、Skipped by sampling、Failed、Expired、または Not collected）で絞り込むことができます。
- サーバー ID で検索するには、8 文字以上を入力します。
選択したフィルターはページの URL に保存されるため、リンクをコピーすることで絞り込んだビューを共有できます。
クラッシュイベントの詳細
クラッシュイベントの詳細を表示するには、そのサーバー ID をクリックします。イベントビューには、イベントのサーバー、イメージ、フリート、リージョン、終了コード、セッションが表示され、以下のタブが含まれます。
- Call stack：クラッシュしたスレッドのフレーム。First frame with source から表示されます。それより上のランタイムフレームは、デフォルトでは非表示です。表示するには、Show runtime frames above it をクリックします。別のスレッドを表示するには、Thread セレクターを使用します。
- Modules：プロセスに読み込まれたバイナリ、そのビルド ID、およびシンボルが見つかったかどうか。
- Log：クラッシュ前にサーバーが書き込んだ最後の行と、エンジンのクラッシュレポートのクラッシュメッセージ（利用可能な場合）。ログ全体をダウンロードするには、Download logs (.zip) をクリックします。
- Server & files：DS ID、フリート、イメージ、リージョン、IP アドレス、セッション ID、終了コード、および Core dump と Logs のファイルとそのサイズおよび有効期限。
- Server history：起動からクラッシュまでのサーバーの状態遷移（Creating、Ready、Claimed、Removed）。
このページには、以下のアクションも用意されています。
- Download core dump：
gdbなどのデバッガーでローカル分析するために、コアダンプをダウンロードします。 - Reprocess：処理が失敗した後などに、コールスタックを再生成します。
- Open fleet、View server details、Copy server ID：関連するフリートまたはサーバーを開くか、サーバー ID をコピーします。
- Turn on collection または Change sampling rate：フリートがコアダンプを保持しなかった場合に表示されます。
クラッシュ情報は、フリートのページからも確認できます。フリート一覧には、各フリートの Crash events, 24 h 列とコアダンプ収集率が表示されます。フリートの詳細ページには View crashes リンクがあり、クラッシュしたサーバーの詳細ページには View crash event リンクがあります。
クラッシュイベントの結果
Result 列とクラッシュイベントの詳細ページのヘッダーには、AMS が各クラッシュイベントをどのように処理したかが表示されます。
| 結果 | 説明 | 推奨される対応 |
|---|---|---|
| Grouped | コールスタックが利用可能で、イベントがクラッシュに割り当てられています。 | クラッシュを開いて、そのすべてのイベントを表示します。 |
| Processing | コアダンプをコールスタックに変換しています。 | 数分待ってから、ページを更新します。 |
| Waiting for core dump upload | サーバーがクラッシュし、そのコアダンプをアップロードしています。 | アップロードが完了するまで待ちます。2 時間以内にコアダンプが届かない場合、イベントはコアダンプなしとして扱われます。 |
| Missing symbols | イメージがデバッグシンボルなしでアップロードされました。コールスタックにはモジュール名とオフセットのみが表示されます。 | 次にイメージをアップロードする際に、デバッグシンボルを含めます。ステップ 2：デバッグシンボル付きでサーバーイメージをアップロードするを参照してください。 |
| No core dump · error exit | サーバーがエラーの終了コードで終了したため、コアダンプは書き込まれませんでした。 | サーバーログを確認して、終了の原因を特定します。 |
| No core dump · killed | サーバーがメモリ不足により SIGKILL で終了したか、AMS によって停止されました。 | サーバーのメモリ使用量とフリートのインスタンスタイプを確認します。 |
| No core dump · collection off | フリートでコアダンプの収集が無効になっています。 | コアダンプの収集を有効にします。ステップ 3：フリートでコアダンプの収集を有効にするを参照してください。 |
| Skipped by sampling | フリートはクラッシュしたサーバーのうち一定の割合からのみコアダンプを収集する設定になっており、このサーバーは対象に選ばれませんでした。 | 収集率を 100% に設定します。 |
| No core dump found | 通常はコアダンプを生成するシグナルによってサーバーが終了しましたが、VM 上にコアダンプが見つかりませんでした。 | コアファイルのサイズ制限が 0 に設定されていないことを確認します。ステップ 1：専用サーバーがコアダンプを書き込めるようにするを参照してください。 |
| No call stack · core dump failed | AMS がコアダンプを収集できませんでした。理由がわかる場合は、ページに表示されます。 | 理由を確認します。問題が解決しない場合は、サーバー ID を添えて AccelByte サポートにお問い合わせください。 |
| Not processed · limit reached | フリートで、同じイメージのクラッシュが 1 時間以内に 50 件を超えました。処理キューを保護するため、それ以降のコアダンプは処理されません。 | ローカル分析のためにコアダンプをダウンロードするか、Reprocess をクリックします。 |
| Processing failed | コアダンプをコールスタックに変換できませんでした。理由がページに表示されます。 | 表示された理由を解決してから、Reprocess をクリックします。 |
| Not processed · crashed before launch | ネームスペースでクラッシュレポートが有効になる前にクラッシュが発生しました。 | Reprocess をクリックしてコールスタックを生成します。 |
| Status unavailable | 現在、コールスタックのステータスを取得できません。AMS からのクラッシュの詳細は引き続き表示されます。 | 後でもう一度お試しください。 |
データの保持と制限
- コアダンプとログは、クラッシュから 30 日間保持された後に削除されます。ファイルが削除された後も、コールスタックとログの抜粋はクラッシュイベントの詳細ページで引き続き確認できます。
- Server Crashes ページには、最大で過去 30 日間のデータが表示されます。
- コールスタックは、x86-64 Linux サーバー（
linux-x86_64）でのみ生成されます。ARM64 イメージ（linux-arm_64）を実行するフリートでは、クラッシュイベント、コアダンプ、ログは記録されますが、コールスタックは生成されません。 - 非圧縮時のサイズが 16 GiB を超えるコアダンプは、コールスタックに変換されません。これらのコアダンプは、引き続きダウンロードしてローカルで分析できます。
- VM の障害によって失われたサーバーについては、クラッシュイベントが記録されない場合があります。
トラブルシューティング
クラッシュイベントにコールスタックがない
クラッシュイベントの Result を確認し、クラッシュイベントの結果の推奨される対応に従ってください。最も一般的な原因は、コアダンプの収集が無効になっていること、収集率が 100% 未満であること、SIGKILL による終了です。
開発用に AMS に登録されたローカル専用サーバーはコアダンプやログを収集できないため、そのクラッシュイベントにコールスタックが含まれることはありません。コールスタックを取得するには、フリート上でクラッシュを再現してください。
コールスタックに関数名ではなくメモリアドレスが表示される
サーバーイメージがデバッグシンボルなしで、または別のビルドのシンボルファイルとともにアップロードされています。同じビルドのシンボルファイルとともに新しいイメージをアップロードし、新しいイメージを使用するようにフリートを更新してください。詳細については、新しい DS バージョンに更新するを参照してください。
アップロードする前に、--dry-run を付けて ags ams upload を実行し、シンボルファイルが含まれていることを確認してください。
Unreal Engine を使用している場合は、ビルド内のサーバーバイナリの隣に .debug ファイルがあることを確認してください。Shipping ビルドには、デフォルトでデバッグファイルが含まれていない場合があります。それでもコールスタックにメモリアドレスが表示される場合は、お問い合わせください。
同じ問題によるクラッシュが別々のグループになる
デバッグシンボルのないイメージからのクラッシュは、コールスタックにメモリオフセットしか含まれないため、イメージごとにグループ化されます。同じ問題によるクラッシュがイメージをまたいでまとめてグループ化されるように、デバッグシンボル付きでイメージをアップロードしてください。
停止したサーバーが一覧に表示されない
Server Crashes には、ステータス Crashed または Start error で終了したサーバーのみが表示されます。正常終了（終了コード 0）、セッションのタイムアウト、AMS によって停止された応答しないサーバーは、クラッシュイベントとして記録されません。これらの終了を確認するには、Multiplayer Servers > Fleet Manager に移動してフリートを開き、Dedicated Server List セクションの History タブをクリックします。このタブには、過去 30 日間のフリートのサーバーが最終ステータスとともに一覧表示されます。
クラッシュが繰り返された後、フリートで新しいサーバーの起動が遅くなる
フリート内のサーバーが繰り返しクラッシュすると、AMS は新しいサーバーを起動するまでの待機時間を延長します（クラッシュバックオフ）。フリートの詳細ページには、クラッシュバックオフ中のサーバー数が表示されます。クラッシュの原因を解決してから、新しいイメージをアップロードしてください。