目次
初めに
Backtraceを実装する場合、最初のライブ リリースがおそらく最も重要なマイルストーンになります。初めてBacktraceを使用してアプリのクラッシュを特定し修正することができます。しかし、リリースする前に不安を抱えていることはないでしょうか？
- Backtrace 設定はライブ環境用に正しくセットアップされていますか？
- どのようなエラー量が予想されますか？
- ライブ環境で最も重要なエラーを見つけるにはどうしたらいいですか？
この記事では、最初のリリースを成功させるために従うべき、基本的なベストプラクティスを共有します。
プレワーク
この記事は、Backtraceインスタンスをセットアップして、エラーを受け取ることができたと仮定しています。紹介する事例の多くはUnityに特化したものですが、Unity以外のプロジェクトにも適用できます。
セットアップについては、Backtrace UnityのREADMEファイルを参照してください。
プロジェクトのセットアップ
セットアップが完了していれば、Backtraceコンソール内にプロジェクトが表示され、エラーが報告されています。しかし、本番用のBacktraceプロジェクトをどのようにセットアップすれば、リリース後にスケールアップできるのか、疑問に思うかもしれません。開発用と本番用でプロジェクトを分けた方がいいのか、iOS用とAndroid用、プラットフォームごとに分けた方が良いのかなど、Backtraceのプロジェクトをどう作成していいか、悩む所ですね。
プロジェクトはいくつでも自由に作成できます。ただし、各プロジェクトにはワークフローの統合、属性、シンボルアーカイブ、送信トークンなどいくつかの設定が存在します。
複数の異なるプロジェクトに分かれている場合、各プロジェクトですべての設定を適切に行う必要があります。また、クラッシュレポートのデータも別々のプロジェクトになるため、各プロジェクトのエラーを比較することが困難になります。
そして、unname.sysnameや独自のカスタムの属性を使うことで、同じプロジェクト内であっても環境ごとにエラーをフィルタリングすることもできます。
これらの理由から、一般的にはアプリケーションごとに単一のBacktraceプロジェクトを持つことが推奨されます。
シンボルのアップロード
クライアントがクラッシュすると、Backtraceにクラッシュレポートが送られ、メモリ上のどこでクラッシュが発生したかについての情報が提供されます。シンボルアーカイブがない場合、クラッシュレポートにはメモリアドレスのみ表示され、意味のあるスタックトレースを得ることは困難です。
シンボルアーカイブはメモリアドレスをソースコードにマッピングしてくれます。バイナリファイルをビルドするときに作成され、Backtraceにアップロードできます。
シンボルアーカイブをアップロードすると、クラッシュコールスタック内の関数名、ファイルパス、行番号などの情報を確認できます。類似のエラーを効率的にグループ化するためにも必要です。そしてBacktraceはシンボル情報を使用してエラーを重複排除するため、クラッシュレポートに必要なストレージの量を大幅に削減することもあります。
特に本番用のバイナリのバージョンでは、シンボルアーカイブを必ずBacktraceにアップロードしましょう。
プロジェクト設定の「シンボルアーカイブ」画面からシンボルアーカイブをBacktraceにアップロードできます。
Windowsバイナリの場合、シンボルファイル（.symまたは.pdbフォーマット）と、対応する.exeまたは.dllファイルの両方を.zipファイルにして、アップロードするようにしてください。
Androidの場合、"Create symbols.zip" を選択し、.zipファイルをBacktraceにアップロードしてください。
iOSの場合は、xcodeプロジェクトで"DWARF with dSYM files"を生成するように設定してください。iOSのビルドが完了すると、...\Build\Products\<フォルダー名>にdsymファイルが保存されます。フォルダーの中のファイルをzipフォルダに圧縮して、Backtraceにアップロードしてください。
シンボルをアップロードした後、「オブジェクトの再処理」画面から、既存のクラッシュレポートに適用することができます。
シンボルの詳細については、Symbolicationを参照してください。
属性を使ったエラーの検索
リリースの後、様々な種類の属性を使用してエラーを検索できます。また、カスタム属性を作成して検索することも可能です。例えば、このスクリーンショットでは、カスタムの「region」属性を使用して日本で発生したエラーを検索しています。
検索クエリで属性を使用するには、属性をレポートに追加し、Backtrace属性を検索用にインデックス化する必要があります。
- クラッシュレポートに属性が含まれていることを確認します。
- クエリで使用できるように、プロジェクト設定の「属性」画面から属性のインデックスを作成します。
- プロジェクト設定の「オブジェクトの再処理」画面からエラーレポートを再処理します。すると既存のエラーレポートに属性インデックスが適用されます。
属性の詳細については、Attributesを参照してください。
ワークフローインテグレーションを追加
Slack、JIRA、メールなどのツールを通じて、新しいエラーを通知することができます。バグチケットの管理や、問題が再び発生した場合の再オープンの支援もできます。
弊社がサポートするサードパーティサービスをご利用の場合は、統合を設定することをお勧めします。
詳細についてはこちらを参照してください。
プロジェクト内のBacktrace設定を再度確認
UnityプロジェクトのBacktraceクライアントには設定が色々ありますが、本番環境用に合わせて変更した方がいい設定もあります。
例えば、
- クライアント側の重複排除(Client-side Deduplication)を有効にする
- クライアントはエラーのコピーを1つだけ送信することができ、Backtraceに送信されるエラーの量を減らすことができます。
- ログのサンプリング(Log sampling)率を10%以下に設定する
- 開発段階では、すべてのログをBacktraceに送信すると便利ですが、ライブ環境では、エラー量の大幅な増加を引き起こす可能性があります。また、フィルタリングして、デバッグログを送信しないこともできます。
- クライアントサイド・アワインディング(client-side unwinding)を有効にする
- Backtraceが重複したエラーを減らすのに役立ち、スタック トレースのシンボルが利用できない場合に、より意味のあるエラーレポートを提供することができます。
- 無視したいエラーを"SkipReport"または"BeforeSend"デリゲートを使用して送信する前にフィルタリングする
- エラーの量を減らすことができます。
- スクリーンショットを送信する必要がない場合は、"Send screenshot "のチェックを外す
- エラーの保存に必要なストレージの量を減らすことができます。
サンプリングとリテンションポリシーを確認
プロジェクト設定の「ストレージ」セクションでクラッシュレポートを保持する期間のルールを設定することができます。また、サンプリングルールを設定することもできます。サンプリングルールは時間の経過とともに同じレポートの複数のコピーを削除することで、必要なストレージ使用量を大幅に削減してくれます。
デフォルトの保持ポリシーでは、クラッシュレポートは30日後に圧縮され、90日後に削除されます。レポート削除後のクラッシュレポートデータの扱いについては、こちらをご覧ください。その他の詳細についてはこちらを参照してください。
ニーズに合わせてポリシーの設定の手伝いはできますので、不明点ございましたらBacktraceサポートにご連絡ください。
プランの確認
アプリを公開する前に、プランが予想されるエラーの数に対応できるかどうかを確認しましょう。
想定されるエラー量はセッション数とセッションごとのエラー数によって異なります。例えば、1ヶ月に1000万セッションあり、そのうちの10%がエラーレポートを送ったとすると、1ヶ月に約100万件のエラーボリュームが予想されます。
どのプランを選択するかについては、Unityのお問い合わせ窓口、またはBacktraceのサポートにお問い合わせいただくことをお勧めします。場合によってはアプリリリース後のモニタリングを行い、適したプランを決定することも可能です。
リリースの予定日を事前にBacktraceに連絡
アプリのリリースする予定がきまりましたら、Backtraceサポートにご連絡いただけるとBacktrace側でもインスタンスを監視することができます。
何かあった時はサポートに連絡
リリース後に気になること等ございましたらBacktraceのサポートにお問い合わせください。
