سرویس 503 در دسترس نیست - سرور Backend

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

ویدیوها

برای کسب اطلاعات بیشتر در مورد حل خطای ۵۰۳ Service Unavailable، ویدیوی زیر را تماشا کنید.

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

علامت

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

پیام‌های خطا

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

HTTP/1.1 503 Service Unavailable
HTTP/1.1 503 Service Unavailable: Back-end server is at capacity

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

The server is temporarily unable to service your request due to
maintenance downtime or capacity problems. Please try again later.

توجه: کد پاسخ و پیام خطای فوق فقط مثال هستند. در برخی موارد، ممکن است فقط کد پاسخ خطا را بدون هیچ پیام خطایی دریافت کنید. قالب و محتوای کد پاسخ خطا و پیام خطا ممکن است بسته به پیاده‌سازی سرور backend متفاوت باشد.

علل

کد وضعیت HTTP 503 به این معنی است که سرور در حال حاضر قادر به رسیدگی به درخواست‌های ورودی نیست. معمولاً این خطا به این دلیل رخ می‌دهد که سرور بیش از حد شلوغ است یا به طور موقت برای تعمیرات از دسترس خارج شده است.

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

علت توضیحات چه کسی می‌تواند مراحل عیب‌یابی را انجام دهد؟
سرور بیش از حد بارگذاری شده سرور backend بیش از حد بارگذاری شده یا فراتر از ظرفیت آن است و نمی‌تواند درخواست‌های جدید کلاینت‌ها را مدیریت کند. کاربران فضای ابری عمومی و خصوصی Edge
سرور در دست تعمیر ممکن است سرور backend موقتاً در دست تعمیر باشد. کاربران فضای ابری عمومی و خصوصی Edge

علت: سرور با بار اضافی/سرور در دست تعمیر

در Apigee Edge، خطای 503 Service Unavailable می‌تواند تحت هر یک از شرایط زیر از سرور backend برگردانده شود:

  • یک سرور backend بیش از حد بارگذاری شده/مشغول است و نمی‌تواند هیچ درخواست جدیدی را مدیریت کند.
  • سرور بک‌اند به دلیل تعمیرات و نگهداری برای مدتی موقتاً از دسترس خارج است.

تشخیص

برای تشخیص خطا، می‌توانید از هر یک از سه روش زیر استفاده کنید:

  • ابزار ردیابی
  • گزارش‌های دسترسی NGINX
  • فراخوانی مستقیم به سرور backend

برای آشنایی با هر روش، روی تب‌های زیر کلیک کنید.

ابزار ردیابی

  1. جلسه ردیابی را فعال کنید و فراخوانی API را برای تکرار مشکل - سرویس 503 در دسترس نیست - انجام دهید.
  2. یکی از درخواست‌های ناموفق را انتخاب کنید و مسیر پیگیری را بررسی کنید.
  3. مراحل مختلف ردیابی را طی کنید و محل وقوع خرابی را پیدا کنید.
  4. اگر متوجه شدید که خطای ۵۰۳ به عنوان پاسخ از سرور هدف برگردانده می‌شود، علت خطای ۵۰۳ سرور هدف است.

    در اینجا یک نمونه اسکرین‌شات ردیابی وجود دارد که پاسخ 503 Service Unavailable دریافتی از سرور هدف را نشان می‌دهد:

  5. روی مرحله‌ی پاسخ دریافتی از سرور هدف کلیک کنید و به بخش‌های «سرصفحه‌های پاسخ» و «محتوای پاسخ» بروید تا ببینید آیا اطلاعات مفیدی دارند یا خیر:
    • هدرهای پاسخ ممکن است حاوی هدر سرور باشند که نشان می‌دهد پاسخ خطا از کجا ارسال شده است.
    • محتوای پاسخ ممکن است حاوی اطلاعات اضافی در مورد دلیل ارسال کد پاسخ ۵۰۳ توسط سرور هدف باشد.
  6. با بررسی مقادیر X-Apigee-fault-source و X-Apigee-fault-code در فاز AX (Analytics Data Recorded) در ردیابی با استفاده از مراحل زیر، تأیید کنید که خطای ۵۰۳ از سرور هدف ناشی می‌شود:
    1. همانطور که در تصویر زیر نشان داده شده است، روی مرحله AX (ثبت داده‌های تحلیلی) کلیک کنید:
    2. در بخش «جزئیات فاز» (Phase Details) به پایین اسکرول کنید تا به بخش «سرصفحه‌های پاسخ» (Response Headers) برسید و مقادیر « کد خطای X-Apigee» و «منبع خطای X-Apigee» را مطابق شکل زیر تعیین کنید:
    3. اگر مقادیر X-Apigee-fault-source و X-Apigee-fault-code با مقادیر نشان داده شده در جدول زیر مطابقت داشته باشند، می‌توانید تأیید کنید که خطای ۵۰۳ از سرور هدف ناشی می‌شود:
      هدرهای پاسخ ارزش
      منبع گسل X-Apigee هدف
      کد خطای X-Apigee کد پاسخ خطا در جریان پیام‌رسانی http
  7. بررسی کنید که آیا از زنجیره‌سازی پروکسی استفاده می‌کنید یا خیر، یعنی اینکه آیا سرور/نقطه انتهایی هدف، پروکسی دیگری را در Apigee فراخوانی می‌کند یا خیر. برای تعیین این موضوع:
    1. به مرحله درخواست ارسال شده به سرور هدف برگردید و روی دکمه نمایش حلقه کلیک کنید و نام مستعار میزبان سرور هدف را تعیین کنید.
    2. اگر نام مستعار میزبان سرور هدف به یک نام مستعار میزبان مجازی اشاره کند، آنگاه این یک زنجیره پروکسی است. در این حالت، باید تمام مراحل فوق را برای پروکسی زنجیره‌ای تکرار کنید تا مشخص شود چه چیزی باعث خطای 503 Service Unavailable می‌شود. در این موارد، 503 Service Unavailable ممکن است در سایر پروکسی‌های زنجیره‌ای در مراحل دیگر نیز رخ دهد که می‌توان با استفاده از این راهنما آن را تشخیص داد.
    3. اگر نام مستعار میزبان سرور هدف به سرور backend شما اشاره می‌کند، به Resolution بروید.

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

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

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

    در اینجا یک نمونه ورودی وجود دارد که خطای ۵۰۳ ایجاد شده توسط سرور هدف را نشان می‌دهد:

  4. پروکسی API خاص را بررسی کنید و مطمئن شوید که از زنجیره پروکسی استفاده می‌کنید، یعنی اگر سرور/نقطه انتهایی هدف، پروکسی دیگری را در Apigee فراخوانی نمی‌کند. اگر از زنجیره پروکسی استفاده می‌کنید، باید تمام مراحل فوق را برای پروکسی زنجیره‌ای تکرار کنید تا زمانی که مشخص شود چه چیزی باعث خطای 503 Service Unavailable می‌شود. در این موارد، 503 Service Unavailable ممکن است در سایر پروکسی‌های زنجیره‌ای در مراحل دیگر نیز رخ دهد، که می‌توانید با استفاده از این راهنما آن را تشخیص دهید.
  5. اگر تأیید کردید که از زنجیره پروکسی استفاده نمی‌کنید و خطای ۵۰۳ از سرور backend شما می‌آید، به Resolution بروید.

فراخوانی به سرور Backend

شما می‌توانید مستقیماً با سرور backend تماس بگیرید و تأیید کنید که همان پاسخ 503 Service Unavailable را دریافت می‌کنید که هنگام ارسال درخواست از طریق Apigee Edge دریافت کردید.

  1. مطمئن شوید که تمام هدرها، پارامترهای کوئری و هرگونه اعتبارنامه‌ای که باید به عنوان بخشی از درخواست به سرور بک‌اند ارسال شود را دارید.
  2. اگر سرویس backend به صورت عمومی قابل دسترسی است، می‌توانید از دستور curl، Postman یا هر REST Client دیگری استفاده کنید و API سرور backend را مستقیماً فراخوانی کنید.
  3. اگر سرور backend فقط از طریق پردازنده‌های پیام قابل دسترسی است، می‌توانید از دستور curl، Postman یا هر REST Client دیگری استفاده کنید و API سرور backend را مستقیماً از پردازنده پیام فراخوانی کنید.
  4. تأیید کنید که سرویس backend واقعاً خطای 503 Service Unavailable را برمی‌گرداند.

وضوح تصویر

اگر مطمئن شدید که خطای ۵۰۳ از سمت سرور backend است، می‌توانید برای حل مشکل موارد زیر را انجام دهید:

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

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

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

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

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

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

اگر کاربر فضای ابری عمومی هستید، اطلاعات زیر را ارائه دهید:

  • نام سازمان
  • نام محیط
  • نام پروکسی API
  • دستور curl را برای بازتولید خطای ۵۰۳ کامل کنید
  • فایل ردیابی حاوی درخواست‌هایی با خطای ۵۰۳ Service Unavailable
  • اگر خطاهای ۵۰۳ در حال حاضر رخ نمی‌دهند، دوره زمانی را به همراه اطلاعات منطقه زمانی که خطاهای ۵۰۳ در گذشته رخ داده‌اند، ارائه دهید.

اگر کاربر فضای ابری خصوصی هستید، اطلاعات زیر را ارائه دهید:

  • پیام خطای کامل برای درخواست‌های ناموفق مشاهده شد.
  • سازمان، نام محیط و نام پروکسی API که برای آن خطای ۵۰۳ مشاهده می‌کنید.
  • بسته پروکسی API.
  • فایل ردیابی حاوی درخواست‌هایی با خطای ۵۰۳ Service Unavailable.
  • گزارش‌های دسترسی NGINX. 
    /opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log
  • گزارش‌های پردازنده پیام. 
    /opt/apigee/var/log/edge-message-processor/logs/system.log
  • دوره زمانی به همراه اطلاعات منطقه زمانی که خطاهای ۵۰۳ رخ داده‌اند.