‫۴۰۴ نمی‌توان کارگزار میزبان <virtual host name> و نشانی وب <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 مشخص‌شده برای پذیرفتن درخواست‌ها در میزبان مجازی مشخص‌شده در پیام خطا پیکربندی نشده است. کاربران «فضای ابری خصوصی و عمومی لبه‌ای»
میزبان مجازی در نسخه بازبینی جدیداً مستقرشده میانای برنامه‌سازی کاربردی پراکسی برداشته شد برداشتن میزبان مجازی از نسخه جدیداً مستقرشده درحالی‌که کارخواه هنوز از میزبان مجازی خاص استفاده می‌کند می‌تواند باعث بروز این مشکل شود. کاربران «فضای ابری خصوصی و عمومی لبه‌ای»
مسیر با هیچ پراکسی API مرتبط نیست کارگزار پروکسی API مشخص‌شده برای پذیرفتن درخواست‌ها در مسیر مشخص‌شده در پیام خطا پیکربندی نشده است. کاربران «فضای ابری خصوصی و عمومی لبه‌ای»
کارگزار میانای برنامه‌سازی کاربردی در محیطی مستقر نشده است کارگزار نیابتی API مشخص در محیط مشخصی که در آن سعی می‌کنید درخواست‌های API را انجام دهید، مستقر نشده است. کاربران «فضای ابری خصوصی و عمومی لبه‌ای»
محیط در «پردازشگر پیام» بار نشده است محیط خاص (که در آن سعی می‌کنید درخواست‌های «میانای برنامه‌سازی کاربردی» را ایجاد کنید) به‌دلیل خطا در «پردازشگرهای پیام» بار نشده است. کاربران Edge Private Cloud
کارگزار نیابتی میانای برنامه‌سازی کاربردی در یک یا چند «پردازشگر پیام» مستقر نشده است کارگزار نیابتی API ممکن است به‌دلیل نبود اعلان رویداد درطول استقرار، در یک یا چند «پردازشگر پیام» مستقر نشده باشد. کاربران Edge Private Cloud

مراحل متداول تشخیص خرابی

گزارش‌های NGINX و «پردازشگر پیام» در عیب‌یابی خطای 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 را برای میانای برنامه‌سازی کاربردی خاص دارید یا شناسه پیام منحصربه‌فرد مرحله ۲ را برای درخواست میانای برنامه‌سازی کاربردی دارید.

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

    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. پیکربندی نقطه پایانی پراکسی را برای پراکسی API بررسی کنید و ببینید آیا پراکسی API برای پذیرش درخواست‌های میزبان مجازی مشخص‌شده در خطا پیکربندی شده است یا نه. این مورد با عنصر VirtualHost نشان داده می‌شود. بیایید برای درک این موضوع، به یک نمونه پیکربندی ProxyEndpoint نگاه کنیم.

    پیکربندی «نقطه پایانی پراکسی نمونه» که نشان می‌دهد پراکسی API درخواست‌ها را در میزبان مجازی امن می‌پذیرد

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

وضوح

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

    نمونه پیکربندی نقطه پایانی پراکسی که> VirtualHost> پیش‌فرض را نشان می‌دهد که اضافه می‌شود

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

دلیل: میزبان مجازی در نسخه بازبینی جدید پراکسی API برداشته شده است

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

تشخیص

  1. پیکربندی نقطه پایانی پراکسی را برای پراکسی میانای برنامه‌سازی کاربردی بررسی کنید تا ببینید آیا پراکسی میانای برنامه‌سازی کاربردی برای پذیرفتن درخواست‌های میزبان مجازی مشخص‌شده در خطا پیکربندی شده است یا نه. این مورد با عنصر VirtualHost در پیکربندی ProxyEndpoint نشان داده می‌شود.
  2. اگر میزبان مجازی مشخص‌شده در خطا در پیکربندی ProxyEndpoint وجود ندارد، مراحل زیر را انجام دهید. درغیراین‌صورت، به دلیل بعدی بروید - مسیر با هیچ پراکسی API مرتبط نیست.
  3. پیکربندی ProxyEndpoint نسخه قبلاً مستقرشده را با نسخه درحال استقرار مقایسه کنید.
    1. برای مثال، فرض کنیم نسخه قبلاً مستقرشده شما 5 بوده است و نسخه درحال‌حاضر مستقرشده شما 6 است:
      • «میزبان‌های مجازی» در «نقطه پایان پراکسی» در بازبینی ۵ پیکربندی شده است
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
      • «میزبان‌های مجازی» در «نقطه پایان پراکسی» در بازبینی ۶ پیکربندی شده است
        • <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 موجود استفاده کنید و فقط میزبان مجازی متفاوتی داشته باشید، کاربرانتان را ازقبل مطلع کنید و این تغییر را در دوره نگهداری انجام دهید.

    این کار تضمین می‌کند که کاربران این پراکسی «میانای برنامه‌سازی کاربردی» از تغییر مطلع شوند و بتوانند از میزبان مجازی دیگری برای تماس با این پراکسی «میانای برنامه‌سازی کاربردی» استفاده کنند. بنابراین، این تغییر بر آن‌ها تأثیری نخواهد داشت.

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

درصورتی‌که برداشتن میزبان مجازی به‌اشتباه و غیرعمدی انجام شده باشد، مراحل زیر را انجام دهید:

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

    تا

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

روال‌های مطلوب

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

دلیل: مسیر با هیچ پراکسی میانای برنامه‌سازی کاربردی مرتبط نیست

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

تشخیص

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

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

  1. اگر path نشان‌داده‌شده در پیام خطا با basepath کارگزار نیابتی API خاص یکسان نباشد یا با basepath شروع نشود، این می‌تواند دلیل خطا باشد.
  2. بیایید با یک مثال این موضوع را توضیح دهیم:
    1. ‫basepath کارگزار نیابتی میانای برنامه‌سازی کاربردی موردنظر /weather است
    2. «نشانی وب درخواست میانای برنامه‌سازی کاربردی» 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 استفاده‌شده در نشانی وب درخواست میانای برنامه‌سازی کاربردی شما با basepath کارگزار نیابتی میانای برنامه‌سازی کاربردی خاص یکسان باشد.
  2. در مثال بالا، نشانی وب «درخواست API» باید به‌صورت زیر باشد: 
    {
https://myorg-prod.apigee.net/weather

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

  1. اگر path استفاده‌شده در «نشانی وب درخواست API» با basepath شروع شود، احتمال دارد که path suffix (بخشی که بعداز basepath می‌آید) نشان‌داده‌شده در پیام خطا با هیچ‌یک از جریان‌های شرطی مطابقت نداشته باشد، دراین‌صورت ممکن است باعث خطای 404 شود.
  2. بیایید با یک مثال این موضوع را توضیح دهیم:
    1. ‫basepath کارگزار نیابتی میانای برنامه‌سازی کاربردی موردنظر /weather است
    2. «نشانی وب درخواست میانای برنامه‌سازی کاربردی» https://myorg-prod.apigee.net/weather/Delhi است. این یعنی مسیر استفاده‌شده در نشانی وب درخواست API /weather/Delhi. است
  3. در این مثال، path با basepath /weather شروع می‌شود. علاوه‌براین، path suffix آن /Delhi است.
  4. اکنون بررسی کنید که آیا جریان شرطی در ProxyEndpoint وجود دارد یا نه.
  5. اگر هیچ جریان شرطی وجود ندارد یا چند جریان غیرشرطی وجود دارد، به دلیل بعدی بروید - کارگزار میانای برنامه‌سازی کاربردی در محیطی مستقر نشده است.
  6. اگر ProxyEndpoint فقط جریان‌های شرطی دارد، موارد زیر را بررسی کنید:
    1. اگر شرایط در همه این جریان‌های شرطی proxy.pathsuffix خاصی را بررسی کند (مسیر پس‌از مسیر پایه).
    2. و اگر path suffix مشخص‌شده در «نشانی وب درخواست 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 (مسیر پس‌از مسیر پایه) را با /Bangalore مطابقت می‌دهد و دیگری که /Chennai را مطابقت می‌دهد. اما هیچ‌کدام با /Delhi که path suffix ارسال‌شده در «نشانی وب درخواست میانای برنامه‌سازی کاربردی» است مطابقت ندارد.
    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 با یکی از جریان‌های شرطی مطابقت داشته باشد، به علت بعدی بروید - کارگزار API در محیطی مستقر نشده است.

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

تشخیص

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

    برای مثال، پیکربندی زیر را درنظر بگیرید:

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

وضوح

کارگزار نیابتی API را در محیط خاصی که قصد دارید درخواست‌های API را در آن ارسال کنید مستقر کنید.

علت: محیط در «پردازشگرهای پیام» بار نشده است

تشخیص

  1. به هریک از «پردازشگرهای پیام» وارد شوید و بررسی کنید که آیا محیط خاصی که در آن درخواست 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 را در «پردازشگرهای پیام» برای یافتن هرگونه خطا درطول بار کردن محیط‌ها بررسی کنید.
  4. خطاهای مختلفی می‌تواند منجر به بار نشدن محیط در «پردازشگر پیام» شود. راه‌حل به خطایی که رخ داده است بستگی دارد.

وضوح

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

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

    خطا شماره ۱: 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. برونداد نمونه نشان می‌دهد که دو گواهینامه و یک کلید در truststore myTruststore وجود دارد. «مخزن اعتماد» معمولاً کلیدی ندارد. اگر این‌طور است، بهتر است یک گواهی و یک کلید داشته باشید.
  4. بااستفاده از میانای برنامه‌سازی کاربردی زیر، جزئیات دو گواهینامه را دریافت کنید: 
    curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
  5. تاریخ انقضای هریک از گواهینامه‌ها را بررسی کنید و گواهینامه منقضی‌شده/قدیمی‌تر را تعیین کنید.
  6. گواهینامه منقضی یا ناخواسته را از فروشگاه مطمئن myTruststore حذف کنید.

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

دلیل: کارگزار پراکسی API در یک یا چند «پردازشگر پیام» مستقر نشده است

کارگزار نیابتی میانای برنامه‌سازی کاربردی ممکن است در یک یا چند «پردازشگر پیام» مستقر نشده باشد. این مشکل بسیار نادر است و بیشتر به‌دلیل دریافت نشدن اعلان رویداد از «سرور مدیریت» به «پردازشگر پیام» درطول استقرار پراکسی API خاص رخ می‌دهد. در این مورد نیز نمی‌توانید جلسه ردیابی را در واسط کاربر Edge ایجاد کنید.

تشخیص

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

وضوح

«پردازشگرهای پیام» خاصی را که نسخه معین مرور کارگزار API در آن‌ها استقرار نیافته است بازراه‌اندازی کنید.

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

عیب‌یابی مشکلات بااستفاده از «پایش میانای برنامه‌سازی کاربردی»

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

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

کد خطا و کد وضعیت در واسط کاربر

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

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

مشاهده گزارش‌ها

گذر از سناریو نمونه نشان می‌دهد چگونه مشکلات 5xx را در میاناهای برنامه‌سازی کاربردی‌تان بااستفاده از «پایش میانای برنامه‌سازی کاربردی» عیب‌یابی کنید. برای مثال، ممکن است بخواهید هشداری راه‌اندازی کنید تا وقتی تعداد کدهای وضعیت 404 از آستانه خاصی فراتر رفت به شما اطلاع داده شود.

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

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

  1. اگر کاربر «ابر عمومی» هستید، اطلاعات زیر را ارائه دهید:
    • نام سازمان
    • نام محیط
    • نام پراکسی میانای برنامه‌سازی کاربردی
    • فرمان curl را برای بازتولید خطا تکمیل کنید
  2. اگر کاربر «ابر خصوصی» هستید، اطلاعات زیر را ارائه دهید:
    • پیام خطای کامل مشاهده شد
    • نام محیط
    • دسته پراکسی میانای برنامه‌سازی کاربردی
    • گزارش‌های «پردازشگر پیام» /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. جزئیاتی درباره اینکه کدام بخش‌های این کتابچه راهنما را امتحان کرده‌اید و هرگونه اطلاعات آماری دیگری که به ما کمک می‌کند حل این مشکل را تسریع کنیم.