בעיות מוכרות ב-Apigee

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

בקטעים הבאים מתוארות הבעיות הידועות ב-Apigee. ברוב המקרים, הבעיות שמפורטות כאן יטופלו במהדורה עתידית.

בעיות ידועות אחרות ב-Edge

בקטעים הבאים מתוארות בעיות שונות שידועות ב-Edge.

אזור/סיכום בעיות מוכרות
פג תוקף של מטמון גורם לערך שגוי של cachehit

כשמשתמשים במשתנה התהליך cachehit אחרי המדיניות של LookupCache, בגלל האופן שבו נשלחים נקודות ניפוי באגים להתנהגות אסינכררונית, המדיניות של LookupPolicy מאכלסת את האובייקט DebugInfo לפני שהקריאה החוזרת (call back) מבוצעת, וכתוצאה מכך מתקבלת שגיאה.

פתרון אפשרי: חוזרים על התהליך (מתקשרים בשיחה שנייה) מיד אחרי השיחה הראשונה.

הגדרת המדיניות InvalidateCache PurgeChildEntries כ-true לא פועלת כמו שצריך

הגדרת PurgeChildEntries במדיניות InvalidateCache אמורה למחוק את ערכי האלמנט KeyFragment בלבד, אבל היא מנקה את כל המטמון.

פתרון עקיף: משתמשים במדיניות KeyValueMapOperations כדי לבצע איטרציה של ניהול גרסאות במטמון ולעקוף את הצורך בביטול התוקף של המטמון.

בקשות עיבוד בו-זמנית לפריסה של SharedFlow או שרת proxy ל-API יכולות לגרום למצב לא עקבי בשרת הניהול, שבו מוצגות כמה גרסאות כפרוסות.

מצב כזה יכול לקרות, למשל, כשמתבצעות הפעלות בו-זמניות של צינור עיבוד נתונים לפריסה של CI/CD באמצעות גרסאות שונות. כדי למנוע את הבעיה הזו, מומלץ לא לפרוס שרתים proxy של API או תהליכים משותפים לפני שהפריסה הנוכחית תושלם.

פתרון עקיף: הימנעו מפריסות בו-זמניות של proxy ל-API או של SharedFlow.

ייתכן שמספרי הקריאות ל-API שמוצגים ב-Edge API Analytics מכילים נתונים כפולים.

לפעמים, נתונים כפולים של קריאות ל-API יכולים להופיע ב-Edge API Analytics. במקרה כזה, המספרים שמוצגים לקריאות ל-API ב-Edge API Analytics גבוהים מהערכים המקבילים שמוצגים בכלי ניתוח נתונים של צד שלישי.

פתרון עקיף: מייצאים את נתוני Analytics ומשתמשים בשדה gateway_flow_id כדי לבטל את הכפילויות בנתונים.

בעיות ידועות בממשק המשתמש של Edge

בקטעים הבאים מתוארות הבעיות הידועות בממשק המשתמש של Edge.

אזור בעיות ידועות
לא ניתן לגשת לדף 'ניהול אזור SSO של Edge' מסרגל הניווט אחרי שהארגון ממופה לאזור זהות כשמחברים ארגון לאזור זהות, אי אפשר יותר לגשת לדף 'ניהול אזור SSO ב-Edge' מסרגל הניווט הימני על ידי בחירה באפשרות 'אדמין' > 'SSO'. כדי לעקוף את הבעיה, תוכלו לעבור ישירות לדף באמצעות כתובת ה-URL הבאה: https://apigee.com/sso

בעיות מוכרות בפורטל המשולב

בקטעים הבאים מתוארות הבעיות הידועות בפורטל המשולב.

אזור בעיות מוכרות
SmartDocs
  • ב-Apigee Edge יש תמיכה במפרט OpenAPI 3.0 כשיוצרים מפרטים באמצעות עורך המפרטים ומפרסמים ממשקי API באמצעות SmartDocs בפורטל, אבל עדיין אין תמיכה בקבוצת משנה של תכונות.

    לדוגמה, התכונות הבאות במפרט OpenAPI 3.0 עדיין לא נתמכות:

    • מאפייני allOf לשילוב ולהרחבה של סכימות
    • הפניות מרחוק

    אם יש הפניה לתכונה שאינה נתמכת במפרט OpenAPI, במקרים מסוימים הכלים יתעלמו מהתכונה אבל עדיין יציגו את תיעוד העזר של ה-API. במקרים אחרים, תכונה שאינה נתמכת תגרום לשגיאות שמונעות את היצירה המוצלחת של מסמכי התיעוד של הפניות ה-API. בכל מקרה, תצטרכו לשנות את מפרט OpenAPI כדי להימנע משימוש בתכונה שלא נתמכת, עד שהיא תהיה נתמכת בגרסה עתידית.

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

  • כשמשתמשים ב'ניסיון ב-API הזה' בפורטל, הכותרת Accept מוגדרת כ-application/json ללא קשר לערך שהוגדר ל-consumes במפרט OpenAPI.
  • 138438484: אין תמיכה במספר שרתים.
ספק זהויות ב-SAML אין תמיכה ביציאה יחידה (SLO) עם ספק הזהויות של SAML בדומיינים מותאמים אישית. כדי להפעיל דומיין מותאם אישית עם ספק זהויות של SAML, משאירים את השדה כתובת URL ליציאה ריק כשמגדירים את ההגדרות של SAML.
אדמין של פורטל
  • בשלב זה אין תמיכה בעדכוני פורטל בו-זמניים (כמו עריכת דפים, עיצובים, קובצי CSS או סקריפטים) על ידי כמה משתמשים.
  • אם תמחקו דף של מסמכי עזרה של API מהפורטל, לא תוכלו ליצור אותו מחדש. תצטרכו למחוק את מוצר ה-API ולהוסיף אותו מחדש, וליצור מחדש את מסמכי העזרה של ה-API.
  • כשמגדירים את מדיניות אבטחת התוכן, יכול להיות שיחלפו עד 15 דקות עד שהשינויים יחולו במלואם.
  • כשמתאימים אישית את העיצוב של הפורטל, יכול להיות שיחלפו עד 5 דקות עד שהשינויים יחולו במלואם.
תכונות הפורטל
  • החיפוש ישולב בפורטל המשולב בגרסה עתידית.

בעיות מוכרות ב-Edge for Private Cloud

בקטעים הבאים מתוארות הבעיות הידועות ב-Edge for Private Cloud.

אזור בעיות מוכרות
‫Edge for Private Cloud 4.53.00 440148595: End of Life Popup Warning Displayed Excessively

ב-Edge for Private Cloud מגרסה 4.53.00 ואילך, מוצג בממשק המשתמש חלון קופץ עם אזהרה על סוף חיי המוצר (EOL). האזהרה הזו מופיעה שוב ושוב, ואי אפשר למנוע את ההופעה שלה או להפחית את התדירות שלה.

נכון לעכשיו, אין למשתמשים אפשרות להשבית את האזהרה הזו על סוף החיים או להפחית את התדירות שבה היא מוצגת.
‫Edge for Private Cloud 4.53.01
443272053: שגיאות במאגר נתונים ברכיבי קצה

ב-Edge for Private Cloud בגרסה 4.53.00 ואילך, סוג מסוים של אינטראקציה בין Cassandra לרכיבי אפליקציה (שרת ניהול, מעבד הודעות או נתב) עלול לגרום לשגיאות במאגר הנתונים. כששגיאה כזו מתרחשת, ביומני המערכת של רכיב האפליקציה הספציפי מופיעים יומנים עם הדפוס הבא:

com.datastax.driver.core.exceptions.ProtocolError: An unexpected protocol error occurred on host WW.XX.YY.ZZ:9042.

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

  1. הקטנת הערך של gc_grace_seconds: בטבלה שמוצגת בהודעת היומן שמשויכת לשגיאה, מקטינים את הערך של gc_grace_seconds על ידי הפעלת הפקודה הבאה, כמו בדוגמה, באמצעות cqlsh: 
    Below command sets gc_grace_seconds of kms.oauth_20_access_tokens to 1 day from default 10 days
ALTER TABLE kms.oauth_20_access_tokens WITH gc_grace_seconds = '86400';
  2. כדי ליצור אזהרות, צריך להגדיל את הסף של tombstone ב-Cassandra. כדי לעשות את זה, צריך לפעול לפי ההוראות הבאות:
    1. בצומת Cassandra, יוצרים או עורכים את הקובץ $APIGEE_ROOT/customer/application/cassandra.properties.
    2. כדי להגדיל את Tombstone warn threshold מ-10k (ברירת המחדל) ל-100k, או להגדיר ערכים גדולים יותר לפי הצורך, מוסיפים את השורה הבאה: 
      conf_cassandra_tombstone_warn_threshold=100000
    3. מוודאים שלמשתמש apigee יש בעלות על הקובץ שלמעלה והרשאת קריאה בו: 
      chown apigee:apigee $APIGEE_ROOT/customer/application/cassandra.properties
    4. מפעילים מחדש את אפליקציית Cassandra בצומת: 
      apigee-service apigee-cassandra restart
    5. חוזרים על השלבים שלמעלה בכל צומת של Cassandra, אחד אחרי השני.
‫42733857: זמן אחזור בעדכון של מיפויים של ערכי מפתח (KVM) מוצפנים

כשעובדים עם מיפויים מוצפנים של זוגות מפתח/ערך שמכילים מספר גדול של רשומות, יכול להיות שיהיו השהיות כשמוסיפים או מעדכנים רשומות, בין אם באמצעות ממשקי API לניהול או באמצעות רכיב PUT במדיניות KeyValueMapOperations . מידת ההשפעה על הביצועים בדרך כלל פרופורציונלית למספר הכולל של הרשומות שמאוחסנות ב-KVM המוצפן.

כדי לצמצם את הבעיה, מומלץ למשתמשים להימנע מיצירת מכונות KVM מוצפנות עם מספר רב מדי של רשומות. פתרון אפשרי הוא לחלק KVM גדול לכמה KVM קטנים יותר. בנוסף, אם תרחיש השימוש מאפשר זאת, מעבר ל-KVM לא מוצפן יכול לשמש גם כשיטת צמצום סיכונים יעילה. חשוב לדעת שהצוות של Apigee מודע לבעיה הזו ומתכנן לפרסם תיקון בתיקון באג עתידי.
קריאות ל-Java

יכול להיות שקריאות ל-Java מותאמות אישית שמנסות לטעון את ספק הקריפטוגרפיה Bouncy Castle באמצעות השם BC ייכשלו, כי ספק ברירת המחדל שונה ל-Bouncy Castle FIPS כדי לתמוך ב-FIPS. השם החדש של הספק שצריך להשתמש בו הוא BCFIPS.
‫Edge for Private Cloud 4.53.00
קריאות ל-Java

יכול להיות שקריאות ל-Java מותאמות אישית שמנסות לטעון את ספק הקריפטוגרפיה Bouncy Castle באמצעות השם BC ייכשלו, כי ספק ברירת המחדל שונה ל-Bouncy Castle FIPS כדי לתמוך ב-FIPS. השם החדש של הספק שצריך להשתמש בו הוא BCFIPS.
Edge for Private Cloud 4.52.01 Mint update

הבעיה הזו משפיעה רק על משתמשים שמשתמשים ב-MINT או שהפעילו את MINT בהתקנות של Edge for Private Cloud.

הרכיב שהושפע: edge-message-processor

בעיה: אם הפעלתם מונטיזציה ואתם מתקינים את גרסה 4.52.01 כהתקנה חדשה או משדרגים מגרסאות קודמות של Private Cloud, תיתקלו בבעיה במעבדי ההודעות. מספר השרשורים הפתוחים יגדל בהדרגה עד שייגמרו המשאבים. החריגה הבאה מופיעה ביומן המערכת של 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 for Private Cloud. נקודת התורפה עלולה לגרום ל-DoS בפונקציונליות של ניהול Apigee API. פרטים נוספים זמינים במאמר עדכון האבטחה הדחוף ל-Apigee‏ GCP-2023-032.

רכיבי הנתב ושרת הניהול של Edge for Private Cloud חשופים לאינטרנט, ויכול להיות שהם פגיעים. למרות ש-HTTP/2 מופעל ביציאת הניהול של רכיבים אחרים שספציפיים ל-Edge ב-Edge for Private Cloud, אף אחד מהרכיבים האלה לא נחשף לאינטרנט. ברכיבים שאינם Edge, כמו Cassandra, ‏ Zookeeper ואחרים, HTTP/2 לא מופעל. מומלץ לבצע את הפעולות הבאות כדי לטפל בנקודת החולשה ב-Edge for Private Cloud:

אם אתם משתמשים ב-Edge Private Cloud בגרסה 4.51.00.11 ואילך, אתם צריכים לבצע את השלבים הבאים:

  1. עדכון שרת הניהול:

    1. בכל צומת של שרת ניהול, פותחים את /opt/apigee/customer/application/management-server.properties
    2. מוסיפים את השורה הזו לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
    3. מפעילים מחדש את רכיב שרת הניהול: 
      apigee-service edge-management-server restart

  2. עדכון מעבד ההודעות:

    1. בכל צומת של מעבד ההודעות, פותחים את /opt/apigee/customer/application/message-processor.properties
    2. מוסיפים את השורה הזו לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
    3. מפעילים מחדש את רכיב עיבוד ההודעות: 
      apigee-service edge-message-processor restart

  3. עדכון הנתב:

    1. בכל צומת של הנתב, פותחים את /opt/apigee/customer/application/router.properties
    2. מוסיפים את השורה הזו לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
    3. מפעילים מחדש את רכיב עיבוד ההודעות: 
      apigee-service edge-router restart

  4. עדכון QPID:

    1. בכל צומת QPID, פותחים את /opt/apigee/customer/application/qpid-server.properties
    2. מוסיפים את השורה הזו לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
    3. מפעילים מחדש את רכיב עיבוד ההודעות: 
      apigee-service edge-qpid-server restart

  5. עדכון Postgres:

    1. בכל צומת של Postgres, פותחים את /opt/apigee/customer/application/postgres-server.properties
    2. מוסיפים את השורה הזו לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
    3. מפעילים מחדש את רכיב עיבוד ההודעות: 
      apigee-service edge-postgres-server restart

אם אתם משתמשים ב-Edge for Private Cloud בגרסאות ישנות יותר מ-4.51.00.11, צריך לבצע את השלבים הבאים:

  1. עדכון שרת הניהול:

    1. בכל צומת של שרת ניהול, פותחים את /opt/apigee/customer/application/management-server.properties
    2. מוסיפים את שתי השורות הבאות לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. מפעילים מחדש את רכיב שרת הניהול: 
      apigee-service edge-management-server restart

  2. עדכון מעבד ההודעות:

    1. בכל צומת של מעבד ההודעות, פותחים את /opt/apigee/customer/application/message-processor.properties
    2. מוסיפים את שתי השורות הבאות לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. מפעילים מחדש את רכיב עיבוד ההודעות: 
      apigee-service edge-message-processor restart

  3. עדכון הנתב:

    1. בכל צומת של הנתב, פותחים את /opt/apigee/customer/application/router.properties
    2. מוסיפים את שתי השורות הבאות לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. מפעילים מחדש את רכיב עיבוד ההודעות: 
      apigee-service edge-router restart

  4. עדכון QPID:

    1. בכל צומת QPID, פותחים את /opt/apigee/customer/application/qpid-server.properties
    2. מוסיפים את שתי השורות הבאות לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. מפעילים מחדש את רכיב עיבוד ההודעות: 
      apigee-service edge-qpid-server restart

  5. עדכון Postgres:

    1. בכל צומת של Postgres, פותחים את /opt/apigee/customer/application/postgres-server.properties
    2. מוסיפים את שתי השורות הבאות לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. מפעילים מחדש את רכיב עיבוד ההודעות: 
      apigee-service edge-postgres-server restart
שדרוג Postgresql בעדכון לגרסה 4.52

יש בעיות ב-Apigee-postgresql בשדרוג מגרסה 4.50 או 4.51 של Edge לענן פרטי לגרסה 4.52. הבעיות מתרחשות בעיקר כשמספר הטבלאות גדול מ-500.

כדי לבדוק את המספר הכולל של הטבלאות ב-Postgres, מריצים את שאילתת ה-SQL הבאה:

select count(*) from information_schema.tables

פתרון עקיף: כש מעדכנים את Apigee Edge מגרסה 4.50.00 או 4.51.00 לגרסה 4.52.00, חשוב לבצע את השלב המקדים לפני שמשדרגים את Apigee-postgresql.
מדיניות LDAP

‫149245401: ההגדרות של מאגר חיבורי LDAP ל-JNDI שהוגדרו דרך משאב LDAP לא משתקפות, והגדרות ברירת המחדל של JNDI גורמות לחיבורים חד-פעמיים בכל פעם. כתוצאה מכך, חיבורים נפתחים ונסגרים בכל פעם לשימוש חד-פעמי, ונוצר מספר גדול של חיבורים לשעה לשרת ה-LDAP.

פתרון עקיף:

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

  1. יוצרים קובץ מאפייני תצורה אם הוא לא קיים: 
    /opt/apigee/customer/application/message-processor.properties
  2. מוסיפים את השורות הבאות לקובץ (מחליפים את הערכים של מאפייני Java Naming and Directory Interface‏ (JNDI) בהתאם לדרישות התצורה של משאב ה-LDAP). 
    bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
-Dcom.sun.jndi.ldap.connect.pool.prefsize=2
-Dcom.sun.jndi.ldap.connect.pool.initsize=2
-Dcom.sun.jndi.ldap.connect.pool.timeout=120000
-Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"
  3. חשוב לוודא שהקובץ /opt/apigee/customer/application/message-processor.properties נמצא בבעלות apigee:apigee.
  4. מפעילים מחדש כל מעבד הודעות.

כדי לוודא שהמאפיינים של מאגר החיבורים של JNDI פועלים, אפשר לבצע tcpdump כדי לראות את ההתנהגות של מאגר החיבורים של LDAP לאורך זמן.
זמן אחזור ארוך של עיבוד בקשות

‫139051927: נמצאו השהיות גבוהות בעיבוד של שרתי proxy במעבד ההודעות, שמשפיעות על כל שרתי ה-proxy של ה-API. התסמינים כוללים עיכובים של 200-300 אלפיות השנייה בזמני העיבוד מעבר לזמני התגובה הרגילים של ה-API, והם יכולים להתרחש באופן אקראי גם עם TPS נמוך. זה יכול לקרות אם יש יותר מ-50 שרתי יעד שמעבד ההודעות מתחבר אליהם.

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

אימות: כדי לקבוע אם הבעיה של זמן האחזור נגרמת בגלל הוצאה של כתובת URL של שרת יעד מהזיכרון, מחפשים ביומני המערכת של מעבד הבקשות את מילות המפתח onEvict או Eviction. הנוכחות שלהם ביומנים מציינת שכתובות URL של שרתים יעד מוצאות מהמטמון של HTTPClient כי גודל המטמון קטן מדי.

פתרון עקיף: בגרסאות 19.01 ו-19.06 של Edge for Private Cloud, אפשר לערוך ולהגדיר את מטמון HTTPClient, ‏ /opt/apigee/customer/application/message-processor.properties:

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

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

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

הערה: בגרסה 50.00 של Edge for Private Cloud, הגדרת ברירת המחדל היא 500.
כמה רשומות למפות של מפתח/ערך

‫157933959: הוספות ועדכונים בו-זמניים לאותו מיפוי של זוגות מפתח/ערך (KVM) בהיקף של הארגון או הסביבה גורמים לנתונים לא עקביים ולעדכונים שאבדו.

הערה: המגבלה הזו רלוונטית רק ל-Edge for Private Cloud. ב-Edge for Public Cloud וב-Hybrid אין את ההגבלה הזו.

כדי לעקוף את הבעיה ב-Edge for Private Cloud, יוצרים את ה-KVM בהיקף apiproxy.