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

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

فیلم های

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

علامت

برنامه مشتری کد وضعیت HTTP 500 را با پیام "خطای سرور داخلی" به عنوان پاسخی برای تماس های API دریافت می کند. خطای 500 Internal Server ممکن است به دلیل خطا در اجرای هر خط مشی در 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"
   }
}

علل احتمالی

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

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

یک خط مشی در پروکسی API ممکن است به دلایلی شکست بخورد. این بخش نحوه عیب یابی مشکل را در صورت بروز خطای 500 سرور داخلی در حین اجرای یک خط مشی توضیح می دهد.

تشخیص

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

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

1. بررسی کنید که خطا ناشی از اجرای یک سیاست است. برای جزئیات بیشتر به تعیین منبع مشکل مراجعه کنید.
2. اگر خطا در حین اجرای خط مشی رخ داده است، ادامه دهید. اگر خطا توسط سرور پشتیبان ایجاد شده است، به Error in the Backend Server بروید.
3. درخواست API را که با خطای 500 داخلی سرور در ردیابی ناموفق است، انتخاب کنید.
4. درخواست را بررسی کنید و خط مشی خاصی را که شکست خورده است یا جریانی به نام "خطا" را انتخاب کنید که بلافاصله پس از خط مشی ناموفق در ردیابی است.
5. با بررسی فیلد "خطا" در بخش Properties یا محتوای خطا، جزئیات بیشتری در مورد خطا دریافت کنید.
6. با استفاده از جزئیاتی که درباره خطا جمع آوری کرده اید، سعی کنید علت آن را مشخص کنید.

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

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

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

وضوح

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

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

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

مثال 1: خطا در خط مشی Callout سرویس به دلیل خطا در سرور backend

اگر تماس با سرور پشتیبان در خط مشی Service Callout با هر خطایی مانند 4XX یا 5XX ناموفق باشد، به عنوان خطای سرور داخلی 500 تلقی می شود.

1. در اینجا مثالی وجود دارد که در آن سرویس Backend با خطای 404 در خط مشی 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. جلسه ردیابی رابط کاربری زیر 500 کد وضعیت ناشی از خطا در خط مشی Callout Service را نشان می دهد:

   

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

مثال 1 قطعنامه

1. در دسترس بودن منبع را در سرور باطن بررسی کنید. ممکن است به طور موقت/دائمی در دسترس نباشد یا ممکن است به مکان دیگری منتقل شده باشد.
2. URL سرور backend را در خط مشی Service Callout ثابت کنید تا به یک منبع معتبر و موجود اشاره کند.
3. اگر منبع فقط به طور موقت در دسترس نیست، پس از در دسترس بودن منبع، درخواست API را انجام دهید.

مثال 2: شکست در سیاست استخراج متغیرها

بیایید اکنون به مثال دیگری نگاه کنیم، جایی که خطای داخلی سرور 500 به دلیل خطا در خط مشی Extract Variables ایجاد می شود و نحوه عیب یابی و رفع مشکل را مشاهده می کنیم.

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

   

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

   <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 Data Recorded" را از درخواست انتخاب کنید.
   2. به پایین بروید و مقدار X-Apigee.Message-ID را یادداشت کنید.

   

7. گزارش پردازشگر پیام ( /opt/apigee/var/log/edge-message-processor/system.log ) را مشاهده کنید و شناسه پیام منحصر به فرد ذکر شده در مرحله 6 را جستجو کنید. پیام خطای زیر برای درخواست 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
   

   خطای بالا نشان می دهد که خط مشی Callout Service به دلیل خطای مهلت زمانی اتصال هنگام اتصال به سرور باطن شکست خورده است.

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

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

   به طور معمول، این خطا در شرایط زیر مشاهده می شود:

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

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

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

مثال 2 رزولوشن

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

مثال 3: شکست در خط مشی JavaCallout

بیایید اکنون به یک مثال دیگر نگاه کنیم، جایی که خطای سرور داخلی 500 به دلیل یک خطا در خط مشی Java Callout ایجاد می شود و نحوه عیب یابی و رفع مشکل را مشاهده می کنیم.

1. ردیابی رابط کاربری زیر 500 کد وضعیت را به دلیل خطا در خط مشی فراخوانی جاوا نشان می دهد:

   

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

   

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

مثال 3 وضوح

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

خطا در سرور Backend

یک خطای 500 سرور داخلی نیز می تواند از سرور باطن نشات بگیرد. این بخش نحوه عیب یابی مشکل را در صورت بروز خطا از سرور باطن توضیح می دهد.

تشخیص

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

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

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

اگر جلسه Trace برای تماس ناموفق API ندارید :

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

اگر یک جلسه Trace برای تماس ناموفق API دارید :

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

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

   

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

   

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

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

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

   گزینه NodeJS Logs در Edge UI - Tab Overview of API Proxy

   

وضوح

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

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

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

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

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

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

1. اگر مشکل همچنان فعال است، ردیابی را در رابط کاربری برای API آسیب دیده فعال کنید.
2. هنگامی که ردیابی را گرفتید، درخواست API را انتخاب کنید که کد پاسخ را 500 نشان می دهد.
3. در تمام مراحل درخواست API ناموفق پیمایش کنید و بررسی کنید که کدام فاز خطای سرور داخلی 500 را برمی گرداند:
   1. اگر خطا در حین اجرای یک خط مشی رخ داد، سپس به Execution Error در یک خط مشی لبه بروید.
   2. اگر سرور باطن با 500 سرور داخلی پاسخ داده است، سپس به خطا در سرور پشتیبان بروید.

استفاده از API Monitoring

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

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

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

استفاده از NGINX Access Logs

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

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

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

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

   

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

   

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