Google sử dụng công nghệ AI để dịch nội dung sang ngôn ngữ bạn ưu tiên. Bản dịch bằng AI có thể có lỗi.

504 Cổng hết thời gian chờ

Bạn đang xem tài liệu về Apigee Edge.
Truy cập vào tài liệu Apigee X. thông tin

Dấu hiệu

Ứng dụng khách nhận được mã trạng thái HTTP 504 kèm theo thông báo Gateway Timeout dưới dạng phản hồi cho các lệnh gọi API.

Mã trạng thái HTTP – lỗi 504 Gateway Timeout cho biết rằng ứng dụng không nhận được phản hồi kịp thời từ Edge Gateway hoặc máy chủ phụ trợ trong quá trình thực thi API

Thông báo lỗi

Ứng dụng khách nhận được mã phản hồi sau:

HTTP/1.1 504 Gateway Timeout

Trong một số trường hợp, bạn cũng có thể thấy thông báo lỗi sau:

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

Nguyên nhân gây ra lỗi hết thời gian chờ của cổng là gì?

Đường dẫn điển hình cho một yêu cầu API thông qua nền tảng Edge sẽ là Client -> Router -> Message Processor -> Backend Server như minh hoạ trong hình bên dưới:

Ứng dụng khách, bộ định tuyến và Trình xử lý thông báo trong nền tảng Edge được thiết lập với các giá trị thời gian chờ phù hợp. Nền tảng Edge dự kiến sẽ gửi phản hồi trong một khoảng thời gian nhất định cho mọi yêu cầu API dựa trên các giá trị thời gian chờ. Nếu bạn không nhận được phản hồi trong khoảng thời gian quy định, thì 504 Gateway Timeout Error sẽ được trả về.

Bảng sau đây cung cấp thêm thông tin chi tiết về thời điểm có thể xảy ra thời gian chờ trong Edge:

Trường hợp hết thời gian chờ	Thông tin chi tiết
Đã hết thời gian chờ trên Trình xử lý thông báo	Máy chủ phụ trợ không phản hồi Trình xử lý thông báo trong khoảng thời gian chờ đã chỉ định trên Trình xử lý thông báo. Message Processor hết thời gian chờ và gửi trạng thái phản hồi là `504 Gateway Timeout` đến Router.
Đã hết thời gian chờ trên Router	Trình xử lý tin nhắn không phản hồi bộ định tuyến trong khoảng thời gian chờ đã chỉ định trên Bộ định tuyến. Bộ định tuyến hết thời gian chờ và gửi trạng thái phản hồi là `504 Gateway Timeout` đến ứng dụng khách.
Hết thời gian chờ trên ứng dụng khách	Bộ định tuyến không phản hồi ứng dụng khách trong khoảng thời gian chờ đã chỉ định trên bộ định tuyến. Ứng dụng Client hết thời gian chờ và kết thúc trạng thái phản hồi là `504 Gateway Timeout` đối với người dùng cuối.

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

Trong Edge, những nguyên nhân thường gặp gây ra lỗi 504 Gateway Timeout là:

Nguyên nhân	Thông tin chi tiết	Số bước được tính cho
Máy chủ phụ trợ chậm	Máy chủ phụ trợ đang xử lý yêu cầu API quá chậm do tải cao hoặc hiệu suất kém.	Người dùng đám mây công khai và đám mây riêng tư
Edge xử lý yêu cầu API chậm	Edge mất nhiều thời gian để xử lý yêu cầu API do tải cao hoặc hiệu suất kém.

Máy chủ phụ trợ chậm

Nếu máy chủ phụ trợ hoạt động rất chậm hoặc mất nhiều thời gian để xử lý yêu cầu API, thì bạn sẽ gặp lỗi 504 Gateway Timeout. Như đã giải thích trong phần trên, thời gian chờ có thể xảy ra trong một trong các trường hợp sau:

Bộ xử lý thông báo hết thời gian chờ trước khi máy chủ phụ trợ phản hồi.
Bộ định tuyến hết thời gian chờ trước khi Bộ xử lý thông báo/máy chủ phụ trợ phản hồi.
Ứng dụng khách hết thời gian chờ trước khi Bộ định tuyến/Bộ xử lý thông báo/máy chủ phụ trợ phản hồi.

Các phần sau đây mô tả cách chẩn đoán và giải quyết vấn đề trong từng trường hợp này.

Tình huống 1: Bộ xử lý thông báo hết thời gian chờ trước khi máy chủ phụ trợ phản hồi

Chẩn đoán

Bạn có thể sử dụng các quy trình sau để chẩn đoán xem lỗi 504 Gateway Timeout có xảy ra do máy chủ phụ trợ chậm hay không.

Quy trình 1: Sử dụng tính năng Trace

Nếu vấn đề vẫn tiếp diễn (vẫn xảy ra lỗi 504), hãy làm theo các bước dưới đây:

Theo dõi API bị ảnh hưởng trong giao diện người dùng Edge. Bạn có thể đợi lỗi xảy ra hoặc nếu có lệnh gọi API, hãy thực hiện một số lệnh gọi API và tái tạo lỗi 504 Gateway Timeout.
Sau khi xảy ra lỗi, hãy kiểm tra yêu cầu cụ thể cho thấy mã phản hồi là 504.
Kiểm tra thời gian đã trôi qua ở mỗi giai đoạn và ghi chú lại giai đoạn mà bạn dành nhiều thời gian nhất.
Nếu bạn nhận thấy lỗi có thời gian đã trôi qua lâu nhất ngay sau một trong các giai đoạn sau, thì điều đó cho thấy máy chủ phụ trợ đang hoạt động chậm hoặc mất nhiều thời gian để xử lý yêu cầu:
- Đã gửi yêu cầu đến máy chủ đích
- Chính sách ServiceCallout

Sau đây là một mẫu Dấu vết cho thấy máy chủ phụ trợ không phản hồi ngay cả sau 55 giây, dẫn đến lỗi 504 Gateway Timeout:

Trong dấu vết ở trên, Message Processor hết thời gian chờ sau 55002 mili giây vì máy chủ phụ trợ không phản hồi.

Quy trình 2: Sử dụng nhật ký Trình xử lý tin nhắn

Kiểm tra nhật ký của Trình xử lý tin nhắn (/opt/apigee/var/log/edge-message-processor/logs/system.log)

Nếu bạn thấy lỗi Gateway Timeout và onTimeoutRead cho yêu cầu cụ thể của API proxy tại thời điểm cụ thể, thì điều đó có nghĩa là Message Processor đã hết thời gian chờ.

Nhật ký của Trình xử lý thông báo mẫu cho thấy Lỗi hết thời gian chờ của cổng

2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1
ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway
Timeout)
2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8
NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() :
SSLClientChannel[C:XX.XX.XX.XX:443 Remote
host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0
bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead

Trong nhật ký Message Processor (Bộ xử lý thông báo) ở trên, bạn nhận thấy rằng máy chủ phụ trợ được biểu thị bằng địa chỉ IP XX.XX.XX.XX không phản hồi ngay cả sau 55 giây (lastIO=55000ms). Do đó, Message Processor đã hết thời gian chờ và gửi lỗi 504 Gateway Timeout.

Hãy kiểm tra: Thời gian chờ được kiểm soát như thế nào trên Trình xử lý tin nhắn?

Thời gian chờ được kiểm soát như thế nào trên Trình xử lý tin nhắn. Trình xử lý thông báo thường được đặt với giá trị thời gian chờ mặc định là 55 giây) thông qua thuộc tính HTTPTransport.io.timeout.millis. Giá trị thời gian chờ này áp dụng cho tất cả API Proxy thuộc một tổ chức do Message Processor này phục vụ.
- Nếu máy chủ phụ trợ không phản hồi trong vòng 55 giây, thì Trình xử lý tin nhắn sẽ hết thời gian chờ và gửi lỗi 504 Gateway Timeout đến ứng dụng.
Giá trị thời gian chờ được chỉ định trong Trình xử lý thông báo có thể bị ghi đè bằng thuộc tính io.timeout.millis được chỉ định trong API Proxy. Giá trị thời gian chờ này áp dụng cho một Proxy API cụ thể mà trong đó thuộc tính nêu trên được chỉ định. Ví dụ: nếu io.timeout.millis được đặt thành 10 giây trong API Proxy, thì giá trị thời gian chờ là 10 giây sẽ được dùng cho API Proxy cụ thể này.
- Nếu máy chủ phụ trợ không phản hồi trong vòng 10 giây cho một API Proxy cụ thể, thì Message Processor sẽ hết thời gian chờ và gửi lỗi 504 Gateway Timeout đến ứng dụng.

Độ phân giải

Kiểm tra lý do máy chủ phụ trợ mất hơn 55 giây và xem liệu bạn có thể khắc phục/tối ưu hoá để phản hồi nhanh hơn hay không.
Nếu không thể sửa/tối ưu hoá máy chủ phụ trợ hoặc nếu bạn biết rằng máy chủ phụ trợ mất nhiều thời gian hơn thời gian chờ đã định cấu hình, thì hãy Tăng giá trị thời gian chờ trên Bộ định tuyến và Trình xử lý thông báo thành một giá trị phù hợp.

Tình huống #2 – Bộ định tuyến hết thời gian chờ trước khi Bộ xử lý thông báo/máy chủ phụ trợ phản hồi

Bạn có thể gặp lỗi 504 Gateway Timeout nếu bộ định tuyến hết thời gian chờ trước khi Bộ xử lý thông báo/máy chủ phụ trợ phản hồi. Điều này có thể xảy ra trong một trong những trường hợp sau:

Giá trị thời gian chờ được đặt trên Bộ định tuyến ngắn hơn giá trị thời gian chờ được đặt trên Trình xử lý thông báo. Ví dụ: giả sử thời gian chờ trên Bộ định tuyến là 50 giây, trong khi Bộ xử lý thông báo là 55 giây.

Hết thời gian chờ trên bộ định tuyến	Hết thời gian chờ trên Trình xử lý thông báo
50 giây	55 giây

Giá trị thời gian chờ trên Trình xử lý thông báo sẽ bị ghi đè bằng giá trị thời gian chờ cao hơn bằng cách sử dụng thuộc tính io.timeout.millis được đặt trong cấu hình điểm cuối đích của API Proxy:

Ví dụ: nếu bạn đặt các giá trị thời gian chờ sau đây:

Hết thời gian chờ trên bộ định tuyến	Hết thời gian chờ trên Trình xử lý thông báo	Hết thời gian chờ trong API Proxy
57 giây	55 giây	120 giây

Nhưng io.timeout.millis được đặt thành 120 giây trong API Proxy:

<HTTPTargetConnection>
     <Properties>
          <Property name="io.timeout.millis">120000</Property>
      </Properties>
      <URL>http://www.apigee.com</URL>
</HTTPTargetConnection>

Sau đó, Message Processor sẽ không hết thời gian chờ sau 55 giây, mặc dù giá trị thời gian chờ của Message Processor (55 giây) nhỏ hơn giá trị thời gian chờ trên bộ định tuyến (57 giây). Lý do là giá trị thời gian chờ 55 giây trên Trình xử lý thông báo sẽ bị ghi đè bằng giá trị 120 giây được đặt trong API Proxy. Vì vậy, giá trị thời gian chờ của Trình xử lý thông báo cho API Proxy cụ thể này sẽ là 120 giây.

Vì Bộ định tuyến có giá trị thời gian chờ thấp hơn (57 giây) so với 120 giây được đặt trong API Proxy, nên bộ định tuyến sẽ hết thời gian chờ nếu máy chủ phụ trợ không phản hồi sau 57 giây.

Chẩn đoán

Kiểm tra nhật ký truy cập NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
Nếu bộ định tuyến hết thời gian chờ trước khi Bộ xử lý thông báo hết thời gian chờ, thì bạn sẽ thấy trạng thái 504 trên nhật ký truy cập NGINX cho yêu cầu API cụ thể và message id từ Bộ xử lý thông báo sẽ được đặt thành -. Điều này là do Router không nhận được phản hồi nào từ Message Processor trong khoảng thời gian chờ được đặt trên bộ định tuyến.

Mẫu mục nhập nhật ký NGINX cho thấy lỗi 504 do Bộ định tuyến hết thời gian chờ
Trong ví dụ trên, hãy lưu ý trạng thái của 504 trên NGINX, mã thông báo từ Message Processor là - và tổng thời gian đã trôi qua là 57,001 giây. Điều này là do bộ định tuyến đã hết thời gian chờ sau 57,001 giây và chúng tôi không nhận được phản hồi nào từ Trình xử lý thông báo.

Trong trường hợp này, bạn sẽ thấy các ngoại lệ Broken Pipe trong nhật ký Message Processor (Trình xử lý thông báo) (/opt/apigee/var/log/edge-message-processor/logs/system.log).

2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>

Lỗi này xuất hiện vì sau khi hết thời gian chờ, bộ định tuyến sẽ đóng kết nối với Trình xử lý thông báo. Khi Message Processor hoàn tất quá trình xử lý, nó sẽ cố gắng ghi phản hồi vào bộ định tuyến. Vì kết nối với bộ định tuyến đã đóng, nên bạn sẽ nhận được Broken Pipe exception trên Message Processor.

Trường hợp ngoại lệ này dự kiến sẽ xuất hiện trong các trường hợp được giải thích ở trên. Vì vậy, nguyên nhân thực sự gây ra lỗi 504 Gateway Timeout vẫn là do máy chủ phụ trợ mất nhiều thời gian hơn để phản hồi và bạn cần giải quyết vấn đề đó.

Độ phân giải

Nếu đó là một máy chủ phụ trợ tuỳ chỉnh, thì

Kiểm tra lý do khiến máy chủ phụ trợ mất nhiều thời gian để phản hồi và xem liệu bạn có thể khắc phục/tối ưu hoá để phản hồi nhanh hơn hay không.

Nếu không thể sửa/tối ưu hoá máy chủ phụ trợ hoặc nếu máy chủ phụ trợ mất nhiều thời gian, thì hãy Tăng giá trị thời gian chờ trên Bộ định tuyến và Trình xử lý thông báo.

Ý tưởng: Đặt giá trị thời gian chờ cho các thành phần khác nhau theo thứ tự sau:

Hết thời gian chờ trên máy khách > Hết thời gian chờ trên bộ định tuyến > Hết thời gian chờ trên trình xử lý thông báo > Hết thời gian chờ trong API Proxy

Nếu đó là máy chủ phụ trợ NodeJS, thì:
1. Kiểm tra xem mã NodeJS có gọi đến bất kỳ máy chủ phụ trợ nào khác hay không và liệu mã đó có mất nhiều thời gian để trả về phản hồi hay không. Kiểm tra lý do khiến các máy chủ phụ trợ mất nhiều thời gian hơn và khắc phục vấn đề nếu cần.
2. Kiểm tra xem Bộ xử lý thông báo có đang sử dụng CPU hoặc mức sử dụng bộ nhớ ở mức cao hay không:
  1. Nếu có bất kỳ Trình xử lý thông báo nào đang gặp phải tình trạng sử dụng CPU cao, hãy tạo 3 dữ liệu kết xuất luồng sau mỗi 30 giây bằng lệnh sau:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Nếu có bất kỳ Trình xử lý thông báo nào đang có mức sử dụng bộ nhớ cao, hãy tạo một kết xuất heap bằng lệnh sau:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Khởi động lại Trình xử lý thông báo bằng lệnh bên dưới. Thao tác này sẽ giảm mức sử dụng CPU và bộ nhớ:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
  4. Theo dõi các lệnh gọi API để xác nhận xem vấn đề có còn tồn tại hay không.
  5. Liên hệ với Nhóm hỗ trợ Apigee Edge và cung cấp các kết xuất luồng, kết xuất heap và nhật ký Trình xử lý thông báo (/opt/apigee/var/log/edge-message-processor/logs/system.log)để giúp điều tra nguyên nhân dẫn đến việc sử dụng nhiều CPU/bộ nhớ.

Kiểm tra điều này: Cách kiểm soát thời gian chờ cho máy chủ phụ trợ NodeJS trên Trình xử lý thông báo

Máy chủ phụ trợ NodeJS chạy trong quy trình JVM của Trình xử lý thông báo. Giá trị thời gian chờ cho các máy chủ phụ trợ NodeJS được kiểm soát thông qua thuộc tính http.request.timeout.seconds trong tệp nodejs.properties. Theo mặc định, thuộc tính này được đặt thành 0, tức là theo mặc định, thời gian chờ sẽ bị vô hiệu hoá đối với tất cả API Proxy thuộc một tổ chức do Message Processor này phân phát. Vì vậy, ngay cả khi máy chủ phụ trợ NodeJS mất nhiều thời gian, Trình xử lý thông báo sẽ không hết thời gian chờ.
Tuy nhiên, nếu máy chủ phụ trợ NodeJS mất nhiều thời gian và nếu thời gian thực hiện yêu cầu API > 57 giây, thì Bộ định tuyến sẽ hết thời gian chờ và gửi lỗi 504 Gateway Timeout đến máy khách.

Tình huống 3 – Ứng dụng khách hết thời gian chờ trước khi Bộ định tuyến/Bộ xử lý tin nhắn/máy chủ phụ trợ phản hồi

Bạn có thể gặp lỗi 504 Gateway Timeout nếu ứng dụng khách hết thời gian chờ trước khi máy chủ phụ trợ phản hồi. Tình huống này có thể xảy ra nếu:

Giá trị thời gian chờ được đặt trên ứng dụng khách thấp hơn giá trị thời gian chờ được đặt trên bộ định tuyến và Trình xử lý thông báo:

Ví dụ: nếu bạn đặt các giá trị thời gian chờ sau đây:

Hết thời gian chờ trên ứng dụng	Hết thời gian chờ trên bộ định tuyến	Hết thời gian chờ trên Trình xử lý thông báo
50 giây	57 giây	55 giây

Trong trường hợp này, tổng thời gian có sẵn để nhận phản hồi cho một yêu cầu API thông qua Edge là <= 50 giây. Thời gian này bao gồm thời gian thực hiện yêu cầu API, yêu cầu được Edge (Bộ định tuyến, Trình xử lý thông báo) xử lý, yêu cầu được gửi đến máy chủ phụ trợ (nếu có), phụ trợ xử lý yêu cầu và gửi phản hồi, Edge xử lý phản hồi và cuối cùng gửi phản hồi đó trở lại cho ứng dụng.

Nếu bộ định tuyến không phản hồi máy khách trong vòng 50 giây, thì máy khách sẽ hết thời gian chờ và đóng kết nối với bộ định tuyến. Máy khách sẽ nhận được mã phản hồi 504.

Điều này sẽ khiến NGINX đặt mã trạng thái 499 cho biết ứng dụng khách đã đóng kết nối.

Chẩn đoán

Nếu ứng dụng khách hết thời gian chờ trước khi nhận được phản hồi từ bộ định tuyến, thì ứng dụng đó sẽ đóng kết nối với bộ định tuyến. Trong trường hợp này, bạn sẽ thấy mã trạng thái 499 trong nhật ký truy cập NGINX cho yêu cầu API cụ thể.
Mẫu mục nhập nhật ký NGINX cho thấy mã trạng thái 499
Trong ví dụ trên, xin lưu ý rằng trạng thái của 499 trên NGINX và tổng thời gian đã trôi qua là 50,001 giây. Điều này cho thấy máy khách đã hết thời gian chờ sau 50,001 giây.

Trong trường hợp này, bạn sẽ thấy Broken Pipe Exceptions trong nhật ký Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).

2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>

Sau khi hết thời gian chờ, Bộ định tuyến sẽ đóng kết nối với Trình xử lý thông báo. Khi Message Processor hoàn tất quá trình xử lý, nó sẽ cố gắng ghi phản hồi vào Router. Vì kết nối đến Bộ định tuyến đã đóng, nên bạn sẽ nhận được Broken Pipe exception trên Trình xử lý thông báo.
Trường hợp ngoại lệ này dự kiến sẽ xảy ra trong các trường hợp được giải thích ở trên. Vì vậy, nguyên nhân thực sự gây ra lỗi 504 Gateway Timeout vẫn là do máy chủ phụ trợ mất nhiều thời gian để phản hồi và bạn cần giải quyết vấn đề đó.

Độ phân giải

Nếu đó là máy chủ phụ trợ tuỳ chỉnh của bạn, hãy làm như sau:

Kiểm tra máy chủ phụ trợ để xác định lý do khiến máy chủ mất hơn 57 giây và xem liệu bạn có thể khắc phục/tối ưu hoá để máy chủ phản hồi nhanh hơn hay không.

Nếu không thể sửa/tối ưu hoá máy chủ phụ trợ hoặc nếu bạn biết rằng máy chủ phụ trợ sẽ mất nhiều thời gian, thì hãy tăng giá trị thời gian chờ trên bộ định tuyến và Trình xử lý thông báo.

Ý tưởng: Đặt giá trị thời gian chờ cho các thành phần khác nhau theo thứ tự sau:

Nếu đó là một phần phụ trợ NodeJS, thì:
1. Kiểm tra xem mã NodeJS có gọi đến bất kỳ máy chủ phụ trợ nào khác hay không và liệu việc đó có mất nhiều thời gian để trả về hay không. Kiểm tra lý do khiến các máy chủ phụ trợ đó mất nhiều thời gian hơn.
2. Kiểm tra xem Bộ xử lý thông báo có đang sử dụng nhiều CPU hoặc bộ nhớ hay không:
  1. Nếu một Trình xử lý thông báo đang có mức sử dụng CPU cao, hãy tạo 3 dữ liệu kết xuất luồng sau mỗi 30 giây bằng lệnh sau:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Nếu Trình xử lý thông báo đang gặp phải mức sử dụng bộ nhớ cao, hãy tạo một tệp báo lỗi bằng lệnh sau:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Khởi động lại Trình xử lý thông báo bằng lệnh bên dưới. Điều này sẽ làm giảm CPU và bộ nhớ:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
  4. Theo dõi các lệnh gọi API để xác nhận xem vấn đề có còn tồn tại hay không.
  5. Liên hệ với Nhóm hỗ trợ Apigee Edge và cung cấp các kết xuất luồng, kết xuất heap và nhật ký Trình xử lý thông báo (/opt/apigee/var/log/edge-message-processor/logs/system.log)để giúp họ điều tra nguyên nhân dẫn đến việc sử dụng nhiều CPU/bộ nhớ.

Tăng giá trị thời gian chờ trên Bộ định tuyến và Trình xử lý thông báo

Hãy chọn cẩn thận các giá trị thời gian chờ sẽ được đặt trên Bộ định tuyến và Trình xử lý thông báo, tuỳ thuộc vào yêu cầu của bạn. Không đặt các giá trị thời gian chờ quá lớn một cách tuỳ ý. Nếu bạn cần được trợ giúp, hãy liên hệ với Nhóm hỗ trợ Apigee Edge.

Bộ định tuyến

chown apigee:apigee /opt/apigee/customer/application/router.properties

Tạo tệp /opt/apigee/customer/application/router.properties trên máy Router nếu chưa có.
Thêm dòng sau vào tệp này:
```
conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS
```
Ví dụ: nếu bạn muốn đặt giá trị thời gian chờ là 120 giây, hãy đặt giá trị này như sau:
```
conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
```
Đảm bảo tệp này thuộc sở hữu của apigee:

Khởi động lại bộ định tuyến:

/opt/apigee/apigee-service/bin/apigee-service edge-router restart

Nếu bạn có nhiều bộ định tuyến, hãy lặp lại các bước trên cho tất cả bộ định tuyến.

Bộ xử lý thông báo

Tạo tệp /opt/apigee/customer/application/message-processor.properties trên máy Message Processor (Bộ xử lý thông báo) nếu chưa có.
Thêm dòng sau vào tệp này:
```
conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS
```
Ví dụ: nếu bạn muốn đặt giá trị thời gian chờ là 120 giây, hãy đặt giá trị này như sau:
```
conf_http_HTTPTransport.io.timeout.millis=120000
```

Đảm bảo tệp này thuộc sở hữu của apigee:

chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

Khởi động lại Trình xử lý tin nhắn:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Nếu bạn có nhiều Trình xử lý tin nhắn, hãy lặp lại các bước trên cho tất cả Trình xử lý tin nhắn.

Ý tưởng: Đặt giá trị thời gian chờ cho các thành phần khác nhau theo thứ tự sau:

Edge xử lý yêu cầu API chậm

Nếu Edge hoạt động rất chậm và/hoặc mất nhiều thời gian để xử lý yêu cầu API, thì bạn sẽ gặp lỗi 504 Gateway Timeout.

Chẩn đoán

Theo dõi API bị ảnh hưởng trong giao diện người dùng Edge.
Chờ lỗi xảy ra hoặc nếu bạn có lệnh gọi API, hãy thực hiện một số lệnh gọi API và tái tạo lỗi 504 Gateway Timeout.
Xin lưu ý rằng trong trường hợp này, bạn có thể thấy một phản hồi thành công trong Dấu vết.
1. Bộ định tuyến/máy khách hết thời gian chờ vì Trình xử lý thông báo không phản hồi trong khoảng thời gian chờ đã chỉ định trên Bộ định tuyến/máy khách (bất kỳ thành phần nào có khoảng thời gian chờ thấp nhất). Tuy nhiên, Trình xử lý thông báo vẫn tiếp tục xử lý yêu cầu và có thể hoàn tất thành công.
2. Ngoài ra, giá trị HTTPTransport.io.timeout.millis được đặt trên Trình xử lý thông báo chỉ kích hoạt nếu Trình xử lý thông báo giao tiếp với máy chủ phụ trợ HTTP/HTTPS. Nói cách khác, thời gian chờ này sẽ không được kích hoạt khi bất kỳ chính sách nào (ngoài chính sách ServiceCallout) trong API Proxy mất nhiều thời gian.
Sau khi xảy ra lỗi, hãy kiểm tra yêu cầu cụ thể có thời gian đã trôi qua lâu nhất.
Kiểm tra thời gian đã trôi qua ở mỗi giai đoạn và ghi chú lại giai đoạn mà bạn dành nhiều thời gian nhất.
Nếu bạn nhận thấy thời gian đã trôi qua lâu nhất trong bất kỳ chính sách nào khác ngoài chính sách Chú thích dịch vụ, thì điều đó cho thấy Edge đang mất nhiều thời gian để xử lý yêu cầu.
Sau đây là một dấu vết giao diện người dùng mẫu cho thấy thời gian đã trôi qua rất lâu trên Chính sách JavaScript:
Trong ví dụ trên, bạn nhận thấy chính sách JavaScript mất một khoảng thời gian dài bất thường là khoảng 245 giây.

Độ phân giải

Kiểm tra xem chính sách mất nhiều thời gian để phản hồi hay không và liệu có mã tuỳ chỉnh nào có thể mất nhiều thời gian để xử lý hay không. Nếu có mã như vậy, hãy xem bạn có thể sửa/tối ưu hoá mã đã xác định hay không.
Nếu không có mã tuỳ chỉnh nào có thể gây ra thời gian xử lý cao, hãy kiểm tra xem Bộ xử lý thông báo có đang gặp phải tình trạng sử dụng CPU hoặc mức sử dụng bộ nhớ cao hay không:
1. Nếu có bất kỳ Trình xử lý thông báo nào đang sử dụng CPU ở mức cao, hãy tạo 3 dữ liệu kết xuất luồng sau mỗi 30 giây bằng lệnh sau:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
2. Nếu có bất kỳ Trình xử lý thông báo nào có mức sử dụng Bộ nhớ cao, hãy tạo một tệp báo lỗi bằng lệnh sau:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
3. Khởi động lại Trình xử lý thông báo bằng lệnh bên dưới. Thao tác này sẽ giảm mức sử dụng CPU và bộ nhớ.
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
4. Theo dõi các lệnh gọi API và xác nhận xem vấn đề có còn tồn tại hay không.
5. Liên hệ với Nhóm hỗ trợ Apigee Edge và cung cấp các kết xuất luồng, kết xuất heap và nhật ký Trình xử lý thông báo (/opt/apigee/var/log/edge-message-processor/logs/system.log)để giúp họ điều tra nguyên nhân dẫn đến việc sử dụng CPU/bộ nhớ ở mức cao.

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

Giám sát API cho phép bạn nhanh chóng cô lập các khu vực có vấn đề để chẩn đoán lỗi, hiệu suất và độ trễ cũng như nguồn của chúng, chẳng hạn như ứ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 xét một tình huống mẫu minh hoạ cách khắc phục các vấn đề 5xx với API bằng tính năng Giám sát API. Ví dụ: bạn có thể thiết lập một cảnh báo để nhận thông báo khi số lượng mã trạng thái 504 vượt quá một ngưỡng cụ thể.