מדריך לפתרון בעיות שקשורות למעבד הודעות

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

בדיקת המוכנות נכשלת עם קוד סטטוס HTTP‏ 500

תיאור הבעיה

אחד או יותר מפודי apigee-runtime לא נמצאים במצב Ready.

הודעת השגיאה

כשמשתמשים ב-kubectl כדי לתאר פוד apigee-runtime שנכשל, מוצגת השגיאה:

Readiness probe failed: HTTP probe failed with statuscode: 500

לדוגמה:

kubectl describe pod -n hybrid \
apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7

...
apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7  Readiness probe failed: HTTP probe
failed with statuscode: 500
...

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

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

מטרה תיאור
בעיה בחיבור בין כלי הסנכרון לבין מישור הניהול הכלי לסנכרון לא מצליח להתחבר למישור הניהול. הבעיה הזו בדרך כלל נגרמת במקרים שבהם מבטלים את כתובת ה-URL של contractProvider ומשייכים אליה חשבון שירות שגוי. לדוגמה, אם מגדירים חשבון שירות לפריסת ביניים עם כתובת URL‏ contractProvider שמפנה לשרת הייצור.
בעיה בחיבור בין מעבד ההודעות לבין הכלי לסנכרון אם ה-MP החדש מופיע כחלק מהגדלה אוטומטית או מהפעלה מחדש של ה-pod, יכול להיות שתראו את השגיאה הזו. בדרך כלל הבעיה הזו מתרחשת כשהכלי לסנכרון לא פועל וה-MP לא הצליח לטעון את החוזה שלו.

אבחון: בעיה בחיבור בין כלי הסנכרון לבין מישור הניהול

כדי לאבחן בעיה בחיבור בין כלי הסנכרון לבין מישור הניהול:

  1. מציגים ברשימה את ה-Pods באשכול: 
    kubectl get pods -n namespace
  2. פותחים מעטפת ב-pod‏ apigee-synchronizer: 
    kubectl exec -it -n namespace synchronizer-pod-name bash

    לדוגמה:

    kubectl exec -it -n apigee apigee-synchronizer-apigee-gcp-prod1-test-blue-cnj5x bash
  3. עוברים לספרייה הבאה: 
    cd /application/opt/apigee/var/log/apigee-synchronizer
ls

  dr-xr-sr-x 4 apigee apigee  4096 Sep 12 16:52 750
  drwxr-sr-x 2 apigee apigee  4096 Sep 12 16:52 cachedFiles
  -rw-r--r-- 1 apigee apigee 22295 Sep 12 16:52 config.log
  -rw-r--r-- 1 apigee apigee    76 Sep 12 16:52 versions.properties
  4. בודקים את הגרסה הפעילה בversion.properties. לדוגמה: 
    cat versions.properties

  #active repository version
  #Sat Dec 14 19:45:00 GMT 2019
  active.version=749
  5. חשוב לוודא שהערך של active.version זהה למספר של תיקיית החוזים. בדוגמה שלמעלה (שמוצגת גם בהמשך), שם התיקייה הוא 750, ולכן הם לא זהים: 
    dr-xr-sr-x 4 apigee apigee  4096 Sep 12 16:52 750
  6. יוצאים מהמעטפת של ה-Pod.

רזולוציה

אם הקובץ version.properties חסר, או אם יש אי התאמה בין הגרסאות כמו שמוסבר למעלה, כדאי לבדוק את יומני הסנכרון כדי לנסות להבין למה החוזים העדכניים ביותר לא מורדים. לדוגמה:

kubectl logs -f -n namespace synchronizer-pod-name

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

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name

אבחון: בעיה בחיבור בין מעבד ההודעות לבין הכלי לסנכרון

כדי לאבחן בעיה בחיבור בין מעבד ההודעות לבין הכלי לסנכרון:

  1. מציגים ברשימה את ה-Pods באשכול: 
    kubectl get pods -n namespace
  2. כדאי לבדוק את יומני זמן הריצה כדי לנסות להבין למה החוזים לא מורדים: 
    kubectl logs -f -n namespace pod-name

    לדוגמה:

    kubectl logs -f -n apigee apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7

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

    2019-09-13 16:59:24,331 podName:N/A ipAddress:N/A dpColor:N/A
HttpClient@331886186-301 DEBUG o.e.j.c.AbstractConnectionPool - AbstractConnectionPool$1.failed() :
Connection 1/64 creation failed
java.net.UnknownHostException: apigee-synchronizer-apigee-gcp-prod1-test.hybrid.svc.cluster.local
at java.net.InetAddress.getAllByName0(InetAddress.java:1281)
at java.net.InetAddress.getAllByName(InetAddress.java:1193)
at java.net.InetAddress.getAllByName(InetAddress.java:1127)
at org.eclipse.jetty.util.SocketAddressResolver$Async.lambda$resolve$1(SocketAddressResolver.java:167)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
at java.lang.Thread.run(Thread.java:748)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
	at java.lang.Thread.run(Thread.java:748)

רזולוציה

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

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name

בדיקת המוכנות נכשלת בגלל מפתח הצפנה לא תקין

תיאור הבעיה

תאי ה-apigee-runtime לא במצב Ready.

אבחון

כשמשתמשים ב-kubectl כדי לתאר פוד apigee-runtime שנכשל, מוצגת השגיאה Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed. לדוגמה: 

$ kubectl describe pod -n namespace apigee-runtime-pod-name

...
Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed due to
com.apigee.probe.model.ProbeFailedException{ code = hybrid.encryption.key.InvalidEncryptionKey,
message = Invalid encryption key. Please check the length of the encryption key, associated
contexts = []}
...

רזולוציה

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

צפייה ביומנים של מעבד ההודעות

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

קריאה ל-proxy ל-API מ-Pod של זמן ריצה

במקרים מסוימים, כדי לעזור בבידוד בעיה, כדאי לבדוק אם אפשר לבצע קריאה של proxy ל-API ישירות מתוך Pod apigee-runtime, וכך לעקוף את שער הכניסה.

  1. מריצים את הפקודה הבאה כדי להעביר את התנועה ליציאה 8443. כך תוכלו לקרוא ל-API בתרמיל: 
    kubectl port-forward -n namespace apigee-runtime-pod-name 8443:8443
  2. שליחת קריאה ל-proxy ל-API שנפרס. לדוגמה, אם נתיב הבסיס של ה-proxy הוא ilove-apis: 
    curl -k -v https://0:8443//ilove-apis

    < HTTP/1.1 200 OK
    < X-Powered-By: Apigee
    < Access-Control-Allow-Origin: *
    < X-Frame-Options: ALLOW-FROM RESOURCE-URL
    < X-XSS-Protection: 1
    < X-Content-Type-Options: nosniff
    < Content-Type: text/html; charset=utf-8
    < Content-Length: 18
    < ETag: W/"12-Jb9QP1bUxNSmZkxQGt5KLQ"
    < Date: Fri, 13 Sep 2019 18:33:46 GMT
    < Via: 1.1 google
    < X-Apigee.Message-ID: 016f5f7f-c59e-404c-86e8-7b0737833f982
    < X-Apigee.dp.color: blue
    < X-Apigee.proxy: /organizations/my-org/environments/test/apiproxies/i-loveapis/revisions/1
    < X-Apigee.proxy.basepath: /ilove-apis
    < X-Apigee.target-latency: 9
    <
    * Connection #0 to host 0 left intact
    <H2>I <3 APIs

בדיקת ה-Management API

כדי לבדוק אם ה-Management API פועל כמו שצריך, אפשר להשתמש ב-API שמתואר בהמשך.

  1. מקבלים את השמות של ה-pods באשכול: 
    kubectl get pods -n namespace
  2. משתמשים בהעברת פורטים כדי לקבל גישה ל-pod‏ apigee-runtime. התחביר של העברה ליציאה אחרת הוא: 
    kubectl port-forward -n namespace podname 8843:8843

    לדוגמה:

    kubectl port-forward -n apigee \
    apigee-runtime-my-organization-test-blue-57965b7789-6j4bp 8843:8843
  3. אחר כך, בחלון מסוף אחר, משתמשים בכלי כמו curl כדי לשלוח בקשה ל-classification/tree API, כמו בדוגמה הבאה: 
    curl -k https://0:8843/v1/classification/tree

    זוהי דוגמה לתשובה, שבה מפורט מידע על שרתי ה-proxy שנפרסו בסביבת הבדיקה:

    [ {
  "condition" : "(always matches)",
  "virtualHost" : {
    "env" : "test",
    "name" : "default",
    "org" : "my-organization",
    "tree" : {
      "elements" : [ {
        "application" : "myproxy",
        "basePath" : "/myproxy",
        "name" : "default",
        "revision" : "1"
      } ],
      "name" : "IdentificationTree"
    }
  }
} ]

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

כדי לעזור בפתרון בעיות, אפשר ליצור סשן של יומן כדי ליצור פלט מפורט של יומן עבור תרמילי apigee-runtime.

יצירת סשן של יומן

כדי ליצור סשן של יומן עבור פוד של זמן ריצה:

  1. מציגים את הפודים של זמן הריצה. כברירת מחדל, הם נמצאים במרחב השמות apigee. אם בחרתם מרחב שמות אחר, השתמשו בו במקום זאת: 
    kubectl get pods -n apigee
  2. בוחרים אחד מה-Pods שמופיעים ברשימה כדי לנפות באגים.apigee-runtime
  3. יוצרים סשן של יומן ב-pod של זמן הריצה שרוצים לפתור בו בעיות באמצעות API‏ /logsessions. פרטים על ה-API זמינים במאמר מידע על logsessions API. 
    kubectl exec -it RUNTIME_POD_NAME -n apigee \
  -- curl "https://0:8843/v1/logsessions?loggerNames=ALL&level=FINE&timeout=60000" -k -X POST -v

    לדוגמה:

    kubectl exec -it apigee-runtime-hybrid-18-01232-dev-d27ca57-190rc6-3klyg-lc7h5 -n apigee \
  -- curl "https://0:8843/v1/logsessions?loggerNames=ALL&level=FINE&timeout=60000" -k -X POST -v

    התגובה היא מזהה סשן של יומן. לדוגמה: 9f831a7d-e533-4ead-8e58-12ec1059a622

  4. מדפיסים את היומנים: 
    kubectl logs -f -n apigee RUNTIME_POD_NAME

רשימת סשנים ביומן

כדי לקבל רשימה של כל סשני היומן הפעילים עבור פוד של זמן ריצה:

kubectl exec -it RUNTIME_POD_NAME -n apigee \
  -- curl "https://0:8843/v1/logsessions" -k -v

קבלת יומן פעילות

כדי לראות את פרטי הסשן ביומן:

kubectl exec -it RUNTIME_POD_NAME -n apigee \
  -- curl "https://0:8843/v1/logsessions/LOG_SESSION_ID" -k -v

סיום של סשן ביומן

כדי לסיים סשן של יומן:

kubectl exec -it RUNTIME_POD_NAME -n apigee \
    -- curl "https://0:8843/v1/logsessions/LOG_SESSION_ID" -k -X DELETE -v

מידע על logsessions API

בקטע הזה מתוארים פרמטרים של שאילתות ב-logsessions API:

  • ‫loggerNames: מציין את סוג פלט היומן שיוצג. ערכים אפשריים: כוללים CONTRACT_REPLICATION, DEBUG.SESSION או ALL
  • ‫level: מציינת את רמת הפלט של היומן. ערכים אפשריים כוללים FINEST, ‏ FINER, ‏ FINE, ‏ INFO, SEVERE, ‏ ALL.
  • ‫timeout: מציין את משך הזמן שבו יפעל סשן היומן ברמת היומן שצוינה. לאחר זמן קצוב לתפוגה, רמת הרישום ביומן חוזרת ל-INFO.

אם הפעולה מצליחה, ה-API מחזיר מזהה סשן עבור סשן היומן.