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

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

ویدیوها

ویدیو توضیحات
500 خطای سرور داخلی - ناشی از باطن یک 500 Internal Server Error در زمان واقعی ناشی از سرور باطن را به همراه مراحل عیب یابی و رفع خطا نشان می دهد.

علامت

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

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

پیام های خطا

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

HTTP/1.1 500 Internal Server Error

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

نمونه شماره 1

نمونه پاسخ سرور باطن شماره 1

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

نمونه شماره 2

نمونه پاسخ سرور Backend شماره 2

<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 ممکن است به دلایل مختلفی توسط سرور باطن بازگردانده شود. این کتاب راهنما نحوه عیب یابی با استفاده از مراحل رایج و رفع این خطا را بدون توجه به علت آن توضیح می دهد.

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

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

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

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

مانیتورینگ API

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

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

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

  2. به سازمانی که می‌خواهید در آن موضوع را بررسی کنید بروید.

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

  5. کد خطا را در برابر زمان ترسیم کنید.

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

    ( مشاهده تصویر بزرگتر )

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

    ( مشاهده تصویر بزرگتر )

  8. روی View logs کلیک کنید و ردیف درخواست ناموفق را گسترش دهید.

    ( مشاهده تصویر بزرگتر )

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

ردیابی

روش شماره 2: با استفاده از ابزار Trace

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

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

  2. اطمینان حاصل کنید که نمایش همه FlowInfos فعال است:

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

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

    ( مشاهده تصویر بزرگتر )

  6. در Trace به فاز AX (Analytics Data Recorded) بروید و روی آن کلیک کنید.

  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-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target
    X-Apigee-Message-ID MESSAGE_ID

NGINX

روش شماره 3: استفاده از گزارش های دسترسی 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 را تعیین کنید.

    نمونه خطای 500 از گزارش دسترسی NGINX:

    ( مشاهده تصویر بزرگتر )

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

    سرصفحه ها ارزش
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target

علت: خطا در سرور باطن

تشخیص

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

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

    ردیابی

    استفاده از Trace:

    اگر یک جلسه Trace برای شکست دارید، مراحل زیر را انجام دهید:

    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>

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

    با سرور باطن تماس بگیرید

    برقراری تماس مستقیم با سرور پشتیبان:

    می توانید یک تماس مستقیم با سرور پشتیبان برقرار کنید و:

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

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

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

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

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

    گزارش های سرور Backend

    استفاده از گزارش های سرور باطن

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

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

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

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

قطعنامه

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

در مثالی که در بالا توضیح داده شد، ممکن است مجبور شوید برای رفع این مشکل از کاربران بخواهید اعتبارنامه معتبری را پاس کنند.

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

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

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

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

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

  • نام سازمان
  • نام محیط زیست
  • نام پروکسی API
  • برای بازتولید خطای 500 دستور curl کامل کنید
  • فایل ردیابی حاوی درخواست هایی با 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 خطا رخ داده است.