アナリティクス指標、ディメンション、フィルタのリファレンス

1 秒あたりの平均トランザクション数（つまり API プロキシ リクエスト数）。期間中のトランザクション数が比較的少ない場合、1 秒あたりの平均トランザクション数が小数第 2 位より小さいと、UI カスタム レポートでゼロと表示されることがあります。

API 構文: tps

ターゲット サービスからのレスポンスの代わりに Response Cache を使用する API リクエストが正常に行われた回数。

API 構文: sum(cache_hit)

指定期間中の 1 トランザクションあたりの L1（メモリ内）キャッシュにある要素数を返します。たとえば、1 日という期間を指定して max を選択するとします。このとき、同日中の特定トランザクションにおけるキャッシュ内要素の最大数が 12 であった場合は、そのカウント「12」が返されます。また、トランザクションが 3 件ある期間を指定して avg を選択するとします。このとき、キャッシュ内要素数がそれぞれ 5、6、7 であった場合は、その平均値「6」が返されます。L1 キャッシュはメモリ内キャッシュであり、L2 データベース キャッシュとは異なります。これについてはキャッシュの仕組みで説明しています。

API 構文: avg(ax_cache_l1_count)

指定期間中に発生したポリシーエラーの総数です。

通常、ポリシーエラーの発生は意図されたものです。たとえば、Verify API Key ポリシーは、リクエストで無効な API キーが渡されたときエラーをスローします。Spike Arrest ポリシーがエラーをスローするのは、API 呼び出し数がポリシーで定義された上限を超えた場合です。そのため、この指標は API 内で潜在的に問題が起こりやすい箇所を見つける場合に役立ちます。たとえば、policy_error 指標が developer_app ディメンションでグループ化されている場合は、API キーまたは OAuth トークンが指定のアプリで期限切れになっていることを検出するために役立つ可能性があります。あるいは特定の API プロキシが多数の Spike Arrest エラーをスローしている場合は、そのプロキシの Spike Arrest 上限で休日のトラフィック増加が考慮されていないことを発見できる可能性があります。

ポリシーエラーがアナリティクスに記録されるのは、そのエラーが API プロキシ障害になる場合だけです。たとえば、ポリシーの continueOnError 属性が true に設定されている場合、API プロキシはポリシーが失敗した場合でもリクエストの処理を続けます。その場合、ポリシーエラーはアナリティクスに記録されません。

エラー時のポリシー名（ax_execution_fault_policy_name）ディメンションは、ポリシーエラーをポリシー名別にグループ化する場合に便利です。

ターゲット障害（404 や 503 など）はポリシー障害としてカウントしません。これらは API プロキシ障害（is_error）としてカウントします。

API 構文: sum(policy_error)

指定期間中に API プロキシがエラーとなった回数の合計です。プロキシ障害が発生するのは、ポリシーが失敗したときか、ターゲット サービスからランタイム障害（404 や 503 など）が発生したときです。

プロキシ（apiproxy）ディメンションは、API プロキシ障害をプロキシ別にグループ化する場合に便利です。

API 構文: sum(is_error)

Edge が受信リクエストを処理するのにかかる平均、最小、または最大時間（ミリ秒）。この時間はリクエストが Edge に到達したとき開始し、Edge がリクエストをターゲット サービスに転送したとき終了します。

さまざまなディメンションを使用することで、リクエスト処理レイテンシを API プロキシ別、デベロッパー アプリ別、リージョン別などで調べることができます。

API 構文: max(request_processing_latency)

Edge により受信されるリクエスト ペイロードのサイズ（バイト単位）。

API 構文: avg(request_size)

Response Cache ポリシーが指定の期間中に実行された総回数。

Response Cache ポリシーは API プロキシの 2 か所で接続されるため（1 回はリクエスト中、もう 1 回はレスポンス中）、通常は 1 回の API 呼び出しで 2 回実行されます。キャッシュ「get」とキャッシュ「put」はそれぞれを 1 回の実行としてカウントします。

ただし、ポリシー内の <SkipCacheLookup> 要素が（リクエスト内で）true の場合はレスポンス キャッシュ実行は 0 に、ポリシー内の <SkipCachePopulation> 要素が（レスポンス内で）true の場合も 0 になります。

Trace ツールで、実行された API 呼び出しの [Response Cache] アイコンをクリックし、responsecache.executed フロー変数を見ると、キャッシュ実行があったかどうかがわかります。あった場合は値が「1」となります。

API 構文: sum(ax_cache_executed)

Edge が API レスポンスを処理するのにかかる平均、最小、または最大時間（ミリ秒）。この時間は API プロキシがターゲット サービス レスポンスを受信したとき開始し、Apigee がレスポンスを元の呼び出し元に転送したとき終了します。

さまざまなディメンションを使用することで、レスポンス処理レイテンシを API プロキシ別、リージョン別などで調べることができます。

API 構文: min(response_processing_latency)

クライアントに返されるレスポンス ペイロードのサイズ（バイト単位）。

API 構文: max(response_size)

ターゲット サービスからの 5xx レスポンスの総数。これらのターゲット サービスエラーは、Apigee に起因するものではありません。

API 構文: sum(target_error)

ターゲット サーバーが呼び出しに応答する合計時間、平均時間、最小時間、または最大時間（ミリ秒）。この指標により、ターゲット サーバーのパフォーマンスがわかります。この時間は Edge がリクエストをターゲット サービスに転送したとき開始し、Edge がレスポンスを受信したとき終了します。

Response Cache ポリシーなどを使用してキャッシュからレスポンスを返す API 呼び出しは、ターゲット サービスに到達しないため、ターゲット レスポンス時間指標が記録されないことに留意してください。

API 構文: avg(target_response_time)

Edge がクライアントからリクエストを受信してからクライアントにレスポンスを返信するまでの合計時間、平均時間、最小時間、または最大時間（ミリ秒単位）。この時間には、ネットワーク オーバーヘッド（たとえばロードバランサやルーターがそれぞれの仕事をするのにかかる時間）、リクエスト処理レイテンシ、レスポンス処理レイテンシ、ターゲット レスポンス時間（レスポンスが、キャッシュではなくターゲット サービスから返される場合）が含まれます。

さまざまなディメンションを使用することで、処理レイテンシを API プロキシ別、デベロッパー アプリ別、リージョン別などで調べることができます。

API 構文: avg(total_response_time)

指定された期間に Edge により処理される API 呼び出しの合計数。

ディメンションを使用することで、トラフィック数を最も有意義な方法でグループ化できます。

API 構文: sum(message_count)

呼び出し先の API プロキシを含む API プロダクトの名前。このディメンションを取得するには、呼び出し元のデベロッパー アプリが、API プロキシを含む 1 つ以上の API プロダクトに関連付けられている必要があります。また、呼び出し先のプロキシは、API 呼び出しで送信される API キーまたは OAuth トークンを検証する必要があります。キーまたはトークンは API プロダクトに関連付けられています。詳細については、最初にすべきこと: 完全な分析データを生成する方法をご覧ください。

上記の条件が満たされない場合、「(not set)」の値が表示されます。分析エンティティ値「(not set)」の意味もご覧ください。

アクセスされた Response Cache 値を含むキー。このキーが Response Cache で構成される方法について詳しくは、Response Cache ポリシーをご覧ください。

Trace ツールで、キャッシュに対して読み書きを行う Response Cache ポリシーを選択すると、この値が responsecache.cachekey フロー変数に表示されます。

Response Cache ポリシーが使用する Key-Value を含むキャッシュの名前。接頭辞 orgName__envName__ が付きます。たとえば、組織が「foo」、環境が「test」、キャッシュ名が「myCache」の場合、ax_cache_name は foo__test__myCache です。

Trace ツールで、Response Cache ポリシーを選択すると、この値が responsecache.cachename フロー変数に表示されます。

Response Cache が取得されたキャッシュ レベル（「L1」メモリ内または「L2」データベース）。このディメンションは、レスポンスがキャッシュではなくターゲットから送られたとき（およびレスポンス キャッシュがターゲット レスポンスでリフレッシュされたとき）、またはリクエスト内のキャッシュキーが無効なときに「CACHE_MISS」も表示します。キャッシュキーはサイズが 2 KB に制限されています。

Trace ツールで、Response Cache ポリシーを選択すると、この値が responsecache.cachesource フロー変数に表示されます。

キャッシュ レベルの詳細については、キャッシュの仕組みをご覧ください。

発信側クライアント IP アドレスを含みます。ax_resolved_client_ip ディメンションの値は、ax_true_client_ip ディメンションと x_forwarded_for_ip ディメンションの値から計算されます。

Akamai などのルーティング プロダクトを使用してクライアントの真の IP アドレスを取得する場合、クライアント IP は Edge の HTTP ヘッダー True-Client-IP に渡されることにご留意ください。その後、ax_true_client_ip ディメンションを設定するために使用されます。

ax_resolved_client_ip ディメンションの値は以下のように計算されます。

1. ax_true_client_ip が null でなくローカル IP アドレスを含まない場合は、ax_resolved_client_ip を ax_true_client_ip に設定します。
2. それ以外の場合は、ax_resolved_client_ip を x_forwarded_for_ip の最初の非ローカル IP アドレスに設定します。
3. ax_true_client_ip と x_forwarded_for_ip の両方にローカル IP のみが含まれる場合は、ax_resolved_client_ip を x_forwarded_for_ip の最後のローカル IP に設定します。
4. ax_true_client_ip と x_forwarded_for_ip の両方が null の場合は、ax_resolved_client_ip を「(not set)」に設定します。
5. ax_true_client_ip がローカル IP で x_forwarded_for_ip が null の場合は、ax_resolved_client_ip を「(not set)」に設定します。

API 呼び出しを行っているデベロッパー アプリのコンシューマ キー（API キー）。リクエスト内で API キーとして渡されるか、OAuth トークンに含まれます。

このディメンションを取得するには、呼び出し先のプロキシが API キーまたは OAuth トークンの有効性を検証するよう構成する必要があります。デベロッパー アプリが API キーを取得し、アプリが Edge に登録されている場合は、これを使用して OAuth トークンを生成できます。詳細については、最初にすべきこと: 完全な分析データを生成する方法をご覧ください。

上記の条件が満たされない場合、「(not set)」の値が表示されます。分析エンティティ値「(not set)」の意味もご覧ください。

API 呼び出しを行っている、Edge 登録したデベロッパー アプリ。

このディメンションを取得するには、呼び出し元のデベロッパー アプリが、呼び出し先の API プロキシを含む 1 つ以上の API プロダクトに関連付けられている必要があります。また、このプロキシは、API 呼び出しで送信される API キーまたは OAuth トークンを検証する必要があります。キーまたはトークンは、デベロッパー アプリを識別します。詳細については、最重要ポイント: 完全な分析データを生成する方法をご覧ください。

上記の条件が満たされない場合、「(not set)」の値が表示されます。分析エンティティ値「(not set)」の意味もご覧ください。

API 呼び出し元のアプリを所有する、Edge 登録した開発者のメール。

このディメンションを取得するには、呼び出し先の API プロキシを含む 1 つ以上の API プロダクトに関連付けられたアプリを開発者が所有している必要があります。また、このプロキシは、API 呼び出しで送信される API キーまたは OAuth トークンを検証する必要があります。キーまたはトークンは、デベロッパー アプリを識別します。詳細については、最重要ポイント: 完全な分析データを生成する方法をご覧ください。

上記の条件が満たされない場合、「(not set)」の値が表示されます。分析エンティティ値「(not set)」の意味もご覧ください。

Edge で生成された一意の開発者 ID。形式は org_name@@@unique_id です。

このディメンションを取得するため、呼び出し先の API プロキシを含む 1 つ以上の API プロダクトに関連付けられたアプリをデベロッパーが所有している必要があります。また、呼び出し先のプロキシは、API 呼び出しで送信される API キーまたは OAuth トークンを検証する必要があります。キーまたはトークンは、デベロッパーを識別します。詳細については、最初にすべきこと: 完全なアナリティクス データを生成する方法をご覧ください。

上記の条件が満たされない場合、「(not set)」の値が表示されます。分析エンティティ値「(not set)」の意味もご覧ください。

エラーが発生した API プロキシ内の名前付きフロー。たとえば、「PreFlow」、「PostFlow」、あるいは作成した条件付きフローの名前などです。

Management API で使用するフルネームは、改行なしの ax_execution_fault_flow_name になることに注意してください。

エラーが発生していない場合は、値「(not set)」が表示されます。

エラーが発生した API プロキシフロー状態の名前。「PROXY_REQ_FLOW」や「TARGET_RESP_FLOW」など。

Management API で使用するフルネームは、改行なしの ax_execution_fault_flow_state になることに注意してください。

エラーをスローして API 呼び出しが失敗する原因となったポリシーの名前。

Management API で使用するフルネームは、改行なしの ax_execution_fault_policy_name になることに注意してください。

ポリシーがエラーをスローしたのにもかかわらずポリシールート属性 continueOnError が true に設定されている場合、API プロキシフローは失敗せず継続し、ポリシーエラーはこのディメンションでカウントされません。

API プロキシ ProxyEndpoint で構成された BasePath。ベースパスに API プロキシ URL のドメインやポート部分は含まれません。たとえば、API プロキシのベース URL が https://apigeedocs-test.apigee.net/releasenotes/ の場合、ベースパスは /releasenotes です。

値は proxy.basepath フロー変数にも格納されます。

API プロキシ ベースパスに追加されたリソースパス。たとえば、API プロキシのベース URL が https://apigeedocs-test.apigee.net/hello/ であり、呼び出しが https://apigeedocs-test.apigee.net/hello/json に対して行われた場合、pathsuffix は /json です。

pathsuffix を使用しない場合、値は空となります。

値は proxy.pathsuffix フロー変数にも格納されます。

呼び出しを行っているデバイスのオペレーティング システムのバージョン。

オペレーティング システムのバージョンを調べる場合に、これを OS ファミリー（ax_ua_os_family）と一緒に 2 番目の「ドリルダウン」ディメンションとして使用すると便利です。

呼び出し元クライアントの IP アドレス。proxy.client.ip フロー変数に格納されます。多くの場合、これは着信呼び出しの X-Forwarded-For アドレスであり、Edge が最後の外部 TCP handshake から受信した IP アドレスです。呼び出し元クライアントやロードバランサである可能性があります。X-Forwarded-For ヘッダーに複数の IP がある場合、これはリストの最後の IP です。

Akamai などのルーティング プロダクトを使用してクライアントの真の IP アドレスを取得する場合、クライアント IP は Edge の HTTP ヘッダー True-Client-IP に渡されます。このディメンションは、これらの真のクライアント IP をそのヘッダーから取得します。

ax_resolved_client_ip ディメンションを介してアクセスした、元のクライアント IP アドレスを調べるため、Edge は ax_true_client_ip ディメンションと x_forwarded_for_ip ディメンションを使用します。

ターゲット サービスへのリソースパス（ドメインを含まない）。クエリ パラメータを除きます。

たとえば、Apigee サンプル ターゲット http://mocktarget.apigee.net には、複数のリソース（挨拶を返す /user など）が含まれます。API プロキシが http://mocktarget.apigee.net/user を呼び出す方法に関係なく、request_path は /user です。

ターゲット サービスへのリソースパス（ドメインを含まない）。クエリ パラメータを含みます。

たとえば、Apigee サンプル ターゲット http://mocktarget.apigee.net には、/user?user={name} リソースや、指定された名前にカスタム挨拶を返すクエリ パラメータなど、複数のリソースが含まれます。API プロキシがいかにして http://mocktarget.apigee.net/user?user=Dude を呼び出すかに関係なく、request_uri は /user?user=Dude です。

ユーザー エージェントまたはソフトウェア エージェントの名前。API 呼び出しを行うために使用します。次に例を示します。

• Chrome から呼び出しを行う Pixel XL: Mozilla/5.0 (Linux; Android 7.1.2; Pixel XL Build/NHG47N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.92 Mobile Safari/537.36
• Chrome から呼び出しを行う iPad: Mozilla/5.0 (iPad; CPU OS 10_2 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/54.0.2840.91 Mobile/14C92 Safari/602.1
• ターミナルからの cURL: curl/7.51.0

ユーザー エージェントのバージョン。

エージェント ファミリーのバージョンを取得する場合に、これをユーザー エージェント ファミリー（ax_ua_agent_family）と一緒に 2 番目の「ドリルダウン」ディメンションとして使用すると便利です。

クエリ パラメータを除く、バックエンド サービスへのリソースパス（ドメインは含まれません）。このリソースパスは、プロキシの <TargetEndpoint> で定義されているものです。

たとえば、API プロキシが次のターゲットを呼び出すとします。

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net/user?user=Dude</URL>
</HTTPTargetConnection>

この例では、target_basepath は /user です。

ターゲットが次のようになっているとします。

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net</URL>
</HTTPTargetConnection>

この場合、target_basepath は null になります。

Trace ツールで、フロー図の最後の AX アイコンを選択すると、target.basepath フロー変数が target_basepath ディメンションにマッピングされます。

ターゲット サービスにより API プロキシに返された HTTP レスポンス ステータス コード。200、404、503 など。

「null」の値は、リクエストがターゲット サービスに到達しないことを意味します。これは、レスポンスが Response Cache ポリシーにより返されたときや、リクエスト処理にエラーがあるときに発生します。

これは、レスポンス ステータス コード（response_status_code）ディメンションとは異なります。

API プロキシの TargetEndpoint で定義されているターゲット サービスの完全な URL。

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net/user?user=Dude</URL>
</HTTPTargetConnection>

この例では、target_url は http://mocktarget.apigee.net/user?user=Dude です。

この URL は、API プロキシ処理中に、target.url フロー変数により上書きされる場合があることも留意してください。

プロキシ チェーンでは、およびスクリプト ターゲット（Node.js）を使用しているときは、呼び出し元プロキシの target_url は null となります。

X-Forwarded-For ヘッダー内の IP アドレスのリスト。

ax_resolved_client_ip ディメンションを介してアクセスした、元のクライアント IP アドレスを調べるため、Edge は ax_true_client_ip ディメンションと x_forwarded_for_ip ディメンションを使用します。

24 時間制に基づいた、API 呼び出しが行われた 2 桁の時間。たとえば、API 呼び出しが午後 10 時と午後 11 時の間の時間に行われた場合、ax_hour_of_day は 22 になります。

時刻値は UTC です。