您正在查看 Apigee Edge 說明文件。
查看 Apigee X 說明文件。 資訊
本主題是數據分析指標、維度和篩選器的參考資料。如要進一步瞭解如何使用這些功能,請參閱 API 數據分析總覽。
本主題會顯示 UI 中顯示的指標和維度名稱,以及您要在 API 呼叫中使用這些項目的名稱。
指標
以下是您可以在自訂報表和管理 API 呼叫中擷取的 API 指標。
自訂報表名稱 | 要在 Management API 中使用的名稱 | 函式 | 說明 |
---|---|---|---|
平均每秒交易次數 | 文字轉語音 | 無 |
平均交易次數,亦即 API Proxy 要求數。請注意,如果時間範圍內的交易次數相對較低,在 UI 自訂報表中,如果數字少於小數點後兩位數,則 UI 自訂報表中的每秒平均交易次數可能會顯示為零。 API 語法: |
快取命中 | cache_hit | 總和 |
使用回應快取 (而非目標服務的回應) 的成功 API 要求數量。 API 語法: |
L1 快取元素數量 | ax_cache_l1_count | 平均、分鐘、最大值 |
傳回指定時間範圍內每筆交易在 L1 (記憶體內) 快取中的元素數量。舉例來說,如果您選擇在某天期間為 API 語法: |
政策錯誤 | policy_error | 總和 |
指定時間範圍內的政策錯誤總數。 政策錯誤通常都是在設計時發生。舉例來說,如果要求中傳遞無效的 API 金鑰,「Verify API 金鑰」政策擲回錯誤;如果 API 呼叫數量超過政策中定義的限制,則「尖峰流量防範」政策就會擲回錯誤。因此,這項指標有助於找出 API 中潛在的問題位置。舉例來說,依 developer_app 維度分組的 policy_error 指標可能有助於您發現特定應用程式的 API 金鑰或 OAuth 權杖已過期,或是特定 API Proxy 擲回大量「尖峰流量逮捕」錯誤,導致您發現 Proxy 的尖峰流量防範限制並未反映節慶期間流量增加的情形。 只有在錯誤導致 API Proxy 失敗時,政策錯誤才會記錄在 Analytics (分析) 中。舉例來說,如果將政策的 「錯誤政策名稱」(ax_execution_fault_policy_name) 維度非常實用,可用來按政策名稱分組政策錯誤。 目標失敗 (例如 404 或 503) 不會視為政策失敗。這些情況屬於 API Proxy 失敗 (is_error)。 API 語法: |
Proxy 錯誤 | is_error | 總和 |
API Proxy 在指定時間範圍內失敗的總次數。當政策失敗或執行階段發生錯誤 (例如目標服務提供的 404 或 503 錯誤),就有可能發生 Proxy 錯誤。 Proxy (apiproxy) 維度適用於將 Proxy 的 API Proxy 錯誤分組。 API 語法: |
要求處理延遲時間 | request_processing_latency | 平均、分鐘、最大值 |
Edge 處理傳入要求所需的時間 (平均值、下限或上限),以毫秒為單位。要求到達 Edge 時起算,並在 Edge 將要求轉送至目標服務時結束。 您可以利用不同維度,按照 API Proxy、開發人員應用程式、區域等項目檢查要求的處理延遲時間。 API 語法: |
要求大小 | request_size | 總和, 平均, 分鐘, 最大值 |
Edge 接收的要求酬載大小,以 bytes 為單位。 API 語法: |
已執行回應快取 | ax_cache_executed | 總和 |
回應快取政策在指定時間範圍內的執行總次數。 由於回應快取政策附加在 API Proxy 中的兩個位置 (在要求中和回應一次),因此通常會在 API 呼叫中執行兩次。快取「get」和快取「put」每次都會計為一次執行。 不過,如果政策中的 在追蹤記錄工具中,您可以在已執行的 API 呼叫中按一下「回應快取」圖示,並查看 API 語法: |
回應處理延遲時間 | response_processing_latency | 平均、分鐘、最大值 |
以毫秒為單位處理 API 回應所需的時間 (平均值、下限或上限)。這個時間是從 API Proxy 收到目標服務回應開始,並在 Apigee 將回應轉送至原始呼叫端時結束。 透過不同維度,您可以依據 API Proxy、區域等項目檢查回應處理的延遲時間。 API 語法: |
回應大小 | response_size | 總和, 平均, 分鐘, 最大值 |
傳回用戶端的回應酬載大小,以 位元組 為單位。 API 語法: |
目標錯誤 | target_error | 總和 |
目標服務提供的 5xx 回應總數。這些是 Apigee 並非由 Apigee 造成的目標服務錯誤。 API 語法: |
目標回應時間 | target_response_time | 總和, 平均, 分鐘, 最大值 |
目標伺服器回應呼叫的時間長度 (總和、平均值、下限或上限),以毫秒為單位。這項指標可讓您瞭解目標伺服器的效能。是從 Edge 將要求轉送至目標服務的時間開始計算,並在 Edge 收到回應時結束。 請注意,如果 API 呼叫傳回快取的回應 (例如使用「回應快取」政策),則該呼叫絕對不會送達目標服務,也不會記錄目標回應時間指標。 API 語法: |
總回應時間 | total_response_time | 總和, 平均, 分鐘, 最大值 |
從 Edge 收到用戶端要求到 Edge 將回應傳回用戶端的時間,以毫秒為單位 (總和、平均值、最小值或最大值)。所需時間包括網路負擔 (例如負載平衡器和路由器執行工作所需的時間)、要求處理延遲時間、回應處理延遲時間,以及目標回應時間 (如果回應是由目標服務而非快取提供)。 您可以利用不同維度,按照 API Proxy、開發人員應用程式、區域等條件檢查處理延遲時間。 API 語法: |
交通 | message_count | 總和 |
Edge 在指定時間範圍內處理的 API 呼叫總數。 您可以運用維度,以對您來說最有意義的方式將流量計數分組。 API 語法: |
尺寸
維度可讓您按有意義的分組查看指標。舉例來說,查看每個開發人員應用程式或 API Proxy 的總流量時,查看總流量就會變得更加強大。
以下是 Apigee 立即提供的維度。此外,您也可以按照「使用自訂數據分析分析 API 訊息內容」一文的說明,自行建立維度。
自訂報表名稱 | 要在 Management API 中使用的名稱 | 說明 |
---|---|---|
Apigee 實體 | ||
Access Token (存取憑證) | access_token | 應用程式使用者的 OAuth 存取權杖。 |
API 產品 | api_product |
API 產品名稱,其中包含要呼叫的 API Proxy。為了取得這項維度,發出呼叫的開發人員應用程式必須與包含 API Proxy 的一或多項 API 產品建立關聯,且呼叫的 Proxy 必須檢查隨 API 呼叫傳送的 API 金鑰或 OAuth 權杖。金鑰或權杖與 API 產品相關聯。詳情請參閱「第一步:如何產生完整的數據分析資料」。 如果不符合上述條件,系統會顯示「(未設定)」值。另請參閱 「數據分析實體值「(未設定)」代表什麼意思? |
快取金鑰 | ax_cache_key |
包含存取之「回應快取」值的金鑰。如要進一步瞭解系統如何建構金鑰以用於回應快取,請參閱「回應快取政策」。 在追蹤記錄工具中,當您選取讀取或寫入快取的回應快取政策時,可以在 |
快取名稱 | ax_cache_name |
含有回應快取政策所用鍵/值的快取名稱,前置字串為 orgName__envName__。例如,如果機構是「foo」,環境為「test」,快取名稱為「myCache」,則 ax_cache_name 為 foo__test__myCache。 |
快取來源 | ax_cache_source |
擷取回應快取的來源快取層級 (「L1」記憶體內或「L2」資料庫)。這個維度也會顯示「CACHE_MISS」錯誤從目標 (而非快取) 傳送 (且回應快取會根據目標回應重新整理),或要求中的快取金鑰無效。快取金鑰的大小上限為 2 KB。 在追蹤記錄工具中選取回應快取政策時,您可以在 如要進一步瞭解快取層級,請參閱快取內部。 |
Client-ID | client_id |
進行 API 呼叫的開發人員應用程式用戶端金鑰 (API 金鑰),無論是以 API 金鑰的形式在要求中傳遞,還是包含在 OAuth 權杖中。 為了取得這項維度,必須將接收呼叫的 Proxy 設為檢查是否有效的 API 金鑰或 OAuth 權杖。開發人員應用程式在 Edge 中註冊時,就會取得用於產生 OAuth 權杖的 API 金鑰。詳情請參閱「第一步:如何產生完整的數據分析資料」。 如果不符合上述條件,系統會顯示「(未設定)」值。另請參閱「Analytics (分析) 實體值「(未設定)」代表什麼意思? |
開發人員應用程式 | developer_app |
邊緣註冊的開發人員應用程式會發出 API 呼叫。 為了取得這項維度,應用程式必須與包含所呼叫 API Proxy 的一或多項 API 產品建立關聯,且 Proxy 必須檢查透過 API 呼叫傳送的 API 金鑰或 OAuth 權杖。開發人員應用程式可以使用金鑰或權杖。詳情請參閱「第一步:如何產生完整的數據分析資料」。 如果不符合上述條件,系統會顯示「(未設定)」值。另請參閱「Analytics (分析) 實體值「(未設定)」代表什麼意思? |
開發人員電子郵件地址 | developer_email |
已註冊邊緣且應用程式已呼叫 API 的開發人員的電子郵件地址。 為了取得這項維度,開發人員必須將應用程式與一或多項 API 產品建立關聯,其中包含所呼叫的 API Proxy,且 Proxy 必須檢查透過 API 呼叫傳送的 API 金鑰或 OAuth 權杖。該金鑰或權杖可用來識別開發人員應用程式。詳情請參閱「第一步:如何產生完整的數據分析資料」。 如果不符合上述條件,系統會顯示「(未設定)」值。另請參閱「Analytics (分析) 實體值「(未設定)」代表什麼意思? |
開發人員 ID | developer, 開發人員 |
專屬 Edge 產生的開發人員 ID,格式為 org_name@@@unique_id。 為了取得這項維度,開發人員必須將應用程式與一或多個 API 產品建立關聯,而該產品包含所呼叫的 API Proxy,且 Proxy 必須檢查透過 API 呼叫傳送的 API 金鑰或 OAuth 權杖。該金鑰或權杖可用來識別開發人員。詳情請參閱「第一步:如何產生完整的數據分析資料」。 如果不符合上述條件,系統會顯示「(未設定)」值。另請參閱「Analytics (分析) 實體值「(未設定)」代表什麼意思? |
環境 | 環境 | 部署 API Proxy 的 Edge 環境。例如「test」或「prod」。 |
錯誤時的錯誤程式碼 | ax_edge_execution_fault_code |
錯誤的錯誤代碼。例如: |
發生錯誤的流程名稱 | ax_execution_fault _flow_name |
API Proxy 中已命名的流程,且產生錯誤。例如「PreFlow」、「PostFlow」或您建立的條件式流程名稱。 請注意,要用於 Management API 的完整名稱是 ax_execution_fault_flow_name,沒有換行。 如果未發生任何錯誤,您就會看到「(未設定)」值。 |
流程資源 | flow_resource | Apigee 僅供使用。如果您有興趣,請參閱這篇社群貼文。 |
發生錯誤的流程狀態 | ax_execution_fault _flow_state |
引發錯誤的 API Proxy 流程名稱,例如「PROXY_REQ_FLOW」或「TARGET_RESP_FLOW」。 請注意,要用於 Management API 的完整名稱是 ax_execution_fault_flow_state,且沒有換行。 |
閘道流程 ID | gateway_flow_id | API 呼叫在 Edge 之間傳輸時,每項呼叫都會取得專屬的閘道流程 ID。範例:rrt329ea-12575-114653952-1。在高 TPS 情境中,如果機構、環境和時間戳記等其他維度在各項呼叫中都相同,那麼閘道流程 ID 可用於區分指標。 |
機構 | 機構 | 部署 API Proxy 的邊緣機構。 |
錯誤的政策名稱 | ax_execution_fault _policy_name |
擲回錯誤導致 API 呼叫失敗的政策名稱。 請注意,要在 Management API 中使用的全名是 ax_execution_fault_policy_name,沒有換行。 如果政策擲回錯誤,但政策根屬性 |
Proxy | apiproxy | API Proxy 的機器名稱 (而非顯示名稱)。 |
Proxy 基本路徑 | proxy_basepath |
在 API Proxy ProxyEndpoint 上設定的 BasePath。基本路徑不包含 API Proxy 網址的網域和通訊埠部分。舉例來說,如果 API Proxy 的基準網址為 https://apigeedocs-test.apigee.net/releasenotes/,基本路徑為 /releasenotes。 這個值也會儲存在 |
Proxy 路徑後置字串 | proxy_pathsuffix |
已新增至 API Proxy 基本路徑的資源路徑。舉例來說,如果 API Proxy 的基本網址為 如未使用路徑後置字元,這個值會是空白的。 這個值也會儲存在 |
Proxy 修訂版本 | apiproxy_revision | 處理 API 呼叫的 API Proxy 修訂版本編號。這不代表 API Proxy 的最新版本。如果 API Proxy 有 10 個修訂版本,目前可能部署了第 8 個修訂版本。此外,如在 UI 中部署 Proxy 中所述,只要修訂版本擁有不同的基礎路徑,API 可以部署多個修訂版本。 |
已解析的用戶端 IP | ax_resolved_client_ip |
包含原始用戶端 IP 位址。「 請注意,使用 Akamai 等轉送產品擷取用戶端的真正 IP 位址時,系統會將用戶端 IP 傳送到 HTTP 標頭 「
|
回應狀態碼 | response_status_code | 從 Apigee 轉送至用戶端的 HTTP 回應狀態碼,例如 200、404、503 等。在 Edge 中,您可以使用指派訊息和提高錯誤等政策覆寫目標的回應狀態碼,因此這項維度可能會與目標回應代碼 (target_response_code) 不同。 |
虛擬主機 | virtual_host | 進行 API 呼叫時,虛擬主機的名稱。舉例來說,機構預設有兩個虛擬主機:default (http) 和 secure (https)。 |
內送/客戶 | ||
用戶端 IP 位址 | client_ip | 連至路由器的系統 IP 位址,例如原始用戶端 (proxy_client_ip) 或負載平衡器。如果 X-Forwarded-For 標頭中有多個 IP,這是指最後列出的 IP。 |
裝置類別 | ax_ua_device_category | API 呼叫時所屬的裝置類型,例如「Tablet」或「Smartphone」。 |
OS 系列 | ax_ua_os_family | 發出呼叫的裝置作業系統系列,例如「Android」或「iOS」。 |
OS 版本 | ax_ua_os_version |
進行通話的裝置作業系統版本。 方便您做為 OS 系列 (ax_ua_os_family) 的第二個「細查」維度,以便查看作業系統的版本。 |
Proxy 用戶端 IP | proxy_client_ip |
呼叫用戶端的 IP 位址,儲存在 |
參照的用戶端 IP | ax_true_client_ip | 使用 Akamai 等轉送產品擷取用戶端的真實 IP 位址時,用戶端 IP 會透過 HTTP 標頭 如要判斷原始用戶端 IP 位址,Edge 是透過 |
要求路徑 | request_path |
目標服務的資源路徑 (不含網域),不含查詢參數。 舉例來說,Apigee 範例目標 |
請求 URI | request_uri |
目標服務的資源路徑 (不含網域),包括查詢參數。 舉例來說,Apigee 範例目標 |
要求動詞 | request_verb | API 要求中的 HTTP 要求動詞,例如 GET、POST、PUT、DELETE。 |
使用者代理程式 | 使用者代理程式 |
發出 API 呼叫的使用者代理程式或軟體代理程式名稱。 示例:
|
使用者代理程式系列 | ax_ua_agent_family | 使用者代理程式系列,例如「Chrome Mobile」或「cURL」。 |
使用者代理程式類型 | ax_ua_agent_type | 使用者代理程式類型,例如「瀏覽器」、「行動瀏覽器」、「媒體庫」等。 |
使用者代理程式版本 | ax_ua_agent_version |
使用者代理程式的版本。 您可以利用使用者代理程式系列 (ax_ua_agent_family) 做為第二個「細查」維度,取得代理程式系列的版本。 |
外寄/指定目標 | ||
目標基本路徑 | target_basepath |
Proxy 的 舉例來說,假設 API Proxy 呼叫下列目標: <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net/user?user=Dude</URL> </HTTPTargetConnection> 在這個範例中, target_basepath 為 假設指定目標是: <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net</URL> </HTTPTargetConnection> target_basepath 會是空值。 在追蹤工具中,當您選取流程圖表結尾的 AX 圖示時, |
目標主機 | 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」,表示要求從未送達目標服務。如果系統提供回應快取政策提供回應,或是要求處理失敗,就會發生這種情況。 |
目標網址 | target_url |
API Proxy 的 TargetEndpoint 中定義的目標服務完整網址。 <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net/user?user=Dude</URL> </HTTPTargetConnection> 在這個範例中,target_url 為 請注意,您也可以在系統處理 API Proxy 時使用 在 Proxy 鏈結中,使用指令碼目標 (Node.js) 時,呼叫 Proxy 中的 target_url 為空值。 |
已轉寄 X 個 | x_forwarded_for_ip |
如要判斷原始用戶端 IP 位址,Edge 是透過 |
時間 | ||
星期幾 | ax_day_of_week | 發出 API 呼叫的當週三字母縮寫。例如 Mon、Tue、Wd。 |
月份 | ax_month_of_year | API 呼叫發生月份的數字。例如 3 月的「03」。 |
時段 | ax_hour_of_day |
以 24 小時制計算,也就是呼叫 API 的 2 位數小時。例如,在晚上 10 點至 11 點之間進行 API 呼叫,ax_hour_of_day 會是 22。 時間值以世界標準時間為準。 |
Time Zone | ax_geo_timezone | API 呼叫來源時區的常見名稱,例如 America/New_York 和歐洲/都柏林。 |
週次 | ax_week_of_month | 當月數字週。舉例來說,針對當月第 3 週發出的 API 呼叫,ax_week_of_month 為 3。 |
位置 | ||
城市 | ax_geo_city | API 呼叫的來源城市。 |
Continent (大陸) | ax_geo_continent | 發出 API 呼叫的洲別的雙字母代碼。例如 NA 代表北美洲。 |
國家/地區 | ax_geo_country | API 呼叫來源國家/地區的雙字母代碼。例如美國。 |
地理區域 | ax_geo_region | 地理區域 (例如 STATE-COUNTRY) 的連字號代碼。例如代表美國華盛頓州的 WA-US。 |
區域 | ax_dn_region | 部署 API Proxy 的 Apigee 資料中心名稱,例如 us-east-1。 |
營利 | ||
Mint 交易忽略訊息 | x_apigee_mint_tx_ignoreMessage | 這個標記可指定是否要忽略與營利相關的訊息。針對所有營利機構設為 false 。 |
Mint 交易狀態 | x_apigee_mint_tx_status | 營利要求的狀態,例如成功、失敗、無效或無。 |
篩選器
篩選器可讓您篩選出具有特定特徵的指標結果。以下是幾個篩選器範例。定義篩選器時,請使用指標和維度 API 樣式的名稱。
傳回名稱為書籍或音樂的 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)
以下運算子可用來建立報表篩選器。
業者 | 說明 |
---|---|
in |
加入清單 |
notin |
從清單中排除 |
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」邏輯評估不同的可能篩選運算式。篩選器會納入符合至少一個條件的資料。 |