درحال مشاهده اسناد Apigee Edge هستید.
به
اسناد Apigee X بروید. اطلاعات
نشانه
برنامه کارخواه برای درخواست‌های API خطای مهلت زمانی دریافت می‌کند یا درخواست به‌طور ناگهانی درحالی‌که درخواست API هنوز در Apigee درحال اجرا است، خاتمه می‌یابد.
کد وضعیت 499 را برای چنین درخواست‌های API در «پایش API» و
گزارش‌های «دسترسی NGINX» مشاهده خواهید کرد. گاهی اوقات، کدهای وضعیت متفاوتی را در «تحلیل‌های API» مشاهده خواهید کرد زیرا
کد وضعیت برگشتی توسط «پردازشگر پیام» را نشان می‌دهد.
پیام خطا
برنامه‌های کارخواه ممکن است خطاهایی ازاین‌دست ببینند:
curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received
چه چیزی باعث اتمام زمان کارخواه می‌شود؟
مسیر معمول برای درخواست «میانای برنامه‌سازی کاربردی» در پلاتفرم Edge به‌صورت کارخواه > مسیریاب > پردازشگر پیام > سرور زیرینه است، همان‌طور که در شکل زیر نشان داده شده است:
«مسیرها» و «پردازشگرهای پیام» در پلاتفرم Apigee Edge با مقادیر پیش‌فرض مناسب برای زمان اتمام تنظیم شده‌اند تا اطمینان حاصل شود که درخواست‌های API برای تکمیل شدن خیلی طول نمی‌کشند.
مهلت کارخواه تمام شد
برنامه‌های کارخواه را می‌توان با مقدار درنگ مناسب براساس نیازهایتان پیکربندی کرد.
کاربرانی مثل مرورگرهای وب و برنامه‌های تلفن همراه زمان‌های اتمام تعریف‌شده توسط سیستم‌عامل دارند.
مهلت در رهیاب
مهلت زمانی پیش‌فرض پیکربندی‌شده در «مسیریاب‌ها» ۵۷ ثانیه است. این حداکثر زمانی است که یک کارگزار API می‌تواند از زمان دریافت درخواست API در Edge تا زمان ارسال پاسخ، ازجمله پاسخ زیرینه و همه خط‌مشی‌هایی که اجرا می‌شوند، اجرا شود. مهلت زمانی پیش‌فرض را می‌توان در «رهیاب‌ها» و «میزبان‌های مجازی» همان‌طور که در پیکربندی مهلت زمانی ورودی/خروجی در «رهیاب‌ها» توضیح داده شده است ملغی کرد.
مهلت پردازشگرهای پیام تمام شد
مهلت زمانی پیش‌فرض پیکربندی‌شده در «پردازشگرهای پیام» ۵۵ ثانیه است. این حداکثر مقدار زمانی است که سرور زیرینه می‌تواند برای پردازش درخواست و پاسخ دادن به «پردازنده پیام»صرف کند. مهلت زمانی پیش‌فرض را می‌توان در «پردازشگرهای پیام» یا در «پراکسی API» لغو کرد، همان‌طور که در پیکربندی مهلت زمانی ورودی/خروجی در «پردازشگرهای پیام» توضیح داده شده است.
اگر مشتری اتصال با «مسیریاب» را قبل‌از پایان مهلت میانای برنامه‌سازی کاربردی ببندد،
خطای پایان مهلت را برای درخواست میانای برنامه‌سازی کاربردی خاص مشاهده خواهید کرد. کد وضعیت 499 Client
Closed Connection برای چنین درخواست‌هایی در «مسیریاب» ثبت می‌شود که می‌توان آن را در گزارش‌های «پایش API» و «دسترسی NGINX» مشاهده کرد.
علل احتمالی
در Edge، دلایل معمول خطای 499 Client Closed Connection عبارت‌اند از:
| علت | شرح | دستورالعمل‌های عیب‌یابی برای موارد زیر قابل‌اجرا است |
|---|---|---|
| کارخواه اتصال را به‌طور ناگهانی بست | این اتفاق زمانی روی می‌دهد که کارخواه اتصال را به‌دلیل لغو درخواست توسط کاربر نهایی قبل‌از تکمیل آن ببندد. | کاربران «ابر عمومی» و «ابر خصوصی» |
| مهلت برنامه کارخواه | این اتفاق زمانی رخ می‌دهد که برنامه کارخواه قبل‌از اینکه «پراکسی میانای برنامه‌سازی کاربردی» فرصت داشته باشد پاسخ را پردازش و ارسال کند، زمانش به‌پایان می‌رسد. معمولاً این اتفاق زمانی رخ می‌دهد که زمان اتمام کار مشتری کمتر از زمان اتمام کار مسیریاب باشد. | کاربران «ابر عمومی» و «ابر خصوصی» |
مراحل متداول تشخیص خرابی
برای تشخیص این خطا، از یکی از ابزارها/تکنیک‌های زیر استفاده کنید:
- پایش میانای برنامه‌سازی کاربردی
- گزارش‌های دسترسی NGINX
پایش میانای برنامه‌سازی کاربردی
برای تشخیص خطا بااستفاده از «پایش API»:
- به صفحه تجزیه‌وتحلیل > پایش API > بررسی پیمایش کنید.
- برای
4xxخطا فیلتر کنید و بازه زمانی را انتخاب کنید. - کد وضعیت را دربرابر زمان طرح کنید.
- سلولی را که
499خطا دارد، همان‌طور که در زیر نشان داده شده است انتخاب کنید:
- اطلاعات مربوط به خطای
499را در قاب سمت چپ همان‌طور که در زیر نشان داده شده است خواهید دید:
- در قاب سمت چپ، روی مشاهده گزارش‌ها کلیک کنید.
از پنجره گزارش‌های ترافیک، جزئیات زیر را برای برخی‌از
499خطاها یادداشت کنید:- درخواست:این بخش روش درخواست و نشانی وب استفاده‌شده برای برقراری تماس‌ها را ارائه می‌دهد
- پاسخ زمان:این بخش کل زمان سپری‌شده برای درخواست را ارائه می‌دهد.
همچنین می‌توانید بااستفاده از API «نظارت بر API» دریافت گزارش‌های API همه گزارش‌ها را دریافت کنید. برای مثال، با پُرسمان کردن گزارش‌های
org،env،timeRange، وstatus، می‌توانید همه گزارش‌های تراکنش‌هایی را که مشتری برای آن‌ها زمان‌بندی کرده است بارگیری کنید.ازآنجایی‌که «پایش API» پراکسی را برای خطاهای 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"
- زمان پاسخ را برای خطاهای
499اضافی بررسی کنید و ببینید آیا زمان پاسخ در همه خطاهای499یکسان است (مثلاً ۳۰ ثانیه).
گزارش‌های دسترسی NGINX
برای تشخیص خطا بااستفاده از گزارش‌های دسترسی NGINX:
- اگر کاربر Private Cloud هستید، می‌توانید از گزارش‌های دسترسی NGINX برای تعیین
اطلاعات کلیدی درباره خطاهای HTTP
499استفاده کنید. - گزارش‌های دسترسی NGINX را بررسی کنید:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log - جستجو کنید تا ببینید آیا در طول مدت مشخصی
499خطا وجود دارد یا نه (اگر مشکل در گذشته رخ داده است) یا اینکه آیا هنوز درخواست‌هایی با499ناموفق هستند یا نه. - اطلاعات زیر را برای برخی‌از خطاهای
499یادداشت کنید:- کل زمان پاسخ‌دهی
- URI درخواست
- نماینده کاربر
نمونه خطای ۴۹۹ از گزارش دسترسی 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
- بررسی کنید که آیا زمان پاسخ کل و عامل کاربر در همه خطاهای
499یکسان است یا نه.
دلیل: کارخواه اتصال را ناگهان بست
تشخیص
- وقتی یک API از برنامه تک‌صفحه‌ای که در مرورگر یا برنامه تلفن همراه اجرا می‌شود فراخوانی می‌شود، اگر کاربر نهایی به‌طور ناگهانی مرورگر را ببندد، به صفحه وب دیگری در همان برگه پیمایش کند، یا با کلیک کردن یا تک‌ضرب زدن روی توقف بارگیری، بارگیری صفحه را متوقف کند، مرورگر درخواست را لغو می‌کند.
- اگر این اتفاق بیفتد، تراکنش‌های دارای وضعیت HTTP
499معمولاً در زمان پردازش درخواست (زمان پاسخ) برای هریک از درخواست‌ها متفاوت خواهند بود. -
با مقایسه زمان پاسخ و بررسی اینکه آیا برای هریک از خطاهای
499بااستفاده از «پایش میانای برنامه‌سازی کاربردی» یا گزارش‌های NGINX Access متفاوت است یا نه، می‌توانید تشخیص دهید که آیا این علت مشکل است یا نه، همان‌طور که در مراحل تشخیص رایج توضیح داده شده است.
وضوح
- این امر طبیعی است و معمولاً اگر خطاهای HTTP
499در مقادیر کم رخ دهند، جای نگرانی نیست. -
اگر این اتفاق اغلب برای مسیر نشانی وب یکسان رخ می‌دهد، ممکن است به این دلیل باشد که پراکسی خاص مرتبط با آن مسیر بسیار کند است و کاربران تمایلی به انتظار ندارند.
وقتی متوجه شدید کدام پراکسی ممکن است تحت تأثیر قرار گیرد، از داشبورد تجزیه‌وتحلیل تأخیر برای بررسی بیشتر علت تأخیر پراکسی استفاده کنید.
- در این مورد، بااستفاده از مراحل مراحل تشخیص خرابی رایج، پراکسی تحت‌تأثیر قرارگرفته را تعیین کنید.
- از داشبورد تجزیه‌وتحلیل تأخیر برای بررسی بیشتر علت تأخیر پراکسی و رفع مشکل استفاده کنید.
- اگر متوجه شدید که تأخیر برای «پراکسی» خاصی طبیعی است، باید به کاربران خود اطلاع دهید که این «پراکسی» برای پاسخ دادن به زمان نیاز دارد.
دلیل: زمان انتظار برنامه کارخواه به‌پایان رسید
این اتفاق می‌تواند در شرایط مختلفی رخ دهد.
-
انتظار می‌رود که تکمیل درخواست تحت شرایط عملیاتی عادی زمان مشخصی (مثلاً ۱۰ ثانیه) طول بکشد. بااین‌حال، برنامه کارخواه با مقدار
مهلت زمانی نادرستی (مثلاً ۵ ثانیه) تنظیم شده است که باعث می‌شود برنامه کارخواه قبل‌از
تکمیل درخواست «میانای برنامه‌سازی کاربردی» مهلت زمانی‌اش به‌پایان برسد و منجر به
499شود. در این مورد، باید درنگ کارخواه را روی مقدار مناسبی تنظیم کنیم. - کاربرگ هدف یا بازارسال بیش‌از حد انتظار طول کشیده است. در این مورد، باید مؤلفه مناسب را اصلاح کنید و مقادیر مهلت زمانی را نیز به‌طور مناسب تنظیم کنید.
- «کارخواه» دیگر به پاسخ نیاز نداشت و بنابراین آن را لغو کرد. این اتفاق می‌تواند برای میاناهای برنامه‌سازی کاربردی با فرکانس بالا مثل تکمیل خودکار یا نظرسنجی کوتاه رخ دهد.
تشخیص
«پایش API» یا گزارش‌های دسترسی NGINX
بااستفاده از «پایش میانای برنامه‌سازی کاربردی» یا گزارش‌های دسترسی NGINX، خطا را تشخیص دهید:
- گزارش‌های «پایش میانای برنامه‌سازی کاربردی» یا گزارش‌های دسترسی NGINX را برای تراکنش‌های HTTP
499همان‌طور که در مراحل تشخیص خرابی رایج توضیح داده شده است بررسی کنید. - تعیین کنید که آیا زمان پاسخ برای همه خطاهای
499یکسان است یا نه. - اگر بله، ممکن است برنامه کارخواه خاصی در طرف خود زمان انتظار ثابتی پیکربندی کرده باشد. اگر کارگزار هدف یا پراکسی API به‌کندی پاسخ دهد، مشتری قبل‌از اینکه پراکسی زمان‌بندی شود، زمان‌بندی می‌شود و درنتیجه مقادیر زیادی HTTP
499sبرای مسیر یکسان URI ایجاد می‌شود. در این مورد، عامل کاربر را از گزارش‌های دسترسی NGINX تعیین کنید که می‌تواند به شما در تعیین برنامه مشتری خاص کمک کند. - همچنین ممکن است ترازکننده‌ای بار در مقابل Apigee وجود داشته باشد، مانند Akamai، F5، AWS ELB، و غیره. اگر Apigee پشت ترازکننده بار سفارشی اجرا می‌شود، زمان اتمام درخواست ترازکننده بار باید به‌گونه‌ای پیکربندی شود که بیشتر از زمان اتمام Apigee API باشد. به‌طور پیش‌فرض، Apigee Router پس‌از ۵۷ ثانیه منقضی می‌شود، بنابراین مناسب است که مهلت زمانی درخواست را در ترازکننده بار روی ۶۰ ثانیه پیکربندی کنید.
ردیابی
عیب‌یابی خطا بااستفاده از «ردیابی»
اگر مشکل همچنان فعال است (499 خطا همچنان رخ می‌دهد)، مراحل زیر را انجام دهید:
- جلسه ردیابی را برای میانای برنامه‌سازی کاربردی تحت‌تأثیر قرارگرفته در «واسط کاربر Edge» فعال کنید.
- یا منتظر بمانید تا خطا رخ دهد، یا اگر فراخوانی API دارید، چند فراخوانی API انجام دهید و خطا را بازتولید کنید.
- زمان سپری‌شده در هر مرحله را بررسی کنید و مرحله‌ای را که بیشترین زمان در آن صرف می‌شود یادداشت کنید.
- اگر خطای دارای طولانی‌ترین زمان سپری‌شده را بلافاصله پس‌از یکی از مراحل زیر مشاهده کردید، این خطا نشان می‌دهد که سرور پشتیبان کند است یا پردازش درخواست زمان زیادی طول می‌کشد:
- درخواست به سرور هدف ارسال شد
- خط‌مشی ServiceCallout
در اینجا نمونه‌ای از ردیابی واسط کاربر نشان داده شده است که مهلت زمانی درگاه را پس‌از درخواست نشان می‌دهد به سرور هدف ارسال شده است:
وضوح
- برای اینکه بدانید مقادیر مهلت زمانی در مؤلفه‌های مختلف درگیر در جریان درخواست API ازطریق Apigee Edge باید روی چه مقداری تنظیم شود، به روال‌های مطلوب برای پیکربندی مهلت زمانی ورودی/خروجی مراجعه کنید.
- مطمئن شوید که مقدار درنگ مناسبی را در برنامه کارخواه براساس روال‌های مطلوب تنظیم کرده‌اید.
اگر مشکل همچنان ادامه داشت، به باید اطلاعات تشخیصی را جمع‌آوری کنید بروید .
باید اطلاعات تشخیص خرابی را جمع‌آوری کند
اگر مشکل برطرف نشد، اطلاعات تشخیص سلامت زیر را جمع‌آوری کنید و سپس با پشتیبانی Apigee Edge تماس بگیرید.
اگر کاربر ابر عمومی هستید، اطلاعات زیر را ارائه دهید:
- نام سازمان
- نام محیط
- نام پراکسی میانای برنامه‌سازی کاربردی
- فرمان
curlتکمیل‌شده برای بازتولید خطای مهلت زمانی - فایل ردیابی برای درخواست‌های «میانای برنامه‌سازی کاربردی» که خطاهای مهلت زمانی کارخواه را برای آن‌ها می‌بینید
اگر کاربر ابر خصوصی هستید، اطلاعات زیر را ارائه دهید:
- پیام خطای کامل مشاهده‌شده برای درخواست‌های ناموفق
- نام محیط
- دسته «پراکسی میانای برنامه‌سازی کاربردی»
- فایل ردیابی برای درخواست‌های «میانای برنامه‌سازی کاربردی» که خطاهای مهلت زمانی کارخواه را برای آن‌ها می‌بینید
- گزارش‌های دسترسی NGINX (
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log) - گزارش‌های سیستم «پردازشگر پیام» (
/opt/apigee/var/log/edge-message-processor/logs/system.log)