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

500 Lỗi máy chủ nội bộ – Đã bật tính năng phát trực tuyến

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

Triệu chứng

Ứng dụng sẽ nhận được mã trạng thái phản hồi HTTP 500 kèm theo thông báo Internal Server Error (Lỗi máy chủ nội bộ) cho các lệnh gọi API.

Thông báo lỗi

Các ứng dụng khách có thể nhận được phản hồi lỗi như sau:

HTTP/1.1 500 Internal Server Error

Theo sau có thể là một thông báo lỗi như sau:

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

Các nguyên nhân có thể

Lỗi máy chủ nội bộ 500 có thể xảy ra do một số nguyên nhân khác nhau. Cẩm nang này tập trung vào Lỗi máy chủ nội bộ 500 gây ra do truy cập vào tải trọng yêu cầu/phản hồi khi tính năng phát trực tuyến đang bật.

Nguyên nhân	Mô tả	Người có thể thực hiện các bước khắc phục sự cố
Truy cập vào trọng tải khi bật tính năng truyền trực tuyến	Đã xảy ra lỗi vì tải trọng yêu cầu/phản hồi được truy cập khi tính năng truyền trực tuyến đang bật.	Người dùng Edge riêng và công khai trên đám mây

Nguyên nhân: Truy cập vào trọng tải khi bật tính năng Phát trực tiếp

Chẩn đoán

Quy trình số 1: Sử dụng dấu vết

Bật tính năng phiên theo dõi và thực hiện lệnh gọi API để tái hiện vấn đề – Lỗi máy chủ nội bộ 500.
Chọn một trong các yêu cầu không thành công rồi kiểm tra dấu vết.
Di chuyển qua các giai đoạn trong quá trình theo dõi và xác định vị trí xảy ra lỗi.
Lỗi này có thể đã xảy ra khi một chính sách đang phân tích cú pháp tải trọng yêu cầu/phản hồi.
Dưới đây là ảnh chụp màn hình theo dõi mẫu cho thấy chính sách JSONBảo vệ JSONThreatProtection không thành công với lỗi JSONThreatProtection :

Ghi lại những thông tin sau từ kết quả theo dõi, như trong ảnh chụp màn hình ở trên:

Chính sách về hành vi không thành công: Bảo vệ sự đe doạ bằng JSON

Quy trình: Yêu cầu proxy
Kiểm tra định nghĩa về chính sách không đạt và kiểm tra tải trọng đang được phân tích cú pháp.
Trong tình huống ví dụ này, hãy kiểm tra chính sách JSON AneProtection có tên là JSON-Bảo vệ- sự bảo vệ không thành công và kiểm tra phần tử <Source>.
```
<JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
   <DisplayName>JSON Threat Protection</DisplayName>
   <ArrayElementCount>20</ArrayElementCount>
   <ContainerDepth>10</ContainerDepth>
   <ObjectEntryCount>15</ObjectEntryCount>
   <ObjectEntryNameLength>50</ObjectEntryNameLength>
   <Source>request</Source>
   <StringValueLength>1000</StringValueLength>
</JSONThreatProtection>
```
Xin lưu ý rằng phần tử <Source> trỏ đến request.Điều này có nghĩa là đã xảy ra lỗi khi phân tích cú pháp tải trọng yêu cầu.
Xác định loại tải trọng đang được phân tích cú pháp bằng cách kiểm tra yêu cầu API.

Bạn có thể kiểm tra nội dung của tải trọng yêu cầu và tiêu đề Content-Type trong yêu cầu API. Trong ví dụ sau về lệnh curl, trọng tải JSON được sử dụng.

curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

Bạn cũng có thể kiểm tra chính sách có lỗi và xác định loại tải trọng được phân tích cú pháp. Trong trường hợp ví dụ trên, chính sách JSON-Bảo vệ khỏi mối đe doạ không hoạt động. Điều này cho biết rằng tải trọng phải ở định dạng JSON.

Xác thực xem tải trọng có đúng định dạng hay không. Nếu tải trọng không hợp lệ, bạn có thể gặp lỗi này.

Lưu ý: Nếu tải trọng lớn, bạn có thể sử dụng bất kỳ trình định dạng trực tuyến nào để xác thực định dạng tải trọng.
Nếu tải trọng hợp lệ, nhưng bạn vẫn gặp lỗi như liệt kê trong phần Thông báo lỗi, thì nguyên nhân gây ra những lỗi này là do tải trọng đang được truy cập khi bạn bật tính năng truyền trực tuyến.

Tuỳ thuộc vào tải trọng được chính sách phân tích cú pháp (như xác định ở bước 6), hãy kiểm tra nội dung tải trọng trong Công cụ theo dõi trong giai đoạn thích hợp.

Trong trường hợp ví dụ, tải trọng yêu cầu đang được phân tích cú pháp, vì vậy, hãy kiểm tra giai đoạn "Yêu cầu đã nhận từ ứng dụng" trong dấu vết và kiểm tra phần Yêu cầu nội dung.

Nếu Nội dung yêu cầu được phát hiện bị trống như trong ảnh chụp màn hình ở trên, mặc dù bạn đã gửi một tải trọng hợp lệ, thì điều đó cho thấy rằng nguyên nhân có thể của vấn đề này là do tính năng truyền phát yêu cầu đã được bật.

Nguyên nhân là do khi bạn bật tính năng truyền trực tuyến, tải trọng yêu cầu sẽ không xuất hiện trong dấu vết.

Tương tự, nếu tải trọng phản hồi được phân tích cú pháp khi lỗi xảy ra, hãy kiểm tra nội dung phản hồi trong giai đoạn "Phản hồi nhận được từ máy chủ mục tiêu".
Tiếp theo, kiểm tra định nghĩa của Proxy và Điểm cuối mục tiêu tuỳ thuộc vào vị trí mà chính sách không đạt được sử dụng trong quy trình Proxy API. Kiểm tra xem bạn đã bật tính năng phát trực tuyến hay chưa.

Trong trường hợp ví dụ, chính sách không thành công được thực thi trong quy trình Yêu cầu proxy (như xác định ở bước 5 ở trên); do đó, hãy kiểm tra Điểm cuối proxy:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
    <Properties>
      <Property name="response.streaming.enabled">true</Property>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
Như trong ví dụ trên, yêu cầu phát trực tuyến đã được bật như được biểu thị bằng thuộc tính "request.streaming.enabled" được đặt thành true.

Do đó, nguyên nhân gây ra lỗi là do bạn sử dụng chính sách JSON HayProtection trong Proxy API để truy cập vào tải trọng yêu cầu khi tính năng truyền trực tuyến được bật. Điều này gây ra lỗi vì nó kích hoạt việc lưu vào bộ đệm trong Proxy API và ngăn chặn mục đích sử dụng tính năng truyền trực tuyến trong Apigee Edge.

Bạn có thể không thấy lỗi này với các tải trọng nhỏ hơn, nhưng khi sử dụng các tải trọng lớn hơn, bạn có thể thấy những lỗi này.
Bạn có thể xác minh rằng lỗi 500 là do chính sách gây ra bằng cách kiểm tra giá trị của "X-Apigee-fault-source" trong Giai đoạn "AX" (Dữ liệu phân tích đã ghi) trong dấu vết bằng cách làm theo các bước dưới đây:
1. Nhấp vào Giai đoạn "AX" (Dữ liệu phân tích được ghi lại) như trong ảnh chụp màn hình bên dưới:
2. Di chuyển xuống phần Thông tin chi tiết về giai đoạn đến mục "Error Headers" (Tiêu đề lỗi) rồi xác định giá trị của "X-Apigee-fault-code", "X-Apigee-fault-source" và "X-Apigee-fault-policy" như minh hoạ bên dưới:
3. Nếu giá trị của "X-Apigee-fault-source" là "policy" như trong hình trên, thì tức là lỗi xảy ra do chính sách truy cập vào tải trọng dữ liệu khi bật tính năng phát trực tuyến.

Độ phân giải

Truy cập tải trọng khi bật chế độ truyền trực tuyến là một phản mẫu như được giải thích trong phần Chống mẫu: Truy cập tải trọng yêu cầu/phản hồi khi bật tính năng truyền trực tuyến.

Nếu muốn xử lý tải trọng, bạn cần tắt tính năng phát trực tuyến trong Điểm cuối proxy/đích bằng cách xoá các thuộc tính "request.streaming.enabled" and "response.streaming.enabled"như minh hoạ trong ví dụ về ProxyEndpoint dưới đây:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
HOẶC
Nếu bạn muốn sử dụng tính năng truyền trực tuyến cho(các) Proxy API, thì đừng sử dụng bất kỳ chính sách nào trong Proxy API truy cập vào tải trọng yêu cầu/phản hồi.

Lưu ý:

Trong cẩm nang này, chúng tôi sử dụng chính sách JSONBảo vệ khỏi mối đe doạ để xử lý tải trọng yêu cầu khi bật tính năng truyền trực tuyến trong tình huống ví dụ. Điều này đã dẫn đến Lỗi máy chủ nội bộ 500 với nhiều lỗi.
Bạn cũng có thể thấy những lỗi này trong các chính sách như JSONToXML và XMLToJSON, những chính sách xử lý yêu cầu hoặc phản hồi tải trọng khi bật tính năng truyền trực tuyến.
Bạn không nên sử dụng bất kỳ chính sách nào như vậy trong các proxy yêu cầu quyền truy cập vào các tải trọng khi bật tính năng truyền trực tuyến.
Làm như vậy là một phản mẫu, như được nêu trong Antipattern: Truy cập tải trọng yêu cầu/phản hồi khi tính năng truyền trực tuyến được bật.

Chẩn đoán vấn đề bằng tính năng Giám sát API

Nếu bạn là người dùng Đám mây riêng tư, hãy bỏ qua quy trình 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, hiệu suất và các vấn đề về độ trễ cũng như nguồn gây ra các vấn đề này, chẳng hạn như các ứng dụng của 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ụ: bạn có thể thiết lập cảnh báo để nhận thông báo khi số lượng 500 Lỗi vượt quá một ngưỡng cụ thể.

Nếu muốn nhận thông báo khi chính sách gửi phản hồi lỗi 500, thì bạn cần thiết lập cảnh báo cho mã trạng thái 500 bằng nguồn lỗi dưới dạng Proxy.

Phải thu thập thông tin chẩn đoán

Nếu sự cố vẫn tiếp diễn sau khi đã làm theo các hướng dẫn ở trên, hãy thu thập các thông tin chẩn đoán sau. Hãy liên hệ và chia sẻ họ với Nhóm hỗ trợ API.

Nếu bạn là người dùng Public Cloud, hãy cung cấp những thông tin sau:

Tên tổ chức
Tên môi trường
Tên proxy API
Hoàn thành lệnh curl cùng với tải trọng yêu cầu (nếu có) để tái tạo lỗi 500
Tệp theo dõi chứa các yêu cầu gặp lỗi 500 đối với lỗi máy chủ nội bộ
Nếu lỗi 500 hiện không xảy ra, hãy cung cấp khoảng thời gian kèm theo thông tin múi giờ khi lỗi 500 lỗi đó xảy ra trong quá khứ.

Nếu bạn là người dùng Đám mây riêng tư, hãy cung cấp những thông tin sau:

Đã phát hiện thấy thông báo lỗi hoàn chỉnh đối với các yêu cầu không thành công
Tổ chức, Tên môi trường và Tên proxy API mà bạn đang quan sát 500 lỗi
Gói proxy API
Tải trọng đã sử dụng trong yêu cầu (nếu có)
Tệp theo dõi chứa các yêu cầu gặp lỗi 500 đối với lỗi máy chủ nội bộ
Nhật ký truy cập NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
Nhật ký Trình xử lý thông báo (/opt/apigee/var/log/edge-message-processor/logs/system.log)
Khoảng thời gian có thông tin múi giờ khi xảy ra 500 lỗi.