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 nhận được 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 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 như vậy trong phần 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ì
hiển thị mã trạng thái do Trình xử lý thư trả về.
Thông báo lỗi
Ứng dụng khách có thể thấy các lỗi như:
curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received
Nguyên nhân nào 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à Khách hàng > Bộ định tuyến > Trình xử lý thư > Máy chủ phụ trợ như minh hoạ trong hình sau:
Bộ định tuyến và Bộ xử lý tin nhắn trong nền tảng Apigee Edge được thiết lập với giá trị thời gian chờ mặc định để đảm bảo rằng các yêu cầu API không mất quá nhiều thời gian để hoàn thành.
Hết thời gian chờ trên ứng dụng
Bạn có thể định cấu hình cho ứng dụng 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 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 Proxy API có thể thực thi từ thời điểm nhận được yêu cầu API trên Edge cho đến khi phản hồi được gửi lại, bao gồm phản hồi phụ trợ và tất cả các chính sách được thực thi. Mặc định Thời gian chờ có thể được ghi đè trên Bộ định tuyến và máy chủ ảo như được giải thích trong Định cấu hình thời gian chờ I/O trên Bộ định tuyến.
Thời gian chờ đối với Bộ xử lý thư
Thời gian chờ mặc định được định cấu hình trên Trình xử lý thư là 55 giây. Đây là số tiền tối đa thời gian mà máy chủ phụ trợ có thể mất để xử lý yêu cầu và phản hồi lại Thông báo Bộ xử lý. 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ư được giải thích trong Đị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 khách đóng kết nối với Bộ định tuyến trước khi proxy API hết thời gian 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 lại trong Bộ định tuyến cho các yêu cầu như vậy. Bạn có thể quan sát thấy mã này trong API
Nhật ký giám sát và nhật ký truy cập NGINX.
Nguyên nhân có thể xảy ra
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 máy khách đóng kết nối do người dùng cuối huỷ kết nối trước khi hoàn tất. | Người dùng đám mây công khai và riêng tư |
| Hết thời gian chờ ứng dụng | Điều này xảy ra khi ứng dụng hết thời gian chờ trước khi Proxy API có thời gian để xử lý và gửi phản hồi. Thông thường, điều này xảy ra khi thời gian chờ của ứng dụng ít hơn so với 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:
- Chuyển đến thẻ Analyze (Phân tích) > Giám sát API > Điều tra.
- Lọc ra
4xxlỗi rồi chọn khung thời gian. - Vẽ Mã trạng thái theo Thời gian.
- Chọn một ô có
499lỗi như minh hoạ dưới đây:
- Bạn sẽ thấy thông tin về lỗi
499ở ngăn bên phải như sau: được hiển thị bên dưới:
- Trong ngăn bên phải, hãy nhấp vào Xem nhật ký.
Trong cửa sổ Traffic Logs (Nhật ký lưu lượng truy cập), hãy lưu ý những thông tin chi tiết sau đây cho một số
499các lỗi:- 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:Mục này cho biết tổng thời gian đã trôi qua của yêu cầu.
Bạn cũng có thể lấy tất cả nhật ký bằng cách sử dụng tính năng Giám sát API GET nhật ký. Cho ví dụ: bằng cách truy vấn nhật ký cho
org,env,timeRangevàstatus, bạn sẽ có thể tải xuống tất cả nhật ký của các giao dịch mà ứng dụng đã hết thời gian chờ.Vì tính năng Giám sát API đặt proxy thành
-cho HTTP499lỗi, bạn có thể dùng API (Logs API) để lấy proxy đã liên kết cho đường dẫn và máy chủ lưu trữ ảo.For example :
curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
- Kiểm tra Thời gian phản hồi để tìm
499lỗi khác và kiểm tra xem Thời gian phản hồi là nhất quán (giả sử là 30 giây) trên tất cả499lỗi.
Nhật ký truy cập NGINX
Cách chẩn đoán lỗi bằng nhật ký truy cập NGINX:
- Nếu là người dùng Đám mây riêng tư, bạn có thể sử dụng nhật ký truy cập NGINX để xác định
thông tin quan trọng về lỗi HTTP
499. - Kiểm tra nhật ký truy cập NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log - Tìm kiếm để xem có lỗi
499nào trong một khoảng thời gian cụ thể hay không (nếu sự cố đã xảy ra trong quá khứ) hoặc nếu có bất kỳ yêu cầu nào vẫn không thành công với499. - 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
Lỗi 499 mẫu 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 sẽ thấy thông tin sau:
- Tổng thời gian phản hồi:
10.001giây. Điều này cho thấy rằng ứ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
- 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 hay không
trên tất cả
499lỗi.
Nguyên nhân: Ứng dụng đã đóng kết nối đột ngột
Chẩn đoán
- Khi một 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 nhiên đóng trình duyệt, điều hướng vào 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 hay nhấn ngừng tải.
- Nếu điều này xảy ra, các giao dịch có trạng thái HTTP
499thường sẽ thay đổi trong thời gian xử lý yêu cầu (Thời gian phản hồi) cho từng yêu cầu. -
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
499sử dụng chức năng Giám sát API hoặc quyền truy cập NGINX sẽ khác nhau nhật ký như được giải thích trong Các bước chẩn đoán phổ biến.
Độ phân giải
- Điều này là bình thường và thường không phải là nguyên nhân đáng lo ngại nếu các lỗi HTTP
499đang diễn ra với số lượng nhỏ. -
Nếu lỗi này thường xảy ra cho cùng một đường dẫn URL, thì có thể là do proxy cụ thể liên quan đến đường dẫn đó 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 Độ trễ trang tổng quan phân tích để điều tra thêm nguyên nhân gây ra độ trễ proxy.
- 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 Các bước chẩn đoán thường gặp.
- Sử dụng Trang tổng quan về phân tích độ trễ để điều tra thêm nguyên nhân gây ra độ trễ proxy và khắc phục sự cố.
- Nếu bạn nhận thấy độ trễ dự kiến cho một Proxy cụ thể, thì có thể bạn để 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.
-
Theo 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 sai
giá trị hết thời gian chờ (giả sử là 5 giâ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 máy khách thành một giá trị thích hợp. - Máy chủ mục tiêu 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 khắc phục vấn đề thích hợp và cũng điều chỉnh giá trị thời gian chờ một cách thích hợp.
- Ứng dụng không cần phản hồi nữa nên đã huỷ. Điều này có thể xảy ra với tần suất, chẳng hạn 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 cách sử dụng chức năng Giám sát API hoặc nhật ký truy cập NGINX:
- Kiểm tra nhật ký giám sát API hoặc nhật ký truy cập NGINX để biết các giao dịch HTTP
499như được giải thích trong Các bước chẩn đoán thường gặp. - Xác định xem Thời gian phản hồi có nhất quán với tất cả lỗi
499hay không. - Nếu có, thì có thể là một ứng dụng khách cụ thể đã định cấu hình thời gian chờ cố định
ở phía sau. Nếu proxy API hoặc máy chủ mục tiêu phản hồi chậm, ứng dụng sẽ hết thời gian chờ
trước khi proxy hết thời gian, dẫn đến số lượng lớn HTTP
499scho 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 có thể giúp bạn xác định ứng dụng khách cụ thể. - Cũng có thể có một trình cân bằng tải trước Apigee như Skyward, 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ì yêu cầu thời gian chờ 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 Theo mặc định, Bộ định tuyến Apigee sẽ hết thời gian chờ sau 57 giây, vì vậy, bộ định tuyến này phù hợp để định cấu hình yêu cầu 60 giây trên trình cân bằng tải.
Trace
Chẩn đoán lỗi bằng cách sử dụng công cụ Theo dõi
Nếu vấn đề vẫn tiếp diễn (vẫn xảy ra 499 lỗi), hãy thực hiện thao tác
các bước sau:
- Bật phiên theo dõi cho API bị ảnh hưởng trong giao diện người dùng Edge.
- Chờ 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.
- Kiểm tra thời gian đã trôi qua ở mỗi giai đoạn và ghi chú về giai đoạn mà thời gian đó chiếm hầu hết thời gian của bạn.
- Nếu bạn quan sát lỗi với thời gian trôi qua lâu nhất 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à một dấu vết giao diện người dùng mẫu cho thấy 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
- Tham khảo Các phương pháp hay nhất để định cấu hình thời gian chờ I/O nhằm nắm được giá trị thời gian chờ nào nên được đặt trên nhiều thành phần liên quan đến quy trình yêu cầu API thông qua Apigee Edge.
- Hãy đả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 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 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 Edge.
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
curldùng để tái hiện 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 các thông tin sau:
- Đã nhậ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ực hiện được
- 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 Trình xử lý thư (
/opt/apigee/var/log/edge-message-processor/logs/system.log)