502 Lỗi thời gian chờ cổng vào không hợp lệ

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 gặp lỗi 502 Bad Gateway (Cổng kết nố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ể 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

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 Thời gian chờ xảy ra trong quá trình bắt tay TLS/SSL giữa Trình xử lý thư 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ờ 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á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. Dưới đây là hướng dẫn về Edge Private Cloud và Public Cloud.

Kiểm 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.

  1. 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.

  2. 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.

    1. Xác định xem lỗi 502 Bad Gateway có xảy ra sau 55 giây hay không. là khoảng thời gian chờ mặc định được thiết lập trên Trình xử lý thư. Nếu bạn thấy rằng lỗi xảy ra sau 55 giây, điều này cho bạn biết rằng thời gian chờ là có thể là nguyên nhân gây ra sự cố.
    2. 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ờ.

    3. 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ư dưới đây. 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.

      1. 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:

      2. 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ư để biết thông tin có 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 dịch vụ đám mây riêng tư và công khai.

  1. 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 telnet hay không:

    1. 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

    2. 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 lỗi nào, hãy chuyển sang bước tiếp theo.

    Nếu lệnh telnet khô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ợ.

  2. 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.log

    và tìm kiếm mã nhận dạng thư duy nhất (giá trị của X-Apigee.Message-ID mà bạn 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. Chuyển đến phần Các bước chẩn đoán khác dành cho người dùng Edge Private và Public Cloud.

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 cho người dùng Edge Private và Public Cloud

Để 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ó hết thời gian chờ trong quá trình bắt tay TLS/SSL hay không.

  1. 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. 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 được giải mã trên máy chủ phụ trợ.
  2. 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 Thông báo này Bộ xử lý; tuy nhiên, việc chụp lại các gói TCP/IP trên máy chủ phụ trợ có thể giúp xác định vấn đề.

  3. 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 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 sử dụng để 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 nhận gói TCP/IP trên Trình xử lý thông báo, hãy sử dụng Địa chỉ IP 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ư, thì bạn cần thử một cách sử dụng lệnh tcpdump khác. Hãy tham khảo tcpdump để biết thêm thông tin về công cụ này và cho các biến thể khác của lệnh này.

  4. 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 hiển thị gói TCP/IP trong Wireshark.

  5. 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.

  6. Sau đó, Trình xử lý thông báo sẽ gửi thông báo "Xin chào khách hàng" thông báo trong gói số 4.

  7. Do máy chủ phụ trợ không xác nhận, nên Thông báo Bộ xử lý truyền lại thông báo "Client Hello" thông báo nhiều lần trong gói tin 5, 6 và 7 sau khi đợi một khoảng thời gian xác định trước.

  8. Khi Trình xử lý thông báo 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ý này 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.

  9. 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 cẩm nang này và xác định rằng gây ra lỗi bắt tay TLS/SSL, hãy chuyển đến phần Giải pháp.

Sử dụng chức 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.

Tìm hiểu một tình huống mẫu minh hoạ cách khắc phục sự cố 5xx với API của bạn bằng cách sử dụng Giám sát 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 Các 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 bạn đã theo dõi 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 để xác định nguyên nhân và khắc phục 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. Cần phải đảm bảo xoá bỏ các hạn chế ở tất cả các lớp mạng liên quan đến vào IP của Trình xử lý tin nhắn để đảm bảo lưu lượng truy cập thông suốt 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ẻ thông tin đó với Bộ phận hỗ trợ Apigee Edge:

  1. 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:
    1. Tên tổ chức
    2. Tên môi trường
    3. Tên proxy API
    4. Hoàn tất lệnh curl để tái hiện lỗi
    5. Tệp theo dõi cho thấy lỗi
    6. Các gói TCP/IP được ghi lại trên máy chủ phụ trợ
  2. Nếu bạn là người dùng Google Cloud Private, hãy cung cấp những thông tin sau:
    1. Đã phát hiện thấy thông báo lỗi hoàn chỉnh
    2. Gói Proxy API
    3. Tệp theo dõi cho thấy lỗi
    4. Nhật ký Bộ xử lý thư /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. 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.
  3. 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.