‫۵۰۰ خطای سرور داخلی

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

ویدیوها

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

نشانه

برنامه مشتری کد وضعیت HTTP ۵۰۰ را با پیام «خطای سرور داخلی» به‌عنوان پاسخ برای تماس‌های API دریافت می‌کند. خطای «۵۰۰: خطای سرور داخلی» می‌تواند ناشی از خطایی درطول اجرای هریک از خط‌مشی‌های 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"
   }
}

علل احتمالی

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

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

خط‌مشی درون کارگزار نیابتی API ممکن است به دلایلی ناموفق باشد. این بخش توضیح می‌دهد که اگر خطای «۵۰۰: خطای سرور داخلی» درحین اجرای خط‌مشی رخ داد، چگونه مشکل را عیب‌یابی کنید.

تشخیص

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

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

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

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

اگر جلسه واسط کاربر ردیابی ندارید، در این‌صورت:

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

وضوح

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

مثال‌های زیر نشان می‌دهد که چگونه علت و راه‌حل انواع مختلف مشکلات را تعیین کنید.

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

مثال ۱: عدم موفقیت در خط‌مشی «نمانام خدمات» به‌دلیل خطای سرور زیرینه

اگر تماس با سرور زیرینه در خط‌مشی «نوشته راهنمای تماس با سرویس» با هر خطایی مثل ‫4XX یا 5XX ناموفق باشد، به‌عنوان «۵۰۰ خطای سرور داخلی» درنظر گرفته می‌شود.

1. در اینجا نمونه‌ای از جایی که سرویس زیرینه با خطای ۴۰۴ در خط‌مشی «گزینه تماس سرویس» ناموفق است آورده شده است. پیام خطای زیر به کاربر نهایی ارسال می‌شود:

   {
   "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. در این مثال، دارایی «خطا» دلیل ناموفق بودن خط‌مشی «خدمات پیامک» را به‌صورت «کد پاسخ ۴۰۴ به‌عنوان خطا درنظر گرفته می‌شود» فهرست می‌کند. اگر منبعی که ازطریق نشانی وب سرور پشتیبان در خط‌مشی «خدمات پیام‌واره» به آن دسترسی پیدا می‌شود دردسترس نباشد، ممکن است این خطا رخ دهد.
4. دسترسی منبع را در سرور نهایی بررسی کنید. ممکن است موقتاً/برای همیشه دردسترس نباشد یا ممکن است به مکان دیگری منتقل شده باشد.

وضوح نمونه ۱

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

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

اکنون به مثال دیگری نگاه می‌کنیم که در آن خطای «۵۰۰: خطای سرور داخلی» به‌دلیل خطایی در خط‌مشی «استخراج متغیرها» ایجاد شده است و می‌بینیم چگونه می‌توان این مشکل را عیب‌یابی و حل کرد.

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

   

2. خط‌مشی «استخراج متغیرها» را که ناموفق بوده است انتخاب کنید، به پایین پیمایش کنید و برای جزئیات بیشتر به بخش «محتوای خطا» نگاه کنید:
   
   
3. «محتوای خطا» نشان می‌دهد که متغیر «serviceCallout.oamCookieValidationResponse» در خط‌مشی «استخراج متغیرها» دردسترس نیست. همان‌طور که نام متغیر نشان می‌دهد، باید پاسخ خط‌مشی «نوشته راهنمای تماس با سرویس» قبلی را نگه دارد.
4. خط‌مشی «خدمات تماس» را در ردیابی انتخاب کنید و ممکن است متوجه شوید که متغیر «serviceCallout.oamCookieValidationResponse» تنظیم نشده است. این نشان می‌دهد که تماس با سرویس زیرینه ناموفق بوده است و متغیر پاسخ خالی ایجاد شده است.
5. اگرچه خط‌مشی «برخوانی سرویس» ناموفق بوده است، اجرای خط‌مشی‌ها پس‌از خط‌مشی «برخوانی سرویس» ادامه می‌یابد زیرا پرچم «ادامه درصورت خطا» در خط‌مشی «برخوانی سرویس» روی درست تنظیم شده است، همان‌طور که در زیر نشان داده شده است:
   
   

   <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. مرحله «داده‌های Analytics ضبط‌شده» را از درخواست انتخاب کنید.
   2. به‌پایین پیمایش کنید و مقدار X-Apigee.Message-ID را یادداشت کنید.

   

7. گزارش «پردازشگر پیام» را مشاهده کنید (/opt/apigee/var/log/edge-message-processor/system.log) و شناسه پیام یکتایی را که در مرحله ۶ یادداشت کرده‌اید جستجو کنید. پیام خطای زیر برای درخواست میانای برنامه‌سازی کاربردی خاص مشاهده شد: :

   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

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

8. برای تعیین علت خطای پایان مهلت اتصال، فرمان telnet را از «پردازشگر(های) پیام» در سرور زیرینه اجرا کنید. فرمان telnet خطای «اتصال به‌موقع بسته شد» را همان‌طور که در زیر نشان داده شده است ارائه داد:

   telnet mybackend.domain.com 443
   Trying XX.XX.XX.XX...
   telnet: connect to address XX.XX.XX.XX: Connection timed out

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

   • وقتی سرور زیرینه برای اجازه دادن به ترافیک از «پردازنده‌های پیام لبه» پیکربندی نشده باشد.
   • اگر سرور زیرینه در درگاه مشخصی گوش نمی‌دهد.

   در مثال مصور بالا، اگرچه خط‌مشی «استخراج متغیرها» ناموفق بود، اما دلیل واقعی این بود که Edge نتوانست به سرور پشتیبان در خط‌مشی «فراخوانی سرویس» متصل شود. و دلیل این خرابی این بود که سرور پشتیبان برای اجازه دادن به ترافیک از «پردازنده‌های پیام Edge» پیکربندی نشده بود.

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

وضوح نمونه ۲

1. علت خطا یا عدم موفقیت در خط‌مشی «استخراج متغیرها» را به‌درستی برطرف کنید.
2. در مثال مصور بالا، راه‌حل این بود که پیکربندی شبکه اصلاح شود تا ترافیک از «پردازنده‌های پیام لبه‌ای» به سرور زیرینه شما مجاز شود. این کار با فهرست مجاز کردن نشانی‌های IP «پردازشگرهای پیام» در سرور زیرینه خاص انجام شد. برای مثال، در Linux، می‌توانید از iptables برای مجاز کردن ترافیک از نشانی‌های IP «پردازنده پیام» در سرور زیرینه استفاده کنید.

مثال ۳: خطا در خط‌مشی JavaCallout

اکنون به یک مثال دیگر نگاه می‌کنیم که در آن خطای «۵۰۰: خطای سرور داخلی» به‌دلیل خطایی در خط‌مشی «تماس با جاوا» ایجاد شده است و می‌بینیم چگونه می‌توان این مشکل را عیب‌یابی و حل کرد.

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

   

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

   

3. در این مثال، دارایی «خطا» در بخش «دارایی‌ها» نشان می‌دهد که این خرابی به‌دلیل استفاده از گذرواژه منقضی‌شده هنگام اتصال به «پایگاه داده Oracle» از درون خط‌مشی «فراخوانی Java» است. نداپرس جاوا خودتان رفتار متفاوتی خواهد داشت و پیام متفاوتی را در دارایی خطا درج خواهد کرد.
4. کد خط‌مشی JavaCallout را بررسی کنید و پیکربندی صحیح موردنیاز برای استفاده را تأیید کنید.

وضوح مثال ۳

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

خطا در سرور زیرینه

«خطای سرور داخلی ۵۰۰» نیز می‌تواند از سرور زیرینه منشأ بگیرد. این بخش نحوه عیب‌یابی مشکل را درصورتی‌که خطا از سرور زیرینه باشد توضیح می‌دهد.

تشخیص

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

علت سایر خطاهای زیرینه می‌تواند بسیار متفاوت باشد. باید هر وضعیت را به‌طور جداگانه تشخیص دهید.

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

اگر جلسه «ردیابی» برای فراخوانی ناموفق API ندارید:

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

اگر جلسه «ردیابی» برای فراخوانی ناموفق میانای برنامه‌سازی کاربردی دارید:

اگر جلسه «ردیابی» دارید، مراحل زیر به شما کمک می‌کند مشکل را تشخیص دهید.

1. در ابزار «ردیابی»، درخواست میانای برنامه‌سازی کاربردی را که با خطای «۵۰۰ خطای سرور داخلی» ناموفق بوده است انتخاب کنید.
2. مرحله «پاسخ دریافتی از سرور هدف» را از درخواست ناموفق «میانای برنامه‌سازی کاربردی» همان‌طور که در شکل زیر نشان داده شده است انتخاب کنید:

   

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

   

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

اگر زیرینه سرور Node.js است:

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

   گزینه «گزارش‌های NodeJS» در «میانای کاربر Edge» - برگه «نمای کلی» «پراکسی میانای برنامه‌سازی کاربردی»

   

وضوح

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

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

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

از یکی از روش‌های زیر برای تعیین اینکه آیا خطای سرور داخلی ۵۰۰ درطول اجرای خط‌مشی در پراکسی API یا توسط سرور پشتیبان ایجاد شده است یا نه استفاده کنید.

استفاده از «ردیابی» در «میانای کاربر»

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

1. اگر مشکل هنوز فعال است، ردیابی را در واسط کاربر برای «میانای برنامه‌سازی کاربردی» تحت‌تأثیر قرارگرفته فعال کنید.
2. پس‌از ضبط ردیابی، درخواست API را که کد پاسخ آن ۵۰۰ است انتخاب کنید.
3. در همه مراحل درخواست ناموفق API پیمایش کنید و بررسی کنید کدام مرحله خطای سرور داخلی ۵۰۰ را برمی‌گرداند:
   1. اگر خطا درحین اجرای خط‌مشی رخ دهد، به خطای اجرا در خط‌مشی Edge بروید.
   2. اگر سرور زیرینه با «۵۰۰ خطای سرور داخلی» پاسخ داده است، به خطا در سرور زیرینه بروید.

استفاده از «پایش میانای برنامه‌سازی کاربردی»

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

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

گام‌به‌گام ازطریق یک سناریو نمونه که نشان می‌دهد چگونه بااستفاده از «پایش API» مشکلات ۵xx را در APIهای خود عیب‌یابی کنید. برای مثال، ممکن است بخواهید هشداری تنظیم کنید تا وقتی تعداد کدهای وضعیت ۵۰۰ یا خطاهای steps.servicecallout.ExecutionFailed از آستانه خاصی فراتر رفت مطلع شوید.

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

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

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

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

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

   

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

   

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