‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

503 שירות לא זמין – NoActiveTargets – HealthCheckFailures

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

סרטונים

מידע נוסף על שגיאות 503 זמין בסרטונים הבאים:

וידאו	תיאור
פתרון בעיות שקשורות לשגיאה 503 (השירות לא זמין) – NoActiveTargets	מידע על הנושאים הבאים: החשיבות של שרתי יעד ושל כלי מעקב אחר תקינות פתרון בעיות של שגיאה בזמן אמת 503 Service Unavailable - NoActiveTargets שנגרמת בגלל כשל בבדיקת התקינות

תיאור הבעיה

אפליקציית הלקוח מקבלת את קוד הסטטוס של תגובת ה-HTTP‏ 503 עם ההודעה Service Unavailable וקוד השגיאה NoActiveTargets עבור בקשות ה-proxy ל-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 Proxy.

המדריך הזה עוסק בשגיאה 503 Service Unavailable עם קוד השגיאה NoActiveTargets שנגרמת בגלל כשלים בבדיקת התקינות. במדריך הזה מפורטות סיבות נוספות לשגיאה הזו.

כשלים בבדיקת התקינות

הכשלים בבדיקת תקינות יופיעו רק אם הגדרתם Health Monitor כחלק מהגדרת איזון העומסים של שרת היעד בנקודת הקצה של היעד של API Proxy.

כששרת יעד נכשל בבדיקת תקינות, 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:

שם שרת היעד
שמות הארגון והסביבה
שם ה-proxy ל-API
שם נקודת היעד

לאחר מכן, Edge מפסיק לשלוח בקשות נוספות לשרת הספציפי הזה. אחרי שכל שרתי היעד שהוגדרו בהגדרות של איזון העומסים מגיעים לספירה MaxFailure, בקשות ה-API הבאות מקבלות תגובה עם קוד השגיאה 503 שירות לא זמין וקוד השגיאה NoActiveTargets.

השימוש ב-Health Monitor מאפשר ל-Apigee Edge לכלול באופן אוטומטי שרת יעד בחזרה לרוטציה כשהוא חוזר לפעולה תקינה, בלי צורך לפרוס מחדש את ה-API Proxy.

אלה הסיבות האפשריות לכישלונות בבדיקת התקינות:

סיבה	תיאור	מי יכול לבצע את השלבים לפתרון בעיות
שגיאה: תם הזמן הקצוב לתפוגה של החיבור	מעבד ההודעות לא מצליח להתחבר לשרת היעד בתוך פרק הזמן שמוגדר כזמן קצוב לתפוגה בהגדרות של LoadBalancer.	משתמשים ב-Edge Private Cloud
בקשה מאובטחת ביציאה לא מאובטחת	אם שרת היעד מוגדר כשרת מאובטח, אבל הוא הוגדר בצורה שגויה עם יציאה לא מאובטחת. אם שרת היעד מוגדר כשרת מאובטח, אבל מנטר התקינות מוגדר לבצע בדיקות תקינות ביציאה לא מאובטחת.	משתמשים ב-Edge Private Cloud
בקשה לא מאובטחת ביציאה מאובטחת	אם שרת היעד מוגדר כשרת לא מאובטח, אבל הוגדר באופן שגוי עם יציאה מאובטחת. אם שרת היעד מוגדר כשרת לא מאובטח, אבל מנטר התקינות מוגדר לבצע בדיקות תקינות ביציאה מאובטחת.	משתמשים ב-Edge Private Cloud
ה-API של בדיקת תקינות מגיב בשגיאה	אם ה-API של בדיקת תקינות מגיב עם שגיאה או קוד תגובה, כל דבר אחר שצוין ברכיב SuccessResponse של Health Monitor.	משתמשים ב-Edge Private Cloud

שלבים נפוצים לאבחון

קביעת מזהה ההודעה של הבקשה שנכשלה

כלי המעקב

כדי לקבוע את מזהה ההודעה של הבקשה שנכשלה באמצעות הכלי 'מעקב':

מפעילים את הפעלת מעקב אחר סשן, שולחים את הקריאה ל-API ומשחזרים את הבעיה – 503 Service Unavailable עם קוד השגיאה NoActiveTargets.
בוחרים אחת מהבקשות שנכשלו.
עוברים אל שלב AX וקובעים את מזהה ההודעה (X-Apigee.Message-ID) של הבקשה על ידי גלילה למטה בקטע פרטי השלב, כמו שמוצג באיור הבא.

יומני גישה של NGINX

כדי לקבוע את מזהה ההודעה של הבקשה שנכשלה באמצעות יומני הגישה של NGINX:

אפשר גם לעיין ביומני הגישה של NGINX כדי לזהות את מזהה ההודעה של שגיאות 503. האפשרות הזו שימושית במיוחד אם הבעיה התרחשה בעבר או אם הבעיה מתרחשת לסירוגין ואין אפשרות לצלם את הנתונים בממשק המשתמש. כדי לקבוע את המידע הזה מיומני הגישה של NGINX:

בודקים את יומני הגישה של NGINX:‏ (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
מחפשים אם יש שגיאות 503 עבור ה-proxy ל-API הספציפי במהלך משך זמן מסוים (אם הבעיה התרחשה בעבר) או אם יש בקשות שעדיין נכשלות עם שגיאה 503.
אם יש שגיאות 503 עם X-Apigee-fault-code messaging.adaptors.http.flow.NoActiveTargets, שימו לב למזהה ההודעה של בקשה אחת או יותר כאלה, כמו שמוצג בדוגמה הבאה:
דוגמה לערך שבו מוצגת השגיאה 503

הודעות שגיאה נפוצות

כשמשתמשים בשרתי יעד ומתרחשת שגיאה בזמן שמעבד ההודעות מנסה להתחבר לשרת הקצה העורפי, יוצגו כמה הודעות שגיאה נפוצות ביומני מעבד ההודעות. השגיאות האלה מתועדות ביומן אחרי הודעת השגיאה או החריגה בפועל שגרמו לכשל.

הודעות השגיאה הנפוצות שמופיעות ביומני Message Processor ‏(/opt/apigee/var/log/edge-message-processor/logs/system.log) עבור 503 Service 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 מציינת שהודעת Message Processor נכשלה עם שגיאת timeout של חיבור כשבוצעה בקשת 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 פעמים, כמו שמוגדר בכלי לבדיקת תקינות, תוצג הודעת אזהרה כזו:
```
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 Proxy הספציפי שבו אתם נתקלים בקוד התגובה 503 עם קוד השגיאה NoActiveTargets.
בדוגמה שלמעלה, בדיקת התקינות נכשלה עם השגיאה connection timed out. בודקים אם אפשר להתחבר ישירות לשרת הספציפי של העורף מכל אחד ממעבדי ההודעות באמצעות הפקודה telnet:

telnet <BackendServer-HostName> 443

אם אתם מצליחים להתחבר לשרת הקצה העורפי, יכול להיות שתראו הודעה כמו Connected to backend-server. יכול להיות שהבעיה זמנית, שהיא נפתרה או שהיא מתרחשת לסירוגין. חוזרים על שלב 4 כמה פעמים (10 פעמים ומעלה) ומאמתים את הפלט.

אם הפקודה telnet לא מחזירה שגיאות באופן עקבי, סימן שהבעיה נפתרה. בודקים שוב אם הכשלים בבדיקת התקינות הפסיקו. אם כן, לא צריך לעשות שום דבר נוסף.
אם אתם לא מצליחים להתחבר לשרת העורפי באמצעות הפקודה telnet לסירוגין, יכול להיות שיש בעיה ברשת או שהשרת העורפי עמוס.

אם אתם לא מצליחים להתחבר לשרת העורפי באמצעות הפקודה telnet באופן עקבי, יכול להיות שהסיבה לכך היא שהתעבורה לא מורשית ממעבדי ההודעות בשרת העורפי הספציפי.

רזולוציה

אם השגיאה connection timed out חוזרת על עצמה, צריך לוודא שאין הגבלות של חומת אש בשרת העורפי, ושהוא מאפשר תנועה ממעבדי ההודעות של Apigee Edge. לדוגמה, ב-Linux, אפשר להשתמש ב-iptables כדי לאפשר את התנועה מכתובות ה-IP של מעבד ההודעות בשרת העורפי.

אם הבעיה נמשכת, צריך לעבוד עם האדמין של הרשת כדי לזהות את הבעיה ולפתור אותה. אם אתם צריכים עזרה נוספת מ-Apigee, אתם יכולים לפנות אל התמיכה של Apigee.

הסיבה: בקשה מאובטחת ביציאה לא מאובטחת

אבחון

קובעים את מזהה ההודעה של הבקשה שנכשלה.
מחפשים את מזהה ההודעה ביומן של מעבד הבקשות (/opt/apigee/var/log/edge-message-processor/logs/system.log).

יוצגו הודעות השגיאה הנפוצות שמתאימות למזהה ההודעה. עם זאת, כדי לגלות את הסיבה האמיתית לכשלים בבדיקת התקינות, צריך לגלול מעל הודעות השגיאה הנפוצות ולבדוק אם יש שגיאות של 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 מספר הפעמים שמוגדר ב'מעקב אחר תקינות המערכת', תוצג אזהרה כמו זו:

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 Proxy הספציפי שבו אתם נתקלים בקוד התגובה 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 בשרת היעד בהגדרה של נקודת הקצה של היעד:
  הגדרת 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> בהגדרות של כלי הבדיקה של תקינות המערכת שמופיעות למעלה. במקרה הזה, מעבד ההודעות של Edge משתמש ביציאה שצוינה בהגדרת שרת היעד (שהיא 80) כדי לבצע קריאות ל-API של בדיקת התקינות.
3. על סמך המידע שלמעלה, הסיבה לשגיאה הזו היא ששרת היעד מוגדר כשרת מאובטח (כי הבלוק SSLInfo מופעל), אבל עם יציאה לא מאובטחת 80.
יציאת HM מאובטחת של יעד לא מאובטח

תרחיש 2: שרת יעד מאובטח מוגדר, אבל Health Monitor מוגדר עם יציאה לא מאובטחת

אם הגדרתם שרת יעד מאובטח אבל ב-Health Monitor מוגדרת יציאה לא מאובטחת כמו 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 (בדיקת תקינות) בשרת היעד בהגדרת נקודת היעד:
  הגדרת 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>
  בדוגמה שלמעלה, המעקב אחר תקינות המערכת מוגדר עם יציאה לא מאובטחת 80, כפי שמצוין ברכיב <Port>.
3. על סמך המידע שלמעלה, הסיבה לשגיאה הזו היא שהשרת היעד מוגדר כשרת מאובטח (כי הבלוק SSLInfo מופעל) ומשתמש ביציאה מאובטחת 443, אבל Health Monitor מוגדר לבצע בדיקות תקינות עם יציאה לא מאובטחת 80 (שצוינה ברכיב <Port>).
  כלומר, במקרה הזה, Edge מבצעת את בדיקות התקינות של ממשקי ה-API כקריאה מאובטחת עם יציאה לא מאובטחת 80, והפעולה נכשלת עם השגיאה שצוינה למעלה.
  
  הערה: לרכיב <Port> שהוגדר בכלי למעקב אחר תקינות השרת יש עדיפות על פני היציאה שמשמשת בהגדרת שרת היעד.

רזולוציה

יציאה לא מאובטחת של יעד מאובטח

תרחיש 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 מוגדר עם יציאה לא מאובטחת

כדי לפתור את השגיאה, פועלים לפי ההוראות הבאות:

משנים את ההגדרה של Health Monitor כך שישתמש ביציאה מאובטחת (לדוגמה: 443) כדי לבצע בדיקות תקינות של שרת היעד בהגדרת נקודת היעד של ה-API Proxy שנכשל, כמו שמוצג בהמשך:

<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.
לדוגמה, יכול להיות שתראו שגיאה ב'ניטור תקינות' כמו בדוגמה הבאה:
```
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 מספר הפעמים שמוגדר ב'מעקב אחר תקינות המערכת', תוצג אזהרה כמו זו:
```
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 Proxy הספציפי שבו אתם נתקלים בקוד התגובה 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 בשרת היעד בהגדרה של נקודת הקצה של היעד:
  הגדרת 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: שרת יעד לא מאובטח מוגדר, אבל Health Monitor מוגדר עם יציאה מאובטחת

אם הגדרתם שרת יעד לא מאובטח, אבל ב-Health Monitor מוגדרת יציאה מאובטחת כמו 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 (בדיקת תקינות) בשרת היעד בהגדרת נקודת היעד:
  הגדרת 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>
  בדוגמה שלמעלה, כלי הבקרה של תקינות המערכת מוגדר עם יציאה מאובטחת 443, כפי שמצוין ברכיב <Port>.
3. על סמך המידע שלמעלה, הסיבה לשגיאה היא ששרת היעד מוגדר כשרת לא מאובטח (כי בלוק SSLInfo לא מוגדר) עם יציאה לא מאובטחת 80 בצורה נכונה, אבל Health Monitor מוגדר לבצע בדיקות תקינות עם יציאה מאובטחת 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: שרת יעד לא מאובטח מוגדר, אבל Health Monitor מוגדר עם יציאה מאובטחת

כדי לפתור את השגיאה, פועלים לפי ההוראות הבאות:

אפשר להסיר את רכיב <Port> מההגדרה של Health Monitor, או לשנות את ההגדרה של Health Monitor כך שתשתמש ביציאה לא מאובטחת (לדוגמה: 80) כדי לבצע בדיקות תקינות של שרת היעד בהגדרת נקודת הקצה של היעד של שרת ה-API Proxy שנכשל, כמו שמוצג בהמשך:

<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).
יוצגו הודעות השגיאה הנפוצות שמתאימות למזהה ההודעה. עם זאת, כדי לגלות את הסיבה האמיתית לכשלים בבדיקת התקינות, צריך לגלול מעל הודעות השגיאה הנפוצות ולבדוק אם יש שגיאות או אזהרות ב'ניטור התקינות'.
לדוגמה, יכול להיות שתראו אזהרה ב'מדד תקינות' כמו בדוגמה הבאה:
```
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 פעמים, כמו שמוגדר בכלי לבדיקת תקינות, תוצג הודעת אזהרה כזו:
```
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 Proxy הספציפי שבו אתם נתקלים בקוד התגובה 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 מצפה לקוד התגובה 200 מ-API לבדיקת תקינות. לשם כך, בודקים את ההגדרה של Health Monitor (ניטור תקינות) בשרת היעד בהגדרת נקודת הקצה של היעד:
הגדרת 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. כתובת ה-URL הנכונה היא https://mocktarget.apigee.net:443/statuscode/200 מתוך Mock Target API.

אם מקבלים תגובה אחרת לשגיאה, צריך לפעול לפי השלבים שלמעלה כדי לזהות את הסיבה לשגיאה. אם צריך, עובדים עם צוות ה-Backend.

רזולוציה

צריך לפתור את הבעיה בממשק ה-API של בדיקת התקינות בשרת הקצה העורפי.
כדי לפתור את הבעיה בדוגמה שלמעלה:

משנים את הרכיב <Path> בהגדרת Health Monitor ל-/statuscode/200 כמו שמוצג למטה:
```
<Path>/statuscode/200</Path>
        
```
שומרים את השינויים ב-API Proxy.

אם הבעיה נמשכת, צריך לעבור אל איסוף מידע לצורך אבחון.

אבחון בעיות באמצעות מעקב אחר קריאות ל-API

מעקב אחר API מאפשר לכם לבודד במהירות אזורים בעייתיים כדי לאבחן בעיות שקשורות לשגיאות, לביצועים ולזמן האחזור, ולמצוא את המקור שלהן, כמו אפליקציות למפתחים, שרתי proxy של API, יעדי קצה עורפיים או פלטפורמת ה-API.

דוגמה לתרחיש שמדגים איך לפתור בעיות מסוג 5xx בממשקי ה-API באמצעות API Monitoring. לדוגמה, אפשר להגדיר התראה כדי לקבל עדכון כשמספר messaging.adaptors.http.flow.NoActiveTargets התקלות חורג מסף מסוים.

צריך לאסוף פרטי אבחון

אם הבעיה נמשכת גם אחרי שמבצעים את ההוראות שלמעלה, צריך לאסוף את פרטי האבחון הבאים. אפשר ליצור קשר עם התמיכה של Apigee ולשתף איתם את הקבצים:

אם אתם משתמשים ב-Public Cloud, עליכם לספק את הפרטים הבאים:

שם הארגון
שם הסביבה
שם ה-proxy ל-API
השלמת פקודת curl לשחזור השגיאה
קובץ מעקב שמכיל את הבקשות עם השגיאה 503 Service Unavailable (השירות לא זמין) עם קוד השגיאה NoActiveTargets

אם אתם משתמשים ב-Private Cloud, עליכם לספק את הפרטים הבאים:
1. הודעת השגיאה המלאה שזוהתה
2. שם הסביבה
3. חבילת proxy ל-API
4. קובץ מעקב שמכיל את הבקשות עם השגיאה 503 Service Unavailable (השירות לא זמין) עם קוד השגיאה NoActiveTargets
5. יומני גישה של NGINX
  (/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log)
6. יומנים של מעבד בקשות
  (/opt/apigee/var/log/edge-message-processor/logs/system.log)