Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

未在 Edge UI 中擷取 API 要求

您目前查看的是 Apigee Edge 說明文件。
前往 Apigee X 說明文件。 info

問題

下圖顯示啟動追蹤工作階段後，Edge UI 未擷取 API 要求：

錯誤訊息

發生這個問題時，Edge 使用者介面不會顯示任何錯誤訊息。

可能原因

下表列出 Edge UI 追蹤功能無法擷取 API 要求的可能原因：

原因	說明	適用於以下裝置的疑難排解說明
訊息處理器未處理的要求	API 要求必須由 Edge 的元件訊息處理器處理，才能擷取追蹤記錄。如果 API 要求無法送達 Apigee Edge，或在 Edge 的進入點 (即路由器) 或在訊息處理器處理前失敗，就無法擷取追蹤記錄。	Edge 公有和私有雲使用者
分類樹狀結構中找不到 API Proxy	Apigee 訊息處理器會使用稱為「分類樹」的轉送規則定義，根據連入要求的主機名稱、基本路徑、修訂版本和環境，調度要求。如果相關 API 代理程式因故從分類樹狀結構中移除，追蹤交易可能不會填入。	Edge Private Cloud 使用者

原因：訊息處理器未處理要求

診斷

如要在追蹤工作階段中擷取 API 要求，API 要求必須由 Edge 的元件「訊息處理器」處理。API 要求可能無法擷取至追蹤交易，原因如下：

舉例來說，如果 API 要求無法送達 Apigee Edge，或在 Edge 的進入點 (即 Router) 或在訊息處理器處理之前失敗，就無法擷取追蹤記錄。下文將詳細說明這些情境。

情境 1：要求無法送達 Apigee Edge

原因

在這種情況下，錯誤可能是由 DNS 解析或網路連線問題所導致。如果發生這種情況，執行這項指令時可能會看到下列錯誤：
```
curl https://hostName:port/apiProxyBasePath/requestPath
```
```
curl: (6) Could not resolve host: hostName
```
解析度

您可以使用下列指令驗證 DNS 設定：
```
dig hostName
```
您可以使用下列指令驗證網路連線：
```
telnet hostName port
```

情境 2：要求在 Apigee Edge 路由器失敗

原因

在這種情況下，錯誤可能是由 TLS/SSL 握手失敗所導致。如果發生這種情況，您可能會看到下列其中一則錯誤訊息：
```
Received fatal alert: handshake_failure
```
```
HTTP/1.1 400 Bad Request
```
您也可能會看到 SSL 憑證錯誤。
解析度

請參閱下列劇本，排解及解決這些問題：

TLS/SSL 握手失敗

400 錯誤的要求 - SSL 憑證錯誤

情境 3：訊息處理器無法處理要求

原因

在這種情況下，Apigee 訊息處理器找不到指定虛擬主機和路徑的 API Proxy。因此，您可能會看到下列其中一項錯誤：

HTTP/1.1 404 Not Found

{
  "fault":{
    "faultstring":"Unable to identify proxy for host: default and url: \/apiProxyBasePath/requestPath",
    "detail":{
      "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
    }
  }
}

解析度

請參閱這份教戰手冊，排解及解決這個問題：「404 無法識別主機的 Proxy」。

原因：分類樹狀結構中找不到 API Proxy

診斷

如果 Message Processor 無法在分類樹狀結構中找到 API Proxy，Edge UI 的追蹤工作階段就不會顯示傳送至該特定 Proxy 的任何 API 要求。

請按照下列步驟判斷是否為這種情況：

登入各個訊息處理器，然後使用下列指令，檢查所要求 API 的特定修訂版本是否已部署在訊息處理器的相關環境中：
```
curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
```
輸出內容範例：

上述指令會輸出已部署修訂版本的清單。舉例來說，如果部署修訂版本 12，您會看到下列輸出內容：
```
[ "12" ]
```
除非遇到間歇性的 HTTP 404 錯誤，否則您應該會看到特定修訂版本已部署。
請閱讀分類樹狀結構，並使用下列指令檢查 API Proxy 名稱是否存在：
```
curl -i http://localhost:8082/v1/classification/tree | grep apiName
```
針對每個訊息處理器重複執行步驟 1 和 2。如果任何訊息處理器的分類樹狀結構中缺少指定的 API 代理名稱，請按照下列解決方法操作。

解決方法

請按照下列步驟解決問題。請務必採取必要防護措施，避免在要求負載量高時重新啟動 Message Processor，以免發生生產中斷情形。

登入分類樹中缺少特定 API Proxy 的每個 Message Processor 主機，然後使用下列指令重新啟動 Message Processor：
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```

重新啟動後，請使用下列指令等待服務啟動：

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready

訊息處理器準備就緒後，請使用下列指令確認 API Proxy 是否可用：
```
curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
```
輸出內容範例：

上述指令會輸出已部署修訂版本的清單。舉例來說，如果部署修訂版本 12，您會看到下列輸出內容：
```
[ "12" ]
```
除非遇到間歇性的 HTTP 404 錯誤，否則您應該會看到特定修訂版本已部署。
讀取分類樹狀結構，並使用下列指令確認 API Proxy 名稱是否存在：
```
curl -i http://localhost:8082/v1/classification/tree | grep apiName
```
如果問題仍未解決，請參閱「必須收集的診斷資訊」。

必須收集診斷資訊

如果按照上述指示操作後問題仍未解決，請收集下列診斷資訊，並提供給 Apigee Edge 支援團隊：

診斷資訊類型	指令
追蹤工作階段指令的輸出內容	curl -v `management-server-host`:8080/v1/runtime/organizations/`orgName`/environments/`envName`/apis/`apiProxyName`/revisions/`revisionNumber`/debugsessions -u `user`
管理伺服器記錄	/opt/apigee/var/log/edge-management-server/logs/system.log
訊息處理器記錄	/opt/apigee/var/log/edge-message-processor/logs/system.log
管理伺服器到訊息處理器的 `telnet`/`netcat` 指令輸出內容	telnet `MessageProcessor_IP` 8082 nc -vz `MessageProcessor_IP` 8082
訊息處理器上 netstat 指令的輸出內容	netstat -an > netstat.txt
在所有訊息處理器上，為特定 API Proxy 部署的輸出清單修訂版本	curl -v http://localhost:8082/v1/runtime/organizations/`orgName`/environments/`envName`/apis/`apiName`/revisions
所有訊息處理器的分類樹狀結構輸出內容	curl -i http://localhost:8082/v1/classification/tree