500 خطای سرور داخلی - سرور Backend

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

ویدیوها

ویدئو توضیحات
خطای ۵۰۰ سرور داخلی - ناشی از backend 500 Internal Server Error که توسط سرور backend ایجاد شده است را به صورت بلادرنگ (real-time) به همراه مراحل عیب‌یابی و حل خطا نشان می‌دهد.

علامت

برنامه‌ی کلاینت، کد وضعیت HTTP 500 را به همراه پیام Internal Server Error به عنوان پاسخی برای فراخوانی‌های API دریافت می‌کند.

کد وضعیت HTTP 500 یک پاسخ خطای عمومی است. این بدان معناست که سرور با شرایط غیرمنتظره‌ای مواجه شده که مانع از انجام درخواست شده است. این خطا معمولاً زمانی توسط سرور بازگردانده می‌شود که هیچ کد خطای دیگری مناسب نباشد.

پیام‌های خطا

برنامه‌ی کلاینت کد پاسخ زیر را دریافت می‌کند:

HTTP/1.1 500 Internal Server Error

علاوه بر این، ممکن است پیام خطایی مشابه آنچه در زیر نشان داده شده است را مشاهده کنید:

نمونه شماره ۱

نمونه پاسخ سرور بک‌اند شماره ۱

{"errorMessage":"Sorry either your e-mail or password didn't match.",
"errorParameters":"{}",
"errorCode":"500",
"errorKey":"INVALID_EMAILPASSWORD"}

نمونه شماره ۲

نمونه پاسخ سرور بک‌اند شماره ۲

<Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

علل احتمالی

500 Internal Server Error می‌تواند به دلایل مختلفی توسط سرور backend برگردانده شود. این راهنما نحوه عیب‌یابی با استفاده از مراحل رایج و حل این خطا را صرف نظر از علت آن توضیح می‌دهد.

علل احتمالی این مشکل به شرح زیر است:

علت توضیحات دستورالعمل‌های عیب‌یابی قابل اجرا برای
خطا در سرور بک‌اند ممکن است سرور بک‌اند به دلایلی از کار بیفتد. کاربران Edge Private و Public Cloud

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

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

نظارت بر API

روش شماره ۱: استفاده از مانیتورینگ API

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

  1. به عنوان کاربری با نقش کاربری مناسب، وارد Apigee Edge UI شوید .

  2. به سازمانی که می‌خواهید مشکل را در آن بررسی کنید، مراجعه کنید.

  3. به صفحه Analyze > API Monitoring > Investigate بروید.
  4. بازه زمانی خاصی را که در آن خطاها را مشاهده کرده‌اید، انتخاب کنید.

  5. رسم کد خطا در مقابل زمان .

  6. سلولی را انتخاب کنید که کد خطای messaging.adaptors.http.flow.ErrorResponseCode در آن قرار دارد، همانطور که در زیر نشان داده شده است:

    ( تصویر را بزرگتر ببینید )

  7. اطلاعات مربوط به کد خطا messaging.adaptors.http.flow.ErrorResponseCode مطابق شکل زیر نمایش داده می‌شود:

    ( تصویر را بزرگتر ببینید )

  8. روی «مشاهده گزارش‌ها» کلیک کنید و ردیف مربوط به درخواست ناموفق را باز کنید.

    ( تصویر را بزرگتر ببینید )

  9. از پنجره Logs ، جزئیات زیر را یادداشت کنید:
    • درخواست شناسه پیام
    • کد وضعیت: 500
    • منبع خطا: target
    • کد خطا: messaging.adaptors.http.flow.ErrorResponseCode

ردیابی

روش شماره ۲: استفاده از ابزار ردیابی

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

  1. جلسه ردیابی را فعال کنید و یا
    • منتظر بمانید تا خطای 500 Internal Server Error با کد خطا messaging.adaptors.http.flow.ErrorResponseCode رخ دهد، یا
    • اگر می‌توانید مشکل را دوباره ایجاد کنید، فراخوانی API را برای ایجاد مجدد مشکل 500 Internal Server Error انجام دهید.

  2. مطمئن شوید که گزینه‌ی Show all FlowInfos فعال است:

  3. یکی از درخواست‌های ناموفق را انتخاب کنید و مسیر پیگیری را بررسی کنید.
  4. مراحل مختلف ردیابی را طی کنید و محل وقوع خرابی را پیدا کنید.

  5. معمولاً خطا را در جریانی پس از دریافت پاسخ از سرور هدف، مطابق شکل زیر، مشاهده خواهید کرد:

    ( تصویر را بزرگتر ببینید )

  6. در مسیر ردیابی، به مرحله AX (داده‌های تحلیلی ثبت‌شده) بروید و روی آن کلیک کنید.

  7. به پایین اسکرول کنید تا به بخش Phase Details Response Headers برسید و مقادیر X-Apigee-fault-code و X-Apigee-fault-source و X-Apigee-Message-ID را مطابق شکل زیر تعیین کنید:

    ( تصویر را بزرگتر ببینید )

  8. به مقادیر X-Apigee-fault-code ، X-Apigee-fault-source و X-Apigee-Message-ID توجه کنید:
    9. هدرهای پاسخ ارزش
    کد خطای X-Apigee messaging.adaptors.http.flow.ErrorResponseCode
    منبع گسل X-Apigee target
    شناسه پیام X-Apigee MESSAGE_ID

انجینکس

روش شماره ۳: استفاده از گزارش‌های دسترسی NGINX

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

  1. اگر شما یک کاربر Private Cloud هستید، می‌توانید از گزارش‌های دسترسی NGINX برای تعیین اطلاعات کلیدی در مورد 500 Internal Server Error استفاده کنید.

  2. گزارش‌های دسترسی NGINX را بررسی کنید:

    /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log

  3. جستجو کنید تا ببینید آیا در یک بازه زمانی خاص (اگر مشکل در گذشته رخ داده است) خطای 500 با کد خطا messaging.adaptors.http.flow.ErrorResponseCode وجود دارد یا خیر، یا اینکه آیا درخواست‌هایی با 500 همچنان با شکست مواجه می‌شوند یا خیر.

  4. اگر هرگونه خطای 500 با X-Apigee-fault-code که با مقدار messaging.adaptors.http.flow.ErrorResponseCode مطابقت دارد، پیدا کردید، مقدار X-Apigee-fault-source را تعیین کنید.

    نمونه خطای ۵۰۰ از لاگ دسترسی NGINX:

    ( تصویر را بزرگتر ببینید )

    ورودی نمونه بالا از لاگ دسترسی NGINX دارای مقادیر زیر برای X-Apigee-fault-code و X-Apigee-fault-source است:

    سربرگ‌ها ارزش
    کد خطای X-Apigee messaging.adaptors.http.flow.ErrorResponseCode
    منبع گسل X-Apigee target

علت: خطا در سرور backend

تشخیص

500 Internal Server Error که توسط سرور backend پاسخ داده می‌شود، می‌تواند به دلایل مختلفی ایجاد شود. شما باید هر موقعیت را به طور مستقل تشخیص دهید.

  1. کد خطا، منبع خطا برای خطای مشاهده شده را با استفاده از API Monitoring، ابزار Trace یا گزارش‌های دسترسی NGINX، همانطور که در مراحل تشخیص مشترک توضیح داده شده است، تعیین کنید.
  2. اگر منبع خطا target و کد خطا messaging.adaptors.http.flow.ErrorResponseCode باشد، نشان می‌دهد که خطا توسط سرور backend برگردانده می‌شود.
  3. برای تشخیص علت مشکل، می‌توانید از یکی از مراحل زیر استفاده کنید:

    ردیابی

    استفاده از ردیابی:

    اگر برای خرابی، جلسه ردیابی (Trace session) دارید، مراحل زیر را انجام دهید:

    1. در Trace، درخواست API که با 500 Internal Server Error شکست خورده است را انتخاب کنید.

    2. همانطور که در شکل زیر نشان داده شده است ، پاسخ دریافتی از فاز سرور هدف را از درخواست API ناموفق انتخاب کنید:

      ( تصویر را بزرگتر ببینید )

    3. به بخش جزئیات فاز (Phase Details) بروید و محتوای پاسخ (Response Content) را که شامل پاسخ از سرور backend است، بررسی کنید.

      نمونه محتوای پاسخ:

      <Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

      در پاسخ بالا، توجه داشته باشید که پیام خطای سرور backend به صورت Not Authorised است. این نشان می‌دهد که کاربر ممکن است اعتبارنامه‌های نامعتبری ارسال کرده باشد و به همین دلیل است که این خطا را دریافت می‌کند.

    فراخوانی سرور بک‌اند

    برقراری تماس مستقیم با سرور backend:

    می‌توانید مستقیماً به سرور backend فراخوانی کنید و:

    • بررسی کنید که آیا همان پاسخ 500 Internal Server Error که هنگام ارسال درخواست از طریق Apigee Edge دریافت کرده‌اید، دریافت می‌کنید یا خیر.
    • پیام خطای (پاسخ) دریافتی از سرور backend را بررسی کنید

    برای برقراری تماس مستقیم با سرور backend، مراحل زیر را انجام دهید:

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

    3. اگر سرور backend فقط از طریق پردازنده‌های پیام قابل دسترسی باشد، می‌توانید از دستور curl ، Postman یا هر REST Client دیگری استفاده کنید و API سرور backend را مستقیماً از پردازنده پیام فراخوانی کنید.

    4. اعتبارسنجی کنید که آیا سرویس backend واقعاً 500 Internal Server Error را برمی‌گرداند یا خیر و پیام خطای (پاسخ) برگردانده شده توسط سرور backend را بررسی کنید و علت این خطا را مشخص کنید.

    گزارش‌های سرور بک‌اند

    استفاده از لاگ‌های سرور بک‌اند

    1. لاگ‌های سرور بک‌اند را بررسی کنید و سعی کنید جزئیات بیشتری در مورد خطا و علت آن به دست آورید.
    2. در صورت امکان، حالت اشکال‌زدایی (debug mode) را در سرور backend فعال کنید تا جزئیات بیشتری در مورد خطا و علت آن به دست آورید.

  4. بررسی کنید که آیا از زنجیره‌سازی پروکسی در نقطه پایانی هدف خاص پروکسی API ناموفق استفاده می‌کنید یا خیر؛ به عبارت دیگر، آیا سرور/نقطه پایانی هدف، پروکسی دیگری را در Apigee Edge فراخوانی می‌کند یا خیر. برای تعیین این موضوع:

    1. اگر رد درخواست ناموفق را دارید، به مرحله درخواست ارسال شده به سرور هدف بروید و روی نمایش حلقه کلیک کنید.

    2. پنجره‌ی Curl for Request Sent to Target Server باز می‌شود که از طریق آن می‌توانید نام مستعار میزبان سرور هدف را تعیین کنید.
    3. نقطه پایانی هدف API Proxy خود را بررسی کنید و بررسی کنید که آیا URL سرور backend یا نام میزبان در سرور هدف به Proxy دیگری یا سرور backend خودتان اشاره می‌کند یا خیر.
    4. اگر نام مستعار میزبان سرور هدف به یک نام مستعار میزبان مجازی اشاره کند، آنگاه زنجیره‌سازی پروکسی رخ داده است. در این حالت، باید تمام مراحل فوق را برای پروکسی زنجیره‌ای تکرار کنید تا زمانی که مشخص شود چه چیزی باعث 500 Internal Server Error می‌شود. در این موارد، 500 Internal Server Error ممکن است در سایر پروکسی‌های زنجیره‌ای در مراحل دیگر نیز رخ دهد که می‌توان با استفاده از دستورالعمل‌های داده شده در این راهنما یا در کتابچه راهنمای خطای ۵۰۰ Internal Server ، آن را تشخیص داده و برطرف کرد.
    5. اگر نام مستعار میزبان سرور هدف به سرور backend شما اشاره می‌کند، به Resolution بروید.

وضوح تصویر

اگر مشخص شد که خطای 500 از سرور backend ناشی می‌شود، با تیم سرور backend خود همکاری کنید تا مشکل را به طور مناسب برطرف کنید.

در مثالی که در بالا مورد بحث قرار گرفت، ممکن است برای رفع این مشکل مجبور شوید از کاربران بخواهید که اعتبارنامه‌های معتبری را ارائه دهند.

نکات کلیدی قابل توجه

  1. پیام خطای واقعی که توسط سرور backend برای 500 Internal Server Error برگردانده می‌شود، تنها در صورتی قابل مشاهده است که شما جلسه ردیابی درخواست‌های ناموفق را ضبط کرده باشید.
  2. پاسخ سرور backend به دلایل امنیتی در API Monitoring، NGINX Access Logs یا Message Processor logs ثبت نخواهد شد.
  3. شما می‌توانید لاگ‌های سرور بک‌اند را بررسی کنید یا حالت اشکال‌زدایی (دیباگ) را در بک‌اند فعال کنید تا جزئیات بیشتری در مورد 500 Internal Server Error و/یا پیام خطای برگردانده شده توسط سرور بک‌اند را مشاهده کنید.

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

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

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

  • نام سازمان
  • نام محیط
  • نام پروکسی API
  • دستور curl را برای بازتولید خطای 500 کامل کنید
  • فایل ردیابی حاوی درخواست‌هایی با 500 Internal Server Error
  • اگر خطاهای 500 در حال حاضر رخ نمی‌دهند، دوره زمانی به همراه اطلاعات منطقه زمانی که خطاهای 500 در گذشته رخ داده‌اند را ارائه دهید.

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

  • پیام خطای کامل مشاهده شده برای درخواست‌های ناموفق
  • سازمان، نام محیط و نام پروکسی API که برای آن خطای 500 مشاهده می‌کنید
  • بسته پروکسی API
  • فایل ردیابی حاوی درخواست‌هایی با 500 Internal Server Error
  • گزارش‌های دسترسی NGINX /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log

    که در آن: ORG ، ENV و PORT# با مقادیر واقعی جایگزین شده‌اند.

  • گزارش‌های سیستم پردازشگر پیام /opt/apigee/var/log/edge-message-processor/logs/system.log
  • دوره زمانی به همراه اطلاعات منطقه زمانی که خطای 500 رخ داده است.