このページは Cloud Translation API によって翻訳されました。

検出ルールのカスタマイズ

Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントに移動。情報

Apigee Sense 検出ルールを表示またはカスタマイズして、不要である可能性のあるリクエストのみを検出できます。Apigee Sense 検出ルールでは、不要である可能性のあるクライアントリクエストを表すパターンが定義されます。

検出ルールの結果の表示の詳細については、Apigee Sense Console スタートガイドをご覧ください。

調整の例

たとえば、検出レポートで、24 時間のレスポンスエラーの割合が高いことが報告されており、不要なリクエストの一部が Brute Guessor パターンに一致していることがわかりました。しかし、このパターンで、API プロキシを介して許可する必要があるリクエストも検出していることがわかりました。

Brute Guessor パターン（以下の表）をカスタマイズすることで、必要なリクエストを許可し、そうでないものを検出するように、より適切に調整できます。Brute Guessor パターンには、次の表に示す条件と値が定義されています。一連のリクエストが 24 時間にわたってこれらの条件を満たす場合、Apigee Sense で、これらのリクエストが Brute Guessor パターンに一致していると報告されます。

条件	値
IP からの呼び出しの最小数	100
エラーしきい値の最小パーセント	90

設計上、24 時間で 90% を超えるエラーが許可される場合があります。この場合、ルールの保護設定により、正規のソースがブロックされる可能性があります。この機能により、条件値を変更できます。前述の例では、まず条件値を次のように変更します。

条件	値
IP からの呼び出しの最小数	100
エラーしきい値の最小パーセント	95

具体的なカスタマイズの変更は、有効なクライアントが API をどのように使用しているかに関するリクエストデータの内容に基づいて異なります。ただし、プロセスが反復的であることがわかる場合があります。この場合は、有用なルール定義になるまで段階的に変更を加えます。

検出の反復的調整

調整が必要な検出ルールには、段階的かつ反復的なアプローチをとることが最善の方法である場合があります。Apigee Sense の検出と分析のサイクルが機能する方法が原因で、各反復に 1 日ほどかかる場合があります。そのサイクルでは、Apigee Sense がクライアントリクエストに関するメタデータを保存し、そのデータを一括で分析し、結果を Apigee Sense コンソールで表示します。

たとえば、次のプロセスを使用できます。

Apigee Sense コンソールの検出レポートを使用して、実際に役立つリクエストを過度に多く検出しているルールなど、調整を使用できる検出ルールを特定します。
ルールのどの条件を調整する必要があるかを特定して、検出される不要なリクエストの割合が高くなるようにします。
Apigee Sense コンソールで、ルールを編集して、識別した条件値を控えめに増分変更します。
1 時間後に、検出レポートを使用して、変更によって、必要な効果がもたらされたかどうかを評価します。
有用な結果が得られるまで、必要に応じて繰り返します。

ガイドラインとベストプラクティス

検出ルールをカスタマイズするときは、次の点に注意してください。

ルールの条件は論理 AND 関係で結合されます。つまり、3 つの条件がある場合、リクエストがルールのパターンに一致するには、3 つの条件がすべて満たされる必要があります。
ルール条件には、最小しきい値が定義されるものや、最大しきい値が定義されるものがあります。
ルールを調整して、不要なトラフィックを特定するための十分なリクエストを検出することと、有用なトラフィックを検出するほど多くしないことのバランスを取ります。ベストプラクティスとして、有用なトラフィックが検出されないように、少なすぎるほど、検出するリクエスト数を減らします。
条件値をほんの少し変更しても、目立った違いはありません。変更の度合いについては、自分自身で判断してください。

パターン、条件、時間枠の詳細については、疑わしいアクティビティへの対処をご覧ください。