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 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ộ) đối với lệnh gọi API.

Thông báo lỗi

Ứ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

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 500 Lỗi máy chủ nội bộ gây ra do truy cập vào yêu cầu/phản hồi tải trọng khi phát trực tuyến được bật.

Nguyên nhân	Nội dung mô tả	Người có thể thực hiện các bước khắc phục sự cố
Truy cập Payload bằng Đã 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 được bật.	Người dùng Edge riêng tư và công khai trên đám mây công cộng

Nguyên nhân: Truy cập tải trọng khi đã bật tính năng truyền trực tuyến

Chẩn đoán

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

Bật tính năng theo dõi phiên và thực hiện lệnh gọi API để tái hiện vấn đề – 500 Lỗi máy chủ nội bộ.
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 của quá trình theo dõi và xác định nơi 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.
Đây là ảnh chụp màn hình về dấu vết mẫu cho thấy lớp JSONThreatProtection chính sách không thành công với lỗi "Expecting } ở dòng 1":

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

Chính sách không đạt: JSONThreatProtection

Quy trình: Yêu cầu proxy
Kiểm tra định nghĩa về chính sách không thành công và kiểm tra tải trọng đang được phân tích cú pháp.
Trong trường hợp ví dụ này, hãy kiểm tra chính sách JSONThreatProtection có tên là JSON-Threat-Protection 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>
```
Lưu ý 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 của yêu cầu.
Xác định loại tải trọng đượ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ụ về lệnh curl sau đây, một tải trọng JSON sẽ đượ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 xem chính sách không thành công và xác định loại trọng tải đang đã phân tích cú pháp. Trong trường hợp ví dụ ở trên, chính sách Bảo vệ mối đe doạ JSON không thành cô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ó ở định dạng phù hợp hay không. Nếu tải trọng không hợp lệ thì 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 của tải trọng.
Nếu tải trọng hợp lệ nhưng bạn vẫn gặp phải lỗi như được liệt kê trong Thông báo lỗi, sau đó là nguyên nhân gây ra các lỗi này là tải trọng đang được truy cập khi bật tính năng truyền trực tuyến.

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

Trong trường hợp ví dụ này, tải trọng yêu cầu được phân tích cú pháp, do đó hãy kiểm tra Giai đoạn "Yêu cầu đã nhận được từ khách hàng" trong theo dõi và kiểm tra Yêu cầu nội dung.

Nếu Yêu cầu nội dung 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 đó chỉ ra rằng nguyên nhân có thể của vấn đề này là bật tính năng truyền trực tuyến yêu cầu.

Lý do là khi bạn bật tính năng truyền trực tuyến, tải trọng của yêu cầu sẽ không xuất hiện trên 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ủ đích".
Tiếp theo, hãy kiểm tra các định nghĩa về Proxy và Điểm cuối mục tiêu, tuỳ thuộc vào vị trí gặp lỗi chính sách này sẽ được sử dụng trong quy trình Proxy API. Xác minh xem tính năng truyền trực tuyến đã được bật 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 luồng yêu cầu Proxy (như đã xác định trong 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ư bạn thấy trong ví dụ trên, yêu cầu truyền trực tuyến đã được bật như được biểu thị bởi thuộc tính "request.streaming.enabled" được đặt thành true.

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

Lỗi này có thể không xuất hiện 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ể xem các 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 "AX" (Dữ liệu Analytics đã ghi lại) Giai đoạn trong quá trình theo dõi 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 Analytics đã ghi lại) như trong ảnh chụp màn hình dưới đây:
2. Cuộn xuống Chi tiết giai đoạn đến phần "Tiêu đề lỗi" và xác định giá trị của "X-Apigee-fault-code", "X-Apigee-fault-source" và "X-Apigee-fault-policy" như minh hoạ dưới đây:
3. Nếu giá trị của "X-Apigee-fault-source" là "policy" như hình trong hình trên, thì giá trị này cho biết rằng lỗi này xảy ra do việc chính sách truy cập vào khi bật tính năng truyền trực tuyến.

Độ phân giải

Việc truy cập vào tải trọng khi bật tính năng truyền trực tuyến là một hành vi phản mẫu, như được giải thích trong Phản mẫu: Truy cập vào 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 thì bạn cần tắt tính năng truyền trực tuyến trong Proxy/Mục tiêu Điểm cuối bằng cách xoá các thuộc tính "request.streaming.enabled" and "response.streaming.enabled"như trong ví dụ về ProxyEndpoint bên dưới:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
OR
Nếu bạn muốn sử dụng tính năng phát trực tuyến cho(các) Proxy API của mình, vui lòng khô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ính sách JSONThreatProtection được dùng để xử lý tải trọng yêu cầu bằng phát trực tuyến trong trường hợp ví dụ này. Điều này dẫn đến lỗi 500 máy chủ nội bộ với nhiều lỗi khác nhau.
Bạn cũng có thể thấy các lỗi này với các chính sách như JSONToXML và XMLToJSON. Các chính sách này tải trọng yêu cầu hoặc phản hồi của bạn 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 khi bật tính năng truyền trực tuyến.
Việc này là phản mẫu, như được ghi trong Phản mẫu: Truy cập vào 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.

Chẩn đoán sự cố 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.

Tính năng 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 của các vấn đề đó, chẳng hạn như ứ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 qua một tình huống mẫu minh hoạ cách khắc phục sự cố 5xx với API của bạn bằng cách sử dụng Giám sát API. Ví dụ: bạn có thể muốn thiết lập cảnh báo để được 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 500 lỗi thì bạn cần thiết lập cảnh báo cho mã trạng thái 500 với nguồn lỗi là Proxy.

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

Nếu vấn đề vẫn tiếp diễn sau khi đã làm theo các hướng dẫn ở trên, hãy thu thập thông tin chẩn đoán sau đây. Hãy liên hệ và chia sẻ chúng với Bộ phận hỗ trợ Apigee.

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

Tên tổ chức
Tên môi trường
Tên proxy API
Hoàn tất lệnh curl cùng với tải trọng yêu cầu (nếu có) để tái hiện lỗi 500
Tệp theo dõi chứa các yêu cầu có Lỗi máy chủ nội bộ 500
Nếu lỗi 500 hiện không xảy ra thì hãy cung cấp khoảng thời gian kèm theo thông tin múi giờ khi lỗi 500 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 các thông tin sau:

Đã nhậ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ực hiện được
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 có Lỗi máy chủ nội bộ 500
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ư (/opt/apigee/var/log/edge-message-processor/logs/system.log)
Khoảng thời gian kèm theo thông tin múi giờ khi xảy ra lỗi 500.