Trang này được dịch bởi Cloud Translation API.

500 Lỗi máy chủ nội bộ

Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến tài liệu về Apigee X. thông tin

Video

Hãy xem các video sau để tìm hiểu thêm về cách giải quyết 500 Lỗi máy chủ nội bộ.

Video	Nội dung mô tả
Giới thiệu	Giới thiệu về 500 Lỗi máy chủ nội bộ và nguyên nhân có thể xảy ra. Đồng thời, minh hoạ lỗi Máy chủ nội bộ 500 theo thời gian thực cùng với các bước để khắc phục và giải quyết lỗi.
Xử lý lỗi về Chú thích dịch vụ và Trích xuất biến	Minh hoạ 2 500 Lỗi máy chủ nội bộ do chính sách Chú thích dịch vụ và Trích xuất biến gây ra, đồng thời trình bày cách khắc phục và xử lý những lỗi này.
Xử lý lỗi chính sách JavaScript	Hiển thị Lỗi máy chủ nội bộ 500 do chính sách JavaScript gây ra cùng các bước khắc phục và giải quyết lỗi này.
Xử lý lỗi từ máy chủ phụ trợ	Cho thấy ví dụ về 500 Lỗi máy chủ nội bộ do lỗi máy chủ phụ trợ và cho thấy các bước để khắc phục lỗi.

Triệu chứng

Ứng dụng khách nhận được mã trạng thái HTTP 500 kèm theo thông báo "Nội bộ Server Error" làm phản hồi cho các lệnh gọi API. Lỗi máy chủ nội bộ 500 có thể xảy ra do lỗi trong quá trình thực thi bất kỳ chính sách nào trong Edge hoặc do lỗi trên máy chủ đích/phụ trợ.

Mã trạng thái HTTP 500 là phản hồi lỗi chung. Điều này có nghĩa là máy chủ đã gặp phải một tình trạng không mong muốn khiến máy chủ không hoàn thành được yêu cầu. Máy chủ thường trả về lỗi này khi không có mã lỗi nào khác phù hợp.

Thông báo lỗi

Bạn có thể nhận được thông báo lỗi sau đây:

HTTP/1.1 500 Internal Server Error

Trong một số trường hợp, bạn có thể thấy một thông báo lỗi khác có nhiều thông tin chi tiết hơn. Dưới đây là thông báo lỗi mẫu:

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

Nguyên nhân có thể xảy ra

Lỗi 500 đối với máy chủ nội bộ có thể xảy ra do một số nguyên nhân. Trong Edge, nguyên nhân có thể được phân loại thành hai danh mục chính dựa trên nơi xảy ra lỗi:

Nguyên nhân	Chi tiết	Các bước khắc phục sự cố chi tiết được cung cấp cho
Lỗi thực thi trong chính sách Edge	Một Chính sách trong proxy API có thể không hoạt động vì lý do nào đó.	Người dùng Edge về dịch vụ đám mây riêng tư và công khai
Lỗi trong Máy chủ phụ trợ	Có thể máy chủ phụ trợ gặp sự cố vì lý do nào đó.	Người dùng Edge về dịch vụ đám mây riêng tư và công khai

Lỗi thực thi trong chính sách Edge

Một Chính sách trong proxy API có thể không hoạt động vì lý do nào đó. Phần này giải thích cách khắc phục vấn đề nếu Lỗi máy chủ nội bộ 500 xảy ra trong quá trình thực thi chính sách.

Chẩn đoán

Các bước chẩn đoán dành cho người dùng đám mây riêng tư và công khai

Nếu bạn có phiên theo dõi giao diện người dùng của lỗi, thì:

Xác minh rằng lỗi phát sinh do thực thi chính sách. Hãy xem phần Xác định nguồn gốc sự cố để biết thông tin chi tiết.
Nếu lỗi xảy ra trong quá trình thực thi chính sách, hãy tiếp tục. Nếu lỗi do máy chủ phụ trợ gây ra, hãy xem bài viết Lỗi trong máy chủ phụ trợ.
Chọn yêu cầu API không thành công kèm theo Lỗi máy chủ nội bộ 500 trong dấu vết.
Kiểm tra yêu cầu và chọn một chính sách cụ thể không thực hiện được hoặc quy trình có tên "Lỗi" xuất hiện ngay sau chính sách không thực hiện được trong quá trình theo dõi.
Để biết thêm thông tin chi tiết về lỗi, hãy kiểm tra trường "error" trong phần Thuộc tính hoặc Nội dung lỗi.
Sử dụng thông tin chi tiết bạn đã thu thập được về lỗi, hãy cố gắng xác định nguyên nhân gây ra lỗi.

Các bước chẩn đoán chỉ dành cho người dùng đám mây riêng tư

Nếu bạn không có phiên giao diện người dùng theo dõi, thì:

Xác minh rằng lỗi đã xảy ra trong khi thực thi chính sách. Hãy xem phần Xác định nguồn gốc sự cố để biết thông tin chi tiết.
Nếu lỗi xảy ra do quá trình thực thi chính sách, hãy tiếp tục. Nếu lỗi xảy ra trong quá trình thực thi chính sách, hãy tiếp tục. Nếu lỗi do máy chủ phụ trợ gây ra, hãy xem bài viết Lỗi trong máy chủ phụ trợ.
Sử dụng nhật ký truy cập NGINX như giải thích trong phần Xác định nguồn của sự cố để xác định chính sách không thành công trong proxy API cũng như mã thông báo yêu cầu duy nhất
Kiểm tra nhật ký Trình xử lý thông báo (/opt/apigee/var/log/edge-message-processor/logs/system.log) và tìm mã nhận dạng thông báo yêu cầu duy nhất trong đó.
Nếu bạn tìm thấy mã thông báo yêu cầu duy nhất, hãy xem liệu bạn có thể tìm thêm thông tin về nguyên nhân gây ra lỗi không.

Độ phân giải

Nếu bạn đã xác định được nguyên nhân của vấn đề với chính sách, hãy cố gắng khắc phục vấn đề bằng cách sửa chính sách và triển khai lại proxy.

Các ví dụ sau đây minh hoạ cách xác định nguyên nhân và cách giải quyết cho các loại vấn đề.

Nếu bạn cần hỗ trợ thêm trong việc khắc phục lỗi máy chủ nội bộ 500 hoặc nghi ngờ đó là sự cố trong Edge, hãy liên hệ với Nhóm hỗ trợ API.

Ví dụ 1: Lỗi trong chính sách Chú thích dịch vụ do lỗi trong máy chủ phụ trợ

Nếu lệnh gọi đến máy chủ phụ trợ không thành công trong chính sách Chú thích dịch vụ và có bất kỳ lỗi nào như 4XX hoặc 5XX, thì lỗi đó sẽ được coi là Lỗi máy chủ nội bộ 500.

Dưới đây là ví dụ về trường hợp dịch vụ phụ trợ gặp lỗi 404 trong chính sách Chú thích về dịch vụ. Thông báo lỗi sau đây sẽ được gửi đến người dùng cuối:

{
"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"
          }
     }
}

Phiên giao diện người dùng theo dõi sau đây cho thấy 500 mã trạng thái gây ra do lỗi trong Chính sách chú thích dịch vụ:
Trong ví dụ này, thuộc tính "error" liệt kê lý do không thực hiện được chính sách Chú thích dịch vụ vì "ResponseCode 404 is enabled" (Phản hồi 404 được coi là lỗi). Lỗi này có thể xảy ra nếu tài nguyên đang được truy cập thông qua URL máy chủ phụ trợ trong chính sách Chú thích dịch vụ không có sẵn.
Kiểm tra tính sẵn có của tài nguyên trên máy chủ phụ trợ. Dữ liệu này có thể không được cung cấp tạm thời/vĩnh viễn hoặc có thể đã được chuyển đến một vị trí khác.

Ví dụ 1: Độ phân giải

Kiểm tra tính sẵn có của tài nguyên trên máy chủ phụ trợ. Dữ liệu này có thể không được cung cấp tạm thời/vĩnh viễn hoặc có thể đã được chuyển đến một vị trí khác.
Hãy chỉnh sửa URL của máy chủ phụ trợ trong chính sách về Chú thích dịch vụ để trỏ đến một tài nguyên hợp lệ và hiện có.
Nếu tài nguyên chỉ tạm thời không sử dụng được, hãy thử gửi yêu cầu API khi đã có tài nguyên.

Ví dụ 2: Lỗi trong chính sách Trích xuất biến

Bây giờ, hãy xem một ví dụ khác, trong đó lỗi 500 Lỗi máy chủ nội bộ xảy ra do lỗi trong chính sách Trích xuất biến và xem cách khắc phục cũng như giải quyết vấn đề đó.

Dấu vết sau đây trong phiên giao diện người dùng cho thấy mã trạng thái 500 do lỗi trong chính sách Trích xuất biến:
Chọn chính sách Trích xuất biến không thành công, di chuyển xuống và xem mục "Nội dung lỗi" để biết thêm thông tin chi tiết:
Thông báo Nội dung lỗi cho biết rằng biến "service callout.oamCookieValidationResponse" không có trong chính sách Trích xuất biến. Đúng như tên gọi của biến, biến này phải chứa nội dung phản hồi của chính sách Chú thích dịch vụ trước đó.
Chọn chính sách về Chú thích dịch vụ trong dấu vết và bạn có thể thấy rằng biến "serviceCallout.oamCookieValidationResponse" chưa được đặt. Điều này cho biết rằng lệnh gọi đến dịch vụ phụ trợ không thành công, dẫn đến một biến phản hồi trống.

Mặc dù chính sách Chú thích dịch vụ không thành công, nhưng việc thực thi các chính sách sau khi chính sách Chú thích dịch vụ vẫn tiếp tục vì cờ "continueOnError" trong chính sách Chú thích dịch vụ được đặt thành true, như minh hoạ dưới đây:

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

Hãy lưu ý mã thông báo duy nhất "X-Apigee.Message-ID" cho yêu cầu API cụ thể này từ dấu vết, như sau:
1. Chọn giai đoạn "Dữ liệu phân tích được ghi lại" trong yêu cầu.
2. Di chuyển xuống rồi ghi lại giá trị của X-Apigee.Message-ID.
Lưu ý: Chỉ người dùng Edge Private Cloud mới có thể thực hiện các bước sau.
Xem nhật ký Trình xử lý thông báo (/opt/apigee/var/log/edge-message-processor/system.log) và tìm mã nhận dạng thông báo duy nhất được ghi chú ở bước 6. Chúng tôi nhận thấy thông báo lỗi sau đây đối với yêu cầu API cụ thể:
```
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
```
Lỗi ở trên cho biết rằng chính sách Chú thích dịch vụ không thành công do lỗi hết thời gian kết nối khi kết nối với máy chủ phụ trợ.
Để xác định nguyên nhân gây ra lỗi hết thời gian kết nối, hãy thực thi lệnh telnet đến máy chủ phụ trợ qua(các) Trình xử lý thông báo. Lệnh telnet đã đưa ra lỗi "Kết nối đã hết thời gian chờ" như sau:
```
telnet mybackend.domain.com 443
Trying XX.XX.XX.XX...
telnet: connect to address XX.XX.XX.XX: Connection timed out
```
Thông thường, lỗi này được quan sát thấy trong các trường hợp sau:
- Khi máy chủ phụ trợ không được định cấu hình để cho phép lưu lượng truy cập từ Edge Message Processors (Bộ xử lý thông báo cạnh).
- Nếu máy chủ phụ trợ không nghe trên cổng cụ thể.
Trong ví dụ minh hoạ ở trên, mặc dù chính sách Trích xuất biến không thành công, nhưng nguyên nhân thực tế là Edge không kết nối được với máy chủ phụ trợ trong chính sách Chú thích dịch vụ. Nguyên nhân gây ra lỗi này là do máy chủ cuối phụ trợ không được định cấu hình để cho phép lưu lượng truy cập từ Edge Message Processors (Bộ xử lý thông báo Edge).

Chính sách Trích xuất biến của riêng bạn sẽ hoạt động theo cách khác và có thể không hoạt động vì một lý do khác. Bạn có thể khắc phục sự cố một cách phù hợp tuỳ thuộc vào nguyên nhân gây ra lỗi của chính sách Trích xuất biến bằng cách kiểm tra thông báo trong thuộc tính error.

Ví dụ 2: Độ phân giải

Khắc phục nguyên nhân gây ra lỗi hoặc không thực hiện được trong chính sách Trích xuất biến một cách phù hợp.
Trong ví dụ minh hoạ trên, giải pháp là chỉnh sửa cấu hình mạng để cho phép lưu lượng truy cập từ Edge Message Processors đến máy chủ phụ trợ của bạn. Bạn có thể thực hiện việc này bằng cách đưa địa chỉ IP của Bộ xử lý thông báo vào danh sách cho phép trên máy chủ phụ trợ cụ thể. Ví dụ: trên Linux, bạn có thể sử dụng iptable để cho phép lưu lượng truy cập từ các địa chỉ IP của Trình xử lý thông báo trên máy chủ phụ trợ.

Ví dụ 3: Lỗi trong chính sách Chú thích Java

Bây giờ, hãy xem một ví dụ khác (ví dụ 500 Lỗi máy chủ nội bộ gây ra do lỗi trong chính sách Chú thích Java) và xem cách khắc phục cũng như giải quyết vấn đề đó.

Dấu vết giao diện người dùng sau đây cho thấy mã trạng thái 500 do lỗi trong Chính sách chú thích Java:
Chọn Luồng có tên "Error", theo sau là Chính sách chú thích Java không thành công để xem thông tin chi tiết về lỗi như trong hình dưới đây:
Trong ví dụ này, thuộc tính "error" trong phần Thuộc tính cho biết lỗi là do sử dụng mật khẩu đã hết hạn trong khi kết nối với Cơ sở dữ liệu Oracle từ trong chính sách JavaChú thích. Chú thích Java của riêng bạn sẽ hoạt động khác và sẽ điền sẵn một thông báo khác trong thuộc tính error.
Kiểm tra mã chính sách Chú thích Java và xác nhận cấu hình chính xác cần sử dụng.

Ví dụ 3: Giải pháp

Hãy sửa mã chú thích Java hoặc cấu hình phù hợp để tránh trường hợp ngoại lệ đối với thời gian chạy. Trong ví dụ minh hoạ về lỗi chú thích Java ở trên, bạn cần dùng đúng mật khẩu để kết nối với cơ sở dữ liệu Oracle để giải quyết vấn đề này.

Lỗi trong máy chủ phụ trợ

Lỗi máy chủ nội bộ 500 cũng có thể bắt nguồn từ máy chủ phụ trợ. Phần này giải thích cách khắc phục vấn đề nếu lỗi đến từ máy chủ phụ trợ.

Chẩn đoán

Các bước chẩn đoán cho tất cả người dùng

Nguyên nhân gây ra các lỗi phụ trợ khác có thể rất khác nhau. Bạn sẽ cần chẩn đoán từng trường hợp một cách độc lập.

Xác minh rằng lỗi do máy chủ phụ trợ gây ra. Hãy xem phần Xác định nguồn gốc sự cố để biết thông tin chi tiết.
Nếu lỗi do máy chủ phụ trợ gây ra, hãy tiếp tục. Nếu lỗi xảy ra trong quá trình thực thi chính sách, hãy chuyển đến phần Lỗi thực thi trong chính sách Edge.
Hãy làm theo các bước bên dưới, tuỳ thuộc vào việc bạn có quyền truy cập vào phiên Theo dõi cho API không thành công hay không, hoặc nếu phần phụ trợ có phải là máy chủ Node.js hay không:

Nếu bạn không có phiên Theo dõi cho lệnh gọi API không thành công:

Nếu không có dấu vết giao diện người dùng đối với yêu cầu không thành công, hãy kiểm tra nhật ký máy chủ phụ trợ để biết thông tin chi tiết về lỗi.
Nếu có thể, hãy bật chế độ gỡ lỗi trên máy chủ phụ trợ để biết thêm thông tin chi tiết về lỗi và nguyên nhân.

Nếu bạn có phiên Theo dõi cho lệnh gọi API không thành công:

Nếu bạn có một phiên Theo dõi, các bước sau đây sẽ giúp bạn chẩn đoán vấn đề.

Trong công cụ Theo dõi, hãy chọn yêu cầu API không thành công kèm theo Lỗi máy chủ nội bộ 500.
Chọn giai đoạn "Phản hồi nhận được từ máy chủ mục tiêu" từ yêu cầu API không thành công như trong hình dưới đây:
Xem phần "Nội dung phản hồi" để biết thông tin chi tiết về lỗi.
Trong ví dụ này, Nội dung phản hồi là Phong bì SOAP cho thấy chuỗi lỗi dưới dạng thông báo "Không được uỷ quyền". Nguyên nhân có khả năng cao nhất của vấn đề này là do người dùng không chuyển thông tin đăng nhập phù hợp (tên người dùng/mật khẩu, mã truy cập, v.v.) đến máy chủ phụ trợ. Bạn có thể khắc phục vấn đề này bằng cách chuyển thông tin xác thực chính xác đến máy chủ phụ trợ.

Nếu phần phụ trợ là máy chủ Node.js:

Nếu phần phụ trợ là Máy chủ phụ trợ Node.js, thì hãy kiểm tra nhật ký Node.js cho Proxy API cụ thể trong Giao diện người dùng Edge (cả người dùng Đám mây công khai và Đám mây riêng tư đều có thể kiểm tra nhật ký Node.js). Nếu là người dùng Edge Private Cloud, bạn cũng có thể kiểm tra nhật ký Trình xử lý thư (/opt/apigee/var/log/edge-message-processor/logs/system.log) của mình để biết thêm thông tin chi tiết về lỗi.

Tuỳ chọn Nhật ký NodeJS trong giao diện người dùng Edge – Thẻ Tổng quan về Proxy API

Độ phân giải

Sau khi đã xác định được nguyên nhân lỗi, hãy khắc phục vấn đề trong máy chủ phụ trợ của bạn.
Nếu đó là máy chủ phụ trợ Node.js:
1. Kiểm tra xem lỗi có được tạo ra từ mã tuỳ chỉnh hay không và khắc phục vấn đề (nếu có thể).
2. Nếu lỗi không được gửi từ mã tuỳ chỉnh của bạn hoặc nếu bạn cần hỗ trợ, hãy liên hệ với Nhóm hỗ trợ API.

Nếu bạn cần hỗ trợ thêm trong việc khắc phục lỗi máy chủ nội bộ 500 hoặc nghi ngờ đó là sự cố trong Edge, hãy liên hệ với Nhóm hỗ trợ API.

Xác định nguồn gốc vấn đề

Hãy sử dụng một trong các quy trình sau để xác định xem Lỗi máy chủ nội bộ 500 bị gửi trong quá trình thực thi chính sách trong proxy API hay do máy chủ phụ trợ gửi.

Sử dụng Dấu vết trong giao diện người dùng

Lưu ý: Cả người dùng đám mây công khai và riêng tư đều có thể thực hiện các bước trong phần này.

Nếu vấn đề vẫn tiếp diễn, hãy bật tính năng theo dõi trong giao diện người dùng cho API bị ảnh hưởng.
Sau khi bạn ghi lại dấu vết, hãy chọn yêu cầu API hiển thị mã phản hồi là 500.
Xem qua tất cả các giai đoạn của yêu cầu API không thành công và kiểm tra giai đoạn nào trả về Lỗi máy chủ nội bộ 500:
1. Nếu xảy ra lỗi trong khi thực thi một chính sách, hãy chuyển đến phần Lỗi thực thi trong chính sách Edge.
2. Nếu máy chủ phụ trợ đã phản hồi bằng mã 500 Internal Server (Máy chủ nội bộ), hãy chuyển đến phần Error in the Backend Server (Lỗi trong máy chủ phụ trợ).

Sử dụng tính năng Giám sát API

Lưu ý: Chỉ người dùng Cloud công khai mới có thể thực hiện các bước trong phần này.

Giám sát API giúp bạn nhanh chóng tách biệt các khu vực có vấn đề để chẩn đoán lỗi, các vấn đề về hiệu suất và độ trễ cũng như các vấn đề liên quan đến nguồn gây ra vấn đề, chẳng hạn như các ứng dụng dành cho nhà phát triển, proxy API, mục tiêu phụ trợ hoặc nền tảng API.

Xem tình huống mẫu minh hoạ cách khắc phục sự cố 5xx xảy ra với API bằng tính năng Giám sát API. Ví dụ: có thể bạn muốn thiết lập cảnh báo để nhận thông báo khi số lượng 500 mã trạng thái hoặc steps.servicecallout.ExecutionFailed lỗi vượt quá một ngưỡng cụ thể.

Sử dụng nhật ký truy cập NGINX

Lưu ý: Các bước trong phần này chỉ dành cho người dùng Edge Private Cloud.

Bạn cũng có thể tham khảo nhật ký Truy cập NGINX để xác định xem mã trạng thái 500 có được gửi trong quá trình thực thi chính sách trong proxy API hay qua máy chủ phụ trợ hay không. Điều này đặc biệt hữu ích nếu vấn đề này đã xảy ra trước đây hoặc nếu vấn đề xảy ra liên tục và bạn không thể ghi lại dấu vết trong giao diện người dùng. Hãy làm theo các bước sau để xác định thông tin này từ nhật ký truy cập NGINX:

Kiểm tra nhật ký truy cập NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log ).
Tìm kiếm xem có bất kỳ Lỗi 500 nào cho proxy API cụ thể trong khoảng thời gian cụ thể hay không.
Nếu có bất kỳ Lỗi 500 nào, hãy kiểm tra xem lỗi đó là lỗi chính sách hay lỗi máy chủ mục tiêu, theo minh hoạ dưới đây:
Mục nhập mẫu hiển thị Lỗi chính sách

Mục nhập mẫu hiển thị Lỗi máy chủ mục tiêu
Sau khi bạn xác định được đó là lỗi chính sách hay lỗi máy chủ mục tiêu, hãy làm như sau:
1. Tiến hành Lỗi thực thi trong chính sách Edge nếu đó là lỗi chính sách.
2. Tiếp tục với Lỗi trong máy chủ phụ trợ nếu đó là lỗi máy chủ mục tiêu.