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

אתם צופים במסמכי התיעוד של 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 Private Cloud
הסביבה לא נטענה במעבד ההודעות סביבה ספציפית (שבה מנסים להפעיל את המעקב) לא נטענה במעבד ההודעות עקב שגיאה.
Stale Message Processor Entries לשרת הניהול יש הפניה למעבדי בקשות לא קיימים (לא פעילים).
אי אפשר להגיע למעבד ההודעות מעבד ההודעות הופסק או שאי אפשר להגיע אליו.
בעיה של ניצול גבוה של משאבים מעבדי ההודעות (Message Processor) חווים ניצול גבוה של משאבים (CPU, זיכרון או עומס).
שרת proxy ל-API לא נפרס במעבד הודעות אחד או יותר יכול להיות ש-proxy ל-API לא נפרס במעבד בקשות אחד או יותר בגלל שחסרה התראה לגבי אירוע במהלך ה-Deployment (פריסה).
בעיה בממשק המשתמש של Edge ממשק המשתמש של Edge לא יכול ליצור סשן של מעקב בגלל שגיאה כלשהי.

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

  1. מריצים את ה-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. אחרי שה-Message Processor יפעל, בודקים שוב אם הוא מאזין ליציאה 8082.

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

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

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

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

    iptables -L -n

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

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

רזולוציה

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

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

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

אבחון

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

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

    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. אם לא מופיעה שגיאה דומה לזו שמוצגת בדוגמה שלמעלה, עוברים אל Stale Message Processor Entries.

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

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

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

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

    פלט לדוגמה:

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

    [ "preprod", "test" ]

  7. אם הסביבה הספציפית, למשל dev, שבה אתם מנסים ליצור סשן של מעקב, מופיעה כחלק מהפקודה שלמעלה, צריך לעבור אל Stale Message Processor Entries.

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

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

רזולוציה

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

  1. אם אחת מהשגיאות הבאות מופיעה ביומן של Message Processor, הבעיה היא באישורים או במפתחות שנוספו למאגר המפתחות או למאגר האישורים שצוינו בסביבה שצוינה.

    שגיאה מספר 1: java.security.KeyStoreException: Cannot overwrite own certificate

    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.KeyStoreException: Cannot overwrite secret key

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

  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. מעבדי ההודעות מגיעים לשימוש גבוה בזיכרון או במעבד
  2. בודקים את היומנים של שרת הניהול /opt/apigee/var/log/edge-management-server/logs/system.log כדי לראות אם יש שגיאות במהלך יצירת סשן של מעקב או ניפוי באגים.

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

    top

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

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

    1. אם יש מעבד הודעות שחווה שימוש גבוה במעבד, צריך ליצור שלושה thread dumps כל 30 שניות באמצעות הפקודה הבאה:

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

    2. אם יש מעבד הודעות עם שימוש גבוה בזיכרון, צריך ליצור heap 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 וספקו את ה-thread dumps, את ה-heap dump ואת היומנים של Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) כדי שהתמיכה תוכל לחקור את הסיבה לשימוש הגבוה במעבד או בזיכרון.

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

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

אבחון

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

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

    פלט לדוגמה:

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

    [ "12" ]

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

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

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

רזולוציה

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

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

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

אבחון

  1. בודקים את היומנים של Edge UI‏ /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. פרטים על החלקים ב-Playbook שניסית, ותובנות אחרות שיעזרו לנו לפתור את הבעיה במהירות.