ネットワーク リクエストのデータ集計をカスタマイズする

Firebase Performance Monitoring は類似したネットワーク リクエストのデータを自動的に集計します。これにより、ネットワーク リクエスト パフォーマンスの傾向を把握できます。

ただし、アプリのユースケースをより適切にサポートするために、Firebase が特定のネットワーク リクエスト データを集計する方法をカスタマイズする必要がある場合があります。ネットワーク リクエストのデータ集計をカスタマイズする方法には、カスタム URL パターンでのデータ集計と成功率の計算方法のカスタマイズの 2 つがあります。

カスタム URL パターンでデータを集計する

Firebase は、リクエストごとにネットワーク リクエストの URL が URL パターンと一致しているかどうかを確認します。リクエスト URL が URL パターンと一致した場合、Firebase はリクエストのデータを URL パターンごとに自動的に集計します。

カスタム URL パターンを作成すると、Firebase の自動 URL パターン マッチングで取得されない特定の URL パターンをモニタリングできます。たとえば、カスタム URL パターンを使用することで、特定の URL のトラブルシューティングを行うことができます。また、URL の特定のセットを継続的にモニタリングできます。

Firebase コンソールのパフォーマンス ダッシュボードの下部にあるトレース テーブルの [ネットワーク リクエスト] サブタブに、すべての URL パターン（カスタム URL パターンを含む）とそれらの集約データが表示されます。

カスタム URL パターン マッチングの仕組み

Firebase は、自動 URL パターン マッチングを行う前に構成済みのカスタム URL パターンとリクエスト URL をマッチングします。カスタム パターンに一致する URL にリクエストが送信されると、Firebase は、リクエストのデータをカスタム URL パターンごとに集計します。

リクエストの URL が複数のカスタム URL パターンと一致する場合、Firebase は最も限定的なカスタム URL パターンとのみリクエストをマッピングします。限定の順序は、パスの左から右に書式なしテキスト > * > ** です。たとえば、example.com/books/dog に対するリクエストは、次の 2 つのカスタム URL パターンに一致します。

• example.com/books/*
• example.com/*/dog

ここで、example.com/books/* の左端のセグメント books は example.com/*/dog の左端のセグメント * よりも優先されるため、パターン example.com/books/* が最も限定的な URL マッチング パターンになります。

新しいカスタム URL パターンを作成する場合は、次の点に注意してください。

• 新しいカスタム URL パターンを作成しても、以前のリクエストの一致と集計データには影響を与えません。Firebase が過去に遡ってリクエスト データを再集計することはありません。

• 新しいカスタム URL パターンの作成で影響を受けるのは、これから発生するリクエストのみです。Performance Monitoring がデータを収集して新しいカスタム URL パターンで集計するまでに最大で 12 時間ほどかかることがあります。

カスタム URL パターンの作成

Firebase コンソールのパフォーマンス ダッシュボードの下部にあるトレース テーブルの [ネットワーク リクエスト] サブタブから、カスタム URL パターンを作成できます。

新しいカスタム URL パターンを作成するには、プロジェクトのメンバーにオーナーまたは編集者のロールが付与されている必要があります。プロジェクトのどのメンバーも、カスタム URL パターンとその集計データを表示できます。

アプリ 1 個あたり合計 400 個までのカスタム URL パターンを作成でき、各アプリのドメイン 1 個あたり 100 個までのカスタム URL パターンを作成できます。

カスタム URL パターンを作成するには、ホスト名の後にパスセグメントを続けます。ホスト名には有効なドメインを含める必要があり、サブドメインを含めることもできます。次のパスセグメント構文を使用して、URL と一致するパターンを作成します。

• 書式なしテキスト - 完全な文字列に一致します。
• * - 最初のサブドメイン セグメント、または 1 つのパスセグメントに含まれる任意の文字列に一致します。
• ** - 任意のパス接尾辞に一致します。

次の表に、カスタム URL パターンのマッチングの候補を示します。

マッチング対象...	作成するカスタム URL パターン...	この URL パターンのマッチング例
正確な URL	example.com/foo/baz	example.com/foo/baz
任意の単一パスセグメント（*）	example.com/*/baz	example.com/foo/baz example.com/bar/baz
	example.com/*/*/baz	example.com/foo/bar/baz example.com/bah/qux/baz
	example.com/foo/*	example.com/foo/baz example.com/foo/bar 注: このパターンは example.com/foo と一致しません。
任意のパス接尾辞（**）	example.com/foo/**	example.com/foo example.com/foo/baz example.com/foo/baz/more/segments
	subdomain.example.com/foo.bar/**	subdomain.example.com/foo.bar subdomain.example.com/foo.bar/baz subdomain.example.com/foo.bar/baz/more/segments
最初のサブドメインのセグメント（*）	*.example.com/foo	bar.example.com/foo baz.example.com/foo

カスタム URL パターンとそのデータを表示する

Firebase コンソールのパフォーマンス ダッシュボードの下部にあるトレース テーブルの [ネットワーク リクエスト] サブタブに、すべての URL パターン（カスタム URL パターンを含む）とそれらの集約データが表示されます。

カスタム URL パターンのみを表示するには、トレース テーブルの [ネットワーク リクエスト] サブタブのプルダウン メニューから [カスタム パターン] を選択します。集計データがないカスタム URL パターンは、このリストにのみ表示されます。

URL パターンで集計したデータの保持期間が過ぎると、Firebase は URL パターンからデータを削除します。カスタム URL パターンで集計したすべてのデータが期限切れになっても、Firebase は Firebase コンソールからカスタム URL パターンを削除しません。代わりに、Firebase はトレース テーブルの [ネットワーク リクエスト] サブタブの [カスタム パターン] リストで、空のカスタム URL パターンを引き続き表示します。

カスタム URL パターンを削除する

プロジェクトからカスタム URL パターンを削除できます。自動 URL パターンは削除できません。

1. パフォーマンス ダッシュボードでトレース テーブルまでスクロールし、[ネットワーク リクエスト] サブタブを選択します。

2. [ネットワーク リクエスト] サブタブのプルダウン メニューから [カスタム パターン] を選択します。

3. 削除するカスタム URL パターンの行にカーソルを合わせます。

4. 行の右端にある more_vert をクリックして [カスタム パターンを削除] を選択し、ダイアログで削除を確定します。

カスタム URL パターンを削除する場合は、次の点に注意してください。

• 今後のリクエストは、次に限定的なカスタム URL パターンにマッピングされます。一致するカスタム URL パターンが見つからない場合、Firebase は自動 URL パターンを使用します。

• 以前のリクエストの一致とデータは、カスタム URL パターンを削除しても影響を受けません。

  削除したカスタム URL パターンとその集約データには、該当するデータ保存期間が終了するまで、[ネットワーク リクエスト] サブタブで引き続きアクセスできます（[すべてのネットワーク リクエスト] が選択されている場合）。削除されたカスタム URL パターンで集計されたデータがすべて期限切れになると、カスタム URL パターンは削除されます。

• [ネットワーク リクエスト] サブタブには（[カスタム パターン] が選択されている場合）、削除されたカスタム URL パターンは表示されません。

次のステップ

• アプリのパフォーマンスを低下させるネットワーク リクエストに関するアラートを設定する。たとえば、特定の URL パターンの応答時間が設定したしきい値を超えた場合に、チームに送信するメール通知アラートを構成できます。

成功率の計算方法をカスタマイズする

Firebase がネットワーク リクエストごとにモニタリングする指標の 1 つに、リクエストの成功率があります。成功率は、全レスポンス数に対する成功レスポンス数の割合です。この指標は、ネットワークとサーバーの障害を測定するのに役立ちます。

具体的には、Firebase では 100～399 の範囲のレスポンス コードのネットワーク リクエストが成功レスポンスであると自動的に判定されます。

Firebase が自動的に成功とカウントするレスポンス コードに加えて、特定のエラーコードを「成功レスポンス」とカウントすることで、成功率の計算をカスタマイズできます。

たとえば、アプリに検索エンドポイント API があり、検索エンドポイントの 404 レスポンスは想定内である場合、404 レスポンスを「成功」としてカウントできます。この検索エンドポイントに 1 時間あたり 100 件のサンプルがあり、そのうち 60 件が 200 レスポンス、40 件が 404 レスポンスであるとします。成功率を構成する前は、成功率は 60% です。404 レスポンスを成功としてカウントするように成功率計算を構成すると、成功率は 100% になります。

成功率の計算を構成する

ネットワーク URL パターンの成功率の計算を構成するには、firebaseperformance.config.update 権限が必要です。そのための権限はデフォルトで次のロールに含まれています。Firebase Performance 管理者、Firebase Quality 管理者、Firebase 管理者、プロジェクトのオーナーまたは編集者。

1. Firebase コンソールで Performance Monitoring の [ダッシュボード] タブに移動し、成功率の計算を構成するアプリを選択します。
2. 画面の下部にあるトレース テーブルまでスクロールし、[ネットワーク リクエスト] タブを選択します。
3. 成功率の計算を構成する URL パターンを見つけます。
4. 行の右端にあるオーバーフロー メニュー（more_vert）を開き、[成功率を構成する] を選択します。
5. 画面上の指示に沿って、成功レスポンス コードとしてカウントするレスポンス コードを選択します。