數據分析指標、維度和篩選器參考資料

本頁內容適用於 Apigee 和 Apigee Hybrid。

查看 Apigee Edge 說明文件。

本主題提供數據分析指標、維度和篩選器的參考資料。如要進一步瞭解如何使用這些 API，請參閱 API Analytics 總覽。

本主題會顯示指標和維度在使用者介面中的名稱，以及在 API 呼叫中使用的名稱。

指標

以下是您可以在自訂報表和 Apigee API 呼叫中擷取的 API 指標。

指標 在 Apigee API 中使用的名稱 函式 說明
每秒平均交易次數 tps 無

每秒的平均交易次數，也就是 API 代理要求數。請注意，如果時間範圍內的交易次數相對較少，且小於兩位小數，則使用者介面自訂報表中的每秒平均交易次數可能會顯示為零。

API 語法：tps
快取命中 cache_hit 總和

使用 ResponseCache (而非目標服務的回應) 的成功 API 要求數量。

API 語法：sum(cache_hit)
L1 快取元素數量 ax_cache_l1_count 平均值、最小值、最大值

在特定時間範圍內，每筆交易的 L1 (記憶體內) 快取元素數量。舉例來說，如果您選擇 max 做為一天中的時間範圍，且特定交易在該時間範圍內快取中的元素數量最多為 12 個，則計數為 12。以 avg 為例，如果您查詢的時間範圍內有三筆交易，且快取計數分別為 5、6 和 7，則平均值為 6。如「快取內部結構」一文所述，L1 快取是記憶體內快取，而非 L2 資料庫快取。

API 語法：avg(ax_cache_l1_count)
政策錯誤 policy_error 總和

指定時間範圍內的政策錯誤總數。

政策錯誤通常是設計上的問題。舉例來說，如果要求中傳遞的 API 金鑰無效，VerifyApiKey 政策就會擲回錯誤；如果 API 呼叫次數超過政策中定義的限制，SpikeArrest 政策就會擲回錯誤。因此，這項指標有助於找出 API 中潛在的問題點。舉例來說，您可能會發現特定應用程式的 API 金鑰或 OAuth 權杖已過期；或是發現特定 API 代理伺服器發生大量SpikeArrest政策錯誤，進而發現代理伺服器的尖峰流量限制未考量到節慶流量增加。policy_errordeveloper_app

只有在政策錯誤導致 API 代理程式失敗時，系統才會在 Analytics 中記錄這項錯誤。 舉例來說，如果政策的 continueOnError 屬性設為 true，即使政策失敗，API Proxy 仍會繼續處理要求。在這種情況下，系統不會在 Analytics 中記錄政策錯誤。

「發生錯誤的政策名稱」(ax_execution_fault_policy_name) 維度有助於依政策名稱將政策錯誤分組。

目標失敗 (例如 404 或 503) 不算違反政策。這些要求會計入 API Proxy 失敗次數 (is_error)。

API 語法：sum(policy_error)
Proxy 錯誤 is_error 總和

在指定時間範圍內，API Proxy 失敗的總次數。如果政策失敗或發生執行階段錯誤 (例如目標服務的 404 或 503)，就可能發生 Proxy 失敗。

Proxy (apiproxy) 維度可將 API Proxy 失敗情形依 Proxy 分組。

API 語法：sum(is_error)
要求處理延遲時間 request_processing_latency 平均值、最小值、最大值

Apigee 處理傳入要求所需的時間 (平均、最短或最長)，單位為毫秒。時間從要求送達 Apigee 開始，到 Apigee 將要求轉送至目標服務為止。

您可以運用不同維度，依 API Proxy、開發人員應用程式、區域等檢查要求處理延遲時間。

API 語法：max(request_processing_latency)
要求大小 request_size 總和、平均值、最小值、最大值

Apigee 收到的要求酬載大小 (以位元組為單位)。

API 語法：avg(request_size)
已執行回應快取 ax_cache_executed 總和

在指定時間範圍內執行 ResponseCache 政策的總次數。

由於 ResponseCache 政策會附加至 API Proxy 的兩個位置 (要求和回應各一次)，因此通常會在 API 呼叫中執行兩次。快取 GET 和快取 PUT 各計為一次執行作業。

不過，如果政策中的 <SkipCacheLookup> 元素 (在要求中) 評估結果為 true，回應快取執行次數為 0；如果政策中的 <SkipCachePopulation> 元素 (在回應中) 評估結果為 true，回應快取執行次數也為 0。

在偵錯工具中，您可以點選已執行的 API 呼叫中的 ResponseCache 圖示，查看 responsecache.executed flow 變數，瞭解是否執行了快取 (值為 1)。

API 語法：sum(ax_cache_executed)
回應處理延遲時間 response_processing_latency 平均值、最小值、最大值

Apigee 處理 API 回應所需的時間量 (平均、最小或最大值)，以毫秒為單位。時間從 API Proxy 收到目標服務回應開始，到 Apigee 將回應轉送給原始呼叫端為止。

您可以使用不同維度，依 API Proxy、區域等檢查回應處理延遲時間。

API 語法：min(response_processing_latency)
回應大小 response_size 總和、平均值、最小值、最大值

傳回給用戶端的回應酬載大小 (以位元組為單位)。

API 語法：max(response_size)
目標錯誤 target_error 總和

目標服務的 5xx 回應總數。這些是目標服務錯誤，並非 Apigee 造成。

API 語法：sum(target_error)
目標回應時間 target_response_time 總和、平均值、最小值、最大值

目標伺服器回應呼叫的時間量 (總和、平均值、最小值或最大值)，以毫秒為單位。這項指標可顯示目標伺服器的效能。時間從 Apigee 將要求轉送至目標服務開始，到 Apigee 收到回應為止。

請注意，如果 API 呼叫從快取傳回回應 (例如使用 ResponseCache 政策)，呼叫就不會連線至目標服務，且系統不會記錄任何目標回應時間指標。

API 語法：avg(target_response_time)
總回應時間 total_response_time 總和、平均值、最小值、最大值

從 Apigee 收到用戶端要求，到 Apigee 將回應傳送回用戶端之間的時間量 (總和、平均值、最小值或最大值)，以毫秒為單位。這段時間包括網路額外負荷 (例如負載平衡器和路由器執行工作所需的時間)、要求處理延遲時間、回應處理延遲時間，以及目標回應時間 (如果回應是從目標服務而非快取提供)。

您可以運用不同維度，依 API Proxy、開發人員應用程式、區域等項目檢查處理延遲。

API 語法：avg(total_response_time)
流量 message_count 總和

Apigee 在指定時間範圍內處理的 API 呼叫總數。

使用維度，以對您最有意義的方式將流量數分組。

API 語法：sum(message_count)
營利
費用 fees 總和、平均值、最小值、最大值

代表設定費、定期費用或預付儲值的金額。

API 語法：sum(fees)
開發人員收益比重 x_apigee_mintng_dev_share 總和、平均值、最小值、最大值

開發人員在交易收益中所占的比例。 只有在費率方案中啟用收益分享功能時，Apigee 才會計算開發人員的收益。

開發人員的收益比例如下：

x_apigee_mintng_dev_share = revShareGrossPrice * (share percentage)

系統會從費率方案擷取分潤百分比值。

API 語法：sum(x_apigee_mintng_dev_share)
營利價格 x_apigee_mintng_price 總和、平均值、最小值、最大值

交易的總收益。 交易收益會設為 DataCapture 政策中擷取的 revShareGrossPrice 營利變數值。

API 語法：sum(x_apigee_mintng_price)
API 價格乘數 x_apigee_mintng_price_multiplier 總和、平均值、最小值、最大值

用來乘上每筆交易費用的係數 (乘數)。每筆交易的費用會列在費率方案的「以用量計費」定價中。

API 語法：avg(x_apigee_mintng_price_multiplier)
營利率 x_apigee_mintng_rate 總和、平均值、最小值、最大值

交易的收費費率。 交易的收費費率是透過下列公式計算得出：

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

系統會從費率方案擷取以用量計費的費率值，且只有在 DataCapture 政策擷取變數時，才會乘以 perUnitPriceMultiplier 值。

API 語法：sum(x_apigee_mintng_rate)

維度

維度可讓您查看有意義分組的指標。舉例來說，如果查看每個開發人員應用程式或 API 代理的總流量計數，就能獲得更實用的資訊。

以下是 Apigee 隨附的維度。

維度 在 Apigee API 中使用的名稱 說明
存取權杖 access_token 應用程式使用者的 OAuth 存取權杖。
API 產品 api_product

  • 包含所呼叫 API Proxy 的 API 產品名稱。如要取得這個維度，發出呼叫的開發人員應用程式必須與一或多個含有 API Proxy 的 API 產品建立關聯，且呼叫的 Proxy 必須檢查 API 呼叫傳送的 API 金鑰或 OAuth 權杖。金鑰或權杖與 API 產品相關聯。詳情請參閱「如何產生完整的數據分析資料？」。

    如未符合上述條件，系統會顯示 (not set) 值。另請參閱「 數據分析實體值『(未設定)』代表什麼意義？」。

  • 就費用指標而言，這會是與費率方案對應的 API 產品，應適用設定費或定期費用。如果是預付加值，這個值會是空白。
AppGroup 應用程式名稱 app_group_app 應用程式屬於 AppGroup 時的名稱。如要瞭解 AppGroups，請參閱「使用 AppGroups 管理應用程式擁有權」。
AppGroup Name app_group_name 包含所呼叫應用程式的 AppGroup 名稱 (如適用)。如要瞭解 AppGroups，請參閱「使用 AppGroups 整理應用程式擁有權」。
快取金鑰 ax_cache_key

包含所存取 ResponseCache 值的鍵。如要進一步瞭解如何為回應快取建構金鑰，請參閱回應快取政策。

在偵錯工具中，選取從快取讀取或寫入快取的 ResponseCache 政策時，您可以在responsecache.cachekey 流程變數中看到這個值。
快取名稱 ax_cache_name

包含 ResponseCache 政策所用鍵/值的快取名稱，前面加上 orgName__envName__。舉例來說，如果機構是 myorgf、環境是 test，而快取名稱是 myCache，則 ax_cache_name 為 foo__test__myCache。

在偵錯工具中，選取 ResponseCache 政策時，您可以在 responsecache.cachename flow 變數中查看這個值。
快取來源 ax_cache_source

擷取 ResponseCache 的快取層級 (L1 記憶體內或 L2 資料庫)。如果回應是從目標而非快取傳送 (且回應快取已使用目標回應重新整理)，或是要求中的快取金鑰無效，這個維度也會顯示 CACHE_MISS。快取金鑰大小上限為 2 KB。

在偵錯工具中，選取 ResponseCache 政策時，您可以在 responsecache.cachesource flow 變數中看到這個值。

如要進一步瞭解快取層級，請參閱快取內部結構。
用戶端 ID client_id

提出 API 呼叫的開發人員應用程式的消費者金鑰 (API 金鑰)，無論是做為 API 金鑰傳遞至要求中，還是納入 OAuth 權杖。

如要取得這個維度，接收呼叫的 Proxy 必須設定為檢查有效的 API 金鑰或 OAuth 權杖。在 Apigee 中註冊開發人員應用程式時，系統會為這些應用程式提供 API 金鑰，可用於產生 OAuth 權杖。詳情請參閱「如何產生完整的數據分析資料？」。

如未符合上述條件，系統會顯示 (not set) 值。另請參閱「數據分析實體值『(未設定)』代表什麼意義？」。
開發人員應用程式 developer_app

在 Apigee 註冊的開發人員應用程式發出 API 呼叫。

如要取得這個維度，應用程式必須與一或多個 API 產品建立關聯，這些產品包含要呼叫的 API 代理項目，且代理項目必須檢查 API 呼叫傳送的 API 金鑰或 OAuth 權杖。這個金鑰或權杖會識別開發人員應用程式。詳情請參閱「如何產生完整的數據分析資料？」。

如未符合上述條件，系統會顯示 (not set) 值。另請參閱「數據分析實體值『(未設定)』代表什麼意義？」。
開發人員電子郵件 developer_email

  • 應用程式發出 API 呼叫時，在 Apigee 註冊的開發人員電子郵件地址。這個欄位未針對 AppGroup 應用程式設定。

    如要取得這個維度，開發人員或 AppGroup 必須擁有與一或多個 API 產品相關聯的應用程式，且這些產品包含要呼叫的 API Proxy，而 Proxy 必須檢查 API 呼叫傳送的 API 金鑰或 OAuth 權杖。這個金鑰或權杖會識別開發人員應用程式。詳情請參閱「如何產生完整的數據分析資料？」。

    如未符合上述條件，系統會顯示 (not set) 值。另請參閱「數據分析實體值『(未設定)』代表什麼意義？」。

  • 就費用指標而言，開發人員應支付設定費、定期費用或預付加值金。
開發人員 ID developer

Apigee 產生的專屬開發人員 ID，格式為 org_name@@@unique_id。如果是 AppGroups，則 unique_id 是 AppGroup 名稱。

如要取得這個維度，開發人員必須擁有與一或多個 API 產品相關聯的應用程式，且這些產品包含要呼叫的 API Proxy，而 Proxy 必須檢查 API 呼叫傳送的 API 金鑰或 OAuth 權杖。這個金鑰或權杖是用來識別開發人員。詳情請參閱「如何產生完整的數據分析資料？」。

如未符合上述條件，系統會顯示 (not set) 值。另請參閱「數據分析實體值『(未設定)』代表什麼意義？」。
環境 environment 部署 API Proxy 的 Apigee 環境。例如 test 或 prod。
發生錯誤時的錯誤碼 ax_edge_execution_fault_code

錯誤的錯誤代碼。例如： messaging.adaptors.http.flow.GatewayTimeout
發生錯誤時的流程名稱 ax_execution_fault
  _flow_name

API Proxy 中發生錯誤的具名流程。例如 PreFlow、PostFlow，或是您建立的條件式流程名稱。

請注意，在 Apigee API 中使用的完整名稱為 ax_execution_fault_flow_name，沒有換行符。

如果沒有發生錯誤，您會看到 (not set) 值。
流程資源 flow_resource 僅限 Apigee 使用。如要瞭解詳情，請參閱這篇文章，瞭解如何在 Analytics 中使用「資源流程」維度。
發生錯誤時進入精神時光屋 ax_execution_fault
  _flow_state

引發錯誤的 API Proxy 流程狀態名稱，例如 PROXY_REQ_FLOW 或 TARGET_RESP_FLOW。

請注意，在 Apigee API 中使用的完整名稱是 ax_execution_fault_flow_state，不含換行符。
閘道流程 ID gateway_flow_id API 呼叫在 Apigee 中傳輸時，每個呼叫都會取得專屬的閘道流程 ID。例如： rrt329ea-12575-114653952-1。在 TPS 較高的情況下，如果其他維度 (例如機構、環境和時間戳記) 在不同呼叫之間相同，閘道流程 ID 就有助於區分指標。
機構 organization 部署 API Proxy 的 Apigee 機構。
發生錯誤時的政策名稱 ax_execution_fault
  _policy_name

導致 API 呼叫失敗並擲回錯誤的政策名稱。

請注意，在 Apigee API 中使用的完整名稱是 ax_execution_fault_policy_name，沒有換行符。

如果政策擲回錯誤，但政策根屬性 continueOnError 設為 true，API 代理流程會繼續執行，不會失敗，且政策失敗不會計入這個維度。
Proxy apiproxy API Proxy 的機器名稱 (不是顯示名稱)。
Proxy Base Path proxy_basepath

在 API Proxy ProxyEndpoint 上設定的 BasePath。基本路徑不包含 API 代理網址的網域和連接埠部分。舉例來說，如果 API 代理的基準網址為 https://apigeedocs-test.apigee.net/releasenotes/，則基準路徑為 /releasenotes。

這個值也會儲存在 proxy.basepath flow 變數中。
Proxy 部署類型 proxy_deployment_type

已部署 Proxy 的 API Proxy 類型。指定 Proxy 類型後，結果只會顯示該類型的 Proxy。可能的值為 STANDARD、EXTENSIBLE 或未設定。
Proxy 路徑後置字串 proxy_pathsuffix

新增至 API Proxy 基礎路徑的資源路徑。舉例來說，如果 API 代理的基準網址為 https://apigeedocs-test.apigee.net/hello/，且呼叫是向 https://apigeedocs-test.apigee.net/hello/json 發出，則 pathsuffix 為 /json。

如果未使用 pathsuffix，則值為空白。

這個值也會儲存在 proxy.pathsuffix flow 變數中。
Proxy 修訂版本 apiproxy_revision 處理 API 呼叫的 API Proxy 修訂版本號碼。這不一定代表 API Proxy 的最新修訂版本。如果 API Proxy 有 10 個修訂版本，目前部署的可能是第 8 個修訂版本。此外，只要修訂版本有不同的基本路徑 (如「部署 Proxy」一文所述)，API 即可部署多個修訂版本。
已解析的用戶端 IP ax_resolved_client_ip

來源用戶端 IP 位址。這項資訊是透過預設用戶端 IP 位址解析或已設定的用戶端 IP 解析中設定的演算法衍生而來。

根據預設行為，ax_resolved_client_ip 維度的值是根據 ax_true_client_ip 和 x_forwarded_for_ip 維度的值計算而來。

請注意，使用 Akamai 等路由產品擷取用戶端的真實 IP 位址時，用戶端 IP 會在 HTTP 標頭 True-Client-IP 中傳遞至 Apigee，然後用於設定 ax_true_client_ip 維度。

ax_resolved_client_ip 維度的值計算方式如下：

  1. 如果 ax_true_client_ip 不是空值，且不包含本機 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 皆為空值，請將 ax_resolved_client_ip 設為 (not set)。
  5. 如果 ax_true_client_ip 是本機 IP，且 x_forwarded_for_ip 為空值，請將 ax_resolved_client_ip 設為 (not set)。
回應狀態碼 response_status_code 從 Apigee 轉送至用戶端的 HTTP 回應狀態碼，例如 200、404、503 等。在 Apigee 中，目標的回應狀態碼可透過 AssignMessage 政策和 RaiseFault 政策等政策覆寫，因此這個維度可能與目標回應代碼 (target_response_code) 不同。
虛擬主機 virtual_host API 呼叫的虛擬主機名稱。詳情請參閱「關於環境和環境群組」。
Inbound/Client
用戶端 IP 位址 client_ip 連線至路由器的系統 IP 位址，例如原始用戶端 (proxy_client_ip) 或負載平衡器。如果 X-Forwarded-For 標頭中有多個 IP，這就是列出的最後一個 IP。
裝置類別 ax_ua_device_category 發出 API 呼叫的裝置類型，例如 Tablet 或 Smartphone。
作業系統系列 ax_ua_os_family 發出通話的裝置作業系統系列，例如 Android 或 iOS。
OS 版本 ax_ua_os_version

撥號裝置的作業系統版本。

建議您將這個維度與作業系統系列 (ax_ua_os_family) 搭配使用，做為第二個向下鑽取維度，查看作業系統版本。
Proxy 用戶端 IP proxy_client_ip

呼叫端用戶端的 IP 位址，儲存在 proxy.client.ip 流程變數中。 這通常是傳入呼叫的 X-Forwarded-For 位址，也就是 Apigee 從最後一次外部 TCP 交握收到的 IP 位址。這可能是呼叫端用戶端或負載平衡器。如果 X-Forwarded-For 標頭中有多個 IP，這就是列出的最後一個 IP。
參照用戶端 IP ax_true_client_ip

使用 Akamai 等路由產品擷取用戶端的真實 IP 位址時，用戶端 IP 會在 HTTP 標頭 True-Client-IP 中傳遞至 Apigee。這個維度會從該標頭擷取這些真實用戶端 IP。

如要判斷原始用戶端 IP 位址 (透過 ax_resolved_client_ip 維度存取)，Apigee 會使用 ax_true_client_ip 和 x_forwarded_for_ip 維度。
要求路徑 request_path

目標服務的資源路徑 (不含網域)，不包括查詢參數。

舉例來說，Apigee 範例目標 http://mocktarget.apigee.net 包含多個資源，包括 /user，這個資源會傳回問候語。無論 API Proxy 如何呼叫 http://mocktarget.apigee.net/user，request_path 都是 /user。
要求 URI request_uri

目標服務的資源路徑 (不含網域)，包括查詢參數。

舉例來說，Apigee 範例目標 http://mocktarget.apigee.net 包含多項資源，包括 /user?user={name} 資源和查詢參數，可根據提供的名稱傳回自訂問候語。無論 API Proxy 如何呼叫 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 Mobile 或 curl。
使用者代理程式類型 ax_ua_agent_type 使用者代理程式類型，例如 Browser、Mobile Browser、Library 等。
使用者代理程式版本 ax_ua_agent_version

使用者代理程式版本。

建議您將這個維度做為使用者代理程式系列 (ax_ua_agent_family) 的第二個向下鑽取維度，藉此取得代理程式系列的相關版本。
外送/目標
目標 target 處理要求的目標端點。例如 default。
目標基礎路徑 target_basepath

目標服務的資源路徑 (不含網域)，排除查詢參數，也就是在 Proxy 的 <TargetEndpoint> 中定義的路徑。

舉例來說，假設 API Proxy 呼叫下列目標：

<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 會是空值。

在「Debug tool」中，選取流程圖結尾的 AX 圖示時，target.basepath 流程變數會對應至 target_basepath 維度。
gRPC 服務名稱 x_apigee_grpc_service_name 僅適用於目標服務為 gRPC 的情況。gRPC 服務名稱。如要瞭解 gRPC Proxy，請參閱「建立 gRPC API Proxy」。
gRPC 狀態 x_apigee_grpc_status 僅適用於目標服務為 gRPC 的情況。gRPC 要求狀態。如要瞭解 gRPC Proxy，請參閱「建立 gRPC API Proxy」。
目標主機 target_host 目標服務的主機。舉例來說，如果 API Proxy 呼叫 http://mocktarget.apigee.net/help，則 target_host 為 mocktarget.apigee.net。
目標 IP 位址 target_ip 將回應傳回 API Proxy 的目標服務 IP 位址。
目標回應代碼 target_response_code

目標服務傳回給 API Proxy 的 HTTP 回應狀態碼，例如 200、404、503 等。

如果值為 null，表示要求從未抵達目標服務。如果回應是由 ResponseCache 政策提供，或是要求處理失敗，就會發生這種情況。

這與回應狀態碼 (response_status_code) 維度不同。
gRPC RPC 名稱 x_apigee_grpc_rpc_name 僅適用於目標服務為 gRPC 的情況。RPC 名稱。如要瞭解 gRPC Proxy，請參閱「建立 gRPC API Proxy」。
目標網址 target_url

API Proxy TargetEndpoint 中定義的目標服務完整網址。

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

在本範例中，target_url 為 http://mocktarget.apigee.net/user?user=Dude。

請注意，您也可以在 API Proxy 處理期間，使用 target.url flow 變數覆寫網址。

在Proxy 鏈結中，呼叫 Proxy 中的 target_url 為空值。
X-Forwarded-For IP x_forwarded_for_ip

X-Forwarded-For 標頭中的 IP 位址清單。

如要判斷原始用戶端 IP 位址 (透過 ax_resolved_client_ip 維度存取)，Apigee 會使用 ax_true_client_ip 和 x_forwarded_for_ip 維度。
X-Forwarded-For Proto x_forwarded_proto

用戶端用來連線至路由器的通訊協定。有效值包括 http 或 https。
時間
星期幾 ax_day_of_week 發出 API 呼叫的星期幾，以三個字母縮寫表示。例如：週一、週二、週三。
月 ax_month_of_year API 呼叫發生的月份 (以數字表示)。例如 03 代表三月。
時段 ax_hour_of_day

以 24 小時制為準，API 呼叫發生的時間 (以 2 位數表示)。舉例來說，如果在晚上 10 點到 11 點之間發出 API 呼叫，ax_hour_of_day 會是 22。

時間值以世界標準時間為準。
時區 ax_geo_timezone 發出 API 呼叫的時區通用名稱，例如 America/New_York 和 Europe/Dublin。
月內的第幾週 ax_week_of_month 當月的週數 (數字)。舉例來說，如果 API 呼叫是在某個月的第 3 週發出，則 ax_week_of_month 為 3。
位置
城市 ax_geo_city 發出 API 呼叫的城市。
洲別 ax_geo_continent 發出 API 呼叫的洲別雙字母代碼。例如： NA 代表北美洲。
國家/地區 ax_geo_country 發出 API 呼叫的國家/地區代碼 (由兩個字母組成)。例如：US 代表美國。
地理區域 ax_geo_region 地理區域的連字號代碼，例如 STATE-COUNTRY。例如： WA-US 代表美國華盛頓。
區域 ax_dn_region 部署 API Proxy 的 Apigee 資料中心名稱，例如 us-east-1。
營利
建立時間 created

目前僅適用於 Apigee 機構，不適用於 Apigee Hybrid 機構。

為應用程式開發人員和 API 產品新增費用時間表的 Unix 時間戳記。
費用類型 fees_type 費用類型。可以是設定費、週期性費用或預付加值。只有在選取 Fees 指標時，才會填入這個值。
收益幣別 x_apigee_mintng_currency
  • 交易收益的幣別會設為 DataCapture 政策中擷取的 currency 營利變數值。這個幣別與「revShareGrossPrice」的幣別相關聯。
  • 就費用指標而言，這會是設定費、定期費用或預付加值的貨幣。
房價方案 ID x_apigee_mintng_rate_plan_id

目前僅適用於 Apigee 機構，不適用於 Apigee Hybrid 機構。

應用程式開發人員的營利費率方案。
交易成功 x_apigee_mintng_tx_success 交易的營利狀態會設為 DataCapture 政策中擷取的 transactionSuccess 營利變數值。

篩選器

篩選器可將結果限制為具有特定特徵的指標。以下是一些篩選器範例。定義篩選器時，請使用指標和維度的 API 樣式名稱。

傳回名稱為 books 或 music 的 API Proxy 指標：

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

傳回名稱開頭為 m 的 API Proxy 指標：

filter=(apiproxy like 'm%')

傳回名稱不是以 m 開頭的 API Proxy 指標：

filter=(apiproxy not like 'm%')

傳回回應狀態碼介於 400 和 599 之間的 API 呼叫指標：

filter=(response_status_code ge 400 and response_status_code le 599)

傳回 API 呼叫的指標，這些呼叫的回應狀態碼為 200，目標回應代碼為 404：

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。這與 not like 類似，但會根據 SQL 標準的規則運算式定義解讀模式。
and 可使用 AND 邏輯納入多個篩選運算式。篩選器會納入符合所有條件的資料。
or 您可以使用 OR 邏輯來評估不同的可能篩選運算式。篩選器會納入符合至少一項條件的資料。