本頁面由 Cloud Translation API 翻譯而成。

未在 Edge UI 中擷取 API 要求

您正在查看 Apigee Edge 說明文件。
查看 Apigee X 說明文件。資訊

問題

下圖顯示追蹤工作階段開始時，Edge UI 不會擷取 API 要求：

錯誤訊息

這個問題發生時，Edge UI 不會顯示任何錯誤訊息。

可能原因

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

原因	說明	適用的疑難排解操作說明
訊息處理器未處理的要求	API 要求必須由 Edge 的元件訊息處理器處理，才能擷取追蹤記錄。如果 API 要求無法連線至 Apigee Edge，則會在進入 Edge 的進入點失敗 (例如路由器) 或失敗，導致訊息處理器無法擷取追蹤記錄。	邊緣公開與私人雲端使用者
在分類樹狀結構中找不到 API Proxy	Apigee 訊息處理方使用稱為「分類樹狀結構」的轉送規則定義，根據傳入要求的主機名稱、基本路徑、修訂版本和環境來分派要求。如果相關的 API Proxy 因某些原因而從「分類樹狀結構」中移除，追蹤記錄交易可能不會填入資料。	Edge Private Cloud 使用者

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

診斷方式

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

舉例來說，如果 API 要求無法連線至 Apigee Edge，則會在進入 Edge 的進入點失敗 (例如路由器) 或失敗，否則系統無法擷取追蹤記錄。以下將詳細說明這些情況。

情境 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

診斷方式

如果訊息處理器在「分類樹狀結構」中找不到 API Proxy，則任何傳送至該 Proxy 的 API 要求都不會顯示在 Edge UI 的追蹤工作階段中。

請按照下列步驟判斷是否發生這種情形：

登入每個訊息處理器，使用下列指令查看所請求 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 Proxy 名稱，請按照下方提供的解決方法操作。

解析度

請按照下列步驟解決這個問題。請務必採取所有必要預防措施，以免在處理大量要求時重新啟動訊息處理器時發生服務中斷情形。

請登入「分類樹狀結構」中缺少特定 API Proxy 的每個訊息處理器主機，然後使用下列指令重新啟動訊息處理器：
```
/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