לא ניתן ליצור פעילות מעקב

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

תיאור הבעיה

המשתמש לא יכול ליצור סשן מעקב בממשק המשתמש של Edge.

הודעת שגיאה

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

Error creating trace session for API proxy <api proxy name>, revision <revision number>, environment <environment name>.
Failed to create DebugSession <session number>

צילום מסך של הודעת שגיאה לדוגמה שמופיעה בממשק המשתמש של Edge:

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

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

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

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

  1. מפעילים את ה-Management API הזה:

    curl -v <management-server-host>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/<revision-number>/debugsessions -u <user>

  2. אם מופיעות שגיאות, רושמים אותן לעצמכם. עוברים אל בעיה בקישוריות רשת.

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

הסיבה: בעיה בקישוריות הרשת

אבחון

  1. צריך לבדוק את היומן של שרת הניהול /opt/apigee/var/log/edge-management-server/logs/system.log ולראות אם יש שגיאות במהלך יצירת סשן המעקב או ניפוי הבאגים.

    שגיאה לדוגמה מהיומן של שרת הניהול

    2018-02-08 09:08:21,310 org:myorg env:uat  qtp1073741635-1074 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : createDebugSession : Unable to connect to the server with UUID cedeabd2-e4d1-40bb-8f18-d6afc8835e5b
org.apache.http.conn.HttpHostConnectException: Connect to 10.84.75.92:8082 [/10.84.75.92] failed: Connection refused
    at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:140) ~[httpclient-4.3.5.jar:4.3.5]
    at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:318) ~[httpclient-4.3.5.jar:4.3.5]
    at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) ~[httpclient-4.3.5.jar:4.3.5]
...<snipped>
Caused by: java.net.ConnectException: Connection refused
    at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_65]
    at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_65]
...<snipped>

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

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

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

  5. בדיקת הקישוריות משרת הניהול למעבד ההודעות ביציאה 8082 באמצעות השלבים הבאים:

    1. אם telnet זמין, משתמשים ב-telnet:

      telnet <MessageProcessor_IP> 8082

    2. אם telnet לא זמין, משתמשים ב-netcat כדי לבדוק את הקישוריות באופן הבא:

      nc -vz <MessageProcessor_IP> 8082

    3. אם מופיעה התשובה "החיבור נדחה" או 'תם פרק הזמן שהוקצב להתחברות', ואז עוברים לשלב הבא.

  6. מתחברים לכל אחד ממעבדי ההודעות באמצעות כתובת ה-IP המתאימה שבה הוצגה השגיאה ומבצעים את השלבים הבאים:

    1. בודקים אם מעבד ההודעות מאזין ביציאה 8082:

      netstat -an | grep LISTEN | grep 8082

    2. אם מעבד ההודעות מאזין ביציאה 8082, עוברים לשלב 7.

    3. אם מעבד ההודעות לא מאזין ביציאה 8082, יש להפעיל מחדש את מעבד ההודעות באמצעות הפקודה הבאה:

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

    4. ממתינים עד שמעבד ההודעות יתחיל להשתמש בפקודה הזו:

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

    5. אחרי שמעבד ההודעות פועל, בודקים שוב אם מעבד ההודעות מאזין ביציאה 8082.

    6. אם מעבד ההודעות מאזין ביציאה 8082, עוברים לשלב 7.

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

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

  9. משתמשים בפקודה מתאימה כדי לבדוק את הכללים של חומת האש. לדוגמה, אתם יכולים להריץ את הפקודה iptable כדי להציג רשימה של כל הכללים של חומת האש שהוגדרו במערכת:

    iptables -L -n

  10. אם לא הוגדרו כללי חומת אש ליציאה 8082, עוברים אל בעיה בשימוש במשאבים גבוהים.

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

רזולוציה

  1. צריך לעבוד עם מנהל הרשת כדי לאפשר תעבורת נתונים נכנסת/יוצאת ביציאה 8082 משרתים חיצוניים.

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

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

אבחון

  1. צריך לבדוק את היומנים של שרת הניהול /opt/apigee/var/log/edge-management-server/logs/system.log ולראות אם יש שגיאות במהלך יצירת סשן המעקב או ניפוי הבאגים.

  2. יכול להיות שתוצג הודעת שגיאה כמו "אין תשובות תקפות מ-MP(s)". במהלך יצירת מעקב או ניפוי באגים, כפי שמוצג בהמשך:

    2018-01-30 08:28:09,721 org:mynonprod env:uat  qtp2007599722-712162 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : no valid responses from MP(s), throwing error
2018-01-30 08:28:09,723 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - CustomJAXRSInvoker.performInvocation() : CustomJAXRSInvoker.performInvocation : Method com.apigee.distribution.DebugSessionAPI.createDebugSession threw an exception.
2018-01-30 08:28:09,724 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - ExceptionMapper.toResponse() : Error occurred : Failed to create DebugSession 1517297564678
2018-01-30 08:28:09,724 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - ExceptionMapper.toResponse() : Returning error response : ErrorResponse{errorCode = distribution.CreateDebugSessionFailed, errorMessage = Failed to create DebugSession 1517297564678}

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

  3. אם לא מופיעה שגיאה שדומה לזו שמוצגת בדוגמה שלמעלה, עוברים אל רשומות של מעבד הודעות לא פעיל.

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

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

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

    curl -s http://localhost:8082/v1/runtime/organizations/<org-name>/environments

    פלט לדוגמה:

    בפלט של הפקודה שלמעלה תוצג רשימת הסביבות ששייכות לארגון הספציפי שנטענות במעבד ההודעות. לדוגמה, אם הסביבות preprod ו-test נטענות במעבד ההודעות, הפלט יופיע כך:

    [ "preprod", "test" ]

  7. אם הסביבה הספציפית, אומרים "dev", שבה אתם מנסים ליצור פעילות של מעקב, רשומה כחלק מהפקודה שלמעלה, ואז עוברים אל Sold Message Processing.

  8. אם הסביבה הספציפית, למשל "dev", לא רשומה כחלק מהפקודה שלמעלה, יש לבדוק ב-/opt/apigee/var/log/edge-message-processor/logs/system.log וב-/opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log במעבדי ההודעות אם יש שגיאות במהלך הטעינה של Environments (סביבות).

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

רזולוציה

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

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

    שגיאה מס' 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. מוחקים את האישור שתוקפו פג או לא רצוי מהמאגר myTruststore.

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

הסיבה: לא ניתן לגשת למעבדי ההודעות או לרשומות לא פעילות של מעבד ההודעות

אבחון

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

  3. יכול להיות שתופיע הודעת שגיאה כמו "server <UUID> מוגדר כ'לא זמין' או 'לא נגיש' במהלך היצירה של סשן של מעקב או ניפוי באגים, כפי שמוצג בהמשך:

    2017-12-27 07:42:38,975 org:cocacola env:prod qtp2007599722-222063 INFO DISTRIBUTION - DebugSessionAPI.createDebugSession() : server 458b5910-2646-441c-a6e2-428b6d84e021 is either not up or reachable, skipping the server

    יכול להיות שאחרי השגיאה הזו תופיע עוד שגיאה אחת: "תם פרק הזמן שהוקצב להתחברות" לאחר זמן מה, כפי שמוצג בהמשך:

    2017-12-27 07:44:46.000 UTC org:cocacola env:prod qtp2007599722-222063 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : createDebugSession : Unable to connect to the server with UUID {}, skipping it458b5910-2646-441c-a6e2-428b6d84e021 org.apache.http.conn.HttpHostConnectException: Connect to 192.168.101.7:8080 [/192.168.101.7] failed: Connection timed out (Connection timed out) at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:140) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:318) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219) ~[httpclient-4.3.5.jar:4.3.5] 
…<snipped>
Caused by: java.net.ConnectException: Connection timed out (Connection timed out) at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_144] at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_144]
…<snipped>

  4. שתי השגיאות האלה עשויות להיגרם בגלל מעבדי הודעות ספציפיים:

    1. לא פעיל (כבר לא קיים)
    2. המכשיר לא זמין/לא זמין מסיבה כלשהי

  5. יש לפעול לפי הפתרון המתאים בהתאם לתרחיש שבו נתקלת.

רזולוציה

תרחיש מס' 1 : מעבדי ההודעות לא פעילים (לא קיימים)

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

    curl -u <sysadmin> "http://<management-server-host>:8080/v1/servers?pod=<podName>&regions=<regionName>"

  2. רושמים בצד את כתובת ה-IP או את שם המארח שתואמים למזהה הייחודי (UUID) של מעבדי ההודעות שצוינו בהודעת השגיאה ביומנים של שרתי הניהול (שלב מס' 3 בקטע 'אבחון'). אפשר לבדוק אם אלה מעבדי הודעות תקינים באחת מהדרכים הבאות:

    1. תרשים ההגדרה האחרון של הטופולוגיה של הענן הפרטי
    2. כתובת ה-IP האחרונה של שרת Edge – טבלת המיפוי של שם המארח

    אם לדעתך הם נחשבים למעבדי הודעות תקינים, אפשר לעבור לשלב תרחיש 2 : אין גישה למעבדי הודעות.

  3. מוחקים את מעבדי ההודעות הלא פעילים (לא קיימים) באמצעות ממשקי ה-API הבאים לניהול:

    1. ביטול הרישום של מעבד ההודעות מהסביבות של הארגון: 

      curl -X POST http://<management-server-host>:8080/v1/o/<orgName>/e/<envName>/servers -d "uuid={uuid}&region=<regionName>&pod=<podName}&action=remove"

    2. ביטול הרישום של סוג השרת: 

      curl http://<management-server-host>:8080/v1/servers -X POST -d "type={message-processor}&region=<regionName>&pod=<podName>&uuid=<uuid>&action=remove"

    3. מוחקים את השרת: 

      curl http://<management-ip>:8080/v1/servers/<uuid> -X DELETE

  4. אם אתם נתקלים באותה בעיה בסביבות אחרות בארגון, חוזרים על שלב 3.

תרחיש 2: אין גישה למעבדי ההודעות

  1. התחברות לכל אחד ממעבדי ההודעות באמצעות קביעת כתובות ה-IP או שמות המארחים על סמך מזהי ה-UUID שתועדו בהודעת השגיאה ביומנים של שרתי הניהול.

  2. מפעילים מחדש את מעבד ההודעות:

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

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

הסיבה: בעיה בשימוש בנפח גדול של משאבים

אבחון

  1. מתחברים לכל אחד ממעבדי ההודעות ובודקים אם נעשה שימוש גבוה במשאבים – מעבד(CPU), זיכרון או עומס. אפשר להשתמש בפקודה top במערכות הפעלה מבוססות Unix כדי לקבל את פרטי השימוש במשאבים של תהליך מעבד ההודעות:

    top

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

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

    1. אם מעבד הודעות מסוים חווה שימוש גבוה במעבד (CPU), יש ליצור שלוש תמונות של שרשורים כל 30 שניות באמצעות הפקודה הבאה:

      sudo <JAVA_HOME>/bin/jstack -l <pid> > <filename>

    2. אם מעבד הודעות כלשהו משתמש בזיכרון רב, יש ליצור Dump של ערימה באמצעות הפקודה הבאה:

      sudo -u apigee <JAVA_HOME>/bin/jmap -dump:live,format=b,file=<filename> <pid>

    3. מעבר לרזולוציה.

רזולוציה

  1. מפעילים מחדש את מעבד ההודעות באמצעות הפקודה הבאה. הפעולה הזו אמורה לצמצם את השימוש במעבד (CPU) ובזיכרון:

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

  2. עוקבים אחרי הקריאות ל-API ומוודאים שהבעיה עדיין קיימת.

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

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

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

אבחון

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

    curl -v localhost:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions

    פלט לדוגמה:

    רשימת התיקונים תופיע כפלט של הפקודה שלמעלה. לדוגמה, אם גרסה 12 פרוסה, הפלט יופיע כך:

    [ "12" ]

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

  3. חוזרים על השלבים 1-2 לכל מעבדי ההודעות.

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

רזולוציה

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

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

הסיבה: בעיה בממשק המשתמש של Edge

אבחון

  1. צריך לבדוק את היומנים של ממשק המשתמש של Edge /opt/apigee/var/log/edge-ui/application.log ו-/opt/apigee/var/log/edge-ui/edge-ui.log כדי לראות אם יש שגיאות.
  2. צריך לפנות לתמיכה של Apigee Edge ולשתף את הקבצים האלה לבדיקה נוספת.

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

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

  1. הפלט של הפקודה:

    curl -v <management-server-host>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/<revision-number>/debugsessions -u <user>

  2. יומן של שרת הניהול 

    /opt/apigee/var/log/edge-management-server/logs/system.log.

  3. יומני מעבד ההודעות

    /opt/apigee/var/log/edge-message-processor/logs/system.log.

  4. פלט פקודות telnet/nc משרת ניהול למעבד הודעות:

    telnet <MessageProcessor_IP> 8082
nc -vz <MessageProcessor_IP> 8082

  5. פלט של פקודת netstat הבאה במעבדי ההודעות:

    netstat -an > netstat.txt

  6. אם זוהתה בעיה בממשק המשתמש של Edge, צריך לספק את יומני ממשק המשתמש של Edge: /opt/apigee/var/log/edge-ui/application.log ו-/opt/apigee/var/log/edge-ui/edge-ui.log.

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