查看 Apigee Edge 說明文件。
前往
Apigee X說明文件。 資訊
影片
請觀看以下影片，進一步瞭解如何解決 500 個內部伺服器錯誤。
| 影片 | 說明 |
|---|---|
| 簡介 | 提供 500 個內部伺服器錯誤和可能原因的簡介。同時示範 即時 500 內部伺服器錯誤，以及疑難排解和解決錯誤的步驟。 |
| 處理服務呼叫和擷取變數錯誤 | 說明由服務呼叫和擷取變數政策造成的兩項內部伺服器錯誤 以及如何解決及解決這些錯誤 |
| 處理 JavaScript 政策錯誤 | 顯示 JavaScript 政策和步驟造成的 500 內部伺服器錯誤 來排解並解決這個錯誤。 |
| 處理後端伺服器失敗 | 顯示因後端伺服器失敗而造成的 500 個內部伺服器錯誤示例，並顯示相關步驟 來修正錯誤。 |
問題
用戶端應用程式會收到 HTTP 狀態碼 500， 「Internal Server Error」 做為 API 呼叫的回應。500 內部伺服器 發生錯誤，可能是因為在 Edge 內執行任何政策時發生錯誤，也可能是發生錯誤 在目標/後端伺服器上設定
HTTP 狀態碼 500 屬於一般錯誤回應。這表示伺服器 因而無法完成要求這個錯誤通常發生在 在沒有其他適當的錯誤代碼時傳回。
錯誤訊息
您可能會收到以下錯誤訊息：
HTTP/1.1 500 Internal Server Error
在某些情況下，您可能會看見其他錯誤訊息，其中包含更多詳細資料。以下是一些範例 錯誤訊息：
{
"fault":{
"detail":{
"errorcode":"steps.servicecallout.ExecutionFailed"
},
"faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
}
}
可能原因
發生 500 內部伺服器錯誤的原因有很多。在 Edge 中 我們可以根據錯誤發生的位置，將原因分為兩個主要類別：
| 原因 | 詳細資料 | 提供詳細的疑難排解步驟 |
| 邊緣政策的執行錯誤 | 政策 可能會因為某些原因而失敗 | 邊緣私人與公有雲使用者 |
| 後端伺服器發生錯誤 | 後端伺服器可能會因某些原因而失敗。 | 邊緣私人與公有雲使用者 |
邊緣政策執行錯誤
其中「政策」 API Proxy 可能會因某些原因而失敗本節說明如何在發生下列情況時， 執行政策時發生 500 內部伺服器錯誤。
診斷
私人與公有雲使用者的診斷步驟
如果您的錯誤有追蹤 UI 工作階段，則：
- 確認錯誤是因執行政策而造成。詳情請參閱判斷問題來源。
- 如果執行政策時發生錯誤，請繼續操作。如果錯誤是由 後端伺服器，請前往後端伺服器發生錯誤。
- 在追蹤記錄中，選取因 500 內部伺服器錯誤而失敗的 API 要求。
- 檢查要求，並選取失敗的特定政策或指定的流程 「錯誤」呼叫追蹤記錄中未通過的政策。
- 如要進一步瞭解錯誤，請查看「錯誤」「屬性」部分 或「錯誤內容」部分
- 請根據收集到的錯誤詳細資料，試著找出造成錯誤的原因。
僅適用於私有雲使用者的診斷步驟
如果您沒有追蹤 UI 工作階段，請按照下列步驟操作：
- 確認執行政策期間發生錯誤。詳情請參閱判斷問題來源。
- 如果錯誤是由政策執行造成，請繼續操作。如果政策在政策期間發生錯誤 並繼續如果錯誤是由後端伺服器造成，請參閱「後端伺服器中的錯誤」。
- 請使用判斷 問題來源：找出 API Proxy 中的失敗政策，以及 專屬要求訊息 ID
- 查看訊息處理器記錄
(
/opt/apigee/var/log/edge-message-processor/logs/system.log)，並搜尋 不重複的要求訊息 ID。 - 如果有找到專屬的要求訊息 ID，請查看是否能進一步瞭解 失敗的原因
解析度
如果您已經找出政策問題的原因，請嘗試 修正政策並重新部署 Proxy
下列範例說明如何判斷不同廣告產品/服務的具體原因和解決方法 問題類型
如需進一步協助排解 500 內部伺服器錯誤，或您懷疑 洽詢 Edge 中的問題，請與 Apigee 聯絡 支援：
示例 1：後端發生錯誤，因此服務呼叫政策失敗 伺服器
若對後端伺服器發出的呼叫在服務呼叫政策中失敗，並出現任何錯誤，例如 4XX 或 5XX，系統會將其視為 500 Internal Server Error (內部伺服器錯誤)。
- 以下舉例說明後端服務在服務中因 404 錯誤而失敗
摘要政策。使用者會收到下列錯誤訊息：
{ "fault": { "detail": { "errorcode":"steps.servicecallout.ExecutionFailed" },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon failed. Reason: ResponseCode 404 is treated as error" } } } - 下列追蹤記錄 UI 工作階段顯示因「服務」錯誤而導致的 500 個狀態碼
摘要政策：
- 在這個範例中，「錯誤」屬性會列出服務呼叫政策的原因 失敗時，"ResponseCode 404 被視為錯誤"。如果發生這個錯誤， 透過服務呼叫政策中的後端伺服器網址存取的資源無法使用 廣告。
- 檢查後端伺服器上的資源可用性。可能無法使用 或已移至其他位置。
範例 1 解析度
- 檢查後端伺服器上的資源可用性。可能無法使用 或已移至其他位置。
- 修正服務呼叫政策中的後端伺服器網址，指向有效的現有伺服器 資源。
- 如果資源暫時無法使用，請嘗試在 資源可供使用。
示例 2：擷取變數政策失敗
現在來看看另一個範例，其中導致 500 內部伺服器錯誤導致錯誤 ，瞭解如何解決問題及解決問題。
- 由於「擷取」發生錯誤，UI 工作階段中的下列追蹤記錄顯示 500 狀態碼
變數政策：
- 選取失敗的擷取變數政策，然後向下捲動並查看「錯誤」
Content"詳細資訊：
- 「錯誤內容」指出 「"serviceCallout.oamCookieValidationResponse"」變數不適用於 擷取變數政策隨著變數名稱所示，該變數應保留 上述服務呼叫政策的回應。
- 在追蹤記錄中選取服務呼叫政策，您可能會發現 "serviceCallout.oamCookieValidationResponse"尚未設定變數。這個 表示對後端服務的呼叫失敗，導致回應空白 變數。
- 雖然服務呼叫政策失敗，但會在服務後執行政策
呼叫政策繼續發生，因為「continueOnError」已設定服務呼叫政策中的旗標
為 true，如下所示：
<ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation"> <DisplayName>Callout.OamCookieValidation</DisplayName> <Properties /> <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest"> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> </Request> <Response>serviceCallout.oamCookieValidationResponse</Response> <HTTPTargetConnection> <Properties /> <URL>http://{Url}</URL> </HTTPTargetConnection> </ServiceCallout> - 記下這個特定 API 的專屬訊息 ID「"X-Apigee.Message-ID"」
要求，如下所示：
- 選取 [Analytics 記錄的資料]來自要求的階段
- 向下捲動並記下 X-Apigee.Message-ID 的值。
- 查看訊息處理器記錄
(
/opt/apigee/var/log/edge-message-processor/system.log)，然後搜尋 建立的文字 ID系統偵測到的 API 出現以下錯誤訊息 要求：2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563 NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX
以上錯誤表示服務呼叫政策因連線而失敗 連線至後端伺服器時發生逾時錯誤。
- 如要判斷造成連線逾時錯誤的原因，請執行
telnet 指令從訊息處理器傳到後端伺服器。電信業
命令顯示「連線逾時」錯誤，如下所示：
telnet mybackend.domain.com 443 Trying XX.XX.XX.XX... telnet: connect to address XX.XX.XX.XX: Connection timed out
一般而言，會在下列情況中觀察到此錯誤：
- 當後端伺服器未設為允許來自邊緣訊息的流量時 處理器：
- 如果後端伺服器未監聽特定的通訊埠。
在上述示例中，雖然「擷取變數」政策失敗， 是因為 Edge 無法連線至服務呼叫中的後端伺服器 政策。這項失敗的原因在於，後端終端伺服器並未設定為 允許來自邊緣訊息處理器的流量
您擷取的「擷取變數」政策運作方式不同，而且因採用「擷取變數」政策 原因。您可以根據 檢查「擷取變數」政策中的訊息，方法是查看錯誤 資源。
解決方案示例 2
- 請妥善修正「擷取變數」政策中錯誤或失敗的原因。
- 在上方的範例中，解決方案是將網路設定更正為 允許從 Edge Message Processors 傳送到您的後端伺服器的流量。此作業是由 將訊息處理器加入許可清單指定後端伺服器上的 IP 位址例如： 在 Linux 上，您可以使用 iptable 來允許來自 後端伺服器上的訊息處理器 IP 位址。
示例 3：Java 呼叫政策失敗
接著再看另一個例子，其中發生 500 內部伺服器錯誤導致錯誤 ，瞭解如何排解問題。
- 由於 Java 呼叫政策發生錯誤，下列 UI 追蹤記錄會顯示 500 狀態碼：
- 選取名為「Error」的流程，後面加上失敗的 Java 呼叫政策
即可取得錯誤詳細資料，如下圖所示：
- 在這個範例中，「屬性」部分下方的「error」屬性會顯示 發生故障是因為連線至 Oracle 資料庫時使用過期的密碼 。您自己的 Java 呼叫將有不同行為， 在 error 屬性中填入不同的訊息。
- 檢查 Java 呼叫政策程式碼，確認需要的正確設定。
範例 3 解析度
請妥善修正 Java 呼叫程式碼或設定，以免發生執行階段例外狀況。於 上述 Java 呼叫失敗範例，其中只有使用正確的密碼 以便連線至 Oracle 資料庫來解決問題。
後端伺服器發生錯誤
「500 內部伺服器錯誤」也可能來自後端伺服器。這個區段 說明如何排解來自後端伺服器的錯誤。
診斷
所有使用者的診斷步驟
其他後端錯誤的原因可能差異很大。你必須診斷各種情況 以便獨立作業
- 確認錯誤是由後端伺服器造成。詳情請參閱判斷問題來源。
- 如果錯誤是由後端伺服器造成，請繼續操作。如果錯誤是在 執行政策，請前往 Edge 的執行錯誤 政策。
- 視您是否能存取 Trace 工作階段而定，請按照以下步驟操作： 如果 API 失敗，或者後端為 Node.js 伺服器，請執行以下操作：
如果失敗的 API 呼叫沒有 Trace 工作階段，請按照下列步驟操作：
- 如果失敗的要求無法使用 UI 追蹤記錄，請檢查後端伺服器 取得該錯誤的詳情。
- 請盡可能在後端伺服器上啟用偵錯模式，以便取得 錯誤與原因。
如有失敗 API 呼叫的 Trace 工作階段，請按照下列步驟操作：
如果您有追蹤工作階段，請按照下列步驟診斷問題。
- 在追蹤工具中選取因 500 個內部伺服器而失敗的 API 要求 發生錯誤，
- 在失敗時選取「Response from target server」(從目標伺服器收到的回應) 階段。
API 要求，如下圖所示：
- 查看「回應內容」部分瞭解錯誤詳情。
- 在這個範例中，SOAP 信封的「回應內容」會顯示錯誤字串 「未經授權」訊息。最有可能導致這個問題的原因 問題在於，正確憑證 (使用者名稱/密碼、存取權杖等) 未 在後端伺服器上執行所需作業只要將正確的憑證傳遞至 後端伺服器
如果後端是 Node.js 伺服器：
- 如果後端是 Node.js 後端伺服器，請檢查 Node.js 記錄檔
特定 API Proxy 的 Edge UI (公用與私人雲端使用者可以
查看 Node.js 記錄檔。如果您是 Edge Private Cloud 使用者，
也可以查看訊息處理者記錄
(
/opt/apigee/var/log/edge-message-processor/logs/system.log) 瞭解詳情 錯誤資訊。
Edge UI 中的 NodeJS 記錄選項 - API Proxy 的總覽分頁
解析度
- 找出錯誤原因後，請在後端伺服器中修正問題。
- 如果是 Node.js 後端伺服器：
- 檢查自訂程式碼是否擲回錯誤，並盡可能修正問題。
- 如果錯誤不是從您的自訂程式碼擲回，或者如果您需要協助，請聯絡 Apigee 支援：
如需進一步協助排解 500 內部伺服器錯誤，或您懷疑 洽詢 Edge 中的問題，請與 Apigee 聯絡 支援：
判斷問題來源
請按照下列任一程序，判斷系統是否擲回 500 內部伺服器錯誤 政策執行期間，或由後端伺服器執行政策時。
在 UI 中使用 Trace
注意：本節中的步驟可同時由「公開」和 私有雲使用者。
- 如果問題仍未解決，請在 UI 中為受影響的 API 啟用追蹤記錄。
- 擷取追蹤記錄後，請選取將回應代碼顯示為 500。
- 瀏覽失敗 API 要求的所有階段，然後查看哪個階段會傳回
500 內部伺服器錯誤：
- 如果在執行政策時擲回錯誤，請繼續執行邊緣政策的執行錯誤。
- 如果後端伺服器已回應 500 內部伺服器，請繼續處理後端伺服器的錯誤。
使用 API Monitoring
注意：本節所述步驟僅限公有雲使用者執行。
API Monitoring 可讓您快速找出問題領域，診斷錯誤、效能和延遲問題及其來源。 例如開發人員應用程式、API Proxy、後端目標或 API 平台
逐步完成範例情境，示範如何使用 API Monitoring 排解 5xx 問題。
舉例來說，您可以設定快訊，讓系統在狀態碼 500 或 steps.servicecallout.ExecutionFailed 錯誤超過特定門檻時接收通知。
使用 NGINX 存取 記錄
注意：本節步驟適用於 Edge Private Cloud 使用者 。
您也可以參閱 NGINX 存取記錄，判斷是否已擲回 500 狀態碼 政策執行期間，或由後端伺服器執行政策時。這是 如果問題是持續發生，或是問題間歇發生，您也不會發現這個問題， 無法在使用者介面擷取追蹤記錄。請按照下列步驟判斷這項資訊 NGINX 存取記錄：
