Yêu cầu API không được ghi lại trong giao diện người dùng Edge

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

Hình ảnh sau đây cho thấy các yêu cầu API không được ghi lại trong giao diện người dùng Edge khi một phiên theo dõi bắt đầu:

Thông báo Lỗi

Sẽ không có thông báo lỗi nào hiển thị trong giao diện người dùng Edge khi sự cố này xảy ra.

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

Bảng sau đây cho thấy các nguyên nhân có thể khiến không ghi nhận được các yêu cầu API trong công cụ Theo dõi giao diện người dùng Edge:

Nguyên nhân: Yêu cầu không được xử lý bởi Đơn vị xử lý thư

Chẩn đoán

Để ghi lại một yêu cầu API trong một phiên Theo dõi, yêu cầu API phải do Trình xử lý thông báo thành phần của Edge xử lý. Có một số lý do khiến yêu cầu API có thể không được ghi lại trong giao dịch Theo dõi.

Ví dụ: Nếu một yêu cầu API không kết nối được với Apigee Edge, thì sẽ không kết nối được tại điểm truy cập đến Edge (tức là Bộ định tuyến) hoặc bị lỗi trước khi được Bộ xử lý thông báo xử lý thì không thể ghi lại dấu vết. Mỗi trường hợp trong số này được trình bày chi tiết hơn bên dưới.

Trường hợp 1: Yêu cầu không đến được ứng dụng Apigee Edge

• Nguyên nhân

  Trong trường hợp này, lỗi có thể là do độ phân giải DNS hoặc sự cố kết nối mạng. Nếu vậy, bạn có thể gặp lỗi sau khi chạy lệnh này:

  curl https://hostName:port/apiProxyBasePath/requestPath
  

  curl: (6) Could not resolve host: hostName
  

• Độ phân giải

  Bạn có thể xác minh cấu hình DNS bằng lệnh sau:

  dig hostName

  Bạn có thể xác minh kết nối mạng bằng lệnh sau đây:

  telnet hostName port

Tình huống 2: Yêu cầu không thành công trên Bộ định tuyến Apigee Edge

• Nguyên nhân

  Trong trường hợp này, lỗi có thể là do lỗi bắt tay TLS/SSL. Nếu vậy, bạn có thể thấy một trong các lỗi sau:

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  Bạn cũng có thể thấy lỗi chứng chỉ SSL.

• Độ phân giải

  Hãy tham khảo những cẩm nang sau đây để khắc phục và giải quyết những vấn đề này:

  Lỗi bắt tay TLS/SSL

  400 Yêu cầu không hợp lệ – Lỗi chứng chỉ SSL

Trường hợp 3: Công cụ xử lý thư không thể xử lý yêu cầu

• Nguyên nhân

  Trong trường hợp này, Trình xử lý tin nhắn Apigee không thể tìm thấy Proxy API cho máy chủ và đường dẫn ảo được chỉ định. Do đó, bạn có thể thấy một trong những các lỗi sau:

  HTTP/1.1 404 Not Found
  

  {
    "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/apiProxyBasePath/requestPath",
      "detail":{
        "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
    }
  }
  
  

• Độ phân giải

  Tham khảo cẩm nang này để khắc phục sự cố và giải quyết vấn đề này: 404 Không thể xác định proxy cho máy chủ lưu trữ.

Nguyên nhân: Không tìm thấy proxy API trong cây phân loại

Chẩn đoán

Nếu Trình xử lý thông báo không tìm thấy proxy API trong Cây phân loại, thì mọi yêu cầu API gửi đến proxy cụ thể đó sẽ không xuất hiện trong các phiên Theo dõi trong giao diện người dùng Edge.

Hãy làm theo các bước bên dưới để xác định xem đây có phải là trường hợp của bạn không:

1. Đăng nhập vào từng Bộ xử lý thư và kiểm tra xem bản sửa đổi cụ thể của API được yêu cầu có được triển khai trong môi trường liên quan của Bộ xử lý thư bằng lệnh sau hay không:

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   Kết quả mẫu:

   Lệnh trên sẽ xuất danh sách các bản sửa đổi đã triển khai. Ví dụ: nếu triển khai bản sửa đổi 12, bạn sẽ thấy kết quả sau:

   [ "12" ]
   

   Trừ khi bạn gặp phải lỗi HTTP 404 gián đoạn, có thể bạn sẽ thấy rằng bản sửa đổi cụ thể đã được triển khai.

2. Đọc Cây phân loại và kiểm tra sự tồn tại của tên proxy API bằng cách sử dụng lệnh sau:

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

3. Lặp lại Bước 1 và 2 cho từng Trình xử lý thư. Nếu tên proxy API đã cho bị thiếu trong Cây phân loại của bất kỳ Trình xử lý thông báo nào thì hãy làm theo giải pháp được đưa ra dưới đây.

Độ phân giải

Hãy làm theo các bước dưới đây để giải quyết vấn đề này. Hãy nhớ thực hiện mọi biện pháp phòng ngừa cần thiết để tránh tình trạng ngừng sản xuất có thể xảy ra do khởi động lại Trình xử lý tin nhắn khi có yêu cầu quá tải.

1. Đăng nhập vào từng máy chủ lưu trữ Trình xử lý thư đang thiếu proxy API cụ thể trong Cây phân loại và sử dụng lệnh dưới đây để khởi động lại Trình xử lý thư:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
   

2. Sau khi khởi động lại, hãy sử dụng lệnh bên dưới để chờ cho đến khi lệnh được kích hoạt:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready
   

3. Khi Trình xử lý thư đã sẵn sàng, hãy xác minh tình trạng sẵn có của proxy API bằng lệnh sau:

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   Kết quả mẫu:

   Lệnh trên sẽ xuất danh sách các bản sửa đổi đã triển khai. Ví dụ: nếu triển khai bản sửa đổi 12, bạn sẽ thấy kết quả sau:

   [ "12" ]
   

   Trừ khi bạn gặp phải lỗi HTTP 404 gián đoạn, có thể bạn sẽ thấy rằng bản sửa đổi cụ thể đã được triển khai.

4. Đọc Cây phân loại và xác minh sự tồn tại của tên proxy API bằng cách sử dụng lệnh sau:

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

   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 sau khi làm theo các hướng dẫn ở trên, hãy thu thập thông tin chẩn đoán sau đây và chia sẻ với Bộ phận hỗ trợ Apigee Edge:

curl -v management-server-host:8080/v1/runtime/organizations/orgName/environments/envName/apis/apiProxyName/revisions/revisionNumber/debugsessions -u user

/opt/apigee/var/log/edge-management-server/logs/system.log

/opt/apigee/var/log/edge-message-processor/logs/system.log

telnet MessageProcessor_IP 8082

nc -vz MessageProcessor_IP 8082

netstat -an > netstat.txt

curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions

curl -i http://localhost:8082/v1/classification/tree