בקטעים הבאים מתוארות הבעיות הידועות ב-Apigee Edge. ברוב המקרים, הבעיות שצוינו יתוקנו בגרסה עתידית.
בעיות ידועות של Edge
בקטעים הבאים מתוארות בעיות ידועות שונות ב-Edge.
אזור
בעיות ידועות
תוקף המטמון גורם לערך cachehit שגוי
כאשר משתמשים במשתנה הזרימה cachehit אחרי המדיניות LookupCache, עקב האופן שבו נקודות ניפוי הבאגים נשלחות להתנהגות אסינכרונית, LookupPolicy מאכלס את האובייקט DebugInfo לפני ביצוע הקריאה החוזרת, וכתוצאה מכך מתקבלת שגיאה.
פתרון אפשרי: יש לחזור על התהליך (ביצוע שיחה שנייה) שוב מיד לאחר השיחה הראשונה.
הגדרת מדיניות InvalidateCache
PurgeChildEntries כ-true לא פועלת כראוי
אם מגדירים את השדה PurgeChildEntries במדיניות InvalidateCache, רק ערכי הרכיב KeyFragment יימחקו לצמיתות, אבל יימחקו מהמטמון כולו.
בקטעים הבאים מתוארות הבעיות הידועות בממשק המשתמש של Edge.
אזור
בעיות ידועות
לא ניתן לגשת לדף 'ניהול אזור SSO של Edge' מסרגל הניווט אחרי שהארגון ממופה לאזור זהות
כשמחברים ארגון לאזור זהות, אי אפשר יותר לגשת לדף 'ניהול אזור SSO ב-Edge' מסרגל הניווט הימני על ידי בחירה באפשרות 'אדמין' > 'SSO'. כדי לעקוף את הבעיה, תוכלו לעבור ישירות לדף באמצעות כתובת ה-URL הבאה: https://apigee.com/sso
בעיות ידועות בפורטל המשולב
בקטעים הבאים מתוארות הבעיות הידועות בפורטל המשולב.
לדוגמה, התכונות הבאות מ-OpenAPI Specification 3.0 עדיין לא נתמכות:
allOf מאפיינים לשילוב ולהרחבה של סכימות
הפניות מרחוק
אם במפרט OpenAPI יש הפניה לתכונה שאינה נתמכת, במקרים מסוימים הכלים יתעלמו מהתכונה אבל עדיין
יעבדו את התיעוד של הפניית ה-API. במקרים אחרים, תכונה שאינה נתמכת תגרום לשגיאות שימנעו עיבוד מוצלח של תיעוד העזר ל-API. בכל מקרה, יהיה עליך לשנות את המפרט של OpenAPI כדי להימנע משימוש בתכונה
שאינה נתמכת עד שתהיה בה תמיכה בגרסה עתידית.
הערה: עורך המפרט פחות מגביל מ-SmartDocs בעיבוד תיעוד של הפניות API, ולכן התוצאות עשויות להיות שונות בין הכלים.
כשמשתמשים ב-API הזה בפורטל, הכותרת Accept מוגדרת ל-application/json ללא קשר לערך שהוגדר עבור consumes במפרט OpenAPI.
ספק זהויות ב-SAML
בדומיינים מותאמים אישית אין תמיכה בהתנתקות יחידה (SLO) עם ספק הזהויות של SAML. כדי להפעיל דומיין מותאם אישית עם ספק זהויות של SAML, צריך להשאיר את השדה כתובת URL ליציאה ריק
כשקובעים את ההגדרות של SAML.
מנהל הפורטל
כרגע אין תמיכה בעדכונים של הפורטל בו-זמנית (למשל: שינויים בדף, בעיצוב, ב-CSS או בסקריפטים) על ידי כמה משתמשים.
אם מוחקים מהפורטל דף תיעוד של קובצי עזר של API, לא ניתן ליצור אותו מחדש. צריך למחוק את המוצר ולהוסיף אותו מחדש
וליצור מחדש את מסמכי התיעוד ל-API.
בקטעים הבאים מתוארות הבעיות הידועות של Edge לענן פרטי.
אזור
בעיות ידועות
נקודת חולשה ב-Apigee HTTP/2
לאחרונה התגלתה נקודת חולשה של התקפת מניעת שירות (DoS) במספר הטמעות של פרוטוקול HTTP/2 (CVE-2023-44487), כולל ב-Apigee Edge לענן פרטי. נקודת החולשה עלולה להוביל לפונקציונליות ניהול של DoS of Apigee API.
לפרטים נוספים, אפשר לקרוא את עדכון האבטחה הדחוף של Apigee GCP-2023-032.
רכיבי הנתב של Edge for Private Cloud ושרת הניהול חשופים לאינטרנט ועלולים להיות פגיעים. HTTP/2 מופעל ביציאת הניהול של רכיבים אחרים שספציפיים ל-Edge של הענן הפרטי, אבל אף אחד מהרכיבים האלה לא חשוף לאינטרנט. ברכיבים שאינם מסוג Edge, כמו Cassandra, Zookeeper ואחרים,
HTTP/2 לא מופעל. אנחנו ממליצים לבצע את הפעולות הבאות כדי לטפל בנקודת החולשה של Edge בענן פרטי:
apigee-mirror לא פועל ב-Red Hat Enterprise Linux (RHEL) 8.0.
פתרון אפשרי:
כפתרון עקיף, אפשר להתקין את apigee-mirror בשרת שבו פועלת גרסה נמוכה יותר של RHEL או
מערכת הפעלה נתמכת אחרת עבור Apigee. לאחר מכן ניתן להשתמש במראה כדי להוסיף חבילות, גם אם התקנת את Apigee בשרתי RHEL 8.0.
מדיניות LDAP
149245401: ההגדרות של מאגר חיבורי LDAP עבור JNDI שהוגדרו באמצעות משאב LDAP לא משתקפות, וברירות המחדל של JNDI גורמות לחיבורים לשימוש יחיד בכל פעם.
כתוצאה מכך, חיבורים נפתחים ונסגרים בכל פעם לשימוש יחיד, ויוצרים מספר גדול של חיבורים בשעה לשרת ה-LDAP.
פתרון אפשרי:
כדי לשנות את המאפיינים של מאגר חיבורי LDAP, צריך לבצע את
השלבים הבאים להגדרת שינוי גלובלי בכל כללי המדיניות של LDAP.
יוצרים קובץ מאפיינים של הגדרות אישיות אם הוא עדיין לא קיים:
צריך לוודא שהקובץ /opt/apigee/customer/application/message-processor.properties נמצא בבעלות apigee:apigee.
מפעילים מחדש כל מעבד הודעות.
כדי לוודא שנכסי ה-JNDI של מאגר החיבורים נכנסים לתוקף, אפשר
לבצע tcpdump כדי לבחון את ההתנהגות של מאגר החיבורים של LDAP
לאורך זמן.
זמן אחזור לעיבוד של הבקשות הגבוהות
139051927: זמני אחזור גבוהים לעיבוד של שרתי proxy שנמצאים במעבד ההודעות
משפיעים על כל שרתי ה-proxy של ה-API. התסמינים כוללים עיכובים של 200 עד 300 אלפיות השנייה בזמני העיבוד במשך זמן התגובה הרגיל של ה-API, והם יכולים להתרחש באופן אקראי גם עם TPS נמוך. מצב כזה יכול להתרחש כשיש יותר מ-50 שרתי יעד שבהם מעבד הודעות יוצר חיבורים.
שורש הבעיה: מעבדי הודעות שומרים מטמון שממפה את כתובת ה-URL של שרת היעד לאובייקט HTTPClient עבור חיבורים יוצאים אל השרתים. כברירת מחדל, ההגדרה הזו מוגדרת ל-50. הערך הזה עשוי להיות
נמוך מדי לרוב הפריסות. אם בפריסה יש כמה שילובים של org ו-env בהגדרה מסוימת,
ועם מספר גדול של שרתי יעד שחורג מ-50 בסך הכול, כתובות ה-URL של שרתי היעד
מוסרות מהמטמון וגורמות לזמני אחזור.
תיקוף: כדי לקבוע אם ההסרה של כתובת ה-URL של שרת היעד גורמת לבעיית זמן האחזור, צריך לחפש את מילת המפתח 'onEvict' או 'Eviction' (פינוי) ב-Messageprocessor system.logs. הנוכחות שלהם ביומנים מציינת שכתובות ה-URL של שרתי היעד
מוסרות מהמטמון של HTTPClient כי גודל המטמון קטן מדי.
פתרון אפשרי:
ב-Edge for Private Cloud בגרסאות 19.01 ו-19.06, אפשר לערוך ולהגדיר את המטמון של HTTPClient, /opt/apigee/customer/application/message-processor.properties:
אחר כך מפעילים מחדש את המעבד של ההודעות. צריך לבצע את אותם השינויים בכל מעבדי ההודעות.
הערך 500 הוא דוגמה. הערך האופטימלי להגדרה צריך להיות גדול יותר ממספר שרתי היעד שאליהם מעבד ההודעות יתחבר. אין תופעות לוואי
של הגדרת הנכס הזה במיקום גבוה יותר, וההשפעה היחידה תהיה זמני עיבוד משופרים של בקשות
לשרת proxy של מעבדי הודעות.
הערה: הגדרת ברירת המחדל של Edge לענן פרטי בגרסה 50.00 היא 500.
מספר רשומות של מפות של ערכים מרכזיים
157933959: הוספות ועדכונים בו-זמנית לאותה מפת ערכי מפתח (KVM) עם היקף ברמת הארגון או הסביבה גורמות לחוסר עקביות בנתונים ולאבד עדכונים.
הערה: ההגבלה הזו חלה רק על Edge לענן פרטי. המגבלה הזו לא קיימת ב-Edge עבור ענן ציבורי
ו-Hybrid.
כדי לעקוף את הבעיה ב-Edge for Private Cloud, צריך ליצור את ה-KVM בהיקף של apiproxy.