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

未在 Edge UI 中擷取 API 要求

查看 Apigee Edge 說明文件。
前往 Apigee X說明文件。資訊

問題

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

錯誤訊息

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

可能原因

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

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

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

診斷

如要在 Trace 工作階段中擷取 API 要求，API 要求必須由 Edge 的元件訊息處理器處理。有幾個原因可能導致 Trace 交易無法擷取 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 訊息處理者找不到指定的虛擬主機和路徑因此，您可能會看到下列錯誤：

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 的 Trace 工作階段中。

請按照下列步驟判斷問題是否發生：

登入每個訊息處理器，使用以下指令檢查所要求 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
```
如果問題仍未解決，請參閱「Must Gather 診斷資訊」。

Must Gather 診斷資訊

如果按照上述操作說明操作後，問題仍未解決，請收集下列診斷資訊，並與 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