499 اتصال بسته مشتری

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

علامت

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

کد وضعیت 499 را برای چنین درخواست های API در مانیتورینگ API و گزارش های دسترسی NGINX مشاهده خواهید کرد. گاهی اوقات، کدهای وضعیت متفاوتی را در API Analytics مشاهده خواهید کرد، زیرا کد وضعیت را که توسط پردازشگر پیام بازگردانده شده است را نشان می دهد.

پیغام خطا

برنامه های مشتری ممکن است خطاهایی مانند:

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received

چه چیزی باعث تایم اوت مشتری می شود؟

مسیر معمولی برای درخواست API در پلتفرم Edge ، Client > Router > Message Processor > Backend Server است که در شکل زیر نشان داده شده است:

روترها و پردازشگرهای پیام در پلتفرم Apigee Edge با مقادیر زمان‌بندی پیش‌فرض مناسب تنظیم شده‌اند تا اطمینان حاصل شود که تکمیل درخواست‌های API خیلی طول نمی‌کشد.

مهلت زمانی روی مشتری

برنامه های مشتری را می توان با مقدار زمان مناسب بر اساس نیازهای شما پیکربندی کرد.

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

وقفه در روتر

زمان پیش‌فرض پیکربندی شده روی روترها 57 ثانیه است. این حداکثر مدت زمانی است که یک پراکسی API می تواند از زمانی که درخواست API در Edge دریافت می شود تا زمانی که پاسخ ارسال شود، اجرا کند، از جمله پاسخ backend و تمام خط مشی هایی که اجرا می شوند. مهلت زمانی پیش‌فرض را می‌توان روی روترها و میزبان‌های مجازی لغو کرد، همانطور که در پیکربندی مهلت زمانی ورودی/خروجی روی روترها توضیح داده شد.

وقفه در پردازشگرهای پیام

مهلت زمانی پیش‌فرض پیکربندی شده در پردازشگرهای پیام 55 ثانیه است. این حداکثر زمانی است که سرور باطن می تواند درخواست را پردازش کند و به پردازشگر پیام پاسخ دهد . مهلت زمانی پیش‌فرض را می‌توان در پردازشگرهای پیام یا در پروکسی API لغو کرد، همانطور که در پیکربندی مهلت زمانی ورودی/خروجی در پردازشگرهای پیام توضیح داده شده است.

اگر مشتری قبل از اتمام زمان پروکسی API، اتصال با روتر را ببندد، خطای مهلت زمانی درخواست API خاص را مشاهده خواهید کرد. کد وضعیت 499 Client Closed Connection برای چنین درخواست‌هایی در روتر ثبت شده است که می‌توان آن را در گزارش‌های API Monitoring و NGINX Access مشاهده کرد.

علل احتمالی

در Edge، دلایل معمول برای خطای 499 Client Closed Connection عبارتند از:

علت توضیحات دستورالعمل های عیب یابی قابل اجرا برای
مشتری به طور ناگهانی اتصال را بسته است این زمانی اتفاق می‌افتد که مشتری اتصال را می‌بندد زیرا کاربر نهایی درخواست را قبل از تکمیل آن لغو می‌کند. کاربران عمومی و خصوصی Cloud
مهلت زمانی برنامه مشتری این زمانی اتفاق می‌افتد که زمان برنامه مشتری قبل از اینکه پروکسی API زمان پردازش و ارسال پاسخ را داشته باشد تمام می‌شود. معمولاً زمانی این اتفاق می‌افتد که تایم اوت سرویس گیرنده کمتر از مهلت زمانی روتر باشد. کاربران عمومی و خصوصی Cloud

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

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

  • مانیتورینگ API
  • گزارش های دسترسی NGINX

مانیتورینگ API

برای تشخیص خطا با استفاده از API Monitoring:

  1. به صفحه Analyze > API Monitoring > Investigate بروید.
  2. خطاهای 4xx را فیلتر کنید و بازه زمانی را انتخاب کنید.
  3. کد وضعیت طرح در برابر زمان .
  4. سلولی را انتخاب کنید که دارای 499 خطا است مانند شکل زیر:

  5. اطلاعات مربوط به خطای 499 را مطابق شکل زیر در سمت راست صفحه مشاهده خواهید کرد:

  6. در قسمت سمت راست، روی View logs کلیک کنید.

    از پنجره Traffic Logs ، جزئیات زیر را برای برخی از 499 خطا یادداشت کنید:

    • درخواست : این روش درخواست و URI مورد استفاده برای برقراری تماس را ارائه می دهد
    • زمان پاسخ : کل زمان سپری شده برای درخواست را نشان می دهد.

    همچنین می توانید با استفاده از API Monitoring GET logs API همه گزارش ها را دریافت کنید. به عنوان مثال، با جستجو در گزارش‌های مربوط به org ، env ، timeRange و status ، می‌توانید تمام گزارش‌ها را برای تراکنش‌هایی دانلود کنید که در آن زمان مشتری تمام شده است.

    از آنجایی که API Monitoring پراکسی را برای خطاهای HTTP 499 روی - تنظیم می‌کند، می‌توانید از API ( Logs API ) برای دریافت پروکسی مرتبط برای میزبان مجازی و مسیر استفاده کنید.

    به عنوان مثال:

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. برای 499 خطای دیگر، زمان پاسخ را بررسی کنید و بررسی کنید که آیا زمان پاسخ (مثلاً 30 ثانیه) در تمام 499 خطا سازگار است یا خیر.

گزارش های دسترسی NGINX

برای تشخیص خطا با استفاده از گزارش های دسترسی NGINX:

  1. اگر کاربر Private Cloud هستید، می توانید از گزارش های دسترسی NGINX برای تعیین اطلاعات کلیدی در مورد خطاهای HTTP 499 استفاده کنید.
  2. گزارش های دسترسی NGINX را بررسی کنید:
    /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log
  3. جستجو کنید تا ببینید آیا خطاهای 499 در طول یک مدت زمان مشخص وجود دارد (اگر مشکل در گذشته اتفاق افتاده باشد) یا آیا درخواست هایی وجود دارد که هنوز با 499 شکست خورده است.
  4. برای برخی از خطاهای 499 به اطلاعات زیر توجه کنید:
    • کل زمان پاسخگویی
    • درخواست URI
    • عامل کاربر

    نمونه خطای 499 از گزارش دسترسی NGINX:

    2019-08-23T06:50:07+00:00       rrt-03f69eb1091c4a886-c-sy      50.112.119.65:47756
10.10.53.154:8443       10.001  -       -       499     -       422     0
   GET /v1/products HTTP/1.1        -       okhttp/3.9.1    api.acme.org
rrt-03f69eb1091c4a886-c-sy-13001-6496714-1
    50.112.119.65   -       -       -       -       -       -       -       -1      -       -       dc-1  router-pod-1
rt-214-190301-0020137-latest-7d
36       TLSv1.2 gateway-1     dc-1  acme    prod  https   -

    برای این مثال، اطلاعات زیر را می بینیم:

    • کل زمان پاسخگویی: 10.001 ثانیه. این نشان می دهد که کلاینت پس از 10.001 ثانیه به پایان رسیده است
    • درخواست: GET /v1/products
    • میزبان : api.acme.org
    • نماینده کاربر: okhttp/3.9.1
  5. بررسی کنید که آیا زمان پاسخگویی کل و عامل کاربر در تمام 499 خطا یکسان است یا خیر.

علت: کلاینت به طور ناگهانی اتصال را بسته است

تشخیص

  1. هنگامی که یک API از یک برنامه تک صفحه ای که در یک مرورگر یا برنامه تلفن همراه اجرا می شود فراخوانی می شود، اگر کاربر نهایی به طور ناگهانی مرورگر را ببندد، به صفحه وب دیگری در همان برگه بروید یا با کلیک کردن بارگذاری صفحه را متوقف کند، درخواست را لغو می کند. یا روی بستن توقف بارگذاری ضربه بزنید.
  2. اگر این اتفاق بیفتد، تراکنش‌های با وضعیت HTTP 499 معمولاً در زمان پردازش درخواست ( زمان پاسخ ) برای هر یک از درخواست‌ها متفاوت است.
  3. می‌توانید با مقایسه زمان پاسخ و بررسی اینکه آیا برای هر یک از 499 خطا با استفاده از گزارش‌های API Monitoring یا دسترسی NGINX همانطور که در مراحل تشخیص رایج توضیح داده شده است، علت آن را تعیین کنید.

قطعنامه

  1. این طبیعی است و اگر خطاهای HTTP 499 در مقادیر کم اتفاق بیفتد، معمولاً جای نگرانی نیست.

  2. اگر اغلب برای یک مسیر URL اتفاق می افتد، می تواند به این دلیل باشد که پروکسی خاص مرتبط با آن مسیر بسیار کند است و کاربران مایل به صبر نیستند.

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

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

علت: مهلت زمانی برنامه مشتری

این می تواند تحت چندین سناریو رخ دهد.

  1. انتظار می رود که درخواست در شرایط عملیاتی معمولی زمان معینی (مثلاً 10 ثانیه) تکمیل شود. با این حال، برنامه کلاینت با یک مقدار مهلت زمانی نادرست تنظیم شده است (مثلاً 5 ثانیه) که باعث می شود برنامه مشتری قبل از تکمیل درخواست API، به 499 برسد. در این حالت، باید تایم اوت مشتری را روی یک مقدار مناسب تنظیم کنیم.
  2. یک سرور یا فراخوان هدف بیشتر از حد انتظار طول می کشد. در این مورد، شما باید کامپوننت مناسب را تعمیر کنید و همچنین مقادیر تایم اوت را به درستی تنظیم کنید.
  3. مشتری دیگر نیازی به پاسخ نداشت و بنابراین سقط شد. این می تواند برای API های با فرکانس بالا مانند تکمیل خودکار یا نظرسنجی کوتاه اتفاق بیفتد.

تشخیص

گزارش های دسترسی API Monitoring یا NGINX

با استفاده از API Monitoring یا گزارش های دسترسی NGINX، خطا را تشخیص دهید:

  1. گزارش‌های نظارت API یا گزارش‌های دسترسی NGINX را برای تراکنش‌های HTTP 499 همانطور که در مراحل تشخیص رایج توضیح داده شده است، بررسی کنید.
  2. تعیین کنید که آیا زمان پاسخ برای همه 499 خطا سازگار است یا خیر.
  3. اگر بله، ممکن است یک برنامه کلاینت خاص یک بازه زمانی ثابت را در انتهای خود پیکربندی کرده باشد. اگر یک پروکسی API یا سرور هدف به کندی پاسخ می‌دهد، سرویس‌گیرنده قبل از اتمام زمان پراکسی، زمان پایان می‌یابد و در نتیجه مقادیر زیادی HTTP 499s برای همان مسیر URI ایجاد می‌شود. در این مورد، User Agent را از لاگ های دسترسی NGINX تعیین کنید که می تواند به شما در تعیین برنامه مشتری خاص کمک کند.
  4. همچنین ممکن است یک بار متعادل کننده در جلوی Apigee مانند Akamai، F5، AWS ELB و غیره وجود داشته باشد. اگر Apigee پشت یک متعادل کننده بار سفارشی اجرا می شود، زمان درخواست بار متعادل کننده باید بیشتر از زمان پایان Apigee API پیکربندی شود. به‌طور پیش‌فرض، روتر Apigee بعد از 57 ثانیه تمام می‌شود، بنابراین برای پیکربندی زمان‌بندی درخواست 60 ثانیه در بار متعادل کننده مناسب است.

ردیابی

با استفاده از Trace خطا را تشخیص دهید

اگر مشکل همچنان فعال است ( 499 خطا همچنان رخ می دهد)، مراحل زیر را انجام دهید:

  1. جلسه ردیابی را برای API آسیب دیده در Edge UI فعال کنید.
  2. یا صبر کنید تا خطا رخ دهد، یا اگر تماس API دارید، سپس چند تماس API برقرار کنید و خطا را تکرار کنید.
  3. زمان سپری شده را در هر مرحله بررسی کنید و مرحله ای را که بیشتر زمان در آن سپری شده است، یادداشت کنید.
  4. اگر بلافاصله پس از یکی از مراحل زیر خطا را با طولانی‌ترین زمان سپری شده مشاهده کردید، نشان می‌دهد که سرور باطن کند است یا زمان زیادی برای پردازش درخواست نیاز دارد:
    • درخواست به سرور مورد نظر ارسال شد
    • خط مشی ServiceCallout

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

قطعنامه

  1. به بهترین روش‌ها برای پیکربندی مهلت زمانی ورودی/خروجی مراجعه کنید تا متوجه شوید چه مقادیری از زمان‌بندی باید روی اجزای مختلف درگیر در جریان درخواست API از طریق Apigee Edge تنظیم شود.
  2. اطمینان حاصل کنید که مقدار مهلت زمانی مناسبی را در برنامه مشتری مطابق با بهترین شیوه ها تنظیم کرده اید.

اگر مشکل همچنان ادامه دارد، به اطلاعات تشخیصی باید جمع‌آوری شود بروید.

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

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

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

  • نام سازمان
  • نام محیط زیست
  • نام پروکسی API
  • دستور کامل curl که برای بازتولید خطای timeout استفاده می شود
  • فایل ردیابی برای درخواست‌های API که خطاهای مهلت زمانی سرویس گیرنده را مشاهده می‌کنید

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

  • پیام خطای کامل برای درخواست های ناموفق مشاهده شد
  • نام محیط زیست
  • بسته پروکسی API
  • فایل ردیابی برای درخواست‌های API که خطاهای مهلت زمانی سرویس گیرنده را مشاهده می‌کنید
  • گزارش‌های دسترسی NGINX ( /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log )
  • گزارش‌های سیستم پردازشگر پیام ( /opt/apigee/var/log/edge-message-processor/logs/system.log )