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 lỗi 502 Bad Gateway. Bộ xử lý thông báo sẽ trả về lỗi này cho ứng dụng khách khi không nhận được phản hồi từ máy chủ phụ trợ.
Thông báo lỗi
Ứng dụng sẽ 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":"Bad Gateway",
"detail":{
"errorcode":"messaging.adaptors.http.flow.BadGateway"
}
}
}
Nguyên nhân có thể xảy ra
Nguyên nhân có thể dẫn đến vấn đề này được liệt kê trong bảng sau:
| Nguyên nhân | Mô tả | Bạn có thể thực hiện các bước khắc phục sự cố bằng |
| Hết thời gian chờ bắt tay TLS/SSL | Hết thời gian chờ trong quá trình giao tiếp qua TLS/SSL giữa Bộ xử lý thông báo và máy chủ phụ trợ. | Người dùng Edge về dịch vụ đám mây riêng tư và công khai |
Nguyên nhân: Hết thời gian chờ bắt tay TLS/SSL
Trong Apigee Edge, bạn có thể thiết lập kết nối TLS/SSL với máy chủ phụ trợ để cho phép giao tiếp TLS giữa Trình xử lý thông báo Edge và một máy chủ phụ trợ.
Quá trình bắt tay TLS/SSL bao gồm nhiều bước. Lỗi này thường xảy ra khi quá trình bắt tay TLS/SSL giữa Bộ xử lý thông báo và một máy chủ phụ trợ đã hết thời gian chờ.
Chẩn đoán
Phần này giải thích cách chẩn đoán chính xác thời gian chờ bắt tay TLS/SSL. Hướng dẫn dành cho Đám mây riêng tư và Đám mây công khai của Edge có trong danh sách.
Kiểm tra đầu ra phiên Theo dõi
Các bước sau đây giải thích cách chẩn đoán sơ bộ sự cố bằng công cụ Apigee Edge Trace.
- Trong giao diện người dùng Edge, hãy bật Trace session (Phiên theo dõi) cho proxy 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ư sau, thì có thể đã xảy ra lỗi hết thời gian chờ bắt tay TLS/SSL. Nguyên nhân có thể gây ra lỗi là do tường lửa của máy chủ phụ trợ đang chặn lưu lượng truy cập từ Apigee.
- Xác định xem lỗi 502 Bad Gateway (Cổng vào không hợp lệ) có xảy ra sau 55 giây hay không. Đây là khoảng thời gian chờ mặc định được đặt trên Trình xử lý thông báo. Nếu bạn thấy lỗi xảy ra sau 55 giây, thì điều này cho bạn biết rằng thời gian chờ có thể là nguyên nhân gây ra sự cố.
- Xác định xem lỗi có xuất hiện lỗi hay không: messaging.adaptors.http.BadGateway. Xin nhắc lại, lỗi này thường cho biết đã hết thời gian chờ.
Nếu bạn đang sử dụng Edge Private Cloud, hãy lưu ý giá trị của trường X-Apigee.Message-ID trong kết quả theo dõi như minh hoạ bên dưới. Người dùng Private Cloud có thể sử dụng giá trị mã nhận dạng này để tiếp tục khắc phục sự cố, như sẽ giải thích ở phần sau.
Nhấp vào biểu tượng Dữ liệu Analytics đã ghi trong đường dẫn theo dõi:
Di chuyển xuống rồi để ý giá trị của trường có tên X-Apigee.Message-ID.
Để xác nhận rằng thời gian chờ giao tiếp qua TLS/SSL là nguyên nhân gây ra lỗi, hãy làm theo các bước trong những phần dưới đây, tuỳ thuộc vào việc bạn đang sử dụng Đám mây công cộng hay Đám mây riêng tư.
Các bước chẩn đoán bổ sung chỉ dành cho người dùng Edge Private Cloud
Nếu đang sử dụng Apigee Edge Private Cloud, bạn có thể thực hiện các bước sau để xác minh nguyên nhân gây ra lỗi bắt tay. Ở bước này, bạn kiểm tra tệp nhật ký của Trình xử lý thư để biết thông tin liên quan. Nếu đang sử dụng Edge Public Cloud, bạn có thể bỏ qua phần này và chuyển đến phần Các bước chẩn đoán khác dành cho người dùng đám mây riêng và công khai.
Kiểm tra xem bạn có thể kết nối trực tiếp với máy chủ phụ trợ cụ thể từ mỗi Bộ xử lý thông báo bằng lệnh
telnethay không:Nếu máy chủ phụ trợ phân giải thành một địa chỉ IP duy nhất, hãy sử dụng lệnh sau:
telnet BackendServer-IPaddress 443
Nếu máy chủ phụ trợ phân giải thành nhiều địa chỉ IP, hãy sử dụng tên máy chủ của máy chủ phụ trợ trong lệnh telnet như minh hoạ dưới đây:
telnet BackendServer-HostName 443
Nếu bạn có thể kết nối với máy chủ phụ trợ mà không gặp phải lỗi nào, hãy chuyển sang bước tiếp theo.
Nếu lệnh
telnetkhông thành công, bạn cần làm việc với nhóm mạng để kiểm tra kết nối giữa trình xử lý thông báo và máy chủ phụ trợ.Kiểm tra tệp nhật ký của Bộ xử lý thư để xem bằng chứng về lỗi bắt tay. Mở tệp:
/opt/apigee/var/log/edge-message-processor/system.logvà tìm kiếm mã nhận dạng thông báo duy nhất (giá trị của X-Apigee.Message-ID mà bạn tìm thấy trong tệp theo dõi). Xác định xem bạn có thấy thông báo lỗi bắt tay liên kết với mã nhận dạng thông báo như minh hoạ bên dưới hay không:
org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443 Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms isOpen=true handshake timeout
Nếu bạn thấy lỗi này trong tệp nhật ký của trình xử lý thư, hãy tiếp tục tìm hiểu thêm. Chuyển đến phần Các bước chẩn đoán khác dành cho người dùng Edge riêng tư và công khai trên Đám mây.
Nếu bạn không thấy thông báo bắt tay trong tệp nhật ký, hãy chuyển đến phần Phải thu thập thông tin chẩn đoán
Các bước chẩn đoán khác dành cho người dùng Edge riêng tư và công khai trên Đám mây công cộng
Để xác định chính xác hơn vấn đề, bạn có thể dùng công cụ tcpdump để phân tích các gói TCP/IP nhằm xác nhận xem có hết thời gian chờ trong quá trình bắt tay TLS/SSL hay không.
- Nếu là người dùng Đám mây riêng tư, bạn có thể thu thập các gói TCP/IP trên máy chủ phụ trợ hoặc Bộ xử lý thông báo. Bạn nên ghi lại trên máy chủ phụ trợ vì các gói đã được giải mã trên máy chủ phụ trợ.
- Nếu là người dùng Đám mây công cộng, bạn không có quyền truy cập vào Bộ xử lý thông báo. Tuy nhiên, việc thu thập các gói TCP/IP trên máy chủ phụ trợ có thể giúp xác định sự cố.
Sau khi quyết định vị trí thu thập các gói TCP/IP, hãy sử dụng lệnh tcpdump sau đây để thu thập các gói TCP/IP.
tcpdump -i any -s 0 host <IP address> -w <File name>Nếu bạn đang lấy các gói TCP/IP trên máy chủ phụ trợ, hãy sử dụng địa chỉ IP công khai của Trình xử lý thông báo trong lệnh
tcpdump. Để được trợ giúp về việc sử dụng lệnh này nhằm kiểm tra lưu lượng truy cập của máy chủ phụ trợ, hãy xem phần tcpdump.Nếu bạn đang lấy các gói TCP/IP trên Bộ xử lý thông báo, hãy sử dụng địa chỉ IP công khai của máy chủ phụ trợ trong lệnh
tcpdump. Để được trợ giúp sử dụng lệnh kiểm tra lưu lượng truy cập của Trình xử lý thông báo, hãy xem phần tcpdump.Nếu có nhiều địa chỉ IP cho máy chủ phụ trợ/Bộ xử lý thư, bạn cần thử sử dụng lệnh
tcpdumpkhác. Hãy tham khảo tcpdump để biết thêm thông tin về công cụ này và để biết các biến thể khác của lệnh này.
Phân tích các gói TCP/IP bằng công cụ Wireshark hoặc công cụ tương tự. Ảnh chụp màn hình dưới đây cho thấy các gói TCP/IP trong Wireshark.
Lưu ý trong đầu ra Wireshark, giao thức bắt tay ba chiều của TCP đã hoàn tất thành công trong 3 gói đầu tiên.
Sau đó, Bộ xử lý thông báo sẽ gửi thông báo "Client Hello" (Xin chào ứng dụng khách) trong gói số 4.
Do không có xác nhận từ máy chủ phụ trợ nên Bộ xử lý thông báo sẽ truyền lại thông báo "Client Hello" nhiều lần trong các gói 5, 6 và 7 sau khi chờ một khoảng thời gian xác định trước.
Khi không nhận được thông báo xác nhận nào sau 3 lần thử lại, Trình xử lý thông báo sẽ gửi thông báo FIN, ACK đến máy chủ phụ trợ để cho biết đang đóng kết nối.
Như bạn thấy trong phiên Wireshark ví dụ, kết nối với phần phụ trợ đã thành công (bước #1). Tuy nhiên, giao thức bắt tay SSL đã hết thời gian chờ vì máy chủ phụ trợ không bao giờ phản hồi.
Nếu bạn đã thực hiện các bước khắc phục sự cố trong cẩm nang này và xác định rằng thời gian chờ gây ra lỗi bắt tay TLS/SSL, hãy chuyển đến phần Resolution (Giải pháp).
Sử dụng tính năng Giám sát API để xác định vấn đề
Giám sát API giúp bạn nhanh chóng tách biệt các khu vực có sự cố để chẩn đoán lỗi, hiệu suất và các vấn đề về độ trễ cũng như các vấn đề về nguồ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.
Tìm hiểu một 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 lỗi messaging.adaptors.http.BadGateway vượt quá một ngưỡng cụ thể.
Độ phân giải
Thường thì thời gian chờ bắt tay SSL xảy ra do các hạn chế do tường lửa trên máy chủ phụ trợ chặn, khiến lưu lượng truy cập từ Apigee Edge. Nếu đã làm theo các bước chẩn đoán và xác định rằng nguyên nhân gây ra lỗi bắt tay là hết thời gian chờ, bạn cần liên hệ với nhóm mạng của mình để xác định nguyên nhân và khắc phục các quy tắc hạn chế đối với tường lửa.
Lưu ý rằng các hạn chế tường lửa có thể được áp đặt ở các lớp mạng khác nhau. Điều quan trọng là phải đảm bảo xoá bỏ các hạn chế ở tất cả lớp mạng liên quan đến IP của Trình xử lý thông báo để đảm bảo lưu lượng truy cập giữa Apigee Edge và máy chủ phụ trợ diễn ra suôn sẻ.
Nếu không có hạn chế nào về tường lửa và/hoặc 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ả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ẻ thông tin 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 hiện lỗi
- Tệp theo dõi cho thấy lỗi
- Gói TCP/IP được thu thập trên máy chủ phụ trợ
- 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
- Gói Proxy API
- Tệp theo dõi cho thấy lỗi
- Nhật ký của Trình xử lý thông báo /opt/apigee/var/log/edge-message-processor/logs/system.log
- Gói TCP/IP được ghi trên máy chủ phụ trợ hoặc Bộ xử lý thông báo.
- Thông tin chi tiết về những phần trong Cẩm nang mà bạn đã thử và mọi thông tin chi tiết khác sẽ giúp chúng tôi nhanh chóng giải quyết vấn đề này.