502 Bad Gateway - TooBigBody

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

علامت

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

پیام خطا

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

HTTP/1.1 502 Bad Gateway

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

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

علل احتمالی

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

در اینجا علل احتمالی خطا آورده شده است:

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

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

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

تشخیص

1. کد خطا ، منبع خطا و اندازه بار پاسخ را برای خطای مشاهده شده با استفاده از API Monitoring، ابزار Trace یا گزارش‌های دسترسی NGINX همانطور که در مراحل تشخیص مشترک با سناریوی شماره ۱ توضیح داده شده است، تعیین کنید.
2. اگر منبع خطا مقدار target داشته باشد، نشان می‌دهد که اندازه بار داده پاسخ ارسال شده توسط سرور target/backend به Apigee بیشتر از حد مجاز در Apigee Edge است.
3. اندازه بار پاسخ را همانطور که از مرحله 1 تعیین شده است، تأیید کنید.
   • اگر اندازه‌ی بار داده (payload size) بیش از ۱۰ مگابایت باشد، پس دلیل خطا همین است.
   • اگر اندازه‌ی بار داده حدود ۱۰ مگابایت باشد، ممکن است بار داده‌ی پاسخ به صورت فشرده ارسال شده باشد. به «علت: اندازه‌ی بار داده‌ی پاسخ پس از رفع فشار از حد مجاز فراتر رفته است» بروید.
4. با بررسی پاسخ واقعی با استفاده از مراحل زیر، تأیید کنید که اندازه بار داده پاسخ واقعاً بالای 10 مگابایت است:
   1. اگر به درخواست واقعی ارسال شده به سرور هدف/بک‌اند دسترسی ندارید، به Resolution بروید.
   2. اگر به درخواست واقعی ارسال شده به سرور هدف/backend دسترسی دارید، مراحل زیر را انجام دهید:
      1. اگر شما یک کاربر ابر عمومی/ابر خصوصی هستید، مستقیماً از خود سرور بک‌اند یا هر دستگاه دیگری که از آنجا مجاز به ارسال درخواست به سرور بک‌اند هستید، درخواستی به سرور بک‌اند ارسال کنید.
      2. اگر شما یک کاربر ابر خصوصی هستید، می‌توانید درخواست را از طریق یکی از پردازنده‌های پیام به سرور backend نیز ارسال کنید.
      3. با بررسی هدر Content-Length، اندازه‌ی payload ارسالی در پاسخ را تأیید کنید.
      4. اگر متوجه شدید که اندازه‌ی payload بیشتر از حد مجاز در Apigee Edge است، پس مشکل از همین‌جا ناشی می‌شود.

   نمونه پاسخ از سرور backend:

   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 پاسخ می‌دهد.

تشخیص

1. کد خطا، منبع خطا و اندازه بار پاسخ را برای خطای مشاهده شده با استفاده از گزارش‌های API Monitoring، Trace Tool یا NGINX Access همانطور که در مراحل تشخیص مشترک با سناریوی شماره ۲ توضیح داده شده است، تعیین کنید.
2. اگر منبع خطا مقدار target داشته باشد، نشان می‌دهد که اندازه بار پاسخ ارسال شده توسط برنامه target/backend به Apigee بیشتر از حد مجاز در Apigee Edge است.
3. اندازه بار پاسخ را همانطور که از مرحله 1 تعیین شده است، تأیید کنید.
   • اگر اندازه‌ی بار داده (payload size) بیش از ۱۰ مگابایت باشد، پس دلیل خطا همین است.
   • اگر اندازه‌ی payload حدود ۱۰ مگابایت باشد، ممکن است payload پاسخ به صورت فشرده ارسال شده باشد. در این صورت، اندازه‌ی فشرده‌نشده‌ی payload پاسخ فشرده‌شده را بررسی کنید.
4. شما می‌توانید با استفاده از یکی از روش‌های زیر، اعتبارسنجی کنید که آیا پاسخ از مقصد/بک‌اند در قالب فشرده ارسال شده است و اندازه فشرده نشده آن بزرگتر از حد مجاز است یا خیر:

   ردیابی

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

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

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

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

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

         نمونه پاسخ دریافتی از سرور backend:

         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 حدود ۱۵ مگابایت بود.

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

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

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

      این نشان می‌دهد که اندازه بار مفید پاسخ بیش از ۱۰ مگابایت است و Apigee وقتی اندازه شروع به فراتر رفتن از حد مجاز ۱۰ مگابایت می‌کند، خطایی با کد خطا به صورت protocol.http.TooBigBody ارسال می‌کند.

وضوح تصویر

محدودیت‌ها

شرکت Apigee انتظار دارد که برنامه‌ی کلاینت و سرور backend، اندازه‌ی بار داده (payload) بزرگتر از حد مجاز، همانطور که برای Request/response size در Apigee Edge Limits مستند شده است، ارسال نکنند.

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

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

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

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

   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 نیاز دارید، به بخش «باید اطلاعات تشخیصی را جمع‌آوری کنید» بروید.

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

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

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

• نام سازمان
• نام محیط
• نام پروکسی 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