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.
Chuyển đến tài liệu về Apigee X. thông tin

Triệu chứng

Ứng dụng sẽ nhận được mã trạng thái HTTP của 404 kèm theo 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 nghĩa là Edge không tìm thấy proxy API cho đường dẫn và máy chủ ảo đã chỉ định.

Thông báo lỗi

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

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ể xảy ra

Một số nguyên nhân có thể gây ra lỗi này được liệt kê dưới đây:

Nguyên nhân Nội dung mô tả Hướng dẫn khắc phục sự cố áp dụng cho
Proxy API không liên kết với máy chủ ảo cụ thể 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 và Private Cloud
Máy chủ ảo bị xoá trong bản sửa đổi proxy API mới được triển khai Việc xoá máy chủ ảo khỏi bản sửa đổi mới triển khai trong khi ứng dụng vẫn đang sử dụng máy chủ ảo cụ thể có thể gây ra sự cố này. Người dùng Edge Public 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ể chưa đượ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 và Private Cloud
Proxy API không được triển khai 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 và Private Cloud
Môi trường không được tải trên Bộ xử lý thông báo Môi trường cụ thể (trong đó bạn đang cố gắng đưa ra yêu cầu API) chưa tải được trên Bộ xử lý thông báo do có lỗi. Người dùng Edge Private Cloud
Proxy API chưa được triển khai trên một hoặc nhiều Bộ xử lý thư Có thể không triển khai được proxy API trên một hoặc nhiều Bộ xử lý thư 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 phổ biến

Nhật ký NGINX và Trình xử lý thư sẽ giúp ích khi khắc phục lỗi 404. 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 các 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ã nhận dạng tin nhắn trong nhật ký.

  3. Hãy kiểm tra nhật ký Trình xử lý thông báo (/opt/apigee/var/log/edge-message-processor/logs/system.log) để xem liệu 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 ở bước 2 cho yêu cầu API hay không).

    Thông báo lỗi mẫu trong nhật ký Trình xử lý thư

    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 proxy API không được định cấu hình để chấp nhận các yêu cầu từ máy chủ ảo cụ thể, thì chúng tôi 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 Điểm cuối 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 đối với 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 cấu hình ProxyEndpoint mẫu để hiểu rõ điều này.

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

  2. Giả sử máy chủ ảo được xác định trong môi trường cụ thể như sau:
    Tên Cổng Email đại diện của máy chủ lưu trữ
    default 80 myorg-prod.apigee.net
    secure 443 myorg-prod.apigee.net
  3. Bạn gửi yêu cầu API tới 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 như 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 đến nguyên nhân tiếp theo – Đường dẫn không liên kết với bất kỳ proxy API nào.

Độ phân giải

  1. Hãy thêm VirtualHost bị thiếu vào cấu hình ProxyEndpoint để giải quyết vấn đề này. Trong 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 proxy mẫu cho thấy chế độ mặc định> VirtualHost> đang được thêm

  2. Ngoài ra, trong ví dụ nêu trên, nếu bạn chỉ định sử dụng secure VirtualHost cho proxy API cụ thể này, hãy chỉ thực hiện các yêu cầu API tới 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 proxy API mới được triển khai

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

Chẩn đoán

  1. Kiểm tra cấu hình Điểm cuối proxy cho proxy API để xem proxy API có được định cấu hình để chấp nhận các yêu cầu đối với 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 đến nguyên nhân tiếp theo – Đường dẫn không 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 đã triển khai trước đó là 5 và bản sửa đổi hiện đã triển khai là 6:
      • Máy chủ ảo được định cấu hình trong Điểm cuối proxy trong 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 trong bản sửa đổi 6
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
    2. Trong ví dụ trên, VirtualHost vh1 đã tồn tại trong revision 5, nhưng bị xoá trong revision 6 và thay thế bằng VirtualHost secure.
    3. Vì vậy, nếu bạn hoặc khách hàng của bạn gửi yêu cầu tới 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. Hãy kiểm tra xem sự thay đổi máy chủ ảo được thực hiện có chủ ý hay vô tình trong bản sửa đổi đang được triển khai, và thực hiện các biện pháp thích hợp như giải thích trong phần Giải pháp.

Độ phân giải

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

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

Trong trường hợp cố ý xoá máy chủ ảo, thì bạn có thể chọn một trong các phương án sau đây (phương pháp đầu tiên đượ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 tồn tại trong bản sửa đổi đã triển khai trước đó).

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

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

  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, 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ì.

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

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

Trong trường hợp việc xoá máy chủ ảo là do nhầm lẫn 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 đã 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 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 luôn nên triển khai các proxy mới hoặc cá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 để có thể tránh được mọi sự cố phát sinh trong quá trình triển khai hoặc giảm thiểu tác độ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 proxy API không được định cấu hình để 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ì chúng tôi 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 các 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 nêu 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 thực hiện các bước trong Tình huống 1 và Tình huống 2.

Trường hợp 1: Đường dẫn không khớp với đường dẫn cơ sở của proxy API

  1. Nếu path chỉ ra trong thông báo lỗi không giống với basepath của 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 lấy một ví dụ để giải thích điều này:
    1. basepath của proxy API dự định là /weather
    2. URL yêu cầu API là https://myorg-prod.apigee.net/climate. Tức là đường dẫn được sử 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 path dùng trong URL yêu cầu API giống với basepath của proxy API cụ thể.
  2. Trong ví dụ trên, URL yêu cầu API phải có dạng như sau:
    {
https://myorg-prod.apigee.net/weather

Trường hợp 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 dùng trong URL yêu cầu API bắt đầu bằng basepath, thì có thể path suffix (phần đứng sau basepath) chỉ định 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 này có thể gây ra lỗi 404.
  2. Hãy lấy một ví dụ giải thích về điều này:
    1. basepath của proxy API dự định là /weather
    2. URL yêu cầu API là https://myorg-prod.apigee.net/weather/Delhi. Tức là đường dẫn được sử 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, tệp này còn có 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 điều kiện, hãy chuyển đến nguyên nhân tiếp theo – Proxy API không được triển khai trong một môi trường.
  6. Nếu ProxyEndpoint chỉ có các luồng 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ì đó chính là nguyên nhân gây ra lỗi.
  7. Giả sử chúng ta có hai 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ụ 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 đường dẫn cơ sở) với /Bangalore và luồng còn lại khớp với /Chennai. Nhưng không có sản phẩm nào khớp với /Delhi chính là path suffix được chuyể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 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ể áp dụng các phương pháp sau để khắc phục 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 quy trình riêng cùng với bộ chính sách bắt buộc và đảm bảo có một điều kiện khớ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 bộ chính sách chung cho đường dẫn /Delhi, thì trong luồng chung, hãy đảm bảo có một điều kiện cho phép /proxy.pathsuffix chung. Điều này có nghĩa là hàm này 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ông 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 – Proxy API chưa được triển khai trong một môi trường.

Nguyên nhân: proxy API không được triển khai trong môi trường

Chẩn đoán

  1. Xác định môi trường tồn tại của bí danh máy chủ lưu trữ được sử 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 về 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ử 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à bí danh của máy chủ lưu trữ.
    • Bí danh máy chủ myorg-prod.apigee.net được định cấu hình là một trong những máy chủ ảo trong môi trường prod của tổ chức bạn.
  2. Kiểm tra xem proxy API cụ thể có được triển khai trong môi trường cụ thể được xác định ở bước 1 ở trên hay không.
  3. Nếu proxy API không được triển khai trong môi trường cụ thể, thì đó chính là nguyên nhân gây ra lỗi 404.
    1. Vì vậy, trong ví dụ ở bước 1 ở trên, giả sử proxy API không được triển khai trong môi trường prod, thì đó chính 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 đến nguyên nhân tiếp theo – Môi trường không 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 đưa ra yêu cầu API.

Nguyên nhân: Môi trường không tải trên Bộ xử lý thư

Chẩn đoán

  1. Đăng nhập vào từng Bộ xử lý thông báo 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 Bộ xử lý thông báo hay không bằng cách dù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ê là một phần của lệnh trên, thì hãy chuyển đến nguyên nhân tiếp theo – Proxy API chưa được triển khai trên một hoặc nhiều Bộ 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 để tìm lỗi trong quá trình tải môi trường.
  4. Có nhiều lỗi có thể dẫn đến việc không tải được môi trường trên Bộ xử lý thông báo. Cách giải quyết phụ thuộc vào lỗi đã xảy ra.

Độ phân giải

Môi trường có thể không tải được trên Bộ xử lý thư vì nhiều lý do. 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.

  1. Nếu bạn thấy một trong các lỗi sau trong nhật ký Trình xử lý thông báo, thì đó là do có vấn đề xảy ra với các chứng chỉ/khoá đã được thêm vào 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

    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 #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á/truststore được chỉ định trong thông báo lỗi hiển thị ở 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>

    Kết quả ví dụ:

    {
   "certs":[
      "mycert",
      "mycert-new"
   ],
   "keys":[
      "mycert"
   ],
   "name":"myTruststore"
}
  3. Kết quả ví dụ cho thấy có 2 chứng chỉ và một khoá trong Truststore myTruststore. Truststore thường 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. Xem thông tin chi tiết về 2 chứng chỉ này bằ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ũ.
  6. Xoá chứng chỉ đã hết hạn hoặc không mong muốn khỏi kho lưu trữ tin cậy myTruststore.

Nếu vấn đề vẫn tiếp diễn hoặc nếu bạn thấy lỗi khác với những lỗi đã nêu 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: proxy API chưa được triển khai trên một hoặc nhiều Bộ xử lý thư

Không thể triển khai proxy API trên một hoặc nhiều Bộ xử lý thư. Vấn đề này rất hiếm khi xảy ra và chủ yếu xảy ra do thiếu thông báo sự kiện từ Máy chủ quản lý tới Đơn vị xử lý thông báo trong quá trình triển khai proxy API cụ thể. Trong trường hợp này, bạn 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 Bộ 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 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 proxy API không xuất hiện dưới dạng kết quả của lệnh nêu trong bước 1 ở trên, hãy khởi động lại Bộ xử lý thông báo cụ thể như giải thích trong phần Độ phân giải.
  3. Lặp lại các bước từ 1 đến 2 cho tất cả các Bộ xử lý thư.
  4. Nếu bản sửa đổi cụ thể của proxy API được triển khai trên tất cả Bộ xử lý thông báo, thì đây không phải là nguyên nhân của sự cố này. Chuyển đến mục Phải thu thập thông tin chẩn đoán.

Độ phân giải

Khởi động lại Bộ xử lý thông báo cụ thể mà tại đó bản sửa đổi cụ thể của proxy API không đượ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

Giám sát API giúp bạn nhanh chóng tách biệt 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ư các nguồn liên quan, chẳng hạn như ứng dụng dành cho 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 Giám sát API > Điều tra và chọn ngày, proxy thích hợp, v.v. Bạn có thể xem các thông tin chi tiết sau đây:

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 rồi kiểm tra thêm.

xem nhật ký

Các bước xem tình huống mẫu minh hoạ cách khắc phục các vấn đề về 5xx xảy ra với API bằng tính năng Giám sát API. Ví dụ: có thể bạn 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 sau khi làm theo hướng dẫn ở trên, hãy thu thập các 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.

  1. 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 curl để tái hiện lỗi
  2. 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
    • Tên môi trường
    • Gói proxy API
    • Nhật ký Trình xử lý thư /opt/apigee/var/log/edge-message-processor/logs/system.log
    • Xuất 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 mà bạn đã thử trong cẩm nang này 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.