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

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 hết thời gian chờ đối với 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ẽ quan sát mã trạng thái 499 cho các yêu cầu API đó trong phần Giám sát API và nhật ký Truy cập NGINX. Đôi khi, bạn sẽ thấy nhiều mã trạng thái trong API Analytics vì mã 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

Ứng dụng khách có thể thấy lỗi như: 

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

Điều gì khiến ứng dụng hết thời gian chờ?

Đường dẫn điển hình cho một yêu cầu API trên nền tảng Edge là Ứng dụng > Bộ định tuyến > Bộ xử lý thông báo > Máy chủ phụ trợ như trong hình sau:

Bộ định tuyến và Bộ xử lý thông báo trong nền tảng Apigee được thiết lập với giá trị thời gian chờ mặc định phù hợp để đảm bảo 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

Các ứng dụng khách có thể được định cấu hình với giá trị thời gian chờ phù hợp dựa trên nhu cầu của bạn.

Các ứng dụng như trình duyệt web và ứng dụng dành cho thiết bị 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ừ khi nhận được yêu cầu API trên Edge cho đến khi phản hồi được gửi trả lại, bao gồm cả phản hồi trong phần phụ trợ và mọi 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 bài viết Định cấu hình thời gian chờ I/O trên Bộ định tuyến.

Thời gian chờ trên Trình xử lý thư

Thời gian chờ mặc định được định cấu hình trên Bộ xử lý thư là 55 giây. Đây là khoảng thời gian tối đa mà máy chủ phụ trợ có thể dùng để 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 Bộ xử lý thông báo hoặc trong Proxy API như giải thích trong bài viết Định cấu hình thời gian chờ I/O trên Bộ 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ẽ quan sát 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 Bộ định tuyến cho những yêu cầu như vậy. Bạn có thể quan sát các yêu cầu này trong nhật ký Giám sát API và NGINX Access (Truy cập NGINX).

Nguyên nhân có thể xảy ra

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

Nguyên nhân Nội dung mô tả Hướng dẫn khắc phục sự cố áp dụng cho
Ứng dụng đã đóng kết nối đột ngột Đ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 hoàn tất. Người dùng đám mây công khai và riêng 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 Proxy API 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à riêng tư

Các bước chẩn đoán phổ biến

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 4xx lỗi và chọn khung thời gian.
  3. Vẽ Mã trạng thái dựa trên Thời gian.
  4. Chọn một ô có 499 lỗi như minh hoạ dưới đây:

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

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

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

    • Request (Yêu cầu): Cung cấp phương thức yêu cầu và URI dùng để thực hiện lệnh gọi
    • Thời gian phản hồi:Chỉ số 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 nhật ký của dịch vụ Giám sát API. Ví dụ: bằng cách truy vấn nhật ký cho org, env, timeRange và status, bạn có thể tải tất cả nhật ký của những giao dịch mà ứng dụng đã hết thời gian chờ.

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

    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 xét 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 hay không (giả sử là 30 giây) trên tất cả các lỗi 499.

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 tư, bạn có thể 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ó Lỗi 499 nào trong một khoảng thời gian cụ thể không (nếu vấn đề đã xảy ra trong quá khứ) hoặc có yêu cầu nào vẫn không thành công với 499 hay không.
  4. Hãy 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 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   -

    Đối với 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 đã hết thời gian chờ sau 10,001 giây
    • Yêu cầu: GET /v1/products
    • Người tổ chức: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 API được gọi từ một ứng dụng trang đơn chạy trong trình duyệt hoặc ứng dụng dành cho thiết bị 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 thẻ hoặc dừng trang tải bằng cách nhấp hoặc nhấn vào ngừng tải.
  2. Nếu điều này xảy ra, những giao dịch có trạng thái HTTP 499 thường sẽ thay đổi 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 mỗi lỗi trong 499 có khác nhau hay không bằng cách sử dụng nhật ký Giám sát API hoặc NGINX Access (Nhật ký truy cập NGINX) như giải thích trong phần Các bước chẩn đoán phổ biến.

Độ phân giải

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

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

    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ễ 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. 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ễ proxy và khắc phục vấn đề.
    3. Nếu nhận thấy độ trễ dự kiến cho 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 khách 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 giá trị thời gian chờ không chính xác (giả sử là 5 giây). Điều này khiến ứng dụng 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 ứng dụng ở một giá trị thích hợp.
  2. Máy chủ hoặc chú thích mục tiêu 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à cũng cần điều chỉnh giá trị thời gian chờ cho phù hợp.
  3. Ứng dụng này không cần phản hồi nữa nên đã huỷ. Điều này có thể xảy ra đối với các API tần suất cao như tự động hoàn thành hoặc thăm dò ý kiến 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 tính năng Giám sát API hoặc nhật ký truy cập NGINX:

  1. Hãy 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ư giải thích trong phần Các bước chẩn đoán phổ biến.
  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ể là một ứng dụng cụ thể đã định cấu hình thời gian chờ cố định ở phía ứng dụng. Nếu một proxy API hoặc máy chủ đích phản hồi chậm, thì ứng dụng sẽ hết thời gian chờ trước khi proxy hết thời gian chờ. Điều này dẫn đến việc một 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 trong nhật ký truy cập NGINX để xác định ứng dụng cụ thể.
  4. Cũng có thể là có một trình cân bằng tải trước Apigee như Akamai, F5, AWS ELB, v.v. Nếu Apigee đang chạy trên một trình cân bằng tải tuỳ chỉnh, thì thời gian chờ yêu cầu của trình cân bằng tải phải được định cấu hình lớn hơn thời gian chờ của API 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 trình cân bằng tải.

Trace

Sử dụng công cụ Theo dõi để chẩn đoán lỗi

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

  1. Bật phiên theo dõi cho API bị ảnh hưởng trong giao diện người dùng Edge.
  2. Hãy chờ cho đến khi lỗi xảy ra hoặc nếu bạn 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 lại giai đoạn mà người dùng dành hầu hết thời gian.
  4. Nếu bạn quan sát thấy lỗi có thời gian dài nhất đã trôi qua ngay sau một trong các giai đoạn sau, thì tức là máy chủ phụ trợ bị 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 về chú thích dịch vụ

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

Độ phân giải

  1. Tham khảo bài viết Các phương pháp hay nhất để định cấu hình thời gian chờ I/O để tìm hiểu xem nên đặt giá trị thời gian chờ nào cho các thành phần liên quan đến luồng 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 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 mục 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 sự cố 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 Bộ phận hỗ trợ Apigee.

Nếu bạn là người dùng Public Cloud (Đá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 proxy API
  • Hoàn tất lệnh curl 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 đang gặp 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 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ên môi trường
  • Gói Proxy API
  • Tệp theo dõi cho các yêu cầu API mà bạn đang gặp 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 Bộ xử lý thư (/opt/apigee/var/log/edge-message-processor/logs/system.log)