503 خدمات در دسترس نیست

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

ویدیوها

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

ویدئو توضیحات
عیب‌یابی و رفع خطای ۵۰۳ Service Unavailable به دلیل مشکل DNS در مورد موارد زیر اطلاعات کسب کنید:
  • خطای ۵۰۳ عدم دسترسی به سرویس ناشی از مشکلات DNS و شبکه در Apigee Edge
  • عیب‌یابی و حل خطای 503 Service Unavailable ناشی از مشکل DNS Resolution
عیب‌یابی و رفع خطای ۵۰۳ Service Unavailable به دلیل مشکل شبکه عیب‌یابی و حل خطای 503 Service Unavailable ناشی از مشکل شبکه در Apigee Edge به صورت بلادرنگ

علامت

برنامه‌ی کلاینت پس از فراخوانی پروکسی API، پاسخ HTTP با وضعیت ۵۰۳ با پیام « سرویس در دسترس نیست» دریافت می‌کند.

پیام‌های خطا

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

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 هنگام برقراری ارتباط با سرور backend، به دلیل اتمام زمان اتصال، نام میزبان نادرست یا خرابی SSL handshake با خطاهایی مواجه شود.

دلایل احتمالی برای پاسخ 503 Service Unavailable عبارتند از:

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

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

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

ابزار ردیابی

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

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

    Message ID in Phase Details section

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

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

همچنین می‌توانید برای تعیین شناسه پیام خطاهای ۵۰۳ به گزارش‌های دسترسی NGINX مراجعه کنید. این امر به ویژه در صورتی مفید است که مشکل در گذشته رخ داده باشد یا اگر مشکل به صورت متناوب رخ می‌دهد و شما قادر به ثبت رد آن در رابط کاربری نیستید. برای تعیین این اطلاعات از گزارش‌های دسترسی 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 وجود دارد، شناسه پیام را برای یک یا چند درخواست از این دست، همانطور که در مثال زیر نشان داده شده است، یادداشت کنید:

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

    Sample entry showing status code, message ID, fault source, and fault code

خطاهای اتصال به دلیل وضوح نادرست DNS

تشخیص

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

    خطای onConnectTimeout نشان می‌دهد که پردازشگر پیام نتوانسته در مدت زمان از پیش تعیین‌شده‌ی وقفه‌ی اتصال (پیش‌فرض: ۳ ثانیه) به سرور backend متصل شود. 
    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 برای سرور backend شما معتبر است یا خیر. اگر آدرس IP معتبر است، به خطاهای اتصال بروید.
  4. اگر آدرس IP نامعتبر باشد، احتمالاً به دلیل مشکلاتی در وضوح DNS ایجاد می‌شود.
  5. مراحل ۳ و ۴ را برای چند درخواست API ناموفق دیگر تکرار کنید و بررسی کنید که آیا همان آدرس‌های IP نامعتبر یا آدرس‌های IP نامعتبر دیگری را مشاهده می‌کنید یا خیر.
  6. در گزارش پردازشگر پیام ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) به دنبال پیام‌هایی با کلمه کلیدی DNS Refresh بگردید. بررسی کنید که آیا آدرس‌های IP بد یا نامعتبر هر از گاهی به حافظه پنهان DNS در پردازشگر پیام اضافه می‌شوند یا خیر. 
    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. این مشکل می‌تواند در صورت وجود هرگونه مشکل در سرورهای DNS معتبر یا سرورهای نام پیکربندی شده در /etc/resolv.conf رخ دهد.

    معمولاً، ممکن است یک یا چند سرور DNS معتبر برای انجام عملیات DNS Resolution پیکربندی شده باشند. اگر هیچ سرور DNS معتبری وجود نداشته باشد، آنگاه به تنظیمات پیکربندی در /etc/resolv.conf مراجعه کرده و DNS Resolution را به صورت مناسب انجام می‌دهد. به عنوان مثال: اگر /etc/resolv.conf برای استفاده از Name Server های خاص پیکربندی شده باشد، از آن Name Server ها برای انجام DNS Resolution استفاده خواهد شد.
  8. اگر مشکلی با سرورهای DNS معتبر یا سرورهای نام مشخص شده در /etc/resolv.conf وجود داشته باشد، نام‌های میزبان سرور backend به آدرس‌های IP بد/نامعتبر تبدیل می‌شوند. سپس آدرس‌های IP بد/نامعتبر در حافظه پنهان DNS پردازنده پیام ذخیره می‌شوند.
    1. اگر مشکل با سرورهای DNS معتبر یا سرورهای نام مشخص شده در /etc/resolv.conf پابرجا باشد، آدرس‌های IP نامعتبر/خراب همچنان در حافظه پنهان DNS پردازنده پیام باقی می‌مانند. تا زمانی که آدرس‌های IP نامعتبر در حافظه پنهان DNS پردازنده پیام ذخیره شوند، درخواست‌ها برای همه آن APIهایی که از سرور backend خاص استفاده می‌کنند با خطای 503 شکست خواهند خورد.
    2. اگر مشکل با سرورهای DNS معتبر یا سرورهای نام مشخص شده در /etc/resolv.conf متناوب باشد، آدرس‌های IP خوب و بد به طور متناوب در حافظه پنهان DNS ذخیره می‌شوند. در این حالت، برای تمام APIهایی که از سرور backend خاص استفاده می‌کنند، به طور متناوب خطای 503 را مشاهده خواهید کرد.
  9. اگر مشکل سرورهای DNS مداوم باشد، شاهد خرابی‌های مداوم خواهید بود. اگر مشکل سرورهای DNS متناوب باشد، شاهد خرابی‌های متناوب خواهید بود. یعنی هر زمان که نام میزبان سرور backend به آدرس‌های IP بد تبدیل شود، خطای 503 را مشاهده خواهید کرد. و هنگامی که نام‌های میزبان سرور backend به آدرس‌های IP خوب تبدیل شوند، شاهد پاسخ‌های موفقیت‌آمیز خواهید بود.

وضوح تصویر

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

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

خطاهای اتصال

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

  • پردازشگر پیام قادر به اتصال در مدت زمان از پیش تعیین شده برای وقفه اتصال نیست. (پیش فرض: ۳ ثانیه)
  • سرور backend اتصال را رد می‌کند.

تشخیص

  1. شناسه پیام درخواست ناموفق را تعیین کنید.
  2. شناسه پیام درخواست خاص را در گزارش پردازشگر پیام ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) جستجو کنید. ممکن است خطاهای زیر را مشاهده کنید:
    1. خطای onConnectTimeout نشان می‌دهد که پردازشگر پیام نتوانسته در مدت زمان از پیش تعیین‌شده‌ی وقفه‌ی اتصال، به سرور backend متصل شود. 
      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 denied نشان می‌دهد که اتصال توسط سرور backend رد شده است. 
      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 مستقیماً از هر یک از پردازنده‌های پیام به سرور backend خاص متصل شوید:
    1. اگر سرور backend به یک آدرس IP واحد متصل می‌شود، از دستور زیر استفاده کنید: 
      telnet BackendServer-IPaddress 443
    2. اگر سرور backend به چندین آدرس IP متصل است، از نام میزبان سرور backend در دستور telnet مانند تصویر زیر استفاده کنید: 
      telnet BackendServer-HostName 443
  4. اگر بتوانید به سرور backend متصل شوید، ممکن است پیامی مانند Connected to backend-server مشاهده کنید. اگر نمی‌توانید به سرور backend متصل شوید، ممکن است به این دلیل باشد که آدرس‌های IP پردازنده‌های پیام در سرور backend خاص مجاز نیستند.

وضوح تصویر

به آدرس‌های IP پردازنده پیام در سرور backend خاص دسترسی بدهید تا ترافیک از پردازنده‌های پیام Edge به سرور backend شما دسترسی پیدا کند. به عنوان مثال، در لینوکس، می‌توانید از iptables برای اجازه دادن به ترافیک از آدرس‌های IP پردازنده پیام در سرور backend استفاده کنید.

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

نام میزبان سرور هدف نادرست است

تشخیص

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

ابزار ردیابی

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

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

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

    Sample request showing error.cause in the trace
  6. اگر متوجه شدید که error.cause نشان می‌دهد که Host قابل دسترسی نیست، احتمالاً علت خطا یکی از موارد زیر است:
    • نام میزبان مشخص شده در پیکربندی سرور/نقطه پایانی هدف نادرست است یا دارای فاصله یا کاراکترهای خاص ناخواسته است.

      برای مثال، همانطور که در زیر نشان داده شده است، یک فاصله ناخواسته در نام میزبان وجود دارد:
      "demo-target.apigee.net "
    • نام میزبان که توسط متغیر target.url در API Proxy با استفاده از AssignMessage یا خط‌مشی جاوا اسکریپت بازنویسی شده است، نادرست است یا دارای فاصله یا هرگونه کاراکتر ویژه ناخواسته دیگری است.
  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. پس از آن یک پیام هشدار نمایش داده می‌شود که در آن پردازنده پیام، آدرس را از حافظه پنهان DNS حذف می‌کند، زیرا دسترسی به میزبان سرور هدف امکان‌پذیر نیست. 
    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 Proxy با استفاده از AssignMessage یا خط‌مشی جاوا اسکریپت بازنویسی شده است، نادرست است یا دارای فاصله یا هرگونه کاراکتر ویژه ناخواسته دیگری است.
  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. با بررسی تعریف سرور هدف مورد استفاده در پروکسی API ناموفق، نام میزبان را تعیین کنید.
      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 handshake

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

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

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

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

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

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

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

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

Flow of client application (northbound connection) through Edge to backend server (southbound connection)

تعیین محل وقوع خطای ۵۰۳ Service Unavailable

برای تعیین اینکه آیا خطای 503 Service Unavailable در اتصال به سمت شمال یا جنوب رخ داده است، از یکی از رویه‌های زیر استفاده کنید.

ردیابی رابط کاربری

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

  1. اگر مشکل هنوز پابرجاست، ردیابی رابط کاربری (UI Trace) را برای API آسیب‌دیده فعال کنید.
  2. اگر ردیابی رابط کاربری برای درخواست ناموفق API نشان دهد که خطای 503 Service Unavailable در جریان درخواست هدف رخ می‌دهد یا توسط سرور backend ارسال می‌شود، پس مشکل از سمت جنوب (یعنی بین پردازنده پیام و سرور backend) است.
  3. اگر ردیابی مربوط به فراخوانی API خاص را دریافت نکردید، مشکل از northbound ، بین برنامه کلاینت و روتر، است.

نظارت بر API

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

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

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

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

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

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