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 Public و Private Cloud
میزبان مجازی در ویرایش جدید پراکسی API حذف شد حذف هاست مجازی از نسخه جدید نصب شده در حالی که مشتری هنوز از میزبان مجازی خاص استفاده می کند می تواند باعث این مشکل شود. کاربران Edge Public و Private Cloud
مسیری که با هیچ پروکسی API مرتبط نیست پروکسی API خاص برای پذیرش درخواست ها در مسیر مشخص شده در پیام خطا پیکربندی نشده است. کاربران Edge Public و Private Cloud
پروکسی API در یک محیط مستقر نشده است پروکسی API خاص در محیط خاصی که در آن می‌خواهید درخواست‌های API را انجام دهید مستقر نشده است. کاربران Edge Public و Private Cloud
محیط روی پردازشگر پیام بارگذاری نشده است محیط خاصی (که در آن می‌خواهید درخواست‌های API را انجام دهید) به دلیل خطا در پردازشگرهای پیام بارگذاری نشده است. کاربران Edge Private Cloud
پروکسی API در یک یا چند پردازشگر پیام مستقر نشده است پروکسی API ممکن است در یک یا چند پردازشگر پیام به دلیل از دست رفتن اعلان رویداد در حین استقرار مستقر نشود. کاربران Edge Private Cloud

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

گزارش های 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 برای درک این موضوع نگاه کنیم.

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

  2. فرض کنید هاست های مجازی در یک محیط خاص به صورت زیر تعریف می شوند:
    نام بندر نام مستعار میزبان
    default 80 myorg-prod.apigee.net
    secure 443 myorg-prod.apigee.net
  3. شما با استفاده از URL 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. برای رفع این مشکل به بخش Resolution زیر بروید.
  6. اگر ProxyEndpoint برای پذیرش درخواست‌ها در VirtualHost default پیکربندی شده است، به علت بعدی بروید - مسیری که با هیچ پروکسی API مرتبط نیست .

قطعنامه

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

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

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

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

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

تشخیص

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

قطعنامه

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

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

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

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

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

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

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

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

سناریوی شماره 2: تغییر ناخواسته

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

  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 برای پذیرش درخواست‌ها برای مسیر خاصی که در پیام خطا نشان داده شده است پیکربندی شده است. می توانید این کار را با انجام مراحل در سناریو شماره 1 و سناریو شماره 2 انجام دهید.

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

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

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

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

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

تشخیص

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

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

    • اگر http://myorg-prod.apigee.net/weather URL شما است، myorg-prod.apigee.net نام مستعار میزبان است.
    • میزبان مستعار myorg-prod.apigee.net به عنوان بخشی از یکی از میزبان های مجازی در محیط prod سازمان شما پیکربندی شده است.
  2. بررسی کنید که آیا پروکسی API خاص در محیط خاصی که در مرحله 1 در بالا تعیین شده است مستقر شده است یا خیر.
  3. اگر پراکسی API در یک محیط خاص مستقر نشده باشد، پس این دلیل خطای 404 است.
    1. بنابراین در مثال مورد استفاده در مرحله 1 در بالا، فرض کنید پروکسی API در محیط prod مستقر نشده است، پس این دلیل خطا است.
    2. به بخش Resolution در زیر بروید.
  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 برای هر گونه خطا در حین بارگیری محیط ها، در پردازشگرهای پیام /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log .
  4. ممکن است خطاهای مختلفی وجود داشته باشد که می تواند منجر به شکست در بارگیری یک محیط در پردازشگر پیام شود. وضوح به خطای رخ داده بستگی دارد.

قطعنامه

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

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

    خطای شماره 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

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

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

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

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

تشخیص

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

قطعنامه

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

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

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

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

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

Fault code and status code in UI

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

علاوه بر این، می توانید همانطور که در تصویر بالا نشان داده شده است، روی View logs کلیک کنید و بیشتر بررسی کنید.

view logs

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

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

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

  1. اگر کاربر Public Cloud هستید، اطلاعات زیر را ارائه دهید:
    • نام سازمان
    • نام محیط زیست
    • نام پروکسی 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. جزئیات مربوط به بخش‌هایی که در این کتاب راهنما امتحان کرده‌اید و هر بینش دیگری که به ما در پیگیری سریع حل این مشکل کمک می‌کند.