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"
      }
   }
}

علل احتمالی

خطای سرور داخلی 500 ممکن است به دلایل مختلفی رخ دهد. این کتاب پخش بر روی خطای 500 سرور داخلی ناشی از دسترسی به بار درخواست/پاسخ در هنگام فعال بودن جریان تمرکز دارد.

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

تشخیص

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

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

   

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

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

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

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

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

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

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

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

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

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

   

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

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

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

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

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

    <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>

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

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

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

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

       

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

       

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

قطعنامه

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

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

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

   یا

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

توجه:

• در این کتاب پخش، از خط‌مشی JSONThreatProtection برای پردازش بار درخواستی با جریان فعال در سناریوی مثال استفاده شده است. این منجر به 500 خطای داخلی سرور با خطاهای مختلف شد.
• این خطاها را می‌توان با خط‌مشی‌هایی مانند JSONToXML و XMLToJSON نیز مشاهده کرد که در صورت فعال بودن جریان، بارهای درخواست یا پاسخ را پردازش می‌کنند.
• اکیداً توصیه می‌کنیم از چنین خط‌مشی‌هایی در پروکسی‌هایی که نیاز به دسترسی به محموله‌ها در هنگام فعال بودن پخش جریانی دارند، استفاده نکنید.
• انجام این کار یک ضد الگو است، همانطور که در Antipattern مستند شده است: هنگامی که پخش جریانی فعال است به بار درخواست/پاسخ دسترسی پیدا کنید .

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

اگر کاربر Private Cloud هستید، از این روش صرفنظر کنید.

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

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

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

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

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

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

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

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

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