502 Cổng kết nối bị lỗi EOF không mong muốn

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à:

  1. Chuyển đến trang tổng quan Điều tra.
  2. 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.
  3. 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.
  4. Ở 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:
  5. Tại đây, chúng ta có thể xem những thông tin sau:

    • Nguồn lỗitarget
    • Mã lỗimessaging.adaptors.http.UnexpectedEOFAtTarget

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

    alt_text

    alt_text

  5. Xác định giá trị của X-Apigee.fault-sourceX-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-sourceX-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ỗi 502 để 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:

  1. Kiểm tra nhật ký truy cập NGINX.
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  2. 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ới 502.
  3. 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ửi Unexpected EOF hay không. Nếu giá trị của X-Apigee.fault-sourceX- Apigee.fault-code khớp với các giá trị hiển thị trong bảng dưới đây, thì lỗi 502 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

  1. 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.
  2. Bật tính năng theo dõi trong giao diện người dùng cho API bị ảnh hưởng.
  3. 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:
    1. Lỗi 502 Bad Gateway xuất hiện ngay khi yêu cầu luồng mục tiêu bắt đầu.
    2. error.class cho thấy messaging.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.

  4. Lấy định nghĩa máy chủ mục tiêu bằng lệnh gọi API Quản lý Edge:
    1. 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>
      
    2. 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 >
      
  5. Đị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ổng 443. 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ỗi UnexpectedEOFAtTarget trên Bộ xử lý thư. Bộ xử lý thông báo sẽ gửi 502 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.

  1. 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:
    1. Bạn cần bật TLS/SSL trong định nghĩa TargetServer, hãy thêm các thuộc tính SSLInfo, 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>
      
    2. 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>
      
  2. Nếu dịch vụ phụ trợ yêu cầu giao tiếp SSL hai chiều, hãy làm như sau:
    1. Bạn cần thiết lập đúng cách các thuộc tính SSLInfo với cờ ClientAuthEnabled, Keystore, KeyAliasTruststore 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 >
      

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

  1. 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.
  2. 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 đủ.

  3. 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.
  4. 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:
    1. 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
      
    2. 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ợ.

  5. Hãy xem xét ví dụ về tcpdump sau đây.

    Mẫu tcpdump được lấy khi 502 Bad Gateway Error (UnexpectedEOFAtTarget) xảy ra

  6. Từ kết quả TCPDump, bạn nhận thấy chuỗi sự kiện sau đây:
    1. Trong gói 985, Bộ xử lý thông báo gửi yêu cầu API đến máy chủ phụ trợ.
    2. Trong gói 986, máy chủ phụ trợ phản hồi ngay lập tức bằng [FIN,ACK].
    3. 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ợ.
    4. Cuối cùng, các kết nối sẽ bị đóng bằng [ACK][RST] từ cả hai phía.
    5. 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.
  7. Đ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:

  1. 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.
  2. 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ợ.
  3. 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ợ.
  4. 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.
  5. 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.
  6. Việc này dẫn đến một Unexpected EOF, sau đó là một 502 đượ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

  1. Nếu bạn là người dùng Đám mây công cộng:
    1. 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
    2. Hãy chuyển đến phần Sử dụng tcpdump để tìm hiểu thêm.
  2. Nếu bạn là người dùng Đám mây riêng tư:
    1. 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.
    2. 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).
    3. 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)
      
    4. Lỗi java.io.EOFException: eof unexpected cho biết Trình xử lý thông báo đã nhận được EOF trong khi vẫn đang chờ đọc phản hồi từ máy chủ phụ trợ.
    5. 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ính bytesWritten=159 cho biết rằng Trình xử lý thông báo đã gửi tải trọng yêu cầu 159 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 ra EOF không mong muốn.
    6. Đ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 tcpdump

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

    1. Trong gói 5992,, máy chủ phụ trợ đã nhận được một yêu cầu GET.
    2. Trong gói 6064, gói này phản hồi bằng 200 OK.
    3. Trong gói 6084, máy chủ phụ trợ đã nhận được một yêu cầu GET khác.
    4. Trong gói 6154, nó phản hồi bằng 200 OK.
    5. Trong gói 6228, máy chủ phụ trợ đã nhận được yêu cầu GET thứ ba.
    6. Lần này, máy chủ phụ trợ trả về một FIN, ACK cho Bộ xử lý thông báo (gói 6285) để 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ợ.

So sánh thời gian chờ hoạt động trên ứng dụng Apigee và máy chủ phụ trợ

  1. 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.
  2. 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ỗi 502.

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

  3. 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.
  4. 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ợ.

  1. Xác định giá trị đã đặt cho thời gian chờ duy trì hoạt động trên máy chủ phụ trợ.
  2. Đị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:

  1. 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.
  2. 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.
  3. 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.
  4. 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ỗi 502
  • 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ỗi 502 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