Firebase Performance Monitoring は、同様のネットワーク リクエストのデータを自動的に集計して、ネットワーク リクエストのパフォーマンスの傾向を把握するのに役立ちます。
ただし、アプリのユースケースをより適切にサポートするために、Firebase が特定のネットワーク リクエスト データを集約する方法をカスタマイズする必要がある場合があります。ネットワーク リクエストのデータ集計をカスタマイズする方法は 2 つあります。カスタム URL パターンでデータを集計する方法と、成功率の計算方法をカスタマイズする方法です。
カスタム URL パターンでデータを集約する
リクエストごとに、Firebase はネットワーク リクエストの URL がURL パターンと一致するかどうかを確認します。リクエスト URL が URL パターンと一致する場合、Firebase は URL パターンに基づいてリクエストのデータを自動的に集約します。
カスタム URL パターンを作成して、Firebase が派生した自動 URL パターン マッチングでキャプチャしていない特定の URL パターンを監視できます。たとえば、カスタム URL パターンを使用して、特定の URL のトラブルシューティングを行ったり、特定の URL セットを経時的に監視したりできます。
Firebase は、すべての URL パターン (カスタム URL パターンを含む) とその集計データを、Firebase コンソールのパフォーマンスダッシュボードの下部にあるトレース テーブルの [ネットワーク リクエスト] サブタブに表示します。
カスタム 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/books/*
は、 example.com/*/dog
の左端のセグメントbooks
がexample.com/books/*
の左端のセグメント*
よりも優先されるため、一致する最も具体的なURL パターンです。
新しいカスタム URL パターンを作成するときは、次の点に注意してください。
新しいカスタム URL パターンを作成しても、以前のリクエストからの一致と集計データは影響を受けません。 Firebase はリクエスト データをさかのぼって再集計しません。
新しいカスタム URL パターンを作成することによって影響を受けるのは、将来のリクエストのみです。 Performance Monitoring が新しいカスタム 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 は、すべての URL パターン (カスタム URL パターンを含む) とその集計データを、Firebase コンソールのパフォーマンスダッシュボードの下部にあるトレース テーブルの [ネットワーク リクエスト] サブタブに表示します。
カスタム URL パターンのみを表示するには、トレース テーブルの [ネットワーク リクエスト] サブタブのドロップダウン メニューから [カスタム パターン] を選択します。カスタム URL パターンに集計データがない場合は、このリストにのみ表示されることに注意してください。
URL パターンで集計されたデータのデータ保持期間が終了すると、Firebase はそのデータを URL パターンから削除します。カスタム URL パターンで集計されたすべてのデータの有効期限が切れた場合、Firebase はカスタム URL パターンを Firebase コンソールから削除しません。代わりに、Firebase は引き続き、トレース テーブルの [ネットワーク リクエスト] サブタブの [カスタム パターン] リストに「空の」カスタム URL パターンをリストします。
カスタム URL パターンを削除する
プロジェクトからカスタム URL パターンを削除できます。自動 URL パターンは削除できないことに注意してください。
パフォーマンスダッシュボードから、トレース テーブルまで下にスクロールし、[ネットワーク リクエスト] サブタブを選択します。
[ネットワーク リクエスト] サブタブのドロップダウン メニューから [カスタム パターン] を選択します。
削除するカスタム URL パターンの行にカーソルを合わせます。
行の右端にある
をクリックし、[カスタム パターンの削除] を選択して、ダイアログで削除を確認します。
カスタム URL パターンを削除する場合は、次の点に注意してください。
今後のリクエストは、次に一致する最も具体的なカスタム URL パターンにマップされます。一致するカスタム URL パターンが見つからない場合、Firebase は自動 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 、および project Owner または Editorのロールには、この必要な権限がデフォルトで含まれています。
- Firebase コンソールの [Performance Monitoring Dashboard ] タブに移動し、成功率の計算を構成するアプリを選択します。
- 画面下部のトレース テーブルまで下にスクロールし、[ Network requests ] タブを選択します。
- 成功率の計算を構成する URL パターンを見つけます。
- 行の右端にあるオーバーフロー メニュー ( ) を開き、 [ Configure success rate ] を選択します。
- 画面の指示に従って、成功した応答コードとしてカウントする応答コードを選択します。