מאפיינים מותאמים אישית לא מופיעים כשמגדירים מספר קבוצות

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

תיאור הבעיה

המשתנה המותאם אישית שנוצר באמצעות המדיניות Statistics Collector לא מוצג בקטע Custom Dimensions בדוחות בהתאמה אישית ב-Analytics בממשק המשתמש החדש של Edge.

הודעת השגיאה

אחרי הפעלה מחדש, ביומן המערכת של edge-postgres-server תופיע השגיאה הבאה לכל שילוב של ארגון/סביבה שבו הנתיב חסר: 

KeeperErrorCode = NoNode for
/organizations/<ORG>/environments/<ENV>/properties
2018-03-29 16:14:48,980 pool-10-thread-2 ERROR ZOOKEEPER -
ZooKeeperServiceImpl.getData() : Could not get data for path:
/organizations//environments//properties, reason:
KeeperErrorCode = NoNode for
/organizations//environments//properties

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

סיבה תיאור הוראות לפתרון בעיות שרלוונטיות ל
חסר נתיב מאפייני Zookeeper לשילוב של ארגון וסביבה. אם הנתיב /organizations//environments//properties ב-ZooKeeper חסר, אי אפשר ליצור מאפיינים מותאמים אישית. משתמשי Edge Private Cloud

הסיבה: חסר נתיב למאפייני ZooKeeper לשילוב של הארגון והסביבה

אבחון

מפעילים את Analytics לשילוב של ארגון וסביבה באמצעות Enable analytics API, שמאכלס את /organizations//environments//properties בעץ ZooKeeper. כשה-API הזה נכשל, הרכיב edge-postgres-server לא יכול ליצור מאפיינים מותאמים אישית, והשגיאה הבאה תופיע בקובץ system.log שלו: 

KeeperErrorCode = NoNode for
/organizations/example/environments/prod/properties
2018-03-29 16:14:48,980 pool-10-thread-2 ERROR ZOOKEEPER -
ZooKeeperServiceImpl.getData() : Could not get data for path:
/organizations/example/environments/prod/properties, reason:
KeeperErrorCode = NoNode for
/organizations/digi/environments/sandbox/properties

בדרך כלל זה קורה כשארגון הצטרף בזמן שהיו יותר מקבוצת ניתוח אחת שהשתמשו באותם מזהי UUID של postgres-server. כדי לבדוק כמה קבוצות ניתוח נתונים קיימות, מריצים את קריאה ל-API הבאה: 

curl -u username:password "http://management-server-host:8080/v1/analytics/groups/ax"

אם ה-API הזה מחזיר כמה קבוצות, סביר להניח שזו הסיבה לבעיה. בדוגמה הבאה, שימו לב שיש שתי קבוצות, שההבדל היחיד ביניהן הוא מקף: axgroup-001 ו-axgroup001 

[ {
  "name" : "axgroup-001",
  "properties" : {
  },
  "scopes" : [ "VALIDATE~test" ],
  "uuids" : {
    "qpid-server" : [ "94c96375-1ca7-412d-9eee-80fda94f6e07" ],
    "postgres-server" : [ "8ee86b70-5b33-44b6-b2f8-1b0ec0ec8d77" ]
  },
  "consumer-groups" : [ {
    "name" : "consumer-group-001",
    "consumers" : [ "94c96375-1ca7-412d-9eee-80fda94f6e07" ],
    "datastores" : [ "8ee86b70-5b33-44b6-b2f8-1b0ec0ec8d77" ],
    "properties" : {
    }
  } ],
  "data-processors" : {
  }
}, {
  "name" : "axgroup001",
  "properties" : {
  },
  "scopes" : [ "example~prod" ],
  "uuids" : {
    "qpid-server" : [ "94c96375-1ca7-412d-9eee-80fda94f6e07" ],
    "postgres-server" : [ "8ee86b70-5b33-44b6-b2f8-1b0ec0ec8d77" ]
  },
  "consumer-groups" : [ {
    "name" : "consumer-group-001",
    "consumers" : [ "94c96375-1ca7-412d-9eee-80fda94f6e07" ],
    "datastores" : [ "8ee86b70-5b33-44b6-b2f8-1b0ec0ec8d77" ],
    "properties" : {
    }
  } ],
  "data-processors" : {
  }

באופן ספציפי, הבעיה נגרמת אם ה-UUID של postgres-server שמוגדר לכל axgroup זהה. דרך מהירה לבדוק את זה היא להריץ את הפקודה הבאה: 

curl -u username:password "http://management-server-host:8080/v1/analytics/groups/ax"|grep -B7 "postgres-server"

בפלט לדוגמה הבא אפשר להשוות במהירות בין מזהי ה-UUID של postgres-server כדי לוודא שהם זהים: 

{  "name" : "axgroup-001",  "properties" : {  },  "scopes" : [ "VALIDATE~test" ],
"uuids" : {    "qpid-server" : [ "94c96375-1ca7-412d-9eee-80fda94f6e07" ],
"postgres-server" : [ "8ee86b70-5b33-44b6-b2f8-1b0ec0ec8d77" ]--
"name" : "axgroup001",  "properties" : {  },  "scopes" : [ "myorg~prod" ],
"uuids" : {    "qpid-server" : [ "94c96375-1ca7-412d-9eee-80fda94f6e07" ],
"aries-datastore" : [ ],    "postgres-server" : [ "8ee86b70-5b33-44b6-b2f8-1b0ec0ec8d77" ],

רזולוציה

אי אפשר להקצות את אותה קבוצת שרתי PostgreSQL לשני axgroups. הדרך הכי מהירה לפתרון היא למחוק את פרטי שרת postgres מקבוצה אחת של axgroup ולהקצות את כל ההיקפים (ארגון, שילובי סביבות) לקבוצה השנייה. כדי לעשות את זה:

  1. מסירים את רכיבי השרת של postgres מאחת משתי קבוצות ה-axgroup לפי ההוראות במאמר הוספה ומחיקה של רכיבי ניתוח נתונים בקבוצות ניתוח נתונים. אם הבעיות מופיעות רק בהיקפי הרשאות שלא קשורים לסביבת הייצור, צריך לבחור את קבוצת ה-axgroup שלא כוללת היקף הרשאות שקשור לסביבת הייצור בתרגיל הזה. אחרת, בוחרים את קבוצת הגישה עם מספר ההיקפים הקטן ביותר.
  2. מסירים את כל ההיקפים מקבוצת ה-axgroup שכבר אין בה שרתי postgres, ואת אלה שבהם אתם רואים את הבעיה במאפיין המותאם אישית מקבוצת ה-axgroup שלהם. בהנחה ש-axgroup-001 מהדוגמה שלמעלה היא הקבוצה שרוצים להשתמש בה, צריך להשתמש בפקודה הבאה כדי להסיר את היקף ההרשאות עבור הארגון myorg והסביבה prod: 
    curl -u username:password -X DELETE 'http://management-server-host:8080/v1/analytics/groups/ax/axgroup001/scopes?org=myorg&env=prod'
  3. מפעילים את ניתוח הנתונים באמצעות Enable analytics API.
  4. מפעילים מחדש את הרכיב edge-postgres-server בצומת הראשי של postgres, ואת כל הרכיבים edge-qpid-server שהתקנתם, באמצעות הפקודות הבאות: 
     /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

     /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
  5. מוודאים שהשגיאה שצוינה בקטע הודעת שגיאה שלמעלה לא מופיעה יותר בקובץ היומן של שרת Postgres‏ /opt/apigee/var/log/edge-postgres-server/logs/system.log.
  6. מוודאים שהמאפיינים המותאמים אישית מופיעים בממשק המשתמש החדש של Edge.

אם הבעיה נמשכת, עוברים אל איסוף מידע לאבחון.

איסוף חובה של נתוני אבחון

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

  1. ‫edge-postgres-server /opt/apigee/var/log/edge-postgres-server/logs/system.log מאז ההפעלה מחדש האחרונה.
  2. הפלט של הקריאה הבאה ל-Management API: 
    curl -u username:password "http://management-server-host:8080/v1/analytics/groups/ax"
  3. הפלט של עץ ZooKeeper שמתקבל באמצעות הפקודה הבאה: 
    /opt/apigee/apigee-zookeeper/contrib/zk-tree.sh > zktree-output.txt