404 Không thể xác định proxy cho máy chủ: <tên máy chủ ảo> và url: <path>

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 mã trạng thái HTTP là 404 cùng với thông báo Not Found và thông báo lỗi Unable to identify proxy for host: VIRTUAL_HOST and url: PATH dưới dạng phản hồi cho các lệnh gọi API.

Lỗi này có nghĩa là Edge không tìm thấy proxy API cho máy chủ ảo và đường dẫn đã chỉ định.

Thông báo Lỗi

Bạn sẽ nhận được mã trạng thái HTTP sau: 

HTTP/1.1 404 Not Found

Bạn cũng sẽ thấy một thông báo lỗi tương tự như thông báo dưới đây: 

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

Thông báo lỗi ở trên cho biết Edge không tìm thấy proxy API cho máy chủ ảo default và đường dẫn /oauth2/token.

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

Sau đây là một số nguyên nhân có thể gây ra lỗi này:

Nguyên nhân Mô tả Hướng dẫn khắc phục sự cố áp dụng cho
API proxy not associated with the specific virtual host Proxy API cụ thể không được định cấu hình để chấp nhận các yêu cầu trên máy chủ ảo được chỉ định trong thông báo lỗi. Người dùng Edge Public Cloud và Private Cloud
Máy chủ ảo bị xoá trong bản sửa đổi mới triển khai của proxy API Việc xoá máy chủ ảo khỏi bản sửa đổi mới triển khai trong khi máy khách vẫn đang sử dụng máy chủ ảo cụ thể có thể gây ra vấn đề này. Người dùng Edge Public Cloud và Private Cloud
Đường dẫn không được liên kết với bất kỳ proxy API nào Proxy API cụ thể không được định cấu hình để chấp nhận các yêu cầu trên đường dẫn được chỉ định trong thông báo lỗi. Người dùng Edge Public Cloud và Private Cloud
Chưa triển khai proxy API trong một môi trường Proxy API cụ thể không được triển khai trong môi trường cụ thể mà bạn đang cố gắng đưa ra yêu cầu API. Người dùng Edge Public Cloud và Private Cloud
Môi trường không được tải trên Trình xử lý tin nhắn Môi trường cụ thể (nơi bạn đang cố gắng thực hiện các yêu cầu API) chưa được tải trên Bộ xử lý thông báo do xảy ra lỗi. Người dùng Edge Private Cloud
Chưa triển khai proxy API trên một hoặc nhiều Trình xử lý thông báo Có thể proxy API không được triển khai trên một hoặc nhiều Trình xử lý thông báo do thiếu thông báo sự kiện trong quá trình triển khai. Người dùng Edge Private Cloud

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

Nhật ký NGINX và Trình xử lý thông báo sẽ hữu ích trong việc khắc phục lỗi 404. Hãy làm theo các bước sau để kiểm tra nhật ký:

  1. Xem nhật ký NGINX bằng lệnh sau: 
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  2. Kiểm tra các trường sau trong mục nhập nhật ký:
    Trường Giá trị
    Upstream_status, status 404
    X-Apigee-fault-code messaging.adaptors.http.flow.ApplicationNotFound

    Ghi lại mã thư trong nhật ký.

  3. Kiểm tra nhật ký Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) để xem bạn có messaging.adaptors.http.flow.ApplicationNotFound cho API cụ thể hay không hoặc bạn có mã nhận dạng thông báo duy nhất từ bước 2 cho yêu cầu API hay không.

    Thông báo lỗi mẫu trong nhật ký Message Processor

    4. NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractRequestListener.onException() : Request:POST, uri:/weather, message Id:null, exception:com.apigee.rest.framework.ResourceNotFoundException{ code = messaging.adaptors.http.flow.ApplicationNotFound, message = Unable to identify proxy for host: vh1 and url: /weather, associated contexts = []}, context:Context@342ea86b input=ClientInputChannel(SSLClientChannel[Accepted: Remote:10.123.123.123:8443 Local:10.135.33.68:62092]@1206954 useCount=1 bytesRead=0 bytesWritten=0 age=1ms  lastIO=0ms  isOpen=true)

    Nhật ký ở trên cho thấy mã lỗi và thông báo lỗi như sau:

    code = messaging.adaptors.http.flow.ApplicationNotFound,
message = Unable to identify proxy for host: vh1 and url: /weather

Nguyên nhân: Proxy API không được liên kết với máy chủ ảo cụ thể

Nếu bạn không định cấu hình proxy API để chấp nhận các yêu cầu cho máy chủ ảo cụ thể, thì chúng ta có thể nhận được phản hồi 404 Not Found kèm theo thông báo lỗi Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Chẩn đoán

  1. Kiểm tra cấu hình Proxy Endpoint (Điểm cuối của proxy) cho proxy API và xem proxy API có được định cấu hình để chấp nhận các yêu cầu cho máy chủ ảo được chỉ định trong lỗi hay không. Điều này được biểu thị bằng phần tử VirtualHost. Hãy xem một cấu hình ProxyEndpoint mẫu để hiểu rõ điều này.

    Cấu hình Điểm cuối của Proxy mẫu cho thấy rằng proxy API chấp nhận các yêu cầu trên một máy chủ ảo bảo mật

  2. Giả sử các máy chủ ảo được xác định trong môi trường cụ thể như sau:
    Tên Cổng Bí danh máy chủ lưu trữ
    default 80 myorg-prod.apigee.net
    secure 443 myorg-prod.apigee.net
  3. Bạn đưa ra yêu cầu API đến default VirtualHost bằng URL http://myorg-prod.apigee.net/weather
  4. Vì ProxyEndpoint không có default VirtualHost như minh hoạ trong ví dụ ở trên, nên bạn sẽ nhận được mã phản hồi 404 kèm theo thông báo lỗi sau: 
    {"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  5. Hãy chuyển đến phần Giải pháp bên dưới để giải quyết vấn đề này.
  6. Nếu ProxyEndpoint được định cấu hình để chấp nhận các yêu cầu trên default VirtualHost, hãy chuyển sang nguyên nhân tiếp theo – Đường dẫn không được liên kết với bất kỳ proxy API nào.

Độ phân giải

  1. Thêm VirtualHost còn thiếu vào cấu hình ProxyEndpoint để giải quyết vấn đề. Đối với ví dụ nêu trên, bạn có thể thêm VirtualHost mặc định vào cấu hình ProxyEndpoint như sau: 
    <VirtualHost>default</VirtualHost>

    Cấu hình Điểm cuối của Proxy mẫu cho thấy VirtualHost mặc định đang được thêm

  2. Ngoài ra, trong ví dụ được đề cập ở trên, nếu bạn chỉ định sử dụng secure VirtualHost cho proxy API cụ thể này, thì chỉ gửi các yêu cầu API đến secure VirtualHost bằng giao thức HTTPS: 
    https://myorg-prod.apigee.net/weather

Nguyên nhân: Máy chủ ảo bị xoá trong bản sửa đổi mới triển khai của proxy API

Nếu một bản sửa đổi mới của một proxy API được triển khai sau khi xoá một máy chủ ảo cụ thể (là một phần của bản sửa đổi đã triển khai trước đó), thì máy chủ ảo đó vẫn được các ứng dụng sử dụng để đưa ra yêu cầu API, điều này có thể gây ra vấn đề này.

Chẩn đoán

  1. Kiểm tra cấu hình Proxy Endpoint (Điểm cuối của proxy) cho API proxy để xem API proxy có được định cấu hình để chấp nhận các yêu cầu cho máy chủ ảo được chỉ định trong lỗi hay không. Điều này được biểu thị bằng phần tử VirtualHost trong cấu hình ProxyEndpoint.
  2. Nếu máy chủ ảo được chỉ định trong lỗi không tồn tại trong cấu hình ProxyEndpoint, hãy thực hiện các bước sau. Nếu không, hãy chuyển sang nguyên nhân tiếp theo – Đường dẫn không được liên kết với bất kỳ proxy API nào.
  3. So sánh cấu hình ProxyEndpoint của bản sửa đổi đã triển khai trước đó với bản sửa đổi hiện được triển khai.
    1. Ví dụ: giả sử bản sửa đổi bạn đã triển khai trước đó là 5 và bản sửa đổi bạn hiện đang triển khai là 6:
      • Máy chủ ảo được định cấu hình trong Điểm cuối của proxy ở bản sửa đổi 5
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
      • Máy chủ ảo được định cấu hình trong Điểm cuối proxy ở bản sửa đổi 6
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
    2. Trong ví dụ trên, VirtualHost vh1 có trong revision 5, nhưng bị xoá trong revision 6 và được thay thế bằng VirtualHost secure.
    3. Vì vậy, nếu bạn hoặc khách hàng của bạn đang gửi yêu cầu đến proxy API này bằng VirtualHost vh1 (thuộc revision 5), thì bạn sẽ nhận được mã phản hồi 404 kèm theo thông báo lỗi sau: 
      {"fault":{"faultstring":"Unable to identify proxy for host: vh1 and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  4. Kiểm tra xem thay đổi máy chủ ảo có được thực hiện cố ý hay vô tình trong bản sửa đổi hiện đang được triển khai hay không, rồi thực hiện các biện pháp thích hợp như được giải thích trong phần Giải pháp.

Độ phân giải

Nếu bạn xác định rằng (các) máy chủ ảo đã bị xoá trong một bản sửa đổi mới, thì đó có thể là hành động cố ý hoặc vô tình. Đối với mỗi trường hợp, hãy thực hiện các bước giải quyết/đề xuất sau đây để giải quyết vấn đề.

Tình huống 1: Thay đổi có chủ ý

Trong trường hợp bạn cố ý xoá máy chủ ảo, bạn có thể chọn một trong các lựa chọn sau. Lựa chọn đầu tiên là phương pháp được đề xuất:

  1. Tạo một proxy mới có đường dẫn cơ sở khác và sử dụng một máy chủ ảo khác (không có trong bản sửa đổi đã triển khai trước đó).

  2. Nếu bạn muốn tiếp tục sử dụng API proxy hiện có nhưng sử dụng một máy chủ ảo khác, thì tốt hơn là bạn nên giữ lại máy chủ ảo hiện có và thêm máy chủ ảo bổ sung.

    Điều này sẽ đảm bảo rằng người dùng của proxy API này không bị ảnh hưởng bởi thay đổi.

  3. Nếu bạn muốn sử dụng proxy API hiện có và chỉ có một máy chủ ảo khác, thì hãy thông báo trước cho người dùng và thực hiện thay đổi này trong thời gian bảo trì.

    Điều này sẽ đảm bảo rằng người dùng của proxy API này biết về thay đổi và họ có thể sử dụng một máy chủ ảo khác để thực hiện các lệnh gọi đến proxy API này. Do đó, những người dùng này sẽ không bị ảnh hưởng bởi thay đổi này.

Tình huống 2: Thay đổi ngoài ý muốn

Trong trường hợp bạn vô tình xoá máy chủ ảo chứ không phải cố ý,hãy làm như sau:

  1. Cập nhật cấu hình ProxyEndpoint trong bản sửa đổi hiện đang được triển khai để sử dụng cùng một máy chủ ảo đã được dùng trong bản sửa đổi đã triển khai trước đó. Trong ví dụ trên, hãy thay đổi phần sau đây từ: 
    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

    tới

    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
  2. Triển khai lại bản sửa đổi.

Các phương pháp hay nhất

Bạn nên triển khai các proxy mới hoặc bản sửa đổi mới trong thời gian bảo trì hoặc khi lưu lượng truy cập dự kiến ở mức thấp nhất để tránh mọi vấn đề phát sinh trong quá trình triển khai hoặc giảm thiểu ảnh hưởng đến lưu lượng truy cập.

Nguyên nhân: Đường dẫn không được liên kết với bất kỳ proxy API nào

Nếu bạn không định cấu hình API proxy để chấp nhận các yêu cầu cho đường dẫn cụ thể được dùng trong URL yêu cầu API, thì bạn có thể nhận được phản hồi 404 Not Found kèm theo thông báo lỗi Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Chẩn đoán

  1. Xem cấu hình ProxyEndpoint cho proxy API cụ thể mà bạn dự định đưa ra yêu cầu API.
  2. Kiểm tra xem proxy API có được định cấu hình để chấp nhận các yêu cầu cho đường dẫn cụ thể được chỉ ra trong thông báo lỗi hay không. Bạn có thể thực hiện việc này bằng cách làm theo các bước trong Tình huống 1 và Tình huống 2.

Tình huống 1: Đường dẫn không khớp với basepath của API proxy

  1. Nếu path được chỉ ra trong thông báo lỗi không giống với basepath của một proxy API cụ thể hoặc không bắt đầu bằng basepath, thì đó có thể là nguyên nhân gây ra lỗi.
  2. Hãy xem một ví dụ để giải thích điều này:
    1. basepath của proxy API dự kiến là /weather
    2. URL yêu cầu API là https://myorg-prod.apigee.net/climate. Điều này có nghĩa là đường dẫn được dùng trong URL yêu cầu API là /climate.
  3. Trong ví dụ này, path không giống với basepath và không bắt đầu bằng basepath. Do đó, bạn sẽ gặp lỗi sau: 
    {
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/climate",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

Độ phân giải

  1. Đảm bảo rằng path được dùng trong URL yêu cầu API của bạn giống với basepath của một proxy API cụ thể.
  2. Trong ví dụ trên, URL yêu cầu API phải như sau: 
    {
https://myorg-prod.apigee.net/weather

Tình huống 2: Đường dẫn không khớp với bất kỳ luồng có điều kiện nào hiện có

  1. Nếu path được dùng trong URL yêu cầu API bắt đầu bằng basepath, thì có thể path suffix (phần xuất hiện sau basepath) được chỉ ra trong thông báo lỗi không khớp với bất kỳ luồng có điều kiện nào, thì điều đó có thể gây ra lỗi 404.
  2. Hãy xem một ví dụ để giải thích điều này:
    1. basepath của proxy API dự kiến là /weather
    2. URL yêu cầu API là https://myorg-prod.apigee.net/weather/Delhi. Điều này có nghĩa là đường dẫn được dùng trong URL yêu cầu API là /weather/Delhi.
  3. Trong ví dụ này, path bắt đầu bằng basepath /weather. Ngoài ra, nó có một path suffix là /Delhi.
  4. Bây giờ, hãy kiểm tra xem có luồng có điều kiện nào trong ProxyEndpoint hay không.
  5. Nếu không có luồng có điều kiện hoặc có một vài luồng không có điều kiện, hãy chuyển sang nguyên nhân tiếp theo – Proxy API chưa được triển khai trong một môi trường.
  6. Nếu ProxyEndpoint chỉ có các quy trình có điều kiện, hãy kiểm tra những điều sau:
    1. Nếu các điều kiện trong tất cả các luồng có điều kiện này kiểm tra một proxy.pathsuffix cụ thể (đường dẫn sau đường dẫn cơ sở).
    2. Và nếu path suffix được chỉ định trong URL yêu cầu API không khớp với bất kỳ điều kiện nào, thì đó là nguyên nhân gây ra lỗi.
  7. Giả sử chúng ta có 2 luồng trong ProxyEndpoint và cả hai đều là luồng có điều kiện như minh hoạ dưới đây: 
    <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>

<Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
    1. Trong ví dụ minh hoạ ở trên, chúng ta có 2 luồng có điều kiện, một luồng khớp với proxy.pathsuffix (đường dẫn sau basepath) với /Bangalore và luồng còn lại khớp với /Chennai. Nhưng không có mẫu nào khớp với /Delhi. Đây là path suffix được truyền trong URL yêu cầu API.
    2. Đây là nguyên nhân gây ra lỗi 404. Do đó, bạn sẽ gặp lỗi sau: 
      {
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

Độ phân giải

  1. Đảm bảo rằng path suffix khớp với ít nhất một trong các luồng có điều kiện trong điểm cuối proxy của bạn.
  2. Trong ví dụ trên, bạn có thể sử dụng một trong các phương pháp sau để giải quyết lỗi:
    1. Nếu bạn muốn thực thi bất kỳ nhóm chính sách cụ thể nào cho đường dẫn /Delhi, hãy thêm một luồng riêng biệt với nhóm chính sách bắt buộc và đảm bảo có một điều kiện phù hợp với /proxy.pathsuffix /Delhi như minh hoạ bên dưới: 
      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>
    2. Nếu bạn muốn thực thi một nhóm chính sách chung cho đường dẫn /Delhi, thì trong quy trình chung, hãy đảm bảo rằng có một điều kiện cho phép /proxy.pathsuffix chung. Tức là nó sẽ cho phép mọi đường dẫn sau basepath /weather như minh hoạ dưới đây: 
      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

Nếu ProxyEndpoint có basepath chính xác và path suffix được chỉ định trong URL API khớp với một trong các luồng có điều kiện, thì hãy chuyển sang nguyên nhân tiếp theo – Chưa triển khai proxy API trong một môi trường.

Nguyên nhân: Proxy API chưa được triển khai trong một môi trường

Chẩn đoán

  1. Xác định môi trường mà bí danh máy chủ lưu trữ được dùng trong URL yêu cầu API của bạn. Bạn có thể thực hiện việc này bằng cách kiểm tra thông tin chi tiết của tất cả máy chủ ảo trong từng môi trường của tổ chức trong giao diện người dùng Edge.

    Ví dụ: giả sử bạn có cấu hình sau:

    • Nếu http://myorg-prod.apigee.net/weather là URL của bạn, thì myorg-prod.apigee.net là tên thay thế của máy chủ lưu trữ.
    • Bí danh máy chủ lưu trữ myorg-prod.apigee.net được định cấu hình trong một trong các máy chủ lưu trữ ảo trong môi trường prod của tổ chức bạn.
  2. Kiểm tra để xem liệu proxy API cụ thể có được triển khai trong môi trường cụ thể được xác định ở bước 1 nêu trên hay không.
  3. Nếu API proxy không được triển khai trong môi trường cụ thể, thì đó là nguyên nhân gây ra lỗi 404.
    1. Vì vậy, trong ví dụ được dùng ở bước 1 nêu trên, giả sử proxy API không được triển khai trong môi trường prod, thì đó là nguyên nhân gây ra lỗi.
    2. Chuyển đến phần Giải pháp bên dưới.
  4. Nếu proxy API được triển khai trong môi trường cụ thể, hãy chuyển sang nguyên nhân tiếp theo – Môi trường không được tải trên Bộ xử lý thông báo.

Độ phân giải

Triển khai proxy API trong môi trường cụ thể mà bạn dự định gửi yêu cầu API.

Nguyên nhân: Môi trường không được tải trên Trình xử lý tin nhắn

Chẩn đoán

  1. Đăng nhập vào từng Trình xử lý tin nhắn và kiểm tra xem môi trường cụ thể mà bạn đang thực hiện yêu cầu API có được tải trên Trình xử lý tin nhắn hay không bằng lệnh sau: 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
  2. Nếu môi trường cụ thể được liệt kê trong lệnh trên, hãy chuyển sang nguyên nhân tiếp theo – Chưa triển khai proxy API trên một hoặc nhiều Trình xử lý thông báo.
  3. Nếu môi trường cụ thể không có trong danh sách, hãy kiểm tra /opt/apigee/var/log/edge-message-processor/logs/system.log và /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log trên Trình xử lý thông báo để xem có lỗi nào trong quá trình tải môi trường hay không.
  4. Có thể có nhiều lỗi khác nhau dẫn đến việc không tải được môi trường trên Trình xử lý thông báo. Cách giải quyết tuỳ thuộc vào lỗi đã xảy ra.

Độ phân giải

Có nhiều lý do khiến Môi trường không được tải trên Trình xử lý thông báo. Phần này minh hoạ một số lý do có thể dẫn đến vấn đề này và giải thích cách giải quyết vấn đề.

  1. Nếu bạn thấy một trong những lỗi sau đây trong nhật ký Message Processor, thì lỗi đó là do vấn đề xảy ra với các chứng chỉ/khoá đã được thêm vào kho khoá/kho tin cậy được chỉ định trong môi trường được chỉ định.

    Lỗi 1: java.security.KeyStoreException: Không thể ghi đè chứng chỉ của riêng mình

    2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na]
at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na]
…
Caused by: java.security.KeyStoreException: Cannot overwrite own certificate
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151]
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151]
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]

    ... 20 common frames omitted

    2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

    Lỗi số 2: java.security.KeyStoreException: Không thể ghi đè khoá bí mật

    2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
...
Caused by: java.security.KeyStoreException: Cannot overwrite secret key
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144]
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144]
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
... 20 common frames omitted

2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert
  2. Lấy thông tin chi tiết về kho khoá/kho lưu trữ đáng tin cậy được chỉ định trong thông báo lỗi xuất hiện ở bước trước bằng cách sử dụng lệnh gọi API quản lý sau: 
    curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user>

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

    {
   "certs":[
      "mycert",
      "mycert-new"
   ],
   "keys":[
      "mycert"
   ],
   "name":"myTruststore"
}
  3. Kết quả đầu ra mẫu cho thấy có 2 chứng chỉ và một khoá trong truststore myTruststore. Thông thường, truststore không chứa khoá. Nếu có, bạn nên có một chứng chỉ và một khoá duy nhất.
  4. Lấy thông tin chi tiết về 2 chứng chỉ bằng cách sử dụng API sau: 
    curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
  5. Kiểm tra ngày hết hạn của từng chứng chỉ và xác định chứng chỉ đã hết hạn/cũ hơn.
  6. Xoá chứng chỉ không mong muốn hoặc đã hết hạn khỏi kho lưu trữ đáng tin cậy myTruststore.

Nếu vấn đề vẫn tiếp diễn hoặc nếu bạn gặp phải lỗi khác với những lỗi được đề cập trong bước 1 ở trên, hãy chuyển đến phần Phải thu thập thông tin chẩn đoán.

Nguyên nhân: API proxy chưa được triển khai trên một hoặc nhiều Trình xử lý thông báo

Có thể bạn chưa triển khai API proxy trên một hoặc nhiều Trình xử lý thông báo. Vấn đề này rất hiếm khi xảy ra và chủ yếu là do Thông báo sự kiện bị thiếu từ Máy chủ quản lý đến Trình xử lý thông báo trong quá trình triển khai một proxy API cụ thể. Trong trường hợp này, bạn cũng sẽ không thể tạo phiên theo dõi trong giao diện người dùng Edge.

Chẩn đoán

  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 proxy API đã được triển khai hay chưa bằng cách sử dụng lệnh sau: 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  2. Nếu bản sửa đổi cụ thể của API proxy không xuất hiện dưới dạng đầu ra của lệnh được đề cập trong bước 1 ở trên, hãy khởi động lại Message Processor cụ thể như giải thích trong phần Giải pháp.
  3. Lặp lại các bước 1 và 2 cho tất cả Trình xử lý thông báo.
  4. Nếu bản sửa đổi cụ thể của API proxy được triển khai trên tất cả các Trình xử lý thông báo, thì đây không phải là nguyên nhân gây ra vấn đề này. Chuyển đến phần Phải thu thập thông tin chẩn đoán.

Độ phân giải

Khởi động lại các Trình xử lý thông báo cụ thể mà bản sửa đổi cụ thể của API proxy chưa được triển khai.

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

Chẩn đoán vấn đề bằng tính năng Giám sát API

Tính năng Giám sát API cho phép bạn nhanh chóng cô lập các khu vực có vấn đề để chẩn đoán lỗi, hiệu suất và các vấn đề về độ trễ cũng như nguồn của các vấn đề đó, chẳng hạn như ứng dụng của nhà phát triển, proxy API, mục tiêu phụ trợ hoặc nền tảng API.

Đối với vấn đề này, bạn có thể chuyển đến trang API Monitoring > Investigate (Giám sát API > Điều tra) rồi chọn ngày, proxy, v.v. thích hợp. Bạn có thể thấy các thông tin chi tiết sau:

Mã lỗi và mã trạng thái trong giao diện người dùng

  • Mã lỗi: messaging.adaptors.http.flow.ApplicationNotFound
  • Mã trạng thái: 404
  • Nguồn lỗi: Apigee hoặc MP

Ngoài ra, bạn có thể nhấp vào Xem nhật ký như trong ảnh chụp màn hình ở trên để kiểm tra thêm.

xem nhật ký

Bước qua một kịch bản mẫu minh hoạ cách khắc phục sự cố 5xx với các API bằng tính năng Giám sát API. Ví dụ: bạn có thể muốn thiết lập một cảnh báo để nhận thông báo khi số lượng mã trạng thái 404 vượt quá một ngưỡng cụ thể.

Phải thu thập thông tin chẩn đoán

Nếu vấn đề vẫn tiếp diễn ngay cả sau khi bạn làm theo hướng dẫn ở trên, hãy thu thập thông tin chẩn đoán sau đây. Hãy liên hệ và chia sẻ thông tin này với Nhóm hỗ trợ Apigee Edge.

  1. 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 proxy API
    • Hoàn tất lệnh curl để tái tạo lỗi
  2. 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
    • Tên môi trường
    • Gói proxy API
    • Nhật ký Bộ xử lý tin nhắn /opt/apigee/var/log/edge-message-processor/logs/system.log
    • Đầu ra của các lệnh sau trên mỗi Bộ xử lý thông báo. 
      • curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
       
      curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  3. Thông tin chi tiết về những phần trong sách hướng dẫn này mà bạn đã thử và mọi thông tin chi tiết khác sẽ giúp chúng tôi nhanh chóng giải quyết vấn đề này.