این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

مهلت زمانی دروازه 504 - پایان زمان روتر

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

علامت

برنامه‌ی کلاینت در پاسخ به فراخوانی‌های API، کد وضعیت HTTP 504 را به همراه پیام Gateway Timeout دریافت می‌کند.

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

پیام خطا

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

HTTP/1.1 504 Gateway Time-out

هنگام فراخوانی چنین پروکسی با استفاده از cURL یا مرورگر وب، ممکن است خطای زیر را دریافت کنید:

<!DOCTYPE html>
<html>
<head>
<title>Error</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

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

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

تمام اجزای موجود در جریان زمان اجرای Apigee Edge شامل کلاینت‌ها، روترها، پردازنده‌های پیام و سرورهای backend با مقادیر پیش‌فرض timeout مناسب تنظیم شده‌اند تا اطمینان حاصل شود که درخواست‌های API برای تکمیل بیش از حد طول نمی‌کشند. اگر هر یک از اجزای موجود در جریان، پاسخی از جزء بالادستی در مدت زمان مشخص شده در پیکربندی timeout دریافت نکنند، آن جزء خاص timeout می‌شود و معمولاً خطای 504 Gateway Timeout را برمی‌گرداند.

این راهنما نحوه عیب‌یابی و رفع خطای 504 ناشی از اتمام مهلت زمانی روتر را شرح می‌دهد.

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

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

علل احتمالی

در Edge، دلایل معمول خطای 504 Gateway Timeout که به دلیل اتمام زمان‌بندی روتر ایجاد می‌شود، عبارتند از:

علت	توضیحات	دستورالعمل‌های عیب‌یابی قابل اجرا برای
پیکربندی نادرست timeout در روتر	این اتفاق زمانی می‌افتد که روتر با دوره زمانی I/O نادرست پیکربندی شده باشد.	کاربران فضای ابری عمومی و خصوصی Edge

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

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

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

نظارت بر API

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

به صفحه Analyze > API Monitoring > Investigate بروید.
خطاهای 5xx را فیلتر کنید و بازه زمانی را انتخاب کنید.
رسم کد وضعیت در مقابل زمان .
برای مشاهده جزئیات بیشتر و مشاهده گزارش‌های مربوط به این خطاها، مانند تصویر زیر، روی سلول خاصی که خطاهای 504 را نشان می‌دهد، کلیک کنید:
مثالی که خطاهای ۵۰۴ را نشان می‌دهد
در پنل سمت راست، روی «مشاهده گزارش‌ها» کلیک کنید.
از پنجره گزارش‌های ترافیک ، جزئیات زیر را برای برخی از خطاهای 504 یادداشت کنید:
- درخواست (Request): این متد درخواست و URI مورد استفاده برای برقراری تماس‌ها را ارائه می‌دهد.
- زمان پاسخ : این مقدار، کل زمان سپری شده برای درخواست را نشان می‌دهد.
در مثال بالا،
- درخواست به GET /test-timeout اشاره می‌کند.
- زمان پاسخ 57.001 ثانیه است. این نشان می‌دهد که روتر قبل از اینکه پردازنده پیام بتواند پاسخ دهد، زمانش تمام شده است، زیرا این مقدار بسیار نزدیک به زمان انتظار ورودی/خروجی پیش‌فرض تنظیم‌شده روی روتر، یعنی ۵۷ ثانیه، است.
همچنین می‌توانید با استفاده از API مانیتورینگ GET logs، تمام لاگ‌ها را دریافت کنید. برای مثال، با جستجوی لاگ‌ها برای org ، env ، timeRange و status ، می‌توانید تمام لاگ‌های مربوط به تراکنش‌هایی را که کلاینت در آن‌ها دچار timeout شده است، دانلود کنید.
از آنجایی که API Monitoring برای این خطاهای 504 ، پروکسی را روی - (تنظیم نشده) تنظیم می‌کند، می‌توانید از API ( Logs API ) برای دریافت پروکسی مرتبط برای میزبان مجازی و مسیر استفاده کنید.
برای مثال:
```
curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https
```
توجه: فیلدهای زیر مقدار خطای 504 را نمایش می‌دهند:
- منبع خطا
- کد خطا
- جریان خطا
- سیاست خطا
- پروکسی خطا
این فیلدها توسط پردازشگر پیام پر می‌شوند و فقط در صورتی که روتر پاسخی از پردازشگر پیام دریافت کند، با مقادیر مناسب تنظیم می‌شوند. در این حالت، روتر زودتر از پردازشگر پیام مهلتش تمام شده است زیرا به موقع پاسخ نداده است. این امر روتر را مجبور می‌کند کد وضعیت را روی 504 تنظیم کند و در نتیجه تمام فیلدهای ذکر شده در بالا به صورت - نمایش داده می‌شوند.
زمان پاسخ (Response Time) را برای خطاهای 504 دیگر بررسی کنید و ببینید که آیا زمان پاسخ (مقدار زمان انتظار ورودی/خروجی (I/O timeout) که روی روتر تنظیم شده و 57 ثانیه است) در تمام خطاهای 504 یکسان است یا خیر.

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

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

گزارش‌های دسترسی NGINX را بررسی کنید:
/opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log
جستجو کنید تا ببینید آیا در یک بازه زمانی خاص خطای 504 وجود دارد (اگر مشکل در گذشته رخ داده است) یا اینکه آیا درخواست‌هایی وجود دارد که هنوز با خطای 504 با شکست مواجه می‌شوند.
برای برخی از خطاهای 504 به اطلاعات زیر توجه کنید:
- زمان پاسخ
- درخواست آدرس اینترنتی
در این مثال، اطلاعات زیر را می‌بینیم:
- زمان درخواست: 57.001 ثانیه. این نشان می‌دهد که زمان‌بندی روتر پس از ۵۷.۰۰۱ ثانیه به پایان رسیده است.
  نکته: این فیلد request_time در لاگ‌های NGINX نشان می‌دهد. این به معنی زمان پردازش درخواست بر حسب ثانیه است؛ زمان سپری شده بین اولین بایت‌هایی که از کلاینت خوانده شده‌اند و زمان نوشتن لاگ پس از ارسال آخرین بایت‌ها به کلاینت.
- درخواست: GET /test-timeout
- نام مستعار میزبان : myorg-test.apigee.net
توجه: فیلدهای زیر - خطای 504 را نمایش می‌دهند:
- منبع خطا
- کد خطا
- جریان خطا
- سیاست خطا
- پروکسی خطا
این فیلدها توسط پردازشگر پیام پر می‌شوند و فقط در صورتی که روتر پاسخی از پردازشگر پیام دریافت کند، با مقادیر مناسب تنظیم می‌شوند. در این حالت، روتر زودتر از پردازشگر پیام مهلتش تمام شده است زیرا به موقع پاسخ نداده است. این امر روتر را مجبور می‌کند کد وضعیت را روی 504 تنظیم کند و در نتیجه تمام فیلدهای ذکر شده در بالا به صورت - نمایش داده می‌شوند.
بررسی کنید که آیا زمان درخواست ( Request Time) با زمان انتظار ورودی/خروجی (I/O timeout) پیکربندی شده روی روتر/میزبان مجازی یکسان است یا خیر. اگر بله، به این معنی است که روتر قبل از اینکه پردازنده پیام (Message Processor) در این مدت پاسخ ندهد، زمان انتظارش به پایان رسیده است.
در مثال ورودی NGINX Access Log که در بالا نشان داده شده است، زمان درخواست 57.001 ثانیه بسیار نزدیک به زمان انتظار ورودی/خروجی پیش‌فرض تنظیم‌شده روی روتر است. این به وضوح نشان می‌دهد که روتر قبل از اینکه پردازنده پیام بتواند پاسخ دهد، زمانش تمام شده است.
با استفاده از مسیر پایه در فیلد درخواست، پروکسی API که درخواست برای آن ارسال شده است را تعیین کنید.

علت: پیکربندی نادرست timeout در روتر

تشخیص

تعیین کنید که آیا خطاهای 504 به دلیل اتمام مهلت روتر قبل از پاسخ پردازنده پیام ایجاد شده‌اند یا خیر. می‌توانید این کار را با بررسی اینکه آیا زمان پاسخ در API Monitoring/ Request Time در روتر (هر دو فیلد اطلاعات یکسانی را نشان می‌دهند، اما با نام‌های مختلف فراخوانی می‌شوند) با زمان انتظار ورودی/خروجی پیکربندی شده در روتر/میزبان مجازی یکسان است یا خیر، و فیلدهای Fault Source ، Fault Proxy و Fault Code روی آن تنظیم شده‌اند - با استفاده از گزارش‌های API Monitoring یا NGINX Access همانطور که در مراحل تشخیص مشترک توضیح داده شده است.
بررسی کنید که آیا مقدار زمان انتظار ورودی/خروجی پیکربندی‌شده روی روتر یا میزبان مجازی خاص در مقایسه با مقدار پیکربندی‌شده روی پردازنده پیام یا پروکسی API خاص، کمتر است یا خیر.
شما می‌توانید این کار را با دنبال کردن مراحلی که در این بخش آمده است، انجام دهید.

تأیید زمان انقضای ورودی/خروجی روی میزبان‌های مجازی

رابط کاربری اج

برای تأیید زمان انقضای میزبان مجازی با استفاده از رابط کاربری Edge، موارد زیر را انجام دهید:

وارد رابط کاربری Edge شوید.
به بخش مدیریت > میزبان‌های مجازی بروید.
یک محیط خاص را انتخاب کنید که در آن با مشکل تایم اوت مواجه هستید.
میزبان مجازی خاصی را که می‌خواهید مقدار زمان‌بندی ورودی/خروجی آن را تأیید کنید، انتخاب کنید.
در قسمت Properties ، مقدار زمان انتظار خواندن پروکسی را بر حسب ثانیه مشاهده کنید.
در مثال بالا، زمان انتظار خواندن پروکسی با مقدار 120 پیکربندی شده است. این بدان معناست که زمان انتظار ورودی/خروجی پیکربندی شده روی این میزبان مجازی ۱۲۰ ثانیه است.
نکته: اگر Proxy Read Timeout هیچ مقداری نداشته باشد، به این معنی است که مقدار پیش‌فرض ۵۷ ثانیه که در روتر پیکربندی شده است را خواهد گرفت (مگر اینکه زمان‌بندی I/O در نمونه‌های روتر لغو شده باشد).

API های مدیریتی

همچنین می‌توانید با استفاده از APIهای مدیریتی زیر، زمان انتظار خواندن پروکسی را تأیید کنید:

برای دریافت پیکربندی virtualhost ، دستور Get virtualhost API را مطابق شکل زیر اجرا کنید:
کاربر ابر عمومی
```
curl -v -X GET https://api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUALHOST_NAME -u USERNAME
```
کاربر ابر خصوصی
```
curl -v -X GET http://MANAGEMENT_SERVER_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments/v/virtualhosts/VIRTUALHOST_NAME -u USERNAME
```
کجا:
ORGANIZATION_NAME نام سازمان است.
ENVIRONMENT_NAME نام محیط است
VIRTUALHOST_NAME نام میزبان مجازی است.

مقدار پیکربندی شده برای ویژگی proxy_read_timeout را بررسی کنید.

نمونه تعریف میزبان مجازی

{
  "hostAliases": [
    "api.myCompany,com",
  ],
  "interfaces": [],
  "listenOptions": [],
  "name": "secure",
  "port": "443",
  "retryOptions": [],
  "properties": {
    "property": [
      {
        "name": "proxy_read_timeout",
        "value": "120"
      }
    ]
  },
  "sSLInfo": {
    "ciphers": [],
    "clientAuthEnabled": "false",
    "enabled": "true",
    "ignoreValidationErrors": false,
    "keyAlias": "myCompanyKeyAlias",
    "keyStore": "ref://myCompanyKeystoreref",
    "protocols": []
  },
  "useBuiltInFreeTrialCert": false
}

در مثال بالا، proxy_read_timeout با مقدار 120 پیکربندی شده است. این بدان معناست که زمان انتظار I/O پیکربندی شده در این میزبان مجازی ۱۲۰ ثانیه است.

نکته: اگر ویژگی proxy_read_timeout در خروجی رابط برنامه‌نویسی کاربردی مدیریت وجود نداشته باشد، به این معنی است که مقدار پیش‌فرض ۵۷ ثانیه را خواهد گرفت (مگر اینکه زمان انتظار ورودی/خروجی در نمونه‌های روتر لغو شده باشد).

تأیید زمان انقضای ورودی/خروجی در فایل router.properties

به یک دستگاه روتر وارد شوید.
در دایرکتوری /opt/nginx/conf.d به دنبال ویژگی proxy_read_timeout بگردید و بررسی کنید که آیا مقدار جدید آن به صورت زیر تنظیم شده است یا خیر:
```
grep -ri "proxy_read_timeout" /opt/nginx/conf.d
```
مقدار تعیین‌شده برای ویژگی proxy_read_timeout را در فایل پیکربندی میزبان مجازی خاص بررسی کنید.
نمونه نتیجه از دستور grep
```
/opt/nginx/conf.d/0-default.conf:proxy_read_timeout 57;
/opt/nginx/conf.d/0-edge-health.conf:proxy_read_timeout 1s;
```
در خروجی مثال بالا، توجه کنید که ویژگی proxy_read_timeout با مقدار جدید 57 در 0-default.conf که فایل پیکربندی برای میزبان مجازی پیش‌فرض است، تنظیم شده است. این نشان می‌دهد که زمان انتظار ورودی/خروجی (I/O timeout) در روتر برای میزبان مجازی پیش‌فرض روی ۵۷ ثانیه پیکربندی شده است. اگر چندین میزبان مجازی دارید، این اطلاعات را برای هر یک از آنها مشاهده خواهید کرد. مقدار proxy_read_timeout را برای میزبان مجازی خاصی که برای ایجاد فراخوانی‌های API که با خطاهای 504 ناموفق بوده‌اند، استفاده کرده‌اید، دریافت کنید.

تأیید زمان انقضای ورودی/خروجی در پروکسی API

شما می‌توانید زمان انتظار I/O را در زیر مشاهده کنید:

نقطه پایانی هدف پروکسی API
سیاست ServiceCallout پروکسی API

مشاهده زمان انقضای ورودی/خروجی در نقطه پایانی هدف پروکسی API

در رابط کاربری Edge، پروکسی API خاصی را که می‌خواهید مقدار زمان انتظار ورودی/خروجی را در آن مشاهده کنید، انتخاب کنید.
نقطه پایانی هدف خاصی را که می‌خواهید بررسی کنید، انتخاب کنید.
به ویژگی io.timeout.millis با مقدار مناسب در عنصر <HTTPTargetConnection> در پیکربندی TargetEndpoint مراجعه کنید.
برای مثال، زمان انتظار ورودی/خروجی در کد زیر روی ۱۲۰ ثانیه تنظیم شده است:
```
<Properties>
  <Property name="io.timeout.millis">120000</Property>
</Properties>
```

مشاهده‌ی زمان انقضای ورودی/خروجی در سیاست ServiceCallout مربوط به پروکسی API

در رابط کاربری Edge، پروکسی API خاصی را که می‌خواهید مقدار جدید زمان‌بندی ورودی/خروجی برای سیاست ServiceCallout را در آن مشاهده کنید، انتخاب کنید.
سیاست ServiceCallout خاصی را که می‌خواهید بررسی کنید، انتخاب کنید.
عنصر <Timeout> را با مقدار مناسب در پیکربندی <ServiceCallout> مشاهده کنید.
برای مثال، زمان انتظار ورودی/خروجی کد زیر ۱۲۰ ثانیه خواهد بود:
```
<Timeout>120000</Timeout>
```

تأیید زمان انقضای ورودی/خروجی در پردازنده‌های پیام

به دستگاه پردازشگر پیام وارد شوید.
با استفاده از دستور زیر، ویژگی HTTPTransport.io.timeout.millis را در دایرکتوری /opt/apigee/edge-message-processor/conf جستجو کنید:
```
grep -ri "HTTPTransport.io.timeout.millis" /opt/apigee/edge-message-processor/conf
```
خروجی نمونه
```
/opt/apigee/edge-message-processor/conf/http.properties:HTTPTransport.io.timeout.millis=55000
```
در خروجی مثال بالا، توجه کنید که ویژگی HTTPTransport.io.timeout.millis با مقدار 55000 در http.properties تنظیم شده است. این نشان می‌دهد که زمان انتظار ورودی/خروجی با موفقیت روی ۵۵ ثانیه در پردازنده پیام پیکربندی شده است.

پس از تعیین زمان انقضای پیکربندی‌شده روی روتر و پردازنده پیام، بررسی کنید که آیا روتر/میزبان مجازی با مقدار زمان انقضای پایین‌تری در مقایسه با مقدار آن در پروکسی پردازنده پیام/API پیکربندی شده است یا خیر.

مقادیر تنظیم شده روی تمام لایه‌ها را همانطور که در جدول زیر نشان داده شده است، یادداشت کنید:

زمان انتظار روی روتر (ثانیه)	زمان انقضا روی میزبان مجازی (ثانیه)	زمان انتظار در پردازنده پیام (ثانیه)	زمان انقضای پروکسی API (ثانیه)
۵۷	-	۵۵	۱۲۰

در این مثال،

مقدار پیش‌فرض ۵۷ ثانیه روی روتر پیکربندی شده است.
مقدار timeout روی میزبان مجازی خاص تنظیم نشده است. این بدان معناست که از مقدار پیش‌فرض ۵۷ ثانیه که روی خود روتر پیکربندی شده است، استفاده خواهد کرد.
در پردازشگر پیام، مقدار پیش‌فرض ۵۵ ثانیه پیکربندی شده است.
با این حال، در API Proxy خاص، مقدار ۱۲۰ ثانیه پیکربندی شده است.

توجه داشته باشید که مقدار timeout بالاتر فقط روی پروکسی API پیکربندی شده است، اما روتر همچنان با ۵۷ ثانیه پیکربندی شده است. از این رو، روتر در ۵۷ ثانیه مهلت خود را تمام می‌کند در حالی که پردازنده پیام/بک‌اند هنوز در حال پردازش درخواست شما است. این باعث می‌شود که روتر با خطای 504 Gateway Timeout به برنامه کلاینت پاسخ دهد.

وضوح تصویر

برای حل این مشکل، مراحل زیر را برای پیکربندی زمان‌بندی صحیح I/O در روتر و پردازنده پیام انجام دهید.

برای درک اینکه چه مقادیری از timeout باید روی اجزای مختلف درگیر در جریان درخواست API از طریق Apigee Edge تنظیم شوند، به بهترین شیوه‌ها برای پیکربندی I/O timeout مراجعه کنید.
در مثال بالا، اگر متوجه شدید که به دلیل نیاز سرور backend به زمان طولانی‌تر، باید مقدار timeout بالاتری تنظیم شود و مقدار timeout پردازنده پیام را به ۱۲۰ ثانیه افزایش داده‌اید، مقدار timeout بالاتری را تنظیم کنید. برای مثال: 123 seconds روی روتر. برای جلوگیری از تأثیر بر تمام API Proxies به دلیل مقدار timeout جدید، مقدار 123 seconds را فقط روی میزبان مجازی خاصی که در API Proxy خاص استفاده می‌شود، تنظیم کنید.
برای تنظیم زمان انقضا روی میزبان مجازی، دستورالعمل‌های موجود در بخش «پیکربندی زمان انقضای ورودی/خروجی روی روترها» را دنبال کنید.