404 לא ניתן לזהות שרת proxy למארח: <שם מארח וירטואלי> וכתובת URL: <path>

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

תיאור הבעיה

אפליקציית הלקוח מקבלת קוד סטטוס HTTP של 404 יחד עם ההודעה Not Found והודעת השגיאה Unable to identify proxy for host: VIRTUAL_HOST and url: PATH בתגובה לקריאות ל-API.

משמעות השגיאה הזו היא ש-Edge לא הצליח למצוא את שרת ה-proxy של ה-API עבור המארח והנתיב הווירטואלי שצוינו.

הודעת שגיאה

תקבלו את קוד מצב ה-HTTP הבא: 

HTTP/1.1 404 Not Found

בנוסף, תוצג לכם הודעת שגיאה שדומה להודעה שמוצגת בהמשך: 

{
   "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/oauth2\/token",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

הודעת השגיאה שלמעלה מציינת ש-Edge לא הצליח למצוא את ה-API של שרת ה-proxy מארח וירטואלי של default ונתיב /oauth2/token.

סיבות אפשריות

אלה כמה מהסיבות האפשריות לשגיאה הזו:

סיבה תיאור הוראות לפתרון בעיות עבור
שרת proxy ל-API לא משויך למארח הווירטואלי הספציפי שרת ה-proxy הספציפי ל-API לא מוגדר לקבל בקשות במארח הווירטואלי שצוין בהודעת השגיאה. משתמשי Edge בענן הציבורי והפרטי
המארח הווירטואלי הוסר בגרסה חדשה של שרת proxy ל-API שנפרסה הסרת המארח הווירטואלי מהגרסה החדשה שנפרסה בזמן שהלקוח ללא תזוזה שימוש במארח הווירטואלי הספציפי עלול לגרום לבעיה הזו. משתמשי Edge בענן הציבורי והפרטי
הנתיב לא משויך לאף שרת proxy ל-API שרת ה-proxy הספציפי ל-API לא מוגדר לקבל בקשות בנתיב שצוין בהודעת השגיאה. משתמשי Edge בענן הציבורי והפרטי
שרת proxy ל-API לא פרוס בסביבה שרת ה-proxy הספציפי ל-API לא נפרס בסביבה הספציפית שבה שמנסה לשלוח את בקשות ה-API. משתמשי Edge בענן הציבורי והפרטי
הסביבה לא נטענה במעבד ההודעות בסביבה הספציפית (שבה אתם מנסים לשלוח את בקשות ה-API) נטען במעבדי ההודעות בגלל שגיאה. משתמשי Edge בענן פרטי
שרת proxy ל-API לא נפרס במעבד הודעות אחד או יותר יכול להיות ששרת ה-proxy של ה-API לא פרוס במעבד הודעות אחד או יותר כי חסרים בו התראה על אירוע במהלך הפריסה. משתמשי Edge בענן פרטי

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

היומנים של NGINX ושל מעבד ההודעות יעזרו בפתרון השגיאה 404. כך בודקים את היומנים:

  1. כדי לצפות ביומני NGINX, משתמשים בפקודה הבאה: 
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  2. בודקים את השדות הבאים ברשומות ביומן:
    שדה ערך
    Upstream_status, status 404
    X-Apigee-fault-code messaging.adaptors.http.flow.ApplicationNotFound

    מציינים את מזהה ההודעה ביומנים.

  3. בדיקת היומנים של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log) כדי לבדוק אם יש את messaging.adaptors.http.flow.ApplicationNotFound ל-API הספציפי או אם יש לכם מזהה ההודעה משלב 2 של בקשת ה-API.

    הודעת שגיאה לדוגמה מהיומן של מעבד ההודעות

    4. NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractRequestListener.onException() : Request:POST, uri:/weather, message Id:null, exception:com.apigee.rest.framework.ResourceNotFoundException{ code = messaging.adaptors.http.flow.ApplicationNotFound, message = Unable to identify proxy for host: vh1 and url: /weather, associated contexts = []}, context:Context@342ea86b input=ClientInputChannel(SSLClientChannel[Accepted: Remote:10.123.123.123:8443 Local:10.135.33.68:62092]@1206954 useCount=1 bytesRead=0 bytesWritten=0 age=1ms  lastIO=0ms  isOpen=true)

    היומן שלמעלה מציג את קוד השגיאה ואת הודעת השגיאה כך:

    code = messaging.adaptors.http.flow.ApplicationNotFound,
message = Unable to identify proxy for host: vh1 and url: /weather

הסיבה: שרת proxy של API לא משויך למארח הווירטואלי הספציפי

אם ה-Proxy ל-API לא מוגדר לקבל את הבקשות מהמארח הווירטואלי הספציפי, אנחנו יכולים לקבל תשובה 404 Not Found עם הודעת השגיאה Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

אבחון

  1. בודקים את ההגדרה של נקודת הקצה (endpoint) של שרת ה-proxy עבור ה-proxy ל-API ובודקים אם מוגדר לקבל את הבקשות למארח הווירטואלי שצוין בשגיאה. הדבר שמצוין באמצעות הרכיב VirtualHost. בואו נבחן דוגמה ProxyEndpoint כדי להבין את זה.

    דוגמה להגדרה של נקודת קצה (endpoint) של שרת Proxy) שמראה ששרת ה-Proxy ל-API מקבל בקשות מארח וירטואלי מאובטח

  2. נניח שהמארחים הווירטואליים מוגדרים בסביבה הספציפית כך:
    שם יציאה כתובת האימייל החלופית של המארח
    default 80 myorg-prod.apigee.net
    secure 443 myorg-prod.apigee.net
  3. שולחים בקשת API ל-VirtualHost של default באמצעות כתובת ה-URL http://myorg-prod.apigee.net/weather
  4. מכיוון שב-ProxyEndpoint אין default VirtualHost כמו שמוצג בדוגמה שלמעלה, תקבלו את קוד התגובה 404 עם הודעת השגיאה הבאה: 
    {"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  5. כדי לטפל בבעיה, אפשר לעבור לקטע פתרון בהמשך.
  6. אם ProxyEndpoint מוגדר לקבל את הבקשות בdefault VirtualHost, מעבר למטרה הבאה – הנתיב לא משויך לאף שרת proxy של API.

רזולוציה

  1. הוספת VirtualHost החסר להגדרות האישיות של ProxyEndpoint כדי לטפל בבעיה. בדוגמה שלמעלה אפשר להוסיף את ערך ברירת המחדל VirtualHost. לתצורה ProxyEndpoint באופן הבא: 
    <VirtualHost>default</VirtualHost>

    תצורה לדוגמה של נקודת קצה (endpoint) של שרת proxy מציגה את ברירת המחדל> VirtualHost&gt; בתהליך הוספה

  2. לחלופין, בדוגמה שצוינה למעלה, אם התכוונת להשתמש רק secure VirtualHost לשרת ה-proxy הספציפי הזה, ולאחר מכן לשלוח את בקשות ה-API רק ל-secure VirtualHost באמצעות פרוטוקול HTTPS: 
    https://myorg-prod.apigee.net/weather

הסיבה: מארח וירטואלי הוסר בגרסה חדשה של שרת proxy ל-API שנפרסה

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

אבחון

  1. כדי לראות אם ה-Proxy ל-API פועל בהגדרה של נקודת הקצה (endpoint) של שרת ה-proxy, מוגדר לקבל את הבקשות למארח הווירטואלי שצוין בשגיאה. הדבר מצוין על ידי הרכיב VirtualHost בתצורה של ProxyEndpoint.
  2. אם המארח הווירטואלי שצוין בשגיאה לא קיים ב-ProxyEndpoint ולאחר מכן מבצעים את השלבים הבאים. אחרת, עברו לסיבה הבאה: הנתיב לא משויך לאף שרת proxy של API.
  3. להשוות בין התצורה של ProxyEndpoint של הגרסה הקודמת שנפרסה לבין התצורה הנוכחית שנפרסה.
    1. לדוגמה, נניח שהגרסה הקודמת שנפרסה הייתה 5 הגרסה הקודמת שנפרסה כרגע היא 6:
      • מארחים וירטואליים שהוגדרו בנקודת קצה של שרת proxy בגרסה 5
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
      • מארחים וירטואליים שהוגדרו בנקודת קצה (endpoint) של שרת proxy בגרסה 6
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
    2. בדוגמה שלמעלה, VirtualHost vh1 היה קיים ב-revision 5, אבל הוא הוסר ב-revision 6 והוחלף ב-VirtualHost secure.
    3. לכן אם אתם או הלקוחות שלכם שולחים את הבקשות לשרת ה-proxy ל-API הזה באמצעות VirtualHost vh1 (זה היה חלק מ-revision 5), ואז תקבל את קוד תגובה 404 עם הודעת השגיאה הבאה: 
      {"fault":{"faultstring":"Unable to identify proxy for host: vh1 and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  4. לבדוק אם השינוי במארח הווירטואלי בוצע בכוונה או בלי כוונה בגרסה הקודמת שנפרסת, ולקחת את האמצעים המתאימים, כפי שמוסבר בקטע פתרון.

רזולוציה

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

תרחיש מס' 1: שינוי מכוון

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

  1. ליצור שרת proxy חדש עם נתיב בסיס אחר ולהשתמש במארח וירטואלי אחר (שלא קיים בגרסה הקודמת שנפרסה).

  2. אם אתם רוצים להמשיך להשתמש בשרת ה-proxy הקיים של ה-API אבל להשתמש במארח וירטואלי אחר, עדיף לשמור את המארח הווירטואלי הקיים ולהוסיף את המארח הווירטואלי הנוסף.

    כך אפשר לוודא שהמשתמשים בשרת ה-Proxy של ה-API לא יושפעו מהשינוי.

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

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

תרחיש מס' 2: שינוי לא מכוון

אם ההסרה של המארח הווירטואלי בוצעה בטעות ולא באופן מכוון,יש לבצע את הפעולות הבאות:

  1. כדי להשתמש, יש לעדכן את התצורה של ProxyEndpoint בגרסה הנוכחית שנפרסה את אותם מארחים וירטואליים שהיו בשימוש בגרסה הקודמת שנפרסה. ב בדוגמה שלמעלה, משנים את הקטע הבא מ: 
    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

    עד

    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
  2. לפרוס מחדש את הגרסה.

שיטות מומלצות

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

הסיבה: הנתיב לא משויך לאף שרת proxy של API

אם ה-Proxy ל-API לא מוגדר לקבל את הבקשות לנתיב הספציפי שבו נעשה שימוש ב- כתובת URL של בקשת API, לאחר מכן נוכל לקבל תשובה מסוג 404 Not Found עם הודעת השגיאה Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

אבחון

  1. יש לבדוק את ההגדרה של ProxyEndpoint עבור שרת ה-proxy הספציפי ל-API שעבורו התכוונת כדי לשלוח את בקשות ה-API.
  2. בודקים אם ה-Proxy ל-API מוגדר לקבל את הבקשות לנתיב הספציפי שצוין בהודעת השגיאה. כדי לעשות את זה, צריך לבצע את השלבים בקטע תרחיש מס' 1 וגם תרחיש מס' 2.

תרחיש מס' 1: הנתיב לא תואם לנתיב הבסיסי של שרת ה-proxy ל-API

  1. אם ה-path שצוין בהודעת השגיאה שונה מה-basepath של שרת ה-proxy הספציפי או שהוא לא מתחיל ב-basepath, אז עשויה להיות הסיבה לשגיאה.
  2. הנה דוגמה שתסביר את זה:
    1. ה-basepath של שרת ה-proxy המיועד ל-API הוא /weather
    2. כתובת ה-URL של בקשת ה-API היא https://myorg-prod.apigee.net/climate. המשמעות היא הנתיב בכתובת ה-URL של בקשת ה-API הוא /climate.
  3. בדוגמה הזו, path שונה מ-basepath, לא מתחיל ב-basepath. לכן מקבלים את השגיאה הבאה: 
    {
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/climate",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

רזולוציה

  1. מוודאים שה-path שמופיע בכתובת ה-URL של בקשת ה-API זהה ל-basepath של שרת ה-proxy הספציפי ל-API.
  2. בדוגמה שלמעלה, כתובת ה-URL של בקשת ה-API צריכה להיות כך: 
    {
https://myorg-prod.apigee.net/weather

תרחיש מס' 2: הנתיב לא תואם לאף אחד מהתהליכים המותנים הזמינים.

  1. אם ה-path שנעשה בו שימוש בכתובת ה-URL של בקשת ה-API מתחיל ב-basepath, אז ייתכן שה-path suffix (החלק שמגיע אחרי basepath) שצוין בהודעת השגיאה לא תואם לאף אחד מהתנאים המותנים יכול לגרום לשגיאה 404.
  2. הנה דוגמה שתסביר את זה:
    1. ה-basepath של שרת ה-proxy המיועד ל-API הוא /weather
    2. כתובת ה-URL של בקשת ה-API היא https://myorg-prod.apigee.net/weather/Delhi. כלומר הנתיב בכתובת ה-URL של בקשת ה-API הוא /weather/Delhi.
  3. בדוגמה הזו, הערך path מתחיל ב-basepath /weather. בנוסף, יש בו path suffix של /Delhi.
  4. עכשיו צריך לבדוק אם יש תהליכים מותנים ב-ProxyEndpoint.
  5. אם אין תהליכים מותנים או שיש כמה תהליכים לא מותנים, עוברים אל הסיבה הבאה: שרת proxy ל-API לא פרוס בסביבה.
  6. אם ל-ProxyEndpoint יש רק תהליכים מותנים, צריך לבדוק את הדברים הבאים:
    1. אם התנאים בכל התהליכים המותנים האלה בודקים אם קיים proxy.pathsuffix ספציפי (הנתיב שאחרי הנתיב הבסיסי).
    2. ואם ה-path suffix שצוין בכתובת ה-URL של בקשת ה-API לא תואם אז זו הסיבה לשגיאה.
  7. נניח שיש לנו שני תהליכים ב-ProxyEndpoint ושניהם זורמים מותנים, כפי שמוצג בהמשך: 
    <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>

<Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
    1. בדוגמה שלמעלה, יש לנו שני תהליכים מותנים, אחד שתואם proxy.pathsuffix (נתיב אחרי הנתיב הבסיסי) אל /Bangalore ואל השני תואם ל-/Chennai. אבל אין אף תוצאה שתואמת ל-/Delhi שהוא ה-path suffix שמועבר בכתובת ה-URL של בקשת ה-API.
    2. זו הסיבה לשגיאה 404. לכן תתקבל השגיאה הבאה: 
      {
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

רזולוציה

  1. חשוב לוודא שה-path suffix תואם לפחות לאחד מהתהליכים המותנים בנקודת הקצה של שרת ה-proxy.
  2. בדוגמה שלמעלה אפשר להשתמש בשיטות הבאות כדי לפתור את השגיאה:
    1. אם רוצים להפעיל קבוצה ספציפית של כללי מדיניות בנתיב /Delhi, ואז להוסיף תהליך נפרד עם קבוצת כללי המדיניות הנדרשת ולוודא שיש תנאי שתואם ל/Delhi של /proxy.pathsuffix כמו שמוצג בהמשך: 
      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>
    2. כדי להפעיל קבוצה משותפת של כללי מדיניות בנתיב /Delhi, את התהליך הנפוץ, לוודא שיש תנאי שמאפשר /proxy.pathsuffix. כלומר, היא תאפשר כל נתיב אחרי basepath /weather כפי שמוצג בהמשך: 
      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

אם ב-ProxyEndpoint יש את basepath הנכון וה-path suffix שצוין בכתובת ה-URL של ה-API תואם לאחד מהתהליכים המותנים, ואז עובר לסיבה הבאה - שרת proxy ל-API לא פרוס בסביבה.

הסיבה: שרת proxy של API לא נפרס בסביבה

אבחון

  1. קובעת את הסביבה שאליה קיים הכינוי של המארח, שמופיע בכתובת ה-URL של בקשת ה-API. ניתן לעשות זאת על ידי בדיקת הפרטים של כל המארחים הווירטואליים בכל אחת מהסביבות של הארגון בממשק המשתמש של Edge.

    לדוגמה, נניח את ההגדרות הבאות:

    • אם המיקום http://myorg-prod.apigee.net/weather הוא כתובת ה-URL, אז myorg-prod.apigee.net הוא הכינוי של המארח.
    • הכינוי של המארח myorg-prod.apigee.net מוגדר כחלק מ מארחים וירטואליים בסביבה prod של הארגון.
  2. בדיקה אם שרת ה-proxy הספציפי ל-API נפרס בסביבה הספציפית שנקבעה בשלב 1 שלמעלה.
  3. אם שרת ה-proxy של ה-API לא נפרס בסביבה הספציפית, זו הסיבה לכך השגיאה 404.
    1. כך שבדוגמה שבה נעשה שימוש בשלב 1 שלמעלה, נניח ששרת ה-Proxy של API לא נפרס prod, אז זו הסיבה לשגיאה.
    2. עוברים לקטע פתרון בהמשך.
  4. אם שרת ה-proxy ל-API נפרס בסביבה הספציפית, צריך לעבור לסיבה הבאה: הסביבה לא נטענה במעבדי הודעות.

רזולוציה

פורסים את שרת ה-proxy ל-API בסביבה הספציפית שבה אתם מתכוונים לשלוח בקשות API.

הסיבה: הסביבה לא נטענה במעבדי ההודעות

אבחון

  1. להתחבר לכל אחד ממעבדי ההודעות ולבדוק אם הסביבה הספציפית שבה אתם גורמים לבקשת ה-API נטענת במעבד ההודעות באמצעות הפקודה הבאה: 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
  2. אם הסביבה הספציפית מופיעה כחלק מהפקודה שלמעלה, עוברים לסיבה הבאה: שרת proxy ל-API לא נפרס במעבד הודעות אחד או יותר.
  3. אם הסביבה הספציפית לא מופיעה ברשימה, /opt/apigee/var/log/edge-message-processor/logs/system.log והקבוצה /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log ב- מעבדי הודעות לאיתור שגיאות במהלך טעינת סביבות.
  4. יכולות להיות שגיאות שונות רבות שעלולות לגרום לכשל בטעינת סביבה במעבד ההודעות. הפתרון תלוי בשגיאה שאירעה.

רזולוציה

יכול להיות שהסביבה לא נטענה במעבד ההודעות מסיבות רבות. הקטע הזה מתארת שתי סיבות אפשריות שיכולות להוביל לבעיה ומסבירות איך לפתור את הבעיה. הבעיה.

  1. אם מופיעה אחת מהשגיאות הבאות ביומן מעבד ההודעות, הסיבה לכך היא נמצאה בעיה באישורים/במפתחות שנוספו למאגר המפתחות/ב-Truststore שצוינו בסביבה שצוינה.

    שגיאה מס' 1: java.security.KeyStoreError: לא ניתן להחליף את האישור של עצמו

    2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na]
at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na]
…
Caused by: java.security.KeyStoreException: Cannot overwrite own certificate
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151]
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151]
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]

    ... 20 common frames omitted

    2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

    שגיאה מס' 2: Java.security.KeyStoreError: לא ניתן להחליף את המפתח הסודי

    2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
...
Caused by: java.security.KeyStoreException: Cannot overwrite secret key
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144]
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144]
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
... 20 common frames omitted

2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert
  2. מקבלים את הפרטים של מאגר המפתחות/האמינות שצוינו בהודעת השגיאה שמוצגת השלב הקודם באמצעות הקריאה הבאה ל-Management API: 
    curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user>

    פלט לדוגמה:

    {
   "certs":[
      "mycert",
      "mycert-new"
   ],
   "keys":[
      "mycert"
   ],
   "name":"myTruststore"
}
  3. הפלט לדוגמה מראה שיש שני אישורים ומפתח ב-Truststore myTruststore בדרך כלל ה-Truststore לא מכיל מפתח. אם כן, סביר להניח עדיף שיהיה אישור אחד ומפתח יחיד.
  4. לקבלת פרטים על שני האישורים באמצעות ממשק ה-API הבא: 
    curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
  5. בודקים את תאריך התפוגה של כל אחד מהאישורים ובודקים מהו התוקף של האישור הישן/פג התוקף יותר.
  6. מוחקים את האישור שתוקפו פג או לא רצוי מ-Truststore myTruststore.

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

הסיבה: שרת ה-proxy ל-API לא נפרסו במעבד הודעות אחד או יותר

אסור לפרוס את שרת ה-proxy של ה-API במעבד הודעות אחד או יותר. הבעיה הזו מתרחשת לעיתים רחוקות יותר והם מתרחשים בעיקר בגלל התראה על אירוע חסר משרת הניהול כדי מעבד הודעות במהלך הפריסה של שרת ה-proxy הספציפי ל-API. במקרה הזה גם: אין אפשרות ליצור את פעילות המעקב בממשק המשתמש של Edge.

אבחון

  1. להתחבר לכל אחד ממעבדי ההודעות ולבדוק אם הגרסה הספציפית של שרת ה-proxy ל-API נפרס או לא משתמש בפקודה הבאה: 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  2. אם הגרסה הספציפית של שרת ה-proxy ל-API לא מופיעה כפלט של הפקודה שצוינו בשלב 1 למעלה, ואז מפעילים מחדש את מעבד ההודעות הספציפי כמו שמוסבר רזולוציה.
  3. חוזרים על שלבים 1-2 לכל מעבדי ההודעות.
  4. אם הגרסה הספציפית של שרת ה-proxy ל-API פרוסה בכל מעבדי ההודעות, אז זו לא הסיבה לבעיה. המשך אל חובה לאסוף את פרטי האבחון.

רזולוציה

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

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

אבחון בעיות באמצעות API Monitoring

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

כדי לפתור את הבעיה הזו, אפשר להיכנס אל API Monitoring > לחקור את הדף בוחרים את התאריך המתאים, שרת proxy וכן הלאה, ויכול להיות שתראו את הפרטים הבאים:

קוד תקלה וקוד הסטטוס בממשק המשתמש

  • קוד התקלה: messaging.adaptors.http.flow.ApplicationNotFound
  • קוד סטטוס: 404
  • מקור התקלה: Apigee או MP

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

צפייה ביומנים

תרחיש לדוגמה מדגים איך פתרון בעיות של 5xx בממשקי ה-API באמצעות API Monitoring. לדוגמה, אפשר: אני רוצה להגדיר התראה ולקבל הודעה כשמספר קודי הסטטוס של 404 חורג מ- סף מסוים.

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

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

  1. אם אתם משתמשים בענן ציבורי, עליכם לספק את הפרטים הבאים:
    • שם הארגון
    • שם הסביבה
    • שם ה-Proxy ל-API
    • צריך להשלים את פקודת ה-curl כדי לשחזר את השגיאה
  2. אם אתם משתמשים בענן פרטי, עליכם לספק את הפרטים הבאים:
    • זוהתה הודעת שגיאה מלאה
    • שם הסביבה
    • חבילת proxy ל-API
    • יומני מעבד ההודעות: /opt/apigee/var/log/edge-message-processor/logs/system.log
    • פלט של הפקודות הבאות בכל אחד ממעבדי ההודעות. 
      • curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
      curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  3. פרטים על הקטעים במדריך הזה שניסית ועל תובנות אחרות יעזרו לנו למצוא פתרון מהיר לבעיה.