英語からAIを使用して翻訳されました
この記事はAI技術を使用して翻訳されたことにご注意ください。正確性を維持するよう努めていますが、一部の詳細は元のテキストを完全に反映していない場合があります。情報に不明な点がある場合は、英語版を参照してください。
APIエラー収集ルールを設定して、これらのエラーに関する詳細情報(ヘッダー、リクエスト/レスポンスボディの内容)を収集し、4XX-5XX範囲内だけでなく、ステータスコードを持つAPIエラーを収集して、エラーのトラブルシューティングを迅速に行えるようにします。
APIエラー収集を設定するには:
- HTTPステータスコードが4XX-5XX範囲内でないネットワークリクエストのAPIエラー収集を設定します。
- セッションリプレイでAPIエラーをトラブルシューティングして、以下の詳細を確認します:
- リクエストとレスポンスのHTTPヘッダー
- ボディ(リクエストによって送信されたデータまたはレスポンスで受信したデータ)
- ボディ要素(リクエスト/レスポンスボディの特定の要素)
- リクエストエンドポイントのクエリパラメータ(要求する情報のURL)
- Errors Dashboard & AlertsおよびAnalysis Contextで、レスポンスボディの内容に基づいてエラーを監視、特定、定量化するために、暗号化されていないレスポンスボディ要素を活用します。
設定が完了したら、APIエラーのトラブルシューティング詳細を活用する方法について詳しく学びます。
個人データの保護
追加するカスタムヘッダーによっては、トラブルシューティングの詳細に個人データが含まれる可能性があります。誰でも簡単にデータを復号化できないようにするために、個人データを含むカスタムヘッダーは暗号化することができますし、すべきです。
ヘッダーとボディ要素は、トラブルシューティングの詳細を公開する際の容易さと速度のために、暗号化されていない状態で収集するオプションがあります。このオプションは、追加する収集データポイントに個人データが含まれていないことが確実な場合にのみ使用するべきです。
リクエストおよび/またはレスポンスボディ全体、ならびにクエリパラメータは、暗号化された状態でのみ収集できます。
個人データを含む特定のヘッダー(クッキー、認証、プロキシ認証ヘッダー)を収集することは許可されていません。これらは処理できない機密データを含んでいます。
詳細については、プライバシーと個人データに関する記事をご覧ください。
トラブルシューティングの詳細を暗号化する
暗号化設定の前提条件:暗号化されたカスタムヘッダーのAPIトラブルシューティング詳細を追加および公開する前に、公開鍵/秘密鍵のペアを事前に設定する必要があります。
暗号化キーの設定に関する 手順はこちらで確認できます。
制限
ウェブ上では、当社の暗号化メカニズムは、ほとんどの人気ブラウザで広くサポートされている2つのブラウザAPI(CryptoKey APIおよびWeb Cryptography API)に依存しています。ただし、一部のブラウザや古いブラウザのバージョンはこれらをサポートしていません。その場合、タグは暗号化データの収集を進めません。
APIエラー収集ルールの概要
リストされた各ルールについて、次の情報を確認できます(左から右へ):
- ルール名
- ルールのステータスコード
- リクエストURL
- ルールが作成された日と最終更新日(および著者名)
新しいルールを作成するか、既存のルールを編集するかを決定するために、以下のアクションを使用してください:
- ルール検索:名前に含まれる用語やドメインのステータスコードに基づいて既存のルールを検索します。
- ルールの並べ替え:列の見出しをクリックして、名前、ステータスコード、ドメイン、または日付(作成日または最終更新日)でルールを並べ替えます。
-
ルールの詳細表示:ルールの右側にある「目」アイコンをクリックしてサイドパネルを開き、収集条件と収集データポイントを確認します。
「デフォルトルール」
このルールは、4XX-500範囲のステータスコードを持つすべてのネットワークリクエストを収集するデフォルトの動作を表しており、デフォルトのデータポイント(リクエストURL、ステータスコード、メソッド)のみを含みます。編集または削除することはできません。
定義済みルール
これらの定義済みルールは、すでにプロジェクトに含まれており、APIエラーおよびAPIエラーの詳細を自動的に収集することを可能にします:
- GraphQL:このルールは、通常は200のステータスコードを持つためデフォルトでは収集されない基本的なGraphQLエラーを収集するために設計されています。このルールは必要に応じて編集および削除できます。
- すべてのエンドポイントのヘッダー:このルールは、すべてのAPI 4XX-5XXエラーのヘッダー収集を設定するために使用されます。ヘッダーのリストは編集可能ですが、ルール自体は削除できません。
新しいルールの作成
ステップ1:ルールの名前付けと条件の追加
1. ‘+ 新しいルール’ボタンをクリックします。
2. ルール名:ルール名フィールドにルールの名前を付けます。この名前は一意でなければなりません。
3. リクエストURL:ルールは、URLにフィールドに追加した値が含まれるすべてのリクエストに一致します。注意:他の既存のルールとまったく同じ条件の集合を使用することはできません。
例(リクエストURLに一致させたい場合): https://subdomain.domain.com/path/sub-path?query=param
次の値が一致します:
- 完全なURL: https://subdomain.domain.com/path/sub-path?query=param
- ドメイン&HTTPプロトコル: https://subdomain.domain.com
- ドメインのみ: domain.com
- パスのみ: /path/sub-path
- ドメイン + パス: subdomain.domain.com/path/sub-path
4. ステータスコード: HTTP ステータスコードのエラーをカバーする 4XX-5XX グループを選択するか、特定のステータスコードを定義できます。
5. レスポンスボディコンテンツ: このルールが収集されるために、ボディコンテンツフィールドにレスポンスのボディに書かれるべき内容を指定します。最大 64 文字を入力できます。このフィールドは、ステータスコードが「200」の場合を除き、すべてのステータスコードに対してオプションです。「200」ステータスコードが指定されている場合は、理想的にはエラーを特定するレスポンスボディコンテンツを指定する必要があります。これは、すべてのネットワークリクエストを API エラーとして収集するのを避けるために行われます。
レスポンスボディコンテンツのロジックと制限
これはフィルタリングロジックで、ロジックは「含む」ため、正確なテストは必要ありません。レスポンスボディコンテンツは大文字と小文字を区別しません(「invalid」は「INVALID_CODE」のような値に一致します)。
例:
レスポンスにエラーが含まれているときにリクエストを収集したいです。
レスポンスボディサンプル:
{ "errors": [ { "message": "Cannot query field 'age' on type 'Customer'.", "code": "1003" } ], "data": { "customer": { "id": "123", "name": "John Doe" } } }
使用するボディコンテンツ値: errors
使用するボディコンテンツ値(特殊文字を含む): errors\"\:\[\{
レスポンスボディコンテンツの制限:
- Android モバイルアプリでは、レスポンスボディが最大 1MB のサイズである場合にボディコンテンツの一致が機能します。
- iOS モバイルアプリでは、レスポンスボディコンテンツサイズに制限はありません。
- ウェブでは、レスポンスボディコンテンツサイズに制限はありません。
6. ルール作成を続けるには「次へ」をクリックします。
ステップ 2: 収集したデータポイントの追加
ルールに名前、条件、リクエスト URL(およびステータスコードが 200 の場合はボディコンテンツ)を入力した後、収集したデータポイントを追加できます。デフォルトでは、Contentsquare はリクエスト URL、ステータスコード、およびメソッドを収集します。
ヘッダー
1. “+ 追加”をクリックします。すべてのヘッダーが同じ条件(リクエストまたはレスポンス、暗号化または非暗号化)を共有している場合は、「+」ボタンをクリックして複数のヘッダーを一度に追加できます。
2. ヘッダー名を入力します。
3. 暗号化:
- 暗号化が設定されている場合、デフォルトの状態は「暗号化済み」になります。ヘッダーを非暗号化で収集するには、オフに切り替えます。
- 暗号化が設定されていない場合、ヘッダーは非暗号化でのみ収集できます。個人情報を含むヘッダーを収集しないようにしてください。
4. デフォルトでは「リクエスト」が選択されています。これを更新してレスポンスを収集することもできます。
5. “適用”をクリックします。
ボディ要素
特定のリクエストまたはレスポンスボディの要素を JSON 形式で収集することにより、活用したいデータポイントの柔軟性を高めることができます。JSON Path ベースのクエリ言語を使用して。
注意: ボディ要素を編集することはできませんが、削除して再作成することはできます。
JSON Pathの長さは60文字に制限されています。
分析用のレスポンスボディ要素
エラーのグループ化とフィルタリング(分析コンテキスト内)およびダッシュボードウィジェットとアラートの作成に使用される、暗号化されずに収集されるレスポンスボディの要素です。
分析のために収集するレスポンスボディ要素を定義するには:
1. “+ 追加”をクリックします。
2. 収集したい要素のJSONパスを入力します。“+”ボタンをクリックすることで、複数のエントリを一度に追加することもできます。
3. “適用”をクリックします。
トラブルシューティング用のレスポンスボディ要素
セッションリプレイの個別イベントレベルで表示される、トラブルシューティングのために収集したいリクエスト/レスポンスボディの要素です。
収集するトラブルシューティング用のレスポンスボディ要素を定義するには:
1. “+ 追加”をクリックします。
2. 収集したい要素のJSONパスを入力します。“+”ボタンをクリックすることで、複数のエントリを一度に追加することもできます。
3. 暗号化:
- 暗号化が設定されている場合、デフォルトの状態は“暗号化済み”になります。ボディ要素を暗号化せずに収集するには、オフに切り替えます。
- レスポンスの場合: トラブルシューティング用のボディ要素は暗号化された状態でのみ収集でき、暗号化されていないレスポンスボディ要素は分析のために追加されます(上記のセクションにて)。
- 暗号化が設定されていない場合、リクエストボディ要素のみが暗号化されずに収集できます。個人情報を含むボディ要素を収集しないようにしてください。
4. デフォルトでは“レスポンス”が選択されています。レスポンスまたはリクエストのボディ要素を収集できます。
5. “適用”をクリックします。
サポートされているボディの種類
ボディ要素の収集は、以下の条件下でリクエスト/レスポンスボディに対して利用可能です:
Web | モバイルアプリ |
‘content-type’ヘッダーが‘application/json’または‘application/graphql’に設定されている必要があります | ボディ形式は任意のJSONタイプである必要があります |
サイズは64,000バイト未満である必要があります | サイズは64,000バイト未満である必要があります |
ボディ要素の例:
“errors[0].message”はエラーメッセージを暗号化せずに収集
“errors[0].code”はエラーコードを暗号化せずに収集
“data.emailAddress”は個人データであるため暗号化して収集
全体のボディ(暗号化済み)
リクエストまたはレスポンスボディ、またはその両方を収集するには、ボックスにチェックを入れます。表示または追跡できない機密データを含むエンドポイントやフィールドを含めないようにしてください。この情報は許可されていません。
サポートされているボディの種類と制限
ウェブ | モバイルアプリケーション |
application/json |
SDKは、フォーマットに関係なく、ボディを文字列として解析しようとします
|
全体のボディコレクションの制限:
リクエストボディは、そのサイズが64 KBを超えない場合に収集されます。
レスポンスボディは、そのサイズが5 KBを超えない場合に収集されます
クエリパラメータ(暗号化済み)
クエリパラメータを収集するには、ボックスにチェックを入れてください。クエリパラメータは、そのサイズが2 KBを超えない場合に収集されます。
デフォルトデータポイント
デフォルトでは、リクエストURL、ステータスコード、メソッドを収集します。
ルールの編集と削除
ルールリストから、ルールの右側にある「目」アイコンをクリックして、ルールのサイドパネルを開きます。
編集するには:
1. ルール名または条件セクションの鉛筆アイコンをクリックします。
2. ステップ1でルールモーダルを開きます。
3. 収集されたデータポイントセクションの鉛筆アイコンをクリックして、ステップ2のルールモーダルを開きます。
4. 変更を適用します。
5. 必要に応じて、他のモーダルに移動して追加の変更を適用します。
6. 「保存」をクリックして変更を適用します。
削除するには:
1. 下部の「ルールを削除」ボタンをクリックします。
2. 「削除」を再度クリックして削除アクションを確認します。
よくある質問
エラーのトラブルシューティングの詳細を遡って追跡できますか?
いいえ、エラーのトラブルシューティングの詳細は、設定が定義された後にのみ収集されます。
リクエストが受け入れられる制限を超えた場合はどうなりますか?
次の制限を持つ3つのデータポイントがあります:
- クエリパラメータの制限: 2 KB
- リクエストボディのサイズ制限: 64 KB
- レスポンスボディのサイズ制限: 5 KB
これらのデータポイントは、他のものとは独立して評価されます。制限に達した場合、データは収集されません。それぞれについて、"..."を暗号化せずにプッシュします。これはリプレイのトラブルシューティングの詳細に反映されます。
リクエストまたはレスポンスボディが、復号化後もエンコードされているように見えるのはなぜですか?
これは、リクエストにヘッダーTransfer-Encoding
がgzip
に設定されている場合に発生することがあります。Chrome DevToolsは自動的にボディを解凍するため、使用しているときには目立ちません。しかし、Player Troubleshootモーダルで見ると、ボディは自動的に解凍されません。復号化後に解凍するためにサードパーティツールを使用することができます。