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 khách nhận được mã trạng thái HTTP của 502
kèm theo thông báo Bad Gateway
dưới dạng phản hồi cho lệnh gọi API.
Mã trạng thái HTTP 502
có nghĩa là ứng dụng không nhận được phản hồi hợp lệ từ các máy chủ phụ trợ thực sự thực hiện yêu cầu.
Thông báo lỗi
Ứng dụng khách nhận được mã phản hồi sau đây:
HTTP/1.1 502 Bad Gateway
Ngoài ra, bạn có thể nhận thấy thông báo lỗi sau:
{ "fault": { "faultstring": "Unexpected EOF at target", "detail": { "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget" } } }
Các nguyên nhân có thể
Một trong những nguyên nhân điển hình cho 502 Bad Gateway Error
là lỗi Unexpected EOF
. Lỗi này có thể là do những nguyên nhân sau:
Nguyên nhân | Thông tin chi tiết | Số bước đã đưa ra cho |
---|---|---|
Máy chủ đích không được định cấu hình đúng cách | Máy chủ đích không được định cấu hình đúng cách để hỗ trợ kết nối TLS/SSL. | Người dùng Edge Public và Private Cloud |
EOFException từ máy chủ phụ trợ | Máy chủ phụ trợ có thể gửi EOF đột ngột. | Chỉ dành cho người dùng Edge Private Cloud |
Định cấu hình không đúng cách để duy trì thời gian chờ hoạt động | Duy trì thời gian chờ hoạt động được định cấu hình không chính xác trên Apigee và máy chủ phụ trợ. | Người dùng Edge Public và Private Cloud |
Các bước chẩn đoán phổ biến
Để chẩn đoán lỗi, bạn có thể sử dụng một trong các phương pháp sau:
Giám sát API
Cách chẩn đoán lỗi bằng tính năng Giám sát API:
Khi sử dụng tính năng Giám sát API, bạn có thể điều tra các lỗi 502
bằng cách làm theo các bước như giải thích trong phần Điều tra vấn đề. Đó là:
- Chuyển đến trang tổng quan Điều tra.
- Chọn Mã trạng thái trong trình đơn thả xuống và đảm bảo bạn chọn khoảng thời gian thích hợp khi lỗi
502
xảy ra. - Nhấp vào hộp trong ma trận khi bạn thấy một số lượng lớn lỗi
502
. - Ở bên phải, hãy nhấp vào Xem nhật ký để xem các lỗi
502
có dạng như sau: - Nguồn lỗi là
target
- Mã lỗi là
messaging.adaptors.http.UnexpectedEOFAtTarget
Tại đây, chúng ta có thể xem những thông tin sau:
Mã này cho biết lỗi 502
là do mục tiêu gây ra do EOF ngoài dự kiến.
Ngoài ra, hãy ghi lại Request Message ID
của lỗi 502
để tìm hiểu thêm.
Công cụ theo dõi
Cách chẩn đoán lỗi bằng công cụ Theo dõi:
- Bật
phiên theo dõi và thực hiện lệnh gọi API để tái tạo vấn đề
502 Bad Gateway
. - 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.
-
Bạn sẽ thấy lỗi sau khi yêu cầu được gửi đến máy chủ đích như dưới đây:
-
Xác định giá trị của X-Apigee.fault-source và X-Apigee.fault-code trong Giai đoạn AX (Dữ liệu phân tích được ghi lại) trong dấu vết.
Nếu giá trị của X-Apigee.fault-source và X-Apigee.fault-code khớp với các giá trị hiển thị trong bảng sau, thì bạn có thể xác nhận lỗi
502
đến từ máy chủ đích:Tiêu đề phản hồi Giá trị X-Apigee.fault-source target
Mã X-Apigee.fault messaging.adaptors.http.flow.UnexpectedEOFAtTarget
Ngoài ra, hãy ghi lại
X-Apigee.Message-ID
của lỗi502
để tìm hiểu thêm.
Nhật ký truy cập NGINX
Cách chẩn đoán lỗi bằng NGINX:
Bạn cũng có thể tham khảo nhật ký truy cập NGINX để xác định nguyên nhân của mã trạng thái 502
. Đ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 đề không 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 trong 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 mọi lỗi
502
đối với proxy API cụ thể trong một khoảng thời gian cụ thể (nếu vấn đề đã xảy ra trong quá khứ) hoặc đối với bất kỳ yêu cầu nào vẫn không thành công với502
. - Nếu có lỗi
502
nào, hãy kiểm tra xem lỗi đó có phải là do mục tiêu gửiUnexpected EOF
hay không. Nếu giá trị của X-Apigee.fault-source và X- Apigee.fault-code khớp với các giá trị hiển thị trong bảng dưới đây, thì lỗi502
là do mục tiêu đóng kết nối đột ngột:Tiêu đề phản hồi Giá trị X-Apigee.fault-source target
Mã X-Apigee.fault messaging.adaptors.http.flow.UnexpectedEOFAtTarget
Dưới đây là mục mẫu cho thấy lỗi
502
do máy chủ mục tiêu gây ra:
Ngoài ra, hãy ghi lại mã nhận dạng thư của lỗi 502
để điều tra thêm.
Nguyên nhân: Máy chủ đích được định cấu hình không chính xác
Máy chủ đích không được định cấu hình đúng cách để hỗ trợ kết nối TLS/SSL.
Chẩn đoán
- Sử dụng Giám sát API, Công cụ theo dõi hoặc nhật ký truy cập NGINX để xác định mã thông báo, mã lỗi và nguồn lỗi cho lỗi
502
. - Bật tính năng theo dõi trong giao diện người dùng cho API bị ảnh hưởng.
- Nếu dấu vết của yêu cầu API không thành công cho thấy những thông tin sau:
- Lỗi
502 Bad Gateway
xuất hiện ngay khi yêu cầu luồng mục tiêu bắt đầu. error.class
cho thấymessaging.adaptors.http.UnexpectedEOF.
thì rất có thể vấn đề này là do cấu hình máy chủ mục tiêu không chính xác.
- Lỗi
- Lấy định nghĩa máy chủ mục tiêu bằng lệnh gọi API Quản lý Edge:
- Nếu bạn là người dùng Cloud công cộng, hãy sử dụng API sau:
curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
- Nếu bạn là người dùng Đám mây riêng tư, hãy sử dụng API này:
curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
Mẫu định nghĩa
TargetServer
bị lỗi:<TargetServer name="target1"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> </TargetServer >
- Nếu bạn là người dùng Cloud công cộng, hãy sử dụng API sau:
-
Định nghĩa
TargetServer
được minh hoạ là ví dụ cho một trong các cấu hình sai thông thường được giải thích như sau:Giả sử máy chủ đích
mocktarget.apigee.net
được định cấu hình để chấp nhận các kết nối bảo mật (HTTPS) trên cổng443
. Tuy nhiên, nếu bạn nhìn vào định nghĩa máy chủ mục tiêu, thì sẽ không có thuộc tính/cờ nào khác cho biết rằng định nghĩa này dành cho các kết nối bảo mật. Điều này khiến Edge coi các yêu cầu API gửi đến máy chủ mục tiêu cụ thể là yêu cầu HTTP (không bảo mật). Do đó, Edge sẽ không bắt đầu quá trình giao tiếp SSL với máy chủ đích này.Vì được định cấu hình để chỉ chấp nhận các yêu cầu HTTPS (SSL) trên
443
, máy chủ đích sẽ từ chối yêu cầu từ Edge hoặc đóng kết nối. Do đó, bạn sẽ gặp lỗiUnexpectedEOFAtTarget
trên Bộ xử lý thư. Bộ xử lý thông báo sẽ gửi502 Bad Gateway
dưới dạng một phản hồi cho ứng dụng.
Độ phân giải
Luôn đảm bảo rằng máy chủ đích được định cấu hình đúng theo yêu cầu của bạn.
Với ví dụ minh hoạ ở trên, nếu muốn gửi yêu cầu tới một máy chủ đích bảo mật (HTTPS/SSL), bạn cần thêm các thuộc tính SSLInfo
có cờ enabled
được đặt
thành true
. Mặc dù được phép thêm các thuộc tính SSLInfo
cho máy chủ mục tiêu trong chính phần định nghĩa điểm cuối mục tiêu, nhưng bạn nên thêm các thuộc tính SSLInfo
trong phần định nghĩa máy chủ mục tiêu để tránh nhầm lẫn.
- Nếu dịch vụ phụ trợ yêu cầu giao tiếp SSL một chiều, hãy làm như sau:
- Bạn cần bật TLS/SSL trong định nghĩa
TargetServer
, hãy thêm các thuộc tínhSSLInfo
, trong đó cờenabled
được đặt thành true (đúng) như minh hoạ bên dưới:<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
- Nếu bạn muốn xác thực chứng chỉ của máy chủ đích trong Edge, thì chúng ta cũng cần đưa vào Truststore (chứa chứng chỉ của máy chủ đích) như minh hoạ dưới đây:
<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Ciphers/> <ClientAuthEnabled>false</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <Protocols/> <TrustStore>mocktarget-truststore</TrustStore> </SSLInfo> </TargetServer>
- Bạn cần bật TLS/SSL trong định nghĩa
- Nếu dịch vụ phụ trợ yêu cầu giao tiếp SSL hai chiều, hãy làm như sau:
- Bạn cần thiết lập đúng cách các thuộc tính
SSLInfo
với cờClientAuthEnabled
,Keystore
,KeyAlias
vàTruststore
như sau:<TargetServer name="mocktarget"> <IsEnabled>true</IsEnabled> <Host>www.example.com</Host> <Port>443</Port> <SSLInfo> <Ciphers/> <ClientAuthEnabled>true</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <KeyAlias>keystore-alias</KeyAlias> <KeyStore>keystore-name</KeyStore> <Protocols/> <TrustStore>truststore-name</TrustStore> </SSLInfo> </TargetServer >
- Bạn cần thiết lập đúng cách các thuộc tính
Tài liệu tham khảo
Cân bằng tải trên các máy chủ phụ trợ
Nguyên nhân: EOFException từ máy chủ phụ trợ
Máy chủ phụ trợ có thể đột ngột gửi EOF (Cuối tệp).
Chẩn đoán
- Sử dụng Giám sát API, Công cụ theo dõi hoặc nhật ký truy cập NGINX để xác định mã thông báo, mã lỗi và nguồn lỗi cho lỗi
502
. - Hãy 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 kiếm xem liệu bạn cóeof unexpected
cho API cụ thể hay không hoặc liệu bạn cómessageid
riêng cho yêu cầu API hay không, sau đó bạn có thể tìm kiếm nó.Dấu vết ngăn xếp ngoại lệ mẫu từ nhật ký Trình xử lý thông báo
"message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {} java.io.EOFException: eof unexpected at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na] at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na] at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na] at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"
Trong ví dụ trên, bạn có thể thấy lỗi
java.io.EOFException: eof unexpected
xảy ra khi Trình xử lý thông báo đang cố đọc phản hồi từ máy chủ phụ trợ. Trường hợp ngoại lệ này cho biết kết thúc tệp (EOF) hoặc kết thúc phát trực tiếp đột ngột.Tức là Trình xử lý thông báo đã gửi yêu cầu API đến máy chủ phụ trợ và đang chờ hoặc đọc phản hồi. Tuy nhiên, máy chủ phụ trợ đã chấm dứt kết nối đột ngột trước khi Bộ xử lý thông báo nhận được phản hồi hoặc có thể đọc phản hồi đầy đủ.
- Kiểm tra nhật ký máy chủ phụ trợ và xem có lỗi hoặc thông tin nào có thể đã khiến máy chủ phụ trợ chấm dứt kết nối đột ngột hay không. Nếu bạn tìm thấy bất kỳ lỗi/thông tin nào, hãy chuyển đến phần Giải pháp và khắc phục vấn đề một cách phù hợp trong máy chủ phụ trợ của bạn.
- Nếu bạn không tìm thấy lỗi hoặc thông tin nào trong máy chủ phụ trợ, hãy thu thập đầu ra
tcpdump
trên Bộ xử lý thông báo:- Nếu máy chủ lưu trữ máy chủ phụ trợ của bạn có một địa chỉ IP duy nhất, hãy sử dụng lệnh sau:
tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME
- Nếu máy chủ lưu trữ máy chủ phụ trợ của bạn có nhiều địa chỉ IP, hãy dùng lệnh sau:
tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME
Thông thường, lỗi này xảy ra do máy chủ phụ trợ phản hồi bằng
[FIN,ACK]
ngay khi Trình xử lý thông báo gửi yêu cầu đến máy chủ phụ trợ.
- Nếu máy chủ lưu trữ máy chủ phụ trợ của bạn có một địa chỉ IP duy nhất, hãy sử dụng lệnh sau:
-
Hãy xem xét ví dụ về
tcpdump
sau đây.Mẫu
tcpdump
được lấy khi502 Bad Gateway Error
(UnexpectedEOFAtTarget
) xảy ra - Từ kết quả TCPDump, bạn nhận thấy chuỗi sự kiện sau đây:
- Trong gói
985
, Bộ xử lý thông báo gửi yêu cầu API đến máy chủ phụ trợ. - Trong gói
986
, máy chủ phụ trợ phản hồi ngay lập tức bằng[FIN,ACK]
. - Trong gói
987
, Trình xử lý thông báo sẽ phản hồi bằng[FIN,ACK]
tới máy chủ phụ trợ. - Cuối cùng, các kết nối sẽ bị đóng bằng
[ACK]
và[RST]
từ cả hai phía. - Vì máy chủ phụ trợ gửi
[FIN,ACK]
nên bạn sẽ nhận được ngoại lệjava.io.EOFException: eof unexpected
trên Trình xử lý thông báo.
- Trong gói
- Điều này có thể xảy ra nếu có sự cố mạng tại máy chủ phụ trợ. Hãy liên hệ với nhóm điều hành mạng của bạn để điều tra thêm về vấn đề này.
Độ phân giải
Khắc phục vấn đề trên máy chủ phụ trợ một cách phù hợp.
Nếu sự cố vẫn tiếp diễn và bạn cần được hỗ trợ khắc phục sự cố 502 Bad Gateway Error
hoặc bạn nghi ngờ đó là sự cố trong Edge, hãy liên hệ với Nhóm hỗ trợ Apigee.
Nguyên nhân: Thời gian chờ duy trì hoạt động không được định cấu hình chính xác
Trước khi bạn chẩn đoán xem đây có phải là nguyên nhân gây ra lỗi 502
hay không, vui lòng đọc qua các khái niệm sau.
Kết nối lâu dài trong Apigee
Theo mặc định, Apigee (và theo tiêu chuẩn HTTP/1.1) sử dụng các kết nối ổn định khi giao tiếp với máy chủ phụ trợ đích. Kết nối ổn định có thể tăng hiệu suất bằng cách cho phép sử dụng lại kết nối TCP/SSL và kết nối TLS/SSL (nếu có) đã thiết lập, giúp giảm chi phí độ trễ. Thời gian cần duy trì kết nối được kiểm soát thông qua thuộc tính giữ thời gian chờ hoạt động (keepalive.timeout.millis
).
Cả máy chủ phụ trợ và Trình xử lý thông báo Apigee đều sử dụng thời gian chờ hoạt động để duy trì các kết nối luôn mở với nhau. Sau khi không nhận được dữ liệu nào trong khoảng thời gian chờ duy trì hoạt động, máy chủ phụ trợ hoặc Trình xử lý thông báo có thể đóng kết nối với nhau.
Theo mặc định, các proxy API được triển khai cho Bộ xử lý thư trong Apigee được đặt thời gian chờ duy trì hoạt động là 60s
trừ phi bị ghi đè. Sau khi không nhận được dữ liệu nào của 60s
, Apigee sẽ đóng kết nối với máy chủ phụ trợ. Máy chủ phụ trợ cũng sẽ duy trì thời gian chờ duy trì hoạt động. Khi hết thời gian này, máy chủ phụ trợ sẽ đóng kết nối với Bộ xử lý thông báo.
Hệ quả của việc định cấu hình thời gian chờ duy trì hoạt động không chính xác
Nếu Apigee hoặc máy chủ phụ trợ được định cấu hình là thời gian chờ duy trì hoạt động không chính xác, thì điều này sẽ dẫn đến một tình huống tương tranh khiến máy chủ phụ trợ gửi một End Of File
(FIN)
không mong muốn để phản hồi yêu cầu về tài nguyên.
Ví dụ: nếu thời gian chờ duy trì hoạt động được định cấu hình trong Proxy API hoặc Trình xử lý thông báo có giá trị lớn hơn hoặc bằng thời gian chờ của máy chủ phụ trợ ngược dòng, thì tình huống tương tranh sau đây có thể xảy ra. Nghĩa là, nếu Trình xử lý thông báo không nhận được bất kỳ dữ liệu nào cho đến khi gần đến ngưỡng của máy chủ phụ trợ và duy trì thời gian chờ hoạt động, thì một yêu cầu sẽ đi qua và được gửi đến máy chủ phụ trợ bằng kết nối hiện có. Việc này có thể dẫn đến
502 Bad Gateway
do lỗi EOF không mong muốn như giải thích dưới đây:
- Giả sử thời gian chờ duy trì hoạt động được thiết lập trên cả Bộ xử lý thông báo và máy chủ phụ trợ là 60 giây và không có yêu cầu mới nào đến sau 59 giây kể từ khi yêu cầu trước đó được Trình xử lý thông báo cụ thể phân phát.
- Bộ xử lý thông báo sẽ tiếp tục và xử lý yêu cầu đến ở giây thứ 59 bằng kết nối hiện có (vì thời gian chờ duy trì hoạt động chưa hết) rồi gửi yêu cầu đến máy chủ phụ trợ.
- Tuy nhiên, trước khi yêu cầu đến máy chủ phụ trợ, ngưỡng thời gian chờ duy trì đã vượt quá trên máy chủ phụ trợ.
- Yêu cầu của Trình xử lý thông báo về tài nguyên đang diễn ra nhưng máy chủ phụ trợ cố gắng đóng kết nối bằng cách gửi gói
FIN
đến Bộ xử lý thông báo. - Trong khi chờ nhận dữ liệu, Trình xử lý thông báo lại nhận được
FIN
không mong muốn và kết nối bị chấm dứt. - Việc này dẫn đến một
Unexpected EOF
, sau đó là một502
được Bộ xử lý thông báo trả về cho ứng dụng khách.
Trong trường hợp này, chúng tôi quan sát thấy lỗi 502
xảy ra vì bạn định cấu hình cùng một giá trị thời gian chờ hoạt động là 60 giây trên cả Bộ xử lý thông báo và máy chủ phụ trợ. Tương tự, vấn đề này cũng có thể xảy ra nếu một giá trị được định cấu hình để duy trì thời gian chờ hoạt động trên Bộ xử lý thông báo cao hơn so với trên máy chủ phụ trợ.
Chẩn đoán
- Nếu bạn là người dùng Đám mây công cộng:
- Sử dụng công cụ Giám sát hoặc Theo dõi API (như giải thích trong phần Các bước chẩn đoán phổ biến) và xác minh rằng bạn có cả hai chế độ cài đặt sau:
- Mã lỗi:
messaging.adaptors.http.flow.UnexpectedEOFAtTarget
- Nguồn lỗi:
target
- Mã lỗi:
- Hãy chuyển đến phần Sử dụng tcpdump để tìm hiểu thêm.
- Sử dụng công cụ Giám sát hoặc Theo dõi API (như giải thích trong phần Các bước chẩn đoán phổ biến) và xác minh rằng bạn có cả hai chế độ cài đặt sau:
- Nếu bạn là người dùng Đám mây riêng tư:
- Sử dụng Công cụ theo dõi hoặc nhật ký truy cập NGINX để xác định mã nhận dạng thông báo, mã lỗi và nguồn lỗi cho lỗi
502
. - Tìm mã nhận dạng thư trong nhật ký Trình xử lý thư
(/opt/apigee/var/log/edge-message-processor/logs/system.log
). - Bạn sẽ thấy
java.io.EOFEXception: eof unexpected
như hình bên dưới:2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1 NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms lastIO=479ms isOpen=true.onExceptionRead exception: {} java.io.EOFException: eof unexpected at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80) at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)
- Lỗi
java.io.EOFException: eof unexpected
cho biết Trình xử lý thông báo đã nhận đượcEOF
trong khi vẫn đang chờ đọc phản hồi từ máy chủ phụ trợ. - Thuộc tính
useCount=7
trong thông báo lỗi ở trên cho biết Trình xử lý thông báo đã sử dụng lại kết nối này khoảng 7 lần và thuộc tínhbytesWritten=159
cho biết rằng Trình xử lý thông báo đã gửi tải trọng yêu cầu159
byte đến máy chủ phụ trợ. Tuy nhiên, hệ thống này lại nhận được 0 byte khi xảy raEOF
không mong muốn. -
Điều này cho thấy Trình xử lý thông báo đã nhiều lần sử dụng lại cùng một kết nối, và trong trường hợp này, Trình xử lý thông báo đã gửi dữ liệu nhưng ngay sau đó lại nhận được một
EOF
trước khi nhận được dữ liệu. Việc này có khả năng cao sẽ xảy ra trường hợp thời gian chờ duy trì hoạt động của máy chủ phụ trợ sẽ ngắn hơn hoặc bằng thời gian chờ đặt trong proxy API.Bạn có thể tìm hiểu thêm với sự trợ giúp của
tcpdump
như giải thích bên dưới.
- Sử dụng Công cụ theo dõi hoặc nhật ký truy cập NGINX để xác định mã nhận dạng thông báo, mã lỗi và nguồn lỗi cho lỗi
Sử dụng tcpdump
- Ghi lại
tcpdump
trên máy chủ phụ trợ bằng lệnh sau:tcpdump -i any -s 0 host MP_IP_Address -w File_Name
- Phân tích
tcpdump
đã chụp:Dưới đây là kết quả tcpdump mẫu:
Trong mẫu
tcpdump
ở trên, bạn có thể thấy những nội dung sau:- Trong gói
5992,
, máy chủ phụ trợ đã nhận được một yêu cầuGET
. - Trong gói
6064
, gói này phản hồi bằng200 OK.
- Trong gói
6084
, máy chủ phụ trợ đã nhận được một yêu cầuGET
khác. - Trong gói
6154
, nó phản hồi bằng200 OK
. - Trong gói
6228
, máy chủ phụ trợ đã nhận được yêu cầuGET
thứ ba. - Lần này, máy chủ phụ trợ trả về một
FIN, ACK
cho Bộ xử lý thông báo (gói6285
) để bắt đầu đóng kết nối.
Cùng một kết nối đã được sử dụng lại hai lần thành công trong ví dụ này. Tuy nhiên, ở yêu cầu thứ ba, máy chủ phụ trợ sẽ bắt đầu đóng kết nối, còn Trình xử lý thông báo đang chờ dữ liệu từ máy chủ phụ trợ. Điều này cho thấy rằng thời gian chờ duy trì hoạt động của máy chủ phụ trợ rất có thể ngắn hoặc bằng với giá trị đã đặt trong proxy API. Để xác thực thông tin này, hãy xem phần So sánh thời gian chờ hoạt động trên ứng dụng Apigee và máy chủ phụ trợ.
- Trong gói
So sánh thời gian chờ hoạt động trên ứng dụng Apigee và máy chủ phụ trợ
- Theo mặc định, Apigee sử dụng giá trị 60 giây cho thuộc tính giữ thời gian chờ hoạt động.
-
Tuy nhiên, có thể bạn đã ghi đè giá trị mặc định trong Proxy API. Bạn có thể xác minh điều này bằng cách kiểm tra định nghĩa
TargetEndpoint
cụ thể trong Proxy API không thành công đang gây ra lỗi502
.Cấu hình TargetEndpoint mẫu:
<TargetEndpoint name="default"> <HTTPTargetConnection> <URL>https://mocktarget.apigee.net/json</URL> <Properties> <Property name="keepalive.timeout.millis">30000</Property> </Properties> </HTTPTargetConnection> </TargetEndpoint>
Trong ví dụ trên, thuộc tính thời gian chờ duy trì hoạt động sẽ bị ghi đè bằng giá trị 30 giây (
30000
mili giây). - Tiếp theo, hãy kiểm tra thuộc tính duy trì thời gian chờ hoạt động được định cấu hình trên máy chủ phụ trợ của bạn. Giả sử máy chủ phụ trợ của bạn được định cấu hình với giá trị là
25 seconds
. - Nếu bạn xác định rằng giá trị của thuộc tính thời gian chờ duy trì hoạt động trên Apigee cao hơn giá trị của thuộc tính thời gian chờ duy trì hoạt động trên máy chủ phụ trợ như trong ví dụ trên, thì đó chính là nguyên nhân gây ra lỗi
502
.
Độ phân giải
Đảm bảo rằng thuộc tính thời gian chờ duy trì hoạt động luôn thấp hơn trên Apigee (trong thành phần Proxy API và Bộ xử lý thông báo) so với thuộc tính trên máy chủ phụ trợ.
- Xác định giá trị đã đặt cho thời gian chờ duy trì hoạt động trên máy chủ phụ trợ.
- Định cấu hình giá trị thích hợp cho thuộc tính thời gian chờ hoạt động trong Proxy API hoặc Trình xử lý thông báo, sao cho thuộc tính thời gian chờ duy trì hoạt động thấp hơn giá trị đặt trên máy chủ phụ trợ, bằng cách thực hiện các bước được mô tả trong bài viết Định cấu hình thời gian chờ hoạt động trên Bộ xử lý thông báo.
Nếu vấn đề vẫn tiếp diễn, hãy chuyển đến phần Phải thu thập thông tin chẩn đoán.
Phương pháp hay nhất
Bạn nên lưu ý rằng các thành phần ở hạ nguồn luôn có ngưỡng thời gian chờ duy trì hoạt động thấp hơn so với đã định cấu hình trên các máy chủ tải lên để tránh các loại điều kiện tranh đấu và lỗi 502
này. Mỗi hop xuôi dòng phải thấp hơn mỗi hop ngược dòng. Trong Apigee, bạn nên sử dụng các nguyên tắc sau:
- Thời gian chờ hoạt động của ứng dụng phải nhỏ hơn thời gian chờ hoạt động của Bộ định tuyến cạnh.
- Thời gian chờ hoạt động của Bộ định tuyến cạnh phải nhỏ hơn thời gian chờ hoạt động của Bộ xử lý thông báo.
- Bộ xử lý thư duy trì thời gian chờ hoạt động phải nhỏ hơn thời gian chờ hoạt động của máy chủ đích.
- Nếu có bất kỳ bước nhảy nào khác đứng trước hoặc phía sau Apigee, bạn nên áp dụng cùng một quy tắc. Bạn phải luôn để ứng dụng ở hạ nguồn thực hiện trách nhiệm đóng kết nối với ứng dụng ngược dòng.
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 hướng dẫn ở trên, hãy thu thập thông tin chẩn đoán sau đây rồi liên hệ với Nhóm hỗ trợ Apigee.
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 tất lệnh
curl
để tái tạo lỗi502
- Tệp theo dõi chứa các yêu cầu có lỗi
502 Bad Gateway - Unexpected EOF
- Nếu lỗi
502
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ỗi502
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 gặp phải
lỗi
502
- Gói Proxy API
- Tệp theo dõi chứa các yêu cầu có lỗi
502 Bad Gateway - Unexpected EOF
- Nhật ký truy cập NGINX
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Nhật ký đơn vị 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
502
lỗi xảy ra Tcpdumps
được thu thập trên Bộ xử lý thông báo hoặc máy chủ phụ trợ hoặc cả hai khi xảy ra lỗi