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

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

תיאור הבעיה

המשתנה המותאם אישית שנוצר באמצעות מדיניות 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. כדי לבדוק כמה קבוצות ניתוח נתונים קיימות, מריצים את קריאה ל-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 לשתי קבוצות של שרתי AX. הדרך הכי מהירה לפתרון היא למחוק את פרטי שרת postgres מקבוצה אחת axgroup ולהקצות את כל ההיקפים (ארגון, שילובי סביבות) לקבוצה השנייה. כדי לעשות את זה: פועלים לפי השלבים הבאים:

  1. מסירים את רכיבי השרת postgres מאחת משתי קבוצות הניתוח באמצעות ההוראות שבמאמר הוספה ומחיקה של רכיבי ניתוח בקבוצות ניתוח. אם אתם רואים בעיות רק בהיקפים שאינם ייצור, בחרו את קבוצת ה-AX שלא כוללת היקף ייצור לתרגיל הזה. אחרת, בוחרים את קבוצת הגישה עם מספר ההיקפים הקטן ביותר.
  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