500 خطای سرور داخلی - پخش جریانی فعال است

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

علامت

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

پیام‌های خطا

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

HTTP/1.1 500 Internal Server Error

این ممکن است با یک پیام خطا مانند این دنبال شود:

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

علل احتمالی

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

علت: دسترسی به Payload با فعال بودن Streaming

تشخیص

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

1. جلسه ردیابی را فعال کنید و فراخوانی API را برای ایجاد مجدد مشکل - خطای داخلی سرور ۵۰۰ - انجام دهید.
2. یکی از درخواست‌های ناموفق را انتخاب کنید و مسیر پیگیری را بررسی کنید.
3. مراحل مختلف ردیابی را طی کنید و محل وقوع خرابی را پیدا کنید.
4. این خطا ممکن است هنگام تجزیه‌ی بار داده‌ی درخواست/پاسخ توسط یک خط‌مشی رخ داده باشد.
5. در اینجا یک نمونه اسکرین‌شات ردیابی که سیاست JSONThreatProtection را نشان می‌دهد، آورده شده است. با خطای "Expecting } در خط ۱" مواجه شدیم:

   

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

   سیاست شکست خورده: JSONThreatProtection

   جریان: درخواست پروکسی

6. تعریف خط‌مشی ناموفق را بررسی کنید و محتوای داده‌ای که در حال تجزیه است را بررسی کنید.

   در سناریوی مثال، سیاست JSONThreatProtection با نام JSON-Threat-Protection که با شکست مواجه شده است را بررسی کنید و عنصر <Source> را نیز بررسی کنید.

   <JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
      <DisplayName>JSON Threat Protection</DisplayName>
      <ArrayElementCount>20</ArrayElementCount>
      <ContainerDepth>10</ContainerDepth>
      <ObjectEntryCount>15</ObjectEntryCount>
      <ObjectEntryNameLength>50</ObjectEntryNameLength>
      <Source>request</Source>
      <StringValueLength>1000</StringValueLength>
   </JSONThreatProtection>

   توجه داشته باشید که عنصر <Source> به request. این بدان معناست که خطا هنگام تجزیه‌ی payload درخواست رخ داده است.

7. با بررسی درخواست API، نوع payload در حال تجزیه را تعیین کنید.

شما می‌توانید محتوای درخواست payload و هدر Content-Type را در درخواست API بررسی کنید. در مثال زیر از دستور curl، از یک payload از نوع JSON استفاده شده است.

curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

همچنین می‌توانید سیاستی که با شکست مواجه شده را بررسی کنید و نوع payload در حال تجزیه را تعیین کنید. در سناریوی مثال بالا، سیاست JSON-Threat-Protection با شکست مواجه شده است. این نشان می‌دهد که payload باید در قالب JSON باشد.

8. اگر فایل ارسالی معتبر نباشد، ممکن است با این خطا مواجه شوید.

9. اگر محتوای مخرب معتبر باشد، اما همچنان خطاهایی مانند آنچه در بخش پیام‌های خطا ذکر شده است را دریافت می‌کنید، علت این خطاها این است که هنگام فعال بودن استریمینگ، به محتوای مخرب دسترسی پیدا می‌شود.

   بسته به نوع داده‌ای که توسط سیاست تجزیه می‌شود (مطابق با مرحله ۶)، محتوای داده را در ابزار Trace در مرحله مناسب بررسی کنید.

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

   

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

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

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

10. در مرحله بعد، بسته به اینکه سیاست ناموفق در جریان API Proxy در کجا استفاده می‌شود، تعاریف Proxy و Target Endpoint را بررسی کنید. بررسی کنید که آیا streaming فعال شده است یا خیر.

    در سناریوی مثال، سیاست ناموفق در جریان درخواست Proxy اجرا شد (همانطور که در مرحله 5 بالا تعیین شد)؛ بنابراین، نقطه پایانی Proxy را بررسی کنید:

    <ProxyEndpoint name="default">
    ...
      <HTTPProxyConnection>
        <BasePath>/v1/weather</BasePath>
        <VirtualHost>secure</VirtualHost>
        <Properties>
          <Property name="response.streaming.enabled">true</Property>
          <Property name="request.streaming.enabled">true</Property>
        </Properties>
      </HTTPProxyConnection>
    </ProxyEndpoint>

    همانطور که در مثال بالا مشاهده می‌شود، درخواست‌های استریمینگ همانطور که با مقدار true برای ویژگی " request.streaming.enabled" مشخص شده است، فعال شده‌اند.

    بنابراین، علت خطا، استفاده از سیاست JSONThreatProtection در API Proxy است که هنگام فعال بودن استریمینگ به بار داده درخواست دسترسی پیدا می‌کند. این امر باعث ایجاد خطا می‌شود زیرا باعث بافر شدن در API Proxy می‌شود و هدف استفاده از استریمینگ در Apigee Edge را از بین می‌برد.

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

11. شما می‌توانید با بررسی مقدار "X-Apigee-fault-source" در فاز "AX" (Analytics Data Recorded) در ردیابی با استفاده از مراحل زیر، تأیید کنید که خطای ۵۰۰ به دلیل سیاست ایجاد شده است:
    1. همانطور که در تصویر زیر نشان داده شده است، روی مرحله " AX " (داده‌های تحلیلی ثبت شده) کلیک کنید:

       

    2. جزئیات فاز را به پایین اسکرول کنید تا به بخش «سرتیترهای خطا» برسید و مقادیر "X-Apigee-fault-code" ، "X-Apigee-fault-source" و "X-Apigee-fault-policy" را مطابق شکل زیر تعیین کنید:

       

    3. اگر مقدار "X-Apigee-fault-source" همانطور که در تصویر بالا نشان داده شده است، برابر با "policy" باشد، نشان می‌دهد که خطا به دلیل دسترسی policy به payload هنگام فعال بودن streaming ایجاد شده است.

وضوح تصویر

دسترسی به محتوای درخواست/پاسخ با فعال بودن پخش جریانی، یک ضدالگو است، همانطور که در بخش «ضدالگو: دسترسی به محتوای درخواست/پاسخ هنگام فعال بودن پخش جریانی» توضیح داده شده است.

1. اگر می‌خواهید بار داده را پردازش کنید، باید با حذف ویژگی‌های " request.streaming.enabled" and " response.streaming.enabled" همانطور که در مثال ProxyEndpoint زیر نشان داده شده است، استریمینگ را در Proxy/Target Endpoint غیرفعال کنید:

   <ProxyEndpoint name="default">
   ...
     <HTTPProxyConnection>
       <BasePath>/v1/weather</BasePath>
       <VirtualHost>secure</VirtualHost>
     </HTTPProxyConnection>
   </ProxyEndpoint>

   یا

2. اگر می‌خواهید از استریمینگ برای پروکسی(های) API خود استفاده کنید، از هیچ سیاستی در پروکسی API که به محتوای درخواست/پاسخ دسترسی دارد، استفاده نکنید.

توجه:

• در این راهنما، از سیاست JSONThreatProtection برای پردازش درخواست با فعال بودن قابلیت استریمینگ در سناریوی مثال استفاده شده است. این امر منجر به خطای ۵۰۰ Internal Server Error با خطاهای مختلف شده است.
• این خطاها را می‌توان در سیاست‌هایی مانند JSONToXML و XMLToJSON نیز مشاهده کرد که هنگام فعال بودن استریم، بارهای درخواست یا پاسخ را پردازش می‌کنند.
• اکیداً توصیه می‌کنیم از چنین سیاست‌هایی در پروکسی‌هایی که نیاز به دسترسی به داده‌های مخرب هنگام فعال بودن پخش دارند، استفاده نکنید.
• انجام این کار یک ضدالگو است، همانطور که در Antipattern: Access the request/response payload when streaming is enabled مستند شده است.

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

اگر از Private Cloud استفاده می‌کنید، از این مرحله صرف نظر کنید.

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

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

اگر می‌خواهید وقتی خطای ۵۰۰ از سمت پالیسی ارسال می‌شود، مطلع شوید، باید هشدار مربوط به کد وضعیت ۵۰۰ را با منبع خطا به عنوان پروکسی تنظیم کنید.

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

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

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

• نام سازمان
• نام محیط
• نام پروکسی API
• دستور curl را به همراه درخواست payload (در صورت وجود) برای تولید مجدد خطای ۵۰۰ تکمیل کنید.
• فایل ردیابی حاوی درخواست‌هایی با خطای ۵۰۰ Internal Server
• اگر خطاهای ۵۰۰ در حال حاضر رخ نمی‌دهند، دوره زمانی به همراه اطلاعات منطقه زمانی که خطاهای ۵۰۰ در گذشته رخ داده‌اند را ارائه دهید.

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

• پیام خطای کامل مشاهده شده برای درخواست‌های ناموفق
• سازمان، نام محیط و نام پروکسی API که برای آن خطای ۵۰۰ مشاهده می‌کنید
• بسته پروکسی API
• بار داده‌ای که در درخواست استفاده شده است (در صورت وجود)
• فایل ردیابی حاوی درخواست‌هایی با خطای ۵۰۰ Internal Server
• گزارش‌های دسترسی NGINX ( /opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log )
• گزارش‌های پردازشگر پیام ( /opt/apigee/var/log/edge-message-processor/logs/system.log )
• دوره زمانی به همراه اطلاعات منطقه زمانی که خطای ۵۰۰ رخ داده است.