Firebase Crashlytics データを BigQuery にエクスポートする

Firebase Crashlytics データを BigQuery にエクスポートして、詳細に分析できます。BigQuery では、BigQuery SQL を使用してデータを分析できます。また、データを別のクラウド プロバイダにエクスポートできるほか、可視化や Google データポータルのカスタム ダッシュボードでデータを使用できます。

BigQuery へのエクスポートを有効にする

  1. Firebase コンソールで、[統合] ページに移動します。

  2. [BigQuery] カードで [リンク] をクリックします。

  3. 画面上の指示に従って、BigQuery へのエクスポートを有効にします。

    BigQueryCrashlytics データにほぼリアルタイムでアクセスする場合は、ストリーミング エクスポートへのアップグレードを検討してください。

エクスポートを有効にした場合の影響

  • データセットのロケーションを選択します。データセットの作成後はロケーションを変更できませんが、データセットを別のロケーションにコピーするか、データセットを別のロケーションに手動で移動(再作成)することはできます。詳細については、既存のエクスポートのロケーションを変更するをご覧ください。

    このロケーションは、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 コンソールでプロジェクトのリンクを解除します。

BigQuery にエクスポートされるデータの概要

Firebase Crashlytics データは、firebase_crashlytics という名前の BigQuery データセットにエクスポートされます。デフォルトでは、プロジェクト内のアプリごとに用意される Crashlytics データセットに個々のテーブルが作成されます。Firebase は、アプリの ID に基づいてテーブルの名前を付けます。ピリオドはアンダースコアに変換され、名前の末尾にプラットフォーム名が追加されます。

たとえば、パッケージ名が com.google.test の Android アプリのデータは com_google_test_ANDROID という名前のテーブルに格納されます。このバッチテーブルは毎日 1 回更新されます。BigQuery への Crashlytics ストリーミング エクスポートを有効にすると、Crashlytics データも com_google_test_ANDROID_REALTIME という名前のテーブルにリアルタイムでストリーミングされます。

テーブルの各行はアプリで発生したイベント(クラッシュ、致命的でないエラー、ANR など)を表します。

BigQuery への Crashlytics のストリーミング エクスポート

BigQuery ストリーミングを使用すると、Crashlytics データをリアルタイムでストリーミングできます。ライブ ダッシュボードでの情報の表示、ライブでのロールアウトの監視、アラートやカスタム ワークフローをトリガーするアプリケーション問題のモニタリングなど、ライブデータが必要なあらゆる目的で使用できます。

BigQuery への Crashlytics ストリーミング エクスポートを有効にすると、バッチテーブルに加えてリアルタイム テーブルも作成されます。この 2 つのテーブルには次の違いがあります。

バッチテーブル リアルタイム テーブル
  • データは 1 日 1 回エクスポートされます。
  • イベントは、BigQuery へのバッチ書き込み前に永続的に保存されます。
  • 最大 30 日前までのデータをバックフィルできます*。
  • データはリアルタイムでエクスポートされます。
  • バックフィルは使用できません。

バッチテーブルには書き込み前のイベントが永続的に保存されるため、このテーブルは長期分析で経時的な傾向を識別する場合に適しています。また、最大で 30 日前まで遡ってテーブルのバックフィルを行うことができます*。リアルタイム テーブルに書き込まれたデータはすぐに BigQuery に書き込まれるため、ライブ ダッシュボードやカスタム アラートにはリアルタイム テーブルが適しています。この 2 つのテーブルを合成クエリで組み合わせると、両方のメリットを利用できます。

デフォルトでは、リアルタイム テーブルのパーティションの有効期限は 30 日間です。これを変更する方法については、BigQuery ドキュメントのパーティションの有効期限を設定するをご覧ください。

* バックフィルのサポートの詳細については、新しいエクスポート インフラストラクチャにアップグレードするをご覧ください。

BigQuery への Crashlytics のストリーミング エクスポートを有効にする

  1. Firebase コンソールで、[統合] ページに移動します。

  2. [BigQuery] カードで [管理] をクリックします。

  3. [ストリーミングを含む] チェックボックスをオンにします。

この操作により、リンクされたすべてのアプリでストリーミングが有効になります。

エクスポートされたデータで可能な操作

BigQuery へのエクスポートでは、デバイスの種類、オペレーティング システム、例外(Android アプリ)またはエラー(Apple アプリ)、Crashlytics ログなど、未加工のクラッシュ データを利用できます。

エクスポートされる Crashlytics データとそのテーブルのスキーマについては、このページの後の部分で詳しく説明します。

データポータルのテンプレートを使用する

データポータルのテンプレートでリアルタイム データを有効にするには、データポータルを使用してエクスポートされた Crashlytics データの可視化の手順に沿って操作します。

ビューを作成する

BigQuery UI を使用して、クエリをビューに変換できます。詳細な手順については、BigQuery ドキュメントのビューを作成するをご覧ください。

クエリを実行する

次の例は、Crashlytics データに対して実行して、障害イベントデータを、より簡単に理解できる概要に集約するレポートを生成するクエリを示しています。このようなレポートは Firebase コンソールの Crashlytics ダッシュボードでは利用できないため、クラッシュ データの分析と理解を補完できます。

例 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 を特定し、次に、このクラッシュが世界的にどのように影響しているのかを確認します。

このクエリを作成するために、次の作業が必要になります。

  1. Google Analytics データの BigQuery へのエクスポートを有効にする詳しくは、プロジェクト データを BigQuery にエクスポートするをご覧ください。

  2. ユーザー 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");
    
  3. ユーザー 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 >= "YYYY_MM_DD"
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

BigQueryCrashlytics スキーマの概要

Crashlytics から BigQuery へのデータ エクスポートを設定すると、Firebase は最近発生したイベント(クラッシュ、致命的ではないエラー、ANR)をエクスポートします。この中には、リンクの 2 日前までのイベントが含まれており、最大 30 日前まで遡ってテーブルのバックフィルを行えるオプションも用意されています。

その時点からユーザーがエクスポートを無効にするまで、Firebase は Crashlytics イベントを毎日エクスポートします。エクスポート後に BigQuery でデータを利用できるようになるまでに数分かかることがあります。

データセット

Crashlytics は、Crashlytics データ用に BigQuery に新しいデータセットを作成します。このデータセットは、複数のアプリがある場合でもプロジェクト全体をカバーします。

テーブル

ユーザーがアプリのデータ エクスポートを無効にしない限り、Crashlytics はプロジェクトに含まれるアプリごとに、データセット内にテーブルを作成します。Firebase は、アプリのバンドル ID に基づいてテーブルの名前を付けます。ピリオドはアンダースコアに変換され、名前の末尾にプラットフォーム名が追加されます。

たとえば、パッケージ名が com.google.test の Android アプリのデータは com_google_test_ANDROID という名前のテーブルに格納され、リアルタイム データ(有効にされてる場合)は com_google_test_ANDROID_REALTIME という名前のテーブルに格納されます。

テーブルには、アプリで定義したカスタム Crashlytics キーに加えて、Crashlytics データの標準セットが含まれています。

テーブルの各行は、アプリで発生したエラーを表します。

テーブルの列は、クラッシュ、致命的でないエラー、ANR で同じです。BigQuery への Crashlytics ストリーミング エクスポートが有効になっている場合、リアルタイム テーブルにはバッチテーブルと同じ列があります。スタック トレースのないイベントを表す行に列が存在する場合があるのでご注意ください。

エクスポート内の列は次の表のとおりです。

フィールド名 データ型 説明
platform STRING Firebase プロジェクトに登録されているアプリのプラットフォーム(有効な値: IOS または ANDROID
bundle_identifier STRING Firebase プロジェクトに登録されているアプリの固有識別子(例: com.google.gmail
Apple プラットフォーム アプリの場合、これはアプリのバンドル ID です。
Android アプリの場合、これはアプリのパッケージ名です。
event_id STRING イベントの一意の ID
is_fatal BOOLEAN アプリがクラッシュしたかどうか
error_type STRING イベントのエラータイプ(FATALNON_FATALANR など)
issue_id STRING イベントに関連付けられている問題
variant_id STRING このイベントに関連付けられている問題のバリアント
すべてのイベントに問題のバリアントが関連付けられているわけではありません。
event_timestamp TIMESTAMP イベントの発生時間
device RECORD イベントが発生したデバイス
device.manufacturer STRING デバイスの製造元
device.model STRING デバイスのモデル
device.architecture STRING 例: X86_32X86_64ARMV7ARM64ARMV7SARMV7K
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 の種類(IOSMACOS など)
operating_system.device_type STRING デバイスの種類(例: MOBILETABLETTV)。「デバイス カテゴリ」とも呼ばれます。
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 例: PORTRAITLANDSCAPEFACE_UPFACE_DOWN
device_orientation STRING 例: PORTRAITLANDSCAPEFACE_UPFACE_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 例: DEVELOPERVENDORRUNTIMEPLATFORMSYSTEM
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 例: DEVELOPERVENDORRUNTIMEPLATFORMSYSTEM
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 例: DEVELOPERVENDORRUNTIMEPLATFORMSYSTEM
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 例: DEVELOPERVENDORRUNTIMEPLATFORMSYSTEM
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)

データポータルでエクスポートされた Crashlytics データを可視化する

Google データポータルを使うと、BigQueryCrashlytics データセットを、見やすく簡単に共有できるうえ、全面的なカスタマイズも可能なレポートに変換できます。

データポータルの使用方法の詳細については、データポータル クイックスタート ガイドのデータポータルへようこそを試してください。

Crashlytics レポート テンプレートを使用する

データポータルには、エクスポートされた Crashlytics BigQuery スキーマからの包括的なディメンションと指標のセットを含む Crashlytics のサンプル レポートがあります。BigQuery への Crashlytics のストリーミング エクスポートを有効にしている場合、エクスポートされたデータはデータポータルのテンプレートの [Realtime trends] ページで確認できます。このサンプルをテンプレートとして使用すると、実際のアプリのクラッシュ データに基づいて新しいレポートやビジュアル資料を手軽に作成できます。

  1. Crashlytics データポータル ダッシュボード テンプレートを開きます。

  2. 右上にある [テンプレートを使用] をクリックします。

  3. [新しいデータソース] プルダウンから [新しいデータソースを作成する] を選択します。

  4. [BigQuery] カードで [選択] をクリックします。

  5. [My Projects] > [PROJECT_ID] > [firebase_crashlytics] > [TABLE_NAME] の順に選択して、エクスポートされた Crashlytics データを含むテーブルを選択します。

    バッチテーブルは常に選択可能です。BigQuery への Crashlytics ストリーミング エクスポートが有効になっている場合は、代わりにリアルタイム テーブルを選択できます。

  6. [Configuration] で、[Crashlytics Template level] を [Default] に設定します。

  7. [Connect] をクリックして新しいデータソースを作成します。

  8. [Add to Report] をクリックして Crashlytics テンプレートに戻ります。

  9. 最後に、[Create Report] をクリックして Crashlytics データポータル ダッシュボード テンプレートのコピーを作成します。

新しいエクスポート インフラストラクチャにアップグレードする

2024 年 10 月中旬に、CrashlyticsCrashlytics データを BigQuery にエクスポートするための新しいインフラストラクチャをリリースしました。現時点では、この新しいインフラストラクチャへのアップグレードは任意です。

この新しいインフラストラクチャは、米国外の Crashlytics データセットのロケーションをサポートしています。

  • 2024 年 10 月中旬以前にエクスポートを有効にした場合は、必要に応じて BigQuery でサポートされているデータセットのロケーションについて、データ エクスポートのロケーションを変更できます。

  • 2024 年 10 月中旬以降にエクスポートを有効にした場合は、セットアップ時に BigQuery でサポートされているデータセットのロケーションを選択できます。

新しいインフラストラクチャのもう 1 つの違いは、エクスポートを有効にする前のデータのバックフィルをサポートしていないことです(以前のインフラストラクチャでは、有効化した日付の 30 日前までバックフィルできました)。新しいインフラストラクチャは、過去 30 日間または BigQuery へのエクスポートを有効にした最新の日付まで(どちらか最新のほう)のバックフィルをサポートしています。

アップグレードの前提条件

新しいインフラストラクチャにアップグレードする前に、次の前提条件を満たしていることを確認してください。現在のバッチ BigQuery テーブルに、登録済みの Firebase アプリに対して設定されているバンドル ID またはパッケージ名と一致する ID があること。

例:

  • com_yourcompany_yourproject_IOS という名前の BigQuery テーブルがある場合は、Firebase プロジェクトにバンドル ID com.yourcompany.yourproject で Firebase iOS+ アプリが登録されている必要があります。

  • com_yourcompany_yourproject_ANDROID という名前の BigQuery テーブルがある場合は、Firebase プロジェクトに Firebase Android アプリがパッケージ名 com.yourcompany.yourproject で登録されている必要があります。

Firebase プロジェクトに登録されているすべての Firebase アプリを確認する方法は次のとおりです。

  1. Firebase コンソールで、 [プロジェクト設定] に移動します。

  2. [アプリ] カードまで下にスクロールし、目的の Firebase アプリをクリックして、ID などのアプリの情報を確認します。

新しいエクスポート インフラストラクチャは、登録済みの Firebase アプリに設定されているパッケージ名またはバンドル ID に基づいて各アプリのデータをエクスポートします。BigQuery ワークフローを中断しないようにするには、新しいインフラストラクチャがすべての新しいデータを既存のテーブルに追加できるように、現在のバッチテーブルにすでに正しい名前が付いていることを確認することが重要です。登録済みの Firebase アプリと一致しないバッチテーブル名があるものの、引き続きアップグレードを希望する場合は、Firebase サポートにお問い合わせください。

新しいインフラストラクチャにアップグレードする方法

エクスポートをすでに有効にしている場合は、Firebase コンソールで Crashlytics データ エクスポートをオフにしてからオンに戻すだけで、新しいインフラストラクチャにアップグレードできます。

詳しい手順は次のとおりです。

  1. Firebase コンソールで、[統合] ページに移動します。

  2. [BigQuery] カードで [管理] をクリックします。

  3. Crashlytics のスライダーをオフに切り替えて、エクスポートを無効にします。プロンプトが表示されたら、データ エクスポートの停止を確認します。

  4. すぐに Crashlytics スライダーをオンに切り替えて、エクスポートを再度有効にします。プロンプトが表示されたら、データのエクスポートを確認します。

    BigQuery への Crashlytics データ エクスポートで、新しいエクスポート インフラストラクチャが使用されるようになりました。