查看 Apigee Edge 說明文件。
前往
Apigee X說明文件。 資訊
這個主題是 Analytics 指標、維度和篩選器的參考資料。如需更多關於 請參閱 API 數據分析總覽。
這個主題會列出使用者介面中顯示的指標和維度名稱,如有需要 以便用於 API 呼叫
指標
以下是您可以在自訂報表和管理 API 呼叫中擷取的 API 指標。
自訂報表名稱 | 要在 Management API 中使用的名稱 | 函式 | 說明 |
---|---|---|---|
平均每秒交易次數 | tps | 無 |
平均交易次數,代表每秒 API Proxy 要求數。 請注意 這段時間內的交易次數 (每次平均交易次數) 秒中如果數值小於 2,在使用者介面自訂報表中就可能顯示為 0 。 API 語法: |
快取命中 | cache_hit | 總和 |
使用回應快取 (而非 回應。 API 語法: |
L1 快取元素數量 | ax_cache_l1_count | 平均、最小值、最大值 |
傳回指定特定交易中每次交易 L1 (記憶體內) 快取的元素數量
時間範圍。舉例來說,如果您選擇 API 語法: |
政策錯誤 | policy_error | 總和 |
指定時間範圍內的政策錯誤總數。 政策錯誤通常是在設計上發生。例如「Verify API 金鑰」政策擲回 要求中傳遞無效的 API 金鑰,以及尖峰流量防範政策時發生錯誤 如果 API 呼叫數量超過政策所定義的限制,就會發生錯誤。以下內容 這項指標可協助您在 API 中找出潛在問題的位置。例如: 按照 developer_app 維度分組的 policy_error 指標,也許能助您一臂之力 某個應用程式的 API 金鑰或 OAuth 權杖已過期;或者您可能會發現 特定 API Proxy 擲回了大量尖峰流量錯誤,您發現 但 Proxy 的尖峰流量限制不考慮節慶流量增加的情況。 只有在錯誤導致 API Proxy 故障時,數據分析才會記錄政策錯誤。
例如,假設政策的 「錯誤政策名稱」(ax_execution_fault_policy_name) 維度可協助您 依政策名稱分組政策錯誤 目標失敗 (例如 404 或 503) 不算是違反政策。這些 計為 API Proxy 失敗 (is_error)。 API 語法: |
Proxy 錯誤 | is_error | 總和 |
在指定時間範圍內,API Proxy 失敗的總次數。代理 假如政策失敗或執行階段發生錯誤 (例如 404 或 503 錯誤。 您可以透過 Proxy (apiproxy) 維度依 Proxy 將 API Proxy 失敗分組。 API 語法: |
要求處理延遲時間 | request_processing_latency | 平均、最小值、最大值 |
時間長度 (平均值、最小值或最大值),以毫秒為單位。 要求 Edge 處理傳入要求從要求達到上限時起算 Edge 將要求轉送至目標服務時結束。 使用不同的維度,依 API Proxy 檢查要求處理延遲時間 開發人員應用程式、區域等等 API 語法: |
要求大小 | request_size | 總和、平均值、最小值、最大值 |
Edge 接收的要求酬載大小 (以位元組為單位)。 API 語法: |
已執行回應快取 | ax_cache_executed | 總和 |
在指定時間內執行回應快取政策的總次數 。 由於回應快取政策會附加在 API Proxy 中的兩個位置 (在 而在回應中傳回一次),則通常會在 API 呼叫中執行兩次。快取 「get」快取的「put」則分別計為一次執行 但如果
在追蹤記錄工具中:
您可以按一下已執行 API 呼叫中的「回應快取」圖示,查看
API 語法: |
回應處理延遲時間 | response_processing_latency | 平均、最小值、最大值 |
時間長度 (平均值、最小值或最大值),以毫秒為單位。 要求 Edge 處理 API 回應API Proxy 收到執行個體的時間起算時間 Apigee 將回應轉送給原始服務後,就會結束於目標服務的回應 呼叫。 使用不同的維度,即可依 API 檢查回應處理延遲時間 Proxy、區域等 API 語法: |
回應大小 | response_size | 總和、平均值、最小值、最大值 |
傳回給用戶端的回應酬載大小, 位元組。 API 語法: |
目標錯誤 | target_error | 總和 |
目標服務的 5xx 回應總數。這些是目標服務 並非由 Apigee 造成的錯誤 API 語法: |
目標回應時間 | target_response_time | 總和、平均值、最小值、最大值 |
時間長度 (總和、平均值、最小值或最大值), 毫秒:供目標伺服器回應呼叫。這個指標 可讓您瞭解目標伺服器的效能Edge 轉寄要求時起算的時間 並在 Edge 收到回應時結束 請注意,如果 API 呼叫從快取傳回回應 (使用 Response Cache 政策),呼叫一律不會觸及目標服務,也不會成為目標服務之一 會記錄回應時間指標。 API 語法: |
總回應時間 | total_response_time | 總和、平均值、最小值、最大值 |
時間長度 (總和、平均值、最小值或最大值), 毫秒,從 Edge 收到用戶端要求到 Edge 將回應傳回用戶端。時間包括網路負擔 (例如 負載平衡器和路由器執行工作所需的時間) 延遲、回應處理延遲時間和目標回應時間 (如有提供回應) 而非快取)。 使用不同的維度 可讓您依 API Proxy 檢查處理延遲時間 開發人員應用程式、區域等等 API 語法: |
流量 | message_count | 總和 |
指定時間範圍內由 Edge 處理的 API 呼叫總數。 使用維度,以對您來說最有意義的流量方式分類流量。 API 語法: |
尺寸
維度可讓您按有意義的群組查看指標,舉例來說,您可以查看 只要查看每個開發人員應用程式或 API Proxy 的計數,就會大幅提升。
以下是 Apigee 立即可用的維度。此外,您可以建立 自有維度 (如「使用自訂分析分析 API 訊息內容」一文所述)。
自訂報表名稱 | 要在 Management API 中使用的名稱 | 說明 |
---|---|---|
Apigee 實體 | ||
存取權杖 | access_token | 應用程式使用者的 OAuth 存取權杖。 |
API 產品 | api_product |
API 產品名稱 (包含要呼叫的 API Proxy)。為了讓您 這個維度,發出呼叫的開發人員應用程式必須與一或多個 API 建立關聯 ,而且要呼叫的 Proxy 必須檢查 API 。金鑰或權杖已與 API 建立關聯 產品。若需更多資訊,請參閲 首要之務:如何產生完整的數據分析資料。 如果不符合上述條件,畫面會顯示「(not set)」這個值。另請參閱 數據分析實體值「(未設定)」是什麼?是什麼意思? |
快取金鑰 | 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。 在追蹤記錄工具中:
當您選取回應快取政策時,可以在
如要進一步瞭解快取層級,請參閱「快取內部」。 |
用戶端 ID | client_id |
發出 API 呼叫的開發人員應用程式的用戶端金鑰 (API 金鑰) 以 API 金鑰的形式傳送的要求,或包含在 OAuth 權杖中。 如要取得這個維度,您必須將接聽呼叫的 Proxy 設為 取得有效的 API 金鑰或 OAuth 權杖開發人員應用程式會取得 API 金鑰,可用來 當應用程式在 Edge 中註冊時,會產生 OAuth 權杖。若需更多資訊,請參閲 首要之務:如何產生完整的數據分析資料。 如果不符合上述條件,畫面會顯示「(not set)」這個值。另請參閱「Analytics 實體值「(未設定)」是什麼?是什麼意思? |
開發人員應用程式 | developer_app |
向 Edge 註冊的開發人員應用程式會發出 API 呼叫。 如要取得這項維度,應用程式必須與一或多項 API 產品建立關聯 必須包含要呼叫的 API Proxy,而 Proxy 必須檢查 API 金鑰, 與 API 呼叫一併傳送的 OAuth 權杖。金鑰或權杖可用於識別開發人員應用程式。適用對象 如需更多資訊,請參閱首要之務:如何產生完整的數據分析資料。 如果不符合上述條件,畫面會顯示「(not set)」這個值。另請參閱「Analytics 實體值「(未設定)」是什麼?是什麼意思? |
開發人員電子郵件 | developer_email |
已註冊 Edge 的開發人員並在應用程式發出 API 呼叫時收到的電子郵件。 如要取得這個維度,開發人員必須將應用程式與一或多個建立關聯 包含所呼叫 API Proxy 的 API 產品,而 Proxy 必須檢查 與 API 呼叫一併傳送的 API 金鑰或 OAuth 權杖。金鑰或符記可用來識別開發人員 應用程式。詳情請參閱「首要之務:如何產生完整的數據分析資料」一文。 如果不符合上述條件,畫面會顯示「(not set)」這個值。另請參閱「Analytics 實體值「(未設定)」是什麼?是什麼意思? |
開發人員 ID | 開發人員 |
由 Edge 產生的專屬開發人員 ID,格式為 org_name@@@org_name。 如要取得這個維度,開發人員必須將應用程式與一或多個建立關聯 包含要呼叫的 API Proxy 的 API 產品,而 Proxy 必須檢查 與 API 呼叫一起傳送的 API 金鑰或 OAuth 權杖。金鑰或符記可用來識別 開發人員。詳情請參閱「首要之務:如何產生完整的數據分析資料」一文。 如果不符合上述條件,畫面會顯示「(not set)」這個值。另請參閱「Analytics 實體值「(未設定)」是什麼?是什麼意思? |
環境 | 環境 | 部署 API Proxy 的 Edge 環境。例如「test」或 「prod」。 |
發生錯誤的錯誤代碼 | ax_edge_execution_fault_code |
錯誤的錯誤程式碼。例如:
|
發生錯誤的流程名稱 | ax_execution_fault _flow_name |
API Proxy 中引發錯誤的名 flow。例如「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.閘道流程 ID 可用於區分 高 TPS 情境中其他面向,例如機構、環境和時間戳記 所有呼叫都相同。 |
機構 | 機構 | 部署 API Proxy 的 Edge 機構。 |
發生錯誤的政策名稱 | 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 的基準網址為 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 個 可能已部署新的修訂版本此外,一個 API 可能以多個版本的形式部署為 前提是修訂版本有不同的基本路徑 (如在使用者介面部署 Proxy 中所述)。 |
已解析的用戶端 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) 或負載平衡器。如果 Pod 中有多個 IP
X-Forwarded-For 標頭,這是列出的最後一個 IP。 |
裝置類別 | ax_ua_device_category | 發出 API 呼叫的裝置類型,例如「平板電腦」或 「智慧型手機」。 |
OS 系列 | ax_ua_os_family | 撥打電話裝置的作業系統系列,例如「Android」或 「iOS」。 |
作業系統版本 | 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 位址,可透過 |
要求路徑 | 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」的值表示要求從未到達目標服務。這種情況會發生在 回應快取政策或要求失敗時,就會傳回回應。 和資料處理之間 不同於回應狀態碼 (response_status_code) 維度。 |
目標網址 | target_url |
在 API Proxy 的 TargetEndpoint 中定義的目標服務完整網址。 <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net/user?user=Dude</URL> </HTTPTargetConnection> 在這個範例中,target_url 是
在 Proxy 中 鏈結和使用指令碼 target (Node.js),呼叫 Proxy 中的 target_url 為空值。 |
X 轉投給 | x_forwarded_for_ip |
如要判斷原始用戶端 IP 位址,可透過 |
時間 | ||
星期幾 | ax_day_of_week | 發出 API 呼叫的星期幾縮寫 (以三字母表示)。適用對象 例如週一、週二、週三 |
月 | ax_month_of_year | 發出 API 呼叫的月份。例如「03」代表 3 月 |
時段 | ax_hour_of_day |
以 24 小時制計算,也就是發出 API 呼叫的 2 位數小時。例如: 在下午 10 點到 11 點之間進行的 API 呼叫,ax_hour_of_day 為 22。 時間值是以世界標準時間為準。 |
時區 | ax_geo_timezone | 發出 API 呼叫時使用的時區常見名稱,例如 America/New_York 和歐洲/都柏林。 |
週次 | ax_week_of_month | 當月的數字。例如,針對在第 3 天 ax_week_of_month 為 3。 |
位置 | ||
城市 | ax_geo_city | API 呼叫的來源城市。 |
洲別 | ax_geo_continent | 發出 API 呼叫的洲別的雙字母代碼。例如: 北美洲。 |
國家/地區 | ax_geo_country | 發出 API 呼叫時所屬國家/地區的雙字母代碼。例如 US 代表美國。 |
地理區域 | ax_geo_region | 地理區域的連字號代碼,例如 STATE-COUNTRY。例如: 美國華盛頓特區 |
區域 | 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」邏輯,評估各種可能的篩選運算式。篩選器 包含符合至少一項條件的資料。 |