‫۵۰۳ سرویس دردسترس نیست

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

ویدیوها

برای اطلاعات بیشتر درباره خطاهای ۵۰۳، ویدیوهای زیر را ببینید:

ویدیو شرح
عیب‌یابی و رفع خطای «۵۰۳ سرویس دردسترس نیست» به‌دلیل مشکل ساناد درباره موارد زیر بیشتر بدانید:
  • خطای «۵۰۳ سرویس دردسترس نیست» ناشی از تفکیک ساناد و مشکلات مربوط به شبکه در Apigee Edge
  • عیب‌یابی و رفع خطای «۵۰۳ سرویس دردسترس نیست» هم‌زمان ناشی از مشکل تفکیک ساناد
عیب‌یابی و رفع خطای ۵۰۳ سرویس دردسترس نیست به‌دلیل مشکل شبکه عیب‌یابی و رفع خطای «۵۰۳ سرویس دردسترس نیست» هم‌زمان ناشی از مشکل شبکه در Apigee Edge

نشانه

برنامه مشتری پس‌از فراخوانی کارگزار API، وضعیت پاسخ HTTP 503 با پیام سرویس دردسترس نیست دریافت می‌کند.

پیام‌های خطا

می‌توانید پیام خطای زیر را ببینید:

HTTP/1.1 503 Service Unavailable

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

سرویس دردسترس نیست

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
       }
    }
}

علل احتمالی

پاسخ HTTP 503 Service Unavailable با کد خطای messaging.adaptors.http.flow.ServiceUnavailable زمانی رخ می‌دهد که «پردازشگر پیام» Apigee Edge به‌دلیل اتمام زمان اتصال، نام میزبان نادرست، یا خطاهای دست‌دهی SSL درحین ارتباط با سرور زیرینه با خطا مواجه شود.

علل احتمالی برای پاسخ ۵۰۳ سرویس دردسترس نیست عبارت‌اند از:

علت شرح چه کسی می‌تواند مراحل عیب‌یابی را انجام دهد
خطاهای اتصال به‌دلیل تفکیک نادرست ساناد وضوح ساناد سرور هدف منجر به نشانی‌های IP بدی شد که به خطاهای اتصال منتهی می‌شود. کاربران Edge Private Cloud
خطاهای اتصال مشکلات شبکه یا اتصال مانع از اتصال مشتری به سرور می‌شود. کاربران Edge Private Cloud
نام میزبان سرور هدف نادرست است میزبان سرور هدف مشخص‌شده نادرست است یا نویسه‌های ناخواسته‌ای (مثل فاصله) دارد. کاربران «فضای ابری خصوصی و عمومی لبه‌ای»
خطاهای دست دادن SSL دست دادن TLS/SSL بین کارخواه و سرور ناموفق بود. (عیب‌یابی برای این نوع مشکل در موضوعی جداگانه پوشش داده شده است.) کاربران «فضای ابری خصوصی و عمومی لبه‌ای»

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

شناسه پیام درخواست ناموفق را تعیین کنید

ابزار ردیابی

برای تعیین شناسه پیام درخواست ناموفق بااستفاده از «ابزار ردیابی»:

  1. اگر مشکل همچنان فعال است، جلسه ردیابی را برای میانای برنامه‌سازی کاربردی تحت‌تأثیر قرارگرفته فعال کنید.
  2. فراخوانی API را انجام دهید و مشکل را بازتولید کنید - ۵۰۳ سرویس دردسترس نیست با کد خطای messaging.adaptors.http.flow.ServiceUnavailable.
  3. یکی از درخواست‌های ناموفق را انتخاب کنید.
  4. به فاز AX پیمایش کنید و با پیمایش به پایین در بخش جزئیات فاز، شناسه پیام (X-Apigee.Message-ID) درخواست را تعیین کنید، همان‌طور که در شکل زیر نشان داده شده است.

    شناسه پیام در بخش «جزئیات فاز»

گزارش‌های دسترسی NGINX

برای تعیین شناسه پیام درخواست ناموفق بااستفاده از گزارش‌های دسترسی NGINX:

همچنین می‌توانید به گزارش‌های NGINX Access مراجعه کنید تا شناسه پیام خطاهای ۵۰۳ را تعیین کنید. این ویژگی به‌ویژه درصورتی مفید است که مشکل در گذشته رخ داده باشد یا مشکل متناوب باشد و نتوانید ردگیری را در واسط کاربر ضبط کنید. برای تعیین این اطلاعات از گزارش‌های دسترسی NGINX، از مراحل زیر استفاده کنید:

  1. گزارش‌های دسترسی NGINX را بررسی کنید: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  2. جستجو کنید که آیا خطاهای ۵۰۳ برای پراکسی API خاص در طول یک دوره زمانی خاص وجود دارد یا خیر (اگر مشکل در گذشته رخ داده است) یا اینکه آیا درخواست‌هایی هنوز با خطای ۵۰۳ ناموفق هستند یا خیر.
  3. اگر خطاهای ۵۰۳ با پیام X-Apigee-fault-code messaging.adaptors.http.flow.ServiceUnavailable وجود دارد، شناسه پیام را برای یک یا چند درخواست ازاین‌دست همان‌طور که در مثال زیر نشان داده شده است یادداشت کنید:

    نمونه ورودی نشان‌دهنده خطای ۵۰۳

    ورودی نمونه که کد وضعیت، شناسه پیام، منبع خطا، و کد خطا را نشان می‌دهد

خطاهای اتصال به‌دلیل تفکیک نادرست ساناد

تشخیص

  1. شناسه پیام درخواست ناموفق را تعیین کنید.
  2. شناسه پیام درخواست ویژه را در گزارش «پردازشگر پیام» (/opt/apigee/var/log/edge-message-processor/logs/system.log) جستجو کنید. ممکن است خطاهای زیر را مشاهده کنید:

    خطای onConnectTimeout نشان می‌دهد که «پردازشگر پیام» نتوانسته است در دوره زمانی ازپیش تعیین‌شده برای مهلت اتصال (پیش‌فرض: ۳ ثانیه) به سرور زیرینه متصل شود. 
    2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[Connected:]@164162 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11  resolvedAddress=www.abc.com/22.22.22.22

2019-08-14 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
  3. نشانی IP حل‌وفصل‌شده را در خطای onConnectTimeout یادداشت کنید و بررسی کنید که نشانی IP برای سرور زیرینه شما معتبر باشد. اگر نشانی IP معتبر است، به خطاهای اتصال بروید.
  4. اگر نشانی IP نامعتبر باشد، احتمالاً به‌دلیل مشکلات مربوط به تفکیک ساناد است.
  5. مرحله ۳ و ۴ را برای چند درخواست ناموفق دیگر API تکرار کنید و بررسی کنید که آیا همان نشانی‌های IP نامعتبر یا نشانی‌های IP نامعتبر دیگری را می‌بینید یا نه.
  6. در گزارش «پردازشگر پیام» (/opt/apigee/var/log/edge-message-processor/logs/system.log) به‌دنبال پیام‌هایی با کلیدواژه بازآوری ساناد بگردید. بررسی کنید که آیا نشانی‌های IP بد یا نامعتبر هرچند وقت یک‌بار به حافظه نهان ساناد در «پردازشگر پیام» اضافه می‌شوند یا نه. 
    2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 INFO c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.reportDifferences() : DNS Refresh for host: apitarget-uat.schemeweb.co.uk:4436. Added 2 IPs [www.abc.com/22.22.22.22, www.abc.com/33.33.33.33] Removed 1 IPs [www.abc.com/11.11.11.11]
  7. اگر سرورهای ساناد معتبر یا سرورهای نام پیکربندی‌شده در /etc/resolv.conf مشکلی داشته باشند، این مشکل ممکن است رخ دهد.

    معمولاً یک یا چند سرور ساناد معتبر برای انجام حل‌وفصل ساناد پیکربندی شده است. اگر سرورهای ساناد معتبری وجود نداشته باشد، به پیکربندی تنظیم‌شده در /etc/resolv.conf برمی‌گردد و تفکیک ساناد را به‌طور مناسب انجام می‌دهد. برای مثال: اگر /etc/resolv.conf برای استفاده از سرورهای نام خاصی پیکربندی شده باشد، از آن سرورهای نام برای انجام تفکیک ساناد استفاده خواهد شد.
  8. اگر سرورهای ساناد معتبر یا سرورهای نام مشخص‌شده در /etc/resolv.conf مشکلی داشته باشند، نام‌های میزبان سرور پشتیبان به نشانی‌های IP بد/نامعتبر تبدیل خواهند شد. نشانی‌های IP بد/نامعتبر در حافظه نهان ساناد «پردازشگر پیام» ذخیره خواهد شد.
    1. اگر مشکل سرورهای ساناد معتبر یا سرورهای نام مشخص‌شده در /etc/resolv.conf ادامه داشته باشد، نشانی‌های IP بد/نامعتبر همچنان در حافظه نهان ساناد «پردازشگر پیام» باقی خواهند ماند. تا زمانی که نشانی‌های IP بد در حافظه نهان ساناد «پردازشگر پیام» ذخیره شده باشد، درخواست‌های همه آن میاناهای برنامه‌سازی کاربردی که از سرور زمینه‌ای خاص استفاده می‌کنند با خطای ۵۰۳ ناموفق خواهد بود.
    2. اگر مشکل سرورهای ساناد معتبر یا سرورهای نام مشخص‌شده در /etc/resolv.conf متناوب باشد، نشانی‌های IP خوب و بد به‌صورت متناوب در حافظه نهان ساناد ذخیره خواهند شد. در این حالت، به‌طور متناوب خطاهای ۵۰۳ را برای همه آن میاناهای برنامه‌سازی کاربردی که از سرور زیرینه خاص استفاده می‌کنند مشاهده خواهید کرد.
  9. اگر مشکل سرورهای ساناد مداوم باشد، با خطاهای پیوسته مواجه خواهید شد. اگر مشکل سرورهای ساناد متناوب باشد، با خطاهای متناوب مواجه خواهید شد. یعنی هرگاه نام میزبان سرور زیرینه به نشانی‌های IP بد تبدیل شود، خطاهای ۵۰۳ را مشاهده می‌کنید. و وقتی نام‌های میزبان سرور زیرینه به نشانی‌های IP خوب تبدیل شوند، پاسخ‌های موفقیت‌آمیز را مشاهده خواهید کرد.

وضوح

لطفاً با سرپرست سیستم‌عامل خود همکاری کنید و مشکلات سرورهای ساناد را برطرف کنید.

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

خطاهای اتصال

خطای اتصال زمانی رخ می‌دهد که «پردازشگر پیام Apigee Edge» تلاش می‌کند به سرور پشتیبان متصل شود و یکی از این مشکلات رخ می‌دهد:

  • «پردازشگر پیام» نمی‌تواند در دوره زمان‌دار اتصال ازپیش تعیین‌شده متصل شود. (پیش‌فرض: ۳ ثانیه)
  • سرور زیرینه اتصال را نمی‌پذیرد.

تشخیص

  1. شناسه پیام درخواست ناموفق را تعیین کنید.
  2. شناسه پیام درخواست ویژه را در گزارش «پردازشگر پیام» (/opt/apigee/var/log/edge-message-processor/logs/system.log) جستجو کنید. ممکن است خطاهای زیر را مشاهده کنید:
    1. خطای onConnectTimeout نشان می‌دهد که «پردازشگر پیام» نتوانسته است در مدت زمان وقفه اتصال ازپیش تعیین‌شده به سرور زیرینه متصل شود. 
      2016-06-23 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@10 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11:80 resolvedAddress=www.abc.com/11.11.11.11
2016-06-23 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
    2. خطای java.net.ConnectException: Connection refused نشان می‌دهد که اتصال توسط سرور زیرینه رد شده است. 
      14:40:16.531 +0530
2016-06-17 09:10:16,531 org:myorg env:prod api:www.abc.com rev:1 rrt07eadn-22739-40983870-15 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() : connect to www.abc.com:11.11.11.11:443 failed with exception {}
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[na:1.7.0_75]
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739) ~[na:1.7.0_75]
at com.apigee.nio.ClientChannel.finishConnect(ClientChannel.java:121) ~[nio-1.0.0.jar:na]
at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:108) ~[nio-1.0.0.jar:na]
  3. بررسی کنید که آیا می‌توانید مستقیماً از هریک از «پردازشگرهای پیام» بااستفاده از دستور telnet به سرور زیرینه خاص متصل شوید یا نه:
    1. اگر سرور زیرینه به یک نشانی IP واحد تبدیل می‌شود، از دستور زیر استفاده کنید: 
      telnet BackendServer-IPaddress 443
    2. اگر سرور زیرینه به چندین نشانی IP تبدیل می‌شود، از نام میزبان سرور زیرینه در فرمان telnet همان‌طور که در زیر نشان داده شده است استفاده کنید: 
      telnet BackendServer-HostName 443
  4. اگر بتوانید به سرور زیرینه متصل شوید، ممکن است پیامی مانند Connected to backend-server ببینید. اگر نمی‌توانید به سرور زیرینه متصل شوید، ممکن است به این دلیل باشد که نشانی‌های IP «پردازشگرهای پیام» در سرور زیرینه خاص در فهرست مجاز قرار ندارد.

وضوح

دسترسی به نشانی‌های IP «پردازشگر پیام» را در سرور زیرینه خاصی فراهم کنید تا ترافیک «پردازشگرهای پیام لبه‌ای» بتواند به سرور زیرینه شما دسترسی پیدا کند. برای مثال، در Linux، می‌توانید از iptables برای مجاز کردن ترافیک از نشانی‌های IP «پردازشگر پیام» در سرور زیرینه استفاده کنید.

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

نام میزبان سرور مقصد نادرست است

تشخیص

اگر نام میزبان مشخص‌شده در سرور مقصد نادرست باشد، می‌توانید پاسخ ۵۰۳ سرویس دردسترس نیست را با کد خطای messaging.adaptors.http.flow.ServiceUnavailable. دریافت کنید

ابزار ردیابی

برای تشخیص خرابی بااستفاده از ابزار «ردیابی»:

  1. اگر مشکل همچنان فعال است، جلسه ردیابی را برای میانای برنامه‌سازی کاربردی تحت‌تأثیر قرارگرفته فعال کنید.
  2. فراخوانی API را انجام دهید و مشکل را بازتولید کنید - ۵۰۳ سرویس دردسترس نیست با کد خطای messaging.adaptors.http.flow.ServiceUnavailable.
  3. یکی از درخواست‌های ناموفق را انتخاب کنید.
  4. در مراحل مختلف ردیابی پیمایش کنید و مکان خرابی را پیدا کنید.
  5. FlowInfo را که خطا دارد انتخاب کنید. می‌توانید اطلاعات بیشتری را در فیلد error.cause پیدا کنید که می‌تواند دلیل ناموفق بودن را به شما بگوید، همان‌طور که در مثال زیر نشان داده شده است:

    درخواست نمونه‌ای که error.cause را در ردیابی نشان می‌دهد

    درخواست نمونه‌ای که error.cause را در ردیابی نشان می‌دهد
  6. اگر متوجه شدید که error.cause عبارت Host not reachable (میزبان دردسترس نیست) را نشان می‌دهد، احتمالاً دلیل خطا یکی از موارد زیر است:
    • نام میزبان مشخص‌شده در پیکربندی سرور هدف/نقطه پایانی هدف نادرست است یا فاصله یا نویسه‌های ویژه ناخواسته دارد.

      برای مثال، همان‌طور که در زیر نشان داده شده است، فضای ناخواسته‌ای در نام میزبان وجود دارد:
      "demo-target.apigee.net "
    • نام میزبان که با متغیر target.url در «پراکسی API» بااستفاده از خط‌مشی AssignMessage یا JavaScript بازنویسی شده است نادرست است یا فاصله یا نویسه‌های ویژه ناخواسته دیگری دارد.
  7. پیکربندی نقطه پایانی مقصد و/یا تعریف سرور مقصد را بررسی کنید تا ببینید نام میزبان سرور مقصد نادرست است یا فاصله یا نویسه‌های خاص ناخواسته دارد.
  8. اگر میزبان سرور مقصد به‌صورت پویا ایجاد شده است، خط‌مشی مناسب (برای مثال، خط‌مشی AssignMessage/JavaScript) را که برای ایجاد آن استفاده شده است بررسی کنید. بررسی کنید نام میزبان سرور مقصد نادرست نباشد یا فاصله یا نویسه خاص ناخواسته نداشته باشد.
  9. پس‌از اینکه نام میزبان سرور هدف را تعیین کردید، فرمان nslookup/dig را روی نام میزبان اجرا کنید تا ببینید آیا قابل‌حل است یا نه.

    برای مثال، اجرای فرمان nslookup در نام میزبان با فضای ناخواسته، برونداد زیر را برمی‌گرداند:

    nslookup "demo-target.apigee.net "
Server:	49.205.75.2
Address:	49.205.75.2#53

** server can't find demo-target.apigee.net\032: NXDOMAIN
  10. اگر فرمان سیستم‌عامل nslookup نیز نتواند نام میزبان را حل کند، دلیل این مشکل نام میزبان نادرستی است که برای سرور هدف استفاده شده است.

    به وضوح بروید.

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

برای تشخیص خرابی بااستفاده از گزارش‌های پردازشگر پیام:

  1. شناسه پیام درخواست ناموفق را تعیین کنید.
  2. شناسه پیام را در گزارش «پردازشگر پیام» جستجو کنید. (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  3. اگر پیام‌های هشدار/خطای زیر را مشاهده کردید، «پردازشگر پیام» نتوانسته است نام میزبان را حل کند. ازآنجایی‌که پیام به‌تعویق انداخته می‌شود، ممکن است این پیام هشدار را برای همه شناسه‌های پیام/درخواست‌ها نبینید. 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 WARN S.HTTPCLIENTSERVICE - DNSCache$2.failed() : Failed to resolve hostname www.somehost.com . Reason mocktarget.apigee.net : Name or service not known. This log message will snooze for 2 hours
  4. پس‌از آن پیام هشداری ارسال می‌شود که در آن «پردازشگر پیام» نشانی را از حافظه نهان ساناد برمی‌دارد، زیرا نمی‌توان به میزبان سرور مقصد دسترسی پیدا کرد. 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid> NIOThread@0 WARN  c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.addressNotReachable() : The last address has been removed from Address list null refreshing
  5. سپس ممکن است پیامی ببینید که در آن «پردازشگر پیام» با استثنای «میزبان دردسترس نیست» ناموفق بوده است. گاهی اوقات نام میزبان را به‌عنوان بخشی از پیام خطا نشان می‌دهد: 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception {}
java.lang.RuntimeException: Host not reachable
	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
	…<snipped>
  6. گاهی اوقات ممکن است آن را به‌عنوان تهی نشان دهد زیرا نام میزبان قابل‌حل یا دسترسی نیست، همان‌طور که در زیر نشان داده شده است: 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
java.lang.RuntimeException: Host not reachable
	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
	…<snipped>
  7. خطای Host not reachable معمولاً در یکی از موارد زیر رخ می‌دهد:
    • نام میزبان مشخص‌شده در پیکربندی سرور هدف/نقطه پایانی هدف نادرست است یا فاصله یا نویسه‌های ویژه ناخواسته دارد.

      برای مثال، در نام میزبان «demo-target.apigee.net » در پیام خطای زیر فضای ناخواسته وجود دارد: 
      NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception
    • نام میزبان که با متغیر target.url در «پراکسی API» بااستفاده از خط‌مشی AssignMessage یا JavaScript بازنویسی شده است نادرست است یا فاصله یا هر نویسه ویژه ناخواسته دیگری دارد.
  8. بااستفاده از یکی از موارد زیر، نام میزبان سرور هدفی را که «پردازشگر پیام» درحال تلاش برای برقراری ارتباط با آن است تعیین کنید:
    1. پیام خطای حاوی Host not reachable را به‌دقت بررسی کنید.
    2. اگر پیام خطا نام میزبان را نشان می‌دهد، نام میزبان را به‌همراه فاصله‌ها یا نویسه‌های خاص کپی کنید.
    3. اگر پیام خطا null را برای نام میزبان نشان می‌دهد، همان‌طور که در پیام خطای زیر می‌بینید، 
      org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
      1. با بررسی تعریف سرور هدف که در «پراکسی میانای برنامه‌سازی کاربردی» ناموفق استفاده شده است، نام میزبان را تعیین کنید.
      2. اگر میزبان سرور مقصد به‌صورت پویا ایجاد شده است، خط‌مشی مناسب (برای مثال، خط‌مشی AssignMessage/JavaScript) مورداستفاده برای ایجاد آن را بررسی کنید.
  9. پس‌از تعیین نام میزبان سرور هدف، فرمان nslookup/dig را روی نام میزبان اجرا کنید و بررسی کنید که آیا قابل‌حل است یا خیر.

    برای مثال، فرمان nslookup را روی نام میزبان دارای فضا اجرا کنید

    nslookup "demo-target.apigee.net "
Server:	49.205.75.2
Address:	49.205.75.2#53

** server can't find demo-target.apigee.net\032: NXDOMAIN
  10. اگر فرمان سیستم‌عامل nslookup نیز نتواند نام میزبان را حل کند، دلیل این مشکل نام میزبان نادرستی است که برای سرور هدف استفاده شده است.

وضوح

  1. مطمئن شوید که نام میزبان سرور هدف مشخص‌شده در پیکربندی نقطه پایانی هدف یا در تعریف سرور هدف صحیح باشد و فاصله یا نویسه خاص ناخواسته نداشته باشد.
  2. اگر از هر خط‌مشی AssignMessage/JavaScript برای تولید پویا نام میزبان سرور هدف استفاده می‌کنید، تعریف خط‌مشی و کد را بررسی کنید و مطمئن شوید که نام میزبان سرور هدف به‌درستی تولید می‌شود.

دست‌دهی SSL ناموفق بود

یک کتابچه کامل عیب‌یابی به خطاهای دست دادن TLS/SSL اختصاص داده شده است. خطاهای دست دادن SSL را ببینید.

تعیین منبع مشکل

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

آشنایی با اتصال‌های شمالی و جنوبی

در Edge، ممکن است در اتصال ورودی یا خروجی با خطای «۵۰۳ سرویس دردسترس نیست» مواجه شوید:

  • اتصال ورودی (یا شمالی) - اتصال بین برنامه کارخواه و «مسیریاب لبه». «مسیریاب» جزء Apigee Edge است که درخواست‌های ورودی سیستم را مدیریت می‌کند.
  • اتصال خروجی (یا جنوبی) - اتصال بین «پردازشگر پیام لبه» و سرور زیرینه. «پردازشگر پیام» یکی از اجزای Apigee Edge است که درخواست‌های API را به سرورهای هدف زیرینه هدایت می‌کند.

اگر کاربر Edge Public Cloud هستید، احتمالاً از اجزای داخلی مثل «رهیاب» یا «پردازشگر پیام» بی‌اطلاع هستید. این عناصر داخلی برای کاربران «ابر عمومی» قابل‌مشاهده یا دردسترس نیستند. درصورت امکان، روش‌های جایگزینی برای بررسی مشکل ارائه می‌دهیم که نیازی به دسترسی مستقیم به این مؤلفه‌ها ندارد.

شکل زیر اتصالات شمالی و جنوبی را برای Apigee Edge نشان می‌دهد.

جریان برنامه کلاینت (اتصال شمالی) ازطریق Edge به سرور پشتیبان (اتصال جنوبی)

تعیین محل وقوع خطای «۵۰۳ سرویس دردسترس نیست»

از یکی از روش‌های زیر برای تعیین اینکه خطای «۵۰۳ سرویس دردسترس نیست» در اتصال شمالی یا جنوبی رخ داده است استفاده کنید.

ردیابی میانای کاربر

برای تعیین محل وقوع خطا بااستفاده از «ردیابی واسط کاربر»:

  1. اگر مشکل همچنان فعال است، ردیابی واسط کاربر را برای «میانای برنامه‌سازی کاربردی» تحت‌تأثیر قرارگرفته فعال کنید.
  2. اگر ردیابی واسط کاربر برای درخواست ناموفق «میانای برنامه‌سازی کاربردی» نشان دهد که خطای «۵۰۳ سرویس دردسترس نیست» درطول جریان درخواست هدف رخ می‌دهد یا توسط سرور زیرینه ارسال می‌شود، دراین‌صورت مشکل جنوبی است (یعنی بین «پردازشگر پیام» و سرور زیرینه).
  3. اگر ردیابی را برای فراخوانی خاص «میانای برنامه‌سازی کاربردی» دریافت نمی‌کنید، مشکل شمالی، بین برنامه مشتری و «مسیریاب» است.

پایش میانای برنامه‌سازی کاربردی

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

گام‌به‌گام ازطریق یک سناریو نمونه که نشان می‌دهد چگونه بااستفاده از «پایش API» مشکلات ۵xx را در APIهای خود عیب‌یابی کنید. برای مثال، ممکن است بخواهید هشداری راه‌اندازی کنید تا وقتی تعداد خطاهای messaging.adaptors.http.flow.ServiceUnavailable از آستانه خاصی فراتر رفت به شما اطلاع داده شود.

گزارش‌های دسترسی NGINX

برای تعیین محل وقوع خطا بااستفاده از «ردیابی واسط کاربر»:

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

  1. گزارش‌های دسترسی NGINX (/opt/apigee/var/log/edge-router/nginx/ org-env.port_access_log) را بررسی کنید.
  2. جستجو کنید که آیا خطای ۵۰۳ برای پراکسی «میانای برنامه‌سازی کاربردی» خاصی وجود دارد یا نه.
  3. اگر بتوانید خطاهای ۵۰۳ را برای میانای برنامه‌سازی کاربردی خاص در زمان خاص شناسایی کنید، مشکل در اتصال جنوبی (بین «پردازشگر پیام» و سرور زیرینه) رخ داده است.
  4. اگر این‌طور نیست، مشکل در اتصال شمالی (بین برنامه مشتری و «مسیریاب») رخ داده است.