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

سرویس 503 در دسترس نیست - NoActiveTargets - HealthCheckFailures

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

ویدیوها

برای اطلاعات بیشتر در مورد خطاهای 503 به ویدیوهای زیر مراجعه کنید:

ویدئو	توضیحات
عیب یابی و رفع مشکل 503 Service Unavailable - NoActiveTargets	با موارد زیر آشنا شوید: اهمیت سرورهای هدف و مانیتورهای سلامت عیب یابی و حل یک سرویس 503 در زمان واقعی در دسترس نیست - خطای NoActiveTargets ناشی از شکست بررسی سلامت

علامت

برنامه سرویس گیرنده کد وضعیت پاسخ HTTP 503 را با پیام Service Unavailable و کد خطا NoActiveTargets برای درخواست های پراکسی API دریافت می کند.

پیغام خطا

پاسخ خطای زیر را خواهید دید:

HTTP/1.1 503 Service Unavailable

پیغام خطای زیر را در پاسخ HTTP خواهید دید:

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.NoActiveTargets"
       }
    }
}

علل احتمالی

پاسخ HTTP 503 Service Unavailable با کد خطا NoActiveTargets معمولاً زمانی مشاهده می شود که از یک یا چند سرور هدف در پیکربندی نقطه پایانی هدف در پروکسی API خود استفاده می کنید.

این کتاب راهنما 503 Service Unavailable را با کد خطا NoActiveTargets که به دلیل خرابی بررسی سلامت ایجاد شده است، پوشش می دهد. لطفاً برای آشنایی با سایر دلایل این خطا به این کتاب بازی مراجعه کنید.

شکست های چک سلامت

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

هنگامی که یک سرور هدف در بررسی سلامت ناموفق باشد، Edge تعداد خرابی سرور را افزایش می دهد. اگر تعداد خرابی‌های بررسی سلامت آن سرور به آستانه از پیش تعریف‌شده ( <MaxFailures> ) برسد، پردازشگر پیام پیام هشدار را همانطور که در زیر نشان داده شده است را در فایل گزارش خود ثبت می‌کند:

Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}

پیام هشدار اطلاعات زیر را ارائه می دهد. این به شما کمک می کند بفهمید کدام سرور هدف به تعداد MaxFailure رسیده است:

نام سرور هدف
نام سازمان و محیط زیست
نام پروکسی API
نام نقطه پایانی هدف

پس از آن، Edge ارسال هرگونه درخواست بیشتر به آن سرور خاص را متوقف می کند. هنگامی که تمام سرورهای هدف پیکربندی شده در پیکربندی LoadBalancer به تعداد MaxFailure رسیدند، درخواست‌های API بعدی با 503 Service Unavailable با کد خطا NoActiveTargets پاسخ داده می‌شوند.

استفاده از Health Monitor به Apigee Edge کمک می‌کند تا به‌طور خودکار یک سرور هدف را پس از سالم شدن، بدون نیاز به بازگردانی API Proxy به چرخش بازگرداند.

در اینجا دلایل احتمالی عدم موفقیت در بررسی سلامت وجود دارد:

علت	توضیحات	چه کسی می تواند مراحل عیب یابی را انجام دهد
خطای زمان اتصال	پردازشگر پیام قادر به اتصال به سرور مورد نظر در بازه زمانی مشخص شده در پیکربندی LoadBalancer نیست.	کاربران Edge Private Cloud
درخواست ایمن در بندر غیر ایمن	اگر سرور مورد نظر به عنوان یک سرور امن تعریف شده باشد، اما به اشتباه با یک پورت غیر ایمن پیکربندی شده باشد. اگر سرور مورد نظر به عنوان یک سرور امن تعریف شده باشد، اما مانیتور سلامت برای انجام بررسی های سلامت در یک پورت غیر ایمن پیکربندی شده است.	کاربران Edge Private Cloud
درخواست غیر ایمن در پورت امن	اگر سرور مورد نظر به عنوان یک سرور غیر ایمن تعریف شده باشد، اما به اشتباه با یک پورت امن پیکربندی شده باشد. اگر سرور مورد نظر به عنوان یک سرور غیر ایمن تعریف شده باشد، اما مانیتور سلامت برای انجام بررسی های سلامت در یک پورت امن پیکربندی شده است.	کاربران Edge Private Cloud
Health Check API با یک خطا پاسخ می دهد	اگر API بررسی سلامت با یک خطا یا کد پاسخ پاسخ دهد، هر چیزی غیر از مشخص شده در عنصر SuccessResponse مانیتور سلامت.	کاربران Edge Private Cloud

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

شناسه پیام درخواست ناموفق را تعیین کنید

ابزار ردیابی

برای تعیین شناسه پیام درخواست ناموفق با استفاده از ابزار Trace:

جلسه ردیابی را فعال کنید، تماس API را برقرار کنید و مشکل را بازتولید کنید - 503 Service Unavailable با کد خطا NoActiveTargets .
یکی از درخواست های ناموفق را انتخاب کنید.
به مرحله AX بروید و شناسه پیام ( X-Apigee.Message-ID ) درخواست را با اسکرول کردن در قسمت Phase Details همانطور که در شکل زیر نشان داده شده است تعیین کنید.

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

برای تعیین شناسه پیام درخواست ناموفق با استفاده از گزارش های دسترسی NGINX:

همچنین می توانید برای تعیین شناسه پیام خطاهای 503 به گزارش های دسترسی NGINX مراجعه کنید. این به ویژه در صورتی مفید است که مشکل در گذشته رخ داده باشد یا اگر مشکل متناوب باشد و شما نتوانید ردیابی را در رابط کاربری ثبت کنید. برای تعیین این اطلاعات از لاگ های دسترسی NGINX از مراحل زیر استفاده کنید:

گزارش های دسترسی NGINX را بررسی کنید: ( /opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log )
جستجو کنید که آیا خطاهای 503 برای پروکسی API خاص در طول یک مدت زمان مشخص وجود دارد (اگر مشکل در گذشته اتفاق افتاده است) یا اگر هنوز درخواست هایی وجود دارد که با 503 ناموفق هستند.
اگر هر گونه خطای 503 با X-Apigee-fault-code messaging.adaptors.http.flow.NoActiveTargets وجود دارد، شناسه پیام یک یا چند درخواست از این قبیل را همانطور که در مثال زیر نشان داده شده است، یادداشت کنید:
نمونه ورودی خطای 503 را نشان می دهد

پیام های خطای رایج

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

پیام های خطای رایج مشاهده شده در گزارش های پردازشگر پیام ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) برای سرویس 503 Unavailable با کد خطا NoActiveTargets به شرح زیر است:

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 INFO  ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Failed to send request to target servers : [demo-target] for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : No Active Target server Found for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Unexpected error while sending request
com.apigee.errors.http.server.ServiceUnavailableException: The Service is temporarily unavailable
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.sendRequest(LBTargetRequestSender.java:299)
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.access$400(LBTargetRequestSender.java:57)
	…<snipped>

این پیغام های خطا نشان می دهد که درخواست به دلیل خرابی به سرور باطن ارسال نمی شود. در نتیجه، پردازشگر پیام 503 Service Unavailable را با کد خطا NoActiveTargets به عنوان پاسخ خود به مشتری ارسال می کند.

علت: پایان زمان اتصال

تشخیص

شناسه پیام درخواست ناموفق را تعیین کنید .
شناسه پیام را در گزارش پردازشگر پیام جستجو کنید ( /opt/apigee/var/log/edge-message-processor/logs/system.log ).
پیام های خطای رایج مربوط به شناسه پیام را خواهید دید. با این حال، برای دریافت علت واقعی شکست‌های بررسی سلامت، بالای این پیام‌های خطای رایج بروید و خطاهای HEALTH MONITOR را بررسی کنید.
به عنوان مثال، پیام خطای زیر HEALTH MONITOR نشان می‌دهد که هنگام درخواست API بررسی سلامت، پردازشگر پیام با خطای پایان زمان اتصال ناموفق بود:
```
Apigee-Timer-6 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://<BackendServer-Hostname>:443/status
java.net.ConnectException: Connection timed out (Connection timed out)
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
…<snipped>
        
```
اگر این خطا برای MaxFailure چندین بار که در Health Monitor پیکربندی شده تکرار شود، یک پیام هشدار مانند زیر مشاهده خواهید کرد:
```
Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
        
```
اطلاعات درج شده در پیام هشدار را با دقت بخوانید. مطمئن شوید که تعداد MaxFailure برای سرور مورد نظر مورد استفاده در پروکسی API خاص که کد پاسخ 503 را با کد خطا NoActiveTargets برای آن استفاده می‌کنید، رسیده است.
در مثال بالا، بررسی سلامت با خطای connection timed out ناموفق بود. بررسی کنید که آیا می‌توانید مستقیماً از هر یک از پردازشگرهای پیام با استفاده از دستور telnet به سرور باطن خاص متصل شوید:

telnet <BackendServer-HostName> 443

اگر بتوانید به سرور باطن متصل شوید، ممکن است پیامی مانند Connected to backend-server را مشاهده کنید. سپس ممکن است مشکل یک مشکل موقتی باشد و ممکن است حل شود یا یک مشکل متناوب باشد. مرحله 4 را چند بار (10 بار) تکرار کنید و خروجی را تأیید کنید.

اگر در دستور telnet به طور مداوم خطایی وجود نداشته باشد، مشکل حل می شود. دوباره بررسی کنید که آیا خرابی های چک سلامت متوقف شده است. اگر بله، پس دیگر لازم نیست کاری انجام دهید.
اگر نمی توانید به طور متناوب با فرمان telnet به سرور بک اند متصل شوید، ممکن است مشکل شبکه وجود داشته باشد یا سرور باطن شما مشغول باشد.

اگر نمی توانید با دستور telnet به طور مداوم به سرور باطن متصل شوید، ممکن است به این دلیل باشد که ترافیک از طرف پردازشگرهای پیام در سرور باطن خاص مجاز نیست.

قطعنامه

اگر خطای connection timed out به طور مداوم مشاهده می شود، مطمئن شوید که سرور باطن هیچ گونه محدودیت فایروال ندارد و اجازه می دهد تا ترافیک پردازشگرهای پیام Apigee Edge را انجام دهد. برای مثال، در لینوکس، می‌توانید از iptables برای اجازه دادن به ترافیک آدرس‌های IP پردازشگر پیام در سرور باطن استفاده کنید.

اگر مشکل همچنان ادامه داشت، برای تعیین و رفع مشکل با سرپرست شبکه خود کار کنید. اگر به کمک بیشتری از Apigee نیاز دارید، با پشتیبانی Apigee تماس بگیرید.

علت: درخواست ایمن در پورت غیر ایمن

تشخیص

شناسه پیام درخواست ناموفق را تعیین کنید .
شناسه پیام را در گزارش پردازشگر پیام جستجو کنید ( /opt/apigee/var/log/edge-message-processor/logs/system.log ).
پیام های خطای رایج مربوط به شناسه پیام را خواهید دید. با این حال، برای دریافت علت واقعی شکست‌های بررسی سلامت، بالای این پیام‌های خطای رایج بروید و خطاهای HEALTH MONITOR را بررسی کنید.
برای مثال، ممکن است یک خطای HEALTH MONITOR را مطابق شکل زیر مشاهده کنید:
```
Apigee-Timer-1 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://mocktarget.apigee.net:80/status
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
        at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
        at sun.security.ssl.InputRecord.read(InputRecord.java:527)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
…<snipped>
        
```
اگر این خطا برای MaxFailure چندین بار که در Health Monitor پیکربندی شده تکرار شود، یک پیام هشدار مانند زیر مشاهده خواهید کرد:
```
Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
        
```
اطلاعات درج شده در پیام هشدار را با دقت بخوانید. مطمئن شوید که تعداد MaxFailure برای سرور مورد نظر مورد استفاده در پروکسی API خاص که کد پاسخ 503 را با کد خطا NoActiveTargets برای آن استفاده می‌کنید، رسیده است.
بررسی سلامت با خطا انجام نشد:
```
Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
      
```
پیام خطا و URL نشان دهنده علت این مشکل این است که یک تماس امن (HTTPS) روی پورت غیر ایمن 80 برقرار شده است.
این خطا در دو حالت زیر ممکن است رخ دهد:
- سرور هدف امن تعریف شده با پورت غیر ایمن
- سرور هدف امن تعریف شده است اما مانیتور سلامت با یک پورت غیر ایمن پیکربندی شده است
پورت غیر ایمن هدف ایمن
سناریو 1: سرور هدف امن تعریف شده با پورت غیر ایمن
اگر یک سرور هدف امن تعریف کرده اید اما با یک پورت غیر ایمن مانند 80، با این خطا مواجه می شوید. مراحل زیر را دنبال کنید تا بررسی کنید که آیا این دلیل این مشکل است یا خیر:
1. تعریف سرور هدف مورد استفاده در پیکربندی نقطه پایانی هدف را بررسی کنید.
2. اکنون، پیکربندی Health Monitor را برای سرور مورد نظر در پیکربندی نقطه پایانی هدف بررسی کنید:
  پیکربندی مانیتور سلامت
  <HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <HTTPMonitor> <Request> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec> <Verb>GET</Verb> <Path>/statuscode/200</Path> </Request> <SuccessResponse> <ResponseCode>200</ResponseCode> </SuccessResponse> </HTTPMonitor> </HealthMonitor>
  توجه داشته باشید که هیچ عنصر <Port> در پیکربندی Health Monitor در بالا مشخص نشده است. در این مورد، پردازشگر پیام Edge از پورت مشخص شده در تعریف سرور هدف (که 80 است) برای برقراری تماس های API بررسی سلامت استفاده می کند.
3. بر اساس اطلاعات بالا، دلیل این خطا این است که سرور مورد نظر به عنوان یک سرور امن (به عنوان بلوک SSLInfo فعال است)، اما با پورت 80 غیر ایمن تعریف شده است.
پورت HM غیر ایمن هدف را ایمن کنید
سناریو 2: سرور هدف ایمن تعریف شده است اما مانیتور سلامت با یک پورت غیر ایمن پیکربندی شده است
اگر یک سرور هدف امن تعریف کرده اید اما مانیتور سلامت با یک پورت غیر ایمن مانند 80 پیکربندی شده است، این خطا را دریافت می کنید. مراحل زیر را دنبال کنید تا بررسی کنید که آیا این دلیل این مشکل است یا خیر:
1. تعریف سرور هدف مورد استفاده در پیکربندی نقطه پایانی هدف را بررسی کنید.
  برای دریافت تعریف سرور هدف از Get TargetServer API استفاده کنید.
  خروجی تعریف سرور هدف
  <TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
  در مثال بالا، تعریف نشان می دهد که هدف سرور mocktarget یک سرور امن است که توسط بلوک SSLInfo نشان داده شده است.
2. سپس، پیکربندی Health Monitor را برای سرور مورد نظر در پیکربندی نقطه پایانی هدف بررسی کنید:
  پیکربندی مانیتور سلامت
  <HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <HTTPMonitor> <Request> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec> <Port>80</Port> <Verb>GET</Verb> <Path>/statuscode/200</Path> </Request> <SuccessResponse> <ResponseCode>200</ResponseCode> </SuccessResponse> </HTTPMonitor>
  در مثال بالا، Health Monitor با پورت 80 غیر ایمن پیکربندی شده است، همانطور که با عنصر <Port> نشان داده شده است.
3. بر اساس اطلاعات بالا، دلیل این خطا این است که سرور هدف به عنوان یک سرور امن تعریف شده است (به عنوان بلوک SSLInfo فعال است) و از پورت امن 443 استفاده می کند، اما مانیتور سلامت برای انجام بررسی های سلامت با یک غیر ایمن پیکربندی شده است. پورت 80 (مشخص شده در عنصر <Port> ).
  یعنی در این حالت Edge API های بررسی سلامت را به عنوان یک تماس ایمن با پورت 80 غیر ایمن انجام می دهد و با خطای فوق الذکر از کار می افتد.
  توجه: عنصر <Port> پیکربندی شده در Health Monitor بر پورت استفاده شده در تعریف سرور هدف اولویت دارد.

قطعنامه

پورت غیر ایمن هدف ایمن

سناریو 1: سرور هدف امن تعریف شده با پورت غیر ایمن

برای رفع این خطا، تعریف سرور هدف را برای استفاده از یک پورت امن مناسب به روز کنید.

از Update a TargetServer API برای به روز رسانی تعریف سرور مورد نظر استفاده کنید و اطمینان حاصل کنید که یک پورت امن (به عنوان مثال: 443) همانطور که در مثال زیر نشان داده شده است استفاده می شود:

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo>
</TargetServer>

پورت HM غیر ایمن هدف را ایمن کنید

سناریو 2: سرور هدف ایمن تعریف شده است اما مانیتور سلامت با یک پورت غیر ایمن پیکربندی شده است

برای رفع این خطا، دستورالعمل های زیر را دنبال کنید:

پیکربندی Health Monitor را تغییر دهید تا از یک پورت امن (به عنوان مثال: 443) برای انجام بررسی سلامت سرور هدف در پیکربندی نقطه پایانی پروکسی API معیوب استفاده کنید، همانطور که در زیر نشان داده شده است:

<HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
    <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Port>443</Port>
      <Verb>GET</Verb>
      <Path>/statuscode/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>

تغییرات را در API Proxy ذخیره کنید.

علت: درخواست غیر ایمن در یک پورت امن

تشخیص

شناسه پیام درخواست ناموفق را تعیین کنید .
شناسه پیام را در گزارش پردازشگر پیام جستجو کنید ( /opt/apigee/var/log/edge-message-processor/logs/system.log ).
پیام های خطای رایج مربوط به شناسه پیام را خواهید دید. با این حال، برای دریافت علت واقعی شکست‌های بررسی سلامت، بالای این پیام‌های خطای رایج بروید و خطاهای HEALTH MONITOR را بررسی کنید.
برای مثال، ممکن است یک خطای HEALTH MONITOR را مطابق شکل زیر مشاهده کنید:
```
Apigee-Timer-2 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : http://mocktarget.apigee.net:443/status
java.net.SocketException: Unexpected end of file from server
	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:851)
	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:848)
	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
…<snipped>
          
```
اگر این خطا برای MaxFailure چندین بار که در Health Monitor پیکربندی شده تکرار شود، یک پیام هشدار مانند زیر مشاهده خواهید کرد:
```
Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
          
```
اطلاعات درج شده در پیام هشدار را با دقت بخوانید. مطمئن شوید که تعداد MaxFailure برای سرور مورد نظر مورد استفاده در پروکسی API خاص که کد پاسخ 503 را با کد خطا NoActiveTargets برای آن استفاده می‌کنید، رسیده است.
بررسی سلامت با خطا انجام نشد:
```
Error sending request Request URL : http://mocktarget.apigee.net:443/status
java.net.SocketException: Unexpected end of file from server
      
```
پیام خطا و URL نشان دهنده علت این مشکل این است که یک تماس غیر ایمن (HTTP) در پورت امن 443 برقرار شده است.
این خطا در دو حالت زیر ممکن است رخ دهد:
- سرور هدف غیر ایمن با پورت امن تعریف شده است
- سرور هدف غیر ایمن تعریف شده است اما مانیتور سلامت با یک پورت امن پیکربندی شده است
پورت امن هدف غیر ایمن
سناریو 1: سرور هدف غیر ایمن با پورت امن تعریف شده است
اگر یک سرور هدف غیر ایمن اما با یک پورت امن مانند 443 تعریف کرده اید، این خطا را دریافت می کنید. مراحل زیر را دنبال کنید تا بررسی کنید که آیا این دلیل این مشکل است یا خیر:
1. تعریف سرور هدف مورد استفاده در پیکربندی نقطه پایانی هدف را بررسی کنید.
  برای دریافت تعریف سرور هدف از Get TargetServer API استفاده کنید.
  خروجی تعریف سرور هدف
  <TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> </TargetServer>
  در مثال بالا، تعریف نشان می‌دهد که هدف سرور mocktarget یک سرور غیرایمن است زیرا بلوک SSLInfo وجود ندارد. با این حال، به اشتباه با پورت 443 ایمن پیکربندی شده است.
2. اکنون، پیکربندی Health Monitor را برای سرور مورد نظر در پیکربندی نقطه پایانی هدف بررسی کنید:
  پیکربندی مانیتور سلامت
  <HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <HTTPMonitor> <Request> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec> <Verb>GET</Verb> <Path>/statuscode/200</Path> </Request> <SuccessResponse> <ResponseCode>200</ResponseCode> </SuccessResponse> </HTTPMonitor> </HealthMonitor>
  توجه داشته باشید که هیچ عنصر <Port> در پیکربندی Health Monitor در بالا مشخص نشده است. در این حالت، پردازشگر پیام Edge از پورت مشخص شده در تعریف سرور هدف که 443 است استفاده می کند.
3. بر اساس اطلاعات بالا، دلیل این خطا این است که سرور هدف به عنوان یک سرور غیر امن (به عنوان بلوک SSLInfo تعریف نشده است) اما دارای پورت امن 443 تعریف شده است.
  یعنی Edge چک های سلامت را به صورت یک تماس غیر ایمن با پورت امن 443 انجام می دهد و با خطای فوق از کار می افتد.
پورت HM ایمن هدف غیر ایمن
سناریو 2: سرور هدف غیر ایمن تعریف شده است اما مانیتور سلامت با یک پورت امن پیکربندی شده است
اگر یک سرور هدف غیر ایمن تعریف کرده اید اما مانیتور سلامت با یک پورت امن مانند 443 پیکربندی شده است، این خطا را دریافت می کنید. مراحل زیر را دنبال کنید تا بررسی کنید که آیا این دلیل این مشکل است یا خیر:
1. تعریف سرور هدف مورد استفاده در پیکربندی نقطه پایانی هدف را بررسی کنید.
  برای دریافت تعریف سرور هدف از Get TargetServer API استفاده کنید.
  خروجی تعریف سرور هدف
  <TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>
  در مثال بالا، تعریف نشان می‌دهد که هدف سرور mocktarget یک سرور غیرایمن است (زیرا بلوک SSLInfo وجود ندارد) که با یک پورت غیر ایمن 80 به درستی پیکربندی شده است.
2. سپس، پیکربندی Health Monitor را برای سرور مورد نظر در پیکربندی نقطه پایانی هدف بررسی کنید:
  پیکربندی مانیتور سلامت
  <HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <HTTPMonitor> <Request> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec> <Port>443</Port> <Verb>GET</Verb> <Path>/statuscode/200</Path> </Request> <SuccessResponse> <ResponseCode>200</ResponseCode> </SuccessResponse> </HTTPMonitor> </HealthMonitor>
  در مثال بالا، Health Monitor با یک پورت امن 443 پیکربندی شده است که توسط عنصر <Port> نشان داده شده است.
3. بر اساس اطلاعات بالا، دلیل این خطا این است که سرور مورد نظر به عنوان یک سرور غیر ایمن (به عنوان بلوک SSLInfo تعریف نشده است) با پورت غیر ایمن 80 به درستی تعریف شده است، اما مانیتور سلامت برای انجام بررسی های سلامت پیکربندی شده است. با یک پورت امن 443 (مشخص شده در عنصر <Port> ).
  یعنی در این حالت Edge چک های سلامت را به صورت یک تماس غیر ایمن با پورت امن 443 انجام می دهد و با خطای فوق از کار می افتد.

قطعنامه

پورت امن هدف غیر ایمن

سناریو 1: سرور هدف غیر ایمن با پورت امن تعریف شده است

برای رفع این خطا، تعریف سرور هدف را برای استفاده از یک پورت امن مناسب به روز کنید.

از Update a Target Server API برای به روز رسانی تعریف سرور هدف استفاده کنید و اطمینان حاصل کنید که از یک پورت غیر ایمن (مثلا: 80) استفاده می شود. همانطور که در مثال زیر نشان داده شده است:

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>

پورت HM ایمن هدف غیر ایمن

سناریو 2: سرور هدف غیر ایمن تعریف شده است اما مانیتور سلامت با یک پورت امن پیکربندی شده است

برای رفع این خطا، دستورالعمل های زیر را دنبال کنید:

یا عنصر <Port> را از پیکربندی Health Monitor حذف کنید یا پیکربندی Health Monitor را تغییر دهید تا از یک پورت غیر ایمن (به عنوان مثال: 80) برای انجام بررسی سلامت سرور هدف در پیکربندی نقطه پایانی هدف پروکسی API معیوب استفاده کنید، همانطور که در زیر نشان داده شده است. :

<HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
   	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Port>80</Port>
      <Verb>GET</Verb>
      <Path>/statuscode/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>

تغییرات را در API Proxy ذخیره کنید.

علت: API بررسی سلامت با خطا پاسخ می دهد

تشخیص

شناسه پیام درخواست ناموفق را تعیین کنید .
شناسه پیام را در گزارش پردازشگر پیام جستجو کنید ( /opt/apigee/var/log/edge-message-processor/logs/system.log ).
پیام های خطای رایج مربوط به شناسه پیام را خواهید دید. با این حال، برای دریافت علت واقعی شکست‌های چک سلامت، بالای این پیام‌های خطای رایج بروید و خطاها/هشدارهای HEALTH MONITOR را بررسی کنید.
برای مثال، ممکن است یک هشدار HEALTH MONITOR را مطابق شکل زیر مشاهده کنید:
```
Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
Apigee-Timer-7 WARN  SERVICES.HEALTH_MONITOR - HTTPMonitor.monitor() : HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
        
```
اگر این خطا برای MaxFailure چندین بار که در Health Monitor پیکربندی شده تکرار شود، یک پیام هشدار مانند زیر مشاهده خواهید کرد:
```
Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
        
```
اطلاعات درج شده در پیام هشدار را با دقت بخوانید. مطمئن شوید که تعداد MaxFailure برای سرور مورد نظر مورد استفاده در پروکسی API خاص که کد پاسخ 503 را با کد خطا NoActiveTargets برای آن استفاده می‌کنید، رسیده است.
چک سلامت پیام هشدار را برگرداند:
```
HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
      
```
پیام هشدار بالا بیان می کند که کد پاسخ مورد انتظار برای API بررسی سلامت 200 بوده است ، اما پاسخ واقعی دریافت شده 404 است . از این رو، این به عنوان یک شکست تلقی می شود.
قبل از بررسی علت پاسخ خطا از API بررسی سلامت، مشخص کنید که چرا Edge انتظار دارد کد پاسخ برای API بررسی سلامت 200 باشد. برای این، پیکربندی Health Monitor را برای سرور مورد نظر در پیکربندی نقطه پایانی هدف بررسی کنید:
پیکربندی مانیتور سلامت
```
<HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
   	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Port>443</Port>
      <Verb>GET</Verb>
      <Path>/status/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>
        
```
توجه داشته باشید که پیکربندی Health Monitor با کد پاسخ 200 در زیر عنصر <SuccessResponse> پیکربندی شده است. این بدان معناست که اگر Edge هر کد پاسخی (مانند 400، 401، 404، 500) به غیر از 200 را از API بررسی سلامت دریافت کند، به عنوان یک خطا تلقی می شود و تعداد خرابی ها را افزایش می دهد.
اکنون، برای بررسی علت پاسخ به خطا از API بررسی سلامت، مراحل زیر را دنبال کنید:

به پیام قبل از پیام هشدار در گزارش پردازشگر پیام نگاه کنید.
```
Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
          
```
URL بررسی سلامت را از این پیام یادداشت کنید.
می‌توانید مستقیماً با این URL از پردازشگر پیام تماس بگیرید و پاسخ واقعی را بررسی کنید
```
curl -i https://mocktarget.apigee.net:443/status/200
          
```
همانطور که در گزارش‌های پردازشگر پیام مشاهده می‌شود، پاسخ تماس بالا 404 را می‌دهد:
```
< HTTP/2 404
          
```
این نشان می‌دهد که حتی تماس مستقیم با URL بررسی سلامت با همان کد پاسخ 404 انجام نمی‌شود. این بدان معنی است که URL بررسی سلامت ممکن است نادرست باشد یا منبعی که به عنوان بخشی از URL به آن دسترسی پیدا می‌کند دیگر در دسترس نباشد.
در مثال API بررسی سلامت ارائه شده در بالا، این مشکل به این دلیل رخ می دهد که یک URL نادرست در پیکربندی Health Monitor استفاده شده است. نشانی اینترنتی صحیح https://mocktarget.apigee.net:443/statuscode/200 از Mock Target API پیدا شد.

اگر پاسخ خطای دیگری دریافت کردید، با دنبال کردن مراحل بالا علت آن را مشخص کنید. در صورت نیاز، با تیم باطن خود کار کنید.

قطعنامه

مشکل API بررسی سلامت در سرور باطن خود را برطرف کنید.
برای رفع مشکل در مثال فوق:

عنصر <Path> را در پیکربندی Health Monitor به /statuscode/200 مطابق شکل زیر تغییر دهید:
```
<Path>/statuscode/200</Path>
        
```
تغییرات را در API Proxy ذخیره کنید.

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

با استفاده از نظارت API مشکلات را تشخیص دهید

API Monitoring شما را قادر می‌سازد تا مناطق مشکل‌دار را به سرعت جدا کنید تا خطاها، عملکرد، و مشکلات تأخیر و منبع آنها، مانند برنامه‌های توسعه‌دهنده، پراکسی‌های API، اهداف باطنی یا پلتفرم API را تشخیص دهید.

یک سناریوی نمونه را طی کنید که نحوه عیب‌یابی مشکلات 5xx با APIهای خود را با استفاده از API Monitoring نشان می‌دهد. به عنوان مثال، ممکن است بخواهید هشداری تنظیم کنید تا زمانی که تعداد خطاهای messaging.adaptors.http.flow.NoActiveTargets از یک آستانه خاص فراتر رفت، مطلع شوید.

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

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

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

نام سازمان
نام محیطی
نام پروکسی API
برای بازتولید خطا، دستور curl را کامل کنید
فایل ردیابی حاوی درخواست‌هایی با سرویس 503 در دسترس نیست با کد خطا NoActiveTargets

اگر کاربر Private Cloud هستید، اطلاعات زیر را ارائه دهید:
1. پیام خطای کامل مشاهده شد
2. نام محیطی
3. بسته پروکسی API
4. فایل ردیابی حاوی درخواست‌هایی با سرویس 503 در دسترس نیست با کد خطا NoActiveTargets
5. گزارش های دسترسی NGINX
  ( /opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log var/log/edge-router/nginx/<org>~<env>.<port#>_access_log )
6. گزارش های پردازشگر پیام
  ( /opt/apigee/var/log/edge-message-processor/logs/system.log )