בקטעים הבאים מתוארות הבעיות הידועות ב-Apigee. ברוב המקרים, הבעיות שמפורטות כאן יטופלו במהדורה עתידית.
בעיות ידועות של 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.
הבעיה הזו משפיעה על משתמשים שמנסים להתקין את SSO או את ממשק המשתמש החדש ב-RHEL 8 עם תמיכה ב-FIPS ב-Edge for Private Cloud 4.53.00.
הרכיב המושפע: SSO וממשק המשתמש החדש
הבעיה: אם מתקינים את SSO או את ממשק המשתמש החדש במערכת ההפעלה RHEL 8 שתומכת ב-FIPS, ההתקנה נכשלת.
פתרון עקיף: מומלץ להשתמש בממשק המשתמש הקלאסי, שכולל את כל התכונות ועונה על הצרכים הפונקציונליים של ממשק המשתמש.
עדכון Mint של Edge for Private Cloud 4.52.01
הבעיה הזו משפיעה רק על משתמשים שמשתמשים ב-MINT או שהפעילו את MINT בהתקנות של Edge for Private Cloud.
הרכיב המושפע: edge-message-processor
הבעיה: אם הפעלתם מונטיזציה ומתקינים את הגרסה 4.52.01 כהתקנה חדשה או משדרגים מגרסאות קודמות של Private Cloud, תתקל בבעיה במעבדי ההודעות. מספר השרשור הפתוחים יגדל בהדרגה, מה שיוביל למיצוי המשאבים. החריגה הבאה מופיעה ביומן system.log של edge-message-processor:
Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread
נקודת חולשה ב-HTTP/2 ב-Apigee
לאחרונה התגלתה נקודת חולשה של התקפת מניעת שירות (DoS) בכמה הטמעות של פרוטוקול HTTP/2 (CVE-2023-44487), כולל ב-Apigee Edge לענן פרטי. נקודת החולשה עלולה לגרום להתקפת מניעת שירות (DoS) על הפונקציונליות של ניהול ה-API ב-Apigee.
פרטים נוספים זמינים בעדכון האבטחה הדחוף ל-Apigee GCP-2023-032.
הרכיבים של נתב ושרת הניהול של Edge for Private Cloud חשופים לאינטרנט, ויכול להיות שהם חשופים להתקפות. אמנם HTTP/2 מופעל ביציאת הניהול של רכיבים אחרים ספציפיים ל-Edge ב-Edge for Private Cloud, אבל אף אחד מהרכיבים האלה לא חשוף לאינטרנט. ברכיבים שאינם של Edge, כמו Cassandra, Zookeeper ורכיבים אחרים, הפרוטוקול HTTP/2 לא מופעל. מומלץ לבצע את הפעולות הבאות כדי לטפל בנקודת החולשה של Edge for Private Cloud:
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 שנמצאו ב-Message Processor משפיעים על כל שרתי ה-API. הסימפטומים כוללים עיכובים של 200-300 אלפיות השנייה בזמני העיבוד בהשוואה לזמני התגובה הרגילים של ה-API, והם יכולים להתרחש באופן אקראי גם אם קצב הבקשות לשנייה נמוך. המצב הזה יכול לקרות אם יש יותר מ-50 שרתי יעד שבהם מעבד ההודעות יוצר חיבורים.
הסיבה העיקרית: מעבדי ההודעות שומרים במטמון מיפוי של כתובת ה-URL של שרת היעד לאובייקט HTTPClient לחיבורים יוצאים לשרתים של היעד. כברירת מחדל, ההגדרה הזו מוגדרת ל-50, ויכול להיות שהיא נמוכה מדי לרוב הפריסות. כשפריסה כוללת כמה שילובים של ארגון/סביבה בהגדרה, ויש בה מספר גדול של שרתים יעד שחורג מ-50 בסך הכול, כתובות ה-URL של שרת היעד ממשיכות להוצא מתוך המטמון, וכתוצאה מכך נוצרות זמני אחזור ארוכים.
אימות: כדי לקבוע אם פינוי כתובות URL של שרת היעד גורם לבעיה בזמן האחזור, מחפשים את מילת המפתח 'onEvict' או 'Eviction' ביומני system.logs של Message Processor. נוכחותן ביומני המערכת מציינת שכתובות ה-URL של שרת היעד מועברות מהמטמון של HTTPClient כי גודל המטמון קטן מדי.
פתרון עקיף:
ב-Edge for Private Cloud בגרסאות 19.01 ו-19.06, אפשר לערוך ולהגדיר את המטמון של HTTPClient, /opt/apigee/customer/application/message-processor.properties:
לאחר מכן מפעילים מחדש את מעבד ההודעות. מבצעים את אותם שינויים בכל מעבדי ההודעות.
הערך 500 הוא דוגמה. הערך האופטימלי להגדרה צריך להיות גדול ממספר שרתי היעד שאליהם מעבד ההודעות יתחבר. אין השפעות לוואי של הגדרה גבוהה יותר של המאפיין הזה, וההשפעה היחידה תהיה על זמני העיבוד של בקשות שרת proxy לעיבוד הודעות.
הערה: הגדרת ברירת המחדל ב-Edge for Private Cloud בגרסה 50.00 היא 500.
רשומות מרובות למפות מפתח/ערך
157933959: הוספה ועדכון בו-זמנית של אותו מפת מפתח/ערך (KVM) ברמת הארגון או הסביבה גורמים לנתונים לא עקביים ולעדכונים שאבדו.
הערה: המגבלה הזו רלוונטית רק ל-Edge for Private Cloud. אין הגבלה כזו ב-Edge for Public Cloud וב-Edge Hybrid.
כדי למצוא פתרון עקיף ב-Edge for Private Cloud, יוצרים את ה-KVM ברמת apiproxy.
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2024-12-21 (שעון UTC)."],[],[]]