目次
通信、エラー数とストレージ要件
Backtraceに送られるクラッシュの数を制限したり、ストレージの必要量を減らしたりするにはどうすればいいですか?
エラー数
-
クライアントでクライアント側の重複排除を有効にすることで、同じエラーが何度も送信されるのを防ぐことができます。
-
クライアントでログエラーサンプリングを使用して、Backtraceに送信されるログ(Debug.LogError)の数を制限することができます。
- レポートをフィルタリングして、必要なものだけを送信することができます。
- SkipReportやBeforeSendデリゲートを使用することで、特定のエラーを送信させないことができます。
-
サブミッショントークンを使って、古いバージョンのエラーを無効にすることができます。
ストレージ容量
-
サーバーのエラーサンプリングを使用して、「同じフィンガープリントの場合、1分ごとに1つの新しいエラーのインスタンスだけを保存する」など、ストレージに保存されるエラーの数を制限することができます。
-
送信アクションを設定することで、さまざまなエラーを無視するためのルールを設定することができます。送信アクションの設定により、ストレージの使用量は減りますが、送信されるエラーの数は減りませんのでご注意ください。
-
シンボルファイルをBacktraceにアップロードするとコールスタックが見やすくなるだけでなく、より多くのエラーを重複排除できるようになることで、ストレージを削減するのに有効です。
-
リテンションポリシーを設定することで定義された期間の後にデータを削除することができます。
クラッシュログが削除されるとどうなりますか?その場合でもエラーを検索することはできますか?
ストレージの要件を減らすために、Backtraceはリテンションポリシーを使用して、一定期間後にクラッシュレポートを削除します。スタンダードプランの場合、リテンションポリシーのデフォルト設定は3ヶ月間です。
では、そのあとはどうなるのでしょうか。
まず、クラッシュが削除されるとデバッグ画面でクラッシュログの詳細を見ることができなくなります。
しかし、Backtrace は類似のクラッシュをfingerprint(指紋)にまとめます。同じfingerprintを持つ、別のクラッシュログが存在すれば、新しいログの詳細はデバッグ画面で確認できます。
そして、クラッシュレポートが削除されてもクラッシュのインデックス化された属性(メタデータ)ははまだ保持されます。
つまり、検索したり、トリアージステータスを追跡したり、デバッグ画面を表示する以外のことは基本的にできます。
では、例を見てみましょう。
クラッシュログが削除されると、オブジェクトに"_deleted"属性が付きます。
このスクリーンショットでは、fingerprint #57690f73 (下の赤い箱)のクラッシュがすべて削除されています。クラッシュの検索、トリアージステータスの追跡、タグの割り当てなどはまだ可能ですが、デバッグ画面でクラッシュの詳細を見ることはできません。
ただし、fingerprint #5d22204a(上の赤箱)では、ログの約 35% が残っています。古いクラッシュの詳細は見れませんが、新しいクラッシュログの詳細を見ることはできます。

シンボルファイル(dsymやsoなど)は、クラウドのストレージ上限にカウントされますか?
シンボルをBacktraceインスタンスにアップロードすると、ストレージの総使用量にカウントされます。
Backtraceインスタンスの代わりに独自のシンボルサーバーを構築することもできます。
シンボルサーバーの詳細についてはこちらをご覧ください。
ソースコードはクラウドストレージの上限に含まれますか?
いいえ、ソースコードはストレージの制限には含まれません。
エラーが送信されていない場合でも、クライアントはBacktraceと通信しますか?通信する場合は、エラー数の上限にカウントされますか?
アプリケーションを起動時に通信を行い、その後、一定の間隔でBacktraceと通信し、クラッシュの安定性を追跡します。エラー数の上限にカウントされません。デフォルトでは、30分に1回送信されますが、設定を変更したり、無効にしたりすることができます。
詳細については、READMEファイルを参照してください。
デバイスがオフラインの状態でエラーが発生した場合はどうなりますか?
設定方法に基づいて再試行します。また、起動時にエラーの送信を試みることもできます。
詳細については、READMEファイルを参照してください。
セキュリティ
Backtraceはオンプレミスで運用できますか?
できます。詳細はお問い合わせ窓口までお問い合わせください。
ソースコードだけ、オンプレミスでホスティングできますか?
できます。詳細はお問い合わせ窓口までお問い合わせください。
Backtraceは、DRMやアンチチートツールをサポートしていますか?
Backtraceは、Denuvoを含むいくつかのDRMツールで動作します。
お使いのツールが動作するかどうかを確認するには、サンプルのクラッシュを作成してテストするか、support@backtrace.ioにお問い合わせください。
Backtraceはシングルサインオン(SSO)に対応していますか?
対応しています。 Backtraceは、SAMLを使用するすべてのサービスで動作します。
詳しくはこちらをご覧ください。
ユーザーおよびプロジェクト管理
チームメンバーが特定のプロジェクトにしかアクセスできないように制限することは可能ですか?
可能です。詳しくはこちらをご覧ください。
プロジェクトを削除できないのはなぜですか?
現在プロジェクトの削除ができません。お困りの場合はsupport@backtrace.ioにお問い合わせください。
ネイティブ・クラッシュ
なぜネイティブ・クラッシュがBacktraceコンソールに表示されないのですか?
受信されていることを確認するために、まずForceCrashを呼び出してみることをお勧めします。
UnityEngine.Diagnostics.Utils.ForceCrash(UnityEngine.Diagnostics.ForcedCrashCategory.Abort);
[DllImport("backtrace-native", EntryPoint = "Crash")]
public static extern void NativeCrash();
クラッシュが発生しない場合は、Backtraceのコンフィグレーションが正しく設定されているか確認してください。
設定内容はプラットフォームによって若干異なる場合があります。詳細については、READMEファイルをご覧ください。
BacktraceはIL2CPP、ネイティブのクラッシュ、システムクラッシュをサポートしていますか?
はい、サポートしています。詳細については、READMEファイルをご覧ください。
ネイティブのクラッシュでシンボルを見るにはどうしたらいいですか?
まず、シンボルファイルをBacktraceにアップロードしてください。シンボルファイルはプロジェクト設定の「シンボル」画面からアップロードすることができます。シンボルを適用するにはプロジェクト設定画面から「オブジェクト再処理」にアクセスし、行うオブジェクトの日付範囲を選択し、「オブジェクトを再処理」ボタンをクリックします。

外部ライブラリの場合など、Backtraceにシンボルファイルをアップロードしても表示されないことがあります。Client side unwindingを有効にすると、これらのシンボルについてより多くの情報を得ることができます。

Backtraceはアプリケーションが反応しない(Application not responding/ANR)によるクラッシュをサポートしていますか?
Backtraceには、AndroidとiOSのハングレポートをキャプチャするオプションがあります。オプションを有効にすると、アプリケーションが5秒以上応答しない場合にレポートが生成されます。

Backtraceはメモリ(Out of Memory/OMM)によるクラッシュをサポートしていますか?
OOMクラッシュがサポートされています。

モバイル以外のプラットフォームでは、OOM クラッシュが表示されますが、メモリ警告情報が利用できない場合があり、その場合は ANR クラッシュと同じように表示されます。
OOM(Out of Memory)例外を検索するにはどうすればいいですか?
Android
OOM クラッシュには error.type = crash と、OOM クラッシュであることを示す memory.warning 属性があります。
iOS
OOM クラッシュはerror.type=Low Memoryとなります。

error.typeを検索できない場合は、error.type属性をインデックス化する必要があるかもしれません。詳しくはこちらをご覧ください。
ソースコードの統合
git/p4のソースコードは、mono C#だけでなく、IL2CPPのクラッシュでも統合できますか?
IL2CPPの場合、ソースコードタブにファイルが表示されますが、エラーが発生した行番号が表示されません。
クラッシュしたソースコードの正しいバージョンを使用するにはどうすればいいですか?
Backtraceでは、ソースコードの「バージョン」に変数を入力することができ、エラー時にリンクするソースコードのバージョンをBacktraceが特定できるようになっています。例えば、{application.version}を使用して、バージョン番号を含むgitタグにリンクすることができます。また、コミットハッシュなどのバージョン情報をカスタムBacktrace属性にリンクすることで、コードの正しいバージョンを確実に取得することができます。

デバッグビューでソースコードファイルが表示されないのはなぜですか?
"Not enough information to locate source code"というメッセージが表示される原因はいくつか考えられます。
- コードがゲームリポジトリの外にある。例えば、関数Debug.LogErrorの内部はUnityのコードベースの一部であり、表示されません。
- ソースコードのバージョンが利用できない。例えば、ソースコードは「master」にしかアクセスできないが、コードが別のブランチにあったり、チェックインされていなかったりする。
- コールスタックに、ファイルの場所を推測するのに十分な情報がない。
サポートをご希望の場合は、support@backtrace.ioにお問い合わせください。その際、ソースコードが表示されていないデバッグ画面のURLをお知らせください。
エラー属性とインデックス
属性の検索ができないのはなぜですか?
属性を検索するにはインデックス化する必要があります。属性をインデックス化する方法については、こちらをご覧ください。
属性をインデックス化しましたが、古いログはまだ検索できません。どうしたらいいですか?
プロジェクト設定の「オブジェクト再処理中」画面から古いエラーログにインデックスを適用することができます。

Backtraceに収集させたくない属性を無効にすることはできますか?
できます。UnityのデフォルトでBacktraceが収集する属性のリストはこちらをご覧ください。
送信したくない属性がある場合は、data.Annotation.EnvironmentVariables辞書を操作することで、設定を変更することができます。詳しくは、READMEをご覧ください。
エラーレポートのエクスポート
Backtraceは、エラーデータを取得するためのAPIを提供していますか?
Backtraceデータのエクスポートにはいくつかのオプションがあります。
- morgueツールで
とコマンドを実行するとエラーをcsvレポートに取り込むことができます。morgue list --csv=
- Datadog/Circonus/Graphiteなどのツールにデータをエクスポートすることができます。
- WebhookにPOSTリクエストでエラーを送信することもできます。