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

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

ویدیوها

برای کسب اطلاعات بیشتر در مورد حل خطاهای 503 Service Unavailable Error ویدیوی زیر را تماشا کنید.

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

علامت

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

پیام های خطا

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

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.

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

علل

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

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

علت توضیحات چه کسی می تواند مراحل عیب یابی را انجام دهد
سرور اضافه بار سرور پشتیبان بیش از حد بارگذاری شده است یا بیش از ظرفیت خود است و نمی تواند درخواست های مشتری ورودی جدید را مدیریت کند. کاربران Edge Public و Private Cloud
سرور در حال تعمیر و نگهداری سرور Backend ممکن است به طور موقت تحت تعمیر و نگهداری باشد. کاربران Edge Public و Private Cloud

علت: بارگذاری بیش از حد سرور/سرور تحت تعمیر و نگهداری

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

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

تشخیص

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

  • ابزار ردیابی
  • گزارش های دسترسی NGINX
  • تماس مستقیم با سرور پشتیبان

برای آشنایی با هر روش روی برگه های زیر کلیک کنید.

ابزار ردیابی

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

    در اینجا یک نمونه اسکرین شات ردیابی است که پاسخ 503 سرویس غیرقابل دسترس دریافت شده از سرور مورد نظر را نشان می دهد:

  5. روی مرحله Response دریافت شده از سرور مورد نظر کلیک کنید و بخش‌های Response Headers و Response Content را مرور کنید تا ببینید آیا اطلاعات مفیدی دارند یا خیر:
    • سرصفحه‌های پاسخ ممکن است حاوی هدر سرور باشد که نشان می‌دهد پاسخ خطا از کجا ارسال شده است.
    • محتوای پاسخ ممکن است حاوی اطلاعات بیشتری در مورد دلیل ارسال کد پاسخ 503 توسط سرور مورد نظر باشد.
  6. با بررسی مقادیر X-Apigee-fault-source و X-Apigee-fault-code در مرحله AX (Analytics Data Recorded) در ردیابی با استفاده از مراحل زیر، تأیید کنید که خطای 503 از سرور مورد نظر می آید:
    1. همانطور که در تصویر زیر نشان داده شده است، روی فاز AX (Analytics Data Recorded) کلیک کنید:
    2. جزئیات فاز را به بخش Response Headers بروید و مقادیر X-Apigee-fault-code و X-Apigee-fault-source را مطابق شکل زیر تعیین کنید:
    3. اگر مقادیر X-Apigee-fault-source و X-Apigee-fault-code با مقادیر نشان داده شده در جدول زیر مطابقت داشته باشند، می توانید تأیید کنید که خطای 503 از سرور هدف می آید:
      سرصفحه های پاسخ ارزش
      X-Apigee-fault-source هدف
      X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
  7. بررسی کنید که آیا از زنجیره پراکسی استفاده می کنید، یعنی آیا سرور هدف/نقطه پایانی هدف در حال فراخوانی پروکسی دیگری در Apigee است. برای تعیین این:
    1. به مرحله درخواست ارسال شده به سرور مورد نظر برگردید و روی دکمه Show Curl کلیک کنید و نام مستعار میزبان سرور مورد نظر را تعیین کنید.
    2. اگر نام مستعار میزبان سرور هدف به یک نام مستعار میزبان مجازی اشاره می کند، آنگاه زنجیره پروکسی است. در این مورد، باید تمام مراحل بالا را برای پراکسی زنجیره‌ای تکرار کنید تا مشخص کنید که چه چیزی باعث خطای 503 Service Unavailable شده است. در این موارد 503 Service Unavailable ممکن است در سایر پروکسی های زنجیره ای در مراحل دیگر نیز اتفاق بیفتد که می توان با استفاده از این کتاب بازی تشخیص داد.
    3. اگر نام مستعار میزبان سرور هدف به سرور باطن شما اشاره می کند، سپس به Resolution بروید.

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

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

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

    در اینجا یک ورودی نمونه وجود دارد که خطای 503 ناشی از سرور مورد نظر را نشان می دهد:

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

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

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

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

قطعنامه

اگر مطمئن شدید که خطای 503 از سرور باطن می‌آید، می‌توانید برای حل این مشکل اقدامات زیر را انجام دهید:

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

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

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

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

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

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

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

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

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

  • پیام خطای کامل برای درخواست های ناموفق مشاهده شد.
  • سازمان، نام محیط و نام پروکسی API که برای آنها خطاهای 503 مشاهده می کنید.
  • API Proxy Bundle.
  • فایل ردیابی حاوی درخواست ها با خطای 503 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
  • دوره زمانی با اطلاعات منطقه زمانی که خطاهای 503 رخ داده است.