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

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

ویدیوها

برای اطلاعات بیشتر در مورد خطاهای 503 به ویدیوهای زیر مراجعه کنید:

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

علامت

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

پیام های خطا

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

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 مواجه شود.

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

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

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

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

ابزار ردیابی

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

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

    Message ID in Phase Details section

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

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

همچنین می توانید برای تعیین شناسه پیام خطاهای 503 به گزارش های دسترسی NGINX مراجعه کنید. این به ویژه در صورتی مفید است که مشکل در گذشته رخ داده باشد یا اگر مشکل متناوب باشد و شما نتوانید ردیابی را در رابط کاربری ثبت کنید. برای تعیین این اطلاعات از لاگ های دسترسی NGINX از مراحل زیر استفاده کنید:

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

    نمونه ورودی خطای 503 را نشان می دهد

    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 نشان می دهد که پردازشگر پیام قادر به اتصال به سرور پشتیبان در مدت زمان توقف اتصال از پیش تعیین شده (پیش فرض: 3 ثانیه) نبوده است. 
    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 نامعتبر باشد، به احتمال زیاد می تواند به دلیل مشکلات مربوط به وضوح DNS باشد.
  5. مرحله 3 و مرحله 4 را برای چند درخواست API ناموفق دیگر تکرار کنید و بررسی کنید که آیا همان آدرس 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 پیکربندی شده باشد. اگر هیچ سرور DNS معتبری وجود نداشته باشد، آنگاه به تنظیمات پیکربندی در /etc/resolv.conf برمی‌گردد و رزولوشن DNS را مطابق مناسب انجام می‌دهد. به عنوان مثال: اگر /etc/resolv.conf برای استفاده از سرورهای نام خاصی پیکربندی شده باشد، آن سرورهای نام برای انجام وضوح DNS استفاده خواهند شد.
  8. اگر مشکلی با سرورهای DNS معتبر یا سرورهای نام مشخص شده در /etc/resolv.conf وجود داشته باشد، نام میزبان سرور باطن به آدرس‌های IP بد/نامعتبر حل می‌شود. آدرس‌های IP بد/نامعتبر سپس در حافظه پنهان DNS پردازنده پیام ذخیره می‌شوند.
    1. اگر مشکل سرورهای DNS معتبر یا سرورهای نام مشخص شده در /etc/resolv.conf ادامه داشته باشد، آدرس‌های IP بد/نامعتبر همچنان در حافظه پنهان DNS پردازنده پیام باقی می‌مانند. تا زمانی که آدرس‌های IP بد در حافظه پنهان DNS پردازنده پیام ذخیره می‌شوند، درخواست‌ها برای همه آن APIهایی که از سرور باطن خاص استفاده می‌کنند با خطای 503 شکست خواهند خورد.
    2. اگر مشکل سرورهای DNS معتبر یا سرورهای نام مشخص شده در /etc/resolv.conf متناوب باشد، آدرس IP خوب و بد به طور متناوب در حافظه پنهان DNS ذخیره می شود. در این مورد، خطاهای 503 را به طور متناوب برای همه آن APIهایی که از سرور باطن خاص استفاده می کنند، خواهید دید.
  9. اگر مشکل سرورهای DNS پایدار باشد، شاهد خرابی های مداوم خواهید بود. اگر مشکل سرورهای DNS متناوب باشد، خرابی های متناوب را مشاهده خواهید کرد. یعنی هر زمان که نام میزبان سرور باطن به آدرس های IP بد حل شود، خطاهای 503 را مشاهده می کنید. و هنگامی که نام میزبان سرور باطن به آدرس های IP خوب حل شود، آنگاه پاسخ های موفقی را مشاهده خواهید کرد.

قطعنامه

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

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

خطاهای اتصال

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

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

تشخیص

  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 رد شد نشان می دهد که اتصال توسط سرور باطن رد شده است. 
      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 پردازشگر پیام در سرور باطن خاص دسترسی دهید تا به ترافیک پردازنده‌های پیام Edge اجازه دسترسی به سرور باطن شما را بدهد. برای مثال، در لینوکس، می‌توانید از iptables برای اجازه دادن به ترافیک آدرس‌های IP پردازشگر پیام در سرور باطن استفاده کنید.

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

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

تشخیص

اگر نام میزبان مشخص شده در سرور هدف نادرست است، می توانید پاسخ 503 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 را در ردیابی نشان می دهد

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

      به عنوان مثال، یک فضای ناخواسته در نام میزبان مانند شکل زیر وجود دارد:
      "demo-target.apigee.net "
    • نام میزبان بازنویسی شده توسط متغیر target.url در پروکسی API با استفاده از خط مشی 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 سیستم عامل نیز نتوانست نام میزبان را حل کند، دلیل این مشکل نام نادرست میزبان استفاده شده برای سرور مورد نظر است.

    به Resolution بروید.

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

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

  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 با استفاده از خط مشی 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

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

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

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

درک اتصالات شمال و جنوب

در Edge، می توانید با خطای 503 Service Unavailable در اتصال ورودی یا خروجی مواجه شوید:

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

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

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

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

تعیین محل وقوع خطای 503 Service Unavailable

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

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

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

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

نظارت API

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

یک سناریوی نمونه را طی کنید که نحوه عیب‌یابی مشکلات 5xx را با استفاده از 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. در صورت وجود هر گونه خطای 503 برای پروکسی API خاص جستجو کنید.
  3. اگر بتوانید هر خطای 503 را برای API خاص در زمان مشخص شناسایی کنید، آنگاه مشکل در اتصال جنوب (بین پردازشگر پیام و سرور باطن) رخ داده است.
  4. اگر نه، پس مشکل در اتصال شمال (بین برنامه مشتری و روتر) رخ داده است.