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.
Truy cập vào tài liệu Apigee X. thông tin

Dấu hiệu

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 được bắt đầu:

Thông báo Lỗi

Khi vấn đề này xảy ra, không có thông báo lỗi nào xuất hiện trong giao diện người dùng Edge.

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

Bảng sau đây cho biết các nguyên nhân có thể dẫn đến việc không ghi lại được các yêu cầu API trong tính năng Theo dõi giao diện người dùng Edge:

Nguyên nhân: Yêu cầu không được Trình xử lý tin nhắn xử lý

Chẩn đoán

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

Ví dụ: nếu một yêu cầu API không đến được Apigee Edge, không thành công tại điểm truy cập vào Edge (tức là Router) hoặc gặp lỗi trước khi được Message Processor xử lý, thì dấu vết sẽ không được ghi lại. Mỗi trường hợp 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 Apigee Edge

• Nguyên nhân

  Trong trường hợp này, lỗi có thể là do vấn đề về khả năng phân giải DNS hoặ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 khả năng kết nối mạng bằng lệnh sau:

  telnet hostName port

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

• Nguyên nhân

  Trong trường hợp này, lỗi có thể là do không kết nối được với TLS/SSL. Nếu vậy, bạn có thể gặp phải 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 các hướng dẫn sau để 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: Bộ xử lý tin nhắn không xử lý được các yêu cầu

• Nguyên nhân

  Trong trường hợp này, Trình xử lý thông báo Apigee không tìm thấy API Proxy cho máy chủ ảo và đường dẫn được chỉ định. Do đó, bạn có thể gặp phải một trong 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

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

Nguyên nhân: Không tìm thấy API Proxy 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 một proxy API trong Cây phân loại, thì mọi yêu cầu API đế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 dưới đây để xác định xem có phải trường hợp này hay không:

1. Đăng nhập vào từng Trình xử lý thông báo 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 Trình xử lý thông báo hay không bằng cách sử dụng lệnh sau:

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

   Ví dụ về kết quả đầu ra:

   Lệnh trên sẽ xuất ra 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ừ phi gặp phải lỗi HTTP 404 không liên tục, nếu không, bạn có thể 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 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ông báo. 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, hãy làm theo giải pháp bên dưới.

Độ phân giải

Vui lòng 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 hoạt động sản xuất có thể xảy ra do khởi động lại Trình xử lý thông báo trong khi gặp phải tình trạng tải yêu cầu cao.

1. Đăng nhập vào từng máy chủ Message Processor bị thiếu proxy API cụ thể trong Classification Tree (Cây phân loại) và sử dụng lệnh bên dưới để khởi động lại Message Processor:

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

2. Sau khi khởi động lại, hãy dùng lệnh bên dưới để đợi cho đến khi thiết bị hoạt động:

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

3. Sau khi Message Processor sẵn sàng, hãy xác minh trạng thái sẵn sàng của API proxy bằng lệnh sau:

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

   Ví dụ về kết quả đầu ra:

   Lệnh trên sẽ xuất ra 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ừ phi gặp phải lỗi HTTP 404 không liên tục, nếu không, bạn có thể 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 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 Thông tin chẩn đoán bắt buộc.

Thông tin chẩn đoán bắt buộc phải thu thập

Nếu vấn đề vẫn tiếp diễn sau khi bạn làm theo hướng dẫn ở trên, vui lòng thu thập thông tin chẩn đoán sau đây và chia sẻ với Nhóm 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