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

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

علامت

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

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

پیام خطا

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

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

چه چیزی باعث وقفه‌های زمانی کلاینت می‌شود؟

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

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

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

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

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

زمان انقضا در روتر

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

زمان انقضا در پردازنده‌های پیام

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

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

علل احتمالی

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

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

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

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

  • نظارت بر API
  • گزارش‌های دسترسی NGINX

نظارت بر API

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

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

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

  6. در پنل سمت راست، روی «مشاهده گزارش‌ها» کلیک کنید.

    از پنجره گزارش‌های ترافیک ، جزئیات زیر را برای برخی از خطاهای 499 یادداشت کنید:

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

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

    از آنجایی که 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 دیگر مرور کنید و بررسی کنید که آیا زمان پاسخ در تمام خطاهای 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 به اطلاعات زیر توجه کنید:
    • زمان پاسخ کل
    • درخواست آدرس اینترنتی
    • عامل کاربر

    نمونه خطای ۴۹۹ از لاگ دسترسی 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 ثانیه. این نشان می‌دهد که کلاینت پس از ۱۰.۰۰۱ ثانیه به پایان زمان خود رسیده است.
    • درخواست: GET /v1/products
    • میزبان : api.acme.org
    • نماینده کاربر: okhttp/3.9.1
  5. بررسی کنید که آیا زمان کل پاسخ و عامل کاربر در تمام خطاهای 499 ثابت است یا خیر.

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

تشخیص

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

وضوح تصویر

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

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

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

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

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

این می‌تواند تحت سناریوهای مختلفی رخ دهد.

  1. انتظار می‌رود که تکمیل درخواست در شرایط عملیاتی عادی، زمان مشخصی (مثلاً ۱۰ ثانیه) طول بکشد. با این حال، برنامه‌ی کلاینت با مقدار timeout نادرستی (مثلاً ۵ ثانیه) تنظیم شده است که باعث می‌شود برنامه‌ی کلاینت قبل از تکمیل درخواست API، timeout شود و منجر به 499 شود. در این حالت، باید timeout کلاینت را روی مقدار مناسبی تنظیم کنیم.
  2. یک سرور هدف یا فراخوانی بیش از حد انتظار طول می‌کشد. در این حالت، باید مؤلفه مربوطه را اصلاح کنید و همچنین مقادیر زمان انتظار را به طور مناسب تنظیم کنید.
  3. کلاینت دیگر نیازی به پاسخ نداشت و بنابراین لغو شد. این اتفاق می‌تواند برای APIهای پرتکرار مانند تکمیل خودکار یا نظرسنجی کوتاه رخ دهد.

تشخیص

گزارش‌های نظارت بر API یا دسترسی NGINX

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

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

ردیابی

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

اگر مشکل هنوز پابرجاست (خطای 499 هنوز رخ می‌دهد)، مراحل زیر را انجام دهید:

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

    در اینجا یک نمونه از ردیابی رابط کاربری وجود دارد که زمان انقضای دروازه (Gateway Timeout) را پس از ارسال درخواست به سرور هدف نشان می‌دهد:

وضوح تصویر

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

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

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

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

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

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