Firebase Performance Monitoringは、類似のネットワークリクエストのデータを自動的に集計して、ネットワークリクエストのパフォーマンスの傾向を理解するのに役立ちます。
ただし、アプリのユースケースをより適切にサポートするために、Firebaseが特定のネットワークリクエストデータを集計する方法をカスタマイズする必要がある場合があります。ネットワークリクエストのデータ集約をカスタマイズする2つの方法を提供します。カスタムURLパターンでデータを集約する方法と、成功率の計算方法をカスタマイズする方法です。
カスタムURLパターンでデータを集約する
Firebaseは、リクエストごとに、ネットワークリクエストのURLがURLパターンと一致するかどうかを確認します。リクエストのURLがURLパターンと一致する場合、FirebaseはリクエストのデータをURLパターンの下に自動的に集約します。
カスタムURLパターンを作成して、Firebaseがキャプチャしていない特定のURLパターンを、派生した自動URLパターンマッチングで監視できます。たとえば、カスタムURLパターンを使用して、特定のURLのトラブルシューティングを行ったり、特定のURLセットを経時的に監視したりできます。
Firebaseは、Firebaseコンソールのパフォーマンスダッシュボードの下部にあるトレーステーブルの[ネットワークリクエスト]サブタブに、すべてのURLパターン(カスタムURLパターンを含む)とそれらの集計データを表示します。
カスタムURLパターンマッチングはどのように機能しますか?
Firebaseは、自動URLパターンマッチングにフォールバックする前に、リクエストURLを設定済みのカスタムURLパターンと照合しようとします。カスタムURLパターンに一致するリクエストの場合、FirebaseはリクエストのデータをカスタムURLパターンに集約します。
リクエストのURLが複数のカスタムURLパターンに一致する場合、Firebaseは、パスの左から右へのプレーンテキスト> *
> **
の特定の順序に従って、リクエストを最も具体的なカスタムURLパターンにのみマッピングします。たとえば、 example.com/books/dog
/ books / dogへのリクエストは、次の2つのカスタムURLパターンに一致します。
-
example.com/books/*
-
example.com/*/dog
ただし、 example.com/*/dog
/ books / *の左端のセグメントのbooks
がexample.com/books/*
の左端のセグメント*
よりも優先されるため、パターンexample.com/books/*
が最も具体的に一致するURLパターンです。
新しいカスタムURLパターンを作成するときは、次の点に注意してください。
以前のリクエストからの一致と集約データは、新しいカスタムURLパターンを作成しても影響を受けません。 Firebaseは、リクエストデータをさかのぼって再集計しません。
新しいカスタムURLパターンを作成すると、将来のリクエストのみが影響を受けます。パフォーマンスモニタリングが新しいカスタムURLパターンでデータを収集および集約するまで、最大12時間待つ必要がある場合があります。
カスタムURLパターンを作成する
Firebaseコンソールのパフォーマンスダッシュボードの下部にあるトレーステーブルの[ネットワークリクエスト]サブタブからカスタムURLパターンを作成できます。
新しいカスタムURLパターンを作成するには、プロジェクトメンバーは所有者または編集者である必要があります。ただし、すべてのプロジェクトメンバーは、カスタムURLパターンとその集約データを表示できます。
アプリごとに合計最大400のカスタムURLパターンを作成し、そのアプリのドメインごとに最大100のカスタムURLパターンを作成できます。
カスタムURLパターンを作成するには、ホスト名で始まり、パスセグメントが続きます。ホスト名には有効なドメインが含まれている必要があり、オプションでサブドメインを含めることができます。次のパスセグメント構文を使用して、URLに一致するパターンを作成します。
- プレーンテキスト—完全に一致する文字列
*
—最初のサブドメインセグメント、または単一パスセグメント内の任意の文字列に一致します**
—任意のパスサフィックスに一致します
次の表は、いくつかの潜在的なカスタム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/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は、Firebaseコンソールのパフォーマンスダッシュボードの下部にあるトレーステーブルの[ネットワークリクエスト]サブタブに、すべてのURLパターン(カスタムURLパターンを含む)とそれらの集計データを表示します。
カスタムURLパターンのみを表示するには、トレーステーブルの[ネットワークリクエスト]サブタブのドロップダウンメニューから[カスタムパターン]を選択します。カスタムURLパターンに集約データがない場合は、このリストにのみ表示されることに注意してください。
URLパターンで集計されたデータのデータ保持期間が終了すると、FirebaseはそのデータをURLパターンから削除します。カスタムURLパターンで集計されたすべてのデータの有効期限が切れた場合、FirebaseはFirebaseコンソールからカスタムURLパターンを削除しません。代わりに、Firebaseは、トレーステーブルの[ネットワークリクエスト]サブタブの[カスタムパターン]リストに「空の」カスタムURLパターンを引き続きリストします。
カスタムURLパターンを削除する
プロジェクトからカスタムURLパターンを削除できます。自動URLパターンは削除できないことに注意してください。
パフォーマンスダッシュボードから、トレーステーブルまで下にスクロールし、[ネットワーク要求]サブタブを選択します。
[ネットワークリクエスト]サブタブのドロップダウンメニューから[カスタムパターン]を選択します。
削除するカスタムURLパターンの行にカーソルを合わせます。
行の右端にある
をクリックし、[カスタムパターンの削除]を選択して、ダイアログで削除を確認します。
カスタムURLパターンを削除するときは、次の点に注意してください。
今後のリクエストは、次に一致するカスタムURLパターンにマッピングされます。 Firebaseが一致するカスタムURLパターンを検出しない場合、自動URLパターンマッチングにフォールバックします。
以前のリクエストからの一致と集計データは、カスタムURLパターンを削除しても影響を受けません。
該当するデータ保持期間が終了するまで、[ネットワークリクエスト]サブタブ([すべてのネットワークリクエスト]が選択されている)で、削除されたカスタムURLパターンとその集約データに引き続きアクセスできます。削除されたカスタムURLパターンの下にあるすべての集計データが期限切れになると、Firebaseはカスタム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 Admin 、 Firebase Quality Admin 、 Firebase Admin 、およびプロジェクトの所有者または編集者。
- Firebaseコンソールの[パフォーマンスモニタリングダッシュボード]タブに移動し、成功率の計算を構成するアプリを選択します。
- 画面下部のトレーステーブルまで下にスクロールして、[ネットワークリクエスト]タブを選択します。
- 成功率の計算を構成するURLパターンを見つけます。
- 行の右端で、オーバーフローメニュー( )を開き、[成功率の構成]を選択します。
- 画面の指示に従って、成功した応答コードとしてカウントする応答コードを選択します。