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

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X. מידע

תיאור הבעיה

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

No traffic in the selected date range

הודעות שגיאה

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

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

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

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

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

אבחון

  1. כדאי לבדוק אם מגיעה תנועת גולשים לשרתי ה-API של שרתי ה-proxy בסביבה הארגונית הספציפית למשך הזמן הספציפי שבו מנסים להציג את נתוני הניתוח באחת מהשיטות הבאות:
    1. יש להפעיל את המעקב לכל אחד מממשקי ה-API שנמצאים כרגע בשימוש של המשתמשים שלך, ולבדוק אם יש לך אפשרות לקבל בקשות כלשהן במעקב.
    2. אפשר לראות את יומני הגישה של NGINX (/opt/apigee/var/log/edge-router/nginx/logs/access.log) ולבדוק אם יש רשומות חדשות בשרתי proxy של API למשך הזמן הספציפי.
    3. אם אתם מתעדים מידע משרתי proxy של API בשרת יומנים כמו 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. משתמשים בשאילתת ה-SQL הבאה כדי לבדוק אם הנתונים העדכניים ביותר זמינים במסד הנתונים של Postgres: 
    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. משתמשים בקריאה הבאה ל-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" או כ-"FAILURE", סימן שיש בעיה בשרת התואם.

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

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

רזולוציה

לרוב, אפשר לפתור את הבעיה על ידי הפעלה מחדש של השרתים, שבהם הוצג השגיאה "FAILURE" או "UNKNOWN".

  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. בדוגמה שלמעלה, ההודעה 'לא ידוע' מוצגת לשרתי 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. שמות org-env שמפורטים ברכיב 'היקפים'.
    2. מזהי UUID של שרתי Postgres ושרתי Qpid.
      • כדי לקבל את מזהי ה-UUID של שרת Postgres, מריצים את הפקודה הבאה בכל אחד מהצמתים של השרת של Postgres: 
        curl 0:8084/v1/servers/self/uuid
      • כדי לקבל את מזהי ה-UUID של שרת ה-Qpid, מריצים את הפקודה הבאה בכל אחד מהצמתים של שרת ה-Qpid: 
        curl 0:8083/v1/servers/self/uuid
  3. אם כל הפרטים נכונים, ממשיכים לשלב נתוני Analytics לא מועברים למסד הנתונים Postgres.
  4. אם מזהי ה-UUID של שרתי Postgres ו/או Qpid שגויים, ייתכן ששרתי הניהול מתייחסים למזהי UUID לא עדכניים.

רזולוציה

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