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

במאמר הזה מוסבר איך לפתור בעיות במעבד ההודעות. מעבד ההודעות הוא חלק מהרכיב 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 /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 -c synchronizer

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

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

  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 -c synchronizer

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

תיאור הבעיה

תאי ה-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. מריצים את הפקודה הבאה כדי להעביר ליציאה 8843. כך תוכלו לקרוא ל-API בתרמיל: 
    kubectl port-forward -n namespace apigee-runtime-pod-name 8843:8843
  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"
    }
  }
} ]

שימוש במצב DEBUG

כדי לעזור בפתרון בעיות, אפשר להפעיל את מצב DEBUG כדי לכלול מידע מפורט יותר ביומני ה-pod‏ apigee-runtime.

  1. מציגים את רשימת ה-pods במרחב השמות: 
    kubectl get pods -n namespace
  2. בוחרים אחד מהפודים ברשימה apigee-runtime לניפוי באגים.
  3. מריצים את פקודת העברה ליציאה אחרת בשביל הפוד הזה. לדוגמה: 
    kubectl port-forward -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd 8843
  4. פותחים טרמינל נוסף ומפעילים את ה-API הבא כדי להפעיל את ניפוי הבאגים: 
    curl "https://0:8843/v1/logsessions?sessions=debug" -X POST -v -k
  5. מריצים את הפקודה kubectl logs כדי לבדוק את היומן במצב ניפוי באגים. לדוגמה: 
    kubectl logs -f -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd
  6. אחרי שמסיימים לבדוק את יומן ניפוי הבאגים, מאפסים את רמת היומן ל-INFO (ברירת המחדל). לדוגמה: 
    curl "https://0:8843/v1/logsessions?sessions=info" -X POST -v -k
  7. מריצים את הפקודה kubectl logs כדי לוודא שהיומן חזר למצב INFO.