Performance Monitoring についてのトラブルシューティングとよくある質問

パフォーマンス イベントのログ メッセージを表示する方法

1. 次のようにデバッグ ロギングを有効にします。

   1. Xcode（v16.2 以上）で、[Product] > [Scheme] > [Edit scheme] の順に選択します。
   2. 左側のメニューから [Run] を選択し、[Arguments] タブを選択します。
   3. [Arguments Passed on Launch] セクションで -FIRDebugEnabled を追加します。

2. ログ メッセージにエラー メッセージがないか確認します。

3. Performance Monitoring は、ログ メッセージをフィルタできるように、ログ メッセージに Firebase/Performance のタグを付けます。

4. Performance Monitoring がパフォーマンス イベントをロギングしていることを示す次の種類のログを確認します。

   • Logging trace metric: TRACE_NAME, FIREBASE_PERFORMANCE_CONSOLE_URL
   • Logging network request trace: URL

5. URL をクリックして Firebase コンソールでデータを表示します。ダッシュボードでデータが更新されるまでに少し時間がかかることがあります。

アプリがパフォーマンス イベントをロギングしていない場合は、トラブルシューティングのヒントをご覧ください。

SDK をアプリに追加したが、SDK を追加するようコンソールに指示が表示される

Firebase は、アプリからイベント情報（アプリの操作など）を受け取るときに、アプリに Performance Monitoring SDK が正常に追加されたかどうかを検出できます。通常、アプリを起動してから 10 分以内に、Firebase コンソールのパフォーマンス ダッシュボードに「SDK を検出しました」というメッセージが表示されます。30 分以内に、最初の処理済みのデータがダッシュボードに表示されます。

最新バージョンの SDK をアプリに追加してから 10 分以上経過しても変化が現れない場合は、ログ メッセージを確認して、Performance Monitoring がイベントをロギングしているか確認します。以下の該当するトラブルシューティングの手順を試して、SDK 検出メッセージの遅延についてトラブルシューティングを行います。

SDK を検出したとコンソールに表示されるが、データが表示されない

Performance Monitoring がパフォーマンス イベントデータを処理した後に、パフォーマンス ダッシュボードにそのデータが表示されます。

「SDK を検出しました」というメッセージが表示されてから 24 時間以上経過してもデータが表示されない場合は、既知の停止が発生しているかどうか Firebase ステータス ダッシュボードを確認します。停止が発生していない場合は、Firebase サポートにお問い合わせください。

アプリがパフォーマンス イベントをロギングしない

パフォーマンス イベントのログ メッセージが表示されない場合は、次のトラブルシューティング手順をお試しください。

1. Info.plist ファイル内の次のフラグのいずれかによってPerformance Monitoring SDK が無効になっていないことを確認します。

   • firebase_performance_collection_enabled
   • firebase_performance_collection_deactivated

2. Performance Monitoring がランタイムで無効になっていないことを確認します（Swift | Obj-C）。

3. アプリで無効になっているものが見つからない場合は、Firebase サポートにお問い合わせください。

パフォーマンス ダッシュボードに画面トレースデータが表示されない

画面レンダリング トレースのデータが表示されない場合は、次のトラブルシューティング手順をお試しください。

パフォーマンス ダッシュボードにカスタム トレースデータが表示されない

自動収集されるトレースのパフォーマンス データは表示され、カスタムコード トレースのデータは表示されませんか。次のトラブルシューティング手順をお試しください。

1. Trace API を使用してインストルメント化したカスタム コード トレースの設定を確認します。特に次の点に注意してください。

   • カスタム コード トレースとカスタム指標の名前には制限があります。先頭または末尾が空白文字でなく、先頭がアンダースコア（_）でない 32 文字以下の名前を指定する必要があります。
   • すべてのトレースを開始して停止する必要があります。開始されていないトレース、停止されていないトレース、開始前に停止されたトレースはログに記録されません。

2. ログ メッセージを確認して、Performance Monitoring が、想定されるカスタム コード トレースをロギングしていることを確かめます。

3. Performance Monitoring がイベントをロギングしているが、24 時間経過してもデータが表示されない場合は、Firebase サポートにお問い合わせください。

パフォーマンス ダッシュボードにネットワーク リクエスト データが表示されない

ネットワーク リクエスト データが表示されない場合は、次のトラブルシューティング手順をお試しください。

1. ネットワーク ライブラリの非互換性を確認します。Performance Monitoring は、次のネットワーク ライブラリを使用するネットワーク リクエストの指標を自動的に収集します。

   • Swift の場合: URLSession と URLConnection
   • Objective-C の場合: NSURLSession と NSURLConnection

   ネットワーク リクエストにはカスタム モニタリングを追加できます。

2. 次の点に注意してください。

   • コードとそのコードで使用しているネットワーキング ライブラリの動作によっては、Performance Monitoring で報告されるのが、完了したネットワーク リクエストだけになることがあります。この場合、開いたままの HTTP/S 接続が報告されていない可能性があります。

   • Performance Monitoring は、無効な Content-Type ヘッダーが指定されたネットワーク リクエストを報告しません。Content-Type ヘッダーのないネットワーク リクエストは受け入れられます。

ネットワーク リクエスト データが想定どおりに集計されない

詳細については、URL パターンに基づいて Performance Monitoring がネットワーク リクエスト データを集計する方法をご覧ください。

カスタム URL パターンもお試しください。

プロジェクト ホームのパフォーマンス カードの [問い合わせが多い問題] はどうなったのですか？

[問い合わせが多い問題] は、[最近のアラート] に置き換えられました。これは、設定したしきい値を超えると自動的に通知されるアラートを、最近導入したことを反映したものです。「問題」のサポートは終了し、アラートに置き換えられました。

パフォーマンス カードの上部にあるアプリセレクタでは、[最近のアラート] でアラート エントリがフィルタされます。選択したアプリについて、直近 3 件のアラートのみが表示されます。

アラートについて詳しくは、パフォーマンスの問題に関するアラートを設定するをご覧ください。

コンソールで問題に対してしきい値を設定する機能は、現在どうなっていますか？

Performance Monitoring では、定義したしきい値を超える指標に対するアラートがサポートされています。パフォーマンス指標に対するこれらの構成可能なしきい値との混同を回避するため、問題に対してしきい値を構成する機能は削除されています。

Firebase コンソールの [詳細] と [指標] の情報はどうなったのですか？

詳細ページと指標ページが一新され、新たに再設計され、一元化されたユーザー インターフェース（UI）に置き換えられました。これにより、問題のトラブルシューティングが向上します。この新しいトラブルシューティングの UI は、詳細や指標と同じコア機能を提供します。トラブルシューティングの詳細については、特定のトレースのデータをさらに表示するをご覧ください。

サンプル数が想定した数と異なるのはなぜですか？

Performance Monitoring は、アプリのユーザー デバイスからパフォーマンス データを収集します。多くのユーザーがアプリを利用している場合や、アプリが大量のパフォーマンス アクティビティを生成する場合は、処理するイベントの数を減らすために、Performance Monitoring はデバイスのサブセットのみに限定してデータを収集することがあります。このように制限しても十分なデータが得られるため、イベントが少なくなったとしても、指標の値はユーザーのアプリ エクスペリエンスを適切に表しています。

収集するデータの量を管理するために、Performance Monitoring は次のサンプリング オプションを使用します。

• デバイス上のレート制限: デバイスが送信するトレースが急増することがないように、デバイスから送信されるコードトレースとネットワーク リクエスト トレースの数を 10 分間あたり 300 イベントに制限しています。このアプローチにより、大量のパフォーマンス データを送信する可能性があるループ型のインストルメンテーションからデバイスを保護し、1 つのデバイスによってパフォーマンスの測定値が歪められるのを防ぎます。

• 動的サンプリング: Performance Monitoring は、1 つのアプリで、すべてのアプリユーザーを通じてコードトレースとネットワーク リクエスト トレースについてそれぞれ制限された数のデータを毎日収集します。（Firebase Remote Config を使用して）デバイスに関する動的サンプリング レートを取得し、ランダムなデバイスでトレースをキャプチャして送信する必要があるかどうかを判断します。サンプリングの対象として選択されていないデバイスはイベントを送信しません。動的サンプリング レートはアプリに固有であり、収集されるデータの全体量が制限を下回るように調整されます。

  BigQuery の統合を有効にしたプロジェクトでは、ネットワーク リクエスト トレースの数の上限が高くなります。

  ユーザー セッションでは、ユーザーのデバイスからさらに多くの詳細なデータを送信します。そのため、データをキャプチャして送信するために必要となるリソースが増えます。ユーザー セッションの影響を最小限に抑えるため、Performance Monitoring はセッション数を制限する場合もあります。

• サーバーサイドのレート制限: アプリでサンプリングの制限を超えないようにするため、Performance Monitoring はサーバーサイドのサンプリングを使用して、デバイスから受信した一部のイベントを破棄する場合があります。この制限によって指標の有効性が変化することはありませんが、次のような小規模なパターンの変化が生じることがあります。

  • トレースの数とコードが実行された回数が異なる場合があります。
  • コード内で密接に結合している複数のトレースのサンプル数が異なる場合があります。

コンソールの [問題] タブはどうなったのですか？

[問題] タブに代わってアラートが導入されました。アラートは、設定したしきい値を超えると自動的に通知されます。これにより、しきい値のステータスを特定するために手動で Firebase コンソールを確認する必要がなくなりました。アラートについて詳しくは、パフォーマンスの問題に関するアラートを設定するをご覧ください。

コンソールの [デバイス] タブと [ネットワーク] タブはどうなったのですか？それらのページに表示されていたトレースを表示するにはどうすればよいですか？

Firebase コンソールの Performance Monitoring セクションが再設計され、主要な指標とすべてのトレースがまとめて [ダッシュボード] タブに表示されるようになりました。今回の再設計の一環として、[デバイス] ページと [ネットワーク] ページを削除しました。

[ダッシュボード] タブの下部にあるトレース テーブルには、[デバイス] タブと [ネットワーク] タブに表示されていた同じ情報がすべて含まれていますが、特定の指標の変化率でトレースを並べ替える機能など、一部の機能が追加されました。特定のトレースの指標とデータをすべて表示するには、トレース テーブル内のトレース名をクリックします。

トレースはトレース テーブルの次のサブタブに表示されます。

• ネットワーク リクエスト トレース（すぐに使用できるものとカスタムの両方） - [ネットワーク リクエスト] サブタブ
• カスタムコード トレース - [カスタム トレース] サブタブ
• アプリの起動、フォアグラウンドのアプリ、バックグラウンド アプリのトレース - [カスタム トレース] サブタブ
• 画面レンダリング トレース - [画面レンダリング] サブタブ
• ページ読み込みトレース - [ページ読み込み] サブタブ

トレース テーブルの詳細と、指標やデータの表示については、コンソールの概要ページ（iOS+ | Android | ウェブ）をご覧ください。

遅いフレームやフリーズしたフレームの数が想定した数と異なるのはなぜですか？

レンダリングが遅いフレームとフリーズしたフレームは、想定される 60 Hz のデバイス リフレッシュ レートで計算されます。デバイスのリフレッシュ レートが 60 Hz 未満の場合は、1 秒間にレンダリングされるフレームが少なくなるため、各フレームでレンダリング時間が長くなります。レンダリング時間が長くなると、レンダリングが遅くなるフレームやフリーズするフレームが多くなるため、遅いフレームやフリーズしたフレームの報告が増えます。ただし、デバイスのリフレッシュ レートが 60 Hz を超える場合は、各フレームでレンダリング時間が短くなります。これにより、遅いフレームやフリーズしたフレームが報告される回数が少なくなります。これは、Performance Monitoring SDK の現在の制限です。

Performance Monitoring データの BigQuery へのエクスポートに、予想よりも時間がかかっています。リアルタイムではないのですか？

Firebase Performance Monitoring の BigQuery 統合を有効にしている場合、データはその日の終わり（太平洋時間）から 12～24 時間後に BigQuery にエクスポートされます。

たとえば、4 月 19 日のデータは、4 月 20 日午後 12 時から深夜まで、BigQuery で使用できます（すべての日時は太平洋時間）。

「準リアルタイム」（またはニア リアルタイム）のパフォーマンス データとは何ですか？

Firebase Performance Monitoring が収集されたパフォーマンス データを適時処理すると、ほぼリアルタイムのデータが Firebase コンソールに表示されます。処理されたデータは、収集されて数分以内にコンソールに表示されるため、「ほぼリアルタイム」という言葉を使用しています。

ほぼリアルタイムのデータ処理を利用するには、リアルタイム対応の SDK バージョンをアプリで使用します。

準リアルタイムのパフォーマンス データをアプリで取得するにはどうすればよいですか？

リアルタイムのデータ処理に対応した Performance Monitoring SDK のバージョンをアプリで使用するだけで、ほぼリアルタイムのデータ処理を利用できます。

リアルタイム対応の SDK のバージョンは次のとおりです。

• iOS - v7.3.0 以降
• tvOS - v8.9.0 以降
• Android - v19.0.10 以降（または Firebase Android BoM v26.1.0 以降）
• ウェブ - v7.14.0 以降

常に最新バージョンの SDK を使用することをおすすめします。ただし、上述のいずれのバージョンでも、Performance Monitoring でほぼリアルタイムのデータ処理が行われます。

どのバージョンの Performance Monitoring SDK がリアルタイムに対応していますか？

リアルタイムのデータ処理に対応している SDK のバージョンは次のとおりです。

• iOS - v7.3.0 以降
• tvOS - v8.9.0 以降
• Android - v19.0.10 以降（または Firebase Android BoM v26.1.0 以降）
• ウェブ - v7.14.0 以降

常に最新バージョンの SDK を使用することをおすすめします。ただし、上述のいずれのバージョンでも、Performance Monitoring でほぼリアルタイムのデータ処理が行われます。

リアルタイム対応の SDK バージョンを使用するようにアプリを更新していないとどうなりますか？

リアルタイム対応の SDK バージョンをアプリで使用していない場合でも、Firebase コンソールにはアプリのパフォーマンス データがすべて表示されます。ただし、パフォーマンス データはデータの収集からおよそ 36 時間遅れて表示されます。

リアルタイム対応の SDK バージョンにアップデートしましたが、一部のユーザーは古いバージョンのアプリを使用しています。それらのユーザーのパフォーマンス データも Firebase コンソールで引き続き表示されますか？

はい。アプリ インスタンスで使用している SDK バージョンに関係なく、すべてのユーザーのパフォーマンス データが表示されます。

ただし、最近（約 36 時間以内）のデータについては、リアルタイム対応の SDK バージョンを使用するアプリ インスタンスのユーザーのデータが表示されます。一方、最近ではないデータには、すべてのバージョンのアプリのパフォーマンス データが表示されます。