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 khách sẽ nhận được mã trạng thái HTTP 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 làm phản hồi cho 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ủ lưu trữ ả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 thể 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

Dưới đâ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
Proxy API không được 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 công khai và riêng tư
Máy chủ ảo đã bị xoá trong một bản sửa đổi proxy API mới được triển khai 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 hoạt động việc sử dụng máy chủ ảo cụ thể có thể gây ra sự cố này. Người dùng Edge công khai và riêng tư
Đườ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 công khai và riêng tư
Proxy API không được triển khai trong 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 sử dụng cố gắng thực hiện các yêu cầu API. Người dùng Edge công khai và riêng tư
Môi trường không được tải trên Trình xử lý thư Môi trường cụ thể (nơi bạn đang cố thực hiện các yêu cầu API) không đã được tải trên Trình xử lý thư do 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ư Proxy API có thể không được triển khai 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ẽ 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 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 thư trong nhật ký.

  3. Kiểm tra nhật ký Trình xử lý thư (/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ể hoặc nếu bạn có giá trị duy nhất mã thông báo trong bước 2 đối với yêu cầu API.

    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 yêu cầu cho 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ó phải là định cấu hình để chấp nhận yêu cầu đối với máy chủ ảo được chỉ định trong lỗi. Đây là biểu thị bằng phần tử VirtualHost. Hãy cùng xem một ProxyEndpoint mẫu để hiểu điều này.

    Cấu hình Điểm cuối proxy mẫu cho thấy proxy API chấp nhận các yêu cầu trên 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 Bí danh máy chủ
    default 80 myorg-prod.apigee.net
    secure 443 myorg-prod.apigee.net
  3. Bạn gửi yêu cầu API đến default VirtualHost bằng URL này http://myorg-prod.apigee.net/weather
  4. Do ProxyEndpoint không có default VirtualHost như minh hoạ trong ví dụ ở trên, bạn nhận được mã phản hồi 404 với 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 đến mục đích 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 bị thiếu vào cấu hình ProxyEndpoint vào giải quyết vấn đề. Trong ví dụ nêu trên, bạn có thể thêm VirtualHost mặc định cho cấu hình ProxyEndpoint như sau: 
    <VirtualHost>default</VirtualHost>

    Cấu hình Điểm cuối proxy mẫu hiển thị giá trị mặc định> VirtualHost&gt; đang được thêm

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

Nguyên nhân: Máy chủ ảo đã bị xoá trong một 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ể (là một phần của bản sửa đổi đã triển khai trước đó), vẫn đang được ứng dụng sử dụng để đưa ra yêu cầu API thì 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ó phải là định cấu hình để chấp nhận yêu cầu đối với máy chủ ảo được chỉ định trong lỗi. Đây là 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 ProxyEndpoint cấu hình, sau đó 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 đượ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 cấu hình hiện tại được triển khai bản sửa đổi.
    1. Ví dụ: giả sử bản sửa đổi bạn đã triển khai trước đây là 5 và bản sửa đổi hiện được 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 sẽ 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 đến proxy API này bằng cách sử dụng VirtualHost vh1 (đó là một phần của revision 5), thì bạn sẽ nhận được Mã phản hồi 404 với 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 không vô tình trong bản sửa đổi đang được triển khai và 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ủ lưu trữ ảo bị xoá trong một bản sửa đổi mới, thì có thể là do có chủ ý hoặc do tai nạn. Đố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 đây để giải quyết vấn đề.

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

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

  1. Tạo 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 bạn muốn tiếp tục sử dụng proxy API hiện có nhưng dùng một máy chủ ảo khác, thì 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 đảm bảo rằng người dùng proxy API này không bị ảnh hưởng bởi 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 của mình 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 proxy API này biết về sự thay đổi này 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 đó, chúng sẽ không bị ảnh hưởng bởi thay đổi này.

Trường hợp 2: Thay đổi ngoài ý muốn

Trong trường hợp việc xoá máy chủ ảo được thực hiện do nhầm lẫn chứ không 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 được triển khai để sử dụng chính các 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 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 thấp nhất để có thể phát sinh mọi sự cố trong quá trình triển khai hoặc có thể 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 đối với đườ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 của proxy API cụ thể mà bạn muốn xác định để thực hiện 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 chỉ ra hay không trong thông báo lỗi. Bạn có thể làm điều 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 số 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 được chỉ ra trong thông báo lỗi không giống với basepath của proxy API cụ thể hoặc proxy đó không bắt đầu bằng basepath, thì proxy đó 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 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à có không được bắt đầu bằng basepath. Do đó, bạn 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ể là path suffix (phần đứng sau basepath) được chỉ ra trong thông báo lỗi không khớp với bất kỳ điều kiện nào thì 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 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 đ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 đế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ó luồng có điều kiện, hãy kiểm tra những mục sau:
    1. Nếu các điều kiện trong tất cả các quy trình 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, thì đó là nguyên nhân gây ra lỗi.
  7. Giả sử chúng ta có hai flow trong ProxyEndpoint và cả hai đều Luồng có điều kiện như sau: 
    <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, trong đó một luồng phù hợp proxy.pathsuffix (đường dẫn sau đường dẫn cơ sở) đến /Bangalore và một kết quả khác khớp với /Chennai. Nhưng không có kết quả nào phù hợp với /Delhi là path suffix được chuyển vào 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 flow 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ỳ bộ chính sách cụ thể nào cho đường dẫn /Delhi, thì hãy thêm một quy trình riêng với bộ chính sách bắt buộc và đảm bảo rằng có một điều kiện khớp với /proxy.pathsuffix /Delhi như minh hoạ dưới đây: 
      <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 luồng chung, hãy đảm bảo rằng có một điều kiện cho phép /proxy.pathsuffix. Nghĩa là 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, sau đó chuyển sang nguyên nhân tiếp theo – Proxy API không đượ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ột môi trường

Chẩn đoán

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

Độ 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 được tải trên Bộ xử lý thư

Chẩn đoán

  1. Đăng nhập vào từng Bộ xử lý thư và kiểm tra xem môi trường cụ thể mà bạn sử dụng đang thực hiện yêu cầu API sẽ được tải trên Trình xử lý thư 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ê như 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ư.
  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 vào Trình xử lý thông báo cho mọi lỗi trong quá trình tải môi trường.
  4. Có thể có nhiều lỗi khác nhau dẫn đến lỗi tải môi trường trên Trình xử lý thư. Giải pháp phụ thuộc vào lỗi đã xảy ra.

Độ phân giải

Có nhiều lý do vì môi trường có thể không được tải trên Trình xử lý thông báo. Phần này minh họa một vài 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 các lỗi sau trong nhật ký Trình xử lý thông báo thì đó là do lỗi đã phát hiện vấn đề với chứng chỉ/khoá đã được thêm vào kho khoá/kho tin cậy (truststore) đượ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á/đáng tin cậy được chỉ định trong thông báo lỗi xuất hiện trong bước trước đó bằng cách sử dụng lệnh gọi API quản lý sau đây: 
    curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user>

    Kết quả mẫu:

    {
   "certs":[
      "mycert",
      "mycert-new"
   ],
   "keys":[
      "mycert"
   ],
   "name":"myTruststore"
}
  3. Kết quả của ví dụ này cho thấy có hai chứng chỉ và một khoá trong kho tin cậy myTruststore. Kho tin cậy thường không chứa khoá. Nếu có, thì việc có một chứng chỉ và một khoá duy nhất sẽ hiệu quả hơn.
  4. Lấy thông tin chi tiết về 2 chứng chỉ 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 tin cậy myTruststore.

Nếu sự cố vẫn tiếp diễn hoặc nếu bạn thấy bất kỳ lỗi nào khác ngoài những lỗi được đề cập trong bước 1 ở trên, hãy chuyển đến mục Phải thu thập thông tin chẩn đoán.

Nguyên nhân: Không có proxy API được triển khai trên một hoặc nhiều Bộ xử lý thư

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

Độ phân giải

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

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

Chẩn đoán các sự cố bằng tính năng Giám sát API

Tính năng 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 các vấn đề về lỗi, hiệu suất và độ trễ cũng như nguồn của các lỗi, 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 phần Giám sát API > Điều tra và chọn ngày, proxy thích hợp, v.v. và bạn có thể thấy các 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ý

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

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

Nếu sự cố vẫn tiếp diễn ngay cả 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. Hãy liên hệ và chia sẻ thông tin này với Bộ phận 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 các 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
    • Kết quả đầu ra của các lệnh sau trên mỗi Bộ xử lý tin nhắn. 
      • 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.