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

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

סרטונים

מומלץ לצפות בסרטונים הבאים כדי לקבל מידע נוסף על שגיאות 503:

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

תיאור הבעיה

אפליקציית הלקוח מקבלת את קוד הסטטוס 503 של תשובת HTTP עם הפרמטר ההודעה השירות לא זמין וקוד השגיאה 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 כשמשתמשים בשרת יעד אחד או יותר בהגדרה של נקודת הקצה (endpoint) של היעד ב-API Proxy.

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

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

הכשלים בבדיקת התקינות יתעדכנו רק אם הגדרתם Health Monitor כחלק מתצורת איזון העומסים בשרת היעד בנקודת הקצה (endpoint) של ה-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:

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

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

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

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

סיבה תיאור מי יכול לבצע את השלבים לפתרון בעיות
שגיאה של תפוגת הזמן הקצוב לחיבור מעבד ההודעות לא יכול להתחבר לשרת היעד בתום הזמן הקצוב לתפוגה תקופה בתצורת Load Balancer. משתמשי Edge בענן פרטי
בקשה מאובטחת ביציאה לא מאובטחת
  1. אם שרת היעד הוגדר כשרת מאובטח, אך מוגדר באופן שגוי עם יציאה לא מאובטחת.
  2. אם שרת היעד מוגדר כשרת מאובטח, אבל מעקב התקינות הוגדרה לבצע בדיקות תקינות ביציאה לא מאובטחת.
 משתמשי Edge בענן פרטי
בקשה לא מאובטחת ביציאה מאובטחת
  1. אם שרת היעד הוגדר כשרת לא מאובטח, אבל הוגדר באופן שגוי עם יציאה מאובטחת.
  2. אם שרת היעד מוגדר כשרת לא מאובטח, אבל מעקב התקינות מוגדר לביצוע בדיקות תקינות ביציאה מאובטחת.
 משתמשי Edge בענן פרטי
ה-Health Check API מגיב עם שגיאה אם ה-API של בדיקת התקינות מגיב עם שגיאה או קוד תגובה, כל דבר מלבד שצוין ברכיב SuccessResponse של Health Monitor. משתמשי Edge בענן פרטי

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

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

כלי המעקב

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

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

    מזהה ההודעה בקטע &#39;פרטי השלב&#39;

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

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

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

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

    רשומה לדוגמה שמציגה שגיאה 503

    רשומה לדוגמה שמציגה קוד סטטוס, מזהה הודעה, מקור השגיאה וקוד השגיאה

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

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

הודעות השגיאה הנפוצות שזוהו ביומנים של מעבד ההודעות. (/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 כתגובה ללקוח.

הסיבה: הזמן הקצוב לתפוגה של החיבור חלף

אבחון

  1. מזהים את מזהה ההודעה של הבקשה שנכשלה.
  2. חיפוש מזהה ההודעה ביומן מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log).
  3. תוכלו לראות את הודעות שגיאה נפוצות שתואמות למזהה ההודעה. אבל, לפעמים כדי לקבל את הסיבה בפועל לכשלים בבדיקת התקינות, צריך לגלול מעל הודעות שגיאה נפוצות ולבדוק אם יש שגיאות מעקב תקינות.

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

  4. בדוגמה שלמעלה, בדיקת התקינות נכשלה עם השגיאה connection timed out. לבדוק אם אתם יכולים להתחבר לשרת העורפי הספציפי ישירות מכל אחד מהדפדפנים הבאים: מעבדי הודעות באמצעות הפקודה telnet:
    5. telnet <BackendServer-HostName> 443
  5. אם אתם מצליחים להתחבר לשרת הקצה העורפי, יכול להיות שתוצג לכם הודעה כמו מחובר לשרת עורפי. לאחר מכן הבעיה עשויה להיות בעיה זמנית ייתכן שהיא נפתרה או שהיא בעיה זמנית. חוזרים על שלב 4 כמה פעמים. (לפחות 10 פעמים) ומאמתים את הפלט.
    1. אם אין שגיאות בפקודה telnet באופן עקבי, הבעיה היא הבעיה נפתרה. בדקו שוב אם הכשלים בבדיקת התקינות הופסקו. אם כן, אין צורך לעשות זאת. לכל מטרה נוספת.
    2. אם לא מצליחים להתחבר לסירוגין לשרת הקצה העורפי באמצעות הפקודה telnet, יכול להיות שיש בעיה ברשת או ששרת הקצה העורפי שלכם עמוס.
  6. אם אין לכם אפשרות להתחבר לשרת הקצה העורפי באמצעות הפקודה telnet בעקביות, יכול להיות שהסיבה לכך היא שהתנועה לא מותרת ממעבדי ההודעות בשרת העורפי הספציפי.

רזולוציה

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

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

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

אבחון

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

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

    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 הגעת למספר המרבי של שרת יעד שבו נעשה שימוש בשרת ה-Proxy הספציפי ל-API שעבורו בחרת לקבל את קוד התגובה 503 עם קוד השגיאה NoActiveTargets.

  4. בדיקת התקינות נכשלה עם השגיאה: 
    Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?

    בהודעת השגיאה ובכתובת ה-URL מציינות שהסיבה לבעיה הזו היא שיחה מאובטחת (HTTPS) בוצעה ביציאה לא מאובטחת 80.

    שגיאה זו יכולה להתרחש בשני התרחישים הבאים:

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

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

    תרחיש 1: שרת יעד מאובטח מוגדר עם יציאה לא מאובטחת

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

    1. צריך לבדוק את ההגדרה של שרת היעד שמשמש בהגדרה של נקודת הקצה (endpoint) של היעד.

      2. משתמשים ב קבלת TargetServer API כדי לקבל את ההגדרה של שרת היעד.

      פלט הגדרת שרת היעד

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

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

    2. עכשיו צריך לבדוק את ההגדרות של Health Monitor לשרת היעד בהגדרה של נקודת הקצה (endpoint) של היעד:

      ההגדרה של כלי תקינות המכשיר

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

    אם הגדרתם שרת יעד מאובטח אבל ב-Health Monitor מוגדר יציאה לא מאובטחת כמו 80, אז השגיאה הזו מופיעה. כדי לאמת, צריך לפעול לפי השלבים הבאים אם זו הסיבה לבעיה:

    1. צריך לבדוק את ההגדרה של שרת היעד שמשמש בהגדרה של נקודת הקצה (endpoint) של היעד.

      אפשר להשתמש ב שימוש ב-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 לגבי שרת היעד בהגדרה של נקודת הקצה (endpoint) של היעד:

      ההגדרה של כלי תקינות המכשיר

      <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, אבל Health Monitor מוגדרת לבצע בדיקות תקינות עם יציאה לא מאובטחת 80 (מצוינת ברכיב <Port>).

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

רזולוציה

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

תרחיש 1: שרת יעד מאובטח מוגדר עם יציאה לא מאובטחת

כדי לתקן את השגיאה הזו, צריך לעדכן את ההגדרה של שרת היעד כך שתשתמש ביציאה מאובטחת מתאימה.

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

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

  1. יש לשנות את התצורה של Health Monitor לשימוש ביציאה מאובטחת (לדוגמה: 443) לביצוע היעד בדיקות תקינות של השרת בתצורת נקודת הקצה (endpoint) של ה-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>
  2. שומרים את השינויים שבוצעו בשרת ה-proxy של ה-API.

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

אבחון

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

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

    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 הגעת למספר המרבי של שרת יעד שבו נעשה שימוש בשרת ה-Proxy הספציפי ל-API שעבורו בחרת לקבל את קוד התגובה 503 עם קוד השגיאה NoActiveTargets.

  4. בדיקת התקינות נכשלה עם השגיאה: 
    Error sending request Request URL : http://mocktarget.apigee.net:443/status
java.net.SocketException: Unexpected end of file from server

    בהודעת השגיאה ובכתובת ה-URL מציינות שהסיבה לבעיה הזו היא קריאה לא מאובטחת (HTTP) בוצעה ביציאה מאובטחת 443.

    שגיאה זו יכולה להתרחש בשני התרחישים הבאים:

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

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

    תרחיש 1: שרת יעד לא מאובטח מוגדר עם יציאה מאובטחת

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

    1. צריך לבדוק את ההגדרה של שרת היעד שמשמש בהגדרה של נקודת הקצה (endpoint) של היעד.

      אפשר להשתמש ב שימוש ב-TargetServer API כדי לקבל את ההגדרה של שרת היעד.

      פלט הגדרת שרת היעד

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

      בדוגמה שלמעלה, ההגדרה מראה ששרת היעד mocktarget הוא שרת לא מאובטח כי אין בלוק SSLInfo. עם זאת, הטקסט הוא שגוי מוגדר ביציאה מאובטחת 443.

    2. עכשיו צריך לבדוק את ההגדרות של Health Monitor לשרת היעד בהגדרה של נקודת הקצה (endpoint) של היעד:

      ההגדרה של כלי תקינות המכשיר

      <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. צריך לבדוק את ההגדרה של שרת היעד שמשמש בהגדרה של נקודת הקצה (endpoint) של היעד.

      אפשר להשתמש ב שימוש ב-TargetServer API כדי לקבל את ההגדרה של שרת היעד.

      פלט הגדרת שרת היעד

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

      בדוגמה שלמעלה, ההגדרה מראה ששרת היעד mocktarget הוא לא מאובטח שרת (מכיוון שאין בלוק SSLInfo) שהוגדר עם יציאה לא מאובטחת 80 נכון.

    2. בשלב הבא, בודקים את ההגדרות של Health Monitor לגבי שרת היעד בהגדרה של נקודת הקצה (endpoint) של היעד:

      ההגדרה של כלי תקינות המכשיר

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

כדי לתקן את השגיאה הזו, צריך לעדכן את ההגדרה של שרת היעד כך שתשתמש ביציאה מאובטחת מתאימה.

אפשר להשתמש ב צריך לעדכן את Target Server API כדי לעדכן את ההגדרה של שרת היעד ולוודא נעשה שימוש ביציאה לא מאובטחת (לדוגמה: 80) כמו בדוגמה הבאה: 

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

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

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

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

  1. צריך להסיר את הרכיב <Port> מהתצורה של Health Monitor או לשנות את התצורה של Health Monitor לשימוש ביציאה לא מאובטחת (לדוגמה: 80) כדי לבצע בדיקות תקינות של שרת היעד בתצורה של נקודת הקצה (endpoint) של היעד של ה-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>
  2. שומרים את השינויים שבוצעו בשרת ה-proxy של ה-API.

הסיבה: בדיקת התקינות של API מגיב עם שגיאה

אבחון

  1. מזהים את מזהה ההודעה של הבקשה שנכשלה.
  2. חיפוש מזהה ההודעה ביומן מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log).
  3. יוצגו הודעות השגיאה הנפוצות שמתאימות למזהה ההודעה. עם זאת, כדי לקבל את הסיבה בפועל לכשלים בבדיקת התקינות, אפשר לגלול מעל הודעות שגיאה נפוצות ולבדוק אם יש שגיאות או אזהרות לגבי תקינות 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 הגעת למספר המרבי של שרת יעד שבו נעשה שימוש בשרת ה-Proxy הספציפי ל-API שעבורו בחרת לקבל את קוד התגובה 503 עם קוד השגיאה NoActiveTargets.

  4. בבדיקת התקינות הוחזרה הודעת האזהרה: 
    HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404

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

  5. לפני שבודקים את הסיבה לשגיאה מה-API של בדיקת התקינות, חשוב להבין למה Edge מצפה שקוד התגובה יהיה 200 עבור ה-API של בדיקת התקינות. לשם כך, צריך לבדוק ב-Health Monitor של שרת היעד בתצורה של נקודת הקצה (endpoint) של היעד:

    ההגדרה של כלי תקינות המכשיר

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

  6. עכשיו, כדי לבדוק את הסיבה לתגובה לשגיאה מה-API של בדיקת התקינות, צריך לבצע את השלבים הבאים:
    1. בודקים את ההודעה שלפני הודעת האזהרה ביומן מעבד ההודעות. 
      Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200

      צריך לרשום לפניכם את כתובת ה-URL של בדיקת התקינות בהודעה הזו.

    2. אפשר לבצע שיחה ישירה לכתובת ה-URL הזו ממעבד ההודעות ולבדוק את התגובה בפועל 
      curl -i https://mocktarget.apigee.net:443/status/200

      התגובה מהקריאה שלמעלה מחזירה שגיאת 404 כפי שהיא מופיעה ביומני מעבד ההודעות:

      < HTTP/2 404
    3. זה מראה שאפילו הקריאה הישירה לכתובת ה-URL של בדיקת התקינות נכשלת עם אותו קוד תגובה 404. המשמעות היא שיכול להיות שכתובת ה-URL של בדיקת התקינות שגויה או שהמשאב שאליו מתבצעת גישה כחלק מכתובת ה-URL לא זמין יותר.
    4. ב-API לדוגמה של בדיקת התקינות שסופק למעלה, הבעיה מתרחשת כי נעשה שימוש בכתובת URL שגויה בהגדרה של כלי המעקב אחר תקינות. כתובת ה-URL הנכונה נמצאת במרחק https://mocktarget.apigee.net:443/statuscode/200 מ- Mock Target API
  7. אם מקבלים תגובות שגיאה אחרות, אפשר לקבוע את הסיבה לכך לפי ההנחיות השלבים שלמעלה. אם צריך, כדאי לעבוד עם צוות הקצה העורפי.

רזולוציה

  1. צריך לפתור את הבעיה ב-API של בדיקת התקינות בשרת הקצה העורפי שלכם.
  2. כדי לפתור את הבעיה בדוגמה שצוינה למעלה:
    1. משנים את הרכיב <Path> בהגדרה של Health Monitor ל-/statuscode/200 כפי שמוצג כאן: 
      <Path>/statuscode/200</Path>
    2. שומרים את השינויים ב-proxy של ה-API.

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

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

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

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

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

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

  1. אם אתם משתמשים בענן ציבורי, עליכם לספק את הפרטים הבאים:
    1. שם הארגון
    2. שם הסביבה
    3. שם ה-API של ה-Proxy
    4. צריך להשלים את פקודת ה-curl כדי לשחזר את השגיאה
    5. קובץ מעקב המכיל את הבקשות עם שירות 503 לא זמין עם קוד שגיאה NoActiveTargets
  2. אם אתם משתמשים בענן פרטי, עליכם לספק את הפרטים הבאים:
    1. זוהה הודעת שגיאה מלאה
    2. שם הסביבה
    3. חבילת API Proxy
    4. קובץ מעקב המכיל את הבקשות עם שירות 503 לא זמין עם קוד שגיאה 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)