נתונים לא מופיעים במרכזי בקרה של Analytics

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

תיאור הבעיה

במרכזי הבקרה של ניתוח הנתונים (ביצועי שרת proxy, ביצועי יעד וכו') לא מוצגים בממשק המשתמש של Edge. בכל מרכזי הבקרה מוצגת ההודעה הבאה:

No traffic in the selected date range

הודעות שגיאה

הבעיה הזו לא מובילה לשגיאות שניתנות למדידה.

גורמים אפשריים

בטבלה הבאה מפורטות הסיבות האפשריות לבעיה הזו:

סיבה	עבור
אין תנועת API מסביבת הארגון	Edge למשתמשים בענן פרטי
הנתונים זמינים במסד הנתונים של Postgres, אך לא מוצגים ב- UI	Edge למשתמשים בענן פרטי
נתוני Analytics לא נדחפים למסד נתונים של Postgres	Edge למשתמשים בענן פרטי
פריסה שגויה של Analytics	Edge למשתמשים בענן פרטי
מזהי UUID של שרת Analytics לא פעילים	Edge למשתמשים בענן פרטי

אין תנועת API עבור סביבת הארגון

אבחון

1. בדיקה אם יש תנועה עבור שרתי ה-proxy ל-API בסביבה הספציפית של הארגון עבור משך הזמן הספציפי שבו אתם מנסים להציג את נתוני הניתוח באמצעות אחד מהקריטריונים הבאים אמצעי תשלום:
   1. מפעילים את המעקב לכל אחד מממשקי ה-API שמשמשים כרגע את המשתמשים שלכם, וגם כדאי לבדוק אם מצליחים לקבל בקשות במעקב.
   2. צפייה ביומני הגישה ל-NGINX (/opt/apigee/var/log/edge-router/nginx/logs/access.log) ולבדוק אם יש כאלה רשומות חדשות עבור שרתי proxy ל-API למשך הזמן הספציפי.
   3. אם רושמים מידע מ-API Proxies בשרת יומן כמו Syslog, Splunk, Loggly וכו', תוכלו לבדוק אם יש רשומות בשרתי היומן האלה עבור שרתי proxy ל-API עבור משך הזמן הספציפי.
2. אם אין תנועה (אין בקשות API) בפרק הזמן הספציפי, נתוני ניתוח הנתונים לא זמין. תופיע ההודעה 'אין תנועה בטווח התאריכים שנבחר' בניתוח הנתונים במרכז הבקרה.

רזולוציה

1. ביצוע קריאות מסוימות לשרת proxy אחד או יותר של API בסביבה הספציפית של הארגון.
2. צריך להמתין כמה שניות ואז להציג את מרכזי הבקרה של ניתוח הנתונים בכרטיסייה 'שעות' ולבדוק אם הנתונים יופיעו.
3. אם הבעיה נמשכת, ממשיכים אל הנתונים הזמינים ב-Postgres מסד הנתונים, אבל לא מוצג בממשק המשתמש.

הנתונים זמינים במסד הנתונים של Postgres, אך לא מוצגים בממשק המשתמש

תיאור הבעיה

קודם כל, חשוב לקבוע את הזמינות של נתוני Analytics העדכניים במסד הנתונים של Postgres.

איך בודקים אם נתוני Analytics העדכניים זמינים במאסטר של Postgres צומת:

1. מתחברים לכל אחד משרתי Postgres ומריצים את הפקודה הבאה כדי לוודא בצומת Master Postgres:

   /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
   

2. בצומת Master Postgres, מתחברים ל-PostgreSQL:

   psql -h /opt/apigee/var/run/apigee-postgresql -U apigee apigee
   

3. איך בודקים אם הטבלה קיימת בארגון באמצעות שאילתת ה-SQL הבאה ב-Postgres מסד נתונים:

   \d analytics."orgname.envname.fact"
   

4. לבדוק אם הנתונים העדכניים ביותר זמינים במסד הנתונים של Postgres באמצעות ה-SQL הבא שאילתה:

   select max(client_received_start_timestamp) from analytics."orgname.envname.fact";
   

5. אם חותמת הזמן האחרונה ישנה מאוד (או אפס), המשמעות היא שהנתונים לא במסד הנתונים של Postgres. סביר להניח שהסיבה לבעיה הזו היא שהנתונים לא נדחפו משרת ה-Qpid למסד הנתונים של Postgres. ממשיכים לקטע נתוני Analytics לא נדחפים למסד נתונים של Postgres.
6. אם הנתונים העדכניים זמינים במסד הנתונים של Postgres בצומת הראשי, פועלים לפי ההוראות הבאות: כדי לבדוק למה הנתונים לא מוצגים בממשק המשתמש של Edge:

אבחון

1. מפעילים את הכלים למפתחים בדפדפן Chrome ולקבל את ה-API שבו נעשה שימוש באחד ממרכזי הבקרה של ניתוח נתונים באמצעות אלה השלבים:
   1. בוחרים בכרטיסייה 'רשת' מתוך הכלים למפתחים.
   2. מתחילים בהקלטה.
   3. טוענים מחדש את מרכז הבקרה של Analytics.
   4. בחלונית הימנית ב'כלים למפתחים', בוחרים את השורה "apiproxy?_optimized..."
   5. בחלונית השמאלית ב'כלים למפתחים', בוחרים באפשרות 'כותרות' ושימו לב 'כתובת URL של הבקשה'.
2. הנה פלט לדוגמה מהכלים למפתחים:

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

   

3. מריצים את הקריאה ישירות ל-API לניהול ובודקים אם התקבלו התוצאות. דוגמה ל-API שיחה לכרטיסייה 'יום' בלוח הבקרה של הביצועים של שרת proxy:

   curl -u username:password
     "http://management_server_IP_address:8080/v1/organizations/
     org_name/environments/env_name/stats/apiproxy?limit=14400&
     select=sum(message_count),sum(is_error),avg(total_response_time),
     avg(target_response_time)&sort=DESC&sortby=sum(message_count),sum(is_error),
     avg(total_response_time),avg(target_response_time)&timeRange=08%2F9%2F2017+
     18:00:00~08%2F10%2F2017+18:00:00&timeUnit=hour&tsAscending=true"
   

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

   telnet Postgres_server_IP_address 5432
   

6. אם לא ניתן להתחבר לשרת Postgres, צריך לבדוק אם יש חומת אש הגבלות על יציאה 5432.
7. אם יש הגבלות על חומת האש, יכול להיות שזו הסיבה לשרת הניהול. הוא לא יכול לשלוף את הנתונים משרת Postgres.

רזולוציה

1. אם יש הגבלות של חומת אש, מסירים אותן כדי ששרת הניהול יוכל לתקשר עם שרת Postgres.
2. אם אין הגבלות של חומת האש, יכול להיות שהבעיה נובעת מתקלה ברשת.
3. אם הייתה תקלה ברשת בשרת הניהול, הפעלה מחדש עשויה לפתור את הבעיה בעיה.
4. מפעילים מחדש את כל שרתי הניהול אחד אחרי השני באמצעות הפקודה הבאה:

   /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
   

5. בודקים אם יש אפשרות לראות את ניתוח הנתונים בממשק המשתמש של Edge.

אם הנתונים עדיין לא מוצגים, צריך לפנות לתמיכה של Apigee Edge.

נתוני Analytics לא נדחפים למסד הנתונים של Postgres

אבחון

אם הנתונים לא נדחפו משרת Qpid למסד הנתונים של Postgres כפי שנקבע בנתונים הזמינים במסד הנתונים של Postgres, אך לא מופיעים בממשק המשתמש, מבצעים את הפעולות הבאות את השלבים הבאים:

1. הרצת הפקודה הבאה לבדוק אם כל שרת Qpid פועל:

   /opt/apigee/bin/apigee-service edge-qpid-server status
   

2. אם שרת Qpid כלשהו מושבת, מפעילים אותו מחדש. אם לא, דלגו לשלב 5.

   /opt/apigee/bin/apigee-service edge-qpid-server restart
   

3. מומלץ להמתין קצת ואז לבדוק שוב אם הנתונים העדכניים זמינים במסד הנתונים של Postgres.
   1. מתחברים ל-PostgreSQL:

      psql -h /opt/apigee/var/run/apigee-postgresql -U apigee apigee
      

   2. מריצים את שאילתת ה-SQL הבאה כדי לבדוק אם הנתונים העדכניים זמינים:

      select max(client_received_start_timestamp) from analytics."orgname.envname.fact";
      

4. אם הנתונים העדכניים זמינים, דלגו על השלבים הבאים והמשיכו לשלב האחרון בקטע קטע בנושא רזולוציה. אם הנתונים העדכניים לא זמינים, אפשר לבצע את הפעולות הבאות לבצע מיליון שלבים.
5. בודקים אם ההודעות מתורי שרת Qpid מועברות למסד הנתונים של Postgres.
   1. מפעילים את qpid-stat -q command ובודקים את ה-msgIn הערכים בעמודה msgOut.
   2. לפניכם פלט לדוגמה שמראה שהערכים msgIn ו-msgOut לא זהים. המשמעות היא שההודעות לא נדחפות משרת Qpid למסד הנתונים של Postgres.

      

6. אם יש חוסר התאמה בעמודות msgIn ו-msgOut, צריך לבדוק את ה-Qpid יומני השרת /opt/apigee/var/log/edge-qpid-server/system.log ובודקים אם יש כל שגיאה.
7. ייתכן שיופיעו הודעות שגיאה כמו "סביר להניח שהסיווג של PG עדיין לא פועל" או "FATAL: מצטערים, כבר יש יותר מדי לקוחות", כפי שמוצג באיור הבא:

   2017-07-28 09:56:39,896 ax-q-axgroup001-persistpool-thread-3
     WARN c.a.a.d.c.ServerHandle - ServerHandle.logRetry() : Found the exception to be
     retriable - . Error observed while trying to connect to
     jdbc:postgresql://PG_IP_address:5432/apigee Initial referenced UUID when
     execution started in this thread was a1ddf72f-ac77-49c0-a1fc-d0db6bf9991d
     Probably PG is still down. PG set used - [a1ddf72f-ac77-49c0-a1fc-d0db6bf9991d]
   2017-07-28 09:56:39,896 ax-q-axgroup001-persistpool-thread-3
     WARN c.a.a.d.c.ServerHandle - ServerHandle.logRetry() : Could not get JDBC Connection;
     nested exception is org.postgresql.util.PSQLException: FATAL: sorry, too many clients already
   2017-07-28 09:56:53,617 pool-7-thread-1
     WARN c.a.a.d.c.ServerHandle - ServerHandle.logRetry() : Found the exception to be
     retriable - . Error observed while trying to connect to
     jdbc:postgresql://PG_IP_address:5432/apigee
     Initial referenced UUID when execution started in this thread was
     a1ddf72f-ac77-49c0-a1fc-d0db6bf9991d Probably PG is still down. PG set used -
     [a1ddf72f-ac77-49c0-a1fc-d0db6bf9991d]
   2017-07-28 09:56:53,617 pool-7-thread-1
     WARN c.a.a.d.c.ServerHandle - ServerHandle.logRetry() : Could not get JDBC Connection;
     nested exception is org.apache.commons.dbcp.SQLNestedException: Cannot create
     PoolableConnectionFactory (FATAL: sorry, too many clients already)
   

מצב כזה יכול לקרות אם שרת Postgres מריץ יותר מדי שאילתות SQL או אם המעבד (CPU) פועל ולכן הם לא יכולים להגיב לשרת Qpid.

רזולוציה

1. מפעילים מחדש את שרת Postgres ואת PostgreSQL כפי שמוצג בהמשך:

   /opt/apigee/bin/apigee-service edge-postgres-server restart
   

   /opt/apigee/bin/apigee-service apigee-postgresql restart
   

2. ההפעלה מחדש מבטיחה שכל השאילתות הקודמות של SQL יופסקו, ויהיה אפשר למסד הנתונים של Postgres.
3. טוענים מחדש את מרכזי הבקרה של Analytics ובודקים אם נתוני Analytics מוצגים.

אם הבעיה נמשכת, צריך לפנות לתמיכה של Apigee Edge.

פריסה שגויה של Analytics

אבחון

1. קבלת סטטוס הפריסה של Analytics באמצעות הקריאה הבאה ל-API:

   curl -u user_email:password http://management_server_host:port
   /v1/organizations/orgname/environments/envname/provisioning/axstatus
   

2. בדיקת הסטטוס של שרתי ה-Qpid וה-Postgres מתוצאות הקריאה ל-API.
   1. אם הסטטוס של שרתי Qpid ו-Postgres מוצג כ-"הצלחה", המשמעות היא. שרתי ניתוח הנתונים מחוברים בצורה תקינה. המשך אל לא פעיל מזהים ייחודיים אוניברסליים (UUID) של שרתי Analytics.
   2. אם הסטטוס של שרתי Qpid/Postgres הוא UNKNOWN. או "נכשל", מציין בעיה בשרת המתאים.

      לדוגמה, התרחיש הבא מציג את הסטטוס של שרתי Postgres בתור "לא ידוע":

      

      זה יכול לקרות אם יש כשל במהלך הקליטה של Analytics. כשל זה מונעת מההודעות משרתי הניהול להגיע לשרתי Postgres.

רזולוציה

בדרך כלל ניתן לפתור את הבעיה הזו על ידי הפעלה מחדש של השרתים שהופיעה השגיאה "נכשל" או 'לא ידוע'.

1. הפעלה מחדש של כל אחד מהשרתים שסטטוס החיווט של ניתוח הנתונים שלהם מראה 'נכשל' או 'לא ידוע' באמצעות הפקודה הבאה:

   /opt/apigee/apigee-service/bin/apigee-service component restart
   

2. מוצרים לדוגמה:
   1. אם מופיעה הבעיה בשרתי Qpid, ולאחר מכן מפעילים מחדש את שרתי ה-Qpid:

      /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
      

   2. אם הבעיה מופיעה בשרתי Postgres, יש להפעיל מחדש גם את ה-Master וגם את ה-Slave צמתים של שרתי Postgres:

      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
      

3. בדוגמה שלמעלה, התווית 'UNKNOWN' מוצגת עבור שרתי Postgres, לכן כדי להפעיל מחדש את השרת Master ו-Slave Postgres:

   /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
   

מזהים ייחודיים אוניברסליים (UUID) של שרת Analytics לא פעילים

אבחון

1. קבלת ההגדרות של ניתוח הנתונים באמצעות הקריאה הבאה ל-API:

   curl -u user_email:password http://management-server-host:port/v1/analytics/groups/ax
   

   הנה פלט לדוגמה מה-API הזה:

   [ {
     "name" : "axgroup001",
     "properties" : {
       "consumer-type" : "ax"
     },
     "scopes" : [ "myorg~prod", "myorg~test" ],
     "uuids" : {
       "aries-datastore" : [ ],
       "postgres-server" : [ "6777...2db14" ],
       "dw-server" : [ ],
       "qpid-server" : [ "774e...fb23", "29f3...8c11" ]
     },
     "consumer-groups" : [ {
       "name" : "consumer-group-001",
       "consumers" : [ "774e...8c11" ],
       "datastores" : [ "6777...db14" ],
       "properties" : {
       }
     } ],
     "data-processors" : {
     }
   } ]
   

2. מוודאים שהפרטים הבאים בפלט נכונים:
   1. שמות של סביבת הארגון המפורטים ב'היקפים' לרכיב מסוים.
   2. מזהי UUID של שרתי Postgres ושרתי Qpid.
      • כדי לקבל את מזהי ה-UUID של השרת ב-Postgres, מריצים את הפקודה הבאה בכל אחד צמתים של שרתי Postgres:

        curl 0:8084/v1/servers/self/uuid
        

      • כדי לקבל את המזהים הייחודיים של שרת ה-Qpid, מריצים את הפקודה הבאה בכל אחד מה-Qpid צמתים בשרת:

        curl 0:8083/v1/servers/self/uuid
        

3. אם כל הפרטים נכונים, ממשיכים אל נתוני Analytics לא נדחפים למסד הנתונים של Postgres.
4. אם מזהי ה-UUID של שרתי Postgres ו/או ה-Qpid שגויים, ייתכן שרתי הניהול מתייחסים למזהי UUID לא פעילים.

רזולוציה

כדי להסיר את מזהי ה-UUID הלא תקינים ולהוסיף את מזהי ה-UUID הנכונים של השרתים, צריך לפנות לתמיכה של Apigee Edge.