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 lỗi 502 Bad Gateway (502 Cổng vào nhận phản hồi không hợp lệ). Trình 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 khách nhận được mã phản hồi sau:
HTTP/1.1 502 Bad Gateway
Ngoài ra, bạn có thể 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
Bảng sau đây liệt kê các nguyên nhân có thể gây ra vấn đề này:
| Nguyên nhân | Nội dung mô tả | Bạn có thể thực hiện các bước khắc phục sự cố bằng cách |
| Hết thời gian chờ bắt tay TLS/SSL | Hết thời gian chờ xảy ra trong quá trình bắt tay TLS/SSL giữa Trình xử lý thông báo và máy chủ phụ trợ. | Người dùng Edge Private và Edge Public Cloud |
Nguyên nhân: Hết thời gian chờ cơ 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ợ để bật giao tiếp TLS giữa Trình xử lý thông báo Edge và 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 Trình xử lý thông báo và 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 cho Edge Private Cloud và Public Cloud được liệt kê.
Điều tra kết quả của phiên theo dõi
Các bước sau đây giải thích cách chẩn đoán sơ bộ vấn đề bằng công cụ Theo dõi cạnh Apigee.
- Trong giao diện người dùng Edge, hãy bật Phiên theo dõi cho proxy API bị ảnh hưởng.
Nếu dấu vết cho yêu cầu API không thành công cho thấy nội dung 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 này là 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 (Lỗi cổng vào nhận phản hồi 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ì tức là hết thời gian chờ là nguyên nhân có thể gây ra vấn đề.
- Xác định xem lỗi có cho thấy lỗi: messaging.adaptors.http.BadGateway hay không. 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 để khắc phục sự cố thêm, như giải thích ở phần sau.
Nhấp vào biểu tượng Analytics Data Recorded (Đã ghi lại dữ liệu của Analytics) trong đường dẫn theo dõi:
Di chuyển xuống rồi ghi lại giá trị của trường có tên X-Apigee.Message-ID.
Để xác nhận rằng thời gian chờ bắt tay TLS/SSL là nguyên nhân gây ra lỗi, hãy làm theo các bước trong các phần sau, tuỳ thuộc vào việc bạn đang sử dụng Cloud Public hay Cloud Private.
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 dịch vụ đám mây riêng tư của Apigee Edge, 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ông báo để 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 Cloud Private và Cloud Public.
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ừ từng Trình 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ạ bên dưới:
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 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 khả năng 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ý Trình xử lý thư để tìm bằng chứng về lỗi bắt tay. Mở tệp:
/opt/apigee/var/log/edge-message-processor/system.logvà tìm mã 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ã thông báo như dưới đây 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ông báo, hãy tiếp tục điều tra thêm. Hãy chuyển đến phần Các bước chẩn đoán khác dành cho người dùng Edge trên đám mây công khai và riêng tư.
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 Cloud công khai và riêng tư
Để xác định chính xác hơn về vấn đề, bạn có thể sử 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 Private Cloud, bạn có thể ghi lại các gói TCP/IP trên máy chủ phụ trợ hoặc Trình xử lý thông báo. Bạn nên thu thập các gó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 Google Cloud công khai, bạn sẽ không có quyền truy cập vào Trình xử lý thông báo; tuy nhiên, việc ghi lại các gói TCP/IP trên máy chủ phụ trợ có thể giúp xác định chính xác vấn đề.
Sau khi quyết định vị trí thu thập gói TCP/IP, hãy sử dụng lệnh tcpdump sau đây để thu thập gói TCP/IP.
tcpdump -i any -s 0 host <IP address> -w <File name>Nếu bạn đang nhận 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ề cách sử dụng lệnh này để kiểm tra lưu lượng truy cập của máy chủ phụ trợ, hãy xem tcpdump.Nếu bạn đang lấy các gói TCP/IP trên Trình 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 về cách 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 tcpdump.Nếu có nhiều địa chỉ IP cho máy chủ phụ trợ/Trình xử lý thông báo, thì bạn cần thử sử dụng một lệnh
tcpdumpkhác. Hãy tham khảo tcpdump để biết thêm thông tin về công cụ này và 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 một công cụ tương tự. Ảnh chụp màn hình sau đây cho thấy các gói TCP/IP trong Wireshark.
Lưu ý trong kết quả của Wireshark, quy trình bắt tay TCP ba chiều đã hoàn tất thành công trong 3 gói đầu tiên.
Sau đó, Bộ xử lý thông báo gửi thông báo "Xin chào Khách hàng" trong gói số 4.
Do không có xác nhận từ máy chủ phụ trợ, nên Trình xử lý thông báo sẽ truyền lại thông báo "Xin chào ứng dụng khách" 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 rằng trình xử lý này đang đóng kết nối.
Như bạn đã thấy trong phiên Wireshark mẫu, kết nối với phần phụ trợ đã thành công (bước 1), tuy nhiên, 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 sách hướng dẫn này và xác định rằng lỗi thời gian chờ đã gây ra lỗi bắt tay TLS/SSL, hãy chuyển đến phần Giải pháp.
Sử dụng tính năng Giám sát API để xác định vấn đề
Tính năng Theo dõi API cho phép bạn nhanh chóng tách riêng 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 gốc 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.
Tiến hành theo 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 Theo dõi 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 lỗi messaging.adaptors.http.BadGateway vượt quá một ngưỡng cụ thể.
Độ phân giải
Thông thường, thời gian chờ bắt tay SSL xảy ra do các quy định hạn chế của tường lửa trên máy chủ phụ trợ chặ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 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 để xác định nguyên nhân và khắc phục các quy định hạn chế của tường lửa.
Lưu ý rằng các hạn chế về 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 rằng bạn đã xoá các quy định hạn chế ở tất cả cá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 diễn ra suôn sẻ giữa Apigee Edge và máy chủ phụ trợ.
Nếu không có quy định 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 vấn đề vẫn tiếp diễn ngay cả sau khi làm theo hướng dẫn ở trên, vui lòng thu thập thông tin chẩn đoán sau. Hãy liên hệ và chia sẻ các tệp đó với Nhóm hỗ trợ Apigee Edge:
- Nếu bạn là người dùng Google Cloud công khai, 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
- Các gói TCP/IP được ghi lại trên máy chủ phụ trợ
- Nếu bạn là người dùng Google Cloud Private, hãy cung cấp những thông tin sau:
- Đã quan sát 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ý Trình xử lý thư /opt/apigee/var/log/edge-message-processor/logs/system.log
- Các gói TCP/IP được ghi lại trên máy chủ phụ trợ hoặc Trình xử lý thông báo.
- Thông tin chi tiết về những phần trong Playbook này 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.