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

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 パターンとそのデータを表示する

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

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

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

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

パフォーマンスダッシュボードでトレーステーブルまでスクロールし、[ネットワークリクエスト] サブタブを選択します。
[ネットワークリクエスト] サブタブのプルダウンメニューから [カスタムパターン] を選択します。
削除するカスタム URL パターンの行にカーソルを合わせます。
行の右端にあるをクリックして [カスタムパターンを削除] を選択し、ダイアログで削除を確定します。

カスタム 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 管理者、プロジェクトのオーナーまたは編集者。

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