Firebase Crashlytics データを BigQuery にエクスポートして、詳細に分析できます。BigQuery では、BigQuery SQL を使用してデータを分析できます。また、データを別のクラウド プロバイダにエクスポートできるほか、可視化や Looker Studio のカスタム ダッシュボードでデータを使用できます。
エクスポートされたデータで可能な操作
BigQuery へのエクスポートでは、デバイスの種類、オペレーティング システム、例外（Android アプリ）またはエラー（Apple アプリ）、Crashlytics ログなど、未加工のクラッシュ データを利用できます。 エクスポートされる Crashlytics データとそのテーブルのスキーマについては、このページの後半で詳しく説明します。
エクスポートされる Crashlytics データでできることの例を次に示します。
クエリを実行する
Crashlytics データに対してクエリを実行することで、クラッシュ イベント データを、より簡単に理解できる概要に集約するレポートを生成できます。これらのタイプのレポートは Firebase コンソールの Crashlytics ダッシュボードでは利用できないため、クラッシュ データの分析と理解を補完できます。このページの後半で、クエリの例をご覧ください。Looker Studio テンプレートを使用する
Crashlytics エクスポートされたデータを可視化するための事前構築済みの Looker Studio テンプレートを提供します。ビューを作成する
BigQuery UI を使用して、SQL クエリで定義された仮想テーブルである「ビュー」を作成できます。さまざまな種類のビューとその作成方法の詳細な手順については、BigQuery ドキュメントをご覧ください。
BigQuery への Crashlytics ストリーミング エクスポート
BigQuery ストリーミングを使用すると、Crashlytics データをリアルタイムでストリーミングできます。ライブ ダッシュボードでの情報の表示、ライブでのロールアウトの監視、アラートやカスタム ワークフローをトリガーするアプリケーション問題のモニタリングなど、ライブデータが必要なあらゆる目的で使用できます。
BigQuery への Crashlytics ストリーミング エクスポートを有効にすると、バッチテーブルに加えてリアルタイム テーブルも作成されます。この 2 つのテーブルには次の違いがあります。
| バッチテーブル | リアルタイム テーブル |
|---|---|
|
|
バッチテーブルには書き込み前のイベントが永続的に保存されるため、このテーブルは長期分析で経時的な傾向を識別する場合に適しています。また、最大で 30 日前まで遡ってテーブルのバックフィルを行うことができます*。リアルタイム テーブルに書き込まれたデータはすぐに BigQuery に書き込まれるため、ライブ ダッシュボードやカスタム アラートにはリアルタイム テーブルが適しています。この 2 つのテーブルを合成クエリで組み合わせると、両方のメリットを利用できます。
デフォルトでは、リアルタイム テーブルのパーティションの有効期限は 30 日間です。これを変更する方法については、BigQuery ドキュメントのパーティションの有効期限を設定するをご覧ください。
* バックフィルのサポートの詳細については、新しいエクスポート インフラストラクチャにアップグレードするをご覧ください。
BigQuery へのエクスポートを有効にする
Firebase コンソールで、[統合] ページに移動します。
[BigQuery] カードで [リンク] をクリックします。
画面上の指示に従って、BigQuery へのエクスポートを有効にします。
BigQuery の Crashlytics データにほぼリアルタイムでアクセスする場合は、ストリーミング エクスポートへのアップグレードを検討してください。
BigQuery への Crashlytics のストリーミング エクスポートを有効にする
Firebase コンソールで、[統合] ページに移動します。
[BigQuery] カードで [管理] をクリックします。
[ストリーミングを含む] チェックボックスをオンにします。
この操作により、リンクされたすべてのアプリでストリーミングが有効になります。
エクスポートを有効にした場合の影響
データセットのロケーションを選択します。データセットの作成後はロケーションを変更できませんが、データセットを別のロケーションにコピーするか、データセットを別のロケーションに手動で移動（再作成）することはできます。詳細については、既存のエクスポートのロケーションを変更するをご覧ください。
このロケーションは、BigQuery にエクスポートされたデータにのみ適用されます。Firebase コンソールの Crashlytics ダッシュボードや Android Studio で使用するために保存されたデータのロケーションには影響しません。
デフォルトでは、プロジェクト内のすべてのアプリが BigQuery にリンクされ、後からプロジェクトに追加するアプリもすべて BigQuery に自動的にリンクされます。データを送信するアプリを管理することもできます。
Firebase は、BigQuery へのデータの毎日の同期を設定します。
通常、プロジェクトをリンクした後、最初のデータセットが BigQuery にエクスポートされる翌日の同期まで待つ必要があります。
毎日の同期は、BigQuery でスケジュール設定したエクスポートに関係なく、1 日 1 回行われます。同期ジョブのタイミングと所要時間は変更される可能性があるため、エクスポートの特定のタイミングに基づいてダウンストリーム オペレーションやジョブをスケジュールすることはおすすめしません。
Firebase は BigQuery に既存データのコピーをエクスポートします。エクスポートするデータの初回の読み込みには、最長で 48 時間かかる場合があります。
各リンク済みアプリでは、このエクスポートには毎日の同期によるデータを含むバッチテーブルも含まれます。
過去 30 日間または BigQuery へのエクスポートを有効にした最新の日付まで（どちらか最新のほう）、バッチテーブルのデータ バックフィルは手動でスケジュールできます。
2024 年 10 月中旬より前に Crashlytics データのエクスポートを有効にした場合は、エクスポートを有効にした日から 30 日前までバックフィルすることもできます。
Crashlytics から BigQuery へのストリーミング エクスポートを有効にすると、すべてのリンク済みアプリに常に更新されるデータを含むリアルタイム テーブルも作成されます。
BigQuery へのエクスポートを無効にするには、Firebase コンソールでプロジェクトのリンクを解除します。
クエリの例
例 1: 日別のクラッシュ数を確認する
修正するバグがほとんどなくなり、チームは新しい写真共有アプリをリリース可能な状態になったと考えました。しかし、リリース前に、過去 1 か月間の 1 日あたりの障害件数を確認し、バグバッシュでアプリが時間とともに安定してきたことを確認したいと考えています。
Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。
SELECT COUNT(DISTINCT event_id) AS number_of_crashes, FORMAT_TIMESTAMP("%F", event_timestamp) AS date_of_crashes FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` GROUP BY date_of_crashes ORDER BY date_of_crashes DESC LIMIT 30;
例 2: 最も多いクラッシュを確認する
生産計画の優先順位を正しく判断するため、アプリで最も発生頻度の高いクラッシュの上位 10 件を特定しようとしています。関連するデータポイントを提供するクエリを作成します。
Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。
SELECT DISTINCT issue_id, COUNT(DISTINCT event_id) AS number_of_crashes, COUNT(DISTINCT installation_uuid) AS number_of_impacted_user, blame_frame.file, blame_frame.line FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` WHERE event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(),INTERVAL 168 HOUR) AND event_timestamp < CURRENT_TIMESTAMP() GROUP BY issue_id, blame_frame.file, blame_frame.line ORDER BY number_of_crashes DESC LIMIT 10;
例 3: クラッシュ数が多い上位 10 台のデバイスを特定する
秋は新しいスマートフォンのシーズンです。この季節はまた、新しいデバイス固有の問題が多発する時期でもあります（特に Android の場合）。今後起きる可能性がある互換性の問題を事前に把握するため、先週（168 時間）最も多く障害が発生した 10 台のデバイスを特定するクエリを作成しました。
Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。
SELECT device.model, COUNT(DISTINCT event_id) AS number_of_crashes FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` WHERE event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR) AND event_timestamp < CURRENT_TIMESTAMP() GROUP BY device.model ORDER BY number_of_crashes DESC LIMIT 10;
例 4: カスタムキーでフィルタリングする
あるゲーム デベロッパーが、ゲームのどのレベルで最も多くの障害が発生するかを調べようとしています。
この統計情報をトラッキングするため、current_level というカスタム Crashlytics キーを設定し、ユーザーが新しいレベルに到達するたびに更新します。
Swift
Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");
Objective-C
CrashlyticsKit setIntValue:3 forKey:@"current_level";
Java
Crashlytics.setInt("current_level", 3);
BigQuery へのエクスポートの対象キーを使用して、各クラッシュ イベントに関連付けられた current_level 値の分布を報告するクエリを作成できます。
Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。
SELECT
COUNT(DISTINCT event_id) AS num_of_crashes,
value
FROM
`PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
UNNEST(custom_keys)
WHERE
key = "current_level"
GROUP BY
key,
value
ORDER BY
num_of_crashes DESC例 5: ユーザー ID を抽出する
Android アプリの早期アクセスを有効にしています。ほとんどのユーザーは問題なく利用していますが、3 人のユーザーから異常な数の障害件数が報告されました。根本的な原因を突き止めるため、これらのユーザーの ID を使用して障害イベントを取得するクエリを作成しました。
Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。
SELECT *
FROM
`PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
user.id IN ("USER_ID_1", "USER_ID_2", "USER_ID_3")
ORDER BY
user.id
例 6: 特定のクラッシュ問題が発生しているすべてのユーザーを抽出する
チームが誤って、ベータ版テスターのグループに重大なバグをリリースしてしまいました。チームは、上記の「最も多いクラッシュを確認する」の例のクエリを使用して、クラッシュ問題の ID を特定し、このクラッシュの影響を受けたアプリユーザーのリストを抽出するクエリを実行しました。
Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。
SELECT user.id as user_id
FROM
`PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
issue_id = "ISSUE_ID"
AND application.display_version = "APP_VERSION"
AND user.id != ""
ORDER BY
user.id;例 7: クラッシュの影響を受けたユーザーの数を国別にまとめる
新しいリリースのロールアウト中に重大なバグが見つかりました。上記の「最も多いクラッシュを確認する」の例のクエリを使用して、クラッシュ問題の ID を特定し、次に、このクラッシュが世界的にどのように影響しているのかを確認します。
このクエリを作成するために、次の作業を行う必要があります。
Google Analytics データの BigQuery へのエクスポートを有効にする詳しくは、プロジェクト データを BigQuery にエクスポートするをご覧ください。
ユーザー ID を Google Analytics SDK と Crashlytics SDK の両方に渡すようにアプリを更新します。
Swift
Crashlytics.sharedInstance().setUserIdentifier("123456789"); Analytics.setUserID("123456789");Objective-C
CrashlyticsKit setUserIdentifier:@"123456789"; FIRAnalytics setUserID:@"12345678 9";Java
Crashlytics.setUserIdentifier("123456789"); mFirebaseAnalytics.setUserId("123456789");ユーザー ID フィールドを使用して、Google Analytics データセットのイベントと Crashlytics データセットのクラッシュを結合するクエリを作成します。
Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と
IOS（パッケージ名とANDROIDの代わりに）を使用します。SELECT DISTINCT c.issue_id, a.geo.country, COUNT(DISTINCT c.user.id) as num_users_impacted FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` c INNER JOIN `PROJECT_ID.analytics_TABLE_NAME.events_*` a on c.user.id = a.user_id WHERE c.issue_id = "ISSUE_ID" AND a._TABLE_SUFFIX BETWEEN '20190101' AND '20200101' GROUP BY c.issue_id, a.geo.country, c.user.id
例 8: 今日ここまでの上位 5 件の問題
Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。
SELECT issue_id, COUNT(DISTINCT event_id) AS events FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME` WHERE DATE(event_timestamp) = CURRENT_DATE() GROUP BY issue_id ORDER BY events DESC LIMIT 5;
例 9: DATE 以降から今日までの上位 5 件の問題
バッチテーブルとリアルタイム テーブルを合成クエリと組み合わせて、信頼性の高いバッチデータにリアルタイム情報を追加することもできます。event_id が主キーであるため、DISTINCT event_id を使用して 2 つのテーブルで共通するイベントの重複を排除できます。
Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。
SELECT issue_id, COUNT(DISTINCT event_id) AS events FROM ( SELECT issue_id, event_id, event_timestamp FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME` UNION ALL SELECT issue_id, event_id, event_timestamp FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`) WHERE event_timestamp >= PARSE_TIMESTAMP("%Y_%m_%d", "YYYY_MM_DD") GROUP BY issue_id ORDER BY events DESC LIMIT 5;
Looker Studio でエクスポートされた Crashlytics データを可視化する
Looker Studio を使用すると、BigQuery の Crashlytics データセットを、見やすく簡単に共有できるうえ、全面的なカスタマイズも可能なレポートに変換できます。
Looker Studio を使用する方法について詳しくは、スタートガイドをご覧ください。
Crashlytics レポート テンプレートを使用する
Looker Studio には、エクスポートされた Crashlytics BigQuery スキーマからの包括的なディメンションと指標のセットを含む Crashlytics のサンプル レポートがあります。BigQuery への Crashlytics のストリーミング エクスポートを有効にしている場合、エクスポートされたデータは Looker Studio のテンプレートの [Realtime trends] ページで確認できます。このサンプルをテンプレートとして使用すると、実際のアプリのクラッシュ データに基づいて新しいレポートやビジュアル資料を手軽に作成できます。
右上にある [テンプレートを使用] をクリックします。
[新しいデータソース] プルダウンから [新しいデータソースを作成する] を選択します。
[BigQuery] カードで [選択] をクリックします。
[My Projects] > [PROJECT_ID] > [firebase_crashlytics] > [TABLE_NAME] の順に選択して、エクスポートされた Crashlytics データを含むテーブルを選択します。
バッチテーブルは常に選択可能です。BigQuery への Crashlytics ストリーミング エクスポートが有効になっている場合は、代わりにリアルタイム テーブルを選択できます。
[Configuration] で、[Crashlytics Template level] を [Default] に設定します。
[Connect] をクリックして新しいデータソースを作成します。
[Add to Report] をクリックして Crashlytics テンプレートに戻ります。
最後に、[Create Report] をクリックして Crashlytics Looker Studio ダッシュボード テンプレートのコピーを作成します。
BigQuery の Crashlytics スキーマの概要
Firebase Crashlytics データは、firebase_crashlytics という名前の BigQuery データセットにエクスポートされます。このデータセットは、複数のアプリがある場合でもプロジェクト全体をカバーします。
テーブル
デフォルトでは、Firebase は BigQuery にリンクされているプロジェクト内のアプリごとに、Crashlytics データセット内に個々のテーブルを作成します。テーブルの名前は、アプリの ID（ピリオドはアンダースコアに変換）に基づいて付けられ、アプリのプラットフォーム（_IOS または _ANDROID）が追加されます。たとえば、パッケージ名が com.google.test の Android アプリのデータは com_google_test_ANDROID という名前のテーブルに格納されます。
BigQuery への Crashlytics ストリーミング エクスポートを有効にすると、Crashlytics データも _REALTIME が付加されたテーブル（com_google_test_ANDROID_REALTIME など）にリアルタイムでストリーミングされます。
テーブルの各行はアプリで発生したイベント（クラッシュ、致命的でないエラー、ANR など）を表します。
テーブルには、アプリで定義したカスタム Crashlytics キーに加えて、Crashlytics データの標準セットが含まれています。
行
テーブルの各行は、アプリで発生したエラーを表します。
列
テーブルの列は、クラッシュ、致命的でないエラー、ANR で同じです。BigQuery への Crashlytics ストリーミング エクスポートが有効になっている場合、リアルタイム テーブルにはバッチテーブルと同じ列があります。スタック トレースのないイベントを表す行に列が存在する場合があるのでご注意ください。
エクスポートされた Crashlytics データのテーブルの列は次のとおりです。
| フィールド名 | データ型 | 説明 |
|---|---|---|
platform |
STRING | Firebase プロジェクトに登録されているアプリのプラットフォーム（有効な値: IOS または ANDROID） |
bundle_identifier |
STRING | Firebase プロジェクトに登録されているアプリの固有識別子（例: com.google.gmailApple プラットフォーム アプリの場合、これはアプリのバンドル ID です。 Android アプリの場合、これはアプリのパッケージ名です。 |
event_id |
STRING | イベントの一意の ID |
is_fatal |
BOOLEAN | アプリがクラッシュしたかどうか |
error_type |
STRING | イベントのエラータイプ（FATAL、NON_FATAL、ANR など） |
issue_id |
STRING | イベントに関連付けられている問題 |
variant_id |
STRING | このイベントに関連付けられている問題のバリアント すべてのイベントに問題のバリアントが関連付けられているわけではありません。 |
event_timestamp |
TIMESTAMP | イベントの発生時間 |
device |
RECORD | イベントが発生したデバイス |
device.manufacturer |
STRING | デバイスの製造元 |
device.model |
STRING | デバイスのモデル |
device.architecture |
STRING | 例: X86_32、X86_64、ARMV7、ARM64、ARMV7S、ARMV7K |
memory |
RECORD | デバイスのメモリ ステータス |
memory.used |
INT64 | 使用済みのメモリ（バイト） |
memory.free |
INT64 | 未使用のメモリ（バイト） |
storage |
RECORD | デバイスの永続ストレージ |
storage.used |
INT64 | 使用済みストレージ（バイト） |
storage.free |
INT64 | 未使用のストレージ（バイト） |
operating_system |
RECORD | デバイスの OS の詳細 |
operating_system.display_version |
STRING | デバイスの OS のバージョン |
operating_system.name |
STRING | デバイスの OS 名 |
operating_system.modification_state |
STRING | デバイスに変更が加えられているかどうか（例: 制限解除されたアプリは MODIFIED、root 権限を取得したアプリは UNMODIFIED など） |
operating_system.type |
STRING | （Apple アプリのみ）デバイスで実行されている OS の種類（IOS、MACOS など） |
operating_system.device_type |
STRING | デバイスの種類（例: MOBILE、TABLET、TV）。「デバイス カテゴリ」とも呼ばれます。 |
application |
RECORD | イベントを生成したアプリ |
application.build_version |
STRING | アプリのビルド バージョン |
application.display_version |
STRING | |
user |
RECORD | （省略可）アプリのユーザーに関して収集された情報 |
user.name |
STRING | （省略可）ユーザーの名前 |
user.email |
STRING | （省略可）ユーザーのメールアドレス |
user.id |
STRING | （省略可）ユーザーに関連付けられているアプリ固有の ID |
custom_keys |
REPEATED RECORD | デベロッパーが定義した Key-Value ペア |
custom_keys.key |
STRING | デベロッパーが定義したキー |
custom_keys.value |
STRING | デベロッパーが定義した値 |
installation_uuid |
STRING | アプリとデバイスのインストールを一意に識別する ID |
crashlytics_sdk_versions |
STRING | イベントを生成した Crashlytics SDK のバージョン |
app_orientation |
STRING | 例: PORTRAIT、LANDSCAPE、FACE_UP、FACE_DOWN |
device_orientation |
STRING | 例: PORTRAIT、LANDSCAPE、FACE_UP、FACE_DOWN |
process_state |
STRING | BACKGROUND または FOREGROUND |
logs |
REPEATED RECORD | Crashlytics ロガーによって生成されたタイムスタンプ付きのログメッセージ（有効な場合） |
logs.timestamp |
TIMESTAMP | ログの作成時間 |
logs.message |
STRING | ログに記録されたメッセージ |
breadcrumbs |
REPEATED RECORD | タイムスタンプ付きの Google Analytics パンくずリスト（有効な場合） |
breadcrumbs.timestamp |
TIMESTAMP | パンくずリストに関連付けられているタイムスタンプ |
breadcrumbs.name |
STRING | パンくずリストに関連付けられている名前 |
breadcrumbs.params |
REPEATED RECORD | パンくずリストに関連付けられたパラメータ |
breadcrumbs.params.key |
STRING | パンくずリストに関連付けられたパラメータキー |
breadcrumbs.params.value |
STRING | パンくずリストに関連付けられたパラメータ値 |
blame_frame |
RECORD | クラッシュまたはエラーの根本的原因として識別されたフレーム |
blame_frame.line |
INT64 | フレーム ファイルの行番号 |
blame_frame.file |
STRING | フレーム ファイルの名前 |
blame_frame.symbol |
STRING | ハイドレードされたシンボル。ハイドレード可能でない場合は未加工のシンボル。 |
blame_frame.offset |
INT64 | コードを含むバイナリ イメージへのバイト オフセット Java 例外で設定解除 |
blame_frame.address |
INT64 | コードを含むバイナリ イメージのアドレス Java フレームで設定解除 |
blame_frame.library |
STRING | フレームを含むライブラリの表示名 |
blame_frame.owner |
STRING | 例: DEVELOPER、VENDOR、RUNTIME、PLATFORM、SYSTEM |
blame_frame.blamed |
BOOLEAN | Crashlytics で、このフレームがクラッシュまたはエラーの原因と判断されたかどうか |
exceptions |
REPEATED RECORD | （Android のみ）このイベントで発生した例外。ネストされている例外は発生順と逆に表示されます。つまり、最後のレコードが最初にスローされた例外です。 |
exceptions.type |
STRING | 例外タイプ（java.lang.IllegalStateException) |
exceptions.exception_message |
STRING | 例外に関連するメッセージ |
exceptions.nested |
BOOLEAN | 最後にスローされた例外を除くすべて（すなわち、最初のレコード）の場合は true。 |
exceptions.title |
STRING | スレッドのタイトル |
exceptions.subtitle |
STRING | スレッドのサブタイトル |
exceptions.blamed |
BOOLEAN | エラーまたはクラッシュが原因で例外が発生しているかどうかを Crashlytics が判断する場合は true |
exceptions.frames |
REPEATED RECORD | 例外に関連付けられているフレーム |
exceptions.frames.line |
INT64 | フレーム ファイルの行番号 |
exceptions.frames.file |
STRING | フレーム ファイルの名前 |
exceptions.frames.symbol |
STRING | ハイドレードされたシンボル。ハイドレード可能でない場合は未加工のシンボル。 |
exceptions.frames.offset |
INT64 | コードを含むバイナリ イメージへのバイト オフセット Java 例外で設定解除 |
exceptions.frames.address |
INT64 | コードを含むバイナリ イメージのアドレス Java フレームで設定解除 |
exceptions.frames.library |
STRING | フレームを含むライブラリの表示名 |
exceptions.frames.owner |
STRING | 例: DEVELOPER、VENDOR、RUNTIME、PLATFORM、SYSTEM |
exceptions.frames.blamed |
BOOLEAN | Crashlytics で、このフレームがクラッシュまたはエラーの原因と判断されたかどうか |
error |
REPEATED RECORD | （Apple アプリのみ）致命的でないエラー |
error.queue_name |
STRING | スレッドが実行されていたキュー |
error.code |
INT64 | アプリのカスタムログに記録された NSError に関連するエラーコード |
error.title |
STRING | スレッドのタイトル |
error.subtitle |
STRING | スレッドのサブタイトル |
error.blamed |
BOOLEAN | Crashlytics で、このフレームがエラーの原因と判断されたかどうか |
error.frames |
REPEATED RECORD | スタック トレースのフレーム |
error.frames.line |
INT64 | フレーム ファイルの行番号 |
error.frames.file |
STRING | フレーム ファイルの名前 |
error.frames.symbol |
STRING | ハイドレードされたシンボル。ハイドレード可能でない場合は未加工のシンボル。 |
error.frames.offset |
INT64 | コードを含むバイナリ イメージへのバイト オフセット |
error.frames.address |
INT64 | コードを含むバイナリ イメージ内のアドレス |
error.frames.library |
STRING | フレームを含むライブラリの表示名 |
error.frames.owner |
STRING | 例: DEVELOPER、VENDOR、RUNTIME、PLATFORM、SYSTEM |
error.frames.blamed |
BOOLEAN | Crashlytics で、このフレームがエラーの原因と判断されたかどうか |
threads |
REPEATED RECORD | イベント発生時に存在していたスレッド |
threads.crashed |
BOOLEAN | スレッドがクラッシュしたかどうか |
threads.thread_name |
STRING | スレッドの名前 |
threads.queue_name |
STRING | （Apple アプリのみ）スレッドが実行されていたキュー |
threads.signal_name |
STRING | アプリをクラッシュさせたシグナルの名前。クラッシュしたネイティブ スレッドにのみ存在します。 |
threads.signal_code |
STRING | アプリをクラッシュさせたシグナルのコード。クラッシュしたネイティブ スレッドにのみ存在します。 |
threads.crash_address |
INT64 | アプリケーションをクラッシュさせたシグナルのアドレス。クラッシュしたネイティブ スレッドにのみ存在します。 |
threads.code |
INT64 | （Apple アプリのみ）アプリケーションのカスタムログの NSError エラーコード |
threads.title |
STRING | スレッドのタイトル |
threads.subtitle |
STRING | スレッドのサブタイトル |
threads.blamed |
BOOLEAN | Crashlytics で、このフレームがクラッシュまたはエラーの原因と判断されたかどうか |
threads.frames |
REPEATED RECORD | スレッドのフレーム |
threads.frames.line |
INT64 | フレーム ファイルの行番号 |
threads.frames.file |
STRING | フレーム ファイルの名前 |
threads.frames.symbol |
STRING | ハイドレードされたシンボル。ハイドレード可能でない場合は未加工のシンボル。 |
threads.frames.offset |
INT64 | コードを含むバイナリ イメージへのバイト オフセット |
threads.frames.address |
INT64 | コードを含むバイナリ イメージ内のアドレス |
threads.frames.library |
STRING | フレームを含むライブラリの表示名 |
threads.frames.owner |
STRING | 例: DEVELOPER、VENDOR、RUNTIME、PLATFORM、SYSTEM |
threads.frames.blamed |
BOOLEAN | Crashlytics で、このフレームがエラーの原因と判断されたかどうか |
unity_metadata.unity_version |
STRING | このデバイスで実行されている Unity のバージョン |
unity_metadata.debug_build |
BOOLEAN | デバッグビルドの場合 |
unity_metadata.processor_type |
STRING | プロセッサの種類 |
unity_metadata.processor_count |
INT64 | プロセッサ（コア）数 |
unity_metadata.processor_frequency_mhz |
INT64 | プロセッサの周波数（MHz） |
unity_metadata.system_memory_size_mb |
INT64 | システムメモリのサイズ（MB 単位） |
unity_metadata.graphics_memory_size_mb |
INT64 | グラフィック メモリ（MB） |
unity_metadata.graphics_device_id |
INT64 | グラフィック デバイスの ID |
unity_metadata.graphics_device_vendor_id |
INT64 | グラフィック プロセッサ ベンダーの ID |
unity_metadata.graphics_device_name |
STRING | グラフィック デバイスの名前 |
unity_metadata.graphics_device_vendor |
STRING | グラフィック デバイスのベンダー |
unity_metadata.graphics_device_version |
STRING | グラフィック デバイスのバージョン |
unity_metadata.graphics_device_type |
STRING | グラフィック デバイスの種類 |
unity_metadata.graphics_shader_level |
INT64 | グラフィックのシェーダー レベル |
unity_metadata.graphics_render_target_count |
INT64 | グラフィカル レンダリング ターゲットの数 |
unity_metadata.graphics_copy_texture_support |
STRING | Unity API で定義されているグラフィック テクスチャのコピーをサポート |
unity_metadata.graphics_max_texture_size |
INT64 | レンダリング テクスチャ専用の最大サイズ |
unity_metadata.screen_size_px |
STRING | 画面サイズのピクセル単位のサイズ（幅 x 高さの形式） |
unity_metadata.screen_resolution_dpi |
STRING | 浮動小数点数による画面の DPI |
unity_metadata.screen_refresh_rate_hz |
INT64 | 画面リフレッシュ レート（Hz） |
新しいエクスポート インフラストラクチャにアップグレードする
2024 年 10 月中旬に、Crashlytics は Crashlytics データを BigQuery にバッチ エクスポートするための新しいインフラストラクチャをリリースしました。
すべての Firebase プロジェクトは、2025 年 9 月 15 日までに新しいバッチ エクスポート インフラストラクチャに自動的にアップグレードされます。 この日付より前にアップグレードできますが、BigQuery バッチテーブルがアップグレードの前提条件を満たしていることを確認してください。
新しいインフラストラクチャにアップグレードできますが、BigQuery バッチテーブルがアップグレードの前提条件を満たしていることを確認してください。
新しいインフラストラクチャを使用しているかどうかを確認する
2024 年 10 月中旬以降にバッチ エクスポートを有効にした場合、Firebase プロジェクトでは新しいエクスポート インフラストラクチャが自動的に使用されます。
プロジェクトで使用されているインフラストラクチャを確認するには、Google Cloud コンソールに移動します。「データ転送構成」に Firebase Crashlytics with Multi-Region Support というラベルが付いている場合、プロジェクトで新しいエクスポート インフラストラクチャが使用されています。
以前のエクスポート インフラストラクチャと新しいエクスポート インフラストラクチャの重要な違い
この新しいインフラストラクチャは、米国以外の Crashlytics データセットのロケーションをサポートしています。
2024 年 10 月中旬以前にエクスポートを有効にし、新しいエクスポート インフラストラクチャにアップグレード済み - 必要に応じてデータ エクスポートのロケーションを変更できるようになりました。
2024 年 10 月中旬以降にエクスポートを有効にした - セットアップ時に、データ エクスポートのロケーションを選択するよう求められました。
新しいインフラストラクチャでは、エクスポートを有効にする前のデータのバックフィルをサポートしていません。
以前のインフラストラクチャでは、エクスポートを有効にした日付の 30 日前までバックフィルが可能でした。
新しいインフラストラクチャは、過去 30 日間または、BigQuery へのエクスポートを有効にした最新の日付まで（どちらか最新のほう）のバックフィルをサポートしています。
新しいインフラストラクチャでは、Firebase プロジェクトの Firebase アプリに設定されている ID を使用して BigQuery バッチテーブルに名前が付けられます。
以前のインフラストラクチャでは、Firebase 構成のアプリのコードベース内のバンドル ID またはパッケージ名に基づいて名前が付けられたバッチテーブルにデータが書き込まれていました。
新しいインフラストラクチャでは、Firebase プロジェクトに登録されている Firebase アプリに設定されているバンドル ID またはパッケージ名に基づいて名前が付けられたバッチテーブルにデータが書き込まれます。
ステップ 1: アップグレードの前提条件
既存の BigQuery バッチテーブルで、Firebase プロジェクトに登録されている Firebase アプリに設定されているバンドル ID またはパッケージ名と一致する ID が使用されていることを確認します。一致しない場合、エクスポートされたバッチデータが中断される可能性があります。ほとんどのプロジェクトは適切で互換性のある状態になりますが、アップグレード前に確認することが重要です。
Firebase プロジェクトに登録されているすべての Firebase アプリは、Firebase コンソールで確認できます。 [プロジェクト設定] に移動し、[マイアプリ] カードまでスクロールして、すべての Firebase アプリとその情報を表示します。
BigQuery バッチテーブルはすべて、Google Cloud コンソールの BigQuery ページで確認できます。
たとえば、アップグレードで問題が発生しない理想的な状態は次のとおりです。
com_yourcompany_yourproject_IOSという名前のバッチテーブルと、バンドル IDcom.yourcompany.yourprojectの Firebase iOS+ アプリが Firebase プロジェクトに登録されている。com_yourcompany_yourproject_ANDROIDという名前のバッチテーブルと、パッケージ名com.yourcompany.yourprojectの Firebase Android アプリが Firebase プロジェクトに登録されている。
登録済みの Firebase アプリに設定されている ID と一致しないバッチテーブル名がある場合は、手動でアップグレードする前、または 2025 年 9 月 15 日より前に、このページの後半の手順に沿ってバッチ エクスポートの中断を回避してください。
ステップ 2: 新しいインフラストラクチャにアップグレードする方法
2024 年 10 月中旬より前にバッチ エクスポートを有効にした場合は、Firebase コンソールで Crashlytics データ エクスポートをオフにしてからオンに戻すだけで、新しいインフラストラクチャに手動でアップグレードできます。
詳しい手順は次のとおりです。
Firebase コンソールで、[統合] ページに移動します。
[BigQuery] カードで [管理] をクリックします。
Crashlytics のスライダーをオフに切り替えて、エクスポートを無効にします。プロンプトが表示されたら、データ エクスポートの停止を確定します。
すぐに Crashlytics スライダーを再度オンに切り替えて、エクスポートを再度有効にします。プロンプトが表示されたら、データのエクスポートを確定します。
これで、BigQuery への Crashlytics データ エクスポートで、新しいエクスポート インフラストラクチャが使用されるようになりました。