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 lỗi 502 Cổng vào bị lỗi. Message Processor (Trình xử lý thông báo) 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ê những 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 |
| Thời gian chờ bắt tay TLS/SSL | Đã xảy ra hết thời gian chờ 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 Cloud và Public Cloud |
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ợ để 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ộ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 cho Edge Private Cloud và Public Cloud được liệt kê.
Khám phá đầu ra 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ụ Dấu vết Apigee Edge.
- Trong giao diện người dùng Edge, hãy bật Phiên gỡ lỗi cho API proxy 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 thông tin 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 máy chủ phụ trợ đang chặn lưu lượng truy cập từ Apigee.
- Xác định xem lỗi 502 Cổng vào bị lỗi 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ý tin nhắn. Nếu bạn thấy lỗi xảy ra sau 55 giây, thì điều này cho biết 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. Lỗi này thường cho biết đã xảy ra tình trạng 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 đầu ra dấu vết như minh hoạ bên dưới. Người dùng Đám mây riêng 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 sau.
Nhấp vào biểu tượng Analytics Data Recorded (Đã ghi lại dữ liệu phân tích) trong đường dẫn theo dõi:
Di chuyển xuống dưới và ghi lại giá trị của trường có tên là X-Apigee.Message-ID.
Để xác nhận rằng TLS/SSL Handshake timeout 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 đâ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ý Message Processor để tìm thông tin liên quan. Nếu đang sử dụng Đám mây công cộng Edge, 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 cho người dùng Đám mây riêng tư và Đám mây công cộng.
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 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, 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ý Message Processor (Trình xử lý thông báo) để 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 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 dấu vết). 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ư như minh hoạ 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. 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 tư và công khai của Edge.
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 Thông tin chẩn đoán cần thu thập
Các bước chẩn đoán khác dành cho người dùng Đám mây riêng tư và Đám mây công cộng của Edge
Để xác định chính xác hơn 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ó xảy ra 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, bạn có thể thu thập các gói TCP/IP trên máy chủ phụ trợ hoặc Trình xử lý thông báo. Tốt nhất là bạn nên ghi lại các gói này trên máy chủ phụ trợ, vì các gói này được giải mã trên máy chủ phụ trợ.
- Nếu là người dùng Đám mây công khai, bạn sẽ không có quyền truy cập vào Message Processor (Bộ 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 các gói TCP/IP, hãy 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ề cách sử dụng lệnh này để kiểm tra lưu lượng truy cập 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 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 sử dụng lệnh này nhằm 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ử một cách 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à 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 đầu ra Wireshark, rằng quy trình bắt tay TCP 3 chiều hoàn tất thành công trong 3 gói đầu tiên.
Sau đó, Trình xử lý thông báo sẽ gửi thông báo "Client Hello" trong gói số 4.
Vì không có thông báo xác nhận từ máy chủ phụ trợ, nên MessageProcessor 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 đợi một khoảng thời gian xác định trước.
Khi Message Processor không nhận được bất kỳ thông báo xác nhận nào sau 3 lần thử lại, nó sẽ gửi thông báo FIN, ACK đến máy chủ phụ trợ để cho biết rằng nó đang đóng kết nối.
Như bạn đã cho 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, quá trình 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ổ tay này và xác định rằng hết thời gian chờ là nguyên nhân 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 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à 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 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 kịch bản 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ể muốn thiết lập một cảnh báo để nhận thông báo khi số 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 rằng nguyên nhân gây ra lỗi bắt tay là do 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 hạn chế của tường lửa.
Xin lưu ý rằng các quy định hạn chế của tường lửa có thể được áp dụng ở nhiều lớp mạng. Bạn cần đảm bảo rằng các hạn chế ở tất cả các lớp mạng đã được xoá 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ó 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 Thông tin chẩn đoán cần thu thập.
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 bạn làm theo hướng dẫn ở trên, vui lòng thu thập thông tin chẩn đoán sau đây. Liên hệ và chia sẻ các thông tin đó với Nhóm hỗ trợ Apigee Edge:
- Nếu bạn là người dùng Đám mây 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 tạo lỗi
- Tệp theo dõi cho thấy lỗi
- Các 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:
- Thông báo lỗi hoàn chỉnh đã quan sát được
- Gói API Proxy
- Tệp theo dõi cho thấy lỗi
- Nhật ký Trình xử lý thông báo /opt/apigee/var/log/edge-message-processor/logs/system.log
- Các gói TCP/IP được thu thập 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 Sổ tay này mà bạn đã thử và mọi thông tin chi tiết khác sẽ giúp chúng tôi đẩy nhanh quá trình giải quyết vấn đề này.