英語からAIを使用して翻訳されました
この記事はAI技術を使用して翻訳されたことにご注意ください。正確性を維持するよう努めていますが、一部の詳細は元のテキストを完全に反映していない場合があります。情報に不明な点がある場合は、英語版を参照してください。
APIエラーの高度なトラブルシューティング設定により、APIエラー(ヘッダー、リクエスト/レスポンスボディの内容)に関する詳細情報を収集するルールを作成できるほか、4XX-5XX範囲だけでなく、ステータスコードを持つAPIエラーを収集できるため、エラーのトラブルシューティングを迅速に行うことができます。
APIエラーの高度なトラブルシューティングを使用して:
- HTTPステータスコードが400未満のネットワークリクエストのAPIエラーの収集を設定します。
- セッションリプレイのイベントストリームで次の種類の追加APIエラー詳細を確認します:
- リクエストとレスポンスのHTTPヘッダー
- ボディ(リクエストによって送信されたデータまたはレスポンスで受信したデータ)
- ボディ要素(リクエスト/レスポンスボディの特定の要素)
- リクエストエンドポイントのクエリパラメータ(要求する情報のURL)
- Errors Dashboards & AlertsおよびAnalysis Contextで暗号化されていないレスポンスボディ要素を活用し、レスポンスボディの内容に基づいてエラーを監視、特定、定量化します。
設定が完了したら、APIエラーのトラブルシューティング詳細を活用する方法について詳しく学んでください。
個人データの保護
追加するカスタムヘッダーによっては、トラブルシューティングの詳細に個人データが含まれる可能性があります。誰でも簡単に復号化できないようにデータを保護するために、個人データを含むカスタムヘッダーは暗号化することが推奨されます。
ヘッダーとボディ要素は、トラブルシューティングの詳細を公開する際の容易さと速度のために、暗号化されていない状態で収集するオプションがあります。このオプションは、追加する収集データポイントに個人データが含まれていないことが確実な場合にのみ使用するべきです。
リクエストおよび/またはレスポンスボディ全体やクエリパラメータは、暗号化された状態でのみ収集できます。
個人データを含む特定のヘッダー(クッキー、認証、プロキシ認証ヘッダー)を収集することは許可されていません。これらは処理できない機密データを含んでいます。
詳細については、プライバシーと個人データに関する記事をご覧ください。
トラブルシューティングの詳細を暗号化する
暗号化設定の前提条件: 暗号化されたカスタムヘッダーのAPIトラブルシューティング詳細を追加および公開する前に、公開鍵/秘密鍵のペアを事前に設定する必要があります。
暗号化キーの設定に関する手順はこちらで確認できます.
制限
ウェブ上では、私たちの暗号化メカニズムは、ほとんどの人気ブラウザによって広くサポートされている2つのブラウザAPI(CryptoKey APIおよびWeb Cryptography API)に依存しています。しかし、一部のブラウザや古いブラウザのバージョンはこれらをサポートしていません。その場合、タグは暗号化データの収集を進めません。
APIエラーのトラブルシューティングタブの概要
1. プロフィールアイコンをクリックし、次に'コンソール'をクリックしてコンソールに移動します。
2. '高度なエラーのトラブルシューティング'タブをクリックします。
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. ステータスコード: 4XX-5XXグループを選択してHTTPステータスコードのエラーをカバーするか、特定のステータスコードを定義できます。
5. レスポンスボディコンテンツ: このルールが収集されるために、ボディコンテンツフィールドにレスポンスのボディに書かれるべき内容を指定します。最大64文字まで入力できます。このフィールドはすべてのステータスコードに対してオプションですが、「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”は個人データとして暗号化されたメールアドレスを収集します
全体のボディ(暗号化済み)
リクエストまたはレスポンスボディ、またはその両方を収集するためにボックスにチェックを入れてください。表示または追跡できない機密データを含むエンドポイントやフィールドを含めないようにしてください。この情報は許可されていません。
サポートされているボディの種類と制限
Web | モバイルアプリケーション |
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モーダルで見ると、ボディは自動的に解凍されません。サードパーティのツールを使用して、復号化後に解凍することができます。