502 Bad Gateway - TooBigBody

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

علامت

برنامه سرویس گیرنده کد وضعیت HTTP 502 Bad Gateway را با protocol.http.TooBigBody کد خطا دریافت می کند.http.TooBigBody به عنوان پاسخی برای تماس های API.

پیغام خطا

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

HTTP/1.1 502 Bad Gateway

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

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

علل احتمالی

این خطا در صورتی رخ می‌دهد که اندازه بار ارسال شده توسط سرور هدف/بک‌اند به Apigee Edge به عنوان بخشی از پاسخ HTTP از حد مجاز در Apigee Edge بیشتر باشد.

در اینجا دلایل احتمالی خطا وجود دارد:

مراحل تشخیص رایج

برای تشخیص این خطا از یکی از ابزارها/تکنیک های زیر استفاده کنید:

علت: حجم بار پاسخگویی بیشتر از حد مجاز است

تشخیص

1. کد خطا ، منبع خطا و اندازه بار پاسخ را برای خطای مشاهده شده با استفاده از مانیتورینگ API، ابزار Trace، یا گزارش های دسترسی NGINX همانطور که در مراحل تشخیص رایج با سناریوی شماره 1 توضیح داده شده است، تعیین کنید.
2. اگر منبع خطا دارای مقدار target باشد، این نشان می‌دهد که اندازه بار پاسخ ارسال شده توسط سرور هدف/بک‌اند به Apigee بیشتر از حد مجاز در Apigee Edge است.
3. اندازه بار پاسخ را همانطور که از مرحله 1 تعیین شده است، تأیید کنید.
   • اگر حجم محموله بیش از 10 مگابایت محدودیت مجاز است، پس این دلیل خطا است.
   • اگر حجم محموله ~ 10 مگابایت محدودیت مجاز باشد، ممکن است بار پاسخ به فرمت فشرده ارسال شود. برو به علت: اندازه بار پاسخ از حد مجاز پس از فشرده سازی فراتر می رود .
4. با بررسی پاسخ واقعی با استفاده از مراحل زیر، تأیید کنید که حجم بار پاسخ در واقع > 10 مگابایت محدودیت مجاز است:
   1. اگر به درخواست واقعی ارائه شده به سرور هدف/بکاند دسترسی ندارید، به Resolution بروید.
   2. اگر به درخواست واقعی ارسال شده به سرور هدف/بک‌اند دسترسی دارید، مراحل زیر را انجام دهید:
      1. اگر کاربر عمومی Cloud/Private Cloud هستید، مستقیماً از سرور باطن یا هر دستگاه دیگری که از آنجا مجاز به ارائه درخواست به سرور باطن هستید، به سرور باطن درخواست دهید.
      2. اگر کاربر Private Cloud هستید، می توانید از یکی از پردازشگرهای پیام نیز درخواست را به سرور پشتیبان ارسال کنید.
      3. با بررسی هدر Content-Length اندازه بار ارسال شده در پاسخ را بررسی کنید.
      4. اگر متوجه شدید که اندازه محموله بیش از حد مجاز در Apigee Edge است، دلیل این مشکل همین است.

   نمونه پاسخ از سرور باطن:

   curl -v https://BACKENDSERVER-HOSTNAME/testfile
   

   * About to connect() to 10.14.0.10 port 9000 (#0)
   *   Trying 10.14.0.10...
   * Connected to 10.14.0.10 (10.148.0.10) port 9000 (#0)
   > GET /testfile HTTP/1.1
   > User-Agent: curl/7.29.0
   > Host: 10.14.0.10:9000
   > Accept: */*
   >
   < HTTP/1.1 200 OK
   < Accept-Ranges: bytes
   < Content-Length: 11534336
   < Content-Type: application/octet-stream
   < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
   < Date: Wed, 30 Jun 2021 09:22:41 GMT
   <
   ----snipped----
   <Response Body>

   در مثال بالا، Content-Length: 11534336 (which is ~11 MB) را می بینید که دلیل این خطا است زیرا از حد مجاز در Apigee Edge فراتر رفته است.

قطعنامه

رجوع به قطعنامه شود.

علت: اندازه بار پاسخگویی پس از رفع فشار از حد مجاز فراتر می رود

اگر محموله پاسخ در قالب فشرده ارسال شود و هدر پاسخ Content-Encoding روی gzip , Apigee بار پاسخ را از حالت فشرده خارج می کند. در طول فرآیند رفع فشار، اگر Apigee اندازه محموله را بزرگتر از حد مجاز در Apigee Edge بیابد. ، سپس فشرده سازی بیشتر را متوقف می کند و بلافاصله با 502 Bad Gateway و protocol.http.TooBigBody کد خطا پاسخ می دهد.http.TooBigBody.

تشخیص

1. کد خطا، منبع خطا و اندازه بار پاسخ را برای خطای مشاهده شده با استفاده از API Monitoring، Trace Tool یا گزارش های دسترسی NGINX همانطور که در مراحل تشخیص رایج با سناریوی شماره 2 توضیح داده شده است، تعیین کنید.
2. اگر منبع خطا دارای مقدار target باشد، این نشان می‌دهد که اندازه بار پاسخ ارسال شده توسط برنامه هدف/بک‌اند به Apigee بیشتر از حد مجاز در Apigee Edge است.
3. اندازه بار پاسخ را همانطور که از مرحله 1 تعیین شده است، تأیید کنید.
   • اگر حجم محموله بیش از 10 مگابایت محدودیت مجاز است، پس این دلیل خطا است.
   • اگر حجم محموله ~ 10 مگابایت محدودیت مجاز باشد، ممکن است بار پاسخ به فرمت فشرده ارسال شود. در این مورد، اندازه فشرده نشده بار پاسخ فشرده را بررسی کنید.
4. با استفاده از یکی از روش‌های زیر می‌توانید تأیید کنید که آیا پاسخ از هدف/پشت‌هند در قالب فشرده ارسال شده است و اندازه غیرفشرده بیشتر از حد مجاز است:

   ردیابی

   با استفاده از ابزار Trace:

   1. اگر ردی برای درخواست ناموفق ثبت کرده اید، به مراحل شرح داده شده در Trace و مراجعه کنید
      1. مقدار target.received.content.length را تعیین کنید
      2. بررسی کنید که آیا درخواست مشتری حاوی سرصفحه Content-Encoding: gzip است یا خیر
   2. اگر مقدار target.received.content.length حدود 10 مگابایت حد مجاز باشد، و سرصفحه پاسخ Content-Encoding: gzip ، پس دلیل این خطا همین است.

   درخواست واقعی

   استفاده از درخواست واقعی:

   1. اگر به درخواست واقعی ارائه شده به سرور هدف/بکاند دسترسی ندارید، به Resolution بروید.
   2. اگر به درخواست واقعی ارسال شده به سرور هدف/بک‌اند دسترسی دارید، مراحل زیر را انجام دهید:
      1. اندازه بار ارسال شده در پاسخ را به همراه هدر Content-Encoding ارسال شده در پاسخ بررسی کنید.
      2. اگر متوجه شدید که هدر پاسخ Content-Encoding روی gzip تنظیم شده است و اندازه فشرده نشده محموله بیشتر از حد مجاز در Apigee Edge است، دلیل این خطا همین است.

         نمونه پاسخ دریافت شده از سرور باطن:

         curl -v https://BACKENDSERVER-HOSTNAME/testzippedfile.gz
         

         * About to connect() to 10.1.0.10 port 9000 (#0)
         *   Trying 10.1.0.10...
         * Connected to 10.1.0.10 (10.1.0.10) port 9000 (#0)
         > GET /testzippedfile.gz HTTP/1.1
         > User-Agent: curl/7.29.0
         > Host: 10.1.0.10:9000
         > Accept: */*
         >
         < HTTP/1.1 200 OK
         < Accept-Ranges: bytes
         < Content-Encoding: gzip
         < Content-Type: application/x-gzip
         < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
         < Testheader: test
         < Date: Wed, 07 Jul 2021 10:14:16 GMT
         < Transfer-Encoding: chunked
         <
         ----snipped----
         <Response Body>

         در مورد بالا، هدر Content-Encoding: gzip ارسال می شود و حجم فایل testzippedfile.gz در پاسخ کمتر از حد مجاز است، اما اندازه فایل فشرده نشده testzippedfile ~15 مگابایت بود.

   گزارش های پردازشگر پیام

   استفاده از گزارش‌های پردازشگر پیام:

   1. اگر کاربر Private Cloud هستید، می‌توانید از گزارش‌های پردازشگر پیام برای تعیین اطلاعات کلیدی درباره خطاهای HTTP 502 استفاده کنید.

   2. گزارش‌های پردازشگر پیام را بررسی کنید

      /opt/apigee/var/log/edge-message-processor/logs/system.log

   3. جستجو کنید تا ببینید آیا خطاهای 502 در طول یک مدت زمان مشخص وجود دارد (اگر مشکل در گذشته اتفاق افتاده است) یا آیا درخواست هایی وجود دارد که هنوز با 502 ناموفق هستند. می توانید از رشته های جستجوی زیر استفاده کنید:

      grep -ri "chunkCount"
      

      grep -ri "BadGateway: Body buffer overflow"
      

   4. خطوطی را از system.log خواهید دید که شبیه به شکل زیر هستند (ممکن است TotalRead و chunkCount در مورد شما متفاوت باشد):

      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.SERVICE -
      TrackingInputChannel.checkMessageBodyTooLarge() : Message is too large.
      TotalRead 10489856 chunkCount 2571
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.CLIENT -
      HTTPClient$Context.onInputException() :
      ClientInputChannel(ClientChannel[Connected:
      Remote:10.148.0.10:9000 Local:10.148.0.9:42240]@9155
      useCount=1 bytesRead=0 bytesWritten=182 age=23ms  lastIO=0ms
      isOpen=true).onExceptionRead exception: {}
      com.apigee.errors.http.server.BadGateway: Body buffer overflow
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR
      ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
      AbstractResponseListener.onError(HTTPResponse@77cbd7c4,
      Body buffer overflow)

   5. در طول فرآیند فشرده سازی، به محض اینکه پردازشگر پیام تشخیص داد که کل بایت های خوانده شده > 10 مگابایت است، متوقف می شود و خط زیر را چاپ می کند:

      Message is too large. TotalRead 10489856 chunkCount 2571

      به این معنی است که حجم بار پاسخگویی بیش از 10 مگابایت است و Apigee زمانی که اندازه شروع به تجاوز از حد مجاز 10 مگابایت با کد خطا به عنوان protocol.http.TooBigBody Apigee خطا را نشان می‌دهد.http.TooBigBody

قطعنامه

محدودیت ها

Apigee انتظار دارد که برنامه کلاینت و سرور پشتیبان اندازه های باری بیشتر از حد مجاز را که برای Request/response size در Apigee Edge Limits مستند شده است ارسال نکند.

1. اگر کاربر Public Cloud هستید، حداکثر محدودیت اندازه بار درخواست و پاسخ همانگونه است که برای Request/response size در Apigee Edge Limits مستند شده است.
2. اگر کاربر Private Cloud هستید، ممکن است حداکثر حد پیش‌فرض برای اندازه بار درخواست و پاسخ را تغییر داده باشید (حتی اگر این یک روش توصیه‌شده نیست). با دنبال کردن دستورالعمل‌های نحوه بررسی محدودیت فعلی، می‌توانید حداکثر محدودیت اندازه بار درخواستی را تعیین کنید.

چگونه حد فعلی را بررسی کنیم؟

این بخش نحوه تأیید اینکه ویژگی HTTPResponse.body.buffer.limit با یک مقدار جدید در پردازشگرهای پیام به روز شده است را توضیح می دهد.

1. در دستگاه Message Processor، ویژگی HTTPResponse.body.buffer.limit را در پوشه /opt/apigee/edge-message- processor/conf جستجو کنید و بررسی کنید که چه مقداری مطابق شکل زیر تنظیم شده است:

   grep -ri "HTTPResponse.body.buffer.limit" /opt/apigee/edge-message-processor/conf
   

2. نتیجه نمونه دستور بالا به شرح زیر است:

   /opt/apigee/edge-message-processor/conf/http.properties:HTTPResponse.body.buffer.limit=10m

3. در خروجی مثال بالا، توجه کنید که ویژگی HTTPResponse.body.buffer.limit با مقدار 10m در http.properties تنظیم شده است.

   این نشان می دهد که محدودیت اندازه بار درخواست پیکربندی شده در Apigee برای Private Cloud 10 مگابایت است.

اگر همچنان به کمک پشتیبانی Apigee نیاز دارید، به Must collect information diagnostic بروید.

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

اطلاعات تشخیصی زیر را جمع آوری کنید و سپس با پشتیبانی Apigee Edge تماس بگیرید:

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

• نام سازمان
• نام محیط زیست
• نام پروکسی API
• دستور کامل curl که برای بازتولید خطای 502 استفاده می شود
• فایل ردیابی برای درخواست های API
• خروجی کامل پاسخ از سرور هدف/باطن همراه با اندازه بار

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

• پیام خطای کامل برای درخواست های ناموفق مشاهده شد
• نام سازمان
• نام محیط زیست
• بسته پروکسی API
• فایل ردیابی برای درخواست های API ناموفق
• دستور کامل curl که برای بازتولید خطای 502 استفاده می شود
• خروجی کامل پاسخ از سرور هدف/باطن همراه با اندازه بار

• گزارش های دسترسی NGINX /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log

  جایی که: ORG ، ENV و PORT# با مقادیر واقعی جایگزین می‌شوند.

• گزارش سیستم پردازشگر پیام /opt/apigee/var/log/edge-message-processor/logs/system.log