‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

פתרון בעיות

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

שגיאת Istio 404 (לא נמצא)

ניפוי באגים של שגיאה 404 (לא נמצא) ב-Istio יכול להיות מתסכל. מקווים שהמידע הזה יעזור לכם להתחיל לאתר את הבעיות.

התנגשות בשער עם תווים כלליים

יכולה להיות רק הגדרת שער אחת שמשתמשת בערך מארחים של תו כללי לחיפוש '*'. אם פרסתם משהו אחר שכולל שער עם תו כללי, שיחות של לקוחות ייכשלו עם סטטוס 404.

דוגמה:

$ istioctl get gateways
GATEWAY NAME         HOSTS     NAMESPACE   AGE
bookinfo-gateway     *         default     20s
httpbin-gateway      *         default     3s

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

מעקב אחר הנקודה שבה המסלול נכשל

‫Istio הוא כמו בצל (או אולי כמו ענק), יש לו שכבות. דרך שיטתית לניפוי באגים של שגיאה 404 היא להתחיל מהיעד ולעבוד החוצה.

עומס העבודה של הקצה העורפי

מוודאים שיש לכם גישה לעומס העבודה מה-sidecar:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl localhost:80/headers

ה-sidecar של הקצה העורפי

מגדירים את כתובת השירות ומקבלים את כתובת ה-IP של ה-pod של עומס העבודה.

SERVICE=httpbin.default.svc.cluster.local:80
  POD_IP=$(kubectl get pod $WORKLOAD_POD -o jsonpath='{.status.podIP}')

גישה לעומס העבודה דרך ה-sidecar:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v http://$SERVICE/headers --resolve "$SERVICE:$POD_IP"

או אם מופעל mTLS של Istio:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v https://$SERVICE/headers --resolve "$SERVICE:$POD_IP" --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --insecure

השער (או קובץ עזר של קצה קדמי)

כדי לגשת לשירות מהשער:

kubectl -n istio-system exec $GATEWAY_POD -- curl -v http://$SERVICE/header

או אם מופעל mTLS של Istio:

kubectl -n istio-system exec $GATEWAY_POD -- curl -v https://$SERVICE/headers --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --insecure

חסרים נתונים של Analytics

אם אתם לא רואים ניתוח נתונים בממשק המשתמש של Analytics, כדאי לבדוק את הסיבות האפשריות הבאות:

יכול להיות שיהיה עיכוב של כמה דקות בקליטת הנתונים ב-Apigee
יומן הגישה של Envoy gRPC לא הוגדר כמו שצריך
‫Envoy לא יכול לגשת לשירות מרוחק
העלאה של שירות מרוחק נכשלת

מפתח API חסר או לא תקין לא נדחה

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

שרת proxy ישיר

בודקים את ההגדרות של ext-authz.

Sidecar

מוודאים שהמאזין מוגדר ליירוט.
בודקים את ההגדרות של ext-authz.

בקשות לא חוקיות נבדקות ומאושרות

שירות מרוחק שהוגדר לפתיחה במקרה של כשל
‫Envoy לא מוגדר לבדיקות RBAC

מידע על פתרון הבעיות האלה מופיע בנושא External Authorization במסמכי התיעוד של Envoy, וגם במידע על המאפיין failure_mode_allow. המאפיין הזה מאפשר לשנות את אופן הפעולה של המסנן במקרה של שגיאות.

חסר JWT או שהוא לא תקין, והמערכת לא דוחה אותו

הסיבה הסבירה היא שמסנן ה-JWT של Envoy לא מוגדר.

מפתח API תקין נכשל

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

‫Envoy לא יכול לגשת לשירות המרוחק
פרטי הכניסה לא תקינים
מוצר API של Apigee לא מוגדר לטירגוט ולסביבה

שלבים לפתרון בעיות

בדיקת מוצר ה-API ב-Apigee

האם הוא מופעל בסביבה שלכם (בדיקה לעומת ייצור)?
המוצר צריך להיות מקושר לאותה סביבה של השירות המרוחק.
האם הוא משויך ליעד שאליו אתם ניגשים?
בודקים את הקטע יעדים של שירותים מרוחקים ב-Apigee. חשוב לזכור: שם השירות צריך להיות שם מארח שמוגדר במלואו. אם מדובר בשירות Istio, השם יהיה משהו כמו helloworld.default.svc.cluster.localcode> – שמייצג את השירות helloworld במרחב השמות default.
האם נתיב המשאב תואם לבקשה שלך?
חשוב לזכור שנתיב כמו / או /** יתאים לכל נתיב. אפשר גם להשתמש בתווים הכלליים '*' או '**' כדי להתאים.
יש לך אפליקציה למפתחים?
כדי לבדוק את המפתחות של מוצר API, צריך לקשר אותו לאפליקציה למפתחים.

בדיקת הבקשה

האם אתם מעבירים את מפתח הצרכן ב-x-api-key header
דוגמה:
```
curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
```
האם אתם משתמשים במפתח צרכן טוב?
חשוב לוודא שהאישורים מהאפליקציה שבה אתם משתמשים אושרו למוצר ה-API שלכם.

בדיקת היומנים של השירות המרוחק

מפעילים את השירות מרחוק עם רישום ביומן ב-debug level. מידע נוסף זמין במאמר בנושא הגדרת רמות של יומני שירות מרחוק.
משתמשים באפשרות -l debug בשורת הפקודה. לדוגמה:
```
apigee-remote-service-envoy -l debug
```

ניסיון לגשת ליעד ובדיקת היומנים

בודקים ביומנים אם יש שורה שנראית בערך כך:

Resolve api: helloworld.default.svc.cluster.local, path: /hello, scopes: []
Selected: [helloworld]
Eliminated: [helloworld2 doesn't match path: /hello]

הגדרת רמות של יומנים בשירותים מרחוק

באמצעות דגל בשורת הפקודה, אפשר להפעיל את השירות המרוחק באחד ממצבי הניפוי הבאים, לפי רמת הפירוט, כאשר debug הוא המפורט ביותר ו-error הוא הכי פחות מפורט:

‫debug – מצב הרישום המפורט ביותר ביומן.
‫info – ברירת המחדל.
warn
‫error – מצב הרישום הכי פחות מפורט ביומן.

לדוגמה, כדי להתחיל את השירות ברמה debug:

apigee-remote-service-envoy -l debug