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

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

علامت

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

این پاسخ خطا نشان می دهد که کلاینت در طول اجرای یک تماس 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 ، Client > Router > Message Processor > Backend Server است که در شکل زیر نشان داده شده است:

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

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

وقفه در روتر

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

علل احتمالی

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

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

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

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

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

نظارت API

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

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

  4. روی سلول خاصی که خطاهای 504 را نشان می دهد کلیک کنید تا جزئیات بیشتر و مشاهده گزارش های مربوط به این خطاها را مطابق شکل زیر مشاهده کنید:

    مثالی که خطاهای 504 را نشان می دهد

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

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

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

    در مثال بالا،

    • درخواست به GET /test-timeout اشاره می کند.
    • زمان پاسخگویی 57.001 ثانیه است. این نشان می‌دهد که روتر قبل از اینکه پردازشگر پیام بتواند پاسخ دهد، به پایان رسیده است، زیرا مقدار بسیار نزدیک به مهلت زمانی پیش‌فرض ورودی/خروجی تنظیم‌شده روی روتر است که 57 ثانیه است.

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

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

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

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https
  6. برای خطاهای 504 اضافی، زمان پاسخ را بررسی کنید و بررسی کنید که آیا زمان پاسخ (مقدار وقفه ورودی/خروجی تنظیم شده در روتر که 57 ثانیه است) در تمام خطاهای 504 سازگار است یا خیر.

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

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

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

    در این مثال، اطلاعات زیر را مشاهده می کنیم:

    • زمان درخواست: 57.001 ثانیه. این نشان می دهد که روتر پس از 57.001 ثانیه به پایان رسیده است.

    • درخواست: GET /test-timeout
    • نام مستعار میزبان : myorg-test.apigee.net

  4. بررسی کنید که آیا زمان درخواست همان زمان I/O است که در روتر/میزبان مجازی پیکربندی شده است. اگر بله، به این معنی است که زمان روتر قبل از پاسخ ندادن پردازشگر پیام در این مدت به پایان رسیده است.

    در مثال ورودی NGINX Access Log نشان داده شده در بالا، زمان درخواست 57.001 ثانیه بسیار نزدیک به زمان پیش‌فرض I/O تنظیم شده روی روتر است. این به وضوح نشان می دهد که زمان روتر قبل از اینکه پردازشگر پیام بتواند پاسخ دهد به پایان رسیده است.

  5. با استفاده از مسیر پایه در قسمت Request ، پروکسی API را که درخواست برای آن ارسال شده است، تعیین کنید.

علت: پیکربندی وقفه نادرست در روتر

تشخیص

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

  2. بررسی کنید که آیا مقدار وقفه ورودی/خروجی پیکربندی شده روی روتر یا میزبان مجازی خاص در مقایسه با پیکربندی شده در پردازشگر پیام یا پروکسی API خاص کمتر است یا خیر.

    با انجام مراحل این بخش می توانید این کار را انجام دهید.

تأیید وقفه I/O در میزبان های مجازی

رابط کاربری لبه

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

  1. به Edge UI وارد شوید.
  2. به Admin > Virtual Hosts بروید.
  3. یک محیط خاص را انتخاب کنید که در آن با مشکل وقفه مواجه هستید.
  4. میزبان مجازی خاصی را که می‌خواهید مقدار وقفه ورودی/خروجی آن را تأیید کنید، انتخاب کنید.
  5. در قسمت Properties ، مقدار Proxy Read Timeout را در چند ثانیه مشاهده کنید.

    در مثال بالا، Proxy Read Timeout با مقدار 120 پیکربندی شده است. این بدان معنی است که زمان I/O پیکربندی شده در این میزبان مجازی 120 ثانیه است.

API های مدیریت

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

  1. Get virtual host API را اجرا کنید تا پیکربندی virtualhost مطابق شکل زیر دریافت کنید:

    کاربر عمومی ابر

    curl -v -X GET https://api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUALHOST_NAME -u USERNAME

    کاربر خصوصی Cloud

    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 نام میزبان مجازی است

  2. مقدار پیکربندی شده برای ویژگی 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 پیکربندی شده در این میزبان مجازی 120 ثانیه است.

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

  1. وارد دستگاه روتر شوید.
  2. ویژگی proxy_read_timeout را در پوشه /opt/nginx/conf.d جستجو کنید و بررسی کنید که آیا با مقدار جدید به صورت زیر تنظیم شده است: 
    grep -ri "proxy_read_timeout" /opt/nginx/conf.d

  3. مقدار تنظیم شده برای ویژگی 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 روی 57 ثانیه روی روتر برای میزبان مجازی پیش فرض پیکربندی شده است. اگر چندین هاست مجازی دارید، این اطلاعات را برای هر کدام از آنها خواهید دید. مقدار proxy_read_timeout را برای میزبان مجازی خاصی که برای برقراری تماس‌های API استفاده کرده‌اید و با خطاهای 504 شکست خورده‌اید، دریافت کنید.

تأیید مهلت زمانی I/O در پراکسی API

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

  • نقطه پایانی هدف پروکسی API
  • خط مشی ServiceCallout پروکسی API
مشاهده زمان I/O در نقطه پایانی هدف پروکسی API
  1. در Edge UI، پراکسی API خاصی را که می‌خواهید مقدار زمان I/O را در آن مشاهده کنید، انتخاب کنید.
  2. نقطه پایانی هدف خاصی را که می خواهید بررسی کنید انتخاب کنید.
  3. ویژگی io.timeout.millis را با مقدار مناسب زیر عنصر <HTTPTargetConnection> در پیکربندی TargetEndpoint ببینید.

    به عنوان مثال، زمان I/O در کد زیر روی 120 ثانیه تنظیم شده است:

    <Properties>
  <Property name="io.timeout.millis">120000</Property>
</Properties>
مهلت زمانی ورودی/خروجی را در خط مشی ServiceCallout پروکسی API مشاهده کنید
  1. در Edge UI، پراکسی API خاصی را انتخاب کنید که می‌خواهید مقدار وقفه ورودی/خروجی جدید برای خط مشی ServiceCallout را در آن مشاهده کنید.
  2. خط مشی ServiceCallout خاصی را که می خواهید بررسی کنید انتخاب کنید.

  3. عنصر <Timeout> را با مقدار مناسب در پیکربندی <ServiceCallout> ببینید.

    برای مثال، زمان I/O کد زیر 120 ثانیه خواهد بود: 

    <Timeout>120000</Timeout>

تأیید زمان I/O در پردازشگرهای پیام

  1. وارد دستگاه پردازشگر پیام شوید.

  2. با استفاده از دستور زیر، ویژگی 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
  3. در خروجی مثال بالا، توجه کنید که ویژگی HTTPTransport.io.timeout.millis با مقدار 55000 در http.properties تنظیم شده است. این نشان می دهد که وقفه I/O با موفقیت روی 55 ثانیه در پردازشگر پیام پیکربندی شده است.

هنگامی که مهلت زمانی پیکربندی شده روی روتر و پردازشگر پیام را تعیین کردید، بررسی کنید که آیا روتر/میزبان مجازی با مقدار وقفه کمتری در مقایسه با پروکسی Message Processor/API پیکربندی شده است.

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

وقفه در روتر (ثانیه) وقفه در میزبان مجازی (ثانیه) وقفه در پردازشگر پیام (ثانیه) وقفه در پروکسی API (ثانیه)
57 - 55 120

در این مثال،

  • مقدار پیش فرض 57 ثانیه روی روتر پیکربندی شده است.
  • مقدار وقفه در میزبان مجازی خاص تنظیم نشده است. این به این معنی است که از مقدار پیش فرض 57 ثانیه پیکربندی شده روی خود روتر استفاده می کند.
  • در پردازشگر پیام، مقدار پیش فرض 55 ثانیه پیکربندی شده است.
  • با این حال، در پروکسی API خاص، مقدار 120 ثانیه پیکربندی شده است.

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

قطعنامه

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

  1. به بهترین روش‌ها برای پیکربندی مهلت زمانی ورودی/خروجی مراجعه کنید تا متوجه شوید چه مقادیری از زمان‌بندی باید روی اجزای مختلف درگیر در جریان درخواست API از طریق Apigee Edge تنظیم شود.
  2. در مثال بالا، اگر مطمئن شدید که مقدار مهلت زمانی بالاتری باید تنظیم شود زیرا سرور باطن به زمان بیشتری نیاز دارد، و مقدار زمان وقفه پردازشگر پیام را به 120 ثانیه افزایش داده اید، برای مثال مقدار مهلت زمانی بالاتری را تنظیم کنید. : 123 seconds روی روتر. برای جلوگیری از تأثیرگذاری بر همه پراکسی‌های API به دلیل مقدار وقفه جدید، مقدار 123 seconds فقط روی میزبان مجازی خاصی که در پروکسی API خاص استفاده می‌شود، تنظیم کنید.
  3. دستورالعمل‌های موجود در پیکربندی وقفه ورودی/خروجی روی روترها را دنبال کنید تا زمان پایان را در میزبان مجازی تنظیم کنید.