分析の指標、ディメンション、フィルタのリファレンス

このページの内容は ApigeeApigee ハイブリッドに該当します。

Apigee Edge のドキュメントを表示する。

このトピックは、アナリティクスの指標、ディメンション、フィルタのリファレンスです。これらの使用方法については、API Analytics の概要をご覧ください。

このトピックでは、指標およびディメンションが UI に表示されるときの名前と、API 呼び出しで使用されるときの名前を示します。

指標

以下は、カスタム レポートと Apigee API 呼び出しで取得できる API 指標です。

指標 Apigee API で使用される名前 関数 説明
1 秒あたりの平均トランザクション数。 tps なし

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

API 構文: tps

キャッシュ ヒット cache_hit sum

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

API 構文: sum(cache_hit)

L1 キャッシュ要素数 ax_cache_l1_count avg、min、max

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

API 構文: avg(ax_cache_l1_count)

ポリシーエラー policy_error sum

指定した期間におけるポリシーエラーの総数です。

ポリシーエラーは通常、意図的に発生します。たとえば、リクエストで無効な API キーを渡すと VerifyApiKey ポリシーによってエラーがスローされ、SpikeArrest ポリシーで API 呼び出しの数が定義された制限を超えると、エラーがスローされます。そのため、この指標は API の潜在的な問題点を見つけるのに役立ちます。たとえば、policy_error 指標は developer_app ディメンションでグループ化されており、特定のアプリの API キーまたは OAuth トークンが期限切れになっていることを発見するのに役立ちます。または、特定の API プロキシで多数の SpikeArrest ポリシーエラーがスローされているため、プロキシの Spike Arrest 上限が休日のトラフィック増加の原因になっていないことがわかります。

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

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

ターゲットの失敗(404503 など)は、ポリシー障害には計上されません。これらは API プロキシ障害(is_error)として計上されます。

API 構文: sum(policy_error)

プロキシエラー is_error sum

指定した期間に API プロキシが失敗した回数の合計。プロキシ障害は、ポリシーが失敗した場合、またはターゲット サービスからの 404503 などのランタイム 障害が発生したときに発生することがあります。

プロキシ(apiproxy)ディメンションは、プロキシで API プロキシ障害をグループ分けするのに役立ちます。

API 構文: sum(is_error)

request_processing_latency request_processing_latency avg、min、max

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

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

API 構文: max(request_processing_latency)

リクエスト サイズ request_size sum、avg、min、max

Apigee が受信したリクエスト ペイロードのサイズ(バイト単位)。

API 構文: avg(request_size)

Response Cache 実行数 ax_cache_executed sum

一定期間に ResponseCache ポリシーが実行された合計回数。

ResponseCache ポリシーは API プロキシで 2 か所に添付されるため(1 回はリクエストで、もう 1 回はレスポンスで)、通常は 1 回の API 呼び出しで 2 回実行されます。キャッシュ GET とキャッシュ PUT はそれぞれ 1 回の実行として計上されます。

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

Debug ツールで、実行された API 呼び出しの ResponseCache アイコンをクリックし、responsecache.executed フロー変数を表示して、キャッシュ実行の有無を確認することができます(キャッシュ実行があった場合、値は 1)。

API 構文: sum(ax_cache_executed)

response_processing_latency response_processing_latency avg、min、max

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

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

API 構文: min(response_processing_latency)

レスポンス サイズ response_size sum、avg、min、max

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

API 構文: max(response_size)

ターゲット エラー target_error sum

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

API 構文: sum(target_error)

target_response_time target_response_time sum、avg、min、max

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

なお、API 呼び出しが(ResponseCache ポリシーを使用して)キャッシュからレスポンスを返す場合、その呼び出しはターゲット サービスに到達せず、ターゲット レスポンス時間指標が記録されません。

API 構文: avg(target_response_time)

total_response_time total_response_time sum、avg、min、max

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

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

API 構文: avg(total_response_time)

トラフィック message_count sum

指定の期間に Apigee によって処理された API 呼び出しの合計数。

ディメンションを使用すると、トラフィック数を最も意味のある形に分類できます。

API 構文: sum(message_count)

収益化
料金 fees sum、avg、min、max

設定料金、定期的な料金、前払い追加料金の金額。

API 構文: sum(fees)

収益の開発者のシェア x_apigee_mintng_dev_share sum、avg、min、max

トランザクションの収益におけるデベロッパーのシェア。 デベロッパーのシェアは、料金プランで収益分配を有効にした場合にのみ計算されます。

デベロッパーのシェアは、次の式で計算されます。

x_apigee_mintng_dev_share = revShareGrossPrice * (share percentage)

シェアの割合の値は料金プランから取得されます。

API 構文: sum(x_apigee_mintng_dev_share)

収益化の価格 x_apigee_mintng_price sum、avg、min、max

トランザクションの総収益。 トランザクションの収益は、DataCapture ポリシーで取得された revShareGrossPrice 収益化変数の値に設定されます。

API 構文: sum(x_apigee_mintng_price)

API 価格の乗数 x_apigee_mintng_price_multiplier sum、avg、min、max

トランザクションごとの費用の係数(乗数)。トランザクションごとの費用は、料金プランの使用量に基づく料金で指定されます。

API 構文: avg(x_apigee_mintng_price_multiplier)

収益化率 x_apigee_mintng_rate sum、avg、min、max

トランザクションに対して課金される料金。 トランザクションに対して課金される料金は、次の数式を使用して計算されます。

x_apigee_mintng_rate = (consumption-based pricing rate) * perUnitPriceMultiplier value

従量制の料金のレートの値は料金プランから取得され、perUnitPriceMultiplier 値は、変数が DataCapture ポリシーによってキャプチャされる場合にのみ乗算されます。

API 構文: sum(x_apigee_mintng_rate)

ディメンション

ディメンションにより、指標をわかりやすいグループに分けて見ることができます。たとえば、トラフィックの合計数を確認するには、デベロッパー アプリごとや API プロキシごとに表示した方が、かなり効果的になります。

Apigee でそのまま使用できるように用意されているディメンションは、次のとおりです。

ディメンション Apigee API で使用される名前 説明
アクセス トークン access_token アプリ エンドユーザーの OAuth アクセス トークン。
API プロダクト api_product
  • 呼び出された API プロキシを含む API プロダクトの名前。このディメンションを取得するには、呼び出しを行うデベロッパー アプリを API プロキシを含む 1 つ以上の API プロダクトに関連付ける必要があります。呼び出されているプロキシは、API 呼び出しにより送信された API キーまたは OAuth トークンを確認する必要があります。キーまたはトークンは API プロダクトに関連付けられています。詳細については、完全な分析データを生成する方法をご覧ください。

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

  • 料金指標では、設定料金または定期的な料金が適用される料金プランに対応する API プロダクトになります。前払い追加料金の場合、値は空になります。

キャッシュキー ax_cache_key

アクセスされた ResponseCache 値を含むキー。このキーをレスポンス キャッシュに対して構成する方法の詳細については、ResponseCache ポリシーをご覧ください。

Debug ツールで、キャッシュからの読み取りまたはキャッシュへの書き込みを行う ResponseCache ポリシーを選択すると、responsecache.cachekey フロー変数内にこの値を表示できます。

キャッシュ名 ax_cache_name

ResponseCache ポリシーで使用される Key-Value を含むキャッシュの名前。接頭辞 orgName__envName__ が付加されます。たとえば、組織が myorgf の場合、環境は test、キャッシュ名は myCacheax_cache_namefoo__test__myCache です。

Debug ツールで、ResponseCache ポリシーを選択すると、この値を responsecache.cachename フロー変数に表示できます。

キャッシュ ソース ax_cache_source

ResponseCache の取得元であるキャッシュ レベル(L1 メモリ内または L2 データベース)。このディメンションは、レスポンスがキャッシュではなくターゲットから配信されたとき(およびレスポンス キャッシュがターゲット レスポンスで更新されたとき)、またはリクエスト内のキャッシュキーが無効な場合にも CACHE_MISS を表示します。キャッシュキーはサイズが 2 KB に制限されています。

Debug ツールで、ResponseCache ポリシーを選択すると、この値を responsecache.cachesource フロー変数に表示できます。

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

クライアント ID client_id

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

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

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

デベロッパー アプリ developer_app

API 呼び出しを行う Apigee 登録済みのデベロッパー アプリ。

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

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

デベロッパーのメール developer_email
  • API 呼び出しを行うアプリを所有する、Apigee 登録済みのデベロッパーのメール。このフィールドは、AppGroup アプリでは設定されません。

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

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

  • 料金指標では、設定料金、繰り返し料金、または前払い追加料金で課金されるデベロッパーになります。
デベロッパー ID developer

Apigee によって生成される org_name@@@unique_id 形式の 一意のデベロッパー ID。AppGroup の場合、unique_id は AppGroup 名です。

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

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

環境 environment API プロキシがデプロイされる Apigee 環境。たとえば、testprod などです。
エラー時の障害コード ax_edge_execution_fault_code

エラーの障害コード。例: messaging.adaptors.http.flow.GatewayTimeout

エラー時のフロー名 ax_execution_fault
  _flow_name

エラーが発生した API プロキシの名前付きフロー。たとえば、PreFlowPostFlow、作成した条件フローの名前などです。

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

エラーが発生しなかった場合、(not set) の値が表示されます。

フローリソース flow_resource Apigee でのみ使用します。詳しくは、アナリティクスで「リソースフロー」ディメンションを使用する方法をご覧ください。
エラー発生フローの状態 ax_execution_fault
  _flow_state

エラーが発生した API プロキシフローの状態の名前(PROXY_REQ_FLOWTARGET_RESP_FLOW など)。

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

gateway_flow_id gateway_flow_id API 呼び出しが Apigee 内を移動する際、各呼び出しは独自のゲートウェイ フロー ID を取得します。たとえば、rrt329ea-12575-114653952-1 です。ゲートウェイ フロー ID は、組織、環境、タイムスタンプなど他のディメンションが呼び出し間で同一である高 TPS 状況において、指標を見分ける場合に便利です。
組織 organization API プロキシがデプロイされる Apigee 組織。
エラー発生ポリシー名 ax_execution_fault
  _policy_name

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

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

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

プロキシ apiproxy API プロキシのマシン名(表示名ではない)。
プロキシ ベースパス proxy_basepath

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

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

プロキシのデプロイタイプ proxy_deployment_type

デプロイされたプロキシの API プロキシタイプ。プロキシタイプを指定すると、結果はそのプロキシタイプに制限されます。考えられる値は、STANDARDEXTENSIBLE、未設定のいずれかです。

プロキシパス接尾辞 proxy_pathsuffix

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

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

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

プロキシ リビジョン apiproxy_revision API 呼び出しを処理した API プロキシのリビジョン番号。これは、必ずしも API プロキシの最新リビジョンを意味するわけではありません。API プロキシにリビジョンが 10 個ある場合、8 番目のリビジョンがデプロイされることがあります。また、プロキシのデプロイで説明しているように、リビジョンが異なるベースパスを持つ限り、API に複数のリビジョがデプロイされる場合があります。
解決済みクライアント IP ax_resolved_client_ip

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

Akamail などのルーティング プロダクトを使用してクライアントの実際の IP アドレスを取得する場合、クライアントの IP は HTTP ヘッダー True-Client-IP で Apigee に渡され、ax_true_client_ip ディメンションの設定に使用されます。

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

  1. ax_true_client_ip が null でなくローカル IP アドレスを含まない場合は、ax_resolved_client_ipax_true_client_ip に設定します。
  2. それ以外の場合は、ax_resolved_client_ipx_forwarded_for_ip の最初の非ローカル IP アドレスに設定します。
  3. ax_true_client_ipx_forwarded_for_ip の両方にローカル IP のみが含まれる場合は、ax_resolved_client_ipx_forwarded_for_ip の最後のローカル IP に設定します。
  4. ax_true_client_ipx_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) に設定します。
レスポンス ステータス コード response_status_code Apigee からクライアントに転送された HTTP レスポンス ステータス コード(200404503 など)。Apigee では、ターゲットからのレスポンス ステータス コードは、AssignMessage ポリシーRaiseFault ポリシーなどのポリシーで上書きできます。このため、このディメンションは、ターゲット レスポンス っコード(target_response_code)と異なる場合があります。
仮想ホスト virtual_host API 呼び出しが行われた仮想ホストの名前。詳細については、環境と環境グループについてをご覧ください。
インバウンド / クライアント
クライアント IP アドレス client_ip 元のクライアント(proxy_client_ip)やロードバランサなど、ルーターを通過するシステムの IP アドレス。X-Forwarded-For ヘッダーに複数の IP がある場合、これはリストの最後の IP です。
デバイス カテゴリ ax_ua_device_category API 呼び出し元のデバイスの種類(TabletSmartphone など)。
OS ファミリー ax_ua_os_family 呼び出し元のデバイスのオペレーティング システム ファミリー(AndroidiOS など)。
OS のバージョン ax_ua_os_version

呼び出し元のデバイスのオペレーティング システムのバージョン。

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

プロキシ クライアント IP proxy_client_ip

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

参照先クライアント IP ax_true_client_ip

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

ax_resolved_client_ip ディメンションを介してアクセスされた元のクライアント IP アドレスを確認するため、Apigee では ax_true_client_ip ディメンションと x_forwarded_for_ip ディメンションが使用されます。

リクエスト パス request_path

クエリ パラメータを除いた、ターゲット サービスへのリソースパス(ドメインを含まない)。

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

リクエスト URI request_uri

クエリ パラメータを含む、ターゲット サービスへのリソースパス(ドメインを含まない)。

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

リクエスト動詞 request_verb API リクエスト内の HTTP リクエスト動詞(GET、POST、PUT、DELETE など)。
ユーザー エージェント useragent

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 ユーザー エージェントのファミリー(Chrome Mobilecurl など)。
ユーザー エージェント タイプ ax_ua_agent_type ユーザー エージェント タイプ(BrowserMobile BrowserLibrary など)。
ユーザー エージェント バージョン ax_ua_agent_version

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

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

アウトバウンド / ターゲット
対象 target リクエストを処理したターゲット エンドポイント。たとえば、default です。
ターゲット ベースパス target_basepath

クエリ パラメータを除く、ターゲット サービスへのリソースパス(ドメインを含まない)。プロキシの <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 になります。

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

gRPC サービス名 x_apigee_grpc_service_name ターゲット サービスが gRPC の場合にのみ適用されます。gRPC サービス名。gRPC プロキシについては、gRPC API プロキシの作成をご覧ください。
gRPC ステータス x_apigee_grpc_status ターゲット サービスが gRPC の場合にのみ適用されます。gRPC リクエストのステータス。gRPC プロキシについては、gRPC API プロキシの作成をご覧ください。
ターゲット ホスト target_host ターゲット サービスのホスト。たとえば、API プロキシが http://mocktarget.apigee.net/help を呼び出す場合、target_host は mocktarget.apigee.net です。
ターゲット IP アドレス target_ip API プロキシにレスポンスを返すターゲット サービスの IP アドレス。
ターゲット レスポンス コード target_response_code

ターゲット サービスによって API プロキシに返された HTTP レスポンス ステータス コード(200404503 など)。

null は、リクエストがターゲット サービスに到達していないことを意味します。これは、レスポンスが ResponseCache ポリシーによって処理されている場合、またはリクエストの処理中にエラーが発覚した場合に発生します。

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

gRPC RPC 名 x_apigee_grpc_rpc_name ターゲット サービスが gRPC の場合にのみ適用されます。RPC 名。gRPC プロキシについては、gRPC API プロキシの作成をご覧ください。
ターゲット URL target_url

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 フロー変数を使用してオーバーライドされる場合もあるので注意してください。

プロキシ チェーンでは、呼び出し元プロキシの target_url は null となります。

x_forwarded_for_ip x_forwarded_for_ip

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

ax_resolved_client_ip ディメンションを介してアクセスされた元のクライアント IP アドレスを確認するため、Apigee では ax_true_client_ip ディメンションと x_forwarded_for_ip ディメンションが使用されます。

X-Forwarded-For Proto x_forwarded_proto

クライアントがルーターに接続するために使用されるプロトコル。有効な値は、http または https です。

時間
曜日 ax_day_of_week API 呼び出しが行われた曜日の 3 文字の略語。たとえば、Mon、Tue、Wed です。
ax_month_of_year API 呼び出しが行われた月の数値。たとえば、3 月は 03 となります。
時刻 ax_hour_of_day

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

時刻値は UTC です。

タイムゾーン ax_geo_timezone API 呼び出しが行われたタイムゾーンの共通名(America/New_York および Europe/Dublin など)
月の週 ax_week_of_month 月の週を表す数値。たとえば、月の第 3 週に行われた API 呼び出しの場合、ax_week_of_month は 3 です。
ロケーション
City ax_geo_city API 呼び出し元の都市。
大陸 ax_geo_continent API 呼び出し元となった大陸の 2 文字のコード。たとえば、北米の場合は NA です。
ax_geo_country API 呼び出し元となった国の 2 文字のコード。たとえば、米国の場合は US です。
地理的リージョン ax_geo_region 地理的リージョンを指すコード(STATE-COUNTRY など)。たとえば、米国ワシントン州は WA-US となります。
リージョン ax_dn_region API プロキシがデプロイされる Apigee データセンターの名前(us-east-1 など)。
収益化
作成日時 created

現在、Apigee 組織で使用できます。Apigee ハイブリッド組織では使用できません。

アプリ デベロッパーと API プロダクトの料金一覧が追加されたときの UNIX タイムスタンプ。

料金タイプ fees_type 料金のタイプ。設定料金、定期的数料、前払い追加料金のいずれかになります。この値は、Fees 指標を選択した場合にのみ入力されます。
収益の通貨 x_apigee_mintng_currency
  • トランザクション収益の通貨は、DataCapture ポリシーで取得された currency 収益化変数の値に設定されます。この通貨は revShareGrossPrice の通貨に関連付けられています。
  • 料金指標では、設定料金、定期的料金、前払い追加料金の通貨になります。
料金プラン ID x_apigee_mintng_rate_plan_id

現在、Apigee 組織で使用できます。Apigee ハイブリッド組織では使用できません。

アプリ デベロッパー向けの収益化率料金プラン。

トランザクションの成功 x_apigee_mintng_tx_success トランザクションの収益化ステータスは、DataCapture ポリシーで取得された transactionSuccess 収益化変数の値に設定されます。

フィルタ

フィルタを使用すると、結果を特定の特性を持つ指標に限定できます。いくつかのサンプル フィルタを以下に示します。フィルタを定義するときに指標およびディメンションの API スタイル名を使用します。

名前が books または music の API プロキシの指標を返します。

filter=(apiproxy in 'books','music')

名前が m で始まる API プロキシの指標を返します。

filter=(apiproxy like 'm%')

名前が m で始まらない API プロキシの指標を返します。

filter=(apiproxy not like 'm%')

レスポンス ステータス コードが 400599 の API 呼び出しの指標を返します。

filter=(response_status_code ge 400 and response_status_code le 599)

レスポンス ステータス コード 200 とターゲット レスポンス コード 404 を使用して、API 呼び出しの指標を返します。

filter=(response_status_code eq 200 and target_response_code eq 404)

レスポンス ステータス コードが 500 の API 呼び出しの指標を返します。

filter=(response_status_code eq 500)

結果がエラーにならなかった API 呼び出しの指標を返します。

filter=(is_error eq 0)

結果が null レスポンスにならなかった API 呼び出しの指標を返します。

filter=(response_status_code isnot null)

レポート フィルタを構築するために使用できる演算子を以下に示します。

演算子 説明
in リストに含む
notin リストから除外する
is response_status_code is null を使用して、ステータス コードが null のレスポンスをフィルタリングします。
isnot response_status_code isnot null を使用して、ステータス コードが null でないレスポンスをフィルタリングします。
eq 等しい、==
ne 等しくない、!=
gt より大きい、>
lt より小さい、<
ge 以上、>=
le 以下、<=
like 文字列パターンが指定したパターンに一致する場合に true を返します。
not like 文字列パターンが指定したパターンに一致する場合に false を返します。
similar to パターンが指定した文字列に一致するかどうかに応じて true または false を返します。like と似ていますが、SQL 標準の正規表現の定義を使用してパターンを解釈する点が異なります。
not similar to パターンが指定した文字列に一致するかどうかに応じて false または true を返します。SQL 標準の正規表現の定義を使用してパターンを解釈する点を除き、not like と似ています。
and AND ロジックを使用して複数のフィルタ式を含めることができます。フィルタには、すべての条件を満たすデータが含まれます。
or OR ロジックを使用して、さまざまなフィルタ式を評価できます。フィルタには、少なくとも 1 つの条件を満たすデータが含まれます。