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

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

ویدیوها

برای کسب اطلاعات بیشتر در مورد حل خطای ۵۰۰ Internal Server Error، ویدیوهای زیر را تماشا کنید.

ویدئو توضیحات
مقدمه مقدمه‌ای بر خطای ۵۰۰ Internal Server و دلایل احتمالی آن ارائه می‌دهد. همچنین یک خطای ۵۰۰ Internal Server در زمان واقعی را به همراه مراحل عیب‌یابی و حل خطا نشان می‌دهد.
مدیریت فراخوانی سرویس و استخراج خطاهای متغیر دو خطای ۵۰۰ Internal Server Error ناشی از سیاست‌های Service Callout و Extract Variable را نشان می‌دهد و نحوه عیب‌یابی و حل این خطاها را نشان می‌دهد.
خطاهای خط‌مشی جاوا اسکریپت را مدیریت کنید خطای ۵۰۰ سرور داخلی ناشی از یک سیاست جاوا اسکریپت و مراحل عیب‌یابی و حل این خطا را نشان می‌دهد.
مدیریت خرابی‌ها از سرورهای backend مثالی از خطای ۵۰۰ سرور داخلی که ناشی از خرابی در سرور backend است را نشان می‌دهد و مراحل رفع خطاها را شرح می‌دهد.

علامت

برنامه‌ی کلاینت، کد وضعیت HTTP 500 را به همراه پیام "خطای داخلی سرور" به عنوان پاسخی برای فراخوانی‌های API دریافت می‌کند. خطای 500 داخلی سرور می‌تواند ناشی از خطایی در حین اجرای هر سیاستی در Edge یا خطایی در سرور هدف/بک‌اند باشد.

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

پیام‌های خطا

ممکن است پیام خطای زیر را دریافت کنید:

HTTP/1.1 500 Internal Server Error

در برخی موارد، ممکن است پیام خطای دیگری را مشاهده کنید که جزئیات بیشتری دارد. در اینجا یک نمونه پیام خطا آورده شده است:

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

علل احتمالی

خطای ۵۰۰ Internal Server می‌تواند به دلایل مختلفی رخ دهد. در Edge، دلایل را می‌توان بر اساس محل وقوع خطا به دو دسته اصلی طبقه‌بندی کرد:

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

خطای اجرا در یک خط‌مشی لبه‌ای

ممکن است به دلایلی یک سیاست در پروکسی API با شکست مواجه شود. در این بخش نحوه عیب‌یابی مشکل در صورت بروز خطای ۵۰۰ Internal Server Error در حین اجرای یک سیاست توضیح داده شده است.

تشخیص

مراحل تشخیصی برای کاربران ابر خصوصی و عمومی

اگر جلسه رابط کاربری ردیابی برای خطا دارید، پس:

  1. تأیید کنید که خطا ناشی از اجرای یک سیاست بوده است. برای جزئیات بیشتر به تعیین منبع مشکل مراجعه کنید.
  2. اگر خطا هنگام اجرای سیاست رخ داد، ادامه دهید.. اگر خطا توسط سرور backend ایجاد شده است، به خطا در سرور backend بروید.
  3. درخواست API که با خطای ۵۰۰ Internal Server Error مواجه شده است را در trace انتخاب کنید.
  4. درخواست را بررسی کنید و سیاست خاصی که شکست خورده است یا جریانی با نام "خطا" که بلافاصله پس از سیاست شکست خورده در ردیابی قرار دارد را انتخاب کنید.
  5. با بررسی فیلد "error" در بخش Properties یا محتوای Error، جزئیات بیشتری در مورد خطا کسب کنید.
  6. با استفاده از جزئیاتی که در مورد خطا جمع‌آوری کرده‌اید، سعی کنید علت آن را تعیین کنید.

مراحل تشخیصی فقط برای کاربران ابر خصوصی

اگر جلسه رابط کاربری ردیابی را ندارید، پس:

  1. تأیید کنید که خطا هنگام اجرای یک سیاست رخ داده است. برای جزئیات بیشتر به تعیین منبع مشکل مراجعه کنید.
  2. اگر خطا ناشی از اجرای سیاست بود، ادامه دهید. اگر خطا در حین اجرای سیاست رخ داد، ادامه دهید. اگر خطا توسط سرور backend ایجاد شده بود، به بخش خطا در سرور backend بروید.
  3. از گزارش‌های دسترسی NGINX همانطور که در بخش «تعیین منبع مشکل» توضیح داده شده است، برای تعیین سیاست ناموفق در پروکسی API و همچنین شناسه پیام درخواست منحصر به فرد استفاده کنید.
  4. لاگ‌های پردازشگر پیام ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) را بررسی کنید و شناسه پیام درخواست منحصر به فرد را در آن جستجو کنید.
  5. اگر شناسه پیام درخواست منحصر به فرد را پیدا کردید، ببینید آیا می‌توانید اطلاعات بیشتری در مورد علت شکست به دست آورید.

وضوح تصویر

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

مثال‌های زیر نحوه تعیین علت و راه‌حل انواع مختلف مسائل را نشان می‌دهند.

اگر در عیب‌یابی خطای ۵۰۰ Internal Server Error به کمک بیشتری نیاز دارید یا گمان می‌کنید که این مشکل در خود مرورگر Edge وجود دارد، با پشتیبانی Apigee تماس بگیرید.

مثال ۱: عدم موفقیت در سیاست فراخوانی سرویس به دلیل خطا در سرور backend

اگر فراخوانی سرور backend در چارچوب سیاست Service Callout با خطایی مانند 4XX یا 5XX مواجه شود، با آن به عنوان خطای 500 Internal Server Error برخورد خواهد شد.

  1. در اینجا مثالی آورده شده است که در آن سرویس backend با خطای ۴۰۴ در سیاست فراخوانی سرویس (Service Callout) از کار می‌افتد. پیام خطای زیر به کاربر نهایی ارسال می‌شود: 
    {
"fault":
     { "detail":
           { "errorcode":"steps.servicecallout.ExecutionFailed"
           },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
 failed. Reason: ResponseCode 404 is treated as error"
          }
     }
}
  2. رابط کاربری ردیابی زیر، کد وضعیت ۵۰۰ را نشان می‌دهد که به دلیل خطایی در سیاست فراخوانی سرویس ایجاد شده است:

  3. در این مثال، ویژگی "error" دلیل عدم موفقیت سیاست فراخوانی سرویس را به صورت "ResponseCode 404 به عنوان خطا در نظر گرفته می‌شود" فهرست می‌کند. این خطا ممکن است در صورتی رخ دهد که منبعی که از طریق URL سرور backend در سیاست فراخوانی سرویس در دسترس است، در دسترس نباشد.
  4. در دسترس بودن منبع را در سرور backend بررسی کنید. ممکن است به طور موقت/دائم در دسترس نباشد یا به مکان دیگری منتقل شده باشد.

مثال ۱ وضوح تصویر

  1. در دسترس بودن منبع را در سرور backend بررسی کنید. ممکن است به طور موقت/دائم در دسترس نباشد یا به مکان دیگری منتقل شده باشد.
  2. آدرس اینترنتی سرور backend را در خط‌مشی فراخوانی سرویس اصلاح کنید تا به یک منبع معتبر و موجود اشاره کند.
  3. اگر منبع فقط موقتاً در دسترس نیست، پس از در دسترس قرار گرفتن منبع، درخواست API را ارسال کنید.

مثال ۲: خطا در سیاست استخراج متغیرها

حال بیایید به مثال دیگری نگاه کنیم، که در آن خطای ۵۰۰ Internal Server Error به دلیل خطایی در سیاست Extract Variables ایجاد شده است و ببینیم چگونه می‌توان مشکل را عیب‌یابی و حل کرد.

  1. ردیابی زیر در جلسه رابط کاربری، کد وضعیت ۵۰۰ را به دلیل خطا در سیاست Extract Variables نشان می‌دهد:

  2. خط‌مشی ناموفق Extract Variables را انتخاب کنید، به پایین اسکرول کنید و برای جزئیات بیشتر به بخش «محتوای خطا» نگاهی بیندازید:

  3. محتوای خطا نشان می‌دهد که متغیر "serviceCallout.oamCookieValidationResponse" در خط‌مشی Extract Variables موجود نیست. همانطور که از نام متغیر پیداست، باید پاسخ خط‌مشی Service Callout قبلی را در خود نگه دارد.
  4. سیاست فراخوانی سرویس (Service Callout) را در ردیابی انتخاب کنید، ممکن است متوجه شوید که متغیر " serviceCallout.oamCookieValidationResponse " تنظیم نشده است. این نشان می‌دهد که فراخوانی سرویس backend با شکست مواجه شده و در نتیجه متغیر پاسخ خالی است.
  5. اگرچه سیاست فراخوانی سرویس با شکست مواجه شده است، اجرای سیاست‌ها پس از سیاست فراخوانی سرویس ادامه می‌یابد زیرا پرچم "continueOnError" در سیاست فراخوانی سرویس روی درست تنظیم شده است، همانطور که در زیر نشان داده شده است: 

    <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
  <DisplayName>Callout.OamCookieValidation</DisplayName>
  <Properties />
  <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  </Request>
  <Response>serviceCallout.oamCookieValidationResponse</Response>
  <HTTPTargetConnection>
    <Properties />
    <URL>http://{Url}</URL>
  </HTTPTargetConnection>
</ServiceCallout>
  6. به شناسه پیام منحصر به فرد "X-Apigee.Message-ID" برای این درخواست API خاص از ردیابی، به شرح زیر توجه کنید:
    1. مرحله «داده‌های تحلیلی ثبت‌شده» را از درخواست انتخاب کنید.
    2. به پایین اسکرول کنید و مقدار X-Apigee.Message-ID را یادداشت کنید.

  7. گزارش پردازشگر پیام ( /opt/apigee/var/log/edge-message-processor/system.log ) را مشاهده کنید و شناسه پیام منحصر به فرد ذکر شده در مرحله ۶ را جستجو کنید. پیام خطای زیر برای درخواست API خاص مشاهده شد:
    2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX

    خطای فوق نشان می‌دهد که سیاست فراخوانی سرویس (Service Callout) به دلیل خطای اتمام زمان اتصال هنگام اتصال به سرور backend با شکست مواجه شده است.

  8. برای تعیین علت خطای زمان اتصال، دستور telnet را از پردازنده(های) پیام به سرور backend اجرا کنید. دستور telnet خطای "زمان اتصال به پایان رسید" را مطابق شکل زیر نشان داد:
    telnet mybackend.domain.com 443
Trying XX.XX.XX.XX...
telnet: connect to address XX.XX.XX.XX: Connection timed out

    معمولاً این خطا در شرایط زیر مشاهده می‌شود:

    • وقتی سرور backend طوری پیکربندی نشده باشد که اجازه عبور ترافیک از پردازنده‌های پیام لبه (Edge Message Processors) را بدهد.
    • اگر سرور backend به پورت خاص گوش نمی‌دهد.

    در مثال نشان داده شده در بالا، اگرچه سیاست Extract Variables با شکست مواجه شد، اما علت اصلی این بود که Edge قادر به اتصال به سرور backend در سیاست Service Callout نبود. و علت این شکست این بود که سرور backend برای اجازه دادن به ترافیک از پردازنده‌های پیام Edge پیکربندی نشده بود.

    سیاست Extract Variables شما رفتار متفاوتی خواهد داشت و ممکن است به دلایل مختلفی شکست بخورد. شما می‌توانید با بررسی پیام موجود در ویژگی خطا ، بسته به علت شکست سیاست Extract Variables خود، مشکل را به طور مناسب عیب‌یابی کنید.

مثال ۲ وضوح تصویر

  1. علت خطا یا عدم موفقیت در سیاست Extract Variables را به طور مناسب برطرف کنید.
  2. در مثال نشان داده شده در بالا، راه حل، اصلاح پیکربندی شبکه برای اجازه دادن به ترافیک از پردازنده‌های پیام لبه به سرور backend شما بود. این کار با اجازه دادن به لیست کردن آدرس‌های IP پردازنده‌های پیام در سرور backend خاص انجام شد. به عنوان مثال، در لینوکس، می‌توانید از iptables برای اجازه دادن به ترافیک از آدرس‌های IP پردازنده پیام در سرور backend استفاده کنید.

مثال ۳: خطا در سیاست JavaCallout

حال بیایید به یک مثال دیگر نگاه کنیم، که در آن خطای ۵۰۰ Internal Server Error به دلیل خطایی در Java Callout policy ایجاد می‌شود و نحوه عیب‌یابی و حل مشکل را بررسی خواهیم کرد.

  1. ردگیری رابط کاربری زیر، کد وضعیت ۵۰۰ را به دلیل خطایی در Java Callout Policy نشان می‌دهد:

  2. برای دریافت جزئیات خطا، همانطور که در شکل زیر نشان داده شده است، جریانی با نام "خطا" و به دنبال آن خط‌مشی فراخوانی ناموفق جاوا را انتخاب کنید:

  3. در این مثال، ویژگی "error" در بخش Properties نشان می‌دهد که این خطا به دلیل استفاده از رمز عبور منقضی شده هنگام اتصال به پایگاه داده اوراکل از طریق خط‌مشی JavaCallout رخ داده است. فراخوانی جاوای شما متفاوت رفتار خواهد کرد و پیام متفاوتی را در ویژگی error نمایش می‌دهد.
  4. کد خط‌مشی JavaCallout را بررسی کنید و پیکربندی صحیحی که باید استفاده شود را تأیید کنید.

مثال ۳ وضوح

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

خطا در سرور Backend

خطای ۵۰۰ Internal Server Error همچنین می‌تواند از سرور backend سرچشمه بگیرد. در این بخش نحوه عیب‌یابی مشکل در صورتی که خطا از سرور backend باشد، توضیح داده شده است.

تشخیص

مراحل تشخیصی برای همه کاربران

علت سایر خطاهای backend می‌تواند بسیار متفاوت باشد. شما باید هر موقعیت را به طور مستقل تشخیص دهید.

  1. تأیید کنید که خطا توسط سرور backend ایجاد شده است. برای جزئیات بیشتر به تعیین منبع مشکل مراجعه کنید.
  2. اگر خطا توسط سرور backend ایجاد شده باشد، ادامه دهید. اگر خطا هنگام اجرای پالیسی رخ داده است، به خطای اجرا در Edge Policy بروید.
  3. بسته به اینکه آیا به جلسه ردیابی برای API ناموفق دسترسی دارید یا خیر، یا اینکه backend یک سرور Node.js است، مراحل زیر را دنبال کنید:

اگر برای فراخوانی ناموفق API، جلسه ردیابی (Trace session) ندارید :

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

اگر برای فراخوانی ناموفق API، یک جلسه ردیابی (Trace session) دارید :

اگر جلسه ردیابی (Trace session) دارید، مراحل زیر به شما در تشخیص مشکل کمک می‌کند.

  1. در ابزار Trace، درخواست API که با خطای ۵۰۰ Internal Server Error شکست خورده است را انتخاب کنید.
  2. همانطور که در شکل زیر نشان داده شده است، مرحله "پاسخ دریافت شده از سرور هدف" را از درخواست API ناموفق انتخاب کنید:

  3. برای دریافت جزئیات مربوط به خطا، بخش «محتوای پاسخ» را بررسی کنید.

  4. در این مثال، محتوای پاسخ که یک پاکت SOAP است، رشته خطا را به صورت پیام "غیرمجاز" نشان می‌دهد . محتمل‌ترین علت این مشکل این است که اعتبارنامه‌های مناسب (نام کاربری/رمز عبور، توکن دسترسی و غیره) توسط کاربر به سرور backend ارسال نشده است. این مشکل را می‌توان با ارسال اعتبارنامه‌های صحیح به سرور backend برطرف کرد.

اگر backend یک سرور Node.js باشد:

  1. اگر backend یک سرور Backend مربوط به Node.js است، گزارش‌های Node.js را برای API Proxy خاص در رابط کاربری Edge بررسی کنید ( کاربران Cloud عمومی و خصوصی می‌توانند گزارش‌های Node.js را بررسی کنند ). اگر شما یک کاربر Edge Private Cloud هستید، می‌توانید گزارش‌های Message Processor خود ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) را نیز برای جزئیات بیشتر در مورد خطا بررسی کنید.

    گزینه NodeJS Logs در رابط کاربری Edge - تب Overview از API Proxy

وضوح تصویر

  1. پس از شناسایی علت خطا، مشکل را در سرور backend خود برطرف کنید.
  2. اگر یک سرور بک‌اند Node.js باشد:
    1. بررسی کنید که آیا خطا از کد سفارشی شما ناشی می‌شود یا خیر و در صورت امکان، مشکل را برطرف کنید.
    2. اگر خطا از کد سفارشی شما ایجاد نشده است یا اگر به کمک نیاز دارید، با پشتیبانی Apigee تماس بگیرید.

اگر در عیب‌یابی خطای ۵۰۰ Internal Server Error به کمک بیشتری نیاز دارید یا گمان می‌کنید که این مشکل در خود مرورگر Edge وجود دارد، با پشتیبانی Apigee تماس بگیرید.

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

برای تعیین اینکه آیا خطای ۵۰۰ Internal Server Error در حین اجرای یک سیاست در پروکسی API یا توسط سرور backend رخ داده است، از یکی از رویه‌های زیر استفاده کنید.

استفاده از Trace در رابط کاربری

توجه: مراحل این بخش را کاربران ابر عمومی و خصوصی می‌توانند انجام دهند.

  1. اگر مشکل هنوز پابرجاست، ردیابی را در رابط کاربری برای API آسیب‌دیده فعال کنید.
  2. پس از ثبت ردپا، درخواست API که کد پاسخ آن ۵۰۰ است را انتخاب کنید.
  3. تمام مراحل درخواست API ناموفق را بررسی کنید و بررسی کنید که کدام مرحله خطای ۵۰۰ Internal Server را برمی‌گرداند:
    1. اگر خطا هنگام اجرای یک سیاست رخ داد، به بخش «خطای اجرا در یک سیاست لبه‌ای» بروید.
    2. اگر سرور backend با خطای ۵۰۰ Internal Server پاسخ داده است، به بخش Error in the Backend Server بروید.

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

توجه: مراحل این بخش فقط توسط کاربران Public Cloud قابل انجام است.

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

یک سناریوی نمونه را که نحوه عیب‌یابی مشکلات 5xx با APIهای شما را با استفاده از API Monitoring نشان می‌دهد، قدم به قدم بررسی کنید . برای مثال، ممکن است بخواهید هشداری تنظیم کنید تا وقتی تعداد کدهای وضعیت 500 یا خطاهای steps.servicecallout.ExecutionFailed از یک آستانه خاص فراتر رفت، مطلع شوید.

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

توجه: مراحل این بخش فقط برای کاربران Edge Private Cloud است.

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

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

    نمونه ورودی که خطای خط‌مشی را نشان می‌دهد

    نمونه ورودی که خطای سرور هدف را نشان می‌دهد

  4. وقتی تشخیص دادید که آیا این خطا مربوط به خط‌مشی است یا خطای سرور هدف:
    1. اگر خطای مربوط به خط‌مشی است، به بخش خطای اجرا در یک خط‌مشی لبه‌ای بروید.
    2. اگر خطا مربوط به سرور هدف است، به بخش خطا در سرور بک‌اند بروید.