404 قادر به شناسایی پروکسی برای میزبان نیست: <نام میزبان مجازی> و آدرس اینترنتی: <path>

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

علامت

برنامه‌ی کلاینت، کد وضعیت HTTP 404 را به همراه پیام Not Found و پیام خطای Unable to identify proxy for host: VIRTUAL_HOST and url: PATH به عنوان پاسخی به فراخوانی‌های API دریافت می‌کند.

این خطا به این معنی است که Edge نتوانسته پروکسی API را برای میزبان مجازی و مسیر مشخص شده پیدا کند.

پیام خطا

کد وضعیت HTTP زیر را دریافت خواهید کرد:

HTTP/1.1 404 Not Found

همچنین یک پیام خطا مشابه آنچه در زیر نشان داده شده است مشاهده خواهید کرد:

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

پیام خطای فوق نشان می‌دهد که Edge نتوانسته پروکسی API را برای میزبان مجازی default و مسیر /oauth2/token پیدا کند.

علل احتمالی

برخی از دلایل احتمالی این خطا در زیر ذکر شده است:

علت توضیحات دستورالعمل‌های عیب‌یابی قابل اجرا برای
پروکسی API با میزبان مجازی خاص مرتبط نیست پروکسی API خاص برای پذیرش درخواست‌ها روی میزبان مجازی مشخص شده در پیام خطا پیکربندی نشده است. کاربران فضای ابری عمومی و خصوصی Edge
میزبان مجازی در نسخه جدید پروکسی API که به تازگی مستقر شده است، حذف شد. حذف میزبان مجازی از نسخه جدید پیاده‌سازی شده در حالی که کلاینت هنوز از میزبان مجازی خاص استفاده می‌کند، می‌تواند باعث این مشکل شود. کاربران فضای ابری عمومی و خصوصی Edge
مسیر با هیچ پروکسی API مرتبط نیست پروکسی API خاص برای پذیرش درخواست‌ها در مسیر مشخص شده در پیام خطا پیکربندی نشده است. کاربران فضای ابری عمومی و خصوصی Edge
پروکسی API در محیطی مستقر نشده است پروکسی API خاص در محیط خاصی که شما سعی در ایجاد درخواست‌های API دارید، مستقر نشده است. کاربران فضای ابری عمومی و خصوصی Edge
محیط روی پردازشگر پیام بارگذاری نشده است محیط خاص (که در آن سعی در ایجاد درخواست‌های API دارید) به دلیل وجود خطا، روی پردازنده‌های پیام بارگذاری نشده است. کاربران فضای ابری خصوصی اج
پروکسی API روی یک یا چند پردازنده پیام مستقر نشده است ممکن است پروکسی API به دلیل عدم اطلاع‌رسانی رویداد در حین استقرار، روی یک یا چند پردازنده پیام مستقر نشود. کاربران فضای ابری خصوصی اج

مراحل تشخیص مشترک

گزارش‌های NGINX و Message Processor در عیب‌یابی خطای 404 مفید خواهند بود. برای بررسی گزارش‌ها از مراحل زیر استفاده کنید:

  1. با استفاده از دستور زیر، لاگ‌های NGINX را مشاهده کنید:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  2. فیلدهای زیر را در ورودی‌های لاگ بررسی کنید:
    میدان ارزش
    Upstream_status, status 404
    X-Apigee-fault-code messaging.adaptors.http.flow.ApplicationNotFound

    شناسه پیام را از گزارش‌ها یادداشت کنید.

  3. لاگ‌های پردازشگر پیام ( /opt/apigee/var/log/edge-message-processor/logs/system.log) را بررسی کنید تا ببینید آیا messaging.adaptors.http.flow.ApplicationNotFound برای API خاص دارید یا اینکه آیا شناسه پیام منحصر به فرد از مرحله 2 را برای درخواست API دارید یا خیر.

    نمونه پیام خطا از گزارش پردازشگر پیام 

    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)

    لاگ بالا کد خطا و پیام خطا را به شرح زیر نشان می‌دهد:

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

علت: پروکسی API با میزبان مجازی خاص مرتبط نیست

اگر پروکسی API برای پذیرش درخواست‌های مربوط به میزبان مجازی خاص پیکربندی نشده باشد، ممکن است با خطای 404 Not Found با پیام خطای Unable to identify proxy for host: VIRTUAL_HOST and url: PATH .

تشخیص

  1. پیکربندی Proxy Endpoint را برای پروکسی API بررسی کنید و ببینید آیا پروکسی API برای پذیرش درخواست‌های میزبان مجازی مشخص شده در خطا پیکربندی شده است یا خیر. این موضوع با عنصر VirtualHost نشان داده شده است. برای درک این موضوع، بیایید به یک نمونه پیکربندی ProxyEndpoint نگاهی بیندازیم.

    نمونه پیکربندی Proxy Endpoint که نشان می‌دهد پروکسی API درخواست‌ها را در یک میزبان مجازی امن می‌پذیرد

  2. فرض کنید میزبان‌های مجازی در محیط خاص به صورت زیر تعریف شده‌اند:
    نام بندر نام مستعار میزبان
    default 80 myorg-prod.apigee.net
    secure 443 myorg-prod.apigee.net
  3. شما با استفاده از آدرس اینترنتی http://myorg-prod.apigee.net/weather یک درخواست API به VirtualHost default ارسال می‌کنید.
  4. از آنجایی که ProxyEndpoint همانطور که در مثال بالا نشان داده شده است، VirtualHost default ندارد، کد پاسخ 404 را با پیام خطای زیر دریافت می‌کنید: 
    {"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  5. برای حل این مشکل به بخش حل مشکل در پایین صفحه مراجعه کنید.
  6. اگر ProxyEndpoint طوری پیکربندی شده باشد که درخواست‌ها را روی VirtualHost default بپذیرد، به دلیل بعدی بروید - مسیر با هیچ پروکسی API مرتبط نیست .

وضوح تصویر

  1. برای رفع مشکل VirtualHost از دست رفته را به پیکربندی ProxyEndpoint اضافه کنید. برای مثال نشان داده شده در بالا، می‌توانید VirtualHost پیش‌فرض را به صورت زیر به پیکربندی ProxyEndpoint اضافه کنید:
    <VirtualHost>default</VirtualHost>

    نمونه پیکربندی Proxy Endpoint که نشان می‌دهد پیش‌فرض > VirtualHost > اضافه شده است

  2. از طرف دیگر، در مثالی که در بالا به آن اشاره شد، اگر قصد داشتید فقط از VirtualHost secure برای این پروکسی API خاص استفاده کنید، درخواست‌های API را فقط با استفاده از پروتکل HTTPS به VirtualHost secure ارسال کنید: 
    https://myorg-prod.apigee.net/weather

علت: میزبان مجازی در نسخه جدید پروکسی API حذف شد.

اگر پس از حذف یک میزبان مجازی خاص (که بخشی از نسخه قبلی بود) که هنوز توسط کلاینت‌ها برای ارسال درخواست‌های API استفاده می‌شود، نسخه‌ی جدیدی از پروکسی API پیاده‌سازی شود، می‌تواند باعث این مشکل شود.

تشخیص

  1. پیکربندی Proxy Endpoint مربوط به پروکسی API را بررسی کنید تا ببینید آیا پروکسی API برای پذیرش درخواست‌های مربوط به میزبان مجازی مشخص شده در خطا پیکربندی شده است یا خیر. این موضوع توسط عنصر VirtualHost در پیکربندی ProxyEndpoint نشان داده شده است.
  2. اگر میزبان مجازی مشخص شده در خطا در پیکربندی ProxyEndpoint وجود ندارد، مراحل زیر را انجام دهید. در غیر این صورت، به دلیل بعدی بروید - مسیر با هیچ پروکسی API مرتبط نیست .
  3. پیکربندی ProxyEndpoint نسخه قبلی پیاده‌سازی شده را با نسخه فعلی پیاده‌سازی شده مقایسه کنید.
    1. برای مثال، فرض کنید نسخه قبلی پیاده‌سازی شده شما 5 و نسخه فعلی پیاده‌سازی شده شما 6 است:
      • میزبان‌های مجازی در Proxy Endpoint در نسخه ۵ پیکربندی شده‌اند 
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
      • میزبان‌های مجازی در Proxy Endpoint در نسخه ۶ پیکربندی شده‌اند 
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
    2. در مثال بالا، VirtualHost vh1 در revision 5, اما در revision 6 حذف شده و با VirtualHost secure جایگزین شده است.
    3. بنابراین اگر شما یا کلاینت‌هایتان با استفاده از VirtualHost vh1 (که بخشی از revision 5 بود) درخواست‌هایی را به این پروکسی API ارسال می‌کنید، کد پاسخ 404 را با پیام خطای زیر دریافت خواهید کرد: 
      {"fault":{"faultstring":"Unable to identify proxy for host: vh1 and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  4. بررسی کنید که آیا تغییر میزبان مجازی عمداً یا سهواً در نسخه فعلی اعمال شده است و اقدامات مناسب را همانطور که در بخش راه‌حل توضیح داده شده است، انجام دهید.

وضوح تصویر

اگر متوجه شدید که میزبان یا میزبان‌های مجازی در نسخه جدید حذف شده‌اند، ممکن است عمدی یا تصادفی بوده باشد. برای هر مورد، مراحل حل/توصیه شده زیر را برای حل مشکل انجام دهید.

سناریوی شماره ۱: تغییر عمدی

در صورتی که حذف میزبان مجازی عمدی باشد، می‌توانید یکی از گزینه‌های زیر را انتخاب کنید که گزینه اول رویکرد پیشنهادی است:

  1. یک پروکسی جدید با مسیر پایه متفاوت ایجاد کنید و از یک میزبان مجازی متفاوت استفاده کنید (که در نسخه قبلی پیاده‌سازی شده وجود ندارد).

  2. اگر می‌خواهید به استفاده از پروکسی API موجود ادامه دهید اما از یک میزبان مجازی متفاوت استفاده کنید، بهتر است میزبان مجازی موجود را حفظ کرده و میزبان مجازی اضافی را اضافه کنید.

    این تضمین می‌کند که کاربران این پروکسی API تحت تأثیر این تغییر قرار نگیرند.

  3. اگر می‌خواهید از پروکسی API موجود استفاده کنید و فقط یک میزبان مجازی متفاوت داشته باشید، از قبل به کاربران خود اطلاع دهید و این تغییر را در طول یک دوره نگهداری انجام دهید.

    این کار تضمین می‌کند که کاربران این پروکسی API از تغییر آگاه هستند و می‌توانند از یک میزبان مجازی متفاوت برای برقراری تماس‌ها به این پروکسی API استفاده کنند. از این رو، آنها تحت تأثیر این تغییر قرار نخواهند گرفت.

سناریوی شماره ۲: تغییر غیرعمدی

در صورتی که حذف میزبان مجازی به اشتباه و نه عمدی انجام شده باشد، موارد زیر را انجام دهید:

  1. پیکربندی ProxyEndpoint را در نسخه فعلی به‌روزرسانی کنید تا از همان میزبان‌های مجازی که در نسخه قبلی استفاده شده بودند، استفاده شود. در مثال بالا، بخش زیر را از [متن زیر] تغییر دهید:
    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

    به 

    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
  2. نسخه اصلاح‌شده را مجدداً مستقر کنید.

بهترین شیوه‌ها

همیشه توصیه می‌شود پروکسی‌های جدید یا نسخه‌های جدید را در طول دوره نگهداری یا زمانی که انتظار می‌رود ترافیک حداقل باشد، مستقر کنید تا از هرگونه مشکلی که در طول استقرار ایجاد می‌شود، جلوگیری شود یا تأثیر آن بر ترافیک به حداقل برسد.

علت: مسیر با هیچ پروکسی API مرتبط نیست

اگر پروکسی API برای پذیرش درخواست‌ها برای مسیر خاص استفاده شده در URL درخواست API پیکربندی نشده باشد، ممکن است با پیام خطای 404 Not Found با پیام خطای Unable to identify proxy for host: VIRTUAL_HOST and url: PATH .

تشخیص

  1. به پیکربندی ProxyEndpoint مربوط به پروکسی API خاصی که قصد ارسال درخواست‌های API برای آن را دارید، نگاهی بیندازید.
  2. بررسی کنید که آیا پروکسی API برای پذیرش درخواست‌ها برای مسیر خاص مشخص شده در پیام خطا پیکربندی شده است یا خیر. می‌توانید این کار را با انجام مراحل موجود در سناریوی شماره ۱ و سناریوی شماره ۲ انجام دهید.

سناریوی شماره ۱: مسیر با مسیر پایه پروکسی API مطابقت ندارد

  1. اگر path نشان داده شده در پیام خطا با basepath پروکسی API خاص یکسان نباشد یا با basepath شروع نشود، می‌تواند دلیل خطا باشد.
  2. برای توضیح این موضوع، مثالی می‌زنیم:
    1. basepath پروکسی API مورد نظر /weather است.
    2. آدرس اینترنتی درخواست API، https://myorg-prod.apigee.net/climate است. این بدان معناست که مسیر استفاده شده در آدرس اینترنتی درخواست API، /climate.
  3. در این مثال، path با basepath یکسان نیست و با basepath شروع نمی‌شود. از این رو خطای زیر را دریافت می‌کنید: 
    {
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/climate",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

وضوح تصویر

  1. مطمئن شوید که path استفاده شده در URL درخواست API شما با basepath پروکسی API خاص یکسان باشد.
  2. در مثال بالا، آدرس درخواست API باید به صورت زیر باشد: 
    {
https://myorg-prod.apigee.net/weather

سناریوی شماره ۲: مسیر با هیچ یک از جریان‌های شرطی موجود مطابقت ندارد

  1. اگر path استفاده شده در URL درخواست API با basepath شروع شود، ممکن است path suffix (بخشی که بعد از basepath می‌آید) که در پیام خطا نشان داده شده است با هیچ یک از جریان‌های شرطی مطابقت نداشته باشد، در این صورت می‌تواند باعث خطای 404 شود.
  2. برای توضیح این موضوع، مثالی می‌زنیم:
    1. basepath پروکسی API مورد نظر /weather است.
    2. آدرس اینترنتی درخواست API، https://myorg-prod.apigee.net/weather/Delhi است. این بدان معناست که مسیر استفاده شده در آدرس اینترنتی درخواست API /weather/Delhi.
  3. در این مثال، path با basepath /weather شروع می‌شود. علاوه بر این، path suffix /Delhi را نیز دارد.
  4. حالا بررسی کنید که آیا جریان‌های شرطی در ProxyEndpoint وجود دارد یا خیر.
  5. اگر هیچ جریان شرطی وجود ندارد یا چند جریان غیر شرطی وجود دارد، به علت بعدی بروید - پروکسی API در یک محیط مستقر نشده است .
  6. اگر ProxyEndpoint فقط جریان‌های شرطی دارد، موارد زیر را بررسی کنید:
    1. اگر شرایط در تمام این جریان‌های شرطی، یک proxy.pathsuffix خاص (مسیر بعد از basepath) را بررسی کنند.
    2. و اگر path suffix مشخص شده در URL درخواست API با هیچ یک از شرایط مطابقت نداشته باشد، دلیل خطا همین است.
  7. فرض کنید دو جریان در ProxyEndpoint داریم و هر دو جریان‌های شرطی هستند، همانطور که در زیر نشان داده شده است: 
    <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>

<Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
    1. در مثال بالا، دو جریان شرطی داریم، یکی که با proxy.pathsuffix (مسیر بعد از basepath) به /Bangalore مطابقت دارد و دیگری با /Chennai مطابقت دارد. اما هیچ کدام با /Delhi که path suffix ارسال شده در URL درخواست API است، مطابقت ندارند.
    2. این دلیل خطای 404 است. از این رو خطای زیر را دریافت خواهید کرد: 
      {
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

وضوح تصویر

  1. مطمئن شوید که path suffix حداقل با یکی از جریان‌های شرطی در نقطه پایانی پروکسی شما مطابقت دارد.
  2. در مثال بالا، می‌توانید از روش‌های زیر برای رفع خطا استفاده کنید:
    1. اگر می‌خواهید مجموعه خاصی از سیاست‌ها را برای مسیر /Delhi اجرا کنید، یک جریان جداگانه با مجموعه سیاست‌های مورد نیاز اضافه کنید و مطمئن شوید که شرطی وجود دارد که با /proxy.pathsuffix /Delhi مطابق شکل زیر مطابقت دارد: 
      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>
    2. اگر می‌خواهید مجموعه‌ای از سیاست‌های مشترک را برای مسیر /Delhi اجرا کنید، در جریان مشترک، مطمئن شوید که شرطی وجود دارد که به /proxy.pathsuffix عمومی اجازه می‌دهد. یعنی، هر مسیری را پس از basepath /weather همانطور که در زیر نشان داده شده است، مجاز می‌داند: 
      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

اگر ProxyEndpoint basepath صحیحی داشته باشد و path suffix مشخص شده در API URL با یکی از جریان‌های شرطی مطابقت داشته باشد، به علت بعدی بروید - پروکسی API در یک محیط مستقر نشده است .

علت: پروکسی API در یک محیط مستقر نشده است

تشخیص

  1. محیطی را که نام مستعار میزبان استفاده شده در URL درخواست API شما در آن وجود دارد، تعیین کنید. این کار را می‌توان با بررسی جزئیات تمام میزبان‌های مجازی در هر یک از محیط‌های سازمان شما در رابط کاربری Edge انجام داد.

    برای مثال، پیکربندی زیر را فرض کنید:

    • اگر http://myorg-prod.apigee.net/weather آدرس اینترنتی شما باشد، myorg-prod.apigee.net نام مستعار میزبان است.
    • میزبان با نام مستعار myorg-prod.apigee.net به عنوان بخشی از یکی از میزبان‌های مجازی در محیط prod سازمان شما پیکربندی شده است.
  2. بررسی کنید که آیا پروکسی API خاص در محیط خاص تعیین شده در مرحله 1 بالا مستقر شده است یا خیر.
  3. اگر پروکسی API در محیط خاص مستقر نشده باشد، دلیل خطای 404 همین است.
    1. بنابراین در مثالی که در مرحله ۱ بالا استفاده شد، فرض کنید پروکسی API در محیط prod مستقر نشده باشد، پس این دلیل خطا است.
    2. به بخش وضوح تصویر در زیر بروید.
  4. اگر پروکسی API در محیط خاص مستقر شده است، به دلیل بعدی بروید - محیط روی پردازنده‌های پیام بارگذاری نشده است .

وضوح تصویر

پروکسی API را در محیط خاصی که قصد ارسال درخواست‌های API را دارید، مستقر کنید.

علت: محیط روی پردازنده‌های پیام بارگذاری نشده است

تشخیص

  1. به هر یک از پردازنده‌های پیام (Message Processors) وارد شوید و با استفاده از دستور زیر بررسی کنید که آیا محیط خاصی که در آن درخواست API را ارسال می‌کنید، در پردازنده پیام بارگذاری شده است یا خیر: 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
  2. اگر محیط خاص به عنوان بخشی از دستور بالا ذکر شده است، به دلیل بعدی بروید - پروکسی API روی یک یا چند پردازنده پیام مستقر نشده است .
  3. اگر محیط خاص ذکر نشده است، برای یافتن هرگونه خطا در هنگام بارگذاری محیط‌ها، /opt/apigee/var/log/edge-message-processor/logs/system.log و /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log را در Message Processors بررسی کنید.
  4. ممکن است خطاهای مختلف زیادی وجود داشته باشد که منجر به عدم بارگذاری یک محیط در پردازنده پیام شود. راه‌حل بستگی به خطایی دارد که رخ داده است.

وضوح تصویر

ممکن است محیط به دلایل زیادی روی پردازشگر پیام بارگذاری نشود. این بخش چند دلیل احتمالی را که می‌تواند منجر به این مشکل شود، نشان می‌دهد و نحوه حل مشکل را توضیح می‌دهد.

  1. اگر یکی از خطاهای زیر را در گزارش پردازشگر پیام مشاهده کردید، این خطا ناشی از مشکلی در گواهی‌ها/کلیدها است که به keystore/truststore مشخص شده در محیط مشخص شده اضافه شده‌اند.

    خطای شماره ۱: java.security.KeyStoreException: نمی‌توان گواهی خود را بازنویسی کرد 

    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

    خطای شماره ۲: java.security.KeyStoreException: نمی‌توان کلید مخفی را بازنویسی کرد 

    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. با استفاده از فراخوانی API مدیریتی زیر، جزئیات keystore/truststore مشخص شده در پیام خطای نشان داده شده در مرحله قبل را دریافت کنید: 
    curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user>

    خروجی مثال: 

    {
   "certs":[
      "mycert",
      "mycert-new"
   ],
   "keys":[
      "mycert"
   ],
   "name":"myTruststore"
}
  3. خروجی مثال نشان می‌دهد که دو گواهی و یک کلید در فروشگاه اعتماد myTruststore وجود دارد. فروشگاه اعتماد معمولاً حاوی کلید نیست. اگر هم باشد، بهتر است یک گواهی و یک کلید داشته باشید.
  4. با استفاده از API زیر، جزئیات مربوط به دو گواهی را دریافت کنید: 
    curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
  5. تاریخ انقضای هر یک از گواهینامه‌ها را بررسی کنید و گواهینامه منقضی شده/قدیمی‌تر را تعیین کنید.
  6. گواهی منقضی شده یا ناخواسته را از فروشگاه اعتماد myTruststore حذف کنید.

اگر مشکل همچنان ادامه داشت یا خطایی غیر از موارد ذکر شده در مرحله 1 بالا مشاهده کردید، به بخش «باید اطلاعات تشخیصی را جمع‌آوری کنید» بروید.

علت: پروکسی API روی یک یا چند پردازنده پیام مستقر نشده است

ممکن است پروکسی API روی یک یا چند پردازنده پیام (Message Processors) مستقر نشده باشد. این مشکل بسیار نادر است و بیشتر به دلیل عدم ارسال اعلان رویداد از سرور مدیریت به پردازنده پیام (Message Processor) در حین استقرار پروکسی API خاص رخ می‌دهد. در این حالت نیز، شما قادر به ایجاد جلسه ردیابی در رابط کاربری Edge نخواهید بود.

تشخیص

  1. به هر یک از پردازنده‌های پیام وارد شوید و با استفاده از دستور زیر بررسی کنید که آیا نسخه خاص پروکسی API مستقر شده است یا خیر: 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  2. اگر نسخه خاص پروکسی API به عنوان خروجی دستور ذکر شده در مرحله 1 بالا نمایش داده نشد، پردازنده پیام خاص را همانطور که در Resolution توضیح داده شده است، مجدداً راه‌اندازی کنید.
  3. مراحل ۱-۲ را برای همه پردازنده‌های پیام تکرار کنید.
  4. اگر نسخه خاص پروکسی API روی همه پردازنده‌های پیام مستقر شده باشد، این دلیل این مشکل نیست. به «باید اطلاعات تشخیصی جمع‌آوری شود» بروید.

وضوح تصویر

پردازشگرهای پیام خاصی را که نسخه خاص پروکسی API روی آنها مستقر نشده است، مجدداً راه‌اندازی کنید. 

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

تشخیص مشکلات با استفاده از مانیتورینگ API

مانیتورینگ API به شما این امکان را می‌دهد که به سرعت حوزه‌های مشکل‌دار را جدا کنید تا مشکلات خطا، عملکرد و تأخیر و منبع آنها، مانند برنامه‌های توسعه‌دهنده، پروکسی‌های API، اهداف backend یا پلتفرم API را تشخیص دهید.

برای این مشکل، می‌توانید به صفحه API Monitoring > Investigate بروید و تاریخ، پروکسی و غیره مناسب را انتخاب کنید، و ممکن است جزئیات زیر را مشاهده کنید:

Fault code and status code in UI

  • کد خطا: messaging.adaptors.http.flow.ApplicationNotFound
  • کد وضعیت: 404
  • منبع خطا: Apigee یا MP

علاوه بر این، می‌توانید همانطور که در تصویر بالا نشان داده شده است، روی مشاهده گزارش‌ها کلیک کنید و اطلاعات بیشتری را بررسی کنید.

view logs

یک سناریوی نمونه را به صورت مرحله‌ای بررسی کنید تا نحوه عیب‌یابی مشکلات 5xx با APIهای خود را با استفاده از مانیتورینگ API نشان دهید. به عنوان مثال، ممکن است بخواهید هشداری تنظیم کنید تا وقتی تعداد کدهای وضعیت 404 از یک آستانه خاص فراتر رفت، به شما اطلاع داده شود.

باید اطلاعات تشخیصی جمع‌آوری کند

اگر مشکل حتی پس از دنبال کردن دستورالعمل‌های بالا ادامه داشت، اطلاعات تشخیصی زیر را جمع‌آوری کنید. با پشتیبانی Apigee Edge تماس بگیرید و این اطلاعات را با آنها به اشتراک بگذارید.

  1. اگر کاربر فضای ابری عمومی هستید، اطلاعات زیر را ارائه دهید:
    • نام سازمان
    • نام محیط
    • نام پروکسی API
    • دستور curl را برای بازتولید خطا کامل کنید
  2. اگر کاربر Private Cloud هستید، اطلاعات زیر را ارائه دهید:
    • پیام خطای کامل مشاهده شد
    • نام محیط
    • بسته پروکسی API
    • گزارش‌های پردازشگر پیام /opt/apigee/var/log/edge-message-processor/logs/system.log
    • خروجی دستورات زیر در هر یک از پردازنده‌های پیام. 
      • curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
      curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  3. جزئیات مربوط به بخش‌هایی از این راهنما که شما امتحان کرده‌اید و هرگونه اطلاعات دیگری که به ما در تسریع حل این مشکل کمک کند.