499 Ứng dụng đã đóng kết nối

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 hết thời gian chờ cho các yêu cầu API hoặc yêu cầu bị chấm dứt đột ngột trong khi yêu cầu API vẫn đang được thực thi trên Apigee.

Bạn sẽ thấy mã trạng thái 499 cho các yêu cầu API như vậy trong tính năng Giám sát API và nhật ký truy cập NGINX. Đôi khi, bạn sẽ thấy các mã trạng thái khác nhau trong API Analytics vì API này cho biết mã trạng thái do Trình xử lý thông báo trả về.

Thông báo lỗi

Các ứng dụng có thể gặp phải những lỗi như: 

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received

Điều gì gây ra thời gian chờ của ứng dụng?

Đường dẫn thông thường cho một yêu cầu API trên nền tảng Edge là Client > Router > Message Processor > Backend Server như minh hoạ trong hình sau:

Các Bộ định tuyến và Bộ xử lý thông báo trong nền tảng Apigee Edge được thiết lập với các giá trị thời gian chờ mặc định phù hợp để đảm bảo rằng các yêu cầu API không mất quá nhiều thời gian để hoàn tất.

Hết thời gian chờ trên ứng dụng

Bạn có thể thiết lập các ứng dụng khách bằng một giá trị thời gian chờ phù hợp dựa trên nhu cầu của mình.

Các ứng dụng như trình duyệt web và ứng dụng di động có thời gian chờ do hệ điều hành xác định.

Hết thời gian chờ trên bộ định tuyến

Thời gian chờ mặc định được định cấu hình trên Bộ định tuyến là 57 giây. Đây là khoảng thời gian tối đa mà một proxy API có thể thực thi kể từ thời điểm yêu cầu API được nhận trên Edge cho đến khi phản hồi được gửi lại, bao gồm cả phản hồi phụ trợ và tất cả các chính sách được thực thi. Bạn có thể ghi đè thời gian chờ mặc định trên Bộ định tuyến và máy chủ ảo như giải thích trong phần Định cấu hình thời gian chờ I/O trên Bộ định tuyến.

Hết thời gian chờ trên Bộ xử lý thông báo

Thời gian chờ mặc định được định cấu hình trên Trình xử lý thông báo là 55 giây. Đây là khoảng thời gian tối đa mà máy chủ phụ trợ có thể mất để xử lý yêu cầu và phản hồi lại Bộ xử lý thông báo. Bạn có thể ghi đè thời gian chờ mặc định trên Trình xử lý thông báo hoặc trong API Proxy như giải thích trong phần Định cấu hình thời gian chờ I/O trên Trình xử lý thông báo.

Nếu ứng dụng đóng kết nối với Bộ định tuyến trước khi proxy API hết thời gian chờ, thì bạn sẽ thấy lỗi hết thời gian chờ cho yêu cầu API cụ thể. Mã trạng thái 499 Client Closed Connection được ghi vào Nhật ký của Bộ định tuyến cho những yêu cầu như vậy. Bạn có thể quan sát mã này trong Nhật ký truy cập API Monitoring và NGINX.

Nguyên nhân có thể dẫn đến vấn đề này

Trong Edge, các nguyên nhân thường gặp gây ra lỗi 499 Client Closed Connection là:

Nguyên nhân Mô tả Hướng dẫn khắc phục sự cố áp dụng cho
Ứng dụng đột ngột đóng kết nối Điều này xảy ra khi ứng dụng đóng kết nối do người dùng cuối huỷ yêu cầu trước khi yêu cầu hoàn tất. Người dùng đám mây công khai và đám mây riêng tư
Hết thời gian chờ của ứng dụng khách Điều này xảy ra khi ứng dụng khách hết thời gian chờ trước khi API Proxy có thời gian xử lý và gửi phản hồi. Điều này thường xảy ra khi thời gian chờ của máy khách nhỏ hơn thời gian chờ của bộ định tuyến. Người dùng đám mây công khai và đám mây riêng tư

Các bước chẩn đoán thường gặp

Hãy sử dụng một trong các công cụ/kỹ thuật sau để chẩn đoán lỗi này:

  • Giám sát API
  • Nhật ký truy cập NGINX

Giám sát API

Cách chẩn đoán lỗi bằng tính năng Giám sát API:

  1. Chuyển đến trang Phân tích > Giám sát API > Điều tra.
  2. Lọc các lỗi 4xx và chọn khung thời gian.
  3. Vẽ Mã trạng thái theo Thời gian.
  4. Chọn một ô có lỗi 499 như minh hoạ bên dưới:

  5. Bạn sẽ thấy thông tin về lỗi 499 trên ngăn bên phải như minh hoạ bên dưới:

  6. Trong ngăn bên phải, hãy nhấp vào Xem nhật ký.

    Trong cửa sổ Nhật ký lưu lượng truy cập, hãy lưu ý những thông tin sau đây về một số lỗi 499:

    • Yêu cầu:Phần này cung cấp phương thức yêu cầu và URI được dùng để thực hiện các lệnh gọi
    • Thời gian phản hồi:Thông tin này cho biết tổng thời gian đã trôi qua cho yêu cầu.

    Bạn cũng có thể nhận tất cả nhật ký bằng cách sử dụng API GET logs (Nhận nhật ký) của API Giám sát. Ví dụ: bằng cách truy vấn nhật ký cho org, env, timeRange và status, bạn có thể tải xuống tất cả nhật ký cho các giao dịch mà khách hàng đã hết thời gian chờ.

    Vì API Monitoring đặt proxy thành - cho các lỗi 499 HTTP, nên bạn có thể sử dụng API (Logs API) để lấy proxy được liên kết cho máy chủ ảo và đường dẫn.

    For example : 

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. Xem Thời gian phản hồi để biết thêm các lỗi 499 và kiểm tra xem Thời gian phản hồi có nhất quán (giả sử là 30 giây) trên tất cả các lỗi 499 hay không.

Nhật ký truy cập NGINX

Cách chẩn đoán lỗi bằng nhật ký truy cập NGINX:

  1. Nếu là người dùng Đám mây riêng, bạn có thể sử dụng nhật ký truy cập NGINX để xác định thông tin chính về lỗi HTTP 499.
  2. Kiểm tra nhật ký truy cập NGINX:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. Tìm kiếm để xem có 499 Lỗi nào trong một khoảng thời gian cụ thể hay không (nếu vấn đề xảy ra trong quá khứ) hoặc xem có yêu cầu nào vẫn không thành công với 499 hay không.
  4. Xin lưu ý những thông tin sau đối với một số lỗi 499:
    • Tổng thời gian phản hồi
    • URI yêu cầu
    • Tác nhân người dùng

    Ví dụ về lỗi 499 trong nhật ký truy cập của NGINX:

    2019-08-23T06:50:07+00:00       rrt-03f69eb1091c4a886-c-sy      50.112.119.65:47756
10.10.53.154:8443       10.001  -       -       499     -       422     0
   GET /v1/products HTTP/1.1        -       okhttp/3.9.1    api.acme.org
rrt-03f69eb1091c4a886-c-sy-13001-6496714-1
    50.112.119.65   -       -       -       -       -       -       -       -1      -       -       dc-1  router-pod-1
rt-214-190301-0020137-latest-7d
36       TLSv1.2 gateway-1     dc-1  acme    prod  https   -

    Trong ví dụ này, chúng ta thấy thông tin sau:

    • Tổng thời gian phản hồi: 10.001 giây. Điều này cho biết ứng dụng khách đã hết thời gian chờ sau 10,001 giây
    • Yêu cầu: GET /v1/products
    • Máy chủ lưu trữ:api.acme.org
    • Tác nhân người dùng:okhttp/3.9.1
  5. Kiểm tra xem Tổng thời gian phản hồi và Tác nhân người dùng có nhất quán trên tất cả các lỗi 499 hay không.

Nguyên nhân: Ứng dụng đã đóng kết nối đột ngột

Chẩn đoán

  1. Khi một API được gọi từ một ứng dụng một trang đang chạy trong trình duyệt hoặc ứng dụng di động, trình duyệt sẽ huỷ yêu cầu nếu người dùng cuối đột ngột đóng trình duyệt, chuyển đến một trang web khác trong cùng một thẻ hoặc ngăn trang tải bằng cách nhấp hoặc nhấn vào dừng tải.
  2. Nếu điều này xảy ra, các giao dịch có trạng thái HTTP 499 thường sẽ khác nhau về thời gian xử lý yêu cầu (Thời gian phản hồi) cho từng yêu cầu.
  3. Bạn có thể xác định xem đây có phải là nguyên nhân hay không bằng cách so sánh Thời gian phản hồi và xác minh xem thời gian này có khác nhau đối với từng lỗi 499 hay không bằng cách sử dụng tính năng Giám sát API hoặc nhật ký truy cập NGINX như được giải thích trong phần Các bước chẩn đoán thường gặp.

Độ phân giải

  1. Đây là điều bình thường và thường không phải là nguyên nhân đáng lo ngại nếu lỗi HTTP 499 xảy ra với số lượng nhỏ.

  2. Nếu điều này thường xuyên xảy ra đối với cùng một đường dẫn URL, thì có thể là do một proxy cụ thể được liên kết với đường dẫn đó hoạt động rất chậm và người dùng không muốn chờ đợi.

    Sau khi biết proxy nào có thể bị ảnh hưởng, hãy sử dụng Trang tổng quan phân tích Độ trễ để tìm hiểu thêm về nguyên nhân gây ra độ trễ của proxy.

    1. Trong trường hợp này, hãy xác định proxy bị ảnh hưởng bằng cách làm theo các bước trong phần Các bước chẩn đoán thường gặp.
    2. Sử dụng Trang tổng quan phân tích độ trễ để điều tra thêm về nguyên nhân gây ra độ trễ của proxy và khắc phục vấn đề.
    3. Nếu thấy độ trễ là điều bình thường đối với một Proxy cụ thể, thì bạn có thể phải thông báo cho người dùng rằng Proxy này sẽ mất một khoảng thời gian để phản hồi.

Nguyên nhân: Ứng dụng hết thời gian chờ

Điều này có thể xảy ra trong một số trường hợp.

  1. Dự kiến yêu cầu sẽ mất một khoảng thời gian nhất định (giả sử là 10 giây) để hoàn tất trong điều kiện hoạt động bình thường. Tuy nhiên, ứng dụng khách được đặt với giá trị thời gian chờ không chính xác (giả sử là 5 giây), khiến ứng dụng khách hết thời gian chờ trước khi yêu cầu API hoàn tất, dẫn đến 499. Trong trường hợp này, chúng ta cần đặt thời gian chờ của máy khách thành một giá trị thích hợp.
  2. Một máy chủ đích hoặc chú thích mất nhiều thời gian hơn dự kiến. Trong trường hợp này, bạn cần sửa thành phần thích hợp và điều chỉnh các giá trị thời gian chờ một cách phù hợp.
  3. Ứng dụng khách không cần phản hồi nữa và do đó đã huỷ. Điều này có thể xảy ra đối với các API có tần suất cao, chẳng hạn như tính năng tự động hoàn thành hoặc tính năng thăm dò ý kiến trong thời gian ngắn.

Chẩn đoán

Giám sát API hoặc nhật ký truy cập NGINX

Chẩn đoán lỗi bằng cách sử dụng tính năng Giám sát API hoặc nhật ký truy cập NGINX:

  1. Kiểm tra nhật ký Giám sát API hoặc nhật ký truy cập NGINX cho các giao dịch HTTP 499 như được giải thích trong phần Các bước chẩn đoán thường gặp.
  2. Xác định xem Thời gian phản hồi có nhất quán cho tất cả các lỗi 499 hay không.
  3. Nếu có, thì có thể một ứng dụng khách cụ thể đã định cấu hình thời gian chờ cố định ở phía ứng dụng đó. Nếu một máy chủ đích hoặc proxy API phản hồi chậm, thì máy khách sẽ hết thời gian chờ trước khi proxy hết thời gian chờ, dẫn đến số lượng lớn HTTP 499s cho cùng một đường dẫn URI. Trong trường hợp này, hãy xác định Tác nhân người dùng từ nhật ký truy cập NGINX. Nhật ký này có thể giúp bạn xác định ứng dụng khách cụ thể.
  4. Cũng có thể có một bộ cân bằng tải trước Apigee, chẳng hạn như Akamai, F5, AWS ELB, v.v. Nếu Apigee đang chạy sau một trình cân bằng tải tuỳ chỉnh, thì bạn phải định cấu hình thời gian chờ yêu cầu của trình cân bằng tải dài hơn thời gian chờ API của Apigee. Theo mặc định, Bộ định tuyến Apigee sẽ hết thời gian chờ sau 57 giây, vì vậy, bạn nên định cấu hình thời gian chờ yêu cầu là 60 giây trên bộ cân bằng tải.

Trace

Chẩn đoán lỗi bằng Trace

Nếu vấn đề vẫn tiếp diễn (vẫn xảy ra lỗi 499), hãy thực hiện các bước sau:

  1. Bật phiên truy vết cho API bị ảnh hưởng trong giao diện người dùng Edge.
  2. Bạn có thể đợi lỗi xảy ra hoặc nếu có lệnh gọi API, hãy thực hiện một số lệnh gọi API và tái tạo lỗi.
  3. Kiểm tra thời gian đã trôi qua ở mỗi giai đoạn và ghi chú lại giai đoạn mà bạn dành nhiều thời gian nhất.
  4. Nếu bạn nhận thấy lỗi có thời gian đã trôi qua lâu nhất ngay sau một trong các giai đoạn sau, thì điều đó cho thấy máy chủ phụ trợ đang hoạt động chậm hoặc mất nhiều thời gian để xử lý yêu cầu:
    • Đã gửi yêu cầu đến máy chủ đích
    • Chính sách ServiceCallout

    Dưới đây là một dấu vết giao diện người dùng mẫu cho thấy Gateway Timeout (Hết thời gian chờ của cổng) sau khi Request (Yêu cầu) được gửi đến máy chủ đích:

Độ phân giải

  1. Tham khảo Các phương pháp hay nhất để định cấu hình thời gian chờ I/O để hiểu rõ những giá trị thời gian chờ cần đặt trên các thành phần khác nhau liên quan đến quy trình yêu cầu API thông qua Apigee Edge.
  2. Đảm bảo rằng bạn đặt giá trị thời gian chờ thích hợp trên ứng dụng khách theo các phương pháp hay nhất.

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ải thu thập thông tin chẩn đoán

Nếu vấn đề vẫn tiếp diễ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 Edge.

Nếu bạn là người dùng Đám mây công cộng, hãy cung cấp những thông tin sau:

  • Tên tổ chức
  • Tên môi trường
  • Tên API Proxy
  • Hoàn tất lệnh curl được dùng để tái tạo lỗi hết thời gian chờ
  • Tệp theo dõi cho các yêu cầu API mà bạn thấy lỗi hết thời gian chờ của ứng dụng

Nếu bạn là người dùng Đám mây riêng, hãy cung cấp những thông tin sau:

  • Thông báo lỗi hoàn chỉnh được ghi nhận cho các yêu cầu không thành công
  • Tên môi trường
  • Gói API Proxy
  • Tệp theo dõi cho các yêu cầu API mà bạn thấy lỗi hết thời gian chờ của ứng dụng
  • Nhật ký truy cập NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
  • Nhật ký hệ thống của Trình xử lý tin nhắn (/opt/apigee/var/log/edge-message-processor/logs/system.log)